# Next stable gentoo-sources

## EasterParade

Depclean removed the sources - I let it do that.

When´s the next stable gentoo-sources to be expected?

----------

## fedeliallalinea

It is strange that portage have deleted the sources of the current stable kernel.

Anyway see https://bugs.gentoo.org/818199

----------

## EasterParade

It is just a guess that the sources got deleted. I needed to change something in the kernel but got this:

```
make && make modules_install && make install

  CALL    scripts/checksyscalls.sh

  CALL    scripts/atomic/check-atomics.sh

  DESCEND  objtool

make[4]: *** Keine Regel vorhanden, um das Ziel „/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.0/include/stddef.h“, 

  benötigt von „/usr/src/linux-5.10.61-gentoo/tools/objtool/fixdep.o“, zu erstellen.  Schluss.

make[3]: *** [Makefile:41: /usr/src/linux-5.10.61-gentoo/tools/objtool/fixdep-in.o] Fehler 2

make[2]: *** [/usr/src/linux-5.10.61-gentoo/tools/build/Makefile.include:5: fixdep] Fehler 2

make[1]: *** [Makefile:68: objtool] Fehler 2

make: *** [Makefile:1948: tools/objtool] Fehler 2

```

Never happened before. The symlink is fine.

I cannot figure any other reason for it except that the source is gone.

Am I wrong?

----------

## Hu

Yes, you are wrong here.  I don't read German (next time, please use LC_ALL=C so that messages are not translated), but I recognize the error anyway.  You have removed the version of gcc which provided /usr/lib/gcc/x86_64-pc-linux-gnu/10.3.0/include/stddef.h, so now the generated Makefile has a stale dependency.  You need to remove the generated Makefile(s) and let the kernel regenerate them with the new gcc version.

----------

## NeddySeagoon

transsib,

If the sources were gone, the Makefile would be gone too.

That produces a different error. Something like  *Quote:*   

> No rule to make ...

 

You would not be able to run make at all.

Heh "Keine Regel vorhanden, um das Ziel" translates by machine to  "No rule present to reach the target"

You have a Makefile. Make went down 3 levels.  

```
make[3]: *** [Makefile:41
```

and gave a line number where the error was triggered.

Does the file

```
 /usr/lib/gcc/x86_64-pc-linux-gnu/10.3.0/include/stddef.h
```

exist?

----------

## EasterParade

No, but 

```
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/stddef.h
```

 does.

Which Makefile do I need to delete, the one in /usr/src/linux or those in /usr/src/linux/tools/build?

----------

## NeddySeagoon

transsib,

Neither. You need to delete all the generated Makefiles in the kernel tree. There are lots.

```
make clean
```

i will do that.

As you have changed gcc versions, you must rebuild the entire kernel anyway, so thats a good place to start.

----------

## EasterParade

Thank you, make clean is on the way.

----------

## EasterParade

Nice.

Works now. Next time gcc gets upgraded I not only compile deep system but gentoo-sources too

after oneshot libtool.

----------

## EasterParade

Hu wrote:

 *Quote:*   

> I don't read German (next time, please use LC_ALL=C so that messages are not translated)

 

I apologize but I understood LC_ALL was discouraged. 

But may be I´m wrong here as well.

----------

## NeddySeagoon

transsib,

You can set LC_ALL=C on the command line when you want to post an error.

There is no need to have it as a global setting.

----------

## EasterParade

NeddySeagoon wrote:

 *Quote:*   

> You can set LC_ALL=C on the command line when you want to post an error.

 

Ugh ... I am such a N00b   :Sad: 

I needed to recompile the kernel for nfs. Up to now I have backups on usb sticks.

I now switch to a NAS; works wonders on Windows but I cannot seem to get nfs mounting to work

here on Gentoo. I had it working (mount as root) and rsync a nice backup. The next day mount stopped working

for no apparent reason as I haven´t changed anything on the NAS that is the nfs server.

So now I try to use cifs although I don´t like it.

Thank you for your help.

----------

## Hu

I am not aware of a specific deprecation of LC_ALL, but since it overrides all other LC_* variables, it may be discouraged because it lacks precision.  For example, if you want German messages, but French collation rules, you cannot set LC_ALL, since it will force both messages and collation to the value picked by LC_ALL.  For such a scenario, you would instead set LC_MESSAGES to German and LC_COLLATE to French.

I usually use LC_ALL in forum recommendations like this because it's shorter than LC_MESSAGES, and because when the goal is to force English text, it's usually preferable to suppress all localization.  Also, if the user I am addressing chose to set LC_ALL to a non-English locale, setting LC_MESSAGES will have no effect.  Conversely, if the user set LC_MESSAGES and left LC_ALL unset, my request to use LC_ALL will still result in untranslated output.

The command locale, without arguments, shows the currently active localization settings.  We don't need those to help you here, but it may be of interest to you.

As regards getting untranslated output:

```
LC_ALL=C make <your-arguments-here>
```

 will do the override for a single command, assuming you are using GNU Bash or a similar shell.

 *NeddySeagoon wrote:*   

> Heh "Keine Regel vorhanden, um das Ziel" translates by machine to "No rule present to reach the target" 

 That's pretty close.

```
$ make -f /dev/null /foo

make: *** No rule to make target '/foo'.  Stop.
```

 *transsib wrote:*   

> So now I try to use cifs although I don´t like it. 

 Start a new thread and ask about your NFS problem.  Perhaps someone can help you get it working again.

