Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/04/2017 01:05 PM, William L. Thomson Jr. wrote: >[snip] >> Maintainers of individual packages have the most knowledge about how to >> best deliver that specific package, but maintainers of profiles have >> the best understanding of what people want to see. > > Yes has to be a balance. I do not believe package maintainers will always > share the vision of the profiles. > > Said another way, if defaults were sane enough, would profiles be necessary? > > Profiles are kind of an extra added benefit to the end user, and those making > the profiles. Mostly a benefit for the end user. There isn't much benefit to > the > package maintainer. I could not really see anything that would give them > reason to spend their time on something that would not benefit them. > I can't speak for other maintainers but generally if there's an issue in an ebuild I maintain, I try to figure out a) the specific problem, and b) the simplest and most-effective solution. If an ebuild I maintain is broken on arm64, for example, it's still my responsibility to figure out how to get it working, assuming the software was written in a way to allow for that build anyway. Since I don't run anything other than amd64 right now, I have to depend on others to find issues for other arches. Generally I'll accept any change as long as it meets our ebuild standards and doesn't exchange one problem for another. One could argue "of course it benefits you", but I don't do it because it benefits me. I do it because a) it fixes a problem I probably didn't know about and b) it's how we make Gentoo better. I don't have an opinion on profiles. I like the idea of them and respect the work that goes into them. If maintainers need to make small changes here or there so their packages work on specific profiles, I don't see the problem. We do commit+push over typos; a profile is more important than that, so naturally we should have little issue ironing out support when the errant wrinkle comes up. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News item for uclibc-ng
On Wed, Feb 08, 2017 at 02:37:52PM -0500, Anthony G. Basile wrote: > 0. Because of changes in the library structure in previous versions, > make sure you are working with 1.0.19 and rebuild world using > > emerge -evq @world --verbose --quiet? just emerge -e @world is probably better. > > 7. For good measure, rebuild the entire system > > emerge —evq @world Another non-ascii I havent tested, but this appears what you want: grep --color='auto' -P -n "[\x80-\xFF]" filename from here: http://stackoverflow.com/a/9395552 -- Jason
Re: [gentoo-dev] News item for uclibc-ng
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Anthony G. Basile: > Hi everyone, > > Attached you'll find a news item for uclibc-ng. I'd like to push > it out in a few days. > >> This will make sure all executables link directly against >> libc.so.0 (as should be "all **the** executables" >> reported by `readelf -d`) rather than via sym links like >> libdl.so.0 -> sym links -> symlinks >> libc.so.0. Then upgrade from 1.0.19 to 1.0.20 without >> symlink-combat: symlink-combat -> symlink-compat >> 1. Get rid of the obstack.h header since its used by configure >> scripts its -> it's >> 6. Finally updated uclibc-ng to the latest updated -> update -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJYm88FAAoJEIT4AuXAiM4z85EIAKCBZdivRA/kliIcj5rCFsJC pRKy7IhNgG8K+zHktV90QbEIXVdOpnZLMx315NEz0vGnPR7Ik/fZqMF8Jwgty26O OHbb2sYEU6KqS3q/Qwa1/OH+ysfX0Jp2rHIPp2X7gSFPQ4AQyQz5od35b24+whsJ dRn9M64lo18+PvAD2L5dz9tG2noazkddWN6rugOMQzQbGO/Rk+Z5M3Zq6zJKBVHO gZCsreQWsqmgHDxX7TzMdqzY0Pt5M5ausvmc689vskYSCt9edhOfYTi2dP+AqLch 4OB5fWcPZe5yGFOeAtLgg0ymBMxSbv8a1Zf5tKwyXsJSE6hJuKgUb/K6gCm1N0Q= =lVV1 -END PGP SIGNATURE-
Re: [gentoo-dev] News item for uclibc-ng
On 2/8/17 3:23 PM, Andrey Utkin wrote: > On Wed, Feb 08, 2017 at 02:37:52PM -0500, Anthony G. Basile wrote: >> Hi everyone, >> >> Attached you'll find a news item for uclibc-ng. I'd like to push it out >> in a few days. >> > >> This will make sure all executables link directly against libc.so.0 (as >> reported by `readelf -d`) rather than via sym links like libdl.so.0 -> >> libc.so.0. Then upgrade from 1.0.19 to 1.0.20 without symlink-combat: >> >> USE=“-symlink-compat" emerge =sys-libs/uclibc-ng-1.0.20 > > First quote sign is non-ascii so command doesn't work when copy-pasted > to terminal. > Thanks, I wrote this on my mac which does things like that. Is there a good utility for catching non-ascii chars? -- 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 for uclibc-ng
On Wed, Feb 08, 2017 at 02:37:52PM -0500, Anthony G. Basile wrote: > Hi everyone, > > Attached you'll find a news item for uclibc-ng. I'd like to push it out > in a few days. > > This will make sure all executables link directly against libc.so.0 (as > reported by `readelf -d`) rather than via sym links like libdl.so.0 -> > libc.so.0. Then upgrade from 1.0.19 to 1.0.20 without symlink-combat: > > USE=“-symlink-compat" emerge =sys-libs/uclibc-ng-1.0.20 First quote sign is non-ascii so command doesn't work when copy-pasted to terminal.
[gentoo-dev] News item for uclibc-ng
Hi everyone, Attached you'll find a news item for uclibc-ng. I'd like to push it out in a few days. -- 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 Title: Upgrade to =sys-libs/uclibc-ng-1.0.22 Author: Anthony G. Basile Content-Type: text/plain Posted: 2017-02-10 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-libs/uclibc-ng Display-If-Profile: default/linux/uclibc/amd64 Display-If-Profile: hardened/linux/uclibc/amd64 Display-If-Profile: default/linux/uclibc/arm/armv7a Display-If-Profile: hardened/linux/uclibc/arm/armv7a Display-If-Profile: default/linux/uclibc/mips Display-If-Profile: hardened/linux/uclibc/mips Display-If-Profile: default/linux/uclibc/mips/mipsel Display-If-Profile: hardened/linux/uclibc/mips/mipsel Display-If-Profile: default/linux/uclibc/ppc Display-If-Profile: hardened/linux/uclibc/ppc Display-If-Profile: default/linux/uclibc/x86 Display-If-Profile: hardened/linux/uclibc/x86 There have been two major changes in uclibc-ng which need special attention when upgrading. Version 1.0.19 restructured the breakout libraries, libcrypt.so.0, libdl.so.0, and friends. The functions in those libraries are now included in libuClibc-0.1.0.19.so. Version 1.0.21 and above removed libc support for obstack, expecting packages to use their bundled GNU lib code. Both changes require special upgrade procedures which we outline below: 0. Because of changes in the library structure in previous versions, make sure you are working with 1.0.19 and rebuild world using emerge -evq @world This will make sure all executables link directly against libc.so.0 (as reported by `readelf -d`) rather than via sym links like libdl.so.0 -> libc.so.0. Then upgrade from 1.0.19 to 1.0.20 without symlink-combat: USE=“-symlink-compat" emerge =sys-libs/uclibc-ng-1.0.20 1. Get rid of the obstack.h header since its used by configure scripts to look for function prototypes and macros. mv /usr/include/obstack.h ~ 2. We also need to force the use of any bundled gnu lib code. We can do this by removing the definition of _GNU_OBSTACK_INTERFACE_VERSION from gnu-version.h cp /usr/include/gnu-versions.h ~ sed -i -e '/#define _GNU_OBSTACK/d' /usr/include/gnu-versions.h 3. We need to tell stdio.h that __UCLIBC_HAS_OBSTACK__ is false. We do this via the uClibc_config.h file. cp /usr/include/bits/uClibc_config.h ~ sed -i -e '/__UCLIBC_HAS_OBSTACK__/ s/1/0/' \ /usr/include/bits/uClibc_config.h 4. To be safe, you may want to back up your entire /lib directory so you can fall back should something go wrong: cp -a /lib /lib.bak 5. Now when we rebuild @world, all packages will use their bundled obstack code rather than depending on libc to provide it. ac_cv_func_obstack_vprintf=no emerge --keep-going --exclude \ sys-libs/uclibc-ng -evq @world 6. Finally updated uclibc-ng to the latest emerge =sys-libs/uclibc-ng-1.0.22 7. For good measure, rebuild the entire system emerge —evq @world
[gentoo-dev] GNOME team meeting 2017-02-10
The Gentoo GNOME team will meet on Friday 2017-02-10, 20:00 UTC in the #gentoo-meetings channel on Freenode. https://www.timeanddate.com/worldclock/fixedtime.html?iso=20170210T20 Agenda: * GNOME 3.22 stabling status ** Should we revert default session to X11 before stabling even if USE=wayland is used, as 3.24 is close-by that makes it work better and some team members themselves are having issues with it on 3.22? * Do we need an upgrade guide for 3.22? * - ebuilds in main tree? * Overlay vs main tree for beta/rc releases * Overlay vs main tree for early development releases * Meta packages dependencies and USE flags (gnome, gnome-light, gnome- core-libs, etc) * Lead elections (might get deferred to e-mails for a quorom) * Open floor signature.asc Description: This is a digitally signed message part
