Re: [gentoo-dev] Dissolving project desktop-misc
Le 29/11/2020 à 16:48, Andreas K. Hüttel a écrit : x11-misc/i855crt I'm fairly certain this package cannot work with post-KMS kernel drivers, so anything after 2010 or so. And the laptops that sport this chip are probably all dead by now (mine is anyway). I'd say, let's push this one to last-rite right away. Cheers, Rémi
[gentoo-dev] Re: [PATCH 3/5] xdg.eclass: move deps to RDEPEND
Le 01/10/2018 à 00:50, Mike Gilbert a écrit : > update-desktop-database and update-mime-database are called from ROOT in > pkg functions, so the related dependenices belong in RDEPEND. > > Signed-off-by: Mike Gilbert As far as the eclass goes, this is correct. But AFAIR, this was needed because some packages look for those tools at build time. It was ages ago so maybe it no longer applies. Rémi
Re: [gentoo-dev] Re: Reverted python3.4 defaults
Le 19/07/2015 18:42, Ben de Groot a écrit : I would like to note that we only have around 50 packages that require python3, while the majority requires python2, and the remainder will function with either. How far are we from building a python3-only stage3? Are there any major blockers? Would any outside help be of use? Rémi
Re: [gentoo-dev] Re: [gentoo-dev-announce] Service relaunch: archives.gentoo.org
Le 26/02/2015 09:39, Markos Chandras a écrit : Excellent! Looks great. Thank you very much for your hard work Seconded, this is a huge improvement over the old site. Thanks to all involved, this is fantastic work! Rémi
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
Le 19/01/2015 23:40, Michał Górny a écrit : 1. Compatibility. USE=ffmpeg is already used for || ( libav ffmpeg ) in a lot of packages. If we changed the meaning, libav users will end up switching '-ffmpeg libav' per-package. Ugly. 2. Feature-oriented flags. USE=ffmpeg represents the generic feature, USE=libav is auxiliary implementation-switch flag. Well, maybe we could use, say, USE=avcodec to avoid ambiguity but that's a larger change. I think our users are clever enough to update their USE flags as they wish. USE=ffmpeg for FFmpeg support + USE=libav for libav support is simple and easily understood. I'd much rather we went with that. Cheers, Rémi
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
Why not : libav? ( media-libs/libav:= ) ffmpeg? ( media-libs/ffmpeg:= ) + REQUIRED_USE=^^ ( libav ffmpeg ) I for one would never expect USE=-libav to enable ffmpeg (nor USE=-ffmpeg to enable libav FWIW). Rémi
Re: [gentoo-dev] Running repoman on the portage tree
Le 19/11/2014 03:17, Alec Ten Harmsel a écrit : Hey devs, Hi Alec, This is my first mail to this list. If this is out of line, let me know. Not out of line on the topic/content, but try to avoid sending 3MB attachments to hundreds (thousands?) of people. * 9233 ebuilds that use a deprecated EAPI Unlike other distros where there's usually one version of a given package (with the history being available in archives elsewhere), we sometimes have dozens of available versions for a single package. When new EAPIs come along, devs will usually improve their ebuilds when new upstream versions are released and leave old ebuilds as-is (especially if said ebuilds have stable keywords). So while that number looks impressive, you need to factor in which packages have ebuilds that use newer EAPIs. If you do come across packages that only offer ebuilds written using deprecated EAPIs, then I'm sure maintainers will accept contributions. Cheers, Rémi
Re: [gentoo-dev] typo in scrypt USE-Flag
Le 02/11/2014 17:48, Alex Xu a écrit : so... instead of emailing 4 people (three bug-wranglers plus one maintainer), you email around 300 people (assuming that subscriber count is around the same as #gentoo-dev users, which is probably a severe underestimate). Alex: no need for a snarky comment. A simple a bug is fine, please do open one would have been enough. Marco: thank you for your contribution, however small. Bugzilla is indeed the proper place for any and all ebuild improvements. Cheers, Rémi
Re: [gentoo-dev] packages masked for removal in 30 days
Le vendredi 23 mai 2014 à 22:57 +0700, gro...@gentoo.org a écrit : # Google closed free usage of the translate api # Masked for removal in 30 days app-text/qgoogletranslator # openmcl has been renamed to clozurecl # Masked for removal in 30 days dev-lisp/openmcl dev-lisp/openmcl-build-tools This is worthy of gentoo-announce@g.o Cheers, Rémi
Re: [gentoo-dev] Akamai secure memory allocator for OpenSSL?
Le lundi 14 avril 2014 à 10:48 +0200, Tiziano Müller a écrit : Not really, no. I would rather wait until other people have reviewed and/or it has been pulled into openssl. To cite the Akamai dev who posted the patch [1]: Let me restate that: *do not just take this patch and put it into production without careful review.* http://lekkertech.net/akamai.txt I, for one, am glad we didn't pull this in right away. OpenSSL is under a lot of scrutiny now, so let's not rush any patches. Cheers Rémi
Re: [gentoo-dev] Maintainer-needed on many of my packages
Le dimanche 29 décembre 2013 à 00:19 +, Robin H. Johnson a écrit : sys-apps/vbetool Is this still remotely useful with KMS-enabled kernels ? Cheers, Rémi
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
Le jeudi 07 novembre 2013 à 10:44 +0100, Alexis Ballier a écrit : in short: if a package requires version X then the ebuild should require version X; it can be forgotten but it's a bug. That _is_ our policy. Ebuilds should - at the very least - mirror what upstream's build script requires. So, count my +1 there. Rémi
Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox
Le mardi 20 août 2013 à 12:26 +0200, Michał Górny a écrit : 3. FEATURES=ipc-sandbox Requires: CONFIG_NAMESPACES, CONFIG_IPC_NS Applies to: src_* This one separates the ebuild's *nix IPC stuff from host. This includes semaphores, shared memory etc. Similarly to network-sandbox, this could prevent ebuilds from communicating with some production servers. But honestly, I have no idea if anything really does it or relies on it. I doubt this could break something but it's worth testing. This could impact ebuilds using the virtualx eclass, depending on how the launched xvfb/xorg server is launched. It'd be interesting to test the impact. Other than that, it looks like really sweet stuff. Cheers, Rémi
Re: [gentoo-dev] Autobuilds go to /experimental and to /releases only when someone actually tests them
Le vendredi 26 juillet 2013 à 21:19 -0700, Paweł Hajdan, Jr. a écrit : 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. How about a regular test livecds event? Kind of like a bug day. Seems like it could also be a nice and easy way to reach potential new contributers: just burn an ISO, reboot your computer, report back whether network/disk access works. Rémi
Re: [gentoo-dev] Re: Packages up for grabs due lack of time
Le dimanche 17 février 2013 à 22:47 -0600, Ryan Hill a écrit : Even after you do that it's hard to figure out what firmware files you actually need. I know I need iwl6000 firmware for Intel Ultimate-N 6300 wifi, but linux-firmware contains: iwlwifi-6000-4.ucode iwlwifi-6000g2a-5.ucode iwlwifi-6000g2a-6.ucode iwlwifi-6000g2b-5.ucode iwlwifi-6000g2b-6.ucode Are these different versions? Different cards? Which do I need? Good kernel modules *should* export needed firmwares as module parameters. You *should* then be able to query it with modinfo: modinfo module -F firmware Note however that *lots* of modules (especially DVB, in my experience) don't properly set those parameters and you're left grepping the source code or dmesg to find which firmware you'll need... Cheers, Rémi
Re: [gentoo-dev] Getting the general dev opinion (Meinungsbild) on some feature
Hi Andreas, Le dimanche 20 janvier 2013 à 16:20 +0100, Andreas K. Huettel a écrit : So, a thread like Should we enable useflag Z by default would then include Please discuss here, vote on ... with a link to the count page (updated via cron every 1h). On login to ..., a message similar to the open elections message could be displayed. Obviously the implementation does not exist, but this is conceptually simple enough so it could be implemented within reasonable time. We (devs) participate in Gentoo in various ways and for very different reasons. And those ways and reasons may change over time. I, for one, no longer consider myself sufficiently informed about new PM/EAPI features, various profile changes, etc. Though I'll gladly update the few packages I maintain to whatever standard is expected, I'll leave the discussion(/trolling?) to other better-informed folks as I often have nothing of value to contribute in those areas. In fact, I believe this to be exactly the Council's role and we already have the necessary tools for that, including a yearly election. Council members already represent Gentoo devs when tougher decisions need to be made. So while I commend you for trying to collect everyone's opinion, I believe it should *not* be necessary for you (or anyone else) to organize elections or polls in order to implement new features or changes to Gentoo. Cheers, Rémi
Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
Le mercredi 28 novembre 2012 à 22:49 +0100, Justin a écrit : Solution: Create them by hand. The solution is to tell *upstream* how to build and ship .pc files with their build system. If we start shipping .pc files no one else has, projects that use such libraries will have only 2 choices: - check the .pc file and use whatever fallback code they had before to find the correct library paths and options. - change nothing and keep their current code Either way, we'll be stuck maintaining .pc files no one will be using. Please convince upstreams stuck in the middle ages that .pc files are a Good Thing™ that make everybody's lives easier. Cheers, Rémi
Re: [gentoo-dev] [PATCH python-r1] Move common utility functions to python-utils-r1.
Le jeudi 22 novembre 2012 à 20:59 +0100, Michał Górny a écrit : You could say it's an algo like this: 1) if you want phase functions for distutils all other automagic, use distutils-r1; 2) if you don't want phase functions but want PYTHON_TARGETS and other metadata stuff, use python-r1; 3) if you don't want phase functions nor metadata, just some random potentially useful functions, use python-utils-r1. Please, pretty please: paste this blurb somewhere (near the top) in *one* of the above three eclasses and modify the other 2 to point developers to the former eclass. Cheers, Rémi
Re: [gentoo-dev] The problem with new dev-python/argparse and REQUIRED_USE
Le jeudi 01 novembre 2012 à 23:30 +0100, Michał Górny a écrit : Do you have any ideas how to solve that kind of stalemate? How about a carefully crafted news item inviting users to enable the latest python version and to emerge -C argparse afterwards? We've already asked users to handle more complex upgrades themselves using news items... Cheers, Rémi
Re: [gentoo-dev] package graveyard
Le 17/08/2011 21:57, Matthew Summers a écrit : +1 on this. It saves the ebuild for posterity AND prevents users hitting nasty bits. This seems to me to beg for a proper well-defined policy, in any case. We already have a policy for this and it's called portage. If a package is broken (and I mean with known ebuild issues, with known bugs, etc), then we already have legitimate reasons to remove it. If not, just let them be in portage. If anything, working on tinderboxes to catch build issues early and file bugs against packages, _that_ would help to clean up cruft from portage. Rémi
Re: [gentoo-dev] openrc-0.8.1 stable candidate
Le 12/04/2011 16:56, William Hubbs a écrit : All, at long last, we have an openrc stable candidate. Thanks to all of you who worked on this over the years, your efforts are _really_ appreciated. This means we need more testers. Openrc being so central to Gentoo, may I suggest a bigger campaign, on planet gnome and other outlets? Cheers, Rémi
Re: [gentoo-dev] FYI: USE=hal masked in base/use.mask and related
Le 27/03/2011 10:36, Samuli Suominen a écrit :
Also, both udisks and upower now have blockers for sys-apps/hal to
prevent overlapping features.
Samuli,
I know you want to kill HAL with a vengeance. I don't disagree with the
ultimate goal but I think you've gone too far.
HAL and u{power,disks} are _perfectly_ parallel installable and there
are absolutely _no_ conflicts between the two.
Blockers should be used for _file_ conflicts, not for _feature_
conflicts, otherwise we'd have to mask and get rid of half (or even
more) of all the packages we provide in portage.
I urge to reconsider this blocker and mask.
Thanks
Re: [gentoo-dev] rejecting unsigned commits
Le 24/03/2011 22:59, Mike Frysinger a écrit : is there any reason we should allow people to commit unsigned Manifest's anymore ? generating/posting/enabling a gpg key is ridiculously easy and there's really no excuse for a dev to not have done this already. I, for one, have never signed my Manifests because I've always found GnuPG to be a major PITA. With that being said, I do understand the rationale of signing them and I'll adapt. However, is there a howto or something explaining how to work _efficiently_ with GPG? How do I avoid having to type my pass-phrase for every commit? Cheers, Rémi PS, wasn't manifest-signing supposed to become moot once we moved to git?
Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade
Le 26/02/2011 17:08, Enrico Weigelt a écrit : I could imagine a way like that: [...] Or we can do it like distributions always do (at least we do) : 1) find packages that don't work out of the box with libpng 1.5 2) work with upstream to fix them Really, libpng15 is to libpng14 what gtk3 is to gtk2: a new library. Let's treat it as such. Rémi
[gentoo-dev] Re: [gentoo-dev-announce] Stabilisation exceptions
Le 24/01/2011 13:31, Christian Faulhammer a écrit : Hi, over the course of the years the x86 (and other architectures as well) has given away permissions to maintainers/teams to mark packages stable themselves. As there never was a definitive list what exceptions exist, I compiled a list of the ones I could get from the top of my head in [1]. Please yell if you have those permissions so I can complete the list for reference purposes. X11 has requested and was granted permission from all arch teams to stabilize x11-misc/util-macros and all media-fonts/* (those that we are responsible for anyhow). There might be another 2 or 3 packages that I've forgotten but we rarely modify them anyway... Cheers, Rémi
Re: [gentoo-dev] Deprecate EAPIs 0 and 1?
Le 31/12/2010 17:04, Brian Harring a écrit : Quick scan of the tree via `pinspect eapi_usage`, the percentile is eapi: '0' 13934 pkgs found, 50.43% of the repository eapi: '2' 8679 pkgs found, 31.41% of the repository eapi: '3' 4432 pkgs found, 16.04% of the repository eapi: '1' 583 pkgs found, 2.11% of the repository Based on those stats, I would definitely deprecated EAPI 1 since it's almost unused, and EAPI 2 since its behavior is really close to EAPI 3. As others have mentioned, only for _new_ ebuilds. My 2¢, Rémi
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2010-12-05 23h59 UTC
Le 06/12/2010 01:25, Robin H. Johnson a écrit : Removals: media-libs/libresample2010-12-01 19:06:41 chainsaw Additions: media-libs/libresample2010-12-01 16:59:41 chainsaw A glitch in the matrix? Rémi
Re: [gentoo-dev] .la files and their future on Gentoo
Le 04/10/2010 08:35, Michał Górny a écrit : On Mon, 04 Oct 2010 00:00:22 +0200 Rémi Cardona r...@gentoo.org wrote: #2a) pkg-config is one solution (what upstream Xorg says: if you want a static libX11, use pkg-config --static), other teams/herds could fix their packages' .pc files to correctly list all required packages for proper static linking. It's not rocket science. AFAIK more .pc files rather need fixing to list only direct dependencies when '--static' is not used. pkg-config itself takes care of the dependencies pretty well. Right, either way, .pc files usually need a little tweaking as devs rarely touch them unless something is really broken. Patching (in accordance with upstream of course) may be required. But it's definitely my preferred solution (and a cross-platform one at that!) Cheers, Rémi
Re: [gentoo-dev] .la files and their future on Gentoo
Le 03/10/2010 16:29, Luca Barbato a écrit : I think the simpler solution is that if it needs .la, before reaching the tree it has to be fixed... Using libltdl (libtool's dlopen wrapper) is a *legitimate* use of .la files. Those programs do not need to be fixed as they are not broken. The discussion here is about random apps and libs, that install .la files for no other reason that they were *built* using libtool. Such programs will work just fine without .la files. The only risk is breaking : 1) building other packages (see the dbus bug) 2) building *static* programs/libs #1 can be fixed using lafilefixer which sanitizes .la files so that they stop referencing other .la files. #2 is harder : #2a) pkg-config is one solution (what upstream Xorg says: if you want a static libX11, use pkg-config --static), other teams/herds could fix their packages' .pc files to correctly list all required packages for proper static linking. It's not rocket science. #2b) drop support for static linking altogether. It can make sense for some packages, but definitely isn't suitable for the entire portage tree. So again, these are the only 2 issues we should be addressing. Cheers, Rémi
Re: [gentoo-dev] .la files and their future on Gentoo
Le 02/10/2010 21:54, Jorge Manuel B. S. Vicetto a écrit : With that goal in mind, I'd like to ask anyone with arguments about this issue to present them as a reply to this thread. [putting on my X11 cap] As far as X11 packages are concerned (libX11, libXext, cairo, etc), we can remove .la files now since upstream only supports linking through pkg-config (static linking included). So X11 can remove them any time, I was just waiting for a flag-day to do it. Cheers, Rémi
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
Le 26/06/2010 21:39, Enrico Weigelt a écrit : #2 One point i don't agree is the dont add -Werror rule. actually, i'm thinking of making -Wall and -Werror mandatory. if some package doenst build fine, it's simply broken. period. You're obviously new here... Just take a stroll through bugzilla to see how much we _fight_ against -Werror. Let's see why you obviously have not thought through this completely before writing this : We currently offer 11 different slots of GCC, 3 of gcc-apple, each with multiple versions, 3 versions of llvm-gcc, 2 versions of clang, 7 versions of icc, so in all 26 *major* versions. You do well know that each compiler prints out different warnings for the *same* code... We also offer 10 versions of glibc, 8 versions of uclibc, and 7 versions of klibc. Each version may have header bugs, so may trigger warnings for perfectly good code. And finally we offer 5 unmasked versions of binutils (newer ones even have a brand new linker - gold) and 5 versions of binutils-apple. Again, different tools, different warnings... If you want to make -Werror mandatory, you *MUST* test all combinations above as *THEY ARE ALL SUPPORTED*. Otherwise, packages will break for no good reason and users will hate us. -Werror is a perfectly fine *developer* feature. For example, Gnome autoconf macros enable it for development snapshots, but never ever enable it for stable releases. So please, if you want to write nonsense, don't write it in the name of Gentoo. Rémi PS, Diego (flameeyes) is already having enough issues with his tinderbox running *ONE* compiler/linker/libc combination...
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/traits: traits-3.4.0.ebuild
Le 10/06/2010 22:45, Arfrever Frehtes Taifersar Arahesis a écrit : 2010-06-10 22:20:44 Nirbheek Chauhan napisał(a): On Fri, Jun 11, 2010 at 1:30 AM, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 2010-06-10 21:27:40 Jeremy Olexa napisał(a): I see no reason to *not* add a ChangeLog entry here. ChangeLog entries are not required for trivial changes. A trivial change is fixing a typo, or a manifest problem, a missing quotation mark, etc. Anything else is not trivial. Anything that changes how an ebuild functions, what it does, or the installed files (and/or their contents) is NOT a trivial change. This commit only removed some compiler warnings. Why argue about this? Just always add a ChangeLog entry, like everyone else. This is in everyone's interest, including yours. Cheers, Rémi
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
Le 06/06/2010 02:08, Sebastian Pipping a écrit : can you explain how that happens? Standard dependency resolution for packages with slots, there's nothing specific about python. Cheers, Rémi
Re: [gentoo-dev] autotools.eclass eautomake update
Le 25/05/2010 00:17, Mike Frysinger a écrit : so prove me wrong and post some useful feedback on the change. i'm simply being realistic. Even if you think no one will ever comment on your patches, I've seen enough projects where posting patches and doing reviews generated interest and got people to contribute. Unless you want to keep this eclass to yourself, posting patches is a Good Thing (tm). sources.gentoo.org/eclass/autotools.eclass?r1=1.97r2=1.98 Maybe you should grep for AC_INIT_AUTOMAKE too, as that's what lots of folks used a while ago. Cheers, Rémi
Re: [gentoo-dev] autotools.eclass eautomake update
Le 25/05/2010 09:23, Mike Frysinger a écrit : Even if you think no one will ever comment on your patches, I've seen enough projects where posting patches and doing reviews generated interest and got people to contribute. i'm just asking for proof that it's useful here And I'm asking you to try it regardless of proof. Consider this a social experiment. no, because that isnt how autoreconf works today. current behavior mimics current autotools. Makes sense, thanks for the explanation. Cheers, Rémi
Re: [gentoo-dev] Does anyone use the VERIFIED status in bugzilla?
Le 14/05/2010 14:45, Jorge Manuel B. S. Vicetto a écrit : Please share your thoughts on this so we can decide how to act on this case. X11 team doesn't use it. While some of our users do come back and close bugs as VERIFIED every now and then, it just doesn't mean anything in the team's workflow. As far as we're concerned, we could just prune it. Cheers, Rémi
Re: [gentoo-dev] ccache causing problems
Le 29/04/2010 09:06, Paweł Hajdan, Jr. a écrit : What actions would you suggest? Don't use ccache. We (speaking as a former gnome herd member) have had countless unexplained bugs due to ccache. Now, the gnome procedure for build failures is to ask users to first disable distcc and ccache before trying to reproduce the bug, and that solves nearly all the weird issues that no-one else can reproduce. Bottom line, unless you're building the same code over and over again, don't use ccache. And even if you are, don't use it, its cache is just too easily broken. Cheers, Rémi
Re: [gentoo-dev] Requiring two sets of eyes for all eclass commits
Le 24/04/2010 19:40, Petteri Räty a écrit : What do you think about not allowing commits to eclasses without mentioning an another developer who has reviewed and approved the diff in the commit message? There's enough people on gentoo-dev for urgent stuff too. More bureaucracy and policies when we arguably have enough (or even too much...?) My vote is a clear and resounding *no*. If someone f*cks up, revert the commit if the issue isn't fixed quickly. If that someone f*cks up again, call devrel on his ass. If anything, we should be working on versionned eclasses rather than VCS hooks. My 2 euro cents. Cheers, Rémi
Re: [gentoo-dev] Policy regarding the inactive members
Le 11/04/2010 15:16, Markos Chandras a écrit : How about the participation to the discussions which took place every day on our mailing lists or in IRC? I, for one, am actually glad that the council (as such) isn't involved in every troll fest we have on -dev, and I hope we keep it that way. I guess not since we need to explicitly bring each issue to the meeting so council can talk about it. That's the whole point of the council (as I understand it): they only come in when there are issues that we (non-council devs) can't solve on our own. Why bother them with stuff that doesn't really concern them? Cheers, Rémi
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
Le 03/04/2010 11:50, Petteri Räty a écrit : 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 You're basically blaming LATER and other resolutions for users failing to *search* correctly. How about changing how users search instead? Let's make the small search box search for ALL bugs instead of just opened ones. *That* should help tremendously. That, and what Mart suggested. That's a good idea too. Cheers, Rémi
Re: [gentoo-dev] [RFC] New eclass for x11 packages
Le 01/03/2010 11:38, Samuli Suominen a écrit : I'd prefer EAUTORECONF (as it's already used in xfconf.eclass for the same purpose, and has no reason to differ) or even SNAPSHOT, but XORG_ prefix seems redudant We decided to put the prefix to make things clearer for ebuild writers and to make the eclass variables consistent. The 5 extra chars are worth it. Besides, this option isn't used a lot, so it won't clutter up portage too much ;) Cheers, Rémi
Re: [gentoo-dev] Calling unknown commands in an ebuild
Le 08/02/2010 03:24, Mike Frysinger a écrit :
if we wanted to specifically target semi-common errors (and i think 'epatch'
w/out eutils.eclass falls into this category), then a repoman check would be
good.
it might also be useful to add a default epatch() to the initial env that
would be clobbered when the inherit occurred.
epatch() { die you need to inherit eutils.eclass to use epatch ; }
+1, that's a very good idea! I've stopped counting how many times that's
happened to me.
I'm sure there are other common mistakes we all do, but this particular
one is a low-hanging fruit.
Cheers,
Rémi
[gentoo-dev] Re: LibGL.la removal news item for =eselect-opengl-1.1.1-r2 going stable
Le 17/01/2010 12:26, Tomáš Chvátal a écrit : Howdy guys, please review the attached file and suggest updates to in. I was asked for this thing going stable due to its being dependency of new nvidia-drivers. Also this thing is probably blocker for the bug on eselect-opengl i just opened: http://bugs.gentoo.org/show_bug.cgi?id=301271 I'm not a big fan of the wording but it's something we refine, the general idea is fine though. I'll try to come up with something soon. If not, it can still be posted as-is, it gets the point across. Cheers, Rémi
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
Le 29/12/2009 14:43, Henry Gebhardt a écrit : 4) add a USE-flag, say devel, that, when enabled, allows compiling programs against the package. x11-libs/libXtst would have an RDEPEND like this: RDEPEND=devel? x11-libs/inputproto This doesn't solve anything. It will just annoy users as they will have to enable USE=devel. So it's like the current situation, only way more annoying... Rémi
Re: [gentoo-dev] Non-free software in Gentoo
Le 28/12/2009 06:36, Vincent Launchbury a écrit : Hi, I recently emailed the Gentoo PR team, voicing my concerns about the amount of non-free software within Gentoo. I got an interesting response from Sebastian Pipping, who said that while Gentoo is all about choice, including the choice to install non-free software, the project is interested in making it easy for people to run a 100% free system, should they choose that path. Gentoo - like the rest of Free and Open Source Software - isn't about choice, it's about empowering users. Gentoo gives you tools and documentation to do whatever you wish. It doesn't mean that we (Gentoo) _have_ to support it. With that out of the way, moving on to the rest of the mail. 1) Not all of the licenses are completely accurate. For example, the Linux kernels are listed as soley GPL-2, yet they contain blobs of non-free firmware. Indeed, that's a very good point. And that's precisely why I was against ACCEPT_LICENSE to begin with. It's a good idea on paper, but it's just not feasible at a large scale (like portage) without a proper _team_ of devoted people sifting through code and license blobs to make it useful. I'm also pretty sure a couple lawyers would be needed as well. Unless people dedicate time and effort, ACCEPT_LICENSE is useless. [snip] The rest of your points are indeed all valid as well. I can only encourage you to either work with individual developers to get ebuilds fixed (USE=bindist or whatever) or join our ranks to fix this yourself if you really want a pure Free Gentoo. This is my first post here, so I apologize if it's misdirected. I'm not sure if I'd really be able to help much on the technical side, but if this garners any cooperation, I'll gladly help out with anything I can. If someone could point me in the right direction, I'd be very grateful. I'd say this is probably better suited for gentoo-project, but it's probably ok to start here, to gauge interest :) Best of luck Rémi
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
Le 28/12/2009 10:10, lx...@gentoo.org a écrit : List of Gentoo bugs: 298616 298618 298620 298621 298623 298624 298626 298627 298629 298631 298633 298634 298636 298638 298640 298642 298644 298645 298646 298648 298649 298653 298654 298656 298657 298658 298659 RESOLVED - WONTFIX Others and myself have spent considerable time making those deps the way they are because : 1) upstream packaging is a bit uncommon 2) ebuild deps don't fit with upstream deps 3) a few embedded devs told me they wiped /usr/include when making images So if you want to fix this properly, a new DEP variable needs to be cooked up : add the following deps to ebuilds' DEPEND when those ebuids DEPEND on this ebuild. Until such a variable exist, having the protos in both DEPEND and RDEPEND is the only _valid_ solution. Thanks Rémi
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
Le 28/12/2009 22:04, Fabio Erculiani a écrit : On Mon, Dec 28, 2009 at 9:51 PM, David Leverton levert...@googlemail.com wrote: On Monday 28 December 2009 20:50:17 Fabio Erculiani wrote: What all this has to do with the fact that they are just build dependencies? Just wondering. They're not just build dependencies. They're required to use the library in a certain way, namely to compile other programs against it. As long as we don't have compile-against dependencies, the only correct way to express that is RDEPEND (and also DEPEND because they're /also/ needed to build the library itself). To me you are saying that DEPEND would work just fine. No? No, but I understand why you're insisting. It took us a few weeks to wrap our heads around this to understand it. Let's take an example (bug #228211 but there are dozens more). In this example, libfakekey does : #include XTest.h and its configure.ac checks for xtst.pc. Both files are provided by x11-libs/libXtst so this dep is added to DEPEND and RDEPEND. The problem comes from libXtst's XTest.h which #includes XInput.h which was provided by x11-proto/inputproto [1]. inputproto is/was a build-time dep of libXtst. - libXtst _directly_ requires inputproto at build-time only - libXtst _directly_ requires libXi at build-time and run-time However : - requiring libXtst at build-time _also_ requires inputproto. For most users out there, this would never be a problem since most Gentoo users always keep build-time deps on their systems. The problem arises for people who only keep run-time deps, usually for binary packages. inputproto being a DEPEND-only dep of libXtst, binary users will never get inputproto when they build libfakekey. So there were 3 solutions : 1) add explicit deps in _all_ packages that DEPEND on libXtst to _also_ depend on inputproto even if they don't use it at all (most don't, they just use XTest functions). 2) add inputproto to libXtst's DEPEND and RDEPEND 3) modify EAPI to add a new *DEPEND variable to cater X's very special needs. Solution #1 is error prone. If we fix ebuilds now, new ebuilds might pop up later with broken dependencies. No go. Solution #3 really isn't for me. I tried getting near PMS and I got bit. If anyone wants to do this, I'll help, but I won't do this on my own. So we went with solution #2. Yes, it does add nasty little headers on a binary distribution, but that was a far better compromise than any of the other 2 solutions. Really, the correct solution (please _listen_ and _trust_ me on this) is to add a new dependency variable to EAPI to correctly describe how X headers and libs really work. That's solution #3. I agree with you, pulling protos in both DEPEND and RDEPEND is a hack, but it's *much* better than the other alternatives. Rémi [1] This file is now part of libXi, but the problem has now shifted to XI.h, so it's still going to be the exact same problem today, but for the sake of simplicity, I'll keep it short.
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
Le 28/12/2009 23:53, Fabio Erculiani a écrit : Interesting, eventually somebody gave me a detailed and technical explanation without [bla bla snip]. Thanks Rémi. Yes, I agree with you that the best (and the one I would go for, too) solution is adding support to a new *DEPEND, perhaps one that could host build-deps only. It looks weird that other PMs out there do that since 1994 (replace 1994 with older value). Perhaps adding a big fat # XXX somewhere in ebuilds would have helped us all in saving some time today. We could indeed, but back then we had something like 20~30 dupes so it felt like an obvious fix. I'll start adding comments in the overlay to clear it up. So, at least for now, I suspect I have to give up and close my shiny 27 bugs. Right? I'm afraid so, yes :) But if you do want to tackle the EAPI/PMS issue, feel free to reuse the tracker for that. I'll gladly tune in for that discussion. Cheers, Rémi
Re: [gentoo-dev] metdata.dtd should require herd/
Le 15/12/2009 16:19, Peter Volkov a écrit : we will force all metadata.xml files have strict order of tags: first herd/ then other tags. Currently there are about 200 ebuilds with different order http://bugs.gentoo.org/show_bug.cgi?id=279206#c4 . Others and I actually make use of the order in metadata.xml. The first entry is the one that will get bugs assignment in bugzilla, and the others will get CCed. So if we're really going with herds first in metadata.xml, could we have an optional attribute - or whatever else you see fit - to convey that _this_ herd/maintainer is the main herd/maintainer? Thanks Rémi
Re: [gentoo-dev] Re: QA last rites for x11-wm/ion
Le 15/12/2009 08:09, Ulrich Mueller a écrit : On Tue, 15 Dec 2009, Peter Hjalmarsson wrote: On the other hand this may be something for treecleaners? A package that has not been bumped for 7 years? With at least three releases since, and a bumprequest open for at least one year? A link to a webside that does not exist? And both its sucessors x11-wm/ion2 and x11-wm/ion3 already punted two years ago. Wasn't there some licence issue with this package, too? That was with ion3 IIRC. Something about the author changing the license from GPL to don't patch ion3 ever without telling me about it and showing me your patches so I can approve them. Or something similar, wikipedia/google might know more than me. As far as the original ion is concerned, the masking seems perfectly in order. If someone wants it, that person can step up and do the work (directly or via proxy). Cheers, Rémi
[gentoo-dev] X license cleaning spree
Dear all, I've started working on one of my to-do items that is usually very low-priority : cleaning up X-related licenses in portage. This is one of the last remains of the Xorg split from a few years ago. X being a big hairy mess, those who managed the transition a few years ago decided that each X package would have its own license file. Not being a lawyer myself, I very much understand why they made that choice. Now that the very few legal issues surrounding Xorg have been ironed out, we can safely clean up all those license files into one : MIT. So here's the list of license that I'm planning on killing because they are - word for word - identical to MIT : fontconfig libdrm libICE libSM libX11 libXau libXaw libXcomposite libXcursor libXdamage libXdmcp libXext libXfixes libXft libXi libXinerama libXmu libXp libXpm libXrandr libXrender libXScrnSaver libXt libXtst libXv libXvMC libXxf86dga libXxf86vm X11 And here's a list of packages that use one or more of these licenses. Please let me know if/when you've fixed them. I'll open bugs next week for the remaining packages, and I'll just fix the rest myself within a month. app-editors/emacs app-editors/emacs-cvs app-emulation/emul-linux-x86-xlibs app-i18n/atokx2 app-i18n/atokx3 app-misc/srm app-text/docbook-sgml-dtd app-text/docbook-xml-dtd app-text/docbook-xml-simple-dtd dev-java/jal dev-libs/libpthread-stubs dev-ml/findlib dev-perl/X11-Protocol games-arcade/pydance games-arcade/pydance-songs media-fonts/efont-unicode media-fonts/sgi-fonts media-gfx/xli media-libs/nas net-misc/curl x11-libs/agg x11-libs/libsvg-cairo x11-libs/openmotif x11-libs/openmotif-compat x11-misc/gbdfed x11-misc/googleearth x11-misc/sux x11-terms/hanterm x11-terms/kterm x11-themes/gentoo-xcursors Help will be most appreciated :) Cheers, Rémi
Re: [gentoo-dev] X license cleaning spree
Le 15/12/2009 10:35, Ulrich Mueller a écrit : On Tue, 15 Dec 2009, Rémi Cardona wrote: And here's a list of packages that use one or more of these licenses. Please let me know if/when you've fixed them. app-editors/emacs app-editors/emacs-cvs x11-libs/openmotif x11-libs/openmotif-compat Done. Thanks :)
[gentoo-dev] Last rites: x11-apps/{ttmkfdir,xfs,xfsinfo}
# Rémi Cardona r...@gentoo.org (13 Dec 2009) # ttmkfdir had multiple QA issues and bugs (bugs #209616, #235354 and #262945) # xfs is completely useless, even on thin clients # and xfsinfo is useless if xfs goes x11-apps/ttmkfdir x11-apps/xfs x11-apps/xfsinfo Cheers, Rémi
Re: [gentoo-dev] ACCEPT_KEYWORDS=~amd64 emerge -avDNut world
Le 10/12/2009 17:22, Samuli Suominen a écrit : In perfect world ~amd64 shouldn't be much different from amd64, so here's a list generated from up-to-date system (stable chroot) from today. If you maintain some of these packages, and it could go stable, please open a stablereq for it. :-) If you don't find this information useful, just move on... no need to reply. Thanks! ;-) The X packages will be handled, as always, with a proper stabilization procedure. Cheers :) Rémi
Re: [gentoo-dev] openrc stabilization todo
Le 04/12/2009 11:41, Mike Frysinger a écrit : On Wednesday 02 December 2009 20:22:07 Jeremy Olexa wrote: Can parallel init script startup be made the default yet? I've been running with it for months and never noticed a problem.. not for stable. no point in proactively shooting our conservative users in the face. let's shoot the unstable ricers first. -mike Sounds like a good first step. +1 from me. Rémi
Re: [gentoo-dev] openrc stabilization todo
Le 03/12/2009 02:22, Jeremy Olexa a écrit : Can parallel init script startup be made the default yet? I've been running with it for months and never noticed a problem.. I've been running it for more than a year on half a dozen boxes, without any issues as well. +1 for making it the default. Thanks
Re: [gentoo-dev] Deprecated eclasses
Le 30/11/2009 05:26, Jonathan Callen a écrit : gst-plugins.eclass ACK on this one, Gilles and I have been meaning to remove it a long time ago. Thanks for cleaning it all up :) Rémi
Re: [gentoo-dev] global USE flag description change: css
Le 15/11/2009 00:16, Doug Goldstein a écrit : The css USE flag currently says: Enables ripping of encrypted DVDs But that really doesn't describe the usage correctly. It enables the ability to READ encrypted DVDs. I'm going to make the change if no one objects. +1, makes perfect sense. Rémi
[gentoo-dev] Last rites: xf86-video-imstt and xf86-video-vermilion
# Rémi Cardona r...@gentoo.org (15 Nov 2009) # Broken since xorg-server 1.5 stabilization # see bugs #248529 and #248531 # Masked for removal in 7 days x11-drivers/xf86-video-imstt x11-drivers/xf86-video-vermilion 'nuff said :) Rémi
Re: [gentoo-dev] QA is unimportant?
Le 09/11/2009 17:30, Patrick Lauer a écrit : Ok, here's the real problem; Unmaintained stuff is unmaintained Patrick, Just piping in to say that dropping a package from portage isn't the end of the world, we have a very good process for it and it has proven to be very effective. Dead packages should be masked : 1) it tells users that no-one among us devs really care about the package. And it's good because we're not lying or pretending to care. I think it's honest of us to admit that some packages are abandoned. Users deserve to know. 2) it sends a crystal-clear message that this package is up for grabs, either by another dev or by a user with a proxy-maintainer. This is yet another good thing because it might encourage users to join our ranks. 3) it allows to effectively clear out cruft, and $deity knows portage is full of it. Faster sync times, fewer security risks, etc. So while of course we're not going to p.mask perl because its sole maintainer has decided to stop working on it, but for _less_ _important_ packages, masking and treecleaning is a *good* thing. And besides, the beauty of CVS is that deleted files are never really gone, so a deleted package can be brought back from the dead in a few minutes. So really, don't feel obliged to touch/bump/fix all unmaintained packages, fix those that you use and treeclean the rest. It'll be for the best. Cheers, Rémi
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
Le 24/10/2009 15:42, Maciej Mrozowski a écrit : If you have any comments, suggestions, important notices regarding this change, please keep discussion in gentoo-desktop mailing list. IMHO, we shouldn't even have desktop/server subprofiles to begin with. I've always considered Gentoo to be an opt-in distro where after a successful install, you end up with a bash prompt and a _means_ of installing new packages. Finding out what USE flags mean and do is part of the Gentoo experience. If we were doing spin-off distros like Ubuntu and Fedora do, then subprofiles would be fine, but we're not. So with my X hat on, I won't be adding any X subprofile. And with my (former?) Gnome hat on, I vote against any gnome subprofile. Cheers, Rémi
Re: [gentoo-dev] Re: [RFC] Splitting desktop profile to KDE and GNOME
Le 26/10/2009 22:58, Richard Freeman a écrit : Gentoo is about choice. No it isn't. Gentoo is about empowering users, giving them the ability and tools to _change_ the distro to _their_ needs. Gentoo does _not_ cater to all the possible needs. This is somewhat off-topic, but it irks me every time I see/hear it, so there. Cheers, Rémi
Re: [gentoo-dev] New ebuild metadata to mark how robust the package is?
Hi Daniel, Le 17/10/2009 01:29, Daniel Bradshaw a écrit : So as I say, it occurs to me that most people probably follow some variation of this selective upgrade method. It might be handy to have some kind of metadata in the ebuilds that can be used to indicate a package that is demanding. Then that flag could be used to highlight the package on a dep tree, or optionally to block the emerge unless the package is specified explicitly. IMHO, we already have the infrastructure for such info. We have elog and news items. Now we (gentoo devs) are finally starting to add news items for bigger updates (gnome, X, java, etc) and that's a good thing. But we definitely cannot and should not use news items for minor upgrades. elog is much better suited for such upgrade notices. However, since elog was put in portage, ebuilds have been using elog/ewarn/einfo _way_ too much. We're now at a point where the elog output at the end of an emerge phase is just _useless_ because of all the noise. And with your metadata proposal, I'm worried the same thing will happen. Devs will enable the troublesome flag for a release, forget to remove it for the next bump and a few months later, half the packages in portage are labeled as such. I really don't want to sound like I want to kill your idea but I'm somewhat doubtful it'll really work given our track record with other such infrastructure. Cheers :) Rémi
Re: [gentoo-dev] News Item: GNOME 2.26 upgrade
Le 06/10/2009 13:02, Mart Raudsepp a écrit : On T, 2009-10-06 at 02:11 +0300, Mart Raudsepp wrote: Hello, See attached news item for consideration. Suggestions on how to improve it, including the text section, very welcome. Attached is a tweaked version with wording fixes from dabbott and author as me instead of team, as I understood to be more appropriate. I will probably wait for further reviews for a couple hours and then commit this and proceed with CCing arch teams for the stabilization work. not handle the desktop. = not handle the desktop's background image But even without this change Reviewed-by: Rémi Cardona r...@gentoo.org Cheers
Re: [gentoo-dev] Re: Xorg 1.6/libxcb 1.4 stabilization news item
Thanks for the wording, I've somewhat made it a bit stronger. @Dev, please ACK or NAK or whatever. Thanks Title: Migration to X.org Server 1.6 and libxcb 1.4 Author: Remi Cardona r...@gentoo.org Content-Type: text/plain Posted: 2009-10-02 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: x11-base/xorg-server-1.6 Display-If-Installed: x11-libs/libxcb-1.4 We're pleased to announce the stabilization of xorg-server-1.6. Users are strongly encouraged to read the following two guides before upgrading: http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml http://www.gentoo.org/proj/en/desktop/x/x11/libxcb-1.4-upgrade-guide.xml
Re: [gentoo-dev] Re: Xorg 1.6/libxcb 1.4 stabilization news item
Le 02/10/2009 09:43, Ulrich Mueller a écrit : On Fri, 02 Oct 2009, Rémi Cardona wrote: We're pleased to announce the stabilization of xorg-server-1.6. Users are strongly encouraged to read the following two guides before upgrading: GLEP 42 says that you should wrap lines at 72 columns, where possible. And apart from the wrapping? Nothing else to add? Cheers, Rémi
Re: [gentoo-dev] Re: Xorg 1.6/libxcb 1.4 stabilization news item
Le 02/10/2009 10:22, Petteri Räty a écrit : Thus, at least 72 hours before a proposed news item is committed, it must be posted to the gentoo-dev mailing list and Cc:ed to p...@gentoo.org (exceptions may be made in exceptional circumstances). Any complaints — for example regarding wording, clarity or accuracy — must be addressed before the news item goes live. p...@gentoo.org hasn't been CC:ed as far as I see. Josh now has commented on it. May I request a faster commit time since I didn't expect Samuli to stabilize everything so quickly? Rémi
[gentoo-dev] Xorg 1.6/libxcb 1.4 stabilization news item
Hi guys, Could anyone write up a one-liner news item for the xorg-server 1.6 stabilization with there 2 upgrade guides : http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml http://www.gentoo.org/proj/en/desktop/x/x11/libxcb-1.4-upgrade-guide.xml I tried figuring out how to write one myself, but failed miserably because of the entirely non-intuitive GLEP. Basically, all stable users should see that news item. Thanks in advance to the benevolent soul who will write it and commit it :) Thanks
[gentoo-dev] Last rites: dev-python/pyxf86config and dev-python/rhpxl
# Rémi Cardona r...@gentoo.org (24 Sep 2009) # Both require xorg-server's libxf86config library which is busted # and they both have no maintainer. See bug #222683 # Masked for removal in 30 days dev-python/pyxf86config dev-python/rhpxl Cheers, Rémi
[gentoo-dev] Last rites: opengl-manpages, xorg-docs, xorg-sgml-doctools
# Rémi Cardona r...@gentoo.org (19 Sep 2009) # Outdated and useless X doc packages # Masked for removal in 30 days app-doc/opengl-manpages app-doc/xorg-sgml-doctools app-doc/xorg-docs Before anyone asks, opengl-manpages is a snapshot for Dec '00. The online documentation at opengl.org is much much more up-to-date. Cheers, Rémi
Re: [gentoo-dev] EAPI and system packages
Le 20/09/2009 02:31, Ryan Hill a écrit : If not, when can we drop support for old EAPIs? Your opinions please. Let's drop it now. We've waited long enough. Portage with EAPI=2 has been stable for more than a year. Rémi
Re: [gentoo-dev] Re: [RFC] Add operator + for licenses (EAPI-4 ?)
Le 06/09/2009 02:34, Thomas Anderson a écrit : Ciaran's really not making homework up for gentoo. Why, remi stated himself that we have homework to do(and we sometimes don't do that homework) I did, but I also stated upstream might have some homework to do themselves. Here's a list of things that : - COPYING automagically copied by automake (that would make the file be GPL-2+ or GPL-3+) - code stolen from other projects under a non-compatible/viral license - bundled libraries - code that's so old, no-one really knows what the original license (XFree86/Xorg) is or who the copyright holders are (Mozilla) And I haven't even had my morning coffee yet. Even if _we_ do our homework, all those reasons above might mislead us into thinking a package has license ABC, while in fact it's under license ABC+ and XYZ. I don't see how a new EAPI will help us with all the aforementioned issues. And for the proposed LICENSE sets to work correctly, the whole tree needs to be audited, and each new _version_ of each package needs to be rigorously checked if we want to provide something users can _trust_. Cheers, Rémi
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: www-plugins/gnash
Le 05/09/2009 11:25, Duncan a écrit : [...] This is off-topic for gentoo-dev. Please continue this discussion in private. Thanks Rémi
Re: [gentoo-dev] Re: [RFC] Add operator + for licenses (EAPI-4 ?)
Le 03/09/2009 23:27, Mounir Lamouri a écrit :
But the content of the license is the same. That only means you can use
a newer one.
I mean we do not need a new license file for that. It's up to upstream
to write somewhere if it's GPL-2 or GPL-2+, am I right ?
Yes, that's for upstream to figure out. For instance, the kernel is
GPL-2 only while some other pacakges are 2+.
I don't want to sound like an ass, but that's why I think we shouldn't
bother too much with LICENSE and all that stuff.
We're not _lawyers_. None of us can guarantee that :
1) the LICENSE field in our ebuilds are correctly set according to what
upstream says.
2) that the actual code of the package is indeed under that license and
not tainted by some other code.
For instance, I'm still working on migrating all the X11 packages to the
MIT license (mainly for cleaning purposes), but in fact, each and
every package should have its own license file (like today) because the
MIT license requires that we acknowledge all major contributions to the
code. Therefore, using a template like ${PORTAGE}/licences/MIT does is
probably not a good idea from a legal point of view.
And the X code being over 15 years old, only God knows who we should be
thanking for this million lines of code.
While you're idea is very nice on paper, actually doing it requires much
_much_ more work than just adding operators and sets to portage.
Rémi
Re: [gentoo-dev] Re: [RFC] Add operator + for licenses (EAPI-4 ?)
Le 04/09/2009 20:52, David Leverton a écrit : Is that really a problem? To me, it's not. :) I admit to not being around for the original design decisions, but I would assume that the purpose of having LICENSE in ebuilds is to tell users what licence the package is under (whether or not it's accurate is a different matter), and the purpose of having the licences themselves in the tree is so that it's easy for users to look them up and decide whether they want to accept the conditions or not. For that purpose, the exact list of credits is irrelevant. That was just an example to show that unless we go through a precise and thorough audit of all the packages we offer, the LICENSE variable is _informational_ at best. Having tools to manipulate those variables is very misleading since users will (rightfully) assume that we've done our homework and that upstream did too. I don't intend to stop anyone from creating new tools, but I just want us all to realize the limits of what is being done here. Cheers, Rémi
[gentoo-dev] Last rites: www-plugins/gnash
# Rémi Cardona r...@gentoo.org (04 Sep 2009) # Masked for removal in 60 days, old and unmaintained in Gentoo # Uses removed VIDEO_CARDS flag (see bug #282981) www-plugins/gnash Cheers, Rémi
[gentoo-dev] Re: [gentoo-dev-announce] Last rites: www-plugins/gnash
Le 04/09/2009 22:41, Andrew John Hughes a écrit : So there'll be no Free Flash support in Gentoo any more? I hope someone will pick this up, this is a high priority FSF project after all. There's media-libs/swfdec that's still offically maintained by the Gnome herd. As far as gnash is concerned, it can still be saved by a willing maintainer. Nothing more, nothing less. Cheers, Rémi
Re: [gentoo-dev] Re: [RFC] Add operator + for licenses (EAPI-4 ?)
Le 03/09/2009 23:10, Mounir Lamouri a écrit : Duncan wrote: Sebastian Pipping posted on Tue, 01 Sep 2009 04:21:49 +0200 as excerpted: However I do notice that GPL-2+ could make things easier. Why not introduce a license group for it like @GPL-2+ or so, instead? That would be transparent and use existing means. I've always thought Gentoo needed plus versions of the versioned licenses, anyway. GPL-2, GPL-2+, GPL-3, and GPL-3+, should all be different licenses, because really, they are. AFAIK, GPL-2 and GPL-2+ are not different, may you tell me more about that ? GPL-2+ means GPL-2 GPL-3 GPL-4 ... Not quite the same thing as just GPL-2 Rémi
Re: [gentoo-dev] [RFC] Add operator + for licenses (EAPI-4 ?)
Le 01/09/2009 00:12, Mounir Lamouri a écrit : Hi, As you should know, GLEP 23 [1] introduced USE flags conditions in LICENSE variable and || operator in addition of licenses groups and ACCEPT_LICENSE variable. [1] http://www.gentoo.org/proj/en/glep/glep-0023.html /me still thinks LICENSE should be informational _at_best_. Users who rely on LICENSE to build an FSF-approved system will simply be mislead. If we want to support this sort of things properly, we should have a treewide license audit. Anything short of that will just be a disservice to our users. Cheers, Rémi
Re: [gentoo-dev] New 10.0 LiveDVD release enhancements
Le 23/08/2009 11:02, Chip Parker a écrit : On Sun, Aug 23, 2009 at 12:07 AM, Alexey Shvetsovale...@gentoo.org wrote: Hi all! Also i think it wil be good idea to include parted into liveDVD since its only tool that support gpt partition tables =) +1 On this one. Since parted comes with partprobe, which is really nice when you want to change the partition tables on a live box. Will one of you file a bug assigned to the relevant team? (probably releng). Feature requests are handled through bugzilla. -dev is most just a black hole for this sort of things. Thanks
Re: [gentoo-dev] New global USE flag mp4
Samuli Suominen a écrit : description: Support for MP4 container format [+ C ] mp4 (media-sound/amarok): Build the TagLib plugin for writing tags in Mp4 container files (m4a). Please note that by enabling this USE flag, the resulting package will not be redistributable, as it links to media-libs/libmp4v2, distributed under a GPL-incompatible license. amarok could have USE=bindist too, couldn't it? Thanks
Re: [gentoo-dev] Unmasking of libxcb 1.4 and related libs in !2008.0 profiles
Paul de Vrieze a écrit : As a service to users, you might want to create an empty library: touch foo.c gcc -shared foo.c -o libxcb-x11.so.0.0.0 That's all Like Samuli said, it's a hack and doing that would be wrong. I will not trade short-term peace of mind for a long term hell for whoever will be maintaining X after me. Just like the expat soname change, we have to remove the band-aids at some point, even if it hurts. Rémi
Re: [gentoo-dev] Re: Re: Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
Le 18/08/2009 03:30, Steven J Long a écrit : [snip] Steven, This thread was dead for more than 4 days. Yet you pick it up and you try to pick a fight with Ciaran. I for one am tired of your behavior on this list and I will not hesitate to contact UserRel to get you out of this list if you don't settle down and start acting like an adult. Now step away from this thread. Thanks Rémi
[gentoo-dev] Unmasking of libxcb 1.4 and related libs in !2008.0 profiles
Hi all, Just a quick heads up that I have just unmasked x11-libs/libxcb-1.4 and its companion libraries in all profiles _except_ 2008.0. As some of you have already found out, since 1.2, libxcb stopped shipping a very specific library: libxcb-xlib.so. This library was only ever meant to be used internally by libX11, but due to libtool's infamous .la files, the removal of this library may cause some headaches during the upgrade. Here are a few steps to fix the breakage : 1) make sure that /usr/lib/libxcb-xlib.* are gone. Portage 2.2_rc* users _should_ remove it as well. 2) run /usr/portage/x11-libs/libxcb/files/xcb-rebuilder.sh to fix .la files. If the tool reports broken packages, please read on. If not, lucky you, your system is ready to go :) 3) run the following one liner to rebuild a simple, yet effective, subset of potentially broken packages. Do not worry, packages you don't have installed will not be installed. emerge --oneshot --nodeps \ $(for i in x11-proto/ x11-libs/libxcb x11-libs/libX11 x11-libs/libXext \ x11-libs/libX x11-libs/xcb-util x11-libs/cairo \ x11-libs/pango x11-libs/gtk+ gnome-base/libgnomeui \ x11-libs/qt-gui; do \ qlist -IC $i; \ done) -pv 4) use revdep-rebuild (from app-portage/gentoolkit) to finish fixing the rest of your system. I hope those instructions are clear enough. If not, please don't hesitate to let me know. Oh and if someone with sufficient guidexml skills could xmlify these instructions, I would be very thankful :) Thanks for reading this. Rémi
Re: [gentoo-dev] Last rites: 14 X input drivers
Le 13/07/2009 19:22, Robert Buchholz a écrit : We're using the x11-drivers/xf86-input-microtouch for a cash register. It works fine, but I think the machine is still on Xorg Server 1.3. I don't have the capacity to maintain this driver myself, but it seems bug #276615 has a patch, so I wonder why it needs to be abandoned. Whom exactly shall I contact upstream about the deprecation? Well, to start off, you might want to check if your hardware is now supported directly by the kernel. If that's the case, then you can use xf86-input-evdev which will make your life much easier. But TBH, I really don't know much about writing X drivers. All I can offer is to commit patches upstream and maybe make tarballs. My suggestion for now is to create a - ebuild of the microtouch driver inside the x11 overlay and make it point to the latest commit that has a chance of working: before the one that adds the AC_MSG(). If that doesn't work, you might want to get in touch with upstream X people via the xorg or xorg-devel mailing lists (resp. at fd.org and x.org). Hope that helps Rémi
[gentoo-dev] Last rites: 14 X input drivers
# Rémi Cardona r...@gentoo.org (13 Jul 2009) # broken and unmaintained by upstream, masked for removal in 30 days # see bug #277521 for more info x11-drivers/xf86-input-calcomp x11-drivers/xf86-input-digitaledge x11-drivers/xf86-input-dmc x11-drivers/xf86-input-dynapro x11-drivers/xf86-input-elo2300 x11-drivers/xf86-input-jamstudio x11-drivers/xf86-input-magellan x11-drivers/xf86-input-magictouch x11-drivers/xf86-input-microtouch x11-drivers/xf86-input-palmax x11-drivers/xf86-input-spaceorb x11-drivers/xf86-input-summa x11-drivers/xf86-input-tek4957 x11-drivers/xf86-input-ur98 All of those are marked as unsupported by upstream and their git code no longer builds (./configure was made to abort on purpose). More will probably come later, but this is the first round of low-hanging fruits. Thanks Rémi
Re: [gentoo-dev] Last rites: 14 X input drivers
Le 13/07/2009 16:56, Marijn Schouten (hkBst) a écrit : Why were they marked unsupported by upstream? Is there a replacement, are they no longer needed, some other reason? Some are now supported by the kernel. For the rest, nobody owns the hardware anymore. (ur98 is for a head-tracker... does anyone own that?) All have in common that they've been broken (in portage) for many months and no-one noticed until Sabayon folks started doing tinderbox builds :) If someone is sincerely impacted by this, please get in touch with upstream (CC me) because most of those drivers could come back to life with very little work. They mostly need someone testing them. But as they stand now, I'm getting rid of them. Cheers, Rémi
Re: [gentoo-dev] Re: Re: A Little Council Reform Anyone?
Le 07/07/2009 18:20, Ciaran McCreesh a écrit : I would be entirely happy if you could get the people whose stated aim is to disrupt PMS and / or third party package managers to stop poisoning the atmosphere. Then _please_ for the love of God just _ignore_ him. Thank you
Re: [gentoo-dev] About time to unify cdda and cdaudio USE flags and make the remaining one global?
Le 05/07/2009 03:12, Sebastian Pipping a écrit : Lars Wendler wrote: So what do you think? Should we convert the bug into a tracker and open bugs for any package using the USE-flag that should be converted into the other one? +1 from me, sounds reasonable. Ditto, sounds good. And now for some bikeshedding fun, which flag are we going to keep? ;) Cheers, Rémi
Re: [gentoo-dev] A Little Council Reform Anyone?
Ned Ludd a écrit : [snip, lots of insightful stuff I either agree with or don't really understand] So lets have some damn fun again !...@#$ _That_ I whole heartedly agree with. Please, all of you in the new council, try to keep this in mind :) Thanks Rémi
[gentoo-dev] Enough about GLEP5{4,5}
Seriously, let's stop. This endless debate has gone on for waaay too long and it is just plain spam now. I'm just too tired of reading those endless discussions that are going _nowhere_. Let's just all agree we've failed to reach a consensus and let's spend time on something else. Surely I must not be the only one who's completely bothered by those debilitating threads? Cheers, Rémi
Re: [gentoo-dev] New app-eselect category?
Le 26/05/2009 22:43, Sérgio Almeida a écrit : Hello, There isn't yet. The code is still pretty ugly and I'm still refactoring to the new architecture before I can make it public (or even officially git it). I will post it on this mailing list as soon as experimentations are possible. Please do try to make it available somewhere (even if only with a dumb live - git ebuild) so that we can actually try it out. I can't remember when was the last Gentoo GSoC project that we were actually able to use/see/build... Good luck for your Summer of Code :) Rémi
Re: [gentoo-dev] about gold bugs
Le 15/05/2009 23:20, Ryan Hill a écrit : Could I ask that people stop closing bugs against the gold linker with such classy witticisms as patches welcome. Honestly, a little heads up before gold hit portage would have been nice too. I already had 2 bugs with gold-related issues even before I had realized that binutils had gained a new USE flag... I honestly thought people were testing gold from an overlay or self-made ebuilds. But point taken, gold bugs are toolchain bug :) Best of luck with gold, I'm eager to try it out! Cheers, Rémi
Re: [gentoo-dev] Last rites: a bunch of X stuff no one should be using since 1994
Le 09/05/2009 13:05, Marijn Schouten (hkBst) a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 � wrote: # R�mi Cardonar...@gentoo.org (09 May 2009) # XPrint is dead, long live XPrint For kings I understand this comment, but can you explain how it applies to XPrint? The replacement for XPrint would be cairo which has PostScript and PDF output backends. FTR, the actual XPrint server has been removed from the main Xorg repository. It's still available in its own repo (a fork of the main repo just before the removal), but it's actively *un*maintained. Cheers :) Rémi
Re: [gentoo-dev] Project summaries
Le 06/05/2009 08:49, Christian Faulhammer a écrit : Hi, any project lead/member can post an answer to this mail for a status report: X11 Herd Status Update Short term or recently done : - 1.5.3-r5 went stable (I'm sure y'all noticed) - there will be another 1.5 stable server within a few weeks - 1.6.x will go into ~arch pretty soon - alpha is pretty much the only arch that doesn't have 1.5 keyword but thanks to frequent poking, things should change pretty soon - 1.3 and 1.4 will get p.masked as soon as alpha and arm stabilize 1.5.3, - 1.3 will get treecleaned during the summer, 1.4 maybe a bit later... - the X11 overlay now has support for the nouveau driver and Gallium (thanks to a few external but essential contributors) Medium term : - libxcb 1.2 will be moved to portage once we figure out a sane way to handle the disappearance of libxcb-x11.so. For those who haven't heard or seen what happens during the upgrade, let's just say that the upgrade from expat 1.95 to 2.0 was a walk in the park compared to this. - continue cleaning up useless libs and protos Longer term : - major Docs overhaul, what we have now is a complete mess. Any help with this is greatly appreciated. See [1] for a short todo list. - try to keep up with upstream X, even if it means upsetting some users. Actually forcing folks to upgrade to 1.5 has been very beneficial, a lot of bugs were uncovered and reported upstream. Intel Driver Status Update - 2.6.3 is the current stable - 2.7.0 is still p.masked, 2.7.1 will likely go in ~arch when it's out - The next stable driver will probably be 2.8 once xorg-server 1.6 is in portage and deemed stable enough. - The upcoming 2.8 branch will have a lot less code and options (no more DRI1, XAA, EXA, ...), making it easier to maintain and to use. Cheers, Rémi
Re: [gentoo-dev] Project summaries
Le 10/05/2009 23:43, Gokdeniz Karadag a écrit : It seems like you have forgotten the link. [1] https://bugs.gentoo.org/show_bug.cgi?id=267769 Thanks
[gentoo-dev] Last rites: a bunch of X stuff no one should be using since 1994
# Rémi Cardona r...@gentoo.org (09 May 2009) # Low-Bandwidth X and the X Proxy Management stuff has been declared # dead since last century. All of those will be gone in 30 days x11-apps/lbxproxy x11-apps/proxymngr x11-apps/xfindproxy x11-apps/xfwp x11-apps/xrx x11-proto/xproxymanagementprotocol # Rémi Cardona r...@gentoo.org (09 May 2009) # XPrint is dead, long live XPrint # nothing in portage uses those apps and libs anymore # will be removed in 30 days (see bug #264982 for rationale) x11-apps/xplsprinters x11-libs/libXprintAppUtil x11-libs/libXprintUtil If anyone cares, yell now. Otherwise, they will be gone from portage in 30 days. To those who believe XPrint and Low-Bandwidth X are still useful: get yourself a clue :) Cheers, Rémi
Re: [gentoo-dev] Re: Training points for users interested in helping out with ebuild development
Petteri Räty a écrit : Currently we really don't need to fail that many people as those who end up at that point in the process almost always have good enough skills as they have contributed via overlays for quite a while. Ditto on that. Most recruits I've been actively watching these past few months (Ford_prefect, nirbheek and now mrpouet) have all been trained that way : - they send us patches for ebuilds - we tell them how they are wrong and they fix 'em - after a while, they get access to the overlay - we still whack them with the cluebat when they break stuff But the whole overlay process is very positive because it's hands-on experience. The ebuild quiz is usually a very good time for them to reflect on all the work they did and they understand more why we had to whack them a few times. Things make much more sense for them. All in all, I would say overlays + the ebuild quiz make for very good recruits. I have yet to be disappointed by this recruitment process. Cheers, Rémi
Re: [gentoo-dev] On git and pushing official gentoo branches
Le 26/04/2009 23:55, Gilles Dartiguelongue a écrit : Hello list, As many of you might already know, gnome switched to git about 2 weeks ago so I'd like to take a pick at what people do concerning upstream using git. How do you present patches you maintain for gentoo to upstream ? Own maintained git server, gentoo hosted git, others ? I've been thinking about something similar for most of X and FreeDesktop's packages which are pretty much all hosted using git as well. Ideally, something like Ubuntu's Launchpad's DVCS capabilities would help. But that's probably wishful thinking on my part. Cheers, Rémi
Re: [gentoo-dev] EAPI-3 draft: slot operator support
Mart Raudsepp a écrit : Hello, This thread is for any discussion about the slot operator support item in EAPI-3 draft. Could anyone actually give a good reason for slot operators? What packages would have a _clear_ benefit from using them? I'm asking for an actual list of packages, not just some package that may exist in a parallel universe. To me it just looks like it's overly complicated and it makes my eyes bleed. Rémi