----------

## EasterParade

Thank you Hu. I got nfs (version 3; gonna switch to version 4 next) working again.

No cifs needed.

All that´s left to do now is find out how to gain access to the share as user in Dolphin,

create a cron job for rsync and fix mounting of the other users` shares so that they can rsync their backups again.

I am happy that I can become real root on the NAS using ssh as the admin so that I can see and edit

what I´ve created on the webbased gui of the NAS (which is quite transparent for a gui).

The NAS` system is a fully fledged, clean&mean Linux system.

Have a nice weekend or what´s left of it everabody.

----------

## figueroa

Re: Next stable kernel

You may be able to extrapolate something from my most recent gentoo-sources entries in /var/log/kernel. 

```
May 7  gentoo-sources-5.4.92

Jul 14 gentoo-sources-5.4.131

Jul 21 gentoo-sources-5.4.134

Aug 30 gentoo-sources-5.4.143
```

I'm following the stable 5.4 series on my primary desktop.

Without any insider information, I'd say it looks like we get new kernel releases when we need them, to incorporate important bug or security fixes. I could be wrong. It might be random, it might be subject to maintainer availability, but I'm going with my first guess until revealed otherwise.

----------

## Naib

stable kernel's follow upstream LTS labeling

----------

## figueroa

I'm masking kernel series I'm not ready to run:

```
$ grep sources /etc/portage/package.mask

>=sys-kernel/gentoo-sources-5.5
```

This way I do get updates to the 5.4 series rather than following whatever current stable might be.

----------

## pietinger

 *figueroa wrote:*   

> I'm masking kernel series I'm not ready to run:
> 
> ```
> $ grep sources /etc/portage/package.mask
> 
> ...

 

If you do an "eix gentoo-sources" you will see, there is also a stable 5.4.143 (for today) and the newest is 5.4.155 as unstable.

If someone want to have the newest kernel of an specific series then it must be the unstable of this series. You need then in your /etc/portage/package.accept_keywords:

```
sys-kernel/gentoo-sources ~amd64
```

I have the same with the 5.10-series. Stable is 5.10.61; newest is 5.10.75 which I have, because in my package.mask I have:

```
>=sys-kernel/gentoo-sources-5.11
```

----------

## figueroa

As I wrote,  *Quote:*   

> I'm following the stable 5.4 series on my primary desktop.

  (Emphasis on "stable.")

I've had 5.4.143 since Aug 30, and it's exactly what I want.

----------

## freke

 *pietinger wrote:*   

>  *figueroa wrote:*   I'm masking kernel series I'm not ready to run:
> 
> ```
> $ grep sources /etc/portage/package.mask
> 
> ...

 

I do (/etc/portage/package.accept_keywords and no masking)

```
=sys-kernel/gentoo-kernel-5.10*

=virtual/dist-kernel-5.10*
```

Seems to achieve the same and will jump onto the next LTS when it's marked stable in portage.

----------

## Hu

I think there is a linguistic ambiguity here.  There is Gentoo stable (ARCH) vs testing (~ARCH), and there is the upstream stable kernel (v5.x.y), in both short-term and long-term flavors.  There is also the upstream non-stable kernel (Linus's v5.x), but nobody here is requesting that.

figueroa wants to use only kernels that come from an upstream long-term stable series, which are also marked as Gentoo stable (ARCH) for his architecture.  pietinger wants an upstream long-term stable series, but is willing to take any kernel in that series that upstream considers stable, without waiting for Gentoo to move it from testing (~ARCH) to stable (ARCH).  Concretely, pietinger will accept a kernel as soon as Greg KH sends the announcement that it is available (ignoring the delay for a Gentoo maintainer to add the ebuild).  figueroa will accept the kernel once the Gentoo maintainer decides to keyword it ARCH, which could take days or weeks, depending on availability, regression reports, etc.

I make no judgment as to whose decision is correct.

Meanwhile, freke is dealing with a related but distinct setup.

----------

## pietinger

Hu,

I am not a native english speaker (+ I am an old man) and therefore I am very thankful for your exact explanation (I couldnt do). I also want to apologize for any misunderstanding I provoked - espacially to @figueroa. I only wanted to give a hint (for all readers of this thread) how to get the newest kernel source of a given series. Thanks again, Hu

and many greetings,

Peter

----------

## Hu

Considering the reuse of terms by different projects (stable for Gentoo versus stable for upstream) to mean slightly different things, I would not be surprised if some native English speakers also got lost in the subtleties here.  I think I have seen that exact confusion in other threads, dealing with other projects.  That is why I focused on spelling out upstream stable versus Gentoo stable in my post above.

----------

## NeddySeagoon

 *Hu wrote:*   

> I make no judgment as to whose decision is correct. 

 

They all are. :)

Seriously, thats a design decision for the admin.

----------

## figueroa

 *pietinger wrote:*   

> Hu,
> 
> I am not a native english speaker (+ I am an old man) and therefore I am very thankful for your exact explanation (I couldnt do). I also want to apologize for any misunderstanding I provoked - espacially to @figueroa. I only wanted to give a hint (for all readers of this thread) how to get the newest kernel source of a given series. Thanks again, Hu
> 
> and many greetings,
> ...

 

Yes, Hu nailed it with his very careful unwinding of our use of language and technical terms. I think we both are doing exactly what we intend, and I think the discussion here may be helpful for all who stumble upon it.

Blessings all around.

----------

