[gentoo-dev] [news item review] sys-devel/kgcc64 removal on sparc
Hi, Please have a look at the following news item. Thanks! Title: sys-devel/kgcc64 removal on sparc Author: Raúl Porcel Content-Type: text/plain Posted: 2014-11-11 Revision: 1 News-Item-Format: 1.0 Display-If-Profile: default/linux/sparc sys-devel/kgcc64 is going to be removed from the sparc system package set since the normal sys-devel/gcc can, since version 4.4, build 64bit kernels. Until now, you had to use CONFIG_CROSS_COMPILE="sparc64-unknown-linux-gnu-" in your kernel configuration, but with sys-devel/kgcc64 going away, you need to remove that option.
Re: [gentoo-dev] Packages up for grabs
> * dev-vcs/mr > * dev-vcs/vcsh On second thought, I think, I'll adapt both of them. :-) Best, Matthias
Re: [gentoo-dev] Packages up for grabs
Am 11. Nov 2014, 15:59 schrieb Pavlos Ratis : > * dev-vcs/mr I can take care of this one - I use dev-vcs/mr quite heavily. Best, Matthias
[gentoo-dev] Packages up for grabs
Hello all, Due to lack of time I'm giving up some packages. Feel free to take them. I'll remove myself from metadata in the following packages within 10 days: * app-admin/cronolog * app-misc/recoll * app-shells/sash * dev-vcs/mr * dev-vcs/vcsh * net-analyzer/portbunny * net-libs/udns Comaintained packages(herds,devs): * app-admin/denyhosts * dev-python/tweepy * kde-misc/kimtoy * kde-misc/plasma-network-status * net-im/turses I will also drop myself from the net-proxy herd. Thanks, Pavlos Ratis
Re: [gentoo-dev] [news item review] bash-completion-2.1-r90, version 2
* Michał Górny schrieb am 11.11.14 um 12:06 Uhr: Dnia 2014-11-11, o godz. 09:53:58 Marc Schiffbauer napisał(a): * Michał Górny schrieb am 10.11.14 um 22:18 Uhr: >Hello, developers. > >I'm planning to commit this news item before >=2.1-r90 goes stable. >I have rewritten the message to be more user-oriented like Rich >suggested (big thanks to you!) and added a paragraph about loading >bashcomp in bashrc. > >Please review. Looks good to me, but to remove "stale symlinks" you need to add the -L option to find. Or write just "symlinks", because like this it will remove *all* symlinks. Is the attached version more clear? Yes, I think so. -- 0x35A64134 - 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 signature.asc Description: Digital signature
Re: [gentoo-dev] Re: [news item review] bash-completion-2.1-r90, version 2
Dnia 2014-11-11, o godz. 11:21:00 Duncan <1i5t5.dun...@cox.net> napisał(a): > Michał Górny posted on Tue, 11 Nov 2014 11:03:03 +0100 as excerpted: > > > Dnia 2014-11-11, o godz. 09:53:58 Marc Schiffbauer > > napisał(a): > > > >> * Michał Górny schrieb am 10.11.14 um 22:18 Uhr: > >> >Hello, developers. > >> > > >> >I'm planning to commit this news item before >=2.1-r90 goes stable. > >> >I have rewritten the message to be more user-oriented like Rich > >> >suggested (big thanks to you!) and added a paragraph about loading > >> >bashcomp in bashrc. > >> > > >> >Please review. > >> > >> Looks good to me, but to remove "stale symlinks" you need to add the -L > >> option to find. Or write just "symlinks", because like this it will > >> remove *all* symlinks. > > > > Well, the meaning was 'all symlinks since they are stale now'. I will > > try to reword it. > > Note that some users (including me) have symlinks in > /etc/bash_completion.d/ that point to their own completions in > /usr/local/share/bash_completion/ or the like. If you do custom stuff like this, you already know enough to understand the consequences of removing the symlinks. You were on your own already, so don't expect that we're going to start holding your hand now. > But, the symlinks pointing to my completions in /usr/local are most > assuredly *NOT* stale, neither will remerging anything make them so. > > So I don't want to remove those symlinks, or I'd lose the connection to > my own completions (presuming the normal bash completion doesn't look in > /usr/local/share/bash_completion for them... I never claimed I to be a > bash-completion wizard, only to have hacked up something that seems to > work, and I want it to STAY working). Of course, you could have asked for proper /usr/local support... but why? It's easier to hack things around then complain. > So if indeed all installed symlinks should be stale at that point, then > the suggested -L -type l -delete would be a good change, as it wouldn't > remove any non-stale symlinks users had put there themselves. People who installed bash-completion after 27.08 have all completions in completionsdir already. For them, the symlinks will still be valid yet unnecessary. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: [news item review] bash-completion-2.1-r90, version 2
Michał Górny posted on Tue, 11 Nov 2014 11:03:03 +0100 as excerpted: > Dnia 2014-11-11, o godz. 09:53:58 Marc Schiffbauer > napisał(a): > >> * Michał Górny schrieb am 10.11.14 um 22:18 Uhr: >> >Hello, developers. >> > >> >I'm planning to commit this news item before >=2.1-r90 goes stable. >> >I have rewritten the message to be more user-oriented like Rich >> >suggested (big thanks to you!) and added a paragraph about loading >> >bashcomp in bashrc. >> > >> >Please review. >> >> Looks good to me, but to remove "stale symlinks" you need to add the -L >> option to find. Or write just "symlinks", because like this it will >> remove *all* symlinks. > > Well, the meaning was 'all symlinks since they are stale now'. I will > try to reword it. Note that some users (including me) have symlinks in /etc/bash_completion.d/ that point to their own completions in /usr/local/share/bash_completion/ or the like. Now I don't claim to know much about creating completions, but for instance, many of my completions were for emerge stubs (ea for emerge --ask, etc), so I was able to simply source the gentoo completion in my own, then use emerge's completion function for my stubs. With this update I had to figure out enough about completions to figure out how to update mine, and I've already done so. But, the symlinks pointing to my completions in /usr/local are most assuredly *NOT* stale, neither will remerging anything make them so. So I don't want to remove those symlinks, or I'd lose the connection to my own completions (presuming the normal bash completion doesn't look in /usr/local/share/bash_completion for them... I never claimed I to be a bash-completion wizard, only to have hacked up something that seems to work, and I want it to STAY working). So if indeed all installed symlinks should be stale at that point, then the suggested -L -type l -delete would be a good change, as it wouldn't remove any non-stale symlinks users had put there themselves. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] [news item review] bash-completion-2.1-r90, version 2
Dnia 2014-11-11, o godz. 09:53:58 Marc Schiffbauer napisał(a): > * Michał Górny schrieb am 10.11.14 um 22:18 Uhr: > >Hello, developers. > > > >I'm planning to commit this news item before >=2.1-r90 goes stable. > >I have rewritten the message to be more user-oriented like Rich > >suggested (big thanks to you!) and added a paragraph about loading > >bashcomp in bashrc. > > > >Please review. > > Looks good to me, but to remove "stale symlinks" you need to add the > -L option to find. Or write just "symlinks", because like this it > will remove *all* symlinks. Is the attached version more clear? -- Best regards, Michał Górny Title: bash-completion-2.1-r90 Author: MichaÅ Górny Content-Type: text/plain Posted: 2014-MM-DD Revision: 1 News-Item-Format: 1.0 Display-If-Installed: signature.asc Description: PGP signature
Re: [gentoo-dev] udev-9999 (and upcoming 217) no longer has userspace firmware loader (will need Linux 3.7 for firmware's to be loaded)
On 11/11/14 01:41, Mike Frysinger wrote: On 01 Sep 2014 06:30, Samuli Suominen wrote: On 01/09/14 03:37, Patrick Lauer wrote: Consider this message a prenotice, now you know it's gone ... one more win for eudev. Sigh. They are planning in dropping the userspace loader as well, it's redudant afterall. Most firmware are kernel loadable by >= 3.7 Everything is kernel loadable (3.7 and few later versions had some exceptions for more rare drivers) in latest echo /bin/busybox mdev > /proc/sys/kernel/hotplug -mike I will continue to maintain eudev 1.10.x which has userland firmware loading support. Versions 2.0 and above removed it. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] [news item review] bash-completion-2.1-r90, version 2
Dnia 2014-11-11, o godz. 09:53:58 Marc Schiffbauer napisał(a): > * Michał Górny schrieb am 10.11.14 um 22:18 Uhr: > >Hello, developers. > > > >I'm planning to commit this news item before >=2.1-r90 goes stable. > >I have rewritten the message to be more user-oriented like Rich > >suggested (big thanks to you!) and added a paragraph about loading > >bashcomp in bashrc. > > > >Please review. > > Looks good to me, but to remove "stale symlinks" you need to add the > -L option to find. Or write just "symlinks", because like this it > will remove *all* symlinks. Well, the meaning was 'all symlinks since they are stale now'. I will try to reword it. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [news item review] bash-completion-2.1-r90, version 2
* Michał Górny schrieb am 10.11.14 um 22:18 Uhr: Hello, developers. I'm planning to commit this news item before >=2.1-r90 goes stable. I have rewritten the message to be more user-oriented like Rich suggested (big thanks to you!) and added a paragraph about loading bashcomp in bashrc. Please review. Looks good to me, but to remove "stale symlinks" you need to add the -L option to find. Or write just "symlinks", because like this it will remove *all* symlinks. $ find /etc/bash_completion.d -type l -delete -Marc -- 0x35A64134 - 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 signature.asc Description: Digital signature
