[gentoo-dev] borked release media
Hey people, what are we going to do with bugs like: https://bugs.gentoo.org/show_bug.cgi?id=421839 https://bugs.gentoo.org/show_bug.cgi?id=445848 I'd like to help with things. Is the process of building livecd .isos and stages documented somewhere? I'd like to reproduce problems locally, work on fixes, and join the release teams. I also think points made at https://bugs.gentoo.org/show_bug.cgi?id=438234 are very reasonable, and we should do more testing of published media/stages. The serious problem here is that we need *new* users. A non-working install CD is a really bad thing here, don't you think? ;-) Again, I'm willing to do the work, just need some documentation/pointers. Paweł signature.asc Description: OpenPGP digital signature
[gentoo-dev] OK to unmask icu-50?
# Tomáš Chvátal scarabeus@ (04 Nov 2012) # Masked for testing with gcc-4.7 and to verify reverse deps dev-libs/icu-49.9.1 I think with icu-50.1-r2 the problems are solved. It should get more testing in ~arch. I'd like to unmask it. WDYT? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Proposal to end-of-life tree-clean old profiles/updates/ files
On 12/9/12 1:17 PM, Brian Dolbec wrote: Starting from a question by Markos in #gentoo-portage about whether to remove entries in profiles/updates for tree-cleaned packages... What's the advantage of doing that? I propose that we say, once a year, schedule a tree-cleaning of old updates files. These updates files could be added to a tarball made available for download. That way if they are needed to update a system older than what the main tree has been tree-cleaned to. They can then be manually downloaded, extracted to the normal location and then run the fixpackages command. I think that complicates the process. :-/ But maybe the advantages outweigh that. The main question here is what is a reasonable length of time to keep the updates actively in-tree? -- From my experience in the forums, I think any updates older than 4 years should be subject to tree-cleaning. Yeah, 4 years is ancient and would probably be non-trivial to update anyway. -- Most old systems that have been updated tend to be less than that, probably about 2 years. 2 years seem reasonable. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] OK to unmask icu-50?
On 12/7/12 11:51 PM, Diego Elio Pettenò wrote: Sounds good to me. Tinderbox was fine with the latest changes to icu. Just for reference, next time it would be nice to unmask this when chromium and libreoffice are both bumped (i.e., two days ago), so that people don't have to rebuild them twice... luckily for me I kept it unmasked when testing it ;) Unmasked for everyone then. Thank you for testing. I think this is quite a good moment for unmasking: I've just done a dev channel bump of Chromium, we're going to have a stable one for security issues, and beta has been done 3 days ago. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Defaulting for debug information in profiles
On 12/17/12 2:11 AM, Tomáš Chvátal wrote: Since we already have splitdebug for quite time (and I suppose quite few of us are using it) how about making it to default profiles default enabled and add -g to default cflags. Currently it is only enabled in the developer profile. Fully seconded. For people raising concerns in this thread: it can be easily disabled. I think good defaults are really important. What do you think is more reasonable to assume: (1) that the user hits crashes and wants to submit a good bug report but doesn't want to recompile half of the system, or (2) that the user has very limited disk space or some other kind of special configurations. Note that (2) is totally fine, I just think it's less likely to happen (hopefully we can avoid a bias here with people thinking if _they_ have a setup that can't use splitdebug or something, the same would apply to everybody else). Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Moving our/portage stuff to var
On 12/17/12 2:19 AM, Tomáš Chvátal wrote: With respect to reality how stuff is done in the linux land all the variable data should be in /var so we should adjust and move it in there too. What would you think? Fully seconded. +1 to /var/cache/portage and having distfiles outside of the portage tree directory. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] College Course in Gentoo Development
On 12/17/12 7:32 AM, Anthony G. Basile wrote: So what should I teach? Here's what I've got off the top of my head: Please comment. If it gets systematized enough, it can be a guide to future devs too. Everything will be creative commons. I think it's worth to mention somewhere that although packages take longer to compile than downloading binaries, people don't have to _watch_ the compilation, and many things can be done e.g. overnight. Also, remember that Google's ChromeOS takes a lot of things from Gentoo, including the package manager and many ebuilds. The idea here is that it has applications in the industry. Oh, unbundling libraries _might_ be valuable too. Or automagic dependencies and other such packaging issues. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Time based retirements
On 12/20/12 7:21 PM, Doug Goldstein wrote: I'm curious who had the brain dead idea to retire Gentoo developers that are still interested in the distro, that maintain low activity packages for herds that are stretched way too thin, and are still contributing to the distro in many ways other than direct CVS commits (e.g. overlays, user support, providing hardware to other devs, etc). Dough, thank you for rising the issue. I'm receiving the undertakers@ e-mail, so I have a pretty good view of what's happening. I have several suggestions how we can improve things: 1. 3 months is too short period anyway. 2. Think through what the goals are. We do not want to retire as many people as possible. We do not want to frustrate people who do contribute to Gentoo. We do not want to discourage people who consider becoming new developers. At least I don't. 3. I think what's important is to keep packages maintained. I consider maintainership to be a duty, not a privilege. If someone is listed in metadata.xml, but is not really maintaining the package, that creates a formal illusion that the package is maintained, and may prevent other people from stepping up and taking maintenance of that package. 4. I suggest that we focus on the above: keeping packages maintained. Taking packages out of hands of inactive/overworked maintainers is good. They can always become _more_ active, which is easier if they retain cvs access. If they make a single commit every 3-6 months, I'm fine with that as long as things are maintained properly. 5. Remember that cvs/bugzilla activity is not the only way of contributing. It's probably most tanglible and very needed, but let's not reduce real people and their real world situations, and their effort to contribute to just dates and numbers. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] glibc-2.17: nscd is optional
On 12/29/12 5:24 PM, Mike Frysinger wrote: rough poll: how many people actually care about nscd ? i'm making it into a USE flag for glibc-2.17 and it's easiest for me to do IUSE=nscd which means it'd default to off. If you want, you can still enable the nscd USE flag in the profile so it is on by default. I'm fine either way, just wanted to note the technical possibility. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo and Root CAs
On 1/1/13 2:51 AM, Dirkjan Ochtman wrote: IMO it would probably be good to limit our CA roots to Mozilla's libnss selection by default and perhaps add a packaged selection of secondary CA's (like CACert) for those who are so inclined. I think that's a good idea: make it easy to only use the Mozilla CA roots, and also make it easy to use the other roots like CACert. Seems like it could be just a USE flag for affected packages. Paweł signature.asc Description: OpenPGP digital signature
[gentoo-dev] collision-protect - protect-owned ?
It came up again with https://bugs.gentoo.org/show_bug.cgi?id=449918, and I think it's worth to think about a better fix. I still keep hitting mysterious collisions with orphaned files from time to time. How about switching the developer profile from collision-protect to protect-owned, and proceeding with enabling protect-owned by default for all profiles? (not all developers are using the developer profile) Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Please guys use checkpath in init scripts
On 1/6/13 8:30 AM, Diego Elio Pettenò wrote: I just gave a quick look at the init scripts installed on the tinderbox, and the amount of them that use mkdir to create the directories in /run and similar is astounding. Please check `man runscript` and use the checkpath helper instead. Should this be documented in devmanual or something? :) Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)
On 1/4/13 9:47 PM, Donnie Berkholz wrote: I did much of the design work nearly 2 years ago: http://dev.gentoo.org/~dberkholz/gentoo_website/gentoo_landing_black.png http://dev.gentoo.org/~dberkholz/gentoo_website/gentoo_landing_install.png http://dev.gentoo.org/~dberkholz/gentoo_website/gentoo_landing_handbook.png http://dev.gentoo.org/~dberkholz/gentoo_website/gentoo_landing_handbook2.png Some early work on it using Bootstrap: http://a3li.li/~alex/g.o/ This looks good to me! That said, why the hell are we wasting time implementing our own website backend when we should be using a CMS? We're here to make a distro, not a website framework. No reason we should care, day to day, about anything but frontend theming and content. +1 Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] DNSSEC (w/ DLV) live on *.dev.gentoo.org
On 1/6/13 5:31 PM, Robin H. Johnson wrote: Just a heads up, DNSSEC is now live on *.dev.gentoo.org hosts. Wow, that sounds pretty cool to me! This could be a nice news: Gentoo one of the first to deploy DNSSEC - what do you think? :) Paweł signature.asc Description: OpenPGP digital signature
[gentoo-dev] January stabilization candidates
Please review attached automatically generated stabilization candidates for January. I don't want to annoy people with automatically filed bugs, and at the same time I also received lots of positive feedback about the effort to keep the stable tree more up-to-date. I think the best way to proceed is to listen to that feedback and continue the effort, while also keeping an updated list of exclusions for packagers/herds that are actively stabilized by maintainers. Paweł # robbat2 app-admin/diradm-2.9.7.1 # haskell app-admin/haskell-updater-1.2.0.8 # radhermit app-admin/lsyncd-2.1.4 # andreis.vinogradovs maksbotan app-admin/sagan-rules-20120918 # desktop-misc app-admin/usbview-2.0 # jer app-admin/whowatch-1.8.3-r1 # radhermit app-backup/duplicity-0.6.20 # benchmarks app-benchmarks/httperf-0.9.0-r2 # app-dicts app-dicts/myspell-sv-2.11 # hwoarang qt app-editors/qxmledit-0.8.3.1 # emacs app-emacs/gentoo-syntax-1.20 # ml emacs app-emacs/ocaml-mode-3.12.1-r1 # maintainer-needed app-emulation/dinero-4.7-r1 # forensics app-forensics/libewf-20121209 # fonts app-i18n/unicode-data-6.1.0 # xmw app-laptop/thinkfan-0.8.1-r1 # shell-tools app-misc/colordiff-1.0.13 # maintainer-needed app-misc/nut-18.4 # anthoine.bourgeois sping app-misc/spacenavd-0.5-r4 # shell-tools app-misc/when-1.1.30 # openoffice app-officeext/dmaths-3.4.9.0 # pinkbyte app-shells/ccsh-0.0.4-r3 # robbat2 app-shells/localshell-1.3.4 # pinkbyte app-shells/rrs-1.70-r1 # qt app-text/cb2bib-1.4.9 # aballier fonts app-text/lcdf-typetools-2.97 # wschlich shell-tools app-text/multitail-5.2.10 # printing app-text/poppler-data-0.4.6 # vim app-vim/zencoding-vim-0.80 # matsuu dev-cpp/gtest-1.6.0-r1 # cjk dev-db/m17n-db-1.6.4 # pgsql-bugs dev-db/postgresql-docs-9.2.2 # embedded dev-embedded/bitbake-1.17.0 # haskell dev-haskell/arrows-0.4.4.1-r1 # haskell dev-haskell/binary-0.5.1.1 # haskell dev-haskell/curl-1.3.8 # haskell dev-haskell/digest-0.0.1.2 # haskell dev-haskell/happy-1.18.10 # haskell dev-haskell/hslogger-1.2.1 # haskell dev-haskell/http-4000.2.6 # haskell dev-haskell/json-0.7 # haskell dev-haskell/language-c-0.4.2 # haskell dev-haskell/missingh-1.2.0.0 # haskell dev-haskell/mmap-0.5.8 # haskell dev-haskell/mtl-2.1.2-r1 # haskell dev-haskell/parallel-3.2.0.3 # haskell dev-haskell/primitive-0.5.0.1 # haskell dev-haskell/split-0.2.1.1 # haskell dev-haskell/stm-2.4.2 # haskell dev-haskell/tar-0.4.0.1 # haskell dev-haskell/terminfo-0.3.2.5 # haskell dev-haskell/text-0.11.2.3 # haskell dev-haskell/zip-archive-0.1.2.1-r2 # haskell dev-haskell/zlib-0.5.4.0 # java dev-java/batik-1.7-r3 # java dev-java/osgi-core-api-5.0.0 # net-mail dev-libs/cyrus-imap-dev-2.4.17 # netmon dev-libs/geoip-1.4.8-r2 # pinkbyte voip dev-libs/jthread-1.3.1 # maintainer-needed dev-libs/libcli-1.9.4-r1 # netmon dev-libs/libdnsres-0.1a-r2 # crypto dev-libs/libksba-1.3.0 # andreis.vinogradovs maksbotan proxy-maint dev-libs/liblognorm-0.3.5 # cjk fonts dev-libs/libotf-0.9.13 # maintainer-needed dev-libs/libx86-1.1-r2 # ruepel proxy-maint dev-libs/mini-xml-2.7 # blueness bugs dev-libs/xapian-bindings-1.2.12-r1 # ml dev-ml/camlzip-1.05 # ml dev-ml/findlib-1.3.3-r1 # ml dev-ml/ocamlnet-3.6.1 # ml dev-ml/pomap-3.0.1 # ml dev-ml/postgresql-ocaml-2.0.2 # ml dev-ml/res-4.0.2 # perl dev-perl/Alien-wxWidgets-0.620.0 # perl dev-perl/Clone-0.340.0 # perl dev-perl/DateTime-TimeZone-1.560.0 # perl dev-perl/File-chdir-0.100.800 # perl dev-perl/HTTP-BrowserDetect-1.470.0 # perl dev-perl/MRO-Compat-0.120.0 # perl dev-perl/Mail-Box-2.107.0 # perl dev-perl/Module-Signature-0.700.0 # perl dev-perl/Net-IP-1.260.0 # perl dev-perl/Net-Pcap-0.170.0 # perl dev-perl/String-Format-1.170.0 # perl dev-perl/Text-CSV_XS-0.940.0 # perl dev-perl/XML-Twig-3.420.0 # perl dev-perl/locale-maketext-lexicon-0.920.0 # perl dev-perl/log-dispatch-2.340.0 # perl dev-perl/net-ssh-perl-1.350.0 # perl dev-perl/perltidy-20121207.0.0 # php-bugs dev-php/xdebug-2.2.1 # python dev-python/argparse-1.2.1-r2 # python dev-python/paramiko-1.9.0 # python dev-python/pyaudio-0.2.7 # hwoarang corentin.labbe proxy-maint dev-python/pybloomfiltermmap-0.3.11 # python dev-python/pypgsql-2.5.1-r1 # python dev-python/python-distutils-extra-2.37 # bazaar python dev-python/testtools-0.9.16 # python dev-python/webob-1.2.3 # python dev-python/webtest-1.4.3 # python dev-python/wtforms-1.0.2 # vapier tcltk dev-tcltk/expect-lite-4.3.3 # tcltk dev-tcltk/tclreadline-2.1.0-r2 # tex cjk dev-tex/cjk-latex-4.8.3 # radhermit dev-util/byacc-20121003 # blueness dev-util/comparator-2.9 # reavertm dev-util/ddd-3.3.12-r3 # bazaar dev-vcs/bzr-xmloutput-0.8.8-r1 # george dev-tools kde dev-vcs/kdesvn-1.6.0 # lxde lxde-base/menu-cache-0.4.1 # hattya net-mail mail-client/sylpheed-3.3.0 # net-mail mail-filter/policyd-weight-0.1.15.2 # spock media-gfx/fbida-2.09 # grozin media-gfx/fotoxx-12.12 # maintainer-needed media-gfx/photopc-3.07 # graphics perl media-libs/exiftool-9.40.0 #
[gentoo-dev] Chromium system ffmpeg
I'm trying to make Chromium be more compatible with more versions of ffmpeg: https://groups.google.com/a/chromium.org/d/topic/chromium-dev/fm5Oe_AC3Sc/discussion (although not stated there, that includes libav). Now the initial response there is not enthusiastic (which doesn't surprise me), but do you think there are some points useful for the discussion I'm not aware of? What are the main challenges of keeping up-to-date with latest ffmpeg API changes? How do other projects deal with that? If there is anything else you want to share/say about this, please do. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] removing the server profiles...
On 1/15/13 3:36 PM, Andreas K. Huettel wrote: several people have pointed out to me that the 10.0 - 13.0 transition would be a good moment to finally remove the (also in my opinion rather useless) server profiles. The easiest way to do this would be to * just not copy the server profiles from 10.0 to 13.0 and * have the deprecation warning for 10.0/server point to 13.0 (i.e. prompt users to upgrade from the 10.0 server profile to the 13.0 base profile). Sounds great! +1 If there are any concerns, why don't we adjust the 13.0 base profile or something? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Chromium system ffmpeg
On 1/15/13 4:55 AM, Alexis Ballier wrote: On Mon, 14 Jan 2013 20:34:42 -0800 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: I'm trying to make Chromium be more compatible with more versions of ffmpeg: https://groups.google.com/a/chromium.org/d/topic/chromium-dev/fm5Oe_AC3Sc/discussion (although not stated there, that includes libav). I've done quite a lot of work for various packages among the past years on that side, so if you have specific questions, feel free to ask. Alright: 1. What's the difference between libav and ffmpeg? Do the projects merge each other's changes? If not, in what direction do patches flow? 2. What are API compatibility policies for ffmpeg and libav? 3. Same as above for making releases (i.e. how frequent they are, how much they change, and how much released libav and ffmpeg are in sync with each other in practice). 4. What are typical incompatibilities (if possible), and usual ways to deal with them? 5. Do you think it's possible / worth trying to convince upstream ffmpeg / libav to have a more stable API over time? Which one could be possibly more willing to listen and why? Now the initial response there is not enthusiastic (which doesn't surprise me), but do you think there are some points useful for the discussion I'm not aware of? I don't get what is the problem: chromium uses an internal version corresponding to ffmpeg git master and doesn't build with older ones? Generally yes. It periodically pulls directly from git master (often ahead of any release) and that usually breaks build with older ffmpegs. What is the min. version it works with? Currently, for masked system-ffmpeg USE flag for chromium, it's ffmpeg-1.0. As a distro we have two options: 1) patch chromium to add #if's for older ffmpeg versions and be compatible: this may or may not be accepted by upstream, supporting older versions is just garbage code for them. I'm pretty sure upstream won't accept trench warfare #ifdefs (I'm also an upstream dev). I'm also not enthusiastic about having an out-of-tree Gentoo-side patch for a fast-moving project like that. The additional cost on each version bump is also something to take into account (fixing incompatibilities is one thing, but I'm also thinking about like merge conflicts on the patches). 2) (preferred) coordinate the other packages to be compatible with newer versions and unmask latest (we should be very close to be able to unmask ffmpeg-1) and make chromium require this version (this require chromium upstream to figure out what is the min. req. version) What when chromium upstream uses code more recent than latest ffmpeg release and it doesn't compile against latest release? Now what about libav? At one time I could compile against latest masked ffmpeg in tree but couldn't compile against latest masked libav (or any other version of it I think). Ideally I would like to make it compilable against both. Does that sound like much more difficult? we should probably do something in-between 1 and 2 in order not to hold off sec. stabilizations of chromium because dozens of stable packages do not build with latest ffmpeg. Yup. Just note there is just ~6 weeks before each stable release. That's not a very long time for most projects, and I think we won't get other packages into shape that quickly. What are the main challenges of keeping up-to-date with latest ffmpeg API changes? How do other projects deal with that? Specify a min. supported version, use #if for what remains. It may be easy or quite a lot of work, depending on what part of the API is used. ATM, being compatible with ffmpeg 0.10 up to git master isn't _that_ heavy on #if's (see eg: http://dev.gentoo.org/~aballier/distfiles/xbmc-11.0-ffmpeg-1.0-compat-1.tar.bz2 ) but may require a lot of changes. I will take a look at that patch later to see how possible changes look like. Usually, if you build with the latest ffmpeg release and don't see any deprecation warning, you are safe for ~1 year or more. Somehow I don't think that'll work. Chromium pulls from ffmpeg trunk frequently, so it's also a moving target. IMHO a compatibility layer like you suggest on your link will be a pain, #if's are easier to handle. I could make a leightweight compatibility layer, don't underestimate how nicely invented it can be. :) What if I say #define ffmpeg_function wrapper_ffmpeg_function for chromium code, and then have wrapper_ffmpeg_function do something smart depending on actual ffmpeg version? Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Chromium system ffmpeg
On 1/16/13 8:40 AM, Alec Warner wrote: Google generally prefers agility. Particularly when machines have gobs of memory (so bundling is not as big of a deal as it was previously) and they can staff security fixes for all their bundled libs. This is quite a pervasive attitude there. Coming from a distribution background it can be weird to see the different priorities (and terrible systems that build the packages that work on $DISTRO, ew.) Bundling is not a problem because of build time, memory usage of disk space concerns (they are to some degree, but that's _not_ the primary reason). The biggest problem are incompatible forks (which we have in chromium tree), which actually hinder agility. For example, system ICU is more recent than the bundled one. Same for several other bundled libraries. A lot of effort goes into maintaining the forks and cherry-picked patches - that effort could be spent on something else. People often speak about the cost of unforking/unbundling, but forking/bundling has its cost too. Because of Windows and Mac, some libraries have to be bundled, but there should be no reason to fork (at least not long-term). Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Chromium system ffmpeg
On 1/15/13 4:55 AM, Alexis Ballier wrote: On Mon, 14 Jan 2013 20:34:42 -0800 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: I'm trying to make Chromium be more compatible with more versions of ffmpeg: https://groups.google.com/a/chromium.org/d/topic/chromium-dev/fm5Oe_AC3Sc/discussion (although not stated there, that includes libav). I've done quite a lot of work for various packages among the past years on that side, so if you have specific questions, feel free to ask. Oh, one more thing: is there an easy way to check whether e.g. CODEC_ID_OPUS is defined? I just realized it's not a pre-processor symbol but an enum value so #ifdef wouldn't work. I could always check the version #defines, but it requires checking version control to see when it was introduced. It would be great to just have a way to more simply exclude code that requires CODEC_ID_OPUS. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Chromium system ffmpeg
On 1/20/13 1:46 AM, Luca Barbato wrote: On 19/01/13 20:10, Paweł Hajdan, Jr. wrote: have a way to more simply exclude code that requires CODEC_ID_OPUS. Exclude in chrome or in libavcodec? The latter is a matter of adding --disable-decoder=opus and/or not --enable-libopus in the configure. Exclude in chrome, in case old ffmpeg/libav does not support it. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] January stabilization candidates
On 1/12/13 11:49 PM, Paweł Hajdan, Jr. wrote: Please review attached automatically generated stabilization candidates for January. Oops, today I've tried my _separate_ script to file stabilization bugs based on a generated list of packages to support that workflow. Now the bug is that the list was the original one from January, and many entries from that list are now stale (the new contents were appended at the end). I hit ctrl-c once I realized the mistake, and I'm going to wait a while for the current batch of bugs to get handled. I can actually batch invalidate all of them. This will generate some further bug spam (I apologize), but can save your time dealing with the mess. Please let me know what's your preference. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC/PATCH] A cleaner API for virtualx.eclass
On 2/11/13 11:14 PM, Michał Górny wrote: My patches introduce a single wrapper with argv-as-parameter syntax. That is, the fore-mentioned example would look like: virtualx run_tests --foo Maybe we can just adapt Ubuntu's (I think) xvfb-run? More standardization == profit. Thank you for working on this! Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests
On 2/13/13 12:28 AM, Robin H. Johnson wrote: On Wed, Feb 13, 2013 at 12:12:35AM +0100, Michael Weber wrote: What is the rotation strategy for (near) outdated keys? Alter the key or create a new one? Sign the new with the old one? If your keysize is still good, you should ideally update the expiry on the key and re-upload it to keyservers. What is considered a good key size these days? Sorry I'm asking a question that has been blogged about thousands of times, but I trust a Gentoo dev more about this than a random blogger who insists everyone should use 8192 bit keys. ;) Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo Bugday
On 2/26/13 4:39 PM, Pavlos Ratis wrote: I would like to announce you a new try to 'revive' the Bugday event. This is excellent! Thank you for your work on this. I have listed some maintainer-wanted and maintainer-need bugs and Bugzilla admins also re-enabled the bugday flag. I would like to ask the Gentoo project teams to start using this flag to their bugs that think that are good to start and enable the flag at them. It would be great to a have a really big list with 'good to start' bugs. I'm going to look over chromium@ bugs, but consider also arch testing bugs (STABLEREQ) relevant - just avoid people making too much noise. 1-2 success reports are enough, and the more testing we can get before actually stabilizing, the better. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean
On 4/6/13 11:08 AM, Michał Górny wrote: 1. Patches have to be either in unified or context diff format. Unified diff is preferred. Are there any other formats than unified and context diff? If not, it'd be like another for indoor or outdoor use only or home or office use - i.e. no need to explicitly list all possible options. 5. The patch name shall shortly summarize the changes done by it. Common sense again. :) And I agree that patches should do that, the question is just whether we put common sense into the policy. 6. Patch files shall start with a brief description of what the patch does. Developers are encouraged to use git-style tags like 'Fixes:' to point to the relevant bug URIs. That could be helpful - could this be made more precise though? Is there any existing convention (going beyond git style, but specifically designed for distro or similar patches) we could follow? 7. Patch combining is discouraged. Developers shall prefer multiple patches following either the upstream commits or a logical commit sequence (if changes are not committed upstream). Common sense as well. (2) is likely to be a bikeshed point here. Long story short, epatch has this fragile patchlevel guessing, users don't have it. If we keep our patches consistent to a single patchlevel, we gain: * ability for users to apply the patches without having them try all patchlevels by hand. * clean error output if patch stops to apply for some reason. * no risk that patch will get applied to the wrong file if patch stops to apply at expected patchlevel and starts to apply on another. The above two points are convincing for me. However, I do acknowledge that it some cases the guessing behavior can be useful for some people (e.g. different layout of git repo vs. release tarballs). How about having a one guessing and one non-guessing variant of epatch, and encouraging the non-guessing one? Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean
On 4/6/13 12:41 PM, Michał Górny wrote: 6. Patch files shall start with a brief description of what the patch does. Developers are encouraged to use git-style tags like 'Fixes:' to point to the relevant bug URIs. That could be helpful - could this be made more precise though? Is there any existing convention (going beyond git style, but specifically designed for distro or similar patches) we could follow? I would honestly just go for the git style. It's the first thing that really succeeded in standardizing patches. Inventing something new is not really necessary, I believe. Oh, I didn't mean inventing anything new. Is there some URL or documentation I could read to familiarize myself with all of the git style? Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
On 4/9/13 10:15 PM, Mike Frysinger wrote: i plan on updating the latest glibc to add USE=suid. in pkg_preinst and ROOT==/, the ebuild will read /proc/mounts for a devpts line with gid=5. if it doesn't find one, i'll have it call `die`. if the bsd pty scenario wasn't long dead, and the devpts option didn't have gid=/mode= options, then it might be reasonable to have it warn and do `chmod +s`. but i can't think of any legitimate reasons for not using devpts mounting it correctly. this is the right answer even in the embedded world. +1 I have it disabled already on some of my systems using suidctl. I was going to suggest making that change some time ago - great to hear it's being done. Thanks for working on this! Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] GCC USE flag changes
On 4/30/13 8:25 PM, Ryan Hill wrote: I'm also going to rename the test flag to regression-test or something similar to get it out of FEATURES=test control. The testsuite is a huge time-suck and only useful to developers IMO (always expected to fail and primarily meant to be used to check for regressions between patchsets). I'm a big supporter of FEATURES=test by default and I think this is a small step towards that. +1 I'll make these changes at the same time as 4.7.3 is bumped to minimize rebuilding but of course stable versions will be affected as well. That's just waiting for me to go through the open bugs so probably end of weekish. Sounds good. I'd also like to drop graphite support for versions 4.4 and 4.5. We use a patch to dlopen graphite libs but older versions were written for ppl-0.10/0.11 (0.12 is the current version) so I doubt they still work properly (missing symbols and whatnot). Some archs still have 4.5 as the latest stable but graphite isn't a supported feature and the number of users on those archs is likely tiny. Yeah, +1 as well. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On 5/1/13 3:04 AM, Fabio Erculiani wrote: It is sad to say that the territoriality in base-system (and toolchain) is not allowing any kind of progress [3] [4]. This is nothing new, by the way. [4] useless crap: https://bugs.gentoo.org/show_bug.cgi?id=399615 As far as I read the bug, Mike (vapier) is doing the right thing. Distros doing lots of custom changes can only add more chaos to the picture. Have you reached out to relevant upstreams? If they refuse to make changes, that's a different story. So far I think it's reasonable to go to upstreams first. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/id3lib: metadata.xml ChangeLog id3lib-3.8.3-r9.ebuild
On 5/5/13 6:20 AM, Jeroen Roovers wrote: On Sat, 04 May 2013 19:49:03 +0200 viv...@gmail.com viv...@gmail.com wrote: (Also, why do a revision bump and leave the stable revision unfixed?) but this: because automake-1.13 is _not_ stable an because there are enough changes to risk to break it? The fix changes a single line in a source file in a predictable way. I trust maintainer's judgement. We have Gentoo developers who are strongly opposed to making _any_ changes to stable ebuilds. I'm in fact leaning towards that group. And we also have developers who see no reasons not to change stable ebuilds in trivial ways (the question remains what is trivial and what is not, and how trivial changes can still break things). The way I see to resolve this - which I think is accurate description of what's happening - is to let maintainers handle the fixes in the way they think is best (after all, they are most knowledgeable about the package in question). Anyone else is free to file a stabilization request and do his own testing - in fact, I also support stable not being too far behind ~arch. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Deptree broken - remove keyword on many packages, or downgrade profile to dev?
On 5/8/13 2:56 AM, Andreas K. Huettel wrote: the deptree of kde-base has been broken for over two months now (most likely more, it was already bad for a while when I filed bug 460532), and we cannot really commit new KDE releases without repoman --force option. A package is missing keyword ~amd64-fbsd, and so far noone from that team has responded to our repeated communication attempts. For the KDE team, I see two options: 1) remove amd64-fbsd keyword everywhere. This is within our rights to do, but hits users badly (if there are any). 2) downgrade the amd64-fbsd profiles from stable to dev in profiles/profiles.desc. This has the big advantage that the impact for users is minimal, but enables us to work normally again at the same time. Needless to say, it's not really a usual step to take for anyone outside the amd64-fbsd team. Out of frustration I am slowly tending to just commit option 2 and take the resulting flak. I support anything done to unbreak the tree. If possible, masking USE flags or packages on amd64-fbsd sounds better than switching the whole profile to dev, which is likely to introduce even more breakages. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] robo-stable bugs
On 5/19/13 6:40 AM, Jeroen Roovers wrote: Private messages and public comments through bugzilla are so far ignored, it seems, so let's try a venue where it's sure to cause a flamewar instead. My apologies for the inconvenience. Hey Jeroen, apologies if I have ignored any of your feedback. I'm indeed behind on bugmail (5000 unread emails, how about that?). I do read mailing list traffic and direct e-mail though. We agreed a little while ago that bug Summaries should start with an atom, if possible, and explain the action later. Could you refer me to the part where we agreed and why? I'm actually happy to make changes that are useful for people, but without a good rationale and an _actual_ consensus someone else will inevitably come and says he likes the old way better. URL: http://packages.gentoo.org/package/dev-libs/libconfig? arches=linux Is this URL useful to include, or did you just want to abuse every last feature found in pybugz? Wouldn't maintainers already know where to find this kind of information? Who do you think is your audience? My audience is a developer who doesn't have lots of time. It's not so much about not knowing at all where to look for it, but being able to do so really quickly. For me (maybe not so for other people - fine), it's much quicker to click a link than to copy-paste package name to either a URL or eshowkw or anything else, especially with more tricky package names like: app-emulation/open-vm-tools-2012.03.13.651368 (long version number) dev-perl/LWP-Protocol-https-6.30.0 (case variations) dev-php/PEAR-Crypt_RC4-1.0.3 (underscore vs dash variations) Please let me know if there is any _downside_ of having the URL, especially now that you know the upside. :) OS: Linux Status: CONFIRMED Severity: enhancement Is a stabilisation an enhancement per se? If all stabilisations are enhancements, then why isn't Severity set to Normal instead? (What is an enhanced severity to begin with, Mozilla?) What is your constructive alternative to this? Priority: Normal This is where you probably wanted to set something similar to Enhancement above, but again you probably shouldn't. Normal stabilisation bugs are normal, not less than normal. AFAIK this is the default setting. What is your constructive alternative? I'm actually serious - if you have specific changes in mind, I'd be happy to make them if I see the rationale. My e-mail editor is messing up the line endings here, but your messages already include double newlines - on bugzilla web pages as well as in the e-mail it sends, so this is your broken pybugz script again, I reckon? Fixed: http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=commitdiff;h=3d2d92a6537bec6be9c39ac113eb88f85faca315 Thank you for reporting this. Also, your script does not set the STABLEREQ keyword. People are having to hunt down your robo-stabilisation requests and add it themselves. You should just do it yourself or turn your script off. This is more tricky. If there is a consensus about STABLEREQ keyword, I'd be happy to add it. I vaguely remember some past controversies about it (or maybe it was actually same as what you're suggesting here). Remember this is supposed to _help_ Gentoo. You can opt out of the bugs (there is a package name and maintainer name regex in the script). You don't need to hunt them down - if you do nothing another script will just CC arches after 30 days. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] robo-stable bugs
On 5/20/13 5:10 AM, Gilles Dartiguelongue wrote: That would explain why you're still filling gnome stabilization bugs while we replied many times we don't want them in their current form ? If you're still getting bugs from my script it's a bug in my script, sorry about that. Could you post the most recent example of such a bug? The script applies exclusion list into account since http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=commitdiff;h=3c20e14c939bf0efa495dead6243f8035d699b86 (Feb 2013) and gnome is part of the exclusion list since http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=commitdiff;h=f63c885b61c46482781e22fb6f117f110eada79d (Aug 2012). This generally needs to go first so sorting by summary shows your packages in order and you have a chance to see this part of the summary in bugzilla (with version optionally), the rest of the summary line is imho less important when working through the web interface. This makes sense. I'll post an update when I make this simple change to the script. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] robo-stable bugs
On 5/21/13 6:38 AM, Thomas Sachau wrote: And if a maintainer is not responding within 30 days, you can ping him or, without a response, try to get a different maintainer. Just assuming that a stable request is ok without a maintainer response is really not a good idea. Thomas, this effort is going on for over a year now (and has been discussed on gentoo-dev). If it's only now you've noticed, maybe the sky isn't falling after all. Note the criteria for the bugs to be filed: 1. No open bugs for the package. 2. No bugs (including closed) for that particular version of the package (so for example closing the stabilization bug will prevent it from being opened again; it also takes into account bugs closed with e.g. NEEDINFO, which can be real issues). 3. At least 30 days in tree. 4. No repoman errors when trying to stabilize it (so all deps already stable). Also, arch teams are responsible for at least shallow (compile) testing of the package, and ideally smoke testing on run and possibly testing with various USE flag combinations and reverse dependencies testing (the latter is a regular part of my stabilization workflow, and the script for that is part of the same suite that files bugs). Note that there is a tradeoff here: I really started the stabilizations after I've noticed how many bugs are fixed in ~arch that still affect stable, but the fixing version didn't get stabilized. This is the downside of an opt-in approach, since inactive maintainers are not going to opt-in. Finally, everyone from metadata.xml is CC-ed. There is no trying a different maintainer - all of them are there since day one. Please let me know if you still have concerns - ideally back them with data and actual cases showing problems (or scenarios that can reasonably be likely) instead of just saying it _might_ lead to breakages. Anything _might_ lead to breakages, including taking no action here and allowing bugs to be not fixed for stable. :) Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] robo-stable bugs
On 5/21/13 1:17 PM, Alexis Ballier wrote: On Tue, 21 May 2013 20:51:52 +0100 Markos Chandras hwoar...@gentoo.org wrote: I'd rather not see this process changes, because it has helped bringing the stable tree up2date. However, given that *a few* people don't like it, I suggest you don't file bugs for packages owned by them. +1 I am (was) unhappy with some corner cases that used to happen (like bug #428968 ) but overall I consider it very useful; Thanks, Alexis. One note about that bug: with lots of bugs being filed, it's not really feasible for me to track comments like that one. If there was a bug on file about dev-ml/camlp5 breaking coq, my script wouldn't consider dev-ml/camlp5 for stabilization - I think this is the right thing for you to do in such cases, much better than implicit bugs that are not in the bug tracker. :) I'm even becoming more lazy and do not look for stable candidates because I know some day I'll have an automated request :P Note that there are several things my script will ignore: 1. Packages with any bugs open. 2. Packages which have at least one ~arch dependency. I still recommend doing some pass over packages you maintain to look for any stable candidates. Hopefully thanks to the script you should need to do that less often. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Usage of dev-utils/ninja in ebuilds
On 5/25/13 12:45 PM, Mike Gilbert wrote: You may see small (~60 seconds) difference when compiling Chromium due to faster target dependency resolution. You may also see faster builds in general because ninja is designed for very high degree of parallelization as compared to make. From a maintainer's perspective, shouldn't the user be able to choose whether ninja or make is used and not the developer? Or does ninja really work out for the majority in a way nobody would complain? Why would the user want to choose the build system? The choice of build system should be transparent to the user. However, I have no strong personal objection to making it configurable. The build system of choice actually is completely transparent to the user... From an upstream perspective, would it be problematic if people use make instead of ninja; or wouldn't it translate into problems upstream has to resolve? (To me, using ninja instead of make sounds like using llvm instead of gcc; correct me if I'm wrong, I'm fairly new to ninja.) So long as GYP supports emitting makefiles as well as ninja build files, I don't think this will be a problem. For Gentoo, I believe phajdan.jr simply chose to switch to ninja to more closely mimic the normal upstream build process. One part is indeed that the upstream default changed to ninja, but another one is that makefile support will be going away. The faster we can switch to ninja and fix any bugs resulting from that, the better. Let me repeat: Chromium project will be dropping support for generating makefiles, making ninja the only supported build system on Linux. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org
On 6/9/13 7:22 AM, Alex Legler wrote: I'd appreciate some input on below plan to move project pages to the Wiki: Alex, thanks for working on this! Some feedback: 1. How will the project pages be protected against unwanted edits? I think it's valuable to have some official pages where you know only Gentoo devs can edit them. 2. How will the staffing needs page be updated after dropping gorg? 3. How secure is the wiki? Do we have regular backups and security updates procedures in place? I know you're member of the security team and infra team is doing its job well, but I just wanted to check. Dynamic web applications arguably have bigger attack surface than effectively a bunch of static files only editable after you gain server access. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
On 6/12/13 11:51 PM, Dirkjan Ochtman wrote: Still seems like working in gentoo-x86 without doing stabilization would cover most of those bases. Working in the unstable main tree is still a lot better than keeping stuff out there in an overlay, IMO. +1 This works really well for the Gentoo Chromium team, where we have just hard masked packages and ~arch packages right in the tree. It helps with earlier detection of problems, especially with ~arch packages. I also know there are developers who are using the hard masked packages (thanks!) and I'd like to make that as easy as possible. Also, because no overlays are needed, we are all on the same page about other packages installed on the system. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
On 6/16/13 12:36 AM, Alexander V Vershilov wrote: In this is a continuation of a 'gentoo-haskell' sub-thread I have to say that Chromium and co. it not a development library this is a end user application. End user applications should be in tree (except for some testing reasons), if not just ignore this letter. And thanks for your work. Nice. :) Note however that v8 and ninja (the build system) are also maintained by the project in the tree. There is also libsrtp... Paweł signature.asc Description: OpenPGP digital signature
[gentoo-dev] repoman commit unexpectedly drops FEATURES=sign on error
Today an interesting thing happened to my repoman, as I was committing a change: Creating Manifest for /home/ph/gentoo-x86/dev-lang/v8 gpg: no default secret key: Unusable secret key gpg: /home/ph/gentoo-x86/dev-lang/v8/Manifest: clearsign failed: Unusable secret key !!! !!! gpg exited with '2' status !!! Disabled FEATURES='sign' /var/cvsroot/gentoo-x86/dev-lang/v8/Manifest,v -- Manifest new revision: 1.321; previous revision: 1.320 Indeed my private key on that machine was expired: pub 1024D/30427902 2009-08-05 [expired: 2013-06-10] But after refreshing it (I have extended the expiration date) it is fine: pub 1024D/30427902 2009-08-05 [expires: 2014-02-10] I was surprised by repoman just dropping FEATURES=sign . I'm aware that at that time it has to commit an updated Manifest to prevent breakages, so if gpg fails it proceeds, but is there something it could do to check gpg sanity before committing anything? Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] repoman commit unexpectedly drops FEATURES=sign on error
On 6/20/13 2:16 AM, Michał Górny wrote: Doing test signatures won't cover all failures. Do you know an example? The only one I'm aware of is when a test signature is made very close to the expiration date, and then the real signature would be done after it. IMHO the best thing to do would be to drop CVS keywords and let repoman do normal commits instead of this two-step thing. But some of the devs really prefer to keep them, at least until we migrate to git and have better ways of e.g. checking the file version. Right, I found that it's used at least for prefix. I'm fine with waiting until git migration - looks like that would solve it naturally. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] dev-cpp/gtest
On 6/30/13 3:03 PM, Thomas Kahle wrote: dev-cpp/gtest is Google's testing framework. According to upstream it is supposed to be shipped as source code and then compiled by the build system of the software that should be tested. In particular it should be compiled with exactly the same flags. That's correct, and I consider that design broken. They could have easily provided an executable like gtest-config or even just use pkg-config to provide proper flags to compile the dependent sources. So far our gtest package has shipped only the compiled library and a bunch of helper scripts. Now bug 474454 asks for the sources to be installed too (or exclusively). What should we do? IMHO a package that installs sources makes no sense. Anything that would use it would be highly non-standard - this was not indended to be shared. I'd rather schedule dropping the package and make reverse dependencies use bundled gtest (upstream intends this to be used as a copylib). In the long term it could be worth it to convince upstream to do something more sane and standard. It is technically possible. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] revbumping ebuilds after USE dependency changes
On 7/24/13 8:31 AM, Alex Alexander wrote: On Wed, Jul 24, 2013 at 10:15:51AM -0400, Mike Gilbert wrote: Actually, Portage normally handles this situation gracefully by using the dependencies from the portage tree instead of vdb. However, in the case of a slot-operator dep, it always uses vdb. See bug 477544. https://bugs.gentoo.org/show_bug.cgi?id=477544 Aha, thanks for the bug, missed it. Well, my recommendation is still valid until portage gets fixed. Glad to know someone's looking into it though. Can we get that recommendation to the devmanual possibly? I'm still a little bit confused what exactly would warrant such a revision bump, and why. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes
On 7/24/13 5:53 PM, Rick Zero_Chaos Farina wrote: On 07/24/2013 03:18 PM, Ciaran McCreesh wrote: On Wed, 24 Jul 2013 21:17:26 +0200 Michał Górny mgo...@gentoo.org wrote: Other thing is that Portage explicitly ignores PMS in this matter and uses dependencies from ebuilds rather than recorded ones. This is supposedly wrong, supposedly slow but allows us to be lazy. It's not slow. It's just wrong, and intermittently leads to very strange behaviour. ++ Shall we revisit that, and try to make portage behave more correctly, even if it means more revbumps / rebuilding? Paweł signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: toolchain-r1.eclass
About one month ago I've filed
https://bugs.gentoo.org/show_bug.cgi?id=474358 about modernizing
toolchain.eclass by creating new toolchain-r1.eclass and migrating
ebuilds using it to the new eclass.
Please see attachments and review the code.
One issue has already been raised, and it's prefix-related changes. I
don't know what to change there, but I'm happy to test suggested changes.
Then there is a question whether toolchain packages should use EAPI 5,
and I think providing an upgrade path is a good concern. Given
portage/python constraints though, it seems to me it would be fine. If
you think it'd be better, I could use a lower EAPI just in case.
All feedback is welcome.
Paweł
--- gcc-4.7.3.ebuild.orig 2013-06-16 17:43:10.0 -0700
+++ gcc-4.7.3.ebuild2013-06-16 17:43:09.0 -0700
@@ -2,6 +2,8 @@
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/sys-devel/gcc/gcc-4.7.3.ebuild,v 1.2
2013/05/20 10:56:06 aballier Exp $
+EAPI=5
+
PATCH_VER=1.0
UCLIBC_VER=1.0
@@ -18,7 +20,7 @@
SSP_UCLIBC_STABLE=x86 amd64 ppc ppc64 arm
#end Hardened stuff
-inherit toolchain
+inherit toolchain-r1
DESCRIPTION=The GNU Compiler Collection
@@ -35,7 +37,7 @@
PDEPEND=${PDEPEND} elibc_glibc? ( =sys-libs/glibc-2.8 )
fi
-src_unpack() {
+src_prepare() {
if has_version 'sys-libs/glibc-2.12' ; then
ewarn Your host glibc is too old; disabling automatic fortify.
ewarn Please rebuild gcc after upgrading to =glibc-2.12
#362315
@@ -47,15 +49,15 @@
EPATCH_EXCLUDE+= 90_all_gcc-4.7-x32.patch
fi
- toolchain_src_unpack
+ toolchain-r1_src_prepare
use vanilla return 0
[[ ${CHOST} == ${CTARGET} ]] epatch ${FILESDIR}/gcc-spec-env.patch
}
-pkg_setup() {
- toolchain_pkg_setup
+pkg_pretend() {
+ toolchain-r1_pkg_pretend
if use lto ; then
ewarn
--- toolchain.eclass2013-06-16 17:42:59.0 -0700
+++ toolchain-r1.eclass 2013-06-16 17:43:26.0 -0700
@@ -23,7 +23,7 @@
inherit git-2
fi
-EXPORT_FUNCTIONS pkg_setup src_unpack src_compile src_test src_install
pkg_postinst pkg_postrm
+EXPORT_FUNCTIONS pkg_pretend pkg_setup src_unpack src_prepare src_configure
src_compile src_test src_install pkg_postinst pkg_postrm
DESCRIPTION=The GNU Compiler Collection
FEATURES=${FEATURES/multilib-strict/}
@@ -108,14 +108,15 @@
if tc_version_is_at_least 3 ; then
IUSE+= doc gcj gtk hardened multilib objc
+ REQUIRED_USE+= gcj? ( cxx )
tc_version_is_at_least 4.0 IUSE+= objc-gc mudflap
- tc_version_is_at_least 4.1 IUSE+= libssp objc++
+ tc_version_is_at_least 4.1 IUSE+= libssp objc++
REQUIRED_USE+= objc++? ( cxx )
tc_version_is_at_least 4.2 IUSE+= openmp
tc_version_is_at_least 4.3 IUSE+= fixed-point
tc_version_is_at_least 4.6 IUSE+= graphite
tc_version_is_at_least 4.6 IUSE+= lto
- tc_version_is_at_least 4.7 IUSE+= go
+ tc_version_is_at_least 4.7 IUSE+= go REQUIRED_USE+=
go? ( cxx )
fi
fi
@@ -559,7 +560,7 @@
# specs + env.d logic
# pkg_*
-toolchain_pkg_setup() {
+toolchain-r1_pkg_pretend() {
if [[ -n ${PRERELEASE}${SNAPSHOT} || ${PV} == ** ]]
[[ -z ${I_PROMISE_TO_SUPPLY_PATCHES_WITH_BUGS} ]]
then
@@ -567,21 +568,19 @@
This is to try and cut down on people filing bugs for
a compiler we do not currently support.
fi
+ [[ -z ${UCLIBC_VER} ]] [[ ${CTARGET} == *-uclibc* ]] die Sorry,
this version does not support uClibc
+}
+
+toolchain-r1_pkg_setup() {
# we dont want to use the installed compiler's specs to build gcc!
unset GCC_SPECS
- if ! use_if_iuse cxx ; then
- use_if_iuse go ewarn 'Go requires a C++ compiler, disabled
due to USE=-cxx'
- use_if_iuse objc++ ewarn 'Obj-C++ requires a C++ compiler,
disabled due to USE=-cxx'
- use_if_iuse gcj ewarn 'GCJ requires a C++ compiler, disabled
due to USE=-cxx'
- fi
-
want_minispecs
unset LANGUAGES #265283
}
-toolchain_pkg_postinst() {
+toolchain-r1_pkg_postinst() {
do_gcc_config
if ! is_crosscompile ; then
@@ -617,7 +616,7 @@
fi
}
-toolchain_pkg_postrm() {
+toolchain-r1_pkg_postrm() {
# to make our lives easier (and saner), we do the fix_libtool stuff
here.
# rather than checking SLOT's and trying in upgrade paths, we just see
if
# the common libstdc++.la exists in the ${LIBPATH} of the gcc that we
are
@@ -694,17 +693,16 @@
die Failed to fixup file ${jfile} for rename to grmic
done
}
-toolchain_src_unpack() {
- [[ -z ${UCLIBC_VER} ]] [[ ${CTARGET} == *-uclibc* ]] die Sorry,
this
[gentoo-dev] unmasking USE=system-ffmpeg for stable www-client/chromium ebuilds
Currently USE=system-ffmpeg is masked for stable www-client/chromium ebuilds. However, recently a new enough media-libs/ffmpeg has been stabilized, making it possible to use system ffmpeg in stable. I'd like to make the change close to a new version of chromium being stabilized so that less rebuilds would be triggered. Here is how the dependency looks like: system-ffmpeg? ( || ( =media-video/ffmpeg-1.0:=[opus] =media-video/libav-9.5:=[opus] ) ) I know there are some controversies around ffmpeg/libav, and I wouldn't like to go into that. I prefer to ask first and have a discussion before rather than surprising people badly. Please let me know what you think about this idea (unmasking USE=system-ffmpeg for stable chromium ebuilds). Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] unmasking USE=system-ffmpeg for stable www-client/chromium ebuilds
On 7/26/13 9:50 AM, Diego Elio Pettenò wrote: Does this still allow me to use libav? If not I'd like to veto it. You can still use libav - either unmask it or USE=-system-ffmpeg. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Autobuilds go to /experimental and to /releases only when someone actually tests them
On 7/26/13 9:13 PM, Rick Zero_Chaos Farina wrote: On 07/27/2013 12:08 AM, Matt Turner wrote: Can we make autobuilds go to /experimental and then only move them to /releases when someone actually tests them? Very interesting. :) I had a similar idea. I think it's great. Looking at bugzilla and listening in #gentoo-releng, it's kind of embarrassing how often someone downloads a Live CD only to find out that networking is totally broken by a udev upgrade, or something to that effect. Yes - and it's very important to make that first experience with the distro as good as possible. The bugs are usually not fixed quickly enough anyway. I'd like to add a suggestion - document the processes better and allow more people to contribute. We don't commit version bumps straight to stable; I don't see why we do with release media. It's been an odd week for me agreeing with people but yeah, I completely agree. I think we *need* to keep the autobuilds going as often as possible to detect obvious breakage, but there is no reason they shouldn't be marked experimental. +1 The real question is, how realistic can we make a process of testing and moving to stable? We have arch teams, we have users... when several users say it's OK I think it is OK. As compared to a script pushing it to the website just because it compiled. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] robo-stable bugs
On 5/20/13 9:58 AM, Paweł Hajdan, Jr. wrote: On 5/20/13 5:10 AM, Gilles Dartiguelongue wrote: This generally needs to go first so sorting by summary shows your packages in order and you have a chance to see this part of the summary in bugzilla (with version optionally), the rest of the summary line is imho less important when working through the web interface. This makes sense. I'll post an update when I make this simple change to the script. As promised I'm announcing I made this change: http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=commitdiff;h=a92c88330af1aec3aa9ee58dc497f047129ccd2e The original thread got somewhat long, so if I've missed any other feedback on which there is a consensus, please let me know. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge
On 8/12/13 10:21 PM, heroxbd wrote: As a natual consequence of the on-going Google Summer of Code project, Gentoo on Android[3], we can run native Gentoo on *all* the Android devices. Compiling out an Xorg and output to HDMI has no theoretical difficulty. Furthermore, sharing of graphic output with Android (instead of a separate HDMI output) can be explored with wayland x11[4]. Sounds good. Note that it doesn't need to be set up as against Canonical. Just do the best thing for the users. I would like to kick out a sub-project of Gentoo targeting smartphone and tablets. It would be nice to find out a solution based on Gentoo for desktop/smartphone hybrid *before* Canonical's release. Everybody can create a sub-project, and I'm happy to see this kind of project appearing in Gentoo. I'd recommend focusing on creating a good, compelling experience, not just pushing out something before Canonical. :) Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changes in libreoffice ebuild
On 8/13/13 8:39 AM, Alexis Ballier wrote: Your arguments make sense but you should also consider it the other way: When you are maintaining a package properly by forwarding patches upstream, having $randomdev jumping in, adding a patch, and letting you clean up the mess is kind of annoying. Part of Tomas' original email was: I've googled it for you, now would you please submit that patch upstream and be forgiven? I agree with staying very close to upstream and submitting patches to them. This is especially important for big packages like libreoffice or say chromium (I help to maintain the latter). Note that there is a possible confusion what ~arch is about. Are breakages allowed there? How long before they get fixed? For example, one could arguably say neon-0.30.0 was added to the tree without testing reverse dependencies. Interestingly, it was submitted by Arfrever (just stating the fact). To his defense, he submitted the libreoffice patch to bugzilla on the same day. Still, one could ask: why wasn't neon-0.30.0 masked instead? One thing I think is really important is respecting the maintainers. If maintainer said please send the patch upstream before committing to cvs, it is _not_ OK to just ignore that. There are other options available like masking neon. And finally to the defense of libreoffice maintainers: packages take long time to compile, people have life. The policy about staying close to upstream is a very good one, and I can totally understand and agree with what they're saying. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox
On 8/20/13 3:26 AM, Michał Górny wrote: I've added a few new fancy features for Gentoo developers to portage git. Sadly, since Zac isn't planning another release until 2.2.0 goes stable, you need to switch to - to use them. But I say to you, it's worth the hassle. I'd really appreciate some testing and feedback. Thanks. The new features sound great! I was thinking for some time it'd be good to have them. Thank you for adding them. This is really appreciated. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: stabilization policies
On 8/20/13 11:19 AM, William Hubbs wrote: During the last release of OpenRC, I learned that people *do* run production servers on ~arch. I asked about it and was told that the reason for this is bitrot in the stable tree. People frequently point to lack of manpower as reason for this, but I don't think it's true. First, the rate arch teams (at least mainstream, amd64/x86) deal with stabilization queues has improved. I'm not aware of any severe backlogs in terms of stabilization bugs filed but not handled (on amd64/x86). Second: people maintain list of packages to unmask, or maintain ~arch servers... I hope they have some kind of testing/staging environment before unleashing ~arch on production servers. Well, this is exactly what stable can be - this effort could easily be shared with the rest of the community by these people stabilizing things. I'm in favor of policy changes if needed to make this happen. Furthermore, it'd be great to have people who actually run servers help with stabilizations. Arch teams could be doing their best, but they probably don't run postgres/apache/ruby/whatever in production, and so it's pretty much if it compiles and reverse dependencies don't explode it's perfect. People running servers in production can actually test these pretty thoroughly in staging environment and either vet them with higher confidence or file good blocking bugs. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [EAPI 6] src_fetch() for fetching live sources
On 8/27/13 3:01 AM, Michał Górny wrote: b) assume that early src_fetch() is allowed to fail and retry before build. This is much like what portage does anyway. If VCS is not installed yet during parallel fetch or --fetchonly, the particular fetch fails like it can fail due to 404. When the actual build process starts, emerge calls src_fetch() again much like it currently retries fetching missing SRC_URI items. This would be simpler. We could probably cache the src_fetch() result (if possible) to avoid double-fetching. Or just accept the minimal overhead of plain update check. I think b) is better. Having a USE flag with a special meaning sounds bad; adding FDEPEND could be reasonable, but then --fetchonly behavior may become counter-intuitive. It seems to me b) is the most reasonable option, and also has the advantage of being simpler as you've said. 2. Should src_unpack() be disallowed from fetching VCS sources? If we introduce src_fetch() in EAPI 6, then we should probably expect all the live eclasses to use that rather than src_unpack() for fetching. If we agree on this, we can extend portage's network-sandbox to this phase, and likely filesystem sandbox as well. I'm fine with this and think it's a good idea, but it's kind of secondary - things will still work whether or not we do that. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] SDL2 update
Just small, very small comments. To avoid being accused of bikeshedding,
I'm totally fine if you don't apply any of them. It's entirely up to you. :)
https://bugs.gentoo.org/show_bug.cgi?id=480826 :
if use directfb ; then
# since DirectFB can link against SDL and trigger a
# dependency loop, only link against DirectFB if it
# isn't broken #61592
echo 'int main(){}' directfb-test.c
$(tc-getCC) directfb-test.c -ldirectfb 2/dev/null \
directfbconf=--enable-video-directfb \
|| ewarn Disabling DirectFB since libdirectfb.so is
broken
fi
Suggestion: print what to do in the ewarn (or just reference the bug
number in he ewarn so the user doesn't have to read the ebuild).
# --disable-threads broken
If there is some reference why/how it is broken, it'd be great to
reference it there (to avoid kind of cargo cult programming it's here
because it always was here, and it is probably still broken but nobody
remembers how).
https://bugs.gentoo.org/show_bug.cgi?id=481796 :
RDEPEND=${DEPEND}
S=${WORKDIR}/SDL2_mixer-${PV}
Why no quotes? ()
https://bugs.gentoo.org/show_bug.cgi?id=481794 :
S=${WORKDIR}/${MY_P}
Why no quotes? ()
src_configure() {
econf \
--disable-gui \
$(use_enable static-libs static)
}
Would it make sense to add USE flag to --enable-gui?
https://bugs.gentoo.org/show_bug.cgi?id=481788 :
S=${WORKDIR}/SDL2_ttf-${PV}
I suggest quotes ().
src_install() {
emake DESTDIR=${D} install || die
dodoc {CHANGES,README}.txt
use static-libs || prune_libtool_files --all
}
In EAPI-5 die after emake is not needed.
Again, these things are _tiny_ details, and it's entirely up to you what
to do with it. I hope it'll be at least somewhat useful. And of course
everything else looks good. :)
Thank you for working on sdl2 bumps!
Paweł
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] include files question
On 9/20/13 9:27 AM, Michał Górny wrote: Putting another includedir is even worse kind of band-aid. If we're to put them in a directory, I'd rather require 'more complete' includes, like: #include openrc/rc.h Otherwise, you're just fighting conflicts in the scope of a single application. Exactly, with /usr/include/openrc added I think #includes should look like above. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] include files question
On 9/15/13 10:01 AM, William Hubbs wrote: All, here is another question wrt OpenRC's api. Currently we store two header files (rc.h and einfo.h) in /usr/include. Since we have more than one include file, wouldn't it be standard practice to store them in a sub directory of /usr/include? I'm leaning towards having a directory for them like /usr/include/openrc, but I'm also fine with having them in /usr/include . It's not so much about standard practice, but even say avoiding file collisions and weird issues with wrong headers being included (especially rc.h seems to be a fairly generic name). Also, it may be easier to change now when we only have two headers, than later. And you may even add compatibility symlinks or copies in /usr/include to give people more time to update. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: FEATURES=binchecks strip for plain file packages e.g. latex, perl, python
On 9/20/13 12:24 PM, Diego Elio Pettenò wrote: As Michał said. Please consider updating the documentation - ebuild(5): RESTRICT = [strip,mirror,fetch,userpriv] This should be a space delimited list of portage features to restrict. You may use conditional syntax to vary restrictions as seen above in DEPEND. binchecks Disable all QA checks for binaries. This should ONLY be used in packages for which binary checks make no sense (linux-headers and kernel-sources, for example, can safely be skipped since they have no binaries). If the binary checks need to be skipped for other reasons (such as proprietary binaries), see the QA CONTROL VARIABLES section for more specific exemptions. This is currently used at least by sys-apps/man-pages, as well as packages in x11-themes and sys-kernel. I'm fine either way, let's just make sure our mailing list advice matches documentation and established practice. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News item: GRUB2 migration
On 9/21/13 8:42 AM, Mike Gilbert wrote: GRUB2 will be stabilized soon (bug 455544). Here's a draft of a news item to hopefully prevent any confusion. Please review. Great news! Thanks for working on this, and it basically works (chainloaded for now, see below) on my x86 system. Some general remarks: 1. When using chainloaded GRUB2, neither Linux kernel boot messages nor openrc boot messages would show up. Also, at shutdown openrc shutdown messages were also not visible. Everything is fine if I boot the kernel using GRUB legacy. This is inside VMWare Fusion. 2. At least /etc/default/grub refers to /boot/grub2, as opposed to /boot/grub from Gentoo docs. GRUB2 uses a different configuration format, and requires a manual migration before your system will actually use it. A guide [1] is available on the gentoo.org website. [...] [1] http://www.gentoo.org/doc/en/grub2-migration.xml The grub postinst message links to http://wiki.gentoo.org/wiki/GRUB2_Quick_Start instead - and that wiki page has a link to http://www.gentoo.org/doc/en/grub2-migration.xml . IMHO it would be elegant for the news item to match the postinst message: either make the grub2-migration.xml point to wiki as possibly containing more information (and switch grub postint to point to grub2-migration.xml), or make both link to the wiki. Paweł signature.asc Description: OpenPGP digital signature
[gentoo-dev] does v8 shared library make sense with current upstream approach?
I'd like to get your feedback and opinion about removing shared v8 library package from Gentoo. It's currently used by www-client/chromium, dev-db/drizzle, dev-db/mongodb, dev-lang/v8cgi and sci-geosciences/osgearth. net-libs/nodejs switched back to bundled v8 a long time ago: 25 Feb 2013; Patrick Lauer +nodejs-0.6.21-r2.ebuild, +nodejs-0.8.20.ebuild: Version bump for 0.6 and 0.8 that also disables shared v8 as our v8 maintainers remove all compatible versions Some bugs for reference: https://bugs.gentoo.org/show_bug.cgi?id=417879 https://bugs.gentoo.org/show_bug.cgi?id=420995 https://bugs.gentoo.org/show_bug.cgi?id=471582 https://bugs.gentoo.org/show_bug.cgi?id=477300 https://bugs.gentoo.org/show_bug.cgi?id=484786 From mongodb upstream https://jira.mongodb.org/browse/SERVER-10282 : compiling with versions of v8 other than what is included is not currently supported. I'd like maintainers of all packages depending on dev-lang/v8 to make their packages use bundled v8 copy instead (I can file bugs for that, let's discuss here whether it should be done). For now V8 upstream gives no guarantees about API/ABI stability and actually breaks it very often (http://upstream-tracker.org/versions/v8.html). Having a shared library so closely tied to packages (which results in frustrating blockers, since v8 is updated often and chromium is synchronized with that) is not really much different from everyone bundling the library. I'd like that to improve, but for now it's time for a pragmatic solution to this IMHO. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News item: GRUB2 migration
On 9/21/13 1:19 PM, Mike Gilbert wrote: I wasn't able to reproduce this in qemu. It is possible that GRUB's graphical terminal driver has some issues with VMWare. However, have a Gentoo box at work that runs GRUB2 on VMWare ESX, and I don't recall having any display issues on the console. But I'm also not chainloading it there. Thanks for testing this. I've tried without chainloading and it was also broken. However, I got it to work later, and there are at least two solutions: 1. In /etc/default/grub, uncomment GRUB_TERMINAL=console line and re-run grub2-mkconfig. 2. In /etc/default/grub, add GRUB_GFXPAYLOAD_LINUX=text line and re-run grub2-mkconfig. Actually Arch wiki article mentions something very similar: https://wiki.archlinux.org/index.php/GRUB2#Disable_framebuffer Also, it seems worth it to add to the guide info about how to roll back just in case. Running grub-install /dev/sda works just fine (it invokes grub legacy as opposed to grub2). Then, looking at Arch wiki article, it's probably a good idea to make backup: https://wiki.archlinux.org/index.php/GRUB2#Backup_important_data . I recommend adding this to our guide. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] does v8 shared library make sense with current upstream approach?
On 9/22/13 5:24 PM, Peter Stuge wrote: Paweł Hajdan, Jr. wrote: compiling with versions of v8 other than what is included is not currently supported. .. For now V8 upstream gives no guarantees about API/ABI stability and actually breaks it very often I agree that it isn't worth the effort to try to offer V8 as a library then. Perfect. As soon as upstream stabilizes one API/ABI I think it would be wise to make a package providing that as a library. Yes, and I'll be trying to move upstream in that direction. Not everybody understands it but actually it isn't a library if there isn't a stable API/ABI. Thanks for mentioning that. Totally agreed. At least applicable to a shared library. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] does v8 shared library make sense with current upstream approach?
On 9/25/13 2:44 AM, Diego Elio Pettenò wrote: On Tue, Sep 24, 2013 at 7:46 PM, Paweł Hajdan, Jr. phajdan...@gentoo.orgwrote: Perfect. Seriously? Perfect because one person agrees with you? Sigh. Look at the API breaks and talk to v8 upstream - if you have a better solution to actual bugs that people report against Gentoo, I'm all for it. Note that I've spent and keep spending time on unbundling what's possible from chromium. I'm not saying bundled is good or fine, but in the current situation of v8 I honestly think trying to ship a shared library offers us *no* advantages and actually creates problems, mainly because v8 was not designed to be used as a shared library and breaks API/ABI even before patch version bumps like a.b.c.x - a.b.c.y. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] does v8 shared library make sense with current upstream approach?
On 9/25/13 1:16 AM, Peter Volkov wrote: But could you comment on how hard it'll be to slot v8 shared library? Keeping libraries bundled is a security nightmare. Slotting v8 would be hugely impractical and rather a misuse of SLOTs. Slotting makes sense when there are at most 2-3 major versions, each with its own release series, that are incompatible, but packages can depend on one or another series. Thing gtk2 vs. gtk3 for example, or maybe some Java libraries. With v8 API and ABI breaks can (and we've seen that) be introduced even between patch version increments like a.b.c.x vs. a.b.c.y. Trying to slot that would be totally equivalent to bundling at the cost of increased complexity (more custom changes compared to upstream - also headers would need to be handled somehow, currently we don't have a good way for that, especially one that would be consistent across distros). Finally, note that v8 upstream only supports the latest stable v8. Slotting would require us to keep old, _known_ to be vulnerable versions of v8 in the tree. Backporting of patches isn't always possible/feasible, and even then for complex and fast moving software it's not guaranteed to fix all the issues (some security bugs might have been fixed in more recent versions without realizing security implications). At least with bundling upstream _may_ track v8 security vulnerabilities and do something with their copy. With slotting we'd have _known_ vulnerable v8 versions right there in the tree. That'd be a security nightmare. Please let me know if you have more questions. At this moment I'm confident slotting does not address the problem. More deeper, upstream changes should be made, and I'll be working on that but it's going to take time. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] does v8 shared library make sense with current upstream approach?
On 9/25/13 9:01 AM, Ian Stakenvicius wrote: However, if it's possible to keep the rest of the tree using one system package of v8 (or very small subset), and just maintain that(those) via security backports, would that be viable? In the current state of v8, no. Latest security-supported v8 is defined as one used by stable chromium. Security backports are not supported by upstream, and are not always even possible with a fast-changing codebase. A good test for this type of questions is look at some of the bugs below: https://bugs.gentoo.org/show_bug.cgi?id=417879 https://bugs.gentoo.org/show_bug.cgi?id=420995 https://bugs.gentoo.org/show_bug.cgi?id=471582 https://bugs.gentoo.org/show_bug.cgi?id=477300 https://bugs.gentoo.org/show_bug.cgi?id=484786 and try to post fixes for them. If you or anyone else can do that, I'm happy to take them and change my opinion (note that I'd apply some quality standards to the patches, not just look whether they happen to work for now). I actually really hope to improve this in the long term (as said before), and we can definitely revisit this in the future. For now I'd like to address real problems that affect users. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] proxy maintainership and gentoo-x86 scm
On 1/14/10 1:49 PM, Nirbheek Chauhan wrote: Besides this, there is the problem of accommodating people who use a subtree of gentoo-x86, and those who don't want the entire CVS history on their hard drives. In summation, robbat2 needs *our* help in the following: a) Push functionality in shallow clones (patches exist upstream) b) Partial-tree checkouts (patches exist upstream) c) Optimize git so it can handle 30,000 files - Maybe maintain a cache of directory timestamps and only stat() directories? - Implement recursive timestamps on directories in various filesystems and then in git (via xattrs perhaps)? People want to do this for things like Tracker too. Prelim patches might exist. d) Implement scripts/infra for people to fetch repository (shallow and deep) bundles to initialize their local git clones (similar to portage snapshots) - git clone from scratch taxes the server too much, just like rsync from scratch e) Server-side scripts for pushing to CIA.vc for pretty stats like we do in CVS - We want this for overlays right now too. f) (Optional) Fix http cloning in git to make it smarter to help people behind firewalls get anonymous clones (patches exist upstream) Did I miss something Robin? It would be nice to post that info to a webpage. That could increase a chance of a volunteer contributing some help. Note in advance: I don't know git internals, so can't help at this moment. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] LibGL.la removal news item for =eselect-opengl-1.1.1-r2 going stable
On 1/17/10 6:57 PM, Vaeth wrote: On Sun, 17 Jan 2010, Paweł Hajdan, Jr. wrote: I wonder why the affected package (eselect-opengl) couldn't run lafilefixer itself. It's mandatory for all users, and would save a lot of frustration. It is not mandatory: You could as well re-emerge the affected packages (shown by revdep-rebuild) which is a much cleaner solution, since it does not break the portage database like lafilefixer does. I see. To be more precise, I meant something must be done to have a not-broken system. Please: When you run tools which break checksums/dates of the database, give the user the possibility to decide whether he really wants this. Good point, I didn't realize that. However, I'd rather fix the tool (for example to update the portage database). Paweł Hajdan jr signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] LibGL.la removal news item for =eselect-opengl-1.1.1-r2 going stable
On 1/17/10 7:28 PM, Krzysiek Pawlik wrote: On 01/17/10 18:20, Paweł Hajdan, Jr. wrote: Please: When you run tools which break checksums/dates of the database, give the user the possibility to decide whether he really wants this. Good point, I didn't realize that. However, I'd rather fix the tool (for example to update the portage database). Nope, that's a bad idea unless you plan to implement such feature for portage, paludis and pkgcore (and possibly other package managers). So use revdep-rebuild (longer but correct solution) or lafilefixer (quicker but introduces other problems). Hmm... last time I tried revdep-rebuild for that problem it either didn't notice something was wrong, or couldn't finish without manual assistance. How about fixing lafilefixer in an other way: it knows which .la files are broken. Instead of changing their contents, it can re-emerge the packages they belong to. But then it probably can't be run automatically by the ebuild (nested emerges). On the other hand, I really wonder how useful the checksums in portage db really are. It includes config files which are frequently modified. It also doesn't include config files the administrator has to create. So for example for verifying system integrity is seems useless to me. I'd expect only a limited group of users caring about the checksum database, and the majority of affected users caring about the update to just work (which running lafilefixer --just-fixit automatically would buy us). Paweł Hajdan jr signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] built_with_use removal
On 1/24/10 5:51 PM, Petteri Räty wrote: There should be no legitimate reason for the number to go up so please whenever bumping ebuilds, remove the usage of built_with_use. How about adding a repoman check for that? Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] The importance of test suites
On 2/21/10 5:08 AM, Ryan Hill wrote: I have one simple request. When you make a non-trivial change to an ebuild - a patch, a version bump, anything that can effect the behaviour of the package - please run the test suite. Yeah, on my dev box I just run with FEATURES=test all the time. Then it's impossible to forget it. And I also catch failures in other packages. Maybe it should get more exposure in the developer docs? If it fails, fix it. Or restrict it. Or even make it non-fatal if there's no other choice. It's really frustrating when there is a bug reported about package failing tests and everybody can reproduce it, yet the maintainer doesn't at least put RESTRICT=test in the ebuild. Is it acceptable for another dev to jump in and add RESTRICT=test to an ebuild if the maintainer does not respond to a bug report in a timely manner? The concern here may be that it's papering over the real problem, but the good side is that it'd make running with FEATURES=test much easier. By the way, for packages that fail the test suite and refuse to disable it, I change the env locally so that FEATURES=-test (via /etc/portage/env). Paweł Hajdan jr signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] The importance of test suites
On 2/21/10 10:40 AM, Thilo Bangert wrote: Paweł Hajdan, Jr. phajdan...@gentoo.org said: The concern here may be that it's papering over the real problem, but the good side is that it'd make running with FEATURES=test much easier. which is a good thing, since more tests will be run. RESTRICT=test should always generate a repoman QA warning IMHO. +1 By the way, for packages that fail the test suite and refuse to disable it, I change the env locally so that FEATURES=-test (via /etc/portage/env). how many packages do you have in there? i usually just do it manually, so i dont have easily available stats on how many packages are affected. I don't have a lot: $ tree /etc/portage/env /etc/portage/env |-- app-portage | `-- portage-utils.env |-- dev-libs | |-- boost.env | `-- libevent.env |-- dev-python | `-- pygtk.env |-- dev-scheme | `-- guile.env `-- sys-devel |-- binutils.env `-- libtool.env 5 directories, 7 files signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] The importance of test suites
On 2/21/10 10:11 AM, Paweł Hajdan, Jr. wrote: On 2/21/10 5:08 AM, Ryan Hill wrote: I have one simple request. When you make a non-trivial change to an ebuild - a patch, a version bump, anything that can effect the behaviour of the package - please run the test suite. Yeah, on my dev box I just run with FEATURES=test all the time. Then it's impossible to forget it. And I also catch failures in other packages. I just noticed that FEATURES=test is enabled by default in the developer profile, with some other features that make portage more strict. It also looks like the developer profile is not mentioned in the developer docs. What would you think about better advocating usage of the developer profile among developers? Looks like many problems would disappear simply because the maintainer of a given package would hit the problem first (and fix it before it gets into portage). Paweł Hajdan jr signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] The importance of test suites
On 2/22/10 2:01 PM, Gilles Dartiguelongue wrote: Le dimanche 21 février 2010 à 10:53 +0100, Paweł Hajdan, Jr. a écrit : $ tree /etc/portage/env /etc/portage/env |-- app-portage | `-- portage-utils.env |-- dev-libs | |-- boost.env | `-- libevent.env |-- dev-python | `-- pygtk.env pygtk should succeed, it does or did last time I touched it. Please report. Still fails for me (https://bugs.gentoo.org/245103). Please note I'm running x86, so this is with dev-python/pygtk-2.14.1-r1 and not the latest version). |-- dev-scheme | `-- guile.env `-- sys-devel |-- binutils.env `-- libtool.env libtool was fixed by diego a couple of weeks ago, it's probably not needed anymore. This still fails for me on x86 stable, https://bugs.gentoo.org/293758. Paweł Hajdan jr signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Proposed change to savedconfig.eclass
While you're touching this, could you improve this part a bit:
# maybe the user is screwing around with perms they shouldnt #289168
if [[ ! -r ${base} ]] ; then
eerror Unable to read ${base} -- perms are screwed ?
die fix your system
fi
I understand frustration caused by weird things people are doing with
systems, but sometimes it can be even caused by some tool's error or
whatever. IMHO these are not good error messages. I'd prefer something
like this:
# Make sure we don't hit a problem with permissions, bug #289168
if [[ ! -r ${base} ]] ; then
eerror Unable to read ${base}. Please run chmod 755 ${base}
eerror and try again.
die unable to read ${base}
fi
Thanks,
Paweł Hajdan jr
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On 3/4/10 7:22 PM, Arfrever Frehtes Taifersar Arahesis wrote: Setting Python 3.1 as main active version of Python is currently unsupported. When it will change, a separate news item will be created to notify users. I'd suggest s/users/you 'eselect python COMMAND --python3 [ARGUMENTS]' can be used to manage configuration of active version of Python 3. I'm confused by the above paragraph. I had to spend a longer while to see that it really means if you want to use eselect-python to manage your python3 configuration, pass the --python3 switch. Before that I wondered what is the meaning of COMMAND and ARGUMENTS. Would be nice to make it more clear. Although Python 3.1 should not be set as main active version of Python, users should run python-updater after installation of Python 3.1. By default, Again, IMHO s/users/you, or please run. It is recommended to use a UTF-8 locale to avoid potential problems. Especially Link to the UTF-8 guide please? C and POSIX locales are discouraged. If locale has not been explicitly set, then POSIX locale is used, so users should explicitly set locale. Problems I'd suggest s/users/you, or maybe make sure you have set locale. occuring only with non-UTF-8 locales should be reported directly to upstream nit: occuring - occurring Paweł Hajdan jr signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Handling of keywording bugs with only one arch
On 3/12/10 8:18 PM, Petteri Räty wrote: There seems to be two different schools on who to assign a keywording bug with only a single arch. Why a special case for that? The general rule seems to be that the owner is the maintaining herd (if any), otherwise the maintainer. Then all arch teams and possible co-maintaining herds are CC-ed. Anyway, I don't have a strong opinion about any of these, just prefer a simplicity of the rules. Paweł Hajdan jr signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On 3/24/10 6:35 PM, Ben de Groot wrote: All valid concerns about text already included in the news item have been addressed. We don't need to include any unofficial recommendations. I'll take that as a yes then, you are indeed disregarding the concerns and recommendations of your fellow Gentoo developers. CC'ing devrel because this is getting out of hand. I think it's a purely technical issue. The arguments against Python 3 are mostly in the form I don't feel it's ready. If it can't be resolved on the list (some people want Python 3, some don't), shouldn't the council decide? The elected Gentoo Council decides on global issues and policies that affect multiple projects in Gentoo. Paweł Hajdan jr signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: pkg_pretend USE validation and VALID_USE alternative
On 3/31/10 1:04 PM, Ulrich Mueller wrote: We already have enough issues with circular dependencies, and I'm sceptical about adding additional failures on USE flag conflicts. Display a warning, but don't error out. How about only allowing local USE flags to conflict? This also seems to be the most common use case. Anyway, the earlier the user can react to USE flags conflict, the better. Paweł Hajdan jr signature.asc Description: OpenPGP digital signature
[gentoo-dev] are hardened-sources maintained?
I'm seeing more and more complaints in https://bugs.gentoo.org/show_bug.cgi?id=284746 (request to bump hardened-sources). Can I take over the package? No real reaction for about 8 months sounds like not maintained to me. I'm using it on one of my machines, and would gladly give the hardened-sources some love. Of course that would mean getting included in hardened-ker...@gentoo.org, but I guess it's the easiest part. Paweł Hajdan jr signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Is Gentoo dying?
On 4/3/10 11:16 AM, Tobias Scherbaum wrote: Hell no, but ... We have lots of quite understaffed areas, to sum up in a positive way. Summing it up the negative way one might say, we have lots of areas were users might get the idea Gentoo already is dead. For example: - hardened-sources are nowadays only available in an experimental overlay, lots of users keep asking what's happening to the hardened-sources on both the -dev but also the -hardened mailinglist. I recently sent an e-mail to gentoo-dev, http://archives.gentoo.org/gentoo-dev/msg_2eb703ee97afc64a29e5d148457ac8d5.xml It seems that some work is being done, but there are people who volunteered to help, like me. What needs to be done with hardened-sources? Just a note: I'm using it on my servers, so I'm really interested in them being maintained, and I'm also able to test. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
On 4/3/10 12:03 PM, Krzysztof Pawlik wrote: On 04/03/10 10:50, Petteri Räty wrote: I don't think later is valid resolution. If there's a valid bug it just means it's never looked at again. If the bug is not valid then a different resolution should be used. So what do you think about disabling later? I would like to avoid things like this: https://bugs.gentoo.org/show_bug.cgi?id=113121#c21 Not applicable to the bug above but in general our social contract says: We will not hide problems Sounds good, can we at the same time get RESOLVED OBSOLETE (for bugs that are not valid anymore due to changed situation, RESOLVED INVALID isn't applicable in this case as it implies the bug is and was invalid from the begining). Wouldn't WORKSFORME apply in that case? Just renaming the resolutions doesn't gain us much. Reducing the number of possible resolutions does, I'd say. signature.asc Description: OpenPGP digital signature
[gentoo-dev] spin (spinroot.com) license
I'd like to add a package for spin to the tree (it's used at several universities, including mine and Caltech). However, it's not straightforward. The basic license is for educational purposes only. Here are my suggestions how to implement that. /usr/portage/licenses/spin-educational with the following content: Copyright (c) 1989-2006 Lucent Technologies, Bell Labs Extensions (c) 2006-2009 NASA/JPL California Institute of Technology All Rights Reserved. For educational purposes only. No guarantee whatsoever is expressed or implied by the distribution of this code. /usr/portage/licenses/spin-commercial with the content pasted from http://www.spinroot.com/spin/spin_license.html And then in the ebuild: LICENSE=|| ( spin-educational spin-commercial ) Are there any license groups these should be added to? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On 4/3/10 3:40 PM, Ben de Groot wrote: Are there any other ideas on how to improve our recruitment process? The idea appeared before, but I think it's worth noting. Either merge the ebuild and end quizzes, or make the split actually meaningful. In my case I just finished both at the same time, but was confused why they are separate. I think I've seen similar comments from other developers. I think I'd rather prefer merging the quizzes. Paweł Hajdan jr signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: virtual/icon-theme
What do you think about creating a new virtual package, icon-theme? This would for example simplify the dependencies for www-client/chromium, which currently uses this: || ( x11-themes/gnome-icon-theme x11-themes/tango-icon-theme x11-themes/xfce4-icon-theme ) Also, possibly other icon theme packages in the tree could be added to that. The suggested description would be Virtual for desktop environments' icon themes. Suggested herd would be freedesktop. What do you think? Paweł Hajdan jr signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: virtual/icon-theme
On 4/11/10 9:54 PM, Petteri Räty wrote: On 04/11/2010 10:38 PM, Paweł Hajdan, Jr. wrote: What do you think about creating a new virtual package, icon-theme? This would for example simplify the dependencies for www-client/chromium, which currently uses this: What other packages would make use of the virtual? I think that the packages that currently depend on one icon theme, could instead just depend on that virtual. For example, xfce works fine without the xfce theme, provided some other theme (like gnome or tango) is there. Is it a requirement that more than one package should depend on it until we can extract a virtual? I think it would simplify managing the dependencies anyway. Another question is, would the freedesktop herd want to maintain the virtual? signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: bugzilla flags for arch-testing
To make it easier to find stabilization bugs with arch-testers' comments, I'd like to add new flags to Gentoo bugzilla. This is only an initial idea, and maybe a different implementation would be better (like the status whiteboard, if it's easily searchable). Initially, I'd like a new flag x86-at to be added, with states: (default), + (meaning that an AT has tested the package successfully on x86), - (meaning that an AT found some problems preventing stabilization) ? (meaning a developer asks for more urgent AT testing) What do you think? Feel free to suggest alternative implementations. The goal is to easily find bugs where ATs posted comments that the package is ready to go stable. Also, I think it may be useful for other arch teams (like amd64). One solution would be to add yet another flag, like amd64-at, but maybe we can have some better ideas. After a consensus is reached, I'm going to file a bug for infra for necessary changes in bugzilla configuration. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: bugzilla flags for arch-testing
On 4/26/10 12:34 PM, Matti Bickel wrote: On 04/26/2010 11:40 AM, Paweł Hajdan, Jr. wrote: To make it easier to find stabilization bugs with arch-testers' comments, I'd like to add new flags to Gentoo bugzilla. Can you explain how the TESTED Keyword is not sufficient for your goal? It explicitly states: Ebuilds that have been marked as tested by arch testers. I'd like to narrow the search to x86 arch testers. We test independently on each arch. Paweł signature.asc Description: OpenPGP digital signature
[gentoo-dev] ccache causing problems
I've just seen two serious problems with ccache in a short period of time. In both, webkit seems to be somehow involved (it has a complex build process). See https://bugs.gentoo.org/show_bug.cgi?id=316657 and https://forums.gentoo.org/viewtopic.php?p=6262495#6262495. I'm afraid we probably can't get enough data from the above to produce a good bug report for ccache. What actions would you suggest? Paweł Hajdan jr signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] ccache causing problems
On 4/29/10 9:41 AM, Robin H. Johnson wrote: On Thu, Apr 29, 2010 at 09:06:51AM +0200, Paweł Hajdan, Jr. wrote: What actions would you suggest? Have your user do a binary search of the ccache dir to find which cache file is causing the problem, by restoring from his backup then renaming half the directories each time. It may be difficult, see https://bugs.gentoo.org/show_bug.cgi?id=316657#c8. Do we have some docs on the web with detailed instructions how to do that? ccache itself hasn't been the problem, but unreliable hardware has. Provably by removing the corrupt cache files, then running with ccache a few more times, and having everything work perfectly. I see. However, I'd consider not detecting the corruption a bug. Paweł Hajdan jr signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About libpng-1.4 handling
On 5/10/10 7:27 PM, Samuli Suominen wrote: Should we advise users to do something like: find /usr/lib -name '*.la' | xargs sed -i -e '/^dep/s:-lpng12:-lpng14:' lafilefixer --justfixit is easier to remember. Does it work equally well? Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About libpng-1.4 handling
On 5/10/10 7:42 PM, Samuli Suominen wrote: On 05/10/2010 08:34 PM, Paweł Hajdan, Jr. wrote: On 5/10/10 7:27 PM, Samuli Suominen wrote: Should we advise users to do something like: find /usr/lib -name '*.la' | xargs sed -i -e '/^dep/s:-lpng12:-lpng14:' lafilefixer --justfixit is easier to remember. Does it work equally well? Last I tried, ... lafilefixer couldn't handle libpng migration But it's Gentoo's script, right? How about just adding the command you posted to lafilefixer? Some people are used to think of Gentoo as the distro where things break once a week. I don't think that, but I can easily imagine how having to run a different command on each upgrade is frustrating people. On the other hand, when we can ensure that emerge -uDNa world, revdep-rebuild, dispatch-conf and lafilefixer result in a working system without additional work, that makes updates more predictable. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Does anyone use the VERIFIED status in bugzilla?
On 5/14/10 3:54 PM, Matti Bickel wrote: From my work on b.g.o: I use a simplified version of this, shown at: http://dev.gentoo.org/~mabi/gentooBzLifecycle.png Yeah, I think the linked diagram really reflects the reality, much better than the official one. I'm in favor of removing the Verified resolution to clean things up. I haven't seen a project where the Verified status would be useful. Generally the reporters re-open their bugs if they are not satisfied. Also, for many classes of bugs verification gives absolutely no benefits, e.g. keywording, stabilization, etc. If we want to keep Verified, then in my opinion some group should be created to verify bugs consistently. If it's just one user doing it, I see no benefits, and only background noise. Note: maybe that user would like to help in the bugzilla in a way we'd all agree to be useful. For example wrangling bugs (assigning to right owners, getting more info, etc). Please make sure not to discourage him from contributing more by too harsh comments. Paweł signature.asc Description: OpenPGP digital signature
Re: Notify people about empty herds (Was: Re: [gentoo-dev] FTR: media-opti...@g.o has no developers)
On 6/3/10 3:32 PM, Markos Chandras wrote: And maybe it would be a wise move to merge/remove some herds because ,as I see, the number of herds is equal ( or even higher ) to the number of developers. Here are some more empty herds: 1) kerberos herd is empty :( 2) secure-tunnelling is empty 3) utf8 is empty and looks like a candidate for removal As for other herds, I don't see anything obviously wrong. It seems fine and useful to have a generic alias even if there is only one developer in a herd. Paweł signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: changing the developer profile: FEATURES=test - FEATURES=test-fail-continue
What do you think about doing the following change in /usr/portage/profiles/targets/developer/make.defaults: replace test with test-fail-continue to make it just less frustrating (we still have a lot of test failures) Hopefully that will also make more of us use the developer profile, and detect test failures. What do you think? Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: changing the developer profile: FEATURES=test - FEATURES=test-fail-continue
On 6/4/10 5:35 PM, Jesus Rivero (Neurogeek) wrote: I've been thinking about this for a while. Some packages have tests that are meant only for upstream in certain conditions and are not meant to be ran during installing. I think that in extreme cases src_test should not call such tests. As we have ARCH teams, couldn't we think a way in which TEST teams can be created? I mean, a bunch of devs only focused on making tests work or just restrict them? I don't think that would be effective. Making the tests work is hard, especially for packages like gcc, or python. Having FEATURES=test is intended to make developers catch these failures before checking in. However, with many packages failing tests, people started running FEATURES=-test or just stopped (or never used) the developer profile. With FEATURES=test test-fail-continue we should get best of both worlds: run tests always, but don't frustrate people by making build fail in the middle of long emerge. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: RFC: changing the developer profile: FEATURES=test - FEATURES=test-fail-continue
On 6/7/10 12:10 PM, Thilo Bangert wrote: as it seems, there is disagreement about the issue among developers. Perhaps the council would like to settle this, so that we can go on with our lives. i do agree, that all packages should build successfully including the test phase. RESTRICTing the test and an open bug when this is not the case. Thilo, I'm trying not to touch the issue of test failures at all. Also, my feeling is that although not too many people commented here, we have a consensus in favor of my suggestion. And my suggestion is to replace FEATURES=test in the developer profile with FEATURES=test test-fail-continue to make us developers actually use it. I've been running my dev box with FEATURES=test test-fail-continue and I'm happy. I'm filing bugs for the test failures, but the packages get installed regardless of that (i.e. I get the work done). If it does answer your doubts, then great. If it doesn't, please let me know what I'm missing. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: changing the developer profile: FEATURES=test - FEATURES=test-fail-continue
On 6/4/10 5:11 PM, Paweł Hajdan, Jr. wrote: What do you think about doing the following change in /usr/portage/profiles/targets/developer/make.defaults: The following change has now landed in CVS: Index: targets/developer/make.defaults === RCS file: /var/cvsroot/gentoo-x86/profiles/targets/developer/make.defaults,v retrieving revision 1.3 retrieving revision 1.4 diff -u -B -r1.3 -r1.4 --- targets/developer/make.defaults 4 Oct 2009 09:44:27 - 1.3 +++ targets/developer/make.defaults 9 Jun 2010 17:03:37 - 1.4 @@ -1,8 +1,8 @@ # Copyright 1999-2008 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# $Header: /var/cvsroot/gentoo-x86/profiles/targets/developer/make.defaults,v 1.3 2009/10/04 09:44:27 ssuominen Exp $ +# $Header: /var/cvsroot/gentoo-x86/profiles/targets/developer/make.defaults,v 1.4 2010/06/09 17:03:37 phajdan.jr Exp $ -FEATURES=collision-protect cvs digest multilib-strict sign splitdebug stricter test userpriv usersandbox +FEATURES=collision-protect cvs digest multilib-strict sign splitdebug stricter test test-fail-continue userpriv usersandbox # Disable branding (from desktop) USE=-branding signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Moving more developer data to LDAP, for scalability/redundancy (away, foward, permissive, SMTP password, plan) [WAS: Suggestion to ask devs to change their bugzilla name]
On 6/11/10 5:27 AM, Robin H. Johnson wrote:
- Ability to split woodpecker/dev.g.o up, and have an EU dev machine,
and a US dev machine. (If mail isn't being forwarded outside of our
systems, you would put in ${userna...@eu.dev.gentoo.org.
Sounds good to me. Looks like it would have lower latency. :)
Cons:
- developers get changes to LDAP wrong already.
= I counter that they ALSO change the wrong filenames and wonder why
there is no effect. I counted a large number of '.permissave',
'.devaway' and '.asmtppasswd' files.
Maybe we should have an easy way to compare how the system sees it
versus how the user sees it? For example some command/script that would say:
.away file: missing
(... similar checks for other files/things omitted here ...)
And then a person who has created a .devaway file can notice the
discrepancy.
- complaints that LDAP is too hard to use.
Maybe we need better scripts and better documentation? I think the main
problem might be that LDAP is too alien for many people.
My opinion: I have no problem using Gentoo LDAP, but would appreciate
some usability improvements. :)
- need to remember your LDAP password!
D'oh, I guess it's always required, for example to update the
description displayed on the roll call. By the way, it looks like this
is the reason why the description is sometimes outdated.
Paweł
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Moving unmaintained packages to Sunrise
On 6/13/10 6:35 PM, Michał Górny wrote: But who's talking here about moving abandoned ebuilds just to keep them? I'd wanted just to make it simpler to switch the 'maintainership' from Gentoo devs to Sunrise users, when the second are ready to maintain the ebuild well. Can you suggest a specific plan or process how to do that? Please don't go into discussion no, the devs should do that vs no, the users should do that. Currently it seems the users can take the last-rited ebuilds and get them into sunrise. They can step up as proxy maintainers and prevent the package from getting tree-cleaned. There are many options, which can be used right now and have existed for months. Paweł signature.asc Description: OpenPGP digital signature
