Project

General

Profile

Housekeeping #2319

[linux-libre-lts]: out of date defconfig => libremakepkg pauses and waits for user input

bill-auger - 6 months ago - . Updated 6 months ago.

Status:
in progress
Priority:
bug
Assignee:
% Done:

0%


Description

<GNUtoo> cd to linux-libre sources
<GNUtoo> cp ../defconfig-x86_64 .config
<GNUtoo> make defconfig
<GNUtoo> cp defconfig ../defconfig-x86_64
<GNUtoo> something like that can fix it

History

#1

Updated by GNUtoo 6 months ago

  • Subject changed from [linux-libre-lts]: libremakepkg pauses and waits for user input to [linux-libre-lts]: out of date defconfig => libremakepkg pauses and waits for user input

The defconfig needs to match the kenrel sources => refresh the defconfig with commands like the ones above.

#2

Updated by bill-auger 6 months ago

wouldnt it be best to put those commands as routine in the PKGBUILD ?

#3

Updated by GNUtoo 6 months ago

  • Status changed from open to in progress

I've fixed it in git for linux-libre.
I've improved the configuration mechanism and naming while I was at it.
An updated package for that is being built.

I'll also take care of kernels/linux-libre-x86_64 but beside that one, we also still need to port it to the other kernels which at the time of writing are:
  • libre/linux-libre-hardened
  • libre/linux-libre-lts
  • libre/linux-libre-pae
  • libre/linux-libre-pck
  • kernels/linux-libre-rt
  • kernels/linux-libre-xtreme

With a tool like meld it should be fast to do though, assuming that testing is fast enough to do.

Denis.

#4

Updated by Megver83 6 months ago

  • Assignee changed from GNUtoo to Megver83

NOOOO!!!!

First: why did GNUtoo modified linux-libre (not -lts like this issue???)

Second: That's the normal behavior it must have. When the configs are outdated, I just copy Arch changes (not Arch configs, only the changes), and in the worst of the cases I manually update the config with `make olddefconfig` and then copy that .config file to the abslibre

Third: I almost got a heart attack after I saw the changes. Please, don't do strange things to the kernels, I really try so hard to keep them as closely as I can to upstream, and I hate when someone just go ahead and makes changes without knowing what's he's doing

#5

Updated by GNUtoo 6 months ago

why did GNUtoo modified linux-libre (not -lts like this issue???)

Someone else was compiling the -lts, and as I worked on linux-libre I fixed it in here, and expected the other person working on the -lts to pick and adapt the change.

That's the normal behavior it must have. When the configs are outdated, I just copy Arch changes (not Arch configs, only the changes), and in the worst of the cases I manually update the config with `make olddefconfig` and then copy that .config file to the abslibre

The behavior it should have would be to just fail (instead of waiting indefinitely or to silently update the configuration). For me the waiting indefinitely is the worst as sometimes we need to be able to update kernels and that prevents people compiling it from seeing what is happening and can delay a lot the update. Configuration issues can instead easily be updated (as the build doesn't wait indefinitely).

I almost got a heart attack after I saw the changes. Please, don't do strange things to the kernels, I really try so hard to keep them as closely as I can to upstream, and I hate when someone just go ahead and makes changes without knowing what's he's doing

I'm perfectly aware that such changes have a maintenance cost.

To really fix this issue for good:
1. we need to make it fail instead of silently updating the configuration.
2. Once that's done we will need to upstream the change.

#6

Updated by bill-auger 6 months ago

that was just a matter of mis-communication while multiple
people were trying to push these packages out the door ASAP - to
me, that meant simply answering Yes,Yes,Yes to the prompts -
IIRC, linux-libre-lts was already built and published before
this BR was opened

the main reason for the BR was that it smelled like a bug to have
the build waiting for user input, and i wanted to discuss that
before making changes - i guess gnutoo though i was going to
adapt the PKGBUILD, and i though he was, after it was decided
what to do about it

Also available in: Atom PDF