Re: [gentoo-dev] Last rites: app-text/epdfview
On Tue, 07 Aug 2012 12:00:13 +0900 hero...@gentoo.org wrote: Hi, Andreas K. Huettel dilfri...@gentoo.org writes: # Andreas K. Huettel dilfri...@gentoo.org (7 Aug 2012) # Many display bugs and compatibility problems, does not build with cups-1.6. # Upstream is dead. There's no real way to support this anymore. Masked for # removal in 30 days. app-text/epdfview I remember when xpdf was removed, epdfview was recommended as a lightweight alternative. How about this time? I personally migrated to evince a while ago. It is a bit GNOME, TBH but doesn't really pull in much. And is definitely less buggy. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] RFC: fsmove to profiles/updates
Hello, Right now, every time a bigger bunch of stuff (installed by various packages) needs to be moved around the filesystem, we have a lot of work to handle it somehow. And finally, users end up having to either rebuild a lot of packages to get the files in the new locations, or we do ugly things to move those files for them. I believe we should consider implementing something simpler. Thus, I propose introducing the following new command to profiles/updates: fsmove old-location new-location which -- at the moment of update -- will cause all PM-owned files in the old-location to be moved to the new one (recursively), updating the vdb as necessary. What remains to be solved/decided: 1. How to treat non-owned files? (leave them there, refuse to proceed with updates?) 2. How to handle relevant required updates? (packages which actually *have* to be updated before moving files) -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: app-text/epdfview
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hero...@gentoo.org wrote: I remember when xpdf was removed, epdfview was recommended as a lightweight alternative. How about this time? Have you gave a try to app-text/mupdf? It is very lightweight and does not depends on poppler. - -- Cyprien Nicolas (Fulax) Gentoo Lisp/Scheme contrib. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAgzJMACgkQWxOlHn1uWpdVXACeLzDmFq2AgKgl0WwFHrcDhlkO YEIAn3ou9VU7CGRGwsLcg487uMNB5Anc =c777 -END PGP SIGNATURE-
[gentoo-dev] RFC: euscan user dashboard
Hi! I'm Federico and I'm working for this year's Google Summer of Code on the euscan project with Corentin Chary. euscan is a tool to automatically scan upstream and find out if some packages in gentoo are outdated and should be bumped. We're working on a dashboard for maintainers where will be possible to receive a personalized report of packages. Currently on euscan (http://euscan.iksaif.net/) is possible to register and watch / unwatch packages. A simple dashboard is provided with a summary of the watched stuff (# of watched packages, # of outdated packages, etc...). We already received some suggestions and we implmented some of them, but we'd like to receive more detailed feedback about: - Mail newsletter: would you like to have it? which info would you like to receive specifically? A summary of the packages you're watching? When a scan is performed would you like an alert with all the new found version? Anything else? - RSS feed: would you like to have it? which info would you like? Only about new found versions of the packages you're watching? Or about portage updates too? - Settings/Preferences e.g.: Receive news only about stable versions, about unstable versions only if the version in gentoo is unstable, etc... Thank you for your help! -- f. Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. (Martin Golding) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: fsmove to profiles/updates
On 7 August 2012 19:52, Michał Górny mgo...@gentoo.org wrote: Hello, Right now, every time a bigger bunch of stuff (installed by various packages) needs to be moved around the filesystem, we have a lot of work to handle it somehow. And finally, users end up having to either rebuild a lot of packages to get the files in the new locations, or we do ugly things to move those files for them. I believe we should consider implementing something simpler. Thus, I propose introducing the following new command to profiles/updates: fsmove old-location new-location which -- at the moment of update -- will cause all PM-owned files in the old-location to be moved to the new one (recursively), updating the vdb as necessary. What remains to be solved/decided: 1. How to treat non-owned files? (leave them there, refuse to proceed with updates?) 2. How to handle relevant required updates? (packages which actually *have* to be updated before moving files) I suggest, that due to the volatility of such actions, a user should have to approve each bulk move before it is done, to avoid breaking things. Sort of like etc-update: An update file is added to the repository PMS's detect the new update, and detect the update has not been performed, and starts notifying the user that pending updates are needed. User performs action(s) when ready via some client ( eselect ? PMS specific? ~~ ) Additionally, move batches could have annotations preceding them indicating either instructional ( einfo ) or automated ( like emerge --config ) to handle things like you'll want to close postgresql before you do this or you'll get database corruption . I guess what I'm saying basically, is a hybrid concept, sort-of like eselect news , except with executable behaviour attached. At least, thats my 2c. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] RFC: euscan user dashboard
On Tue, 07 Aug 2012 10:12:47 +0200 Federico \fox\ Scrinzi fo...@anche.no wrote: We already received some suggestions and we implmented some of them, but we'd like to receive more detailed feedback about: - Mail newsletter: would you like to have it? which info would you like to receive specifically? A summary of the packages you're watching? When a scan is performed would you like an alert with all the new found version? Anything else? - RSS feed: would you like to have it? which info would you like? Only about new found versions of the packages you're watching? Or about portage updates too? I believe these two should be developed together. Something like newsletter being sent on user-specified timeout with new information, and RSS having new information whenever user pulls it. I would practically say that they should contain whatever will be in dashboard. Best, if one could have a list like: | dashboard | RSS | newsletter feature 1 | [yes/no] | [yes/no] | [every week/every .../no] feature 2 | feature 3 | For RSS, this would work as a base specifier (like when user pulls /dashboard/rss), while it would be fun to support changing the options by URI like /dashboard/rss?feature1=no. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-dev-announce] Last rites: app-text/epdfview
On Tue, 7 Aug 2012, Andreas K. Huettel wrote: # Andreas K. Huettel dilfri...@gentoo.org (7 Aug 2012) # Many display bugs and compatibility problems, does not build with cups-1.6. # Upstream is dead. There's no real way to support this anymore. Masked for # removal in 30 days. Unfortunately the best lightweight replacement I can # recommend is app-text/apvlv, otherwise you can go for app-text/acroread # (huge, closed source), kde-base/okular (KDE), or app-text/evince (Gnome). app-text/epdfview app-text/qpdfview is not bad (though I prefer okular). Andrey
Re: [gentoo-dev] Last rites: app-text/epdfview
On 08/07/2012 06:00 AM, hero...@gentoo.org wrote: Hi, Andreas K. Huettel dilfri...@gentoo.org writes: # Andreas K. Huettel dilfri...@gentoo.org (7 Aug 2012) # Many display bugs and compatibility problems, does not build with cups-1.6. # Upstream is dead. There's no real way to support this anymore. Masked for # removal in 30 days. app-text/epdfview I remember when xpdf was removed, epdfview was recommended as a lightweight alternative. How about this time? app-text/zathura-meta (zathura supports both poppler and mupdf backends but only poppler backend is in Portage for now because our mupdf package sucks wrt bugs 407805 and 407807)
[gentoo-dev] Questions about SystemD and OpenRC
Hi everyone, for a couple of months now, I see on the list some of activities about OpenRC been ported to FreeBSD or OpenRC to Debian and other stuff related to SystemD. I have some basic questions about all that : 1. The SystemD and Udev projetcs are merged now, so what is the impact on the Gentoo on a short term period ? 2. I saw on some lists that Gnome/Kde and Xfce plan to use some SystemD API, so does it means that we will need to install SystemD aside of OpenRC ? 3. In a long term vision, can OpenRC still exist on a Gentoo box(OpenRC might be able to boot the box then give the control to SystemD/Udev for the rest of the boot process) or we will need to migrate to SystemD to be able to use Gnome/Kde or Xfce ? 4. Finally, is there any reason why Gnome/Kde/Xfce wants to add deps related to SystemD ? I don't understand why these desktops want to depend on a specific Sysint Thanks ! Sylvain aka d2_racing
Re: [gentoo-dev] RFC: fsmove to profiles/updates
Kent Fredric wrote: I suggest, that due to the volatility of such actions, a user should have to approve each bulk move before it is done, to avoid breaking things. Further thoughts about this: * The move is needed for some reason. * The person running emerge will in the common case not know the details; so they are in a bad position to make any decision on the matter. * There will without a doubt be cases when things break regardless of how clever the users are. Rather than adding a prompt for the user to have to care about (everyone will answer yes all the time or no all the time anyway) I suggest that the action be made easy to undo, so that when something breaks it is possible and indeed easy to roll it back. Not so easy to say what else must be rolled back together with the fsmove! Personally I hate eselect news, I would much like to disable it. I prefer not adding more of the same. If an action is neccessary then go ahead and do it automatically, but make it easy to undo, and undo automatically on failure, as well as allow me to undo when I find a problem. //Peter
Re: [gentoo-dev] Questions about SystemD and OpenRC
On Tue, Aug 7, 2012 at 8:47 AM, Sylvain Alain d2racing...@gmail.com wrote: Hi everyone, for a couple of months now, I see on the list some of activities about OpenRC been ported to FreeBSD or OpenRC to Debian and other stuff related to SystemD. You and half the world. Most of the issues you raise are much bigger than Gentoo and are taking the whole linux world by storm. I have some basic questions about all that : 1. The SystemD and Udev projetcs are merged now, so what is the impact on the Gentoo on a short term period ? In the short term nothing, although systemd has half-decent support now, the default remains openrc and there are no plans to change that. 2. I saw on some lists that Gnome/Kde and Xfce plan to use some SystemD API, so does it means that we will need to install SystemD aside of OpenRC ? Now, no. In the future - nobody really knows for sure, but it seems likely that at least in some cases not only will you need to install it, but you'll need to run it also. I'd heard only Gnome was moving in this direction, but perhaps other projects are as well. I'd be surprised if Xfce moves in this direction - they've always been about being minimal. 3. In a long term vision, can OpenRC still exist on a Gentoo box(OpenRC might be able to boot the box then give the control to SystemD/Udev for the rest of the boot process) or we will need to migrate to SystemD to be able to use Gnome/Kde or Xfce ? If you do need systemd for gnome/etc then most likely you'll just want to use it across the board. Trying to run some kind of a hybrid seems like the worst of both worlds. 4. Finally, is there any reason why Gnome/Kde/Xfce wants to add deps related to SystemD ? I don't understand why these desktops want to depend on a specific Sysint You'd have to talk to them, but I believe their goal is to go for more of a vertically-integrated experience (which fits more with Gnome or KDE than Xfce, but again the last I'd heard only Gnome was going in this direction so far). Ubuntu is doing similar things with Unity/Upstart. I don't know everything that the integration will support, but I can imagine they're interested in things like better WiFi and network roaming support (re-set your network, re-configure your firewall settings, update the UI, etc), better behavior during suspend/resume/etc, handling of things like bluetooth, and so on. I don't run linux on a laptop unless you count my Chromebook so I can't really vouch for what the current experience is like or what needs improvement. I've tried to stick to the facts here, at least as far as I'm aware of them. I don't think we need another 50-post thread on The Unix Way(TM) and whether it is a good or bad thing. These developments are going to be a challenge for distros like Gentoo or Debian that aim to be general/meta distributions. It used to be that you could swap out major components and all the APIs/interfaces still worked. In the future it might be much harder to run Gnome on Gentoo on an OSX kernel, etc. However, all of this is a bit speculative and it is hard to say how things will actually turn out. Rich
[gentoo-dev] x11-drivers/xf86-video-openchrome needs a new maintainer
Hello developers, for the last few years I have been maintaining x11-drivers/xf86-video-openchrome as best as I could. I was basing most of that work on my extensive use (in a workstation of sorts) of a single VIA EPIA M-1 mainboard for a period of more than seven years, but it proved increasingly difficult to hang on to it. A bad case of capacitor plague[1] meant that peripheral I/O functions (sound, USB, probably more subsystems I wasn't even trying to use anymore) were becoming increasingly unstable. Lately even booting the system was hit and miss, and its dismal performance paired with having a 1600x1200 screen resolution supported by a /very/ slow frame buffer had me looking for a spiffy alternative. When that opportunity presented itself, I stuffed the single storage device into the new system and ran with it. I haven't looked back and I don't think I want to fire up the EPIA again, so I can no longer maintain the graphics driver for it. Most of the work on the VIA graphics drivers used to take place at a separate website [2], but recently most of the work has shifted to freedesktop.org[3]. The OLPC[4] project has a vested interest in getting the open source driver to work, too, which is where former Gentoo developer Daniel Drake[5] does more than his share of the work. The last year or so has seen a lot of work put into getting DRM working properly, and that holds at least some promise for the future of both the hardware and its usability in Linux based systems. In the last few years there have been a few occasions where the unstable branch of openchrome ebuilds in the tree wouldn't work at all, and there have even been cases where the stable branch had severe problems that weren't noticed or fixed until I happened to stumble upon them myself. VIA graphics found some use in the middle of the last decade, but I guess most owners gratefully used their spare AGP or PCI slots instead of the built-in graphics, or I would have seen more bug reports, testing and support. The X11 team is now the principal maintainer of these low maintenance ebuilds. So, if you have and use the graphics hardware that this driver supports, give it some care. Happy hacking, jer [1] http://en.wikipedia.org/wiki/Capacitor_plague [2] http://www.openchrome.org/ [3] http://cgit.freedesktop.org/openchrome/ [4] http://one.laptop.org/ [5] http://www.reactivated.net/weblog/
[gentoo-dev] Last rites: dev-util/cccc
# Michael Palimaka kensing...@gentoo.org (7 Aug 2012) # Fails to build with GCC 4.7 (bug #430250) # Bundles utilities from dev-util/pccts # Dead upstream. Removal in 30 days. dev-util/
Re: [gentoo-dev] RFC: fsmove to profiles/updates
On Tue, 7 Aug 2012 15:10:35 +0200 Peter Stuge pe...@stuge.se wrote: Rather than adding a prompt for the user to have to care about (everyone will answer yes all the time or no all the time anyway) I suggest that the action be made easy to undo, so that when something breaks it is possible and indeed easy to roll it back. Not so easy to say what else must be rolled back together with the fsmove! I don't think that's possible. Much like with other kinds of updates, the packages in the tree would be updated to install in the new location anyway. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Questions about SystemD and OpenRC
Rich Freeman wrote: In the future it might be much harder to run Gnome on Gentoo on an OSX kernel, etc. Yes, but if the upstream that is Gnome decides to start depending on systemd features then that's their decision, and the place to discuss if it's good or bad (more important, the place to change it!) would be within the Gnome project. I guess Gentoo will always continue to offer the best of upstream. OTOH, if upstream goes and make some change that means a regression for Gentoo users, then they deserve bug report floods from their users! :) //Peter
Re: [gentoo-dev] Questions about SystemD and OpenRC
On Tue, Aug 7, 2012 at 10:11 AM, Peter Stuge pe...@stuge.se wrote: Yes, but if the upstream that is Gnome decides to start depending on systemd features then that's their decision, and the place to discuss if it's good or bad (more important, the place to change it!) would be within the Gnome project. More or less, but again my goal was not to start another discussion - just to inform. Anybody inclined to comment on whether this is good or bad should go look at the list archives and see if any of the 400 messages in the last month already covered their points. I guess Gentoo will always continue to offer the best of upstream. I don't think Gentoo has to limit itself to what upstream supports (I don't think anybody would look at Prefix and say that this was what any upstream had in mind). However, the bottom line is that to do something exotic takes effort, so nothing will happen unless somebody makes it happen. OTOH, if upstream goes and make some change that means a regression for Gentoo users, then they deserve bug report floods from their users! :) Perhaps, but don't count on it going anywhere. With Gnome 3 they must already have pretty thick skin. I suspect upstream would say that if you want a smooth desktop experience you shouldn't be running Gentoo. To some degree they probably even have a valid point. Gentoo is about more than a just-works desktop so I think the best we'll be able to offer is a reasonable experience. If things get really integrated you might see some Sabayon-like forks favoring particular DEs/etc, and as long as those forks contribute to our main tree I think that is good for all of us. Rich
Re: [gentoo-dev] RFC: fsmove to profiles/updates
On Tue, Aug 7, 2012 at 9:58 AM, Michał Górny mgo...@gentoo.org wrote: I don't think that's possible. Much like with other kinds of updates, the packages in the tree would be updated to install in the new location anyway. If I were faced with doing this manually I know the first thing I'd do is run quickpkg on the affected packages. Maybe something could be done with that (though quickpkg is not part of @system). However, in general big moves like this are never going to be easy to recover from. If you have sed scripts cleaning up config files or whatever who knows what the previous values were. I think any kind of large-scale directory moves are going to be risky on a distro like Gentoo. We should probably give them careful thought before implementing them. This isn't something like Ubuntu where you practically wipe and re-install all of /usr a few times a year from what amounts to a bunch of tarballs. Rich
Re: [gentoo-dev] Gentoo vs. upstream
Rich Freeman wrote: I suspect upstream would say that if you want a smooth desktop experience you shouldn't be running Gentoo. To some degree they probably even have a valid point. Yes and no.. I think it will always be possible to use Gentoo to create as smooth a desktop experience as any distro provides, but it will certainly require knowing every single detail of what makes that desktop experience possible. Gentoo is about more than a just-works desktop Yes! 3 so I think the best we'll be able to offer is a reasonable experience. One doesn't have to exclude the other, but users will have to know how things work, in order to use Gentoo to get things the way they want them. Just like it has always been. If things get really integrated you might see some Sabayon-like forks favoring particular DEs/etc, and as long as those forks contribute to our main tree I think that is good for all of us. I agree completely! //Peter
Re: [gentoo-dev] RFC: fsmove to profiles/updates
On Tue, 7 Aug 2012 10:48:01 -0400 Rich Freeman ri...@gentoo.org wrote: I think any kind of large-scale directory moves are going to be risky on a distro like Gentoo. We should probably give them careful thought before implementing them. This isn't something like Ubuntu where you practically wipe and re-install all of /usr a few times a year from what amounts to a bunch of tarballs. Yes, they are risky and complex. And many things which possibly could help us, simply don't work on Gentoo. Sometimes because of PMS stupidity, sometimes because we feel like ugly hacks done by users should simply work. We already give a lot of thought and care to handle the moves but we still miss some essential tool which could help us handle them better. Most importantly, which would allow us to avoid forcing users to have half-moved system. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Questions about SystemD and OpenRC
The KDE team seems to work on that too : http://lists.kde.org/?l=kde-core-develm=134052539215508w=2 Now I understand why some devs are working hard to make Mdev working with OpenRC. They want to replace Udev/SystemD with Mdev/OpenRC and solve this situation. Sylvain aka d2_racing 2012/8/7 Rich Freeman ri...@gentoo.org On Tue, Aug 7, 2012 at 10:11 AM, Peter Stuge pe...@stuge.se wrote: Yes, but if the upstream that is Gnome decides to start depending on systemd features then that's their decision, and the place to discuss if it's good or bad (more important, the place to change it!) would be within the Gnome project. More or less, but again my goal was not to start another discussion - just to inform. Anybody inclined to comment on whether this is good or bad should go look at the list archives and see if any of the 400 messages in the last month already covered their points. I guess Gentoo will always continue to offer the best of upstream. I don't think Gentoo has to limit itself to what upstream supports (I don't think anybody would look at Prefix and say that this was what any upstream had in mind). However, the bottom line is that to do something exotic takes effort, so nothing will happen unless somebody makes it happen. OTOH, if upstream goes and make some change that means a regression for Gentoo users, then they deserve bug report floods from their users! :) Perhaps, but don't count on it going anywhere. With Gnome 3 they must already have pretty thick skin. I suspect upstream would say that if you want a smooth desktop experience you shouldn't be running Gentoo. To some degree they probably even have a valid point. Gentoo is about more than a just-works desktop so I think the best we'll be able to offer is a reasonable experience. If things get really integrated you might see some Sabayon-like forks favoring particular DEs/etc, and as long as those forks contribute to our main tree I think that is good for all of us. Rich -- Salut alp Sylvain
[gentoo-dev] Re: gentoo-x86 commit in dev-perl/XML-Parser: XML-Parser-2.410.0-r1.ebuild ChangeLog
* Fabian Groffen (grobian) grob...@gentoo.org:
grobian 12/08/07 15:21:54
Modified: ChangeLog
Added:XML-Parser-2.410.0-r1.ebuild
Log:
Fix expat detection for FreeBSD that silently went unnoticed.
The following single quotes were dropped:
-myconf=EXPATLIBPATH='${EPREFIX}/usr/$(get_libdir)'
EXPATINCPATH='${EPREFIX}/usr/include'
+myconf=EXPATLIBPATH=${EPREFIX}/usr/$(get_libdir)
EXPATINCPATH=${EPREFIX}/usr/include
Sorry, I don't understand the problem. Is it a general problem with
the single quote or a special FreeBSD problem?
I think we should convert all myconf strings to arrays:
myconf=( EXPATLIBPATH=${EPREFIX}/usr/$(get_libdir)
EXPATINCPATH=${EPREFIX}/usr/include )
--
Thanks
Re: [gentoo-dev] Re: gentoo-x86 commit in dev-perl/XML-Parser: XML-Parser-2.410.0-r1.ebuild ChangeLog
On Tue, 7 Aug 2012 18:03:14 +0200
Torsten Veller t...@gentoo.org wrote:
* Fabian Groffen (grobian) grob...@gentoo.org:
grobian 12/08/07 15:21:54
Modified: ChangeLog
Added:XML-Parser-2.410.0-r1.ebuild
Log:
Fix expat detection for FreeBSD that silently went unnoticed.
The following single quotes were dropped:
-myconf=EXPATLIBPATH='${EPREFIX}/usr/$(get_libdir)'
EXPATINCPATH='${EPREFIX}/usr/include'
+myconf=EXPATLIBPATH=${EPREFIX}/usr/$(get_libdir)
EXPATINCPATH=${EPREFIX}/usr/include
Sorry, I don't understand the problem. Is it a general problem with
the single quote or a special FreeBSD problem?
A general problem. It won't work unless it's eval-ed. And if it were,
there will be more harm than you can possibly imagine.
I think we should convert all myconf strings to arrays:
myconf=( EXPATLIBPATH=${EPREFIX}/usr/$(get_libdir)
EXPATINCPATH=${EPREFIX}/usr/include )
+1.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
[gentoo-dev] Re: gentoo-x86 commit in dev-perl/XML-Parser: XML-Parser-2.410.0-r1.ebuild ChangeLog
On 07-08-2012 18:03:14 +0200, Torsten Veller wrote:
* Fabian Groffen (grobian) grob...@gentoo.org:
grobian 12/08/07 15:21:54
Modified: ChangeLog
Added:XML-Parser-2.410.0-r1.ebuild
Log:
Fix expat detection for FreeBSD that silently went unnoticed.
The following single quotes were dropped:
-myconf=EXPATLIBPATH='${EPREFIX}/usr/$(get_libdir)'
EXPATINCPATH='${EPREFIX}/usr/include'
+myconf=EXPATLIBPATH=${EPREFIX}/usr/$(get_libdir)
EXPATINCPATH=${EPREFIX}/usr/include
Sorry, I don't understand the problem. Is it a general problem with
the single quote or a special FreeBSD problem?
I've only observed it happening on FreeBSD indeed.
I think we should convert all myconf strings to arrays:
myconf=( EXPATLIBPATH=${EPREFIX}/usr/$(get_libdir)
EXPATINCPATH=${EPREFIX}/usr/include )
I don't understand enough of the Makefile.PL thing to tell why the
quotes work on Darwin, Solaris, but not FreeBSD 9.1-BETA1. I do know
that EPREFIX cannot contain spaces though, hence I applied the fix as
committed. If the array approach works with the eclass, then that'll be
certainly cleaner.
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: Digital signature
Re: [gentoo-dev] Questions about SystemD and OpenRC
On Tue, 7 Aug 2012 11:33:59 -0400 Sylvain Alain d2racing...@gmail.com wrote: The KDE team seems to work on that too : http://lists.kde.org/?l=kde-core-develm=134052539215508w=2 it's actually worth it. more user-spread FUD or however you like to call it on the topic than I'm not sure if *devs* are actually working on that. I believe there's Now I understand why some devs are working hard to make Mdev working with OpenRC. different, you could as well disable USE=udev and use regular udev. equivalent to KDE/GNOME/whatever without anything? And if it's no But you are aware that KDE/GNOME/whatever+mdev would be practically They want to replace Udev/SystemD with Mdev/OpenRC and solve this situation. Sylvain aka d2_racing 2012/8/7 Rich Freeman ri...@gentoo.org On Tue, Aug 7, 2012 at 10:11 AM, Peter Stuge pe...@stuge.se wrote: Yes, but if the upstream that is Gnome decides to start depending on systemd features then that's their decision, and the place to discuss if it's good or bad (more important, the place to change it!) would be within the Gnome project. More or less, but again my goal was not to start another discussion - just to inform. Anybody inclined to comment on whether this is good or bad should go look at the list archives and see if any of the 400 messages in the last month already covered their points. I guess Gentoo will always continue to offer the best of upstream. I don't think Gentoo has to limit itself to what upstream supports (I don't think anybody would look at Prefix and say that this was what any upstream had in mind). However, the bottom line is that to do something exotic takes effort, so nothing will happen unless somebody makes it happen. OTOH, if upstream goes and make some change that means a regression for Gentoo users, then they deserve bug report floods from their users! :) Perhaps, but don't count on it going anywhere. With Gnome 3 they must already have pretty thick skin. I suspect upstream would say that if you want a smooth desktop experience you shouldn't be running Gentoo. To some degree they probably even have a valid point. Gentoo is about more than a just-works desktop so I think the best we'll be able to offer is a reasonable experience. If things get really integrated you might see some Sabayon-like forks favoring particular DEs/etc, and as long as those forks contribute to our main tree I think that is good for all of us. Rich -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: gentoo-x86 commit in dev-perl/XML-Parser: XML-Parser-2.410.0-r1.ebuild ChangeLog
On 07-08-2012 18:23:54 +0200, Michał Górny wrote: Sorry, I don't understand the problem. Is it a general problem with the single quote or a special FreeBSD problem? A general problem. It won't work unless it's eval-ed. And if it were, there will be more harm than you can possibly imagine. It works fine under Linux, Solaris and Darwin. So I think you're jumping to conclusions here too quickly. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Questions about SystemD and OpenRC
On Tue, Aug 7, 2012 at 12:29 PM, Michał Górny mgo...@gentoo.org wrote: On Tue, 7 Aug 2012 11:33:59 -0400 Sylvain Alain d2racing...@gmail.com wrote: The KDE team seems to work on that too : http://lists.kde.org/?l=kde-core-develm=134052539215508w=2 it's actually worth it. more user-spread FUD or however you like to call it on the topic than I'm not sure if *devs* are actually working on that. I believe there's Perhaps not official Gentoo devs, but users taking development initiative to solve a problem in userland. I'm not an official Gentoo dev, either, but I think it'd be a very bad idea to discourage or ridicule such initiative. Someone putting in that much effort in light of all the information already available isn't something that should be taken lightly! Now I understand why some devs are working hard to make Mdev working with OpenRC. different, you could as well disable USE=udev and use regular udev. equivalent to KDE/GNOME/whatever without anything? And if it's no But you are aware that KDE/GNOME/whatever+mdev would be practically (My reason for replying...looks like a few chunks of text got lost here.) [snip] -- :wq
Re: [gentoo-dev] Portage FEATURE suggestion - limited-visibility builds
On Tue, Jul 31, 2012 at 7:57 PM, viv...@gmail.com viv...@gmail.com wrote: Il 31/07/2012 21:27, Michał Górny ha scritto: I'd be more afraid about resources, and whether the kernel will be actually able to handle bazillion bind mounts. And if, whether it won't actually cause more overhead than copying the whole system to some kind of tmpfs. If testing show that bind mounts are too heavy we could resort to LD_PRELOAD a library that filter the acces to the disk, or to rework sandbox to also hide w/o errors some files, with an appropriate database (sys-apps/mlocate come to mind) every access will have negligible additional cost compared to that of rotational disks. So, while I suspect that bind mount overhead won't actually be that bad, I'm also thinking that extending the role of sandbox as has already been suggested might be the simpler solution (and it works on other kernels as well). I'd still like a run-time solution some day, but that would probably require SELinux and seems like a much more ambitious project, and we'll probably get quite a bit of QA value out of a sandbox solution. I think the right solution is to not use external utilities unless they can be linked in - at least not for anything running in sandbox. We're talking about at VERY high volume of file opens most likely and we can't be spawning processes every time that happens, let alone running bash scripts or whatever. So, here is my design concept (which had a little help from my LUG - PLUG): 1. At the start of the build, portage generates a list of files that are legitimate dependencies - anything in DEPEND or @system. This can be done by parsing the /var/pkg/db files (I assume portage has some internal API for this already). 2. Portage or a helper program (whatever is fastest) calls stat on each file to obtain the device and inode IDs. Maybe long-term we might consider caching these (but I'm not sure how stable they are). 3. The list of valid device/inode IDs are passed to sandbox somehow (maybe in a file). Sandbox creates a data structure in memory containing them for rapid access (btree or such). 4. When sandbox intercepts a file open request, it checks the file inode against the list and allows/denies accordingly. That said, after doing a quick pass at the sandbox source it seems like it already is designed to restrict read access, but it uses canonical filenames to do so. I'm not sure if those are going to be reliable, especially if a filesystem contains bind mounts. Since it is already checking a read list if we thought that mechnism would be robust and fast, we could just remove SANDBOX_READ=/ from /etc/sandbox.d/00default and then load in whatever we want afterwards. I need to spend more time groking the current source. I'd think that using inode numbers as a key would be faster than determining a canonical file name on every file access, but if sandbox is already doing the latter then obviously it isn't that much overhead. The other thing I'm not sure about here are symlinks. If a symlink is contained in a dependency, but the linked file is not, can that file be used by a package? I suppose the reverse is also a concern - if a file is accessed through a symlink that isn't part of a dependency, but the file it is pointing to is, is that a problem? I'm wondering if there is any eselect logic that could cause problems here. When calling stat we can choose whether to dereference symlinks.
Re: [gentoo-dev] Questions about SystemD and OpenRC
Hi, Let's cut the FUD. On Tue, 2012-08-07 at 08:47 -0400, Sylvain Alain wrote: 1. The SystemD and Udev projetcs are merged now, so what is the impact on the Gentoo on a short term period ? Only the build system is merged, they're still separate binaries. 2. I saw on some lists that Gnome/Kde and Xfce plan to use some SystemD API, so does it means that we will need to install SystemD aside of OpenRC ? The APIs that GNOME is using from systemd are simple, well designed and well documented D-Bus APIs [1][2][3]. They are implemented by simple binaries separate from the core systemd. Legacy init systems can just re-use them as-is. Also, systemd includes logind, which replaces ConsoleKit with a much better design. 4. Finally, is there any reason why Gnome/Kde/Xfce wants to add deps related to SystemD ? I don't understand why these desktops want to depend on a specific Sysint Old versions of GNOME (and KDE, XFCE, etc) had to have distro-specific code for a bunch of things, such as changing the timezone, the system locale or the hostname. Because these things are in separate places in every distribution for historical reason. So every desktop had to re-implement these things for every distribution, making a lot of duplicated code. The goal is to have a single set of tools using a common D-Bus API that you only have to implement once per distribution and that every desktop can use. 3. In a long term vision, can OpenRC still exist on a Gentoo box(OpenRC might be able to boot the box then give the control to SystemD/Udev for the rest of the boot process) or we will need to migrate to SystemD to be able to use Gnome/Kde or Xfce ? I expect that in the not so long term, systemd will become an essential user-space component of desktop Linux, just like crond, syslog, dbus, udev or glibc. Sharing that code just makes sense, that allows distributions to focus on their strength instead of having to maintain a nightmare of shell scripts. Sure you can do a Android and write your own crappier version, but that doesn't gain you anything. Refs: [1] http://www.freedesktop.org/wiki/Software/systemd/hostnamed [2] http://www.freedesktop.org/wiki/Software/systemd/timedated [3] http://www.freedesktop.org/wiki/Software/systemd/localed [4] http://www.freedesktop.org/wiki/Software/systemd/logind -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Questions about SystemD and OpenRC
On Tue, 7 Aug 2012 13:31:32 -0400 Michael Mol mike...@gmail.com wrote: On Tue, Aug 7, 2012 at 12:29 PM, Michał Górny mgo...@gentoo.org wrote: On Tue, 7 Aug 2012 11:33:59 -0400 Sylvain Alain d2racing...@gmail.com wrote: The KDE team seems to work on that too : http://lists.kde.org/?l=kde-core-develm=134052539215508w=2 it's actually worth it. more user-spread FUD or however you like to call it on the topic than I'm not sure if *devs* are actually working on that. I believe there's Perhaps not official Gentoo devs, but users taking development initiative to solve a problem in userland. I'm not an official Gentoo dev, either, but I think it'd be a very bad idea to discourage or ridicule such initiative. Someone putting in that much effort in light of all the information already available isn't something that should be taken lightly! I don't want to offend anyone but let's be honest: people start many initiatives, and they are not always right, no matter how many effort is put. I don't want to discourage it but sometimes I dislike the importunity accompanying it. Users are free to do whatever they want as long as it doesn't harm the rest of users. And I'm afraid that too much enthusiasm over mdev will actually cause a number of users to end up being disappointed that one or another magic requiring udev no longer works. Now I understand why some devs are working hard to make Mdev working with OpenRC. different, you could as well disable USE=udev and use regular udev. equivalent to KDE/GNOME/whatever without anything? And if it's no But you are aware that KDE/GNOME/whatever+mdev would be practically (My reason for replying...looks like a few chunks of text got lost here.) Sorry for the confusion caused to you and the others. You need to read it bottom-to-top. I reversed the line order for Sylvain who seems to prefer reading that way. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Questions about SystemD and OpenRC
Michał Górny wrote: On Tue, 7 Aug 2012 13:31:32 -0400 Michael Mol mike...@gmail.com wrote: On Tue, Aug 7, 2012 at 12:29 PM, Michał Górny mgo...@gentoo.org wrote: On Tue, 7 Aug 2012 11:33:59 -0400 Sylvain Alain d2racing...@gmail.com wrote: The KDE team seems to work on that too : http://lists.kde.org/?l=kde-core-develm=134052539215508w=2 it's actually worth it. more user-spread FUD or however you like to call it on the topic than I'm not sure if *devs* are actually working on that. I believe there's Perhaps not official Gentoo devs, but users taking development initiative to solve a problem in userland. I'm not an official Gentoo dev, either, but I think it'd be a very bad idea to discourage or ridicule such initiative. Someone putting in that much effort in light of all the information already available isn't something that should be taken lightly! I don't want to offend anyone but let's be honest: people start many initiatives, and they are not always right, no matter how many effort is put. I don't want to discourage it but sometimes I dislike the importunity accompanying it. Users are free to do whatever they want as long as it doesn't harm the rest of users. And I'm afraid that too much enthusiasm over mdev will actually cause a number of users to end up being disappointed that one or another magic requiring udev no longer works. User perspective follows: What I don't like about the way Walter, mdev, is being treated is this. People say that if you don't like the way udev is going, WRITE CODE. If you are not going to write code, don't complain about udev. Then Walter, I think I got the name right, comes along and comes up with a alternative for udev that seems to work well for the people using it. Then people complain because he is actually stepping up and WRITING CODE. Well, it seems a person can't win on this. Some, no names mentioned, need to make up their minds. Either listen when people don't like the way things are going or let people write code to have a alternative to whatever people are not liking and don't complain because people are stepping up and doing something about it, for example, writing code. As to mdev not being as feature rich as udev, well, some people don't need the features udev has and I don't think anyone is saying mdev is the same as udev. It even says on the wiki that there are some situations where it should not even be tried because it is known to not work. Given that, if a person tries to use mdev to replace udev in a situation where it is known not to work, then they should read more closely. It's not Walters fault, it's the person in the chair. Now, since Walter didn't like the way things are going, can he write code and be left in peace to do so? Maybe have a little bit of support while he is doing it? Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] RFC: fsmove to profiles/updates
On 8 August 2012 01:58, Michał Górny mgo...@gentoo.org wrote: I don't think that's possible. Much like with other kinds of updates, the packages in the tree would be updated to install in the new location anyway. Sure, but the question is when does this happen. Users are expecting such changes when they emerge a new package, but if you're on a system that has versions pinned, you're not expecting magical changes to happen during emerge sync I'd hope at the very least there was a FEATURES= option to disable automatic fs moves. I can understand how most people will probably want to just let moves happen, but I still think you should still have a way to disable this for people who have higher security concerns. Some moves will need checks done to see if they can be done safely or not, and some moves will require updating files in /etc/ to make them work, so moving the files but *not* changing /etc/* forcibly could easily lead to a broken system . And this is especially the case if you're trying to move dirs which contain a mix of user and installed content. ( ie: /var/db/postgres/ ) Some will be able to be performed hands-free, and others will *need* some user interaction to avoid a broken system. -- Best regards, Michał Górny -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] UTF-8 locale by default
On Friday, August 03, 2012 07:16:45 AM Luca Barbato wrote: On 07/27/2012 07:24 PM, Mike Frysinger wrote: yes, and i'm waiting on the POSIX group to formalize C.UTF-8. that's the only real option in my mind for making unicode the default. any other amalgamations of various locales is ugly as sin. When they meet? I'd be fine with a pre-release =P lu 2008 TC1 is just finishing up balloting as we speak. If this isn't already in there you may be in for a long wait. Feel free to subscribe to the austin- group lists -- It's open to anyone. A calendar with the teleconference schedule is available. -- Dan Douglas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Questions about SystemD and OpenRC
On Tue, Aug 7, 2012 at 5:36 PM, Dale rdalek1...@gmail.com wrote: Now, since Walter didn't like the way things are going, can he write code and be left in peace to do so? Maybe have a little bit of support while he is doing it? ++ I can't say I think that preferring mdev over an initramfs is a good choice, but I can say that I prefer that people have the choice to make in the first place. Nobody can expect anybody to maintain something for them, but if some are willing to step up and give Gentoo a bit of a broader perspective that is what we're all about. Where else are you going to find a linux distro that can run a fair bit of their repository on Interix of all things? We all get grumpy from time to time, but I've learned that if you're going to speak up it is best if you're doing so to offer something better, and not just to gripe. My hat is always off to those who write code, and the community around Gentoo that has allowed us to choose whether to run it. Systemd, Dracut, Wayland, and more - bring it on, and if my writing an odd init script/unit/whatever for a package I maintain makes it possible to do something genuinely new with Gentoo, then file all the bugs you want. :) Rich
