Re: [gentoo-dev] ffmpeg vs libav choice of default
On 4 February 2015 at 20:43, Mike Auty ike...@gentoo.org wrote: Whilst the default *is* still in place (and particularly after the recent news article detailing that users should be using libav), could we please keep commits like the following until *after* we've made an agreed upon decision please? http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/package.mask?r1=1.16328r2=1.16329 Anyone using mpv (because mplayer does not work with libav, and they were directed to use mpv by the news article) will now be hit by blockers attempting to reinstall ffmpeg. It's fine to have disagreements, but airing them in front of the users like this is not an ideal situation... That would suggest political motives or something of the sort. But that is far from the truth. Newer mpv versions were masked for many months, for no apparently valid reason, except that the libav versions on which it optionally (!) depended were masked. Since we introduced the libav useflag, we have now a way to finally make mpv-0.7* (using the upstream recommended ffmpeg as default) visible to ~arch users, without the need to unmask it. Users who wish to use libav with it, can do so by unmasking the useflag and the relevant libav version. (While before they would have had to unmask both mpv and libav. The resulting change is minor.) Fewer users will now need to unmask mpv-0.7*. Besides, it is a reminder that upstream recommends ffmpeg, which comes as a surprise to many. And as a result, we can unmask the newest version of smplayer, which can now function as a GUI frontend for mpv as well. I would say this is an overall improvement for our end-users. I don't want to get into the politics of it, but just look at it from a practical perspective. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] ffmpeg vs libav choice of default
On 4 February 2015 at 21:49, Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Ulrich Mueller schrieb: In the replies to http://forums.gentoo.org/viewtopic.php?p=7694982 several users have expressed their preference for ffmpeg. To help finding out what users actually think, I added a poll to the forum to ask them about their preference. https://forums.gentoo.org/viewtopic-t-1010096.html They seem pretty strongly in favour of changing the default back to ffmpeg: https://forums.gentoo.org/viewtopic-t-1010096-postdays-0-postorder-asc-vote-viewresult.html -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] ffmpeg vs libav choice of default
On 4 February 2015 at 17:21, Michał Górny mgo...@gentoo.org wrote: Dnia 2015-02-04, o godz. 10:12:12 Ulrich Mueller u...@gentoo.org napisał(a): With the recent introduction of the libav USE flag, the Gentoo default for ffmpeg vs libav is more pronounced than it was before (with libav being listed first in || ( ) dependencies). In the replies to http://forums.gentoo.org/viewtopic.php?p=7694982 several users have expressed their preference for ffmpeg. So can someone please remind me what are the technical reasons why we prefer libav over ffmpeg? From an upstream that I care about: https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav Based on that I would say we should switch back the default to ffmpeg. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] ffmpeg vs libav choice of default
On 4 February 2015 at 17:55, Michał Górny mgo...@gentoo.org wrote: Dnia 2015-02-04, o godz. 17:24:03 Ben de Groot yng...@gentoo.org napisał(a): From an upstream that I care about: https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav Based on that I would say we should switch back the default to ffmpeg. From what I heard, that upstream likes to change its opinion frequently, pretty much based on which upstream he is pissed at the moment. But it's just rumors. Rumours have no place here. Let's focus on the technical arguments. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On 3 February 2015 at 00:00, Michael Orlitzky m...@gentoo.org wrote: On 02/02/2015 10:50 AM, Michał Górny wrote: Maybe. Though it still will keep the confusion of !libav meaning ffmpeg. We could remove USE=libav from the tree, leaving only USE=ffmpeg. Then ffmpeg_impl_libav would switch the implementation if USE=ffmpeg is enabled. Maybe a little cleaner but still relies on the implicit thing. Not to mention the user is supposed to set either: FFMPEG_IMPL=libav or: FFMPEG_IMPL= which is nowhere close to sane :). With only one flag, why bother with the USE_EXPAND? Actually, after reading this conversation, I don't think we need the USE_EXPAND. The current solution with USE=ffmpeg libav works. It may not be the cleanest, but the other solution proposed here doesn't add that much. Please restore the news item and unmask the revbumps, so we can get on with business. :) -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86
On Fri, Jan 23, 2015 at 4:38 PM, Michał Górny mgo...@gentoo.org wrote: 3. Put it in an ebuild, after all. This will add a lot of complexity but GPG comes for free, plus some people will actually test and stabilize it. I think this should be in an ebuild. You mentioned that it's only needed ONCE, but it's needed ONCE for everytime one install gentoos, along the same lines as mirrorselect. A couple of years from now, do we want users to have to dig through several dozen old news items to get this tool? I know the ebuild's a bit of extra work but then the python issues can also be properly handled. And bugs can be properly handled, etc etc. -Ben
Re: [gentoo-dev] git.gentoo.org/git.overlays.gentoo.org upgrades, 2014/12/24 2014/12/26: gitolite upgrade done
On 28 December 2014 at 11:36, Robin H. Johnson robb...@gentoo.org wrote: We are now running gitolite-gentoo-3.6.2.1, a huge jump from our prior 2.3.3. File a bug if you see anything weird, and ping me in IRC (#gentoo-dev) if you think it's urgent. There still is no web interface for browsing the repositories. What are the plans for returning that service? -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
On 23 December 2014 at 00:11, Andreas K. Huettel dilfri...@gentoo.org wrote: +1 for an archive overlay I set up the graveyard overlay for such purposes, a couple of years ago. But it hasn't taken off: https://github.com/gentoo/graveyard Feel free to resurrect it. (pun intended) -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Make 'vaapi' USE flag global
On 28 November 2014 at 20:20, Sergey Popov pinkb...@gentoo.org wrote: Packages that uses 'vaapi' local USE-flag: media-libs/avidemux-core media-libs/xine-lib media-tv/mythtv media-tv/xbmc media-video/avidemux media-video/ffmpeg media-video/hwdecode-demos media-video/libav. media-video/mpv media-video/vlc virtual/ffmpeg www-plugins/gnash Descriptions for that flag are pretty the same and we already have 'vdpau' USE flag, which is for someway similar technology. So, how about making this flag global too? Do it! -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Last rites: razorqt-base/*
On 8 November 2014 19:15, Jauhien Piatlicki jauh...@gentoo.org wrote: Hi Ben, Have you read comments on Qt overlay commit? Have you check reverse dependencies of packages you are masking? razorqt-base/libqtxdg is used by LXQt. So, please, unmask it. I will move it into lxqt-base category. But until this, please, do not touch it. And, please, make sure you are reading metadata.xml and checking revdeps of packages you are touching. I mistakenly assumed you had a newer version of all packages in the lxqt-base category. Nothing outside of the razorqt-base category should logically have depended on a package in there. Anyway, I have since fixed this issue with a package move to dev-libs/libqtxdg. I have adjusted the depend lines in relevant lxqt ebuilds. -- Cheers, Ben | yngwin Gentoo developer
[gentoo-dev] Last rites: razorqt-base/*
# Ben de Groot yng...@gentoo.org (7 Nov 2014) # Unmaintained, no longer supported, and starting to throw compilation # errors (bug #513906, bug #528372). Masked for removal in 30 days. # Update to lxqt-base/* packages. razorqt-base/libqtxdg razorqt-base/razorqt-appswitcher razorqt-base/razorqt-autosuspend razorqt-base/razorqt-config razorqt-base/razorqt-data razorqt-base/razorqt-desktop razorqt-base/razorqt-kbshortcuts razorqt-base/razorqt-libs razorqt-base/razorqt-lightdm-greeter razorqt-base/razorqt-meta razorqt-base/razorqt-notifications razorqt-base/razorqt-openssh-askpass razorqt-base/razorqt-panel razorqt-base/razorqt-policykit razorqt-base/razorqt-power razorqt-base/razorqt-runner razorqt-base/razorqt-session -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Add bc back to the stage3
On 27 September 2014 20:40, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 27 Sep 2014 18:31:03 +0600 Vladimir Romanov bluebo...@gmail.com wrote: Em. I don't agree. I prefer Emacs and don't like Vim. But if i must choose between Vim and Nano, i prefer Nano But vi is POSIX. vi is available through busybox already -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings
On 13 August 2014 02:46, Michał Górny mgo...@gentoo.org wrote: Dnia 2014-08-11, o godz. 20:48:20 William Hubbs willi...@gentoo.org napisał(a): got a minor (but chatty) QA warning: DESCRIPTION ends with a '.' character Why is this a QA warning in the first place? Because it is a common mistake, and having the warning in-place should help people avoid repeating it. This is correct. I don't recall a policy mandating that descriptions can't end with '.'. I asked our QA lead about it and was told that he didn't recall that we have an official policy about it either. Also, the devmanual never mentions any such requirement. I don't know if and where it is documented but that's what I was taught when I started contributing to Gentoo, and it pretty much follows the common sense. DESCRIPTION is supposed to be short and descriptive. So you do an elliptical sentence (if I got the right translation), and that doesn't end with a dot. Again, this is what I was taught as well. It may have been an undocumented rule, but it has been around for as long as I can remember. It also makes linguistic sense, and as an English teacher it always irks me when I see this mistake. If you have any fair reason to not follow this, please speak of it. Otherwise, this is pure bikeshed and waste of time. This thread already took much more time than fixing your packages if repoman complained about them. Amen! If someone can point me to something I'm missing, let me know. Otherwise, I think the warning should be removed. Even if there were no written-down policy, why would it be removed? What is the benefit of removing the check that resulted in many fixes already? Do you want to revert the removals afterwards? Or do you want to introduce new packages which use '.' there? I completely support this argument. The warning is correct and should remain in place. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Supporting both Qt4 and Qt5 builds
On 10 August 2014 18:51, Georg Rudoy 0xd34df...@gmail.com wrote: Hi, I'm thinking of converting a few ebuilds (x11-libs/qwt, dev-libs/kqoauth, net-libs/qxmpp among them) to support building with both Qt4 and Qt5. Should this better be done by adding the corresponding useflags (qt4 and qt5 respectively) or by slotting? What's your opinion on this? The Qt team has always recommended the useflag method for packages that support more than one major version of Qt. This is also what we implement ourselves. So for consistency's sake, please stick with the useflags. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Re: RFC: news item for upower
On Wed, Jun 4, 2014 at 11:24 AM, Samuli Suominen ssuomi...@gentoo.org wrote: Wrong. I'm always using the -t (--tree) flag with Portage and I would have seen upower being the culprit immediately, and second command would have been `eix upower` to see available versions, at which point I would have seen upower-pm-utils, and figured it out. - Samuli I'm glad this fire has mostly been put out, but I think you are making quite a leap here that normal users can see upower-pm-utils, and figure it out. You may be too close to this problem to understand just how confusing it is to everyone else. No offense intended. -Ben
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
On Fri, May 30, 2014 at 11:50 AM, Tom Wijsman tom...@gentoo.org wrote: On Fri, 30 May 2014 19:26:38 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: I'll give it 48 hours and then p.mask it. Genkernel itself does work; so, there is no point to masking it. I like the message the package.mask would send to maintainers, but that would be very bad for our handbook to recommend a hard masked tool. FYI this has been an ongoing problem for some time-- genkernel's code is still well maintained and seeing development, it's the arch-specific kernel configs that are unmaintained. And broken in quite a few ways right now. We have a few people willing to spend the 20 minutes it would take to fix all of these config problems, but no one in an official dev seat. None of the current genkernel maintainers want to touch the kernel config part. As nice at it sounds to just DROP these configs, that option is not really feasible considering the way we currently use genkernel in our handbook. Relying on the kernel's own defconfig, genkernel all will NOT produce the same mostly-usable-on-any-hardware result that we now rely on. I would be more than willing to whip up a config that fixes this udev issue plus a dozen more, and post it somewhere for review. But I'd only be able to cover x86/amd64. Or anyone else can do it-- load up our existing config into menuconfig (probably against current stable gentoo-sources, add/remove a handful of options to fix up all these bugs. Save, exit, give it to the genkernel maintainer and we're done. -Ben Kohler
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
On Fri, May 30, 2014 at 12:59 PM, Tom Wijsman tom...@gentoo.org wrote: Good idea, we really could use some kind of kernel seeds in the Portage tree; if someone is willing to maintain them, knowing that Pappy has maintained them for years and spoke about it it seems like hard work. Remember that these kernel seeds are actually pretty far from what we need for genkernel defaults (at least the way we currently recommend using it in our install handbook). The kernel seeds provide a good sane kernel config *with little or no specific hardware support*. But I'm definitely in favor of separately packaging the kernel configs. -Ben
Re: [gentoo-dev] Re: Banning modification of pkg-config files
On 10 May 2014 04:34, Markos Chandras hwoar...@gentoo.org wrote: On 05/09/2014 09:32 PM, Tom Wijsman wrote: On Fri, 9 May 2014 16:15:58 -0400 Rich Freeman ri...@gentoo.org wrote: I think fixing upstream is a no-brainer. It indeed is, this is the goal; you can force them in multiple ways, some of which can be found on the Lua bug and previous discussion(s). The controversy only exists when upstream refuses to cooperate (which seems to be the case when we're one of six distros patching it). If there are other situations where we supply our own files please speak up. Not that I know of; the refusal to cooperate is what this is all about, see my last response to hwoarang before this mail for a short summary. Though, I think that the Lua maintainers can explain all the details... When the only issue is maintainer laziness I could see fixing that in a different way... It has always been an issue; we could always use more manpower, ... https://wiki.gentoo.org/wiki/Contributing_to_Gentoo Well to me it feels that gentoo specific .pc files is a similar problem to any other patch that affects upstream code in order to make the package compatible with gentoo. Some people may consider downstream pc files more dangerous because reverse deps are affected. But really, if there is no other alternative, we shouldn't be treating this as a special case. We patch upstream packages all the time after all Exactly. I don't understand why this is an issue at all. Obviously, if upstream does not ship a .pc file or ships a broken one, we try to work with upstream to get it fixed on their end. If they are uncooperative, we fix it on our end. -- Cheers, Ben | yngwin Gentoo developer
[gentoo-dev] Packages up for grabs / looking for new primary maintainers
As my time is limited, and certain issues also drain my motivation, I am stepping down as primary maintainer for the following packages. They are also assigned to a herd, but since these are relatively high maintenance they need a dedicated maintainer. (And fonts herd has been basically inactive for the last couple of years...) app-text/calibre media-libs/fontconfig media-libs/freetype www-apps/nikola x11-libs/cairo I would also like to completely hand over maintenance of the following low-maintenance packages: app-admin/pydf app-arch/lrzip app-arch/xar Feel free to remove me as maintainer for these last three packages, if anyone is willing to take over. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Stable masks on multilib packages
On 1 April 2014 21:58, Alexandre Rostovtsev tetrom...@gentoo.org wrote: On Tue, 2014-04-01 at 13:13 +0800, Ben de Groot wrote: On 1 April 2014 06:16, Michał Górny mgo...@gentoo.org wrote: Hello, all. The late multilib ppc issues made me re-check our stable masks on abi_x86_* flags and, honestly, I'm not sure if we're doing things the right way. That said, I have an alternate idea inspired by the ppc breakage. Your thoughts? In my opinion your multilib approach introduces an unnecessary degree of complexity, which --as has been shown here again-- is prone to breakage. It would be best for our beloved distro to revert all the multilib changes, and try a different approach, or leave this prone-to-breakage implementation to an overlay for the few people who would actually benefit from it. Speaking as a wine maintainer, the emul-linux-x86-* approach has many times been proven to be an embarrassing failure and the main source of pain and frustration for wine users. The sooner emul-linux-x86-* can be removed from the tree, the better for Gentoo. I would like to see an honest cost-benefit analysis of the emul-linux-x86 approach compared to the multilib eclass approach. Because in my experience the latter introduces more breakage and higher maintenance costs. I am aware of only two solutions to the emul-linux-x86-* problems : multilib-portage and multilib-build.eclass. The first requires everybody to switch to a new package manager. The second allows us to keep using portage, but requires library maintainers to add some simple boilerplate to their ebuilds for multilib support. Do you have yet another alternative in mind? In my mind the emul-linux-x86 approach is more acceptable. I don't have experience with multilib-portage, as I don't have a use case for it. Another option, which seems to me to be more reasonable and which has greatly lower maintenance costs, is using a chroot. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Stable masks on multilib packages
On 2 April 2014 07:38, Patrick Lauer patr...@gentoo.org wrote: On 04/01/2014 01:13 PM, Ben de Groot wrote: On 1 April 2014 06:16, Michał Górny mgo...@gentoo.org wrote: Hello, all. The late multilib ppc issues made me re-check our stable masks on abi_x86_* flags and, honestly, I'm not sure if we're doing things the right way. That said, I have an alternate idea inspired by the ppc breakage. Your thoughts? In my opinion your multilib approach introduces an unnecessary degree of complexity, which --as has been shown here again-- is prone to breakage. And it removes any chance of writing ebuilds - I seriously have no idea how to fix those things now. They are multibuilds, not ebuilds. This is part of the complexity I mentioned. I significantly raises maintenance costs, and I'm not convinced of the benefit. It would be best for our beloved distro to revert all the multilib changes, and try a different approach, or leave this prone-to-breakage implementation to an overlay for the few people who would actually benefit from it. As a temporary stage they are kinda okish, maybe ... but ... the whole transition strategy has been very very silly and should have been staged in an overlay. I'd even build-test them and file bugs - just don't do this salami tactic of one breakage a day. I'm strongly considering reverting these changes in the packages I maintain. I'm tired of having to deal time and again with multilib breakage. Either that, or someone else can take over primary maintainership. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Stable masks on multilib packages
On 1 April 2014 06:16, Michał Górny mgo...@gentoo.org wrote: Hello, all. The late multilib ppc issues made me re-check our stable masks on abi_x86_* flags and, honestly, I'm not sure if we're doing things the right way. That said, I have an alternate idea inspired by the ppc breakage. Your thoughts? In my opinion your multilib approach introduces an unnecessary degree of complexity, which --as has been shown here again-- is prone to breakage. It would be best for our beloved distro to revert all the multilib changes, and try a different approach, or leave this prone-to-breakage implementation to an overlay for the few people who would actually benefit from it. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
On 12 February 2014 07:04, Samuli Suominen ssuomi...@gentoo.org wrote: [...] It's sad that people don't follow common sense (which happens to be the GNOME highlights) and that everything must be turned into a policy of somesort so people get it. [...] Just make the gnome gtk3 policy the guideline if you must. It's just documenting common sense. It seems that only the Gnome team regards this as common sense. Others, such as the Qt team and QA regard the versioned useflag solution as more sensible. I think we can conclude that there is no perfect solution, and we simply have different preferences. That said, I'm not sure we absolutely need a policy. Though I would agree it would be more elegant if we can solve this matter, to make it easier to grasp by our users. In that case the QA proposal makes sense to me. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Portage Feature Request: making thirdpartymirrors easier to manage
On Wed, Jan 8, 2014 at 12:37 PM, Alex Xu alex_y...@yahoo.ca wrote: Eww. Geographically-close files should be made available through GENTOO_MIRRORS and the regular distfiles system. I think you may be missing the point of this proposal, or are unaware of how profiles/thirdpartymirrors and SRC_URI=mirror://.. work. Readability and maintanence issues aside (which themselves are huge), the current setup with a list of literally hundreds of geographically-random mirrors for one source, is quite often doing a disservice to our users. Most of the very large upstream mirror list sources are already sorted geographically, it would be great to take advantage of this. And to me, it seems like the proposed thirdpartymirrors/mirrorname/Region setup seems quite elegant. I'm sure it would be optional and mirror lists that can't take advantage of this would just use a flat file at thirdpartymirrors/mirrorname. -Ben
Re: [gentoo-dev] Portage Feature Request: making thirdpartymirrors easier to manage
On Mon, Jan 6, 2014 at 2:20 PM, Robin H. Johnson robb...@gentoo.org wrote: This is a small feature request, but it will require a modification to PMS, so I describe it here. The present thirdpartymirrors file is unwieldy, and difficult to manage due to it's format with very long lines. It also doesn't permit easy comments. Presently commits to it look very ugly, because diffs are line-based, and we pack a lot into each line. I would like to make it a directory instead of a single file, and extend the internal syntax. I am very excited about this whole idea, this thirdpartymirrors setup badly needs some reworking. To me it makes the most sense to turn thirdpartymirrors into a dir, with a file structure like: thirdpartymirrors/mirror1 thirdpartymirrors/mirror2 thirdpartymirrors/mirror3/ thirdpartymirrors/mirror3/Asia thirdpartymirrors/mirror3/Europe thirdpartymirrors/mirror3/Etc thirdpartymirrors/mirror4 I'm not sure I see much real value in allowing individual profiles to add/remove mirrors from each group, to be honest. Maybe I'm just not thinking of the right scenarios. But I really do believe just the basic changes like splitting the file so each group gets its own file, one server per line, with comments, etc... will be a huge help in using and maintaining these groups. -Ben
Re: [gentoo-dev] Portage QOS
On Thu, Jan 9, 2014 at 6:44 AM, Igor lanthrus...@gmail.com wrote: According to distro watch: ... According to Linux Counter ... What are distro watch and linux counter and who cares what their opt-in stats gathering says? -most Gentoo users I've ever talked to I think if you drop the premise Gentoo is dying, how do we fix it? and just focus on Here are some ideas on how we can improve Gentoo, you'll get a better response here. From what I see (IRC activity, new ebuild activity, bugzilla activity, etc), our community seems stronger than ever. I think a lot of us are puzzled that you think Gentoo has stopped. You have some great ideas but this is not a sinking ship scenario. -Ben
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
On Fri, Dec 13, 2013 at 10:08 AM, Peter Stuge pe...@stuge.se wrote: Sergey Popov wrote: Last time I checked, vixie-cron upstream was died If vixie-cron upstream is dead as you say Define dead? Bugs are not fixed for a very long time, no answers on private e-mails or in maillists. Define very long time? //Peter If you have some reason we should be sticking to vixie-cron, please stop being so mysterious and share it with the rest of us. Thanks! -Ben
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
On Wed, Dec 11, 2013 at 1:30 PM, Peter Stuge pe...@stuge.se wrote: I think that nobody who is not intimately familiar with the development in both projects can think anything that is actionable. It's insulting to see how people all over the internet run as fast as they possibly can in whatever direction even though they have nearly zero detailed understanding of the options they are choosing between. Suggesting cronie in the handbook seems like a no-brainer. Do you have some information on vixie-cron that we're all missing? -Ben
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Fri, Dec 6, 2013 at 9:26 AM, Ian Stakenvicius a...@gentoo.org wrote: If the stage3 could include a dhcp client and (ideally imo) netifrc, even though they aren't a part of @system, that would help prevent the stuff missing, damnit, have to reboot back to livecd cycle. Since it isn't part of @world we would still need the documentation and instructions for someone to explicitly choose a network provider, otherwise they'll be bitten with it disappearing via --depclean. The user can still bring up networking via ifconfig or udhcpc if he happens to miss the handbook section on networking. If the user skips parts of the handbook, things may not work quite right... but the manual workaround is so trivial anyway, this is really a non-issue. Just make it clear that emerge netifrc is needed to use net.* scripts, and mention some alternatives. A news item would be a good idea to warn veteran haven't used the handbook in years people. -Ben
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 14 November 2013 13:13, Michał Górny mgo...@gentoo.org wrote:
Dnia 2013-11-14, o godz. 07:49:55
Patrick Lauer patr...@gentoo.org napisał(a):
On 11/13/2013 11:02 PM, Ian Stakenvicius wrote:
It's also worth pointing out that the whole reason why abi_x86_32 is
{package.,}use.stable.masked is because trying to manage the partial
transisition between emul-* and multilib-build dependencies
^^
Why is there a partial random transition with no roadmap, no coordination?
https://wiki.gentoo.org/wiki/Multilib_porting_status
That's the closest thing to a roadmap.
Closest thing, yeah. But it doesn't really solve the problem. It's
basically a one-man show, but affecting a large part of the tree,
going ahead like a steam roller that can't be stopped, never mind the
road kill.
Well, discussing it properly would also maybe have been a good idea, but
since this is now getting unilaterally hammered in it's mostly about
damage limitation now ...
And how is it possible to discuss anything properly in Gentoo?
That's because we have no proper leadership. We're an anarchistic
collection of people working at cross-purposes at the best of times.
There is no direction, and very little accountability.
--
Cheers,
Ben | yngwin
Gentoo developer
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 14 November 2013 20:32, Rich Freeman ri...@gentoo.org wrote: On Thu, Nov 14, 2013 at 7:21 AM, Ben de Groot yng...@gentoo.org wrote: On 14 November 2013 13:13, Michał Górny mgo...@gentoo.org wrote: And how is it possible to discuss anything properly in Gentoo? That's because we have no proper leadership. We're an anarchistic collection of people working at cross-purposes at the best of times. There is no direction, and very little accountability. This seems to be an arrangement that everybody likes except when somebody else does something differently than they would prefer... Seems, maybe. I for one do not like it at all, and I do bring that up from time to time. Others agree with me to various degrees. The problem is that it's so damn hard to change anything structurally in Gentoo. We have a Council, and any issue can always be escalated there. As it is always happy to point out, Council doesn't see itself as leadership, just as a supreme court of appeal, when everything else seems to have failed. It likes to get involved as little as possible. We also have Comrel, which is a better starting point for cases concerning individuals vs policies. This also displays little real leadership. It concerns itself with conflict resolution, with various degrees of success. (I still have a bad taste in my mouth from my past dealings with that institution.) However, so far I haven't really seen any real indications of what the concern is here. 32-bit software on amd64 has always been a kludge, and if anything the latest multilib eclass seems to be less of a kludge. I vehemently disagree. The emul-* packages may be a hack, but they work and cover the use cases we need. The new multilib eclass approach is much more intrusive in many packages, introduces new levels of complexity in ebuilds, with resulting new bugs and new behaviour that confuses users, and adding maintenance costs. It does this for very little gain. The great majority of our users doesn't need this functionality. The costs are higher than the benefits, in my opinion. Where are the use cases for this high-cost solution that is being pushed upon us? Apparently some argue that there is a better solution being worked on, and that's great to hear. What exactly is the problem? If the eclass were breaking things that weren't already broken and having a real impact on ordinary systems I'd consider that a concern. If you'd care to look at the history of bugs due to multilib eclass introduction in various packages, that's what you'd find. The problem with having top-down leadership in a volunteer-based organization is that it tends to drive away anybody who doesn't agree with the leader. If a supreme leader said mgorny has the right solution to multilib - everybody is going to work to implement it that would probably cause more harm than good. Everybody wants a supreme leader until the leader backs something they oppose. But what's the alternative? Having a few dozen self-appointed leaders doing whatever they want, and often taking things in opposing directions. It's not top-down leadership, but rule of the strongest. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 14 November 2013 23:12, Rich Freeman ri...@gentoo.org wrote: On Thu, Nov 14, 2013 at 7:57 AM, Ben de Groot yng...@gentoo.org wrote: I said As it is always happy to point out, Council doesn't see itself as leadership, just as a supreme court of appeal, when everything else seems to have failed. It likes to get involved as little as possible. The last time I talked to Council she said that she doesn't like it when you anthropomorphize her. Certainly I stated in my manifesto that I believe that Council members SHOULD be leaders, and should not limit their leadership of the distro to casting votes. That's why we're chatting on a list, and I'm not sitting back waiting for you to put this issue on a Council agenda. That is nice of you, but many of your fellow councilmen (historically, as well as currently) do not hold similar views, as was made painfully clear to me a few years ago. We also have Comrel, which is a better starting point for cases concerning individuals vs policies. This also displays little real leadership. It concerns itself with conflict resolution, with various degrees of success. (I still have a bad taste in my mouth from my past dealings with that institution.) Well, that is the role of Comrel. I don't expect it to decide whether developers can touch each other's ebuilds to add systemd units to them, etc. However, if the Council establishes a policy then Comrel should certainly take issue with devs that ignore that policy. Comrel certainly can show leadership when it comes to how it operates, facilitating better relations in the community in general, etc. The costs are higher than the benefits, in my opinion. Where are the use cases for this high-cost solution that is being pushed upon us? Where are the costs for this high-cost solution that you purport the existence of? Just what about this solution is difficult to maintain? I keep hearing that it is painful, but I haven't seen specific examples of HOW it is painful. See how much effort is expended on this, and how many maintainers are being involved: https://bugs.gentoo.org/buglist.cgi?quicksearch=ALL+multilib I was particularly hit by this as maintainer of freetype, see bugs 455070 and 459352 for some of the mess that could have been avoided. The problem with having top-down leadership in a volunteer-based organization is that it tends to drive away anybody who doesn't agree with the leader. If a supreme leader said mgorny has the right solution to multilib - everybody is going to work to implement it that would probably cause more harm than good. Everybody wants a supreme leader until the leader backs something they oppose. But what's the alternative? Having a few dozen self-appointed leaders doing whatever they want, and often taking things in opposing directions. It's not top-down leadership, but rule of the strongest. When you have officially-appointed leaders they usually tend to be the same people who would otherwise be the self-appointed leaders. They just have more power to kick everybody out who disagrees with them. It is still the rule of the strongest. How did Linus become the leader of Linux? He wrote it... At least there is one person in charge who sets a clear direction, and is accountable. I used to get philosophical about things like this, but I think the model Gentoo has is actually not a bad one. I guess we'll have to agree to disagree on this one then. In the end, stuff only gets done if people write code. Your power in any FOSS project really comes down to your ability to write code or convince others to write code on your behalf. No, it's more about your ability to commit and get away with it. We can argue about what piece of software is conceptually the best, but implemented software will almost always win over the unimplemented competitor, unless the merits of the competitor are such that people will flock behind it and actually implement it. Rich -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 15 November 2013 01:32, Rich Freeman ri...@gentoo.org wrote: On Thu, Nov 14, 2013 at 11:38 AM, Ben de Groot yng...@gentoo.org wrote: I was particularly hit by this as maintainer of freetype, see bugs 455070 and 459352 for some of the mess that could have been avoided. Looks like 455070 was the source of problems there (the other is just a tracker with the aftermath). The package had no maintainer at the time, only a herd (per cvs). There was a request in the bug for whether it was suitable to deploy to production. Somebody associated with the herd gave a thumbs-up, apparently (I can only say that based on your comment - I have no idea how that was communicated). Then something went wrong. Since it caused problems, it was masked. Those who run ~arch should be thanked for saving the stable users from potential breakage! I'm not sure what should have been done differently. If the package maintainer (in this case a herd) says that something is good to go, why would anybody assume that it wasn't? You suggested testing in an overlay 20 days earlier, but you weren't in any particularly privileged position at the time (you were presumably just another maintainer of the herd). I don't really want to bring up this episode again, but it is a telling example, which you asked for. As can be seen from the ChangeLog, I was the primary maintainer. As a member of the herd I didn't feel it necessary to assert any kind of privilege any other way. I had already said no, or at least wait but that was circumvented by asking another herd member who hadn't touched the package in years. It would have been nice were I asked for my okay before making any changes. And as can be seen, the mess I feared for indeed took place. This could have been prevented, in my opinion, had this seen more extensive testing in an overlay. And this is exactly why I am now more weary for the next package about to be mangled: cairo (bug 488672). I am even tempted to undo the multilib changes to freetype, since it is still causing trouble (just search for freetype bugs and see how often multilib pops up). I'm not pointing fingers here. This was apparently a miscommunication, and part of the cause was a failure to document that there was a primary maintainer of the package (something which was subsequently corrected). Michał did offer to just maintain the status quo on that package instead of migrating it, and apparently he thought he had the all-clear to migrate it anyway. Michał did add the multilib project as a co-maintainer, taking responsibility for dealing with the multilib-related issues long-term. In my mind this is the sort of things projects should do. Indeed, but more communication with the current actual maintainers of the package in question should also be part of that. I'm sure there were other issues, but issues will happen when projects make changes. That's just the way things roll around here. If Michał just committed a change to a package without conferring with the maintainer at all or giving significant notice, I'd feel differently. I think we just need to learn and move forward, and from the looks of things we have. Gentoo always has been a fairly disruptive distro, though it has settled down of late. I don't think we're erring on the side of breaking systems too often right now, though I'm always for preventing that as long as it doesn't require ossification. (Just a note - this is all based on what I could piece together from cvs and bugzilla. I'm sure those who were personally involved could contribute more detail. I'm not sure it is necessary that do so, but I'll gladly defer to those with firsthand knowledge.) In the end, stuff only gets done if people write code. Your power in any FOSS project really comes down to your ability to write code or convince others to write code on your behalf. No, it's more about your ability to commit and get away with it. So, I'm 100% for what Donnie said and in general I tend to lean towards saying thanks, but no thanks when a heavy contributor is driving everybody nuts. However, the reality is that those who commit more also tend to be allowed to get away with committing more. That's just human nature - we all like our free toys and we're reluctant to take too much objection when we're slapped around a little by the guy who is giving us the free toys. There needs to be a balance, and from the sound of things Markos is looking to step in and adjust the balance if it gets out of line. Honestly, I just wish everybody would do what they can to make his job easier, and I say that without pointing my fingers in any direction. I think we have a really great thing going here... Rich Markos has shown initiative and good ideas, so I'm looking forward to positive changes. I am also cautiously optimistic about a renewed QA team, which could be involved more in this kind of issues. As I see it now
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
On 8 November 2013 08:55, Rémi Cardona r...@gentoo.org wrote: 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. Since this thread was deemed necessary, apparently it's not. Or at least not clearly stated. Ebuilds should - at the very least - mirror what upstream's build script requires. And they do. Strictly spoken, we do not support ebuilds / versions that are not (or no longer) in the tree. If the user chooses to use ebuilds / versions we don't support, they are on their own. That said, we can do it as a courtesy to users, when it is brought to our attention. But it's more of an enhancement than a bug, in my opinion. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec
On 3 November 2013 17:02, Alan McKinnon alan.mckin...@gmail.com wrote: On 03/11/2013 01:45, yac wrote: Afaik there is no official way to update gentoo, is there? It's always been emerge -avuND world I personally got used to -uaNDv and I don't even know what exactly is the difference and it's implications between that and just -uD the difference is -N, it's in man emerge We really should change this recommendation to --changed-use instead of -N. But we also need a short option for that. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
On 14 October 2013 03:32, William Hubbs willi...@gentoo.org wrote: All, from what I'm seeing, we should look into converting /etc/mtab to a symlink to /proc/self/mounts [1]. Are there any remaining concerns about doing this? If not, it seems like it would be pretty easy to make baselayout create this symlink in the stages (I'm willing to do this work), but what about on systems that are already installed? Should we send out a news item and have everyone convert their /etc/mtab manually or find a way to automate that? William [1] http://bugs.gentoo.org/show_bug.cgi?id=477498 I don't see a compelling case being made for why we should make this change apart from all the other distros are doing it, and quite a few reasons why we shouldn't. I'm open to being convinced, so please tell me why this is good for Gentoo users. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Re: sys-kernel/tuxonice-sources up for grabs
On 23 September 2013 08:14, Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/09/13 08:21 PM, Rick Zero_Chaos Farina wrote: On 09/21/2013 08:44 AM, Pacho Ramos wrote: El sáb, 21-09-2013 a las 14:42 +0200, Pacho Ramos escribió: I don't have time for it for a long time (since I switched to official suspend time ago and moved back to gentoo-sources then), updated patches are periodically generated and put at: http://tuxonice.nigelcunningham.com.au/downloads/all/?C=MO=D Feel free to get it if you want It goes with tuxonice-userui Is any of this really needed anymore? I suspend/hibernate/resume with gentoo-sources and hardened-sources Does it really make sense to hold on to tuxonice still? -Zero Admittedly I haven't looked into this, but I believe tuxonice-sources is still required if you wish to use a hibernation file rather than a swap partition. There are numerous other features to, iirc, that users may want that the kernel just doesn't offer. Tux-on-ice patches are also included in pf-sources, so those who want it can get it that way. Then we may not need to maintain separate tuxonice-sources. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] [RFC] git.eclass, git-2.eclass... git-r1.eclass?
On 28 August 2013 16:00, Michał Górny mgo...@gentoo.org wrote: Hello, all. I think I'm finally ready to put all the breaking awesomeness that was waiting for the git eclasses. However, I'm wondering what's the best way of proceeding with it. We've just lately finished the git-git-2 eclass migration. The old eclass is no longer used and is marked for removal in a few days. [...] However, I would like to do a few breaking changes to simplify the eclass and its maintenance: [...] But it's not all removing. There are also a few things I would like to change/add: [...] How should I proceed? Assuming that git-2.eclass is used by live ebuilds only, and those ebuilds can be subject to random breakage, I could supposedly just start changing API of the eclass. On the other hand, I could also go for beautiful git-r1.eclass, and cleanly switch the packages. Then, I could go for something involving the two -- create a new git-r1.eclass that has API fully stripped, and start deprecating features from git-2.eclass. We would be able to switch to git-r1 to test offending packages safely, then do a big switch of remaining packages and make the two eclasses temporarily equivalent. What are your thoughts? You are planning to do more than trivial changes, so you should make a new eclass (-version). Ebuilds rely on eclass functionality to be stable, so please don't introduce unnecessary breakage. This is another indication that we really need a better mechanism for eclass versioning. But that would deserve it's own separate thread. As for naming, I recommend you do a +1 to avoid confusion, so git-3.eclass, or git-r3.eclass. Again, here it would be good to agree on a convention for everyone to follow. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Moving more arches to dev profiles
On 22 August 2013 18:01, Rich Freeman ri...@gentoo.org wrote: On Thu, Aug 22, 2013 at 1:39 AM, Ben de Groot yng...@gentoo.org wrote: On 22 August 2013 01:19, Matt Turner matts...@gentoo.org wrote: On Wed, Aug 21, 2013 at 8:50 AM, Markos Chandras hwoar...@gentoo.org wrote: Is there an alternative? afaik a profile can be either stable,dev or exp. I can't see how we can implement something between stable and dev. And what would that represent? It may or may not be stable? If this is the case, then I believe ~arch is more preferred. I haven't read much into it, but Fedora has a concept of Secondary Architectures. I think it would make sense if we could keep stable keywords for them, but not prevent maintainers from needing to wait on them to stabilize other packages. I don't see how that would work. You can't remove older versions unless a newer one is stabilized, or you'd break the tree. Sort-of. You'd break it in that users would have to accept ~arch to keep that package, or remove it. It is really no different than dropping stable keywords which forces them to do the same thing, except that you're doing it one package at a time. You could impose a time limit to respond to the STABLEREQ prior to removal (30-60 days or something). The problem is with reverse dependencies. We had this a while ago with Qt libraries, and I ended up needing to mask a whole list of packages on two slacker arches. That's more trouble than it's worth for me. In my opinion we should only bother with stabilization on the most widely used arches: amd64, x86, and arm. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Moving more arches to dev profiles
On 21 August 2013 19:04, Markos Chandras hwoar...@gentoo.org wrote: Hi, It's time of year again to consider moving a few arches to dev-only status. I propose the following arches to lose their stable keywords - s390 - sh - ia64 - alpha - m68k - sparc ++ And consider adding ppc and ppc64 to that list. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Sets in the tree
On 21 August 2013 23:03, Sergey Popov pinkb...@gentoo.org wrote: 15.08.2013 12:12, Pacho Ramos пишет: El mié, 14-08-2013 a las 15:17 +0100, Ciaran McCreesh escribió: Ah, looks like I was too optimistic and we are (again) with the usual blocking (and blocker) issues -_- (PMS refusing to include something because of lack of documentation :S) And they are right at this point. How you can include something into standard, that is not documented? Documentation of how to use sets(for users) is not enough in this case, IMHO. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop-effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead So let's get a proper spec and documentation! Because sets can be very useful, as I'm sure everyone will agree. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Moving more arches to dev profiles
On 22 August 2013 01:19, Matt Turner matts...@gentoo.org wrote: On Wed, Aug 21, 2013 at 8:50 AM, Markos Chandras hwoar...@gentoo.org wrote: Is there an alternative? afaik a profile can be either stable,dev or exp. I can't see how we can implement something between stable and dev. And what would that represent? It may or may not be stable? If this is the case, then I believe ~arch is more preferred. I haven't read much into it, but Fedora has a concept of Secondary Architectures. I think it would make sense if we could keep stable keywords for them, but not prevent maintainers from needing to wait on them to stabilize other packages. I don't see how that would work. You can't remove older versions unless a newer one is stabilized, or you'd break the tree. One option I see is to limit the amount of packages with stable keywords to a select list, e.g. @system and closely related packages, and refuse stable keywords for GUI toolkits and their desktop reverse dependencies and the like. Ago is doing a fantastic job, but it would be good to lower his work-load and reduce the bus factor problem. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] gtk2/gtk3 use flags
On 21 August 2013 07:36, Gilles Dartiguelongue e...@gentoo.org wrote: Le mardi 20 août 2013 à 17:31 +0400, Sergey Popov a écrit : 16.08.2013 21:15, hasufell пишет: https://bugs.gentoo.org/show_bug.cgi?id=420493 gtk2 and gtk3 useflags are discouraged and should only be used in special cases file a bug for those if there is not one already What's about maintainer wish to support both of toolkits? I have dropped GTK2 support in gtkdiskfree[1], but it seems that proxied maintainer will quit if i keep things that way :-/ The upstream maintainer is free to support both toolkits if he wishes to do so, but we strongly recommend to only select one slot for applications in gentoo tree, the one which works best for the application. -- Gilles Dartiguelongue e...@gentoo.org Gentoo When upstream supports both, and the maintainer wishes to do so as well, I would strongly recommend to support both, so that end-users can make their own choices. Some may wish to use the applications in a light-weight gtk2-only environment such as LXDE. As long as gtk+:2 is supported in the tree, I don't see why we should artificially restrict such choices for our users. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] rfc: stabilization policies
On 21 August 2013 04:12, Michael Orlitzky mich...@orlitzky.com wrote: [snip] Ok, this one is ridiculous. The stable version of Rails is 2.3.18, and 3.0 was released almost exactly three years ago. Every time rails-3.x gets bumped, I have to manually update the entire list above. I need to do it on an x86 server as well, so I get to do it twice; I can't even copy/paste the list. Yes you can. Just leave out the actual keyword. It will assume ~arch. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] gtk2/gtk3 use flags
On 17 August 2013 01:12, Michael Weber x...@gentoo.org wrote: Hello, gtk is a global use flag [1], gtk2 and gtk3 are used in metadata.xml [2]. Is there a consensus how to use these flags if an app provides gtk2 and gtk3 gui in parallel or exclusive? Michael [1] /usr/portage/profiles/use.desc gtk - Add support for x11-libs/gtk+ (The GIMP Toolkit) [2] egrep gtk(2|3) /usr/portage/profiles/use.local.desc app-admin/gtkdiskfree:gtk3 - Use GTK+3 instead of 2 app-editors/emacs:gtk3 - Link against version 3 of the GIMP Toolkit instead of version 2 (x11-libs/gtk+) app-editors/emacs-vcs:gtk3 - Link against version 3 of the GIMP Toolkit instead of version 2 (x11-libs/gtk+) app-i18n/fcitx:gtk3 - Install GTK3 IM module app-i18n/fcitx-configtool:gtk3 - Use GTK+3 instead of 2 app-i18n/ibus:gtk3 - Enable support for gtk+3 app-i18n/ibus-anthy:deprecated - Install deprecated pygtk2 library app-i18n/ibus-unikey:gtk3 - Enable support for gtk+3 app-i18n/imsettings:gtk3 - Enable support for x11-libs/gtk+:3 app-i18n/scim:gtk3 - Enable support for x11-libs/gtk+:3 app-i18n/uim:gtk3 - Enable support for x11-libs/gtk+:3 app-office/libreoffice:gtk3 - Enable highly experimental gtk3 frontend dev-java/icedtea-web:gtk2 - Use x11-libs/gtk+:2 instead of x11-libs/gtk+:3 dev-java/icedtea-web:gtk3 - Use x11-libs/gtk+:3 (default) dev-python/matplotlib:gtk3 - Use x11-libs/gtk+:3 instead of x11-libs/gtk+:2 lxde-base/lxdm:gtk3 - Use GTK+3 instead of 2 mail-client/claws-mail:gtk3 - Build support for GTK+3 media-libs/libcanberra:gtk3 - Enables building of gtk+3 helper library, gtk+3 runtime sound effects and the canberra-gtk-play utility. To enable the gtk+3 sound effects add canberra-gtk-module to the colon separated list of modules in the GTK_MODULES environment variable. media-plugins/audacious-plugins:gtk3 - Link against version 3 of the GIMP Toolkit instead of version 2 (x11-libs/gtk+) media-sound/audacious:gtk3 - Link against version 3 of the GIMP Toolkit instead of version 2 (x11-libs/gtk+) media-sound/jalv:gtk2 - Adds support for GTK+2 in addition to GTK+3 controlled by the gtk useflag. media-sound/mp3splt-gtk:gtk3 - Link against x11-libs/gtk+:3 instead of x11-libs/gtk+:2 net-analyzer/wireshark:gtk2 - Build the wireshark executable with a GTK+ UI version 2. net-analyzer/wireshark:gtk3 - Build the wireshark executable with a GTK+ UI version 3. net-dns/avahi:gtk3 - Build the avahi-ui-gtk3 library, and use gtk3 for the avahi utilities under USE=utils net-libs/gtk-vnc:gtk3 - Build the gtk3 gtk-vnc library and other gtk3 assets net-misc/spice-gtk:gtk3 - Link against x11-libs/gtk+:3 instead of x11-libs/gtk+:2 net-p2p/eiskaltdcpp:gtk3 - Use x11-libs/gtk+:3 instead of x11-libs/gtk+:2 www-client/dwb:gtk3 - Link against x11-libs/gtk+:3 instead of x11-libs/gtk+:2 www-client/uget:gtk3 - Use x11-libs/gtk+:3 instead of x11-libs/gtk+:2 www-client/uzbl:gtk3 - Use x11-libs/gtk+:3 instead of x11-libs/gtk+:2 x11-themes/light-themes:gtk3 - Support GTK 3.x, too x11-wm/fvwm:gtk2-perl - Enable GTK2 Perl bindings -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org As mentioned on IRC, there's this: https://wiki.gentoo.org/wiki/Gnome_Team_Policies#gtk3 -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge
On 13 August 2013 13:21, heroxbd hero...@gentoo.org wrote: Dear Fellows, I would like to kick out a sub-project of Gentoo targeting smartphone and tablets. It would be nice to find out a solution based on Gentoo for desktop/smartphone hybrid *before* Canonical's release. I would be interested in such a project. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Sat, Aug 10, 2013 at 6:59 AM, Tom Wijsman tom...@gentoo.org wrote: Support for it is given all over the place; like for instance in #gentoo and #gentoo-desktop on the FreeNode IRC network, on the Gentoo Forums, on the gentoo-user ML as well as for bugs on the Bugzilla bug tracker. The people saying this is unsupported are either WISHING it was unsupported, or they are completely uninformed (w.r.t. systemd usability on gentoo) and are just here to express general anti-systemd sentiment. In either case, they are not really contributing anything worthwhile to this discussion. People are running gnome-3.8 and systemd today, on gentoo. It's working great for tons of people out there. We're supporting it in #gentoo and on the forums today, with much success. If you (people out there, not you Tom) don't realize that yet, please pull your head out of the sand. -Ben
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On 9 August 2013 21:57, Michał Górny mgo...@gentoo.org wrote: Dnia 2013-08-09, o godz. 13:45:25 Tom Wijsman tom...@gentoo.org napisał(a): On Fri, 09 Aug 2013 19:39:08 +0800 Patrick Lauer patr...@gentoo.org wrote: On 08/09/2013 07:26 PM, Tom Wijsman wrote: On Fri, 09 Aug 2013 19:31:22 +0800 Patrick Lauer patr...@gentoo.org wrote: You just removed the upgrade path for users. The upgrade path is to install systemd or to implement openrc support. Invalid upgrade path. The upgrade path is to install Fedora is about as reasonable, and also not acceptable. Your upgrade path is no longer an upgrade; the other ones are, and as said before, running Gentoo has no implication that OpenRC must be ran. I can think of at least a few examples where 'upgrade path' actually involved replacing one package with another and yet nobody complains about that. This one is *so special* just because we have a few folks which really have nothing useful to do and instead spit their systemd hatred on gentoo-dev@ and expect others to join their stupid vendetta. Please keep your insults off this list. You may want to deny them, but there are valid reasons why people oppose systemd. It doesn't help to keep so aggressively pushing it. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On 7 August 2013 20:45, Michael Weber x...@gentoo.org wrote: Greetings, Gnome Herd decided to target stablilization of 3.8 [1] which requires systemd. What are the reasons to stable 3.8 and not 3.6, a version w/o this restriction, enabling all non systemd users to profit from this eye-candy as well. I raise the freedom of choice card here. And deliberately choosing an uncooperative version doesn't shine a good light. People are free to use a saner desktop environment... -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 9:17 AM, Patrick Lauer patr...@gentoo.org wrote: Any users trying this sidegrade will be left without support and risk being ridiculed by annoyed bystanders. There are many of us supporting systemd + gnome 3.8 in #gentoo right now today, and I am strongly discouraging this ridicule. We also discourage ridicule when someone asks for support on KDE, Gnome, Pulseaudio, NetworkManager, proprietary drivers, or any of the other packages that tend to draw such polar opinions-- but are fully supported. I do think it's a good idea to get all this out in the open though-- make sure users know exactly what they're getting into, how much it's going to turn their gentoo world upside down (for a day or 2), WHY this is happening, and what the alternatives are. Most of this has been covered in this thread already. But it's not unsupported just because some people don't know how (or have no desire) to support it. As for the stabilization issue-- it seems like most people against stabilization just want ~arch as a barrier or whoa, wait up a sec warning to stable users don't stumble upon systemd, which makes sense. But I think there are better ways to accomplish this, rather than abusing keywords. -Ben
Re: [gentoo-dev] renaming gentoo-oldnet
On 4 August 2013 10:38, Brian Dolbec dol...@gentoo.org wrote: On Sat, 2013-08-03 at 21:03 -0500, Doug Goldstein wrote: On Sat, Aug 3, 2013 at 7:30 PM, William Hubbs willi...@gentoo.org wrote: On Sun, Aug 04, 2013 at 01:49:46AM +0300, Alon Bar-Lev wrote: On Sun, Aug 4, 2013 at 1:38 AM, William Hubbs willi...@gentoo.org wrote: OK... so gentoo-networking? or just come up with own name? best-networking? You and I have had this talk more times than I can remember at this point. Using the name oldnet sucks and was one of the worst choices possible. Looking through our IRC chats, I had also suggested gentoo-networking. How about gen-net? It's nice, short and the name is more flexible if the pkg is picked up by other distros (something bantied about during previous discussions). ++ -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] newsitem: Kernel Team vanilla-sources policy
On 4 August 2013 09:56, Alex Xu alex_y...@yahoo.ca wrote: Minor grammar/typographical errata: On 04/08/13 12:53 AM, Mike Pagano wrote: The Gentoo Kernel Team will no longer be providing stable vanilla-sources kernels. All currently stabilized vanilla-sources versions will be dropped to ~arch. The Arch teams, via normal requests of the Kernel Team, will continue to stabilize gentoo-sources kernels upon request. This decision is based on the facts that upstream is now releasing approximately 1-2 vanilla- try not to wrap vanilla-sources on the hyphen if possible sources kernels a week. Arch teams, understandable, are unable to keep up with s/understandable/understandably/ this rate of release. As most vanilla releases contain security fixes, the user who only runs stable vanilla-sources will consistently be behind and potentially at risk. For the latest upstream non Gentoo patched vanilla s/non Gentoo patched/non-Gentoo-patched/ or upstream kernel unpatched by Gentoo kernel, we recommend user add 'sys-kernel/vanilla-sources' to their s/user add/adding/;s/their/the/ or similar; recommend user add is not grammatically correct Make that: we recommend the user to add 'sys-kernel/vanilla-sources' to their package.accept_keywords file. (Note: their is perfectly correct usage as a gender-neutral reference to a singular person.) Alternatively: we recommend users to add package.accept_keywords file. Gentoo-sources will continue to be a tested and s/Gentoo-sources/gentoo-sources/ supported version for Gentoo users. s/\. /. /g (or vice versa) -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Vanilla sources stabilization policy change
On Wed, Jul 24, 2013 at 2:01 PM, Peter Stuge pe...@stuge.se wrote: To be clear: I am not suggesting to change the meaning of stable, I am suggesting that the latest available upstream kernel should perhaps be the default for Gentoo users. How to make that happen is less important, the idea to automatically mark v-s stable is only that, an idea. :) //Peter You seem to be ignoring the regressions that often come with new kernel releases, the very common breakage caused in stable genkernel all, and other various complications. Unleashing brand new kernel.org sources on stable users as soon as they are released seems crazy to me. These releases surely bring more than just the newest fixes. Going straight to stable is (in my eyes) so far from being a viable option, that always unstable, allow unstable if you're ok with the risk/benefit tradeoff seems like the best bet, to me. -Ben
Re: [gentoo-dev] Re: font.eclass add Xorg FontPath elements for non-standard paths
On 5 July 2013 06:36, Ryan Hill dirtye...@gentoo.org wrote: What you want is the font path element catalog and /etc/X11/fontpath.d (bug #185264) which I abandoned when I realized that no one actually uses fontpath anymore, that it caused the startup time to drastically increase with the number of installed fonts, and that adding your own fontpath entries is both trivial and documented everywhere. We should probably add this to our documentation, and link to that from a post-install message (using readme.gentoo.eclass). -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Proper distribution integration of kernel *-sources, patches and configuration.
On 1 July 2013 22:41, Tom Wijsman tom...@gentoo.org wrote: ### TL; DR ### By introducing feature patches which menu options are disabled by default to genpatches, we can deduplicate *-sources maintainers as well as large groups of users work. By introducing a distribution section in the menuconfig, we can provide options that enable minimal Gentoo requirements by default (DEVTMPFS, making Gentoo systems bootable since an udev release a long time ago) and other distribution stuff. Sounds like a great idea to me! -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
On 26 May 2013 02:13, Markos Chandras hwoar...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/25/2013 05:14 PM, Ben de Groot wrote: But if a co-maintainer pushes through a change that I oppose, then working together becomes quite difficult. In this case I opted to give up maintainership. Ben, We've been working together, in the same team(s), for more than 4 years and we never had a single problem in co-maintaining packages. I would never expected you to make so much noise because I committed a file (yes a file, *not* a patch) that changes absolutely *nothing* to existing users but it helps all those users who want to use systemd. I am very disappointed and confused. You should have known me better by now. It is exactly because of our good history together that I was so surprised and disappointed to see you disregarding my opinion in this, and dismissing it as my problem. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
On 26 May 2013 01:00, Pacho Ramos pa...@gentoo.org wrote: We can now have long discussions about upstream decisions, how to handle devrel problems... but I think it's much more easy: this kind of boycott attitudes should stop in favor of common sense. Common sense would be to recognize that systemd is a bad implementation of a bad idea, and to boycott it distro-wide. But you know what they say about common sense... -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
On 26 May 2013 00:48, Michał Górny mgo...@gentoo.org wrote: On Sun, 26 May 2013 00:14:36 +0800 Ben de Groot yng...@gentoo.org wrote: Unless I am mistaken, we did NOT agree anywhere that Gentoo maintainers MUST add systemd support when upstream does not ship such files. We did agree that Gentoo maintainers are not supposed to work on enabling systemd support if they don't want to. OK, that sounds good. On the other hand, we also agreed that they shouldn't refuse unit files if anyone else does the work for them. Where is this policy documented? [...] And you misunderstood: it is systemd that is aggressively opposed to Gentoo. But apparently that doesn't bother some of our developers and Gentoo is becoming more and more welcoming to it. Protecting freedom through taking away the freedom of using systemd? Makes sense really. That would be similar to the way the GPL protects software freedom. Does that not make sense to you either? But it isn't even like that. I'm not taking away anyone's freedom to use systemd. You can do so if you wish. You can add unit files to your system by yourself, or use an overlay. There are various ways this could be realized even within Gentoo. But you seem to dismiss all of those, and will only be happy by forcing maintainers to add support to packages they maintain, even if they believe it is a bad idea. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On 26 May 2013 15:37, Michał Górny mgo...@gentoo.org wrote: On Sun, 26 May 2013 00:14:36 +0800 Ben de Groot yng...@gentoo.org wrote: Systemd is diametrically opposed to the FreeBSD, customization, extreme configurability, and top-notch developer community aspects of that. Systemd upstream developers have made it abundantly clear they are not interested in working with Gentoo developers to see to the needs of source-based distros. They stand for vertical integration instead of customization and configurability. And you misunderstood: it is systemd that is aggressively opposed to Gentoo. But apparently that doesn't bother some of our developers and Gentoo is becoming more and more welcoming to it. By the way, we should really keep the separation between systemd itself and the unit files. I agree that systemd is not the best thing we could have. But the unit file format is, er, good enough -- and has the advantage of eventually taking a lot of work from our shoulders. Although some of the ideas (esp. wrt targets) are near to crazy and awfully hard to understand, that's what we have and trying to do something else is eventually going to make people's lives harder. We should *really* work on supporting the unit files within OpenRC (aside to init.d files). That's a way to at least: a) reuse the work that has been done upstream already (when it was done), b) have common service names and startup behavior in all relevant distros (which is really beneficial to the users). Considering the design of OpenRC itself, it wouldn't be *that hard*. Actually, a method similar to one used in oldnet would simply work. That is, symlinking init.d files to a common 'systemd-wrapper' executable which would parse the unit files. I think this idea actually makes sense. Re-using upstream work seems a logical idea, and could ease maintenance. Of course the issue is whether the OpenRC devs see any benefit in this. On the completely different topic, I agree that systemd design is far from the best and the way it's maintained is just bad. I was interested in the past in creating an improved alternative using compatible file format and libraries, while choosing a better design, improving portability and keeping stuff less integrated. But the fact is -- I doubt it will make sense, much like the eudev project. And it will take much more work, and give much less appreciation. First of all, working on it will require a lot of work. Seeing how large systemd become and how rapidly it is developing, establishing a good alternative (even dropping such useless parts as the Journal) will take at least twice that work. Then, it will require people working on it. People who know the details of various systems and who are willing to spend their time on it. And there wouldn't be much of people really willing to work on it. The systemd haters will refuse the project because of its resemblance to systemd. The systemd lovers will refuse it because of its resemblance to systemd. And the OpenRC lovers will want to design it to resemble OpenRC which is just pointless. Then the few remaining people will find systemd 'good enough'. And even if there are a few people who will want to work on it, and design a 'good systemd', they wouldn't get much appreciation. Fedora definitely won't care for it. It would have to be really definitely awesome for most Linux distros to even notice it. And I doubt *BSD people would be interested in something external. It is possible that systemd upstream will steal a few patches or ideas from it. Yet they will never apply any of the really important changes, so the project will have to be maintained indefinitely. The only hope for it would be to win over systemd users which I doubt will happen. So there's a lot of work, no fame or money in it, and most likely more work being the only future. Anyone volunteering? I agree it would be pretty hard to carve out a niche for this. Personally I would see more in runit. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
On 26 May 2013 18:04, Rich Freeman ri...@gentoo.org wrote: On Sun, May 26, 2013 at 3:43 AM, Michał Górny mgo...@gentoo.org wrote: On Sun, 26 May 2013 15:23:44 +0800 Ben de Groot yng...@gentoo.org wrote: Where is this policy documented? Nowhere, I think. I've seen it coming in the late thread, looked common sense enough to me. If it is to be documented, I think we should document it in a more general fashion. To cover all stuff like completions, logrotate and so on. As others have already pointed out, we are an organization, not a CPU. We can't make EVERYTHING a rule, and devs should act in a cooperative manner so that this remains the case. Sure, this can be made into a policy, and if things get out of hand I'm sure it will be. I'm not quite sure I see the need yet, as we don't have an example yet of a maintainer not cooperating with the systemd team on the installation of init files (in the present example Ben isn't actually a maintainer, since he stepped down). In packages I maintain, I will not be adding any systemd related files. All bug reports requesting such additions will be closed as an upstream matter. If Ben wants to boycott systemd by not maintaining any packages that support it, that is his choice. I just suspect that the end result of that will be that he'll end up not maintaining much of anything. I'd hate to see that happen, as it would be a loss for Gentoo. But, frankly, letting any one person dictate the direction of the entire distro by essentially threatening to quit would be worse. Gentoo is evolving in directions I do not agree with. I am feeling less and less at home here. More and more often it seems I am the minority voice of protest. I am not enjoying this role, and increasingly the thought arises that I should just get out of people's way and find another place that is closer to my ideas of what a distro should be. Gentoo is about choice - and the nature of choice is that most of the choices it supports are ones that you wouldn't personally make. We do a reasonably good job letting everybody have their cake and eat it too. However, it really isn't an appropriate distro for absolute purists of almost any kind - it reeks of compromise. We package proprietary software (we don't redistribute the copyrighted parts), we more-or-less run on Windows/OSX, we support that X32 alternate architecture that some believe has no useful purpose, and so on. If you really want to influence the battle of the init implementations, then write code, not emails. I am not a programmer, I am a simple package maintainer. Maybe that is a wrapper that allows OpenRC to support systemd units. Maybe that is more functionality for OpenRC. Maybe it is something else. However, trying to influence things by just spitting into the wind isn't going to do much but get your face dirty. Sure, devs can quit, but that isn't just a loss for Gentoo. Frankly if your main goal in life is to avoid systemd then you're better off supporting Gentoo which is likely to support that option nearly forever far better than any other distro. If forcing Gentoo package maintainers to add systemd support to packages they maintain is your idea of the best option to avoid systemd, then I respectfully disagree. Obviously I have better (and more fun) things to do. -- Cheers, Ben | yngwin Gentoo developer
[gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
my wishes, I will remove myself as maintainer of this package. If having systemd@g.o (or any other alternative init system, or any other developer permitted by them or a higher instance) add just a few characters you never need to touch and changing an unit file you don't want is too much, then you're just stepping away from the collaborative effort that pursues the goal as stated on the about page of Gentoo; we're all in this together, don't make hate tear you apart. I am making a stand for what I believe in. That is not hate. I simply think that systemd is a bad idea. But if others want to make it work on Gentoo, that is their time to waste. For my part, I simply wish to not be forced to add support for it in packages I maintain. Are you going to stop maintaining any package alternative init system maintainers and users come nag you on? :( That is not what this is about. I will simply do the same as I already did on this bug: refer users to upstream. But if a co-maintainer pushes through a change that I oppose, then working together becomes quite difficult. In this case I opted to give up maintainership. [1]: http://www.gentoo.org/main/en/about.xml Hope you would reconsider, it isn't hard to CC systemd@g.o and let them add or change characters that don't stand in your way; in fact, when I'm bug wrangling I've started CC-ing them on any new systemd unit request bugs such they can help if the maintainer does not have knowledge in the area. I don't want to do that. And as long as I am not forced to do so, I will maintain the packages I maintain as I see fit. Similarly, I expect in the near future that OpenRC mantainers (and any other alternative init system maintainers) will do the same; because really, even some of our systemd developers are starting to forget how init files were implemented, nor are they able to easily test them. At least not until we get eselect init sorted out... :) -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Making systemd more accessible to normal users
On 15 May 2013 21:41, Fabio Erculiani lx...@gentoo.org wrote: Are we realizing that in order to keep systemd out of our way, we're currently writing and maintaining drop-in replacements for the features that systemd is already providing in an actively maintained state? openrc-settingsd was the first thing that we as Gentoo developers (Pacho?) had to write in order to merge GNOME 3.6 into our tree. It's well known that Gnome is part and parcel of the whole vertical integration circus. And (and!) how does all this fit together with eudev? If the idea is to either put logind in udev (thus, not creating a separate logind ebuild), it means that eudev is already a dead end for GNOME users, unless the eudev team is going to provide logind as well. I'm not sure what the eudev team is planning, but it's been working well so far for me. And since I don't use Gnome, it's not an issue as long as other desktop environments are not making the same mistakes. I don't want to start a flamewar here, I was the one who called Lennart software lennartware, but science is science, and a reality check had to be done: at some near point in the future, our users will be forced to replace udev/eudev with systemd. Like it. Or not. This isn't science. And unless you use Gnome, I don't see why we would be forced to use systemd. KDE, Xfce, LXDE and Razor-qt are still happy to support non-systemd operating systems. The way I see it is that Gnome is making itself more of a non-option on Gentoo, Slackware and BSD systems. While I successfully use both openrc and systemd, I _do_ think that (and expect to see) more and more users (and developers) will be switching to systemd. Is there anything we can do? Besides being prepared, I don't think so. Do we control upstreams? No, sorry. We don't control upstreams, but we still have choices. At this point I only see Gnome and udev upstreams who are forcing their users to use systemd. (There may be other projects too that I'm not aware of.) So what do we want to do then? Isolate from the rest of the world? (It's not a sarcastic question). I hope that everybody does their own reality check. We say that Gentoo stands for choice. That is why we should resist allowing systemd (and Gnome) to take those choices away with their mistaken idea of vertical integration. We do have other options. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] devmanual moved to github
On 12 May 2013 21:27, Peter Stuge pe...@stuge.se wrote: Rich Freeman wrote: The devmanual git repository[1] moved to github[2]. The only thing that isn't FOSS is github itself. Not sure if others feel strongly about it. I feel strongly against github. Making something like github the primary point of contact communicates many negative things for Gentoo IMO. On the technical level I think it's unneccessary and concretely unhelpful to limit a git repo workflow to the subset that github implements. I guess that Infra might also feel strongly about this. I hope Markos discussed the move with them already and that any concerns of theirs were understood. //Peter Just push to two remotes, like we have been doing for the qt overlay. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Making systemd more accessible to normal users
On 1 May 2013 18:04, Fabio Erculiani lx...@gentoo.org wrote: It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). In my opinion you should not be asking maintainers to add systemd units to their packages. They most likely do not have systems on which they can test these, and very few users would need them anyway. I would think it is better to add them to a separate systemd-units package. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Making systemd more accessible to normal users
On 8 May 2013 23:39, Fabio Erculiani lx...@gentoo.org wrote: On Wed, May 8, 2013 at 5:26 PM, Ben de Groot yng...@gentoo.org wrote: On 1 May 2013 18:04, Fabio Erculiani lx...@gentoo.org wrote: It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). In my opinion you should not be asking maintainers to add systemd units to their packages. They most likely do not have systems on which they can test these, and very few users would need them anyway. I would think it is better to add them to a separate systemd-units package. This sounds really wrong (tm) to me. It took me two weeks to kill that silly systemd-units pkg. All the distros around here do install systemd units with their packages and I believe that the council has already spoken about this. It sounds more wrong to me to be asking normal package maintainers to test and maintain unit files, while they don't use systemd themselves, nor have it installed. Nor would most of our users need this. And I believe the council has only spoken out against using a useflag for installing such files. Afaik they haven't spoken out against a systemd-units package. Please refer me to their decision if I'm wrong. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Making systemd more accessible to normal users
On 8 May 2013 23:49, Fabio Erculiani lx...@gentoo.org wrote: On Wed, May 8, 2013 at 5:39 PM, Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Ben de Groot schrieb: On 1 May 2013 18:04, Fabio Erculiani lx...@gentoo.org wrote: It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). In my opinion you should not be asking maintainers to add systemd units to their packages. They most likely do not have systems on which they can test these, and very few users would need them anyway. I would think it is better to add them to a separate systemd-units package. Note that a similar thing is already done with the selinux policy packages. Upstreams will _DO_ ship systemd units at some point in future. It's a completely different thing. Don't compare oranges to apples. Where upstreams ship systemd units, I don't think there is any issue. The problem is you are asking Gentoo maintainers to add unit files that upstream is not shipping. In this case we should test and maintain these ourselves, which is an additional burden for very little (if any) gain. Mostly the complaints against adding systemd units are that it would unnecessarily clutter non-systemd installs. Users who complain are told to set INSTALL_MASK but that is somewhat unwieldy. Cluttering a system by just installing 4kb files? The council has spoken. If you don't like the decision, I am sorry. I can say the same for init scripts, they are freaking cluttering my system and they're all over. Or perhaps all these man pages, I don't need man pages locally but still most ebuilds do install them. What do we do? Let's be serious here. You are forgetting that OpenRC is, and will remain for the foreseeable future, the default on Gentoo. Any systemd related files are completely useless for most of our users. And those of us who consider systemd a cancer do not want to see such files installed at all. Gentoo is about choice and configurability. This means we will accommodate both sides: so those who want to use an alternative init system can do so, and those who want to avoid it can also keep doing so. A separate package for the unit file would solve this problem nicely. No, it will generate a gazillion of other problems. Like conflicts arising every single day, just to name one. I think you are making the problem bigger than it is. Are there really that many packages that need a unit file, but upstream doesn't ship them yet, and many that are in the process of changing that? Either way, it should be an easy fix for systemd enthusiasts. Is that hard to do it right, as everybody else in this world does, and move on? Gentoo is different. If we should do what everybody else does, then there is no reason for our existence. Another option would be to add a dounit command to a future EAPI (like doinitd today) and make portage install them unless FEATURES=nounit (like nodoc/noinfo/noman today). Why all this mess!? You know very well why. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Packages using -Werror
On 3 May 2013 12:09, Ryan Hill dirtye...@gentoo.org wrote: Most of the bugs filed on the gcc 4.8 tracker so far have been caused by packages being built with -Werror. I just noticed one package where the Makefile was being patched to remove -g from CXXFLAGS but -Werror on the same line was left in. Just in case people weren't aware, building with -Werror is a bad idea and against policy*. If you're fixing one of these bugs by silencing the warning be sure to remove the flag also. Thanks! https://bugs.gentoo.org/show_bug.cgi?id=werror http://blog.flameeyes.eu/2009/02/future-proof-your-code-dont-use-werror * said policy might not actually exist in writing outside of the mailing list. still a bad idea though. -- gcc-porting toolchain, wxwidgets @ gentoo.org If this is a policy, it should be documented in our devmanual. Personally I've always thought -Werror is a mistake in release code, but was accepted practice. I've almost never actively removed it from packages I maintain. That will change now, upon learning of this policy. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Packages using -Werror
On 3 May 2013 16:36, Kacper Kowalik xarthis...@gentoo.org wrote: On 03.05.2013 10:06, Ben de Groot wrote: On 3 May 2013 12:09, Ryan Hill dirtye...@gentoo.org wrote: Most of the bugs filed on the gcc 4.8 tracker so far have been caused by packages being built with -Werror. I just noticed one package where the Makefile was being patched to remove -g from CXXFLAGS but -Werror on the same line was left in. Just in case people weren't aware, building with -Werror is a bad idea and against policy*. If you're fixing one of these bugs by silencing the warning be sure to remove the flag also. Thanks! https://bugs.gentoo.org/show_bug.cgi?id=werror http://blog.flameeyes.eu/2009/02/future-proof-your-code-dont-use-werror * said policy might not actually exist in writing outside of the mailing list. still a bad idea though. -- gcc-porting toolchain, wxwidgets @ gentoo.org If this is a policy, it should be documented in our devmanual. It is [1] Cheers, Kacper [1] http://devmanual.gentoo.org/ebuild-writing/common-mistakes/ Thanks! We stand corrected. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] FYI: emul-linux-x86-xlibs deps being replaced in gx86
On 22 April 2013 21:51, Alexis Ballier aball...@gentoo.org wrote: On Mon, 22 Apr 2013 20:21:55 +0800 Ben de Groot yng...@gentoo.org wrote: It should come as no surprise that I am not happy with this. While I applaud your efforts to attempt to improve the multilib situation, I don't think we are quite at the stage yet where this can be pushed as the default choice, as you are doing now. In my opinion this belongs in an overlay for further development and much more extensive testing. You are now pushing this to ebuilds that may very well go stable within weeks — unless I'm missing something and you are masking these features / useflags on stable. It is not default unless abi_x86_32 friends are enabled; old behavior is preserved until these flag are default in multilib profiles. It is also not stable until the multilib deps are stable, which is independent of packages having the || dep being stable. If there is a need then useflags can be masked on stable also so that, again, behavior remains the same on stable. Alexis. Alright, that wasn't immediately obvious. That does make these changes more acceptable. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] libpng 1.6 upgrade and subslotting (and misuse of subslotting when there is also normal slotting)
On 6 Apr, 2013 4:46 AM, Samuli Suominen ssuomi...@gentoo.org wrote: libpng 1.6 is in portage, but temporarily without KEYWORDS, pending on testign and this conversion, help would be much appericiated with converting the tree to use automatic rebuilds for the upgrade Because there is binary-only SLOT=1.2 of libpng, none of these are correct: $ grep -r 'media-libs/libpng.*:=' */*/*.ebuild app-misc/tracker/tracker-0.14.4.ebuild: =media-libs/libpng-1.2:= app-misc/tracker/tracker-0.14.5.ebuild: =media-libs/libpng-1.2:= app-misc/tracker/tracker-0.16.0.ebuild: =media-libs/libpng-1.2:= app-misc/tracker/tracker-.ebuild: =media-libs/libpng-1.2:= media-gfx/digikam/digikam-3.0.0.ebuild: media-libs/libpng:= media-gfx/digikam/digikam-3.1.0.ebuild: media-libs/libpng:= media-plugins/gst-plugins-gl/gst-plugins-gl-0.10.3.ebuild: =media-libs/libpng-1.4:= media-plugins/gst-plugins-libpng/gst-plugins-libpng-1.0.5.ebuild:RDEPEND==media-libs/libpng-1.4:= media-plugins/gst-plugins-libpng/gst-plugins-libpng-1.0.6.ebuild:RDEPEND==media-libs/libpng-1.4:= www-client/chromium/chromium-27.0.1453.12.ebuild: media-libs/libpng:= www-client/chromium/chromium-27.0.1453.3.ebuild: media-libs/libpng:= www-client/chromium/chromium--r1.ebuild:media-libs/libpng:= They should all be :0= to avoid matching the :1.2 SLOT. Plus some hundreds are completely without subslotting: $ grep -r 'media-libs/libpng' */*/*.ebuild |grep -v ':.*=' output - http://bpaste.net/show/89268/ Thanks, Samuli This would be a good opportunity to use the latest eapi in all those packages. Would adding the :0= slot operator, and upping the eapi, warrant a revbump tho, or can we simply do it “in place?
Re: [gentoo-dev] Re: Expanding categories' descriptions
On 2 April 2013 19:01, Sergey Popov pinkb...@gentoo.org wrote: 01.04.2013 11:52, Michael Palimaka пишет: On 1/04/2013 04:29, Denis M. wrote: I think it's a good idea to expand the categories' descriptions (found in the corresponding metadata.xml files) with more accurate descriptions of which packages are welcome to fit in which categories. If expanding the metadata.xml files does not seem a good idea, we should at least make a little bit more comprehensive description somewhere in the gentoo.org/doc/ or wiki.gentoo.org pages. What do you think about it? Sounds good to me. From time to time I see even experienced developers not sure as to which category a package belongs. There is also inconsistency with packages of a certain type being spread over multiple categories. For example, packages containing password manager in the description currently exist in three different categories. +1 for that. I was really confused(tbh, i am confused even now) about x11-apps/x11-misc categories, for example. Sometimes it is really not clear where package should goes. Another example - app-admin/ansible. Some devs thinks that it should be sys-cluster/ansible, but i put it into app-admin/, relying on app-admin/puppet as an example. So, some sort of clarification for such noobs, like me, would be really appreciated :-) I agree that it is a good idea. I also tried to be explicit when I added the dev-qt category. I'm sure we can benefit from more precise descriptions for all categories. So please come with some suggestions to get the ball rolling! -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] bash-3.1 stable
On Tue, Apr 2, 2013 at 9:39 AM, hasufell hasuf...@gentoo.org wrote: On 04/02/2013 04:01 PM, Markos Chandras wrote: Here we go again. Fine, keep arguing about the really important question why old X is in the tree when new X is stable. Did anyone actually consider to ask the maintainers instead of opening a public debate on this? I guess no, because bikeshedding in the mailing list is so much better. I am sorry about that. In fact I was about to file a bug, but then decided to take it up here and CC base-system. That was probably a mistake. Thanks to everyone for the comments... or not. People who are not interested in this topic should ignore the thread, it's not necessary to reply with the word bikeshedding every time you see a thread that you consider mundane or trivial. I was looking forward to hearing some insights on why bash-3.1 is still around, when I get sick of hearing about it, I'll stop following the thread. -Ben
Re: [gentoo-dev] Last rites: app-text/cuneiform
On 24 March 2013 22:48, Markos Chandras hwoar...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/24/2013 12:40 PM, Rich Freeman wrote: On Sun, Mar 24, 2013 at 8:31 AM, Markos Chandras hwoar...@gentoo.org wrote: I don't mind adding that link to every package mask. Do note thought that this is not the only way for a package to be rescued (assuming it can be rescued). Providing fixes without becoming the maintainer is also a viable solution, which is probably something we need to add to that page as well. I started something at: http://dev.gentoo.org/~rich0/treeclean.txt It needs some work, and guidexmlification. However, I tried to hit some of the alternatives. I don't think we need to create a new page for that. Just put all this text into the treecleaners page. I suggest putting it in the wiki instead. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] New install isos needed
On Mon, Mar 25, 2013 at 8:45 AM, Rich Freeman ri...@gentoo.org wrote: Tend to agree. To install Gentoo you really just need a shell, the ability to partition and create filesystems, some basic networking (even that is somewhat optional), and a text editor. Sure, a browser and such is a real nice-to-have, as would be something nicer than nano, but you really don't need them to install Gentoo. As an experienced user, it's fairly easy to run through the basic gentoo install procedure from just about any root-on-linux login prompt you can find. But like it or not, some new users do depend on a certain amount of consistency and and blindly-trusted copy-paste-ability. Even the gentoo-based sysresccd deviates enough to make things interesting at times. As cool as zsh is, having it as the default shell (with non-gentoo-standard prompt) IS going to throw some people for a loop. Not to mention the polluted environment issues (ie $path set after chroot). I think it's important that our officially-endorsed iso stays closely tied to the standard gentoo setup. For the new user experience, I don't think any old linux iso will do just fine applies. BTW I just quoted your one paragraph because I definitely agree with everything else you said. -Ben
Re: [gentoo-dev] New install isos needed
On Sun, Mar 24, 2013 at 6:33 AM, Alexander Berntsen alexan...@plaimi.netwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Making an install ISO is as pointless as writing a CMS for Gentoo.org... Gentoo should only bother if it is really necessary. ZSH-related bugs fixed ? Link SystemRescueCD : Link something else I really feel like we should still have an official minimal iso, but there is no reason it needs to be on the same schedule as the weekly stage3 autobuilds. It doesn't even need to be autobuilt at all, a couple of hand-rolled hand-reviewed releases a year, or as-needed based on new features that show up. -Ben
Re: [gentoo-dev] New install isos needed
On Sun, Mar 24, 2013 at 2:46 PM, Alexander Berntsen alexan...@plaimi.netwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 24/03/13 20:32, Ben Kohler wrote: I really feel like we should still have an official minimal iso Feelings do not matter. - -- Alexander As a very active contributor in #gentoo, assisting new users every day with their first-time gentoo installs, I strongly believe it's important that we have an official install medium upon which the official installation handbook is based. But I would also like to see the handbook expanded a bit to make it clear that nearly any other livecd can be used, when the official minimal cd has bugs or just lacks some features for a special setup. -Ben (iamben @ freenode)
Re: [gentoo-dev] New install isos needed
On Sun, Mar 24, 2013 at 2:46 PM, Alexander Berntsen alexan...@plaimi.netwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 24/03/13 20:32, Ben Kohler wrote: I really feel like we should still have an official minimal iso Feelings do not matter. - -- Alexander Just to add a bit more, to get across the point that I'm not just some random whining user-- most of the major bugs on our stage3s and minimal isos in the last 6 months or so were reported by me. The firmware issue that sparked this thread, was reported, investigated, and solved by me. BUT I don't think that we should scrap the gentoo minimal iso, just change the release schedule processes. -Ben
Re: [gentoo-dev] New install isos needed
On 24 March 2013 09:17, Dale rdalek1...@gmail.com wrote: Andreas K. Huettel wrote: Am Samstag, 23. März 2013, 21:40:16 schrieb Markos Chandras: Why not officially recommend SystemRescueCD instead? Looks really bad to recommend another installation media (even if it is based on Gentoo) to people who want to install our distro. I'd rather Gentoo recommended the live DVDs we do from time to time than having these autobuilds around that seem to break far too often. Except for the fact that downloading a DVD is slightly different from downloading a CD... Seriously. SystemRescueCD is more or less exactly what we would need. Has anyone ever approached the SystemRescueCD developers? I must confess, I have not used the official Gentoo ISOs in ages. I use the SystemRescueCD from a USB stick all the time. Me too. Our minimal CD is too minimal for my tastes (no X, no GUI browser for documentation), and our DVD too heavy. SystemRescueCD seems to hit the sweet spot. Maybe we could do a co-branded edition once in a while? -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Re: Last rites: media-tv/tvtime
On 24 March 2013 09:19, Nikos Chantziaras rea...@gmail.com wrote: On 24/03/13 02:12, Markos Chandras wrote: On 24 March 2013 00:02, Nikos Chantziaras rea...@gmail.com wrote: AFAIK, tvtime has no alternatives at all. If it goes, analog TV users can't watch TV anymore :-/ Nothing I can do. It has no maintainer and quite a few outstanding bugs. If people need it, they should probably move it to a local overlay. Shouldn't this be marked as maintainer-needed instead of dropping it? If it didn't have unadressed open bugs. But as it is, it needs some maintainer love, or otherwise tree-cleaning. Users who want to keep this in portage need to step up for proxy-maintainership and address the open bugs. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] [RFC] New category for LeechCraft
On 6 March 2013 15:07, Maxim Koltsov maksbo...@gentoo.org wrote: Hi, Currently there are 61 leechcraft packages in tree scattered across several categories. We propose to move them to one new category to make maintaining easy as well as rsync --exclude'ing. So, two questions: 1) Do you agree with adding new category? I don't see why not. 2) How should we call it: app-leechcraft, leechcraft-base or anything else? Yes, something like that. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] The Gentoo Qt Project wants your help!
On 2 March 2013 15:57, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 02/03/2013 07:54, Ben de Groot wrote: 1. Get Qt5 ready for inclusion in the tree. This includes writing and improving ebuilds and eclasses, testing to build those, filing bug reports on failure, finding fixes for those bugs, reporting problems upstream. We do development in the qt overlay, using git. If you decide to work on Qt5, my suggestion if for somebody to proxy it on main tree *under package.mask* and shoot me an email. Leveraging the tinderbox will at least allow you to find failure points. It's basically Davide (pesa) working on it now, but he doesn't have enough time to do all the work needed. We have most of the basic parts ready in the overlay. But we will discuss it in our meeting this weekend. When we move it to the tree, we will follow your advice and have it masked initially, so we can get a tinderbox run and some more people testing it. Thanks for the offer! -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] The Gentoo Qt Project wants your help!
On 2 March 2013 20:26, Jauhien Piatlicki jpiatli...@gmail.com wrote: 02.03.13 07:54, Ben de Groot написав(ла): app-admin/keepassx app-text/goldendict If these two packages need a maintainer, I could proxy-maintain them. I'm not a developer, but I have some experience with ebuild writing. Yes. They are not high-maintenance, but someone keeping an eye on version bumps and bug reports would be helpful. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] The Gentoo Qt Project wants your help!
On 2 March 2013 20:33, Samuli Suominen ssuomi...@gentoo.org wrote: On 02/03/13 08:54, Ben de Groot wrote: The Gentoo Qt Project wants your help! sci-calculators/qalculator This project died after the first betas. I propose treecleaning it. We have plenty of more maintained calculators in tree. If it is dead upstream, then yes, maybe we should consider treecleaning it instead. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] The Gentoo Qt Project wants your help!
On 2 March 2013 22:35, Tom Wijsman tom...@gentoo.org wrote: I first thought it was a binary, but now that I see it is actually compiled from source in the avidemux build process, we have control over it. Therefore, I'll step up to be the primary maintainer. Do you want me to keep the Qt herd in the metadata.xml as secondary? No, I don't think that's necessary. Keeping it in video herd makes more sense. Even if that wasn't the case, separate package doesn't make sense, USE=+system-libs might Agreed, an USE flag makes much more sense! I didn't consider this because I thought it was a binary. Sadly the system library doesn't work well with avidemux because it doesn't have any of these useful patches; but indeed, together with mantainers of this package on other distributions we should be able to push some patches upstream... Therefore, I think we should keep USE=system-libs until avidemux is properly tested to make USE=+system-libs appropriate. If avidemux keeps patching ffmpeg (beyond line-endings), I don't think it is wise to make system-libs the default. I originally took on this package when I became a Gentoo dev ~5 years ago, but I hardly use it anymore and I don't have the time to maintain this. Thanks for stepping up. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
[gentoo-dev] The Gentoo Qt Project wants your help!
The Gentoo Qt Project wants your help! == The Gentoo Qt Project is a small team responsible for maintaining the Qt libraries and associated applications within our beloved distro. Over time the number of packages we maintain has grown. Not only is there quite some work to be done to get the shiny new Qt5 version ready for the portage tree, we now also have our own light-weight Qt-based desktop environment in Razor-qt, as well as a growing number of Qt-based applications. Recently a few of our team members have left to do other things, so we are looking for new people to help us out! Whatever your skill level, there is probably something you can do to help! We specifically are looking for people to help us to do the following: 1. Get Qt5 ready for inclusion in the tree. This includes writing and improving ebuilds and eclasses, testing to build those, filing bug reports on failure, finding fixes for those bugs, reporting problems upstream. We do development in the qt overlay, using git. 2. Application maintenance. At the moment we simply don't have the manpower to actively maintain all Qt-based applications that we have an interest in. A number of those could use a more dedicated maintainer. This can be either a Gentoo developer or a proxy-maintainer. You would be responsible for spotting version bumps, updating ebuilds, handling bug reports and contacting upstream developers where necessary. An overview of the packages we (co-)maintain is here: http://euscan.iksaif.net/herds/qt/ For a specific list of packages we could use help with, see below. 3. Bug handling. See http://tiny.cc/qtbugs for our open bugs. We can use help to test and confirm bugs and proposed patches; to see if bugs are filed upstream and if there are patches available; to keep an eye on bug-fix releases. 4. Documentation. We would like to see more user guides, and updates to our FAQ, on the Gentoo Wiki. What we can give you is a friendly developer team, with members spread all over the world; assistance with ebuild writing skills; commit access to a lively git-based overlay, even if you are not a developer; mentoring in case you do want to become a developer; a dedicated #gentoo-qt IRC channel; and the satisfaction that you help improving Gentoo, the distro we all love. You can contact us on q...@gentoo.org, or the #gentoo-qt IRC channel. == New primary maintainer needed: == app-admin/keepassx app-cdr/acetoneiso app-editors/focuswriter app-editors/tea app-editors/znotes dev-python/pyside and related packages dev-util/beediff dev-util/eggy dev-util/monkeystudio media-sound/mp3diags media-video/avidemux (bundled libs) media-video/qx11grab net-im/psi (urgently needs to be updated to new release version) net-libs/qmf (needs gcc-4.7 fix) x11-misc/qtfm == We could also use a hand with: == app-text/goldendict dev-games/tiled dev-util/xxdiff media-gfx/nomacs media-sound/coquillo net-news/quiterss net-news/rssguard www-client/qupzilla x11-misc/basqet app-editors/qwriter app-editors/qxmledit app-emulation/qtemu app-mobilephone/past app-mobilephone/qtadb app-office/qchartdiary app-text/cb2bib dev-db/dbmodel dev-db/sqliteman dev-libs/qjson dev-libs/qoauth dev-tex/qtexengine dev-tex/texamator dev-util/qfsm dev-util/universalindentgui dev-vcs/hgview dev-vcs/qct dev-vcs/qsvn media-gfx/pencil media-gfx/pictureflow media-gfx/qosmic media-gfx/qvv net-analyzer/nmapsi net-ftp/oneclickftp net-ftp/qshare net-ftp/scythia net-im/qwit net-misc/dnetstats net-misc/netfleet sci-calculators/qalculator sci-visualization/kst x11-misc/okindd x11-misc/qps x11-misc/qsynergy x11-misc/tinymount -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project
On Fri, Feb 15, 2013 at 7:48 AM, Ian Stakenvicius a...@gentoo.org wrote: I expect to see the full result one would have to emerge -epv [package] , at least that will report the repos for all *DEPENDs (although it is a bit overkill to have users submit that in the general case) There are also commands like eix --installed-from-overlay to see at a glance what questionable packages may be in play. Clearly we have a dev or 2 with some overlay hate, but I don't really think that's relevant to this project discussion. It certainly shouldn't be a show stopper. -Ben
Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project
On 15 February 2013 22:34, Diego Elio Pettenò flamee...@flameeyes.eu wrote: (But I would still argue that spotting overlay usage is not always as simple; at least in one case I got somebody who was trying to hide their use of proaudio.) Users editing the output of emerge --info and hiding they overlay usage is another problem. Anyway, overlays are not going away, so we just need to streamline our process of dealing with the resulting bugs. To bring this back on topic, users are going to get tree-cleaned ebuilds anyway, putting them in their local overlays if they want to use these packages. We're just facilitating them with a more centralized solution for this, as there is obvious demand for it. Plus, this may be a stepping stone for users fixing those packages and taking up proxy-maintainership. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: Graveyard overlay (was: Re: [gentoo-dev] last rites: games-strategy/x2, games-strategy/x2-demo)
On 14 February 2013 20:25, George Shapovalov geo...@gentoo.org wrote: Um, what about the sunset overlay? IIRC, it was used/intended primarily for this purpose. Is it still alive? (haven't heard it mentioned in a while and layman seems to list onyl sunrise) You probably mean kde-sunset, which is specifically for Qt3/KDE3. But I guess we could consider merging kde-sunset with graveyard. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests
On 13 February 2013 15:07, Michael Weber x...@gentoo.org wrote: On 02/13/2013 12:28 AM, Robin H. Johnson wrote: On Wed, Feb 13, 2013 at 12:12:35AM +0100, Michael Weber wrote: On 02/12/2013 10:14 PM, William Hubbs wrote: If you have any questions on this, please feel free to let us know. What is the rotation strategy for (near) outdated keys? Alter the key or create a new one? Sign the new with the old one? If your keysize is still good, you should ideally update the expiry on the key and re-upload it to keyservers. Can you commit this to the document, please? IMHO the answer to these questions is not obvious nor given by (our) docu [1]. I'm pretty sure it was in the devrel developer handbook at one point, along with instructions to create your key, but I can't find it now. Maybe, add keep ldap id/fingerprint synchronized there, too. http://www.gentoo.org/proj/en/infrastructure/ldap.xml#doc_chap3 That does tell how to update the data, but does not suggest to do so. My main concern is the cross-referencing of our documentation. I'm aware that there is a ton of documentation splattered all over the place and outside our infra. But besides the non-trivial step to become a dev (as mentioned last week) there is a certain non-trivial step to keep one, esp. by gathering the non-routine informations and fast-forward developments. All pertinent information should be in the devmanual. If it's not, then this omission should be fixed as soon as possible. There is no reason to keep this scattered over multiple locations. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Graveyard overlay (was: Re: [gentoo-dev] last rites: games-strategy/x2, games-strategy/x2-demo)
On 14 February 2013 08:08, Florian Philipp li...@binarywings.net wrote: Am 14.02.2013 00:07, schrieb Brian Dolbec: Easy, just copy the ebuild and any patches in the files subdir to a local overlay. Which brings us back to the old discussion on what good it does for one person to do the work of masking and removing and N persons to do the work of creating an overlay instead of just letting the package rot in the tree until it is actually broken. But I guess everyone's pretty tired of that discussion so let's leave it at that. Okay, let's do this. Since the users don't seem to be able to organize themselves, I have taken the initiative to set this up. Currently there is the graveyard overlay on github, and I will be opening the required bug reports to get this mirrored on git.overlays.gentoo.org and included in layman's overlay list. I need two things: 1. Users volunteering some time to keep this running 2. Agreement on a place to host tarballs no longer hosted upstream People who are interested can contact me in the #gentoo-dev-help channel on Freenode. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations
On 10 February 2013 10:43, Douglas Freed dwfr...@mtu.edu wrote: * all 13.0 profiles have been created and are marked stable the same way as 10.0 was * all 10.0 profiles have been removed from profiles.desc * all 10.0 profiles have been deprecated Suggestion: perhaps a news item should be created for the migration to the new profiles? As a Gentoo user who just got a giant red warning from portage that his active profile was deprecated, I feel like many people are going to be confused about this. -Doug Obviously a news item should precede any deprecation of stable profiles. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
On 10 February 2013 20:11, Rich Freeman ri...@gentoo.org wrote: Otherwise, purpose-driven overlays just make sense - they allow a different set of contributors who are more familiar/interested in a set of packages to maintain them. It makes more sense to let those people be proxy-maintainers and keep those packages in the main tree. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: News item (was: Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations)
On 10 February 2013 23:02, Andreas K. Huettel dilfri...@gentoo.org wrote: Am Sonntag, 10. Februar 2013, 15:15:43 schrieb Markos Chandras: I suspect most people are interested in understanding what changed (since deprecation means that the new thing is better than the old one). Moreover, the news item is another way to assure them that everything is not as bad as the initial red warning might had made them think so and keep calm and use Gentoo ;-) OK, here's a news item (actually two, separate for server and non-server profiles). Since it's a bit late now, I'll commit this or the improved version after discussion here in 6h (21:00 UTC) unless there are severe protests. -- the non-server profile variant (sparing you a lot of Display-If-Profile lines) Title: New 13.0 profiles and deprecation of 10.0 profiles Author: Andreas K. Hüttel dilfri...@gentoo.org Content-Type: text/plain Posted: 2013-02-10 Revision: 1 News-Item-Format: 1.0 Display-If-Profile: default/linux/alpha/10.0 Display-If-Profile: default/linux/alpha/10.0/desktop [...] Display-If-Profile: default/linux/x86/10.0/desktop/kde Display-If-Profile: default/linux/x86/10.0/developer We have generated a new set of profiles for Gentoo installation. These are now called 13.0 instead of 10.0. Everyone should upgrade as soon as possible (but please make sure sys-apps/portage is updated to current stable *before* you switch profile). This brings (nearly) no user-visible changes. Some new files have been added to the profile directories that make it possible for the developers to do more fine-grained use flag masking (see PMS-5 for the details), and this formally requires a new profile tree with EAPI=5. -- the server profile variant (sparing you the headers entirely) We have generated a new set of profiles for Gentoo installation. These are now called 13.0 instead of 10.0. Everyone should upgrade as soon as possible (but please make sure sys-apps/portage is updated to current stable *before* you switch profile). This brings (nearly) no user-visible changes. Some new files have been added to the profile directories that make it possible for the developers to do more fine-grained use flag masking (see PMS-5 for the details), and this formally requires a new profile tree with EAPI=5. In the course of this change, the server profiles will be removed; they do not exist in the 13.0 tree anymore. You should migrate to the corresponding parent profile. This may change the default value of some use-flags. The specific setting in server was USE=-perl -python snmp truetype xml You may want to check the setting of these flags after switching profile, but otherwise nothing changes. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ Looks good to me! -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Rename Creative Commons license files?
On 8 February 2013 00:31, Alec Warner anta...@gentoo.org wrote: On Thu, Feb 7, 2013 at 8:07 AM, Ulrich Mueller u...@gentoo.org wrote: I always wondered why we are using such bulky names like CCPL-Attribution-ShareAlike-2.5 for the Creative Commons licenses, instead of CC-BY-SA-2.5 like everyone else. The latter also used by our documentation pages and is the name in the SPDX license list [1], So, while in general I'm against renaming of licenses (e.g., it would be pointless to rename our GPL-2 to GPL-2.0 in order to conform to the SPDX list), I think that in this case we should get rid of these long names which unnecessarily clutter the output of various tools. ask for forgiveness, not permission ;) -A The plan would be as follows: CC0-1.0-Universal - CC0-1.0 CCPL-Attribution-2.0 - CC-BY-2.0 CCPL-Attribution-2.5 - CC-BY-2.5 CCPL-Attribution-3.0 - CC-BY-3.0 CCPL-Attribution-NoDerivs-2.5 - CC-BY-ND-2.5 CCPL-Attribution-NoDerivs-3.0 - CC-BY-ND-3.0 CCPL-Attribution-NonCommercial-NoDerivs-2.0 - CC-BY-NC-ND-2.0 CCPL-Attribution-NonCommercial-NoDerivs-2.5 - CC-BY-NC-ND-2.5 CCPL-Attribution-ShareAlike-2.0 - CC-BY-SA-2.0 CCPL-Attribution-ShareAlike-2.5 - CC-BY-SA-2.5 CCPL-Attribution-ShareAlike-3.0 - CC-BY-SA-3.0 CCPL-Attribution-ShareAlike-NonCommercial-2.5 - CC-BY-NC-SA-2.5 CCPL-Attribution-ShareAlike-NonCommercial-3.0 - CC-BY-NC-SA-3.0 CCPL-Sampling-Plus-1.0- CC-Sampling-Plus-1.0 CCPL-ShareAlike-1.0 - CC-SA-1.0 In total, about 100 packages are affected. so it's a minor effort. Ulrich [1] http://www.spdx.org/licenses/ Yes please! -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] New eclass: cmake-multilib for cmake multilib package builds
On 6 February 2013 04:19, Michał Górny mgo...@gentoo.org wrote: The idea is the same as in autotools-multilib. The eclass is a straightfoward wrapper for cmake-utils which inherits multilib-build and runs cmake phase functions for all ABIs (using out-of-source build). The eclass uses the same header consistency check as autotools-multilib (therefore, I move the function to multilib-build). I'm attaching an ebuild for virtualgl as an example of use. I see no attachments... -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] New eclass: cmake-multilib for cmake multilib package builds
On 7 February 2013 16:36, Ben de Groot yng...@gentoo.org wrote: On 6 February 2013 04:19, Michał Górny mgo...@gentoo.org wrote: The idea is the same as in autotools-multilib. The eclass is a straightfoward wrapper for cmake-utils which inherits multilib-build and runs cmake phase functions for all ABIs (using out-of-source build). The eclass uses the same header consistency check as autotools-multilib (therefore, I move the function to multilib-build). I'm attaching an ebuild for virtualgl as an example of use. I see no attachments... Because you used separate emails. Ignore the noise please. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
On 1 February 2013 02:59, Pacho Ramos pa...@gentoo.org wrote: El dom, 27-01-2013 a las 18:47 +0100, Pacho Ramos escribió: El dom, 27-01-2013 a las 15:00 +0100, Pacho Ramos escribió: Currently, when people uses DOC_CONTENTS variable to place their desired messages, they are automatically reformatted by fmt to get proper messages (for example, splitting long lines). But, in some cases, may be useful to disable this behavior and respect strictly how DOC_CONTENTS was formatted, for example in that kind of messages telling people to run a command and, then, requiring a new line to be used. This can also be useful to append extra information to DOC_CONTENTS when, for example, additional info is needed when enabling a USE flag. Well, after reading man echo I see all this is not needed, I simply need to use echo -e to get it understand \n to create new lines New patch attached This will add an option to disabling autoformatting to let people get their doc_contents 100% respected if they want How about using an as-is argument to readme.gentoo_create_doc? That would be more concise. :-) -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
On 30 January 2013 05:47, Pacho Ramos pa...@gentoo.org wrote:
El mar, 29-01-2013 a las 14:03 +0800, Ben de Groot escribió:
On 29 January 2013 03:30, Pacho Ramos pa...@gentoo.org wrote:
El lun, 28-01-2013 a las 14:37 +0800, Ben de Groot escribió:
I've started using this eclass, but with README files, not the variable,
because this is currently the only way I can make sure it honours my
formatting.
Couldn't it be covered if echo -e was used (even with fmt) and you,
then, control formatting with some of the sequences it allows (they are
shown in its man page)?
No. The eclass should assume that DOC_CONTENTS is already correctly
formatted. If you must, you can add a convenience function for people
who do want reformatting, but this should NOT be the default. Please
don't make this eclass harder to use than it needs to be.
I can add a variable (and probably will), but would prefer to keep it
formatting messages by default, otherwise, how will you set DOC_CONTENTS
variable inside a pkg phase (instead of global scope) without adding
tabs to it? You can of course add it, but it will be read as something
like:
src_prepare() {
DOC_CONTENTS=blablabla
blablabla
# Rest of src_prepare stuff
}
I still prefer the eclass not to mess with formatting by default. You
can do what you want by
src_prepare() {
DOC_CONTENTS=blabla
indented content
# other stuff
}
src_install() {
default
readme.gentoo_reformat
}
Also, autoformatting will help to prevent every package setting messages
with different lines length (in some cases really long lines that I
finally reported some bugs in the past to get them fitting in standard
80 characters per line).
Sometimes long lines are what is required. If not, then filing a bug
is the friendly solution.
--
Cheers,
Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
On 29 January 2013 03:30, Pacho Ramos pa...@gentoo.org wrote: El lun, 28-01-2013 a las 14:37 +0800, Ben de Groot escribió: I've started using this eclass, but with README files, not the variable, because this is currently the only way I can make sure it honours my formatting. Couldn't it be covered if echo -e was used (even with fmt) and you, then, control formatting with some of the sequences it allows (they are shown in its man page)? No. The eclass should assume that DOC_CONTENTS is already correctly formatted. If you must, you can add a convenience function for people who do want reformatting, but this should NOT be the default. Please don't make this eclass harder to use than it needs to be. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
On 28 January 2013 12:37, Mike Frysinger vap...@gentoo.org wrote:
On Sunday 27 January 2013 13:21:27 Pacho Ramos wrote:
The problem is that it doesn't work so well. If I have the following at
src_prepare (for example):
src_prepare() {
DOC_CONTENTS=You must create a symlink rom /etc/splash/tuxonice
to the theme you want tuxonice to use, e.g.: \n
# ln -sfn /etc/splash/emergence /etc/splash/tuxonice
\n
...
and I handle ${DOC_CONTENTS} with quotes, it will end writing that tabs
also in generated file as the contents of the variable will be put
as-is. On the other hand, if I don't put it between quotes
forcibly normalizing whitespace for all callers is wrong imo (as is sending it
through `fmt`). if the caller gave you content to write, it should write it.
if the caller didn't want tabs, it shouldn't have used it in the first place.
-mike
I've started using this eclass, but with README files, not the variable,
because this is currently the only way I can make sure it honours my
formatting.
--
Cheers,
Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
