[gentoo-dev] Adding slot and subslot deps to others' packages
Hi, Few months ago I have written a small FAQ on how to use slots and subslots for library dependencies properly [1]. However, today I see that most of the developers didn't care to properly update their packages and when I introduced binary compatibility slot in libgcrypt, I had my hands full of work fixing the mess for a single package. Honestly, it's PITA to update and commit a few dozen ebuilds just to modify a single dependency. Plus sometimes portage's dynamic-deps no longer work so I'd have to revbump all the packages as well to be 100% correct. And the sole fact that I'm fixing just one dep when there's a dozen libraries more that may need fixing in the future... So, I'm asking: would you mind if I started taking random packages and updating the library dependencies (whenever they are clear) to use slot :0 (in EAPI 1..4) and :0= (in EAPI 5) as appropriate? [1]:http://article.gmane.org/gmane.linux.gentoo.devel/88541 -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?
On 2014.02.28 14:44, Samuli Suominen wrote: > > On 28/02/14 16:18, Tom Wijsman wrote: > > On Fri, 28 Feb 2014 15:28:30 +0200 > > Samuli Suominen wrote: > > > >> It would be very helpful if INSTALL_MASK could be overriden from > an > >> ebuild, ... > > What is the intended goal? Can you give an example? > > - User has INSTALL_MASK="/lib/systemd" > - Ebuild has INSTALL_MASK_OVERRIDE="/lib/systemd/systemd-udevd > /lib/systemd/network" > - Portage's default is to respect ebuild first, then users setting, > unless he changes INSTALL_MASK_ORDER to respect his > > I completely agree using INSTALL_MASK is 100% responsibility of the > user > setting it, it's like blind 'rm -f', but some people > don't agree and keep attacking me. > I'm using the word attacking because it's constant, relentless, > repeating and I don't see an end to it. I believe Poly-C just > proofed that point in this thread. > > > Samuli, You can't win this one. Consider ln -s /dev/null /lib/systemd/ or whatever. It achieves the same thing and you can't override it unless you also remove the symlink. INSTALL_MASK means I_KNOW_WHAT_IM_DOING_AND_AM_PREPARED_TO_KEEP_THE_PIECES systemd and the components it has sucked in has become the centre of a religious war with Zelots on both sides. All an INSTALL_MASK_OVERRIDE would do is escalate the war. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpLFfXk4wQ0s.pgp Description: PGP signature
[gentoo-dev] New clone type and local git mirror support in git-r3
Hello, users and developers. I've just committed a large patch set that improves the compatibility and usability of git-r3.eclass. The two major highlights are: 1. the semi-working and problematic shallow clone support has been replaced by more generic and better designed EGIT_CLONE_TYPE system, 2. local git mirror support has been added for people that are using live ebuilds on multiple Gentoo systems. First of all, if you have EGIT_NONSHALLOW set somewhere, you can remove it. The shallow clones are no longer the default, and this variable is not used anymore. Instead, you may want to set EGIT_CLONE_TYPE in make.conf to one of the three supported clone types: 'mirror', 'single' (the default) or 'shallow'. The 'mirror' mode clones all branches & tags in the remote repository, making the local copy suitable for further cloning or reuse as a git mirror. The 'single' mode clones only the requested branch or tag, along with complete history (and tags that point on fetched commits). This mode is the default since it provides all the advantages of git while avoiding fetching unnecessary branches. The 'shallow' mode tries to clone the minimum number of objects necessary. It is very space-efficient yet may cause problems (and therefore ebuilds may override it). Since it doesn't fetch the complete branch history, some features won't be available (like 'git describe' won't be able to find an earlier tag). The ebuilds that do not support shallow clones may use complementary EGIT_MIN_CLONE_TYPE variable to enforce another type of clones. For example, all ebuilds using Google Code git repositories will need to set EGIT_MIN_CLONE_TYPE=single due to server limitations. If shallow clones cause only minor inconveniences (like non-pretty version number that doesn't cause any more issues), developers are encouraged not to force 'larger' clones. Since setting EGIT_CLONE_TYPE is considered an expert feature, developers are not required to retroactively test their ebuilds with shallow clones. Instead, they can wait till one of the users using it reports an issue. Setting a local git mirror is pretty straightforward. You need to share the 'git3-src' directory used to store local clones (preferably with EGIT_CLONE_TYPE=mirror) via one of the supported git transports, and then set EGIT_MIRROR_URI to the URI corresponding to that directory. For example, if you used the HTTP transport and aliased the git3-src directory to /git, your EGIT_MIRROR_URI would look like: EGIT_MIRROR_URI=http://localserver/git/ Any questions or problems shall arise, please don't hesitate to reply to this mail, to gentoo-dev@. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Adding slot and subslot deps to others' packages
On Sun, 2 Mar 2014 09:37:22 +0100 Michał Górny wrote: > Few months ago I have written a small FAQ on how to use slots > and subslots for library dependencies properly [1]. However, today > I see that most of the developers didn't care to properly update their > packages and when I introduced binary compatibility slot in libgcrypt, > I had my hands full of work fixing the mess for a single package. How about you file a tracker bug report for each library package, and then file bug reports per package using that dependency blocking the tracker bug? jer
Re: [gentoo-dev] Adding slot and subslot deps to others' packages
Dnia 2014-03-02, o godz. 16:45:03 Jeroen Roovers napisał(a): > On Sun, 2 Mar 2014 09:37:22 +0100 > Michał Górny wrote: > > > Few months ago I have written a small FAQ on how to use slots > > and subslots for library dependencies properly [1]. However, today > > I see that most of the developers didn't care to properly update their > > packages and when I introduced binary compatibility slot in libgcrypt, > > I had my hands full of work fixing the mess for a single package. > > How about you file a tracker bug report for each library package, and > then file bug reports per package using that dependency blocking the > tracker bug? Excuse me but are you serious? I'm supposed to report a faftillion of bugs? Filing them will take more time than fixing the packages, not to mention all the time wasted on handling responses and all other noise. But it seems that Gentoo developers lately prefer noise over real work. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: Adding slot and subslot deps to others' packages
On 03/02/2014 07:37 PM, Michał Górny wrote: > Hi, > > Few months ago I have written a small FAQ on how to use slots > and subslots for library dependencies properly [1]. However, today > I see that most of the developers didn't care to properly update their > packages and when I introduced binary compatibility slot in libgcrypt, > I had my hands full of work fixing the mess for a single package. > > Honestly, it's PITA to update and commit a few dozen ebuilds just to > modify a single dependency. Plus sometimes portage's dynamic-deps > no longer work so I'd have to revbump all the packages as well to > be 100% correct. And the sole fact that I'm fixing just one dep when > there's a dozen libraries more that may need fixing in the future... Please carefully consider whether a revbump is unconditionally required for every situation. Pinning a dependency to SLOT 0 will be picked up by dynamic-deps, and if the user has it turned off it is likely that more building will be caused by the rebuilds versus the new binary compatibility slot. dynamic-deps does not apply to the subslot dependency operator, but revbumping to add it will just cause the user to have to build the package twice - once for the revbump and once when the subslot changes. > > So, I'm asking: would you mind if I started taking random packages > and updating the library dependencies (whenever they are clear) to use > slot :0 (in EAPI 1..4) and :0= (in EAPI 5) as appropriate? > > [1]:http://article.gmane.org/gmane.linux.gentoo.devel/88541 > For adding an explicit slot after a binary compatibility slot is introduced, I think that is fine. I have been doing that for virtual/jpeg as I come across them (AFAIK no effort was made to fix this when it was introduced) and I have never had any complaints.
Re: [gentoo-dev] Adding slot and subslot deps to others' packages
On Sun, 2 Mar 2014 16:52:22 +0100 Michał Górny wrote: > > How about you file a tracker bug report for each library package, > > and then file bug reports per package using that dependency > > blocking the tracker bug? > > Excuse me but are you serious? Sure. > I'm supposed to report a faftillion of bugs? If the transition is that large and involves so many packages/maintainers, then sending a single "FAQ" to a general mailing list was apparently not enough. > Filing them will take more time than fixing the packages, > not to mention all the time wasted on handling responses and all other > noise. Apparently 19 weeks, 4 days, 3 hours and 2 minutes (and counting)[1] wasn't enough time? > But it seems that Gentoo developers lately prefer noise over real > work. Wow. [slow clap] jer [1] http://article.gmane.org/gmane.linux.gentoo.devel/88541
Re: [gentoo-dev] Re: Adding slot and subslot deps to others' packages
Dnia 2014-03-03, o godz. 03:04:41 Michael Palimaka napisał(a): > On 03/02/2014 07:37 PM, Michał Górny wrote: > > Hi, > > > > Few months ago I have written a small FAQ on how to use slots > > and subslots for library dependencies properly [1]. However, today > > I see that most of the developers didn't care to properly update their > > packages and when I introduced binary compatibility slot in libgcrypt, > > I had my hands full of work fixing the mess for a single package. > > > > Honestly, it's PITA to update and commit a few dozen ebuilds just to > > modify a single dependency. Plus sometimes portage's dynamic-deps > > no longer work so I'd have to revbump all the packages as well to > > be 100% correct. And the sole fact that I'm fixing just one dep when > > there's a dozen libraries more that may need fixing in the future... > Please carefully consider whether a revbump is unconditionally required > for every situation. Just to be clear, I'm not going to revbump the packages now. I'd like to fix all the dependencies early enough so that we wouldn't have to revbump them when we introduce compat slots. > > So, I'm asking: would you mind if I started taking random packages > > and updating the library dependencies (whenever they are clear) to use > > slot :0 (in EAPI 1..4) and :0= (in EAPI 5) as appropriate? > > > > [1]:http://article.gmane.org/gmane.linux.gentoo.devel/88541 > > For adding an explicit slot after a binary compatibility slot is > introduced, I think that is fine. I have been doing that for > virtual/jpeg as I come across them (AFAIK no effort was made to fix this > when it was introduced) and I have never had any complaints. I want to do this *before*, for all potential packages. That is, just fix all the stuff at once instead of fixing again and again every time a new library is modified. Committing to CVS has more overhead than adding the slot. So it's better to add slots to all deps rather than one-by-one. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Adding slot and subslot deps to others' packages
Am Sonntag, 2. März 2014, 16:45:03 schrieb Jeroen Roovers: > On Sun, 2 Mar 2014 09:37:22 +0100 > > Michał Górny wrote: > > Few months ago I have written a small FAQ on how to use slots > > and subslots for library dependencies properly [1]. However, today > > I see that most of the developers didn't care to properly update their > > packages and when I introduced binary compatibility slot in libgcrypt, > > I had my hands full of work fixing the mess for a single package. > > How about you file a tracker bug report for each library package, and > then file bug reports per package using that dependency blocking the > tracker bug? I see your point. However please read this beautiful document for the ensuing mess (where things were done accordingly): https://bugs.gentoo.org/show_bug.cgi?id=455900 [For the record, upstream ICU devs recommend to rebuild reverse dependencies even after patch release updates to ensure stability. This was discussed on their mailing list some time ago. I'm not going to comment on whether that is sane or not, but we have to work with it. Now what do you prefer, randomly crashing packages or an additional rebuild?] -- Andreas K. Huettel Gentoo Linux developer (council, kde) dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] Re: FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
Everyone on this list really except perhaps Duncan really needs to learn to trim quotess. Kthx. Gilles Dartiguelongue wrote: > Sure at some point you have to make things evolve but this upstream > solution simply isn't nice for its users. That may be, but I don't think it's a distribution's responsibility to try to own that problem. //Peter
Re: [gentoo-dev] Adding slot and subslot deps to others' packages
On Sun, 2 Mar 2014 17:34:36 +0100 "Andreas K. Huettel" wrote: > > How about you file a tracker bug report for each library package, > > and then file bug reports per package using that dependency > > blocking the tracker bug? > > I see your point. However please read this beautiful document for the > ensuing mess (where things were done accordingly): > https://bugs.gentoo.org/show_bug.cgi?id=455900 That's not a tracker bug, it's the exact opposite: CC everyone involved and hope the bug gets resolved at some point. It has the same problems as an e-mail to a general mailing list (like the one we are responding to now); entirely unlike a tracker bug would have. jer
Re: [gentoo-dev] Adding slot and subslot deps to others' packages
On Sun, Mar 2, 2014 at 10:45 AM, Jeroen Roovers wrote: > On Sun, 2 Mar 2014 09:37:22 +0100 > Michał Górny wrote: > >> Few months ago I have written a small FAQ on how to use slots >> and subslots for library dependencies properly [1]. However, today >> I see that most of the developers didn't care to properly update their >> packages and when I introduced binary compatibility slot in libgcrypt, >> I had my hands full of work fixing the mess for a single package. > > How about you file a tracker bug report for each library package, and > then file bug reports per package using that dependency blocking the > tracker bug? > That is certainly the conservative way to handle this, and it seems like a lot more work. This seems like a QA project. Perhaps we could get the QA team to make a couple for decisions? Firstly, do you agree that we should migrate library dependencies as mgorny has described? Secondly, can we grant developers the license to make these changes outside of the normal "file-a-bug" workflow as an efficiency measure? If there are any reasonable objections (besides maintainer territorial-ism), of course the QA team should consider them.
Re: [gentoo-dev] Re: FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On Sun, Mar 02, 2014 at 05:49:59PM +0100, Peter Stuge wrote: > Gilles Dartiguelongue wrote: > > Sure at some point you have to make things evolve but this upstream > > solution simply isn't nice for its users. > > That may be, but I don't think it's a distribution's responsibility > to try to own that problem. This is my point exactly. Patrick's proposal is that we make this policy that all config files belong in /etc a distro policy, including patching upstream software to force it to conform. If we make this a distro policy and upstream rejects it, there will always be a lot of work downstream that is imo unnecessary. William signature.asc Description: Digital signature
Re: [gentoo-dev] Adding slot and subslot deps to others' packages
On Sun, 2 Mar 2014 12:32:05 -0500 Mike Gilbert wrote: > On Sun, Mar 2, 2014 at 10:45 AM, Jeroen Roovers > wrote: > > On Sun, 2 Mar 2014 09:37:22 +0100 > > Michał Górny wrote: > > > >> Few months ago I have written a small FAQ on how to use slots > >> and subslots for library dependencies properly [1]. However, today > >> I see that most of the developers didn't care to properly update > >> their packages and when I introduced binary compatibility slot in > >> libgcrypt, I had my hands full of work fixing the mess for a > >> single package. > > > > How about you file a tracker bug report for each library package, > > and then file bug reports per package using that dependency > > blocking the tracker bug? > > > > That is certainly the conservative way to handle this, and it seems > like a lot more work. Not managing the migration is apparently a lot of work, since the work isn't being done "voluntarily". Managing the migration might seem like a lot of work, but at least it allows you to track progress properly and tick off finished tasks, while in the mean time everyone involved gets informed, and perhaps gets their bugs fixed for them quicker. > This seems like a QA project. Perhaps we could get the QA team to make > a couple for decisions? Wow, that would make it a *lot* of work. > Firstly, do you agree that we should migrate library dependencies as > mgorny has described? There is no agreement on whether it should even be done? > Secondly, can we grant developers the license to make these changes > outside of the normal "file-a-bug" workflow as an efficiency measure? People handling the sub-SLOT migration for dev-libs/libgcrypt would probably know better what they are doing than the package maintainers, so I see no reason for QA to "grant licenses". > If there are any reasonable objections (besides maintainer > territorial-ism), of course the QA team should consider them. That's back to the "agreement" bit, I guess. Honestly, setting up a tracker and blocking it with bugs about packages which someones-sub-SLOT-checking-script has vetted to be involved could be done in less than a day (for the hundred or so packages that depend on dev-libs/libgcrypt). It doesn't need some QA team to study in depth -- it needs a couple of volunteers to do the checks and file the bug reports. jer
Re: [gentoo-dev] Re: FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On Sat, Mar 1, 2014 at 1:31 PM, Alec Warner wrote: > > gconf, dconf, polkit, dbus, all do stuff like this. I actually find the > solution somewhat elegant from my side as a sysadmin. > I think the "right approach" depends on the degree to which the file requires tweaking. For 99% of users, udev requires no touching at all (though the persistent network names drive me nuts so I touch it anyway). If you do touch it most likely you're just adding one rule, or overriding a rule or two. That makes the approach it uses of defaults and overrides really nice, because you don't have a ton of cruft to merge in /etc - the only code that is present is the stuff that matters. For 99% of users, xorg.conf needs little touching at all (which is a VERY welcome change from how it used to be). My xorg.conf.d contains one file with 6 lines in it. So, the new approach makes sense. My postfix config contains a large number of overrides, as do most. Postfix really needs a moderate bit of setup in terms of setting domains, policies, and so on. Most people have anti-spam or greylisting or such enabled, or they relay through an outside smtp server, and so on. Plug-and-play configs are unusual for a mail server. That tends to make the big file in /etc with lots of changes more useful - it gives you a template to edit, and if upstream changes something you want to see what it is so that you can decide how to best merge in your tweaks. So, the traditional approach works best for config files that need a lot of editing which don't lend themselves to modularization. I find the new approach works better for situations where the files are very modular (that is, in practice you can change just one setting and not have to look at others), and when changes are the exception rather than the rule (which means that you're only managing exceptions). Personally, I'm glad my udev rules directory is now nearly empty. Previously it was just a situation where orphan rules caused trouble, updates required care, and so on. Now the only things that can possibly cause trouble are my disabling of the persistent network names, and a few rules that add symlinks for some pl2303s so that I can refer to them with consistent names (which I don't actually need any longer anyway now that I use a cablecard tuner). Rich
Re: [gentoo-dev] Adding slot and subslot deps to others' packages
Dnia 2014-03-02, o godz. 19:09:09 Jeroen Roovers napisał(a): > On Sun, 2 Mar 2014 12:32:05 -0500 > Mike Gilbert wrote: > > > On Sun, Mar 2, 2014 at 10:45 AM, Jeroen Roovers > > wrote: > > > On Sun, 2 Mar 2014 09:37:22 +0100 > > > Michał Górny wrote: > > > > > >> Few months ago I have written a small FAQ on how to use slots > > >> and subslots for library dependencies properly [1]. However, today > > >> I see that most of the developers didn't care to properly update > > >> their packages and when I introduced binary compatibility slot in > > >> libgcrypt, I had my hands full of work fixing the mess for a > > >> single package. > > > > > > How about you file a tracker bug report for each library package, > > > and then file bug reports per package using that dependency > > > blocking the tracker bug? > > > > > > > That is certainly the conservative way to handle this, and it seems > > like a lot more work. > > Not managing the migration is apparently a lot of work, since the work > isn't being done "voluntarily". Managing the migration might seem like a > lot of work, but at least it allows you to track progress properly and > tick off finished tasks, while in the mean time everyone involved gets > informed, and perhaps gets their bugs fixed for them quicker. Except that with that number of bugs, some of them are going to get outdated very quickly due to version bumps where maintainer ignored the bug. And believe me, if I'll file around 50 bugs for each maintainer, they are not going to be happy. I guess some of them will be closed as DONTCARE, and others reassigned to me like I needed that. Pretty much like you keep assigning every bug with 'clang' in summary line to me like I was supposed to patch every package in the world for clang compatibility. > > If there are any reasonable objections (besides maintainer > > territorial-ism), of course the QA team should consider them. > > That's back to the "agreement" bit, I guess. > > Honestly, setting up a tracker and blocking it with bugs about packages > which someones-sub-SLOT-checking-script has vetted to be involved could > be done in less than a day (for the hundred or so packages that depend > on dev-libs/libgcrypt). It doesn't need some QA team to study in depth > -- it needs a couple of volunteers to do the checks and file the bug > reports. I'm not talking about libgcrypt. Those dependencies were 'mostly fixed' already and no sane person will revbump every single package just to make sure that everything will go right. Especially when Council banned a few EAPIs and the revbump would have to be connected with EAPI bump... and that would really make it all so happy and awesome. So I'm not talking about few dozen libgcrypt consumers. I'm talking about all packages in Gentoo that depend on at least a single library. I won't give you numbers but I guess you can imagine the number of bugs. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Adding slot and subslot deps to others' packages
On Sun, Mar 2, 2014 at 1:09 PM, Jeroen Roovers wrote: > Honestly, setting up a tracker and blocking it with bugs about packages > which someones-sub-SLOT-checking-script has vetted to be involved could > be done in less than a day (for the hundred or so packages that depend > on dev-libs/libgcrypt). It doesn't need some QA team to study in depth > -- it needs a couple of volunteers to do the checks and file the bug > reports. Honestly, it would be best to coordinate this with QA. QA isn't just about taking away commit rights in punishment for your sins. Scripts to help make devs aware of potential improvements should be a part of QA as well. And that isn't saying that you have to be on the QA team in order to do this either. If this sort of thing interests anybody, just ping them. I know QA is interested in improving the use of slot operator dependencies, because they've said as much on their irc channel... My script for spotting opportunities to use slot op deps is still out there. Of course, I wouldn't just "fix" any ebuild that comes up as there are situations where it isn't appropriate. What would probably make sense is for QA to define a var for ebuilds to set when they've been screened and found to be false positives, and then suppress them from the output. I'm all for nudging maintainers to add slot op deps when they make sense, or allowing others to do the work for them as long as they exercise reasonable care. Ebuilds don't belong to maintainers, but we should work with them whenever possible so that they're in a position to spot issues and deal with them. Rich
Re: [gentoo-dev] Adding slot and subslot deps to others' packages
On Sun, Mar 2, 2014 at 2:20 PM, Rich Freeman wrote: > My script for spotting opportunities to use slot op deps is still out > there. Of course, I wouldn't just "fix" any ebuild that comes up as > there are situations where it isn't appropriate. What would probably > make sense is for QA to define a var for ebuilds to set when they've > been screened and found to be false positives, and then suppress them > from the output. > Just curious: What exactly does your script count as an "opportunity"? I don't have a link handy.
Re: [gentoo-dev] Adding slot and subslot deps to others' packages
On Sun, Mar 2, 2014 at 1:09 PM, Jeroen Roovers wrote: > Honestly, setting up a tracker and blocking it with bugs about packages > which someones-sub-SLOT-checking-script has vetted to be involved could > be done in less than a day (for the hundred or so packages that depend > on dev-libs/libgcrypt). It doesn't need some QA team to study in depth > -- it needs a couple of volunteers to do the checks and file the bug > reports. > Unless I have missed mgorny's point here, this isn't just about libraries that have currently subslots. This is about every single library in the tree. That's a LOT of bugs. I guess filing bugs is doable if we handle a few libraries at a time. However, it would be nice to avoid the repetitive "paperwork" and just let people get the job done.
Re: [gentoo-dev] Adding slot and subslot deps to others' packages
On Sun, Mar 2, 2014 at 2:44 PM, Mike Gilbert wrote: > On Sun, Mar 2, 2014 at 1:09 PM, Jeroen Roovers wrote: >> Honestly, setting up a tracker and blocking it with bugs about packages >> which someones-sub-SLOT-checking-script has vetted to be involved could >> be done in less than a day (for the hundred or so packages that depend >> on dev-libs/libgcrypt). It doesn't need some QA team to study in depth >> -- it needs a couple of volunteers to do the checks and file the bug >> reports. >> > > Unless I have missed mgorny's point here, this isn't just about > libraries that have currently subslots. This is about every single > library in the tree. Correct - my script will spot packages that depend on libraries that are set up with subslots, but which don't contain a slot operator dep. It will not spot libraries that do not use subslots. However, I'm not sure why you'd need a tracker per library for that. Adding a subslot to a library impacts only that library. Once that is done then the script I wrote will detect all the other packages which should be modified to go along with it. You can add a subslot to a library without adding a corresponding slot operator dep to every package that uses it. I think it makes more sense to add subslots to libs and not revbump them, vs not doing anything for 18 months because it is too much work. Sure, the full benefit won't come up-front without all the work, but you'll at least get some benefit vs not ever getting any. The perfect is the enemy of the good... Rich
[gentoo-dev] Interview Inquiry for the Linux Action Show
Hello All, My name is Michael Tunnell and I am looking for someone from the Gentoo team to do an interview about the Gentoo project and their personal involvement with the project on the Linux Action Show. If you aren't aware of the Linux Action Show, LAS is a weekly podcast and the #1 Linux Podcast in multiple rankings throughout the internet. LAS is recorded LIVE every Sunday at 10:00 AM PST and is also the longest running Linux Podcast of 8 years with 302 episodes as of today. Would anyone be interested in having an interview on the show? The interview would be preferred to be recorded live during show time but another time can also be accommodated if needed. Chris & Matt will ask questions regarding the Gentoo project itself, your involvement with the project, plans for the future (possibly) and possibly viewer submitted questions. Viewer Submitted Questions would be done in the LAS Subreddit so you could read the public submissions beforehand to get an idea what the kind of questions will be. We would like to have a Gentoo Developer or Gentoo staff of some kind to participate in the interview. If you are interested please reply here or if you would prefer private correspondence then you can email me directly at m...@michaeltunnell.com -- Michael Tunnell Producer for Jupiter Broadcasting
Re: [gentoo-dev] Adding slot and subslot deps to others' packages
On Sun, 2 Mar 2014 14:44:52 -0500 Mike Gilbert wrote: > Unless I have missed mgorny's point here, this isn't just about > libraries that have currently subslots. This is about every single > library in the tree. Some (many?) libraries rarely change API/ABI so it wouldn't make sense to include those in a first run. > That's a LOT of bugs. I guess filing bugs is doable if we handle a few > libraries at a time. However, it would be nice to avoid the repetitive > "paperwork" and just let people get the job done. Better yet, focus on those (few?) libraries that regularly change APIs/ABIs and for which adding sub-SLOT deps to dependent ebuilds makes sense *now*. That's just the one tracker bug per library and blocking bugs for its revdeps, and I'd gladly help out focusing the effort. jer
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2014-03-02 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2014-03-02 23h59 UTC. Removals: net-libs/libguac2014-02-25 15:50:16 nativemad net-libs/libguac-client-rdp 2014-02-25 15:51:32 nativemad net-libs/libguac-client-vnc 2014-02-25 15:51:43 nativemad net-misc/guacd 2014-02-25 15:52:56 nativemad Additions: dev-python/pyfeyn 2014-02-24 04:16:55 grozin dev-util/sasm 2014-02-24 18:16:40 maksbotan sci-libs/voro++ 2014-02-24 23:36:07 ottxor www-apache/mod_authnz_persona 2014-02-25 08:29:23 djc app-arch/pdlzip 2014-02-25 08:45:22 mgorny perl-core/Devel-PPPort 2014-02-25 15:26:21 zlogene dev-python/sphinx-bootstrap-theme 2014-02-25 17:23:08 bicatali mate-base/mate-common 2014-02-26 21:52:22 tomwij app-arch/lzlib 2014-02-27 10:55:45 mgorny app-arch/plzip 2014-02-27 10:55:49 mgorny mate-base/mate-session-manager 2014-02-27 18:41:22 tomwij mate-base/mate-menus2014-02-28 01:06:25 tomwij mate-base/libmatekbd2014-02-28 13:15:03 tomwij app-text/mate-doc-utils 2014-02-28 13:38:12 tomwij sci-libs/Shapely2014-02-28 14:04:31 slis net-analyzer/nagios-check_linux_bonding 2014-02-28 18:16:49 ercpe dev-libs/libmateweather 2014-02-28 23:09:59 tomwij dev-python/pretend 2014-03-01 03:46:20 radhermit dev-python/cryptography 2014-03-01 03:48:56 radhermit dev-java/boilerpipe 2014-03-01 09:15:45 ercpe media-plugins/gst-plugins-vaapi 2014-03-01 10:09:39 pacho dev-db/derby2014-03-01 18:57:12 ercpe net-analyzer/masscan2014-03-01 21:31:07 robbat2 mate-base/mate-desktop 2014-03-02 02:18:45 tomwij mate-extra/mate-dialogs 2014-03-02 02:32:25 tomwij mate-extra/mate-polkit 2014-03-02 03:10:48 tomwij x11-libs/libmatewnck2014-03-02 03:49:52 tomwij dev-python/ssl-fetch2014-03-02 05:42:49 dolsen dev-java/hamcrest-integration 2014-03-02 16:26:05 ercpe -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: net-libs/libguac,removed,nativemad,2014-02-25 15:50:16 net-libs/libguac-client-rdp,removed,nativemad,2014-02-25 15:51:32 net-libs/libguac-client-vnc,removed,nativemad,2014-02-25 15:51:43 net-misc/guacd,removed,nativemad,2014-02-25 15:52:56 Added Packages: dev-python/pyfeyn,added,grozin,2014-02-24 04:16:55 dev-util/sasm,added,maksbotan,2014-02-24 18:16:40 sci-libs/voro++,added,ottxor,2014-02-24 23:36:07 www-apache/mod_authnz_persona,added,djc,2014-02-25 08:29:23 app-arch/pdlzip,added,mgorny,2014-02-25 08:45:22 perl-core/Devel-PPPort,added,zlogene,2014-02-25 15:26:21 dev-python/sphinx-bootstrap-theme,added,bicatali,2014-02-25 17:23:08 mate-base/mate-common,added,tomwij,2014-02-26 21:52:22 app-arch/lzlib,added,mgorny,2014-02-27 10:55:45 app-arch/plzip,added,mgorny,2014-02-27 10:55:49 mate-base/mate-session-manager,added,tomwij,2014-02-27 18:41:22 mate-base/mate-menus,added,tomwij,2014-02-28 01:06:25 mate-base/libmatekbd,added,tomwij,2014-02-28 13:15:03 app-text/mate-doc-utils,added,tomwij,2014-02-28 13:38:12 sci-libs/Shapely,added,slis,2014-02-28 14:04:31 net-analyzer/nagios-check_linux_bonding,added,ercpe,2014-02-28 18:16:49 dev-libs/libmateweather,added,tomwij,2014-02-28 23:09:59 dev-python/pretend,added,radhermit,2014-03-01 03:46:20 dev-python/cryptography,added,radhermit,2014-03-01 03:48:56 dev-java/boilerpipe,added,ercpe,2014-03-01 09:15:45 media-plugins/gst-plugins-vaapi,added,pacho,2014-03-01 10:09:39 dev-db/derby,added,ercpe,2014-03-01 18:57:12 net-analyzer/masscan,added,robbat2,2014-03-01 21:31:07 mate-base/mate-desktop,added,tomwij,2014-03-02 02:18:45 mate-extra/mate-dialogs,added,tomwij,2014-03-02 02:32:25 mate-extra/mate-polkit,added,tomwij,2014-03-02 03:10:48 x11-libs/libmatewnck,added,tomwij,2014-03-02 03:49:52 dev-python/ssl-fetch,added,dolsen,2014-03-02 05:42:49 dev-java/hamcrest-integration,added,ercpe,2014-03-02 16:26:05 Done.
Re: [gentoo-dev] Adding slot and subslot deps to others' packages
On Sun, 2 Mar 2014 19:58:47 +0100 Michał Górny wrote: > > Honestly, setting up a tracker and blocking it with bugs about > > packages which someones-sub-SLOT-checking-script has vetted to be > > involved could be done in less than a day (for the hundred or so > > packages that depend on dev-libs/libgcrypt). It doesn't need some > > QA team to study in depth -- it needs a couple of volunteers to do > > the checks and file the bug reports. > > I'm not talking about libgcrypt. Those dependencies were 'mostly > fixed' already and no sane person will revbump every single package > just to make sure that everything will go right. Especially when > Council banned a few EAPIs and the revbump would have to be connected > with EAPI bump... and that would really make it all so happy and > awesome. The point would be to add the sub-SLOT token to *DEPEND at a revision bump or version bump. With a blocking bug for each affected package, and assuming maintainers check for open bug reports when they bump (as they already should), you would effectively make sure they *should* have known about adding the sub-SLOT changes. With only some helpful messages and friendly reminders on a general mailing list, you don't achieve the same effect. So again, if you or anyone else plans on giving a new library the same treatment, then get some people involved in filing the bug reports, so they get fixed within a good timeframe. We're still talking weeks to months to years for some libraries and their reverse dependencies, but at least we'd be on our way. jer
Re: [gentoo-dev] Adding slot and subslot deps to others' packages
On Sun, Mar 2, 2014 at 7:23 PM, Jeroen Roovers wrote: > On Sun, 2 Mar 2014 14:44:52 -0500 > Mike Gilbert wrote: > >> Unless I have missed mgorny's point here, this isn't just about >> libraries that have currently subslots. This is about every single >> library in the tree. > > Some (many?) libraries rarely change API/ABI so it wouldn't make sense > to include those in a first run. > >> That's a LOT of bugs. I guess filing bugs is doable if we handle a few >> libraries at a time. However, it would be nice to avoid the repetitive >> "paperwork" and just let people get the job done. > > Better yet, focus on those (few?) libraries that regularly change > APIs/ABIs and for which adding sub-SLOT deps to dependent ebuilds makes > sense *now*. > Ah, what a silly thing for me to overlook. That does change my outlook.
