Re: [gentoo-dev] Re: Creating a USE_EXPAND for ssl providers
On 05/30/14 10:05, Ian Stakenvicius wrote: Nothing at all, but I don't see a generic global SSL USE_EXPAND adding any particular benefit, either. What are the intended benefits to this, besides aesthetics?? Take a look at bug #510974. Because USE=ssl means different things on different packages. -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197
[gentoo-dev] alpha, ia64, ppc, ppc64, sparc developers, need your attention
http://bugs.gentoo.org/show_bug.cgi?id=505962#c6 is blocking stabilizing the new virtuals, and thus, converting the tree, and also blocking stabilization of the already converted packages (gnome seems to have some) pending for 3 months already thanks, samuli
Re: [gentoo-dev] alpha, ia64, ppc, ppc64, sparc developers, need your attention
El dom, 01-06-2014 a las 14:18 +0300, Samuli Suominen escribió: http://bugs.gentoo.org/show_bug.cgi?id=505962#c6 is blocking stabilizing the new virtuals, and thus, converting the tree, and also blocking stabilization of the already converted packages (gnome seems to have some) pending for 3 months already thanks, samuli This makes me wonder about the real status of some of this arches. I know that now we will probably see how Agostino goes ahead and does all the work (that is nice and I really welcome his work trying to keep this arches in shape), but also makes me thing if makes sense to keep this agostino-dependency for this arches more and more time. What will occur if he is not around sometime? :/
Re: [gentoo-dev] alpha, ia64, ppc, ppc64, sparc developers, need your attention
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/01/2014 12:33 PM, Pacho Ramos wrote: El dom, 01-06-2014 a las 14:18 +0300, Samuli Suominen escribió: http://bugs.gentoo.org/show_bug.cgi?id=505962#c6 is blocking stabilizing the new virtuals, and thus, converting the tree, and also blocking stabilization of the already converted packages (gnome seems to have some) pending for 3 months already thanks, samuli This makes me wonder about the real status of some of this arches. I know that now we will probably see how Agostino goes ahead and does all the work (that is nice and I really welcome his work trying to keep this arches in shape), but also makes me thing if makes sense to keep this agostino-dependency for this arches more and more time. What will occur if he is not around sometime? :/ We have been through the same discussion not so long ago and the result was to start dropping the ~m68k, s390 and sh to ~testing[1]. In the thread that started it all[2] there has been no resistance about dropping the keywords of these arches on $subject and here we are again discussing the problem. Here[3] you can see council's decision. I quote here just for fyi: In summary: - - m68k, s390, sh: will be dropped to unstable keywords globally. - - alpha, ia64: Maintainers can remove older stable versions according to the package-by-package proposal. - - sparc: No action. So unless I make a mistake, you are free to start dropping alpha, ia64 to ~arch. For ppc,ppc64 and sparc it's probably best to resurrect the old thread and possible have add it to the agenda for the next meeting. [1] http://permalink.gmane.org/gmane.linux.gentoo.devel/88183 [2] http://www.gossamer-threads.com/lists/gentoo/dev/277054 [3] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQF8BAEBCgBmBQJTixXHXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZpzgH/04Mzd2eu24PG6Rk6pdzn0vE RT2FatinkXfan8r0zrEUf9jAGDdEWlpMxUlK2+10EBmBaNIDx3C66vdr1sK8mq61 TgKZkyUPuAkIAfOx4B8epJj1CSwx7DRnSuZTI1MWkd6sBdjqvGw4EN+QlzwfOzN9 UJ93OxGMvYHC9J6YQzq3kbJW9j4FoDTdQAIDPcKt+nppBTTHw5Qb1/Fum/ZjxpaI drgMtxLbzKpIPm9teUVtu0vYdgxVGmPezV1vJ5GWqQ42O9OqKq/tA1uvvOHYigDD GpL8Ze0hLGEEEp+16prISB/PKvZUjVb/WFblQeKoscq68YQneV8m7jLaJf+94C4= =uPfn -END PGP SIGNATURE-
Re: [gentoo-dev] alpha, ia64, ppc, ppc64, sparc developers, need your attention
El dom, 01-06-2014 a las 13:00 +0100, Markos Chandras escribió: On 06/01/2014 12:33 PM, Pacho Ramos wrote: El dom, 01-06-2014 a las 14:18 +0300, Samuli Suominen escribió: http://bugs.gentoo.org/show_bug.cgi?id=505962#c6 is blocking stabilizing the new virtuals, and thus, converting the tree, and also blocking stabilization of the already converted packages (gnome seems to have some) pending for 3 months already thanks, samuli This makes me wonder about the real status of some of this arches. I know that now we will probably see how Agostino goes ahead and does all the work (that is nice and I really welcome his work trying to keep this arches in shape), but also makes me thing if makes sense to keep this agostino-dependency for this arches more and more time. What will occur if he is not around sometime? :/ We have been through the same discussion not so long ago and the result was to start dropping the ~m68k, s390 and sh to ~testing[1]. In the thread that started it all[2] there has been no resistance about dropping the keywords of these arches on $subject and here we are again discussing the problem. Here[3] you can see council's decision. I quote here just for fyi: In summary: - m68k, s390, sh: will be dropped to unstable keywords globally. - alpha, ia64: Maintainers can remove older stable versions according to the package-by-package proposal. - sparc: No action. So unless I make a mistake, you are free to start dropping alpha, ia64 to ~arch. For ppc,ppc64 and sparc it's probably best to resurrect the old thread and possible have add it to the agenda for the next meeting. [1] http://permalink.gmane.org/gmane.linux.gentoo.devel/88183 [2] http://www.gossamer-threads.com/lists/gentoo/dev/277054 [3] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt The problem arrives when even core components like udev takes so long to be handled :/ (and situation would be much worse if Agostino doesn't have time to make his mass stabilizations... well, each time I report a stabilization bug that affects me I cross my fingers expecting ago has enough time to handle them ;))
Re: [gentoo-dev] alpha, ia64, ppc, ppc64, sparc developers, need your attention
On 06/01/2014 01:07 PM, Pacho Ramos wrote: El dom, 01-06-2014 a las 13:00 +0100, Markos Chandras escribió: On 06/01/2014 12:33 PM, Pacho Ramos wrote: El dom, 01-06-2014 a las 14:18 +0300, Samuli Suominen escribió: http://bugs.gentoo.org/show_bug.cgi?id=505962#c6 is blocking stabilizing the new virtuals, and thus, converting the tree, and also blocking stabilization of the already converted packages (gnome seems to have some) pending for 3 months already thanks, samuli This makes me wonder about the real status of some of this arches. I know that now we will probably see how Agostino goes ahead and does all the work (that is nice and I really welcome his work trying to keep this arches in shape), but also makes me thing if makes sense to keep this agostino-dependency for this arches more and more time. What will occur if he is not around sometime? :/ We have been through the same discussion not so long ago and the result was to start dropping the ~m68k, s390 and sh to ~testing[1]. In the thread that started it all[2] there has been no resistance about dropping the keywords of these arches on $subject and here we are again discussing the problem. Here[3] you can see council's decision. I quote here just for fyi: In summary: - m68k, s390, sh: will be dropped to unstable keywords globally. - alpha, ia64: Maintainers can remove older stable versions according to the package-by-package proposal. - sparc: No action. So unless I make a mistake, you are free to start dropping alpha, ia64 to ~arch. For ppc,ppc64 and sparc it's probably best to resurrect the old thread and possible have add it to the agenda for the next meeting. [1] http://permalink.gmane.org/gmane.linux.gentoo.devel/88183 [2] http://www.gossamer-threads.com/lists/gentoo/dev/277054 [3] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt The problem arrives when even core components like udev takes so long to be handled :/ (and situation would be much worse if Agostino doesn't have time to make his mass stabilizations... well, each time I report a stabilization bug that affects me I cross my fingers expecting ago has enough time to handle them ;)) Relying on a single developer handling all architectures clearly does not scale and it is dangerous. We really need to be realistic and consider how many stable alpha/sparc/ia64/ppc* users are out there. In my mind the number is rather small, so does it really worth the effort trying to keep them stable hurting the remaining stable architectures and causing significant delays in publishing GLSAs? The reason I suggested to move the discussion back to the old thread is that some of these things have already been discussed in the past so I would like to avoid restarting the discussion from scratch. -- Regards, Markos Chandras
Re: [gentoo-dev] alpha, ia64, ppc, ppc64, sparc developers, need your attention
El dom, 01-06-2014 a las 13:59 +0100, Markos Chandras escribió: On 06/01/2014 01:07 PM, Pacho Ramos wrote: El dom, 01-06-2014 a las 13:00 +0100, Markos Chandras escribió: On 06/01/2014 12:33 PM, Pacho Ramos wrote: El dom, 01-06-2014 a las 14:18 +0300, Samuli Suominen escribió: http://bugs.gentoo.org/show_bug.cgi?id=505962#c6 is blocking stabilizing the new virtuals, and thus, converting the tree, and also blocking stabilization of the already converted packages (gnome seems to have some) pending for 3 months already thanks, samuli This makes me wonder about the real status of some of this arches. I know that now we will probably see how Agostino goes ahead and does all the work (that is nice and I really welcome his work trying to keep this arches in shape), but also makes me thing if makes sense to keep this agostino-dependency for this arches more and more time. What will occur if he is not around sometime? :/ We have been through the same discussion not so long ago and the result was to start dropping the ~m68k, s390 and sh to ~testing[1]. In the thread that started it all[2] there has been no resistance about dropping the keywords of these arches on $subject and here we are again discussing the problem. Here[3] you can see council's decision. I quote here just for fyi: In summary: - m68k, s390, sh: will be dropped to unstable keywords globally. - alpha, ia64: Maintainers can remove older stable versions according to the package-by-package proposal. - sparc: No action. So unless I make a mistake, you are free to start dropping alpha, ia64 to ~arch. For ppc,ppc64 and sparc it's probably best to resurrect the old thread and possible have add it to the agenda for the next meeting. [1] http://permalink.gmane.org/gmane.linux.gentoo.devel/88183 [2] http://www.gossamer-threads.com/lists/gentoo/dev/277054 [3] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt The problem arrives when even core components like udev takes so long to be handled :/ (and situation would be much worse if Agostino doesn't have time to make his mass stabilizations... well, each time I report a stabilization bug that affects me I cross my fingers expecting ago has enough time to handle them ;)) Relying on a single developer handling all architectures clearly does not scale and it is dangerous. We really need to be realistic and consider how many stable alpha/sparc/ia64/ppc* users are out there. In my mind the number is rather small, so does it really worth the effort trying to keep them stable hurting the remaining stable architectures and causing significant delays in publishing GLSAs? The reason I suggested to move the discussion back to the old thread is that some of these things have already been discussed in the past so I would like to avoid restarting the discussion from scratch. Yes, I agree. What I am trying to say is that this discussions usually ends when some people reports that statistically they don't take so long to stabilize and don't have so many opened bugs... but that statistics depends on ago being able to do the work recently and, then, it's a chicken-egg problem: we want and need him to stabilize on that arches... but that makes other think the arches are ok in that area while they are really relying on one man work :(
Re: [gentoo-dev] RFC: Removing src_test from www-client/chromium
On 5/31/14, 8:30 PM, Tom Wijsman wrote: On Sat, 31 May 2014 19:50:20 +0200 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: This is one of my points: I don't remember a single chromium bug filed in Gentoo that would be caught by a test or that a failing test actually detected. Your point covers the lack of tests, or tests that are non-fatal; however, it doesn't cover tests that are fatal, what if they fail? I'm confused by the distinction of fatal and non-fatal tests. Neither upstream nor the Gentoo chromium package makes that distinction. By the way, I don't remember seeing many reports about font issues or tab crashes. Please make sure to file them when they occur, or just point me to them in case I somehow missed them. They usually go straight to upstream, though I've managed to somehow fix it up; as for Gentoo, some people create forum threads about them. I can't speak for other people, but please consider reporting issues to Gentoo first. Our bug queue is under 30 bugs, while upstream is several thousand. Once we can confirm a bug clearly belongs to upstream, we can tell the reporter to file bug upstream or do that ourselves, but keeping Gentoo out of the loop seems to increase the time needed to fix a bug. (One was due to a library compiled with a less common flag, the other due to fontconfig being a regression magnet; both fun to debug, the former a test wolud've caught, the latter is due to the lack thereof) If there's something that could be changed e.g. in chromium's dependencies, please let me know. There are cases where we require certain USE flags to be set on dependencies for things to work properly. About the issue that a test would have caught: was that a chromium test? If so, which one? While I don't run tests myself; the need for them is clear, for those that aim for more production ready systems (eg. university network PCs). This seems too theoretical to me. I'd be fine with someone volunteering to maintain chromium's src_test in Gentoo. Unless we have such a person though, it seems to mostly take valuable focus away from bugs that definitely *do* affect our users, for no provable benefit for Gentoo. What about provable benefit for upstream? Does upstream /dev/null them? Effectively yes. For an example see https://bugs.gentoo.org/show_bug.cgi?id=497512 and https://groups.google.com/a/chromium.org/d/msg/chromium-dev/OdX7ShsOqsM/-R9sexJAEa4J The failure is not Gentoo-specific, and is not a bug in code but problem with the test (it makes assumptions about internal glibc implementation). It actually fails on the latest Ubuntu LTS Trusty Tahr, which means the test will have to be fixed or disabled upstream. But 6 months of no reaction is not really a good sign IMHO. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Removing src_test from www-client/chromium
On Sun, 01 Jun 2014 15:41:35 +0200 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 5/31/14, 8:30 PM, Tom Wijsman wrote: On Sat, 31 May 2014 19:50:20 +0200 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: This is one of my points: I don't remember a single chromium bug filed in Gentoo that would be caught by a test or that a failing test actually detected. Your point covers the lack of tests, or tests that are non-fatal; however, it doesn't cover tests that are fatal, what if they fail? I'm confused by the distinction of fatal and non-fatal tests. Neither upstream nor the Gentoo chromium package makes that distinction. Tests that break parts of your browser; you don't notice such tests in what was said, until one day such a test does break one or another way. By the way, I don't remember seeing many reports about font issues or tab crashes. Please make sure to file them when they occur, or just point me to them in case I somehow missed them. They usually go straight to upstream, though I've managed to somehow fix it up; as for Gentoo, some people create forum threads about them. I can't speak for other people, but please consider reporting issues to Gentoo first. Our bug queue is under 30 bugs, while upstream is several thousand. Once we can confirm a bug clearly belongs to upstream, we can tell the reporter to file bug upstream or do that ourselves, but keeping Gentoo out of the loop seems to increase the time needed to fix a bug. This confuses me; your thread opener seems to suggest you have too much bugs, whereas this one seems to suggest you don't have enough bugs. What's the purpose of disabling src_test if bug count isn't a problem? Iotw, why are you making a project-internal decision here? (Your last two paragraphs may respond to this; in which case, nvm) (One was due to a library compiled with a less common flag, the other due to fontconfig being a regression magnet; both fun to debug, the former a test wolud've caught, the latter is due to the lack thereof) If there's something that could be changed e.g. in chromium's dependencies, please let me know. There are cases where we require certain USE flags to be set on dependencies for things to work properly. Wasn't the case of a different version or USE flag state; but that is the case one or another day, I'll let you know. About the issue that a test would have caught: was that a chromium test? If so, which one? Unable to tell, since I don't run them. While I don't run tests myself; the need for them is clear, for those that aim for more production ready systems (eg. university network PCs). This seems too theoretical to me. I'd be fine with someone volunteering to maintain chromium's src_test in Gentoo. Unless we have such a person though, it seems to mostly take valuable focus away from bugs that definitely *do* affect our users, for no provable benefit for Gentoo. What about provable benefit for upstream? Does upstream /dev/null them? Effectively yes. For an example see https://bugs.gentoo.org/show_bug.cgi?id=497512 and https://groups.google.com/a/chromium.org/d/msg/chromium-dev/OdX7ShsOqsM/-R9sexJAEa4J The failure is not Gentoo-specific, and is not a bug in code but problem with the test (it makes assumptions about internal glibc implementation). It actually fails on the latest Ubuntu LTS Trusty Tahr, which means the test will have to be fixed or disabled upstream. But 6 months of no reaction is not really a good sign IMHO. Paweł Yeah; if failing tests on distributions aren't getting fixed by upstream, then there's indeed no point to keep them running. Though; on the other hand, one has to consider that this acts like a priority queue and therefore tests that fail on most distributions would get fixed before tests that fail on just one or two distributions. It's a tricky decision to drop them; but it's not an irreversible decision, thus a reevaluation in 5 years from now could be possible. If that reevaluation then shows a responsive upstream, reconsider src_test. Don't mind me, I've played devil's advocate to explore the reasoning; go ahead if you want to, given it barely result in fatal test failures. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] alpha, ia64, ppc, ppc64, sparc developers, need your attention
01.06.2014 15:18, Samuli Suominen пишет: http://bugs.gentoo.org/show_bug.cgi?id=505962#c6 is blocking stabilizing the new virtuals, and thus, converting the tree, and also blocking stabilization of the already converted packages (gnome seems to have some) pending for 3 months already thanks, samuli Is compile only test enough for you? If so, i can take care about it right now.
Re: [gentoo-dev] alpha, ia64, ppc, ppc64, sparc developers, need your attention
On 01/06/14 18:48, Mikle Kolyada wrote: 01.06.2014 15:18, Samuli Suominen пишет: http://bugs.gentoo.org/show_bug.cgi?id=505962#c6 is blocking stabilizing the new virtuals, and thus, converting the tree, and also blocking stabilization of the already converted packages (gnome seems to have some) pending for 3 months already thanks, samuli Is compile only test enough for you? If so, i can take care about it right now. yes, compile test is enough, because the changes are not that large compared to current stable
Re: [gentoo-dev] alpha, ia64, ppc, ppc64, sparc developers, need your attention
On 06/01/14 08:07, Pacho Ramos wrote: The problem arrives when even core components like udev takes so long to be handled :/ (and situation would be much worse if Agostino doesn't have time to make his mass stabilizations... well, each time I report a stabilization bug that affects me I cross my fingers expecting ago has enough time to handle them ;)) I'll help out with the ppc32/64. Ping me for important packages. I'd like to ignore low level ones. I'm taking care of udev as I type this. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2014-06-01 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2014-06-01 23h59 UTC. Removals: dev-lang/fpc-ide2014-05-26 06:14:10 radhermit app-emulation/qemu-user 2014-05-30 04:38:08 vapier Additions: net-libs/balde-markdown 2014-05-26 02:36:50 rafaelmartins dev-python/mimerender 2014-05-26 06:46:24 patrick dev-python/multipledispatch 2014-05-26 07:42:23 patrick lxqt-base/lxqt-session 2014-05-26 14:03:42 jauhien lxqt-base/lxqt-common 2014-05-26 14:03:42 jauhien x11-misc/obconf-qt 2014-05-26 14:21:07 jauhien lxqt-base/liblxqt-mount 2014-05-26 15:12:27 jauhien lxqt-base/libsysstat2014-05-26 15:21:15 jauhien lxqt-base/lxqt-globalkeys 2014-05-26 15:30:07 jauhien lxqt-base/lxqt-panel2014-05-26 16:08:22 jauhien sys-power/upower-pm-utils 2014-05-26 19:37:42 ssuominen dev-python/shortuuid2014-05-27 06:17:52 ercpe dev-python/cfgio2014-05-27 06:31:20 ercpe lxqt-base/lxqt-about2014-05-27 14:13:33 jauhien lxqt-base/lxqt-notificationd2014-05-27 14:41:31 jauhien lxqt-base/lxqt-config 2014-05-27 14:54:04 jauhien lxqt-base/lxqt-config-randr 2014-05-27 15:04:52 jauhien lxqt-base/lxqt-policykit2014-05-27 15:18:55 jauhien lxqt-base/lxqt-runner 2014-05-27 15:37:56 jauhien lxqt-base/lxqt-powermanagement 2014-05-27 15:59:48 jauhien media-gfx/lximage-qt2014-05-27 16:47:47 jauhien lxqt-base/lxqt-meta 2014-05-27 18:20:21 jauhien www-apache/mpm_itk 2014-05-28 02:23:41 mjo dev-perl/HTML-FormatText-WithLinks-AndTables2014-05-28 10:14:30 titanofold dev-perl/Data-GUID 2014-05-28 10:15:02 titanofold dev-perl/Mozilla-CA 2014-05-28 10:15:29 titanofold dev-perl/Date-Extract 2014-05-28 10:16:01 titanofold dev-perl/Role-Basic 2014-05-28 10:16:39 titanofold dev-perl/Email-Address-List 2014-05-28 10:17:08 titanofold dev-perl/Symbol-Global-Name 2014-05-28 10:17:35 titanofold dev-perl/HTML-FormatText-WithLinks 2014-05-28 10:18:02 titanofold dev-java/jboss-marshalling 2014-05-28 15:41:48 tomwij net-libs/libtelnet 2014-05-28 15:47:22 nativemad dev-java/netty-codec2014-05-28 17:28:39 tomwij app-backup/qt4-fsarchiver 2014-05-28 20:03:09 hasufell dev-perl/Crypt-X509 2014-05-29 09:16:07 titanofold dev-ruby/creole 2014-05-30 01:46:15 mrueg dev-libs/libgaminggear 2014-05-30 10:20:05 swift app-pda/libusbmuxd 2014-05-30 11:30:51 ssuominen dev-java/netty-handler 2014-05-30 12:10:59 tomwij app-misc/eid-viewer-bin 2014-05-30 12:13:19 swift dev-libs/grok 2014-05-31 12:59:08 ercpe dev-ruby/sshkit 2014-06-01 07:13:58 graaff -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-lang/fpc-ide,removed,radhermit,2014-05-26 06:14:10 app-emulation/qemu-user,removed,vapier,2014-05-30 04:38:08 Added Packages: net-libs/balde-markdown,added,rafaelmartins,2014-05-26 02:36:50 dev-python/mimerender,added,patrick,2014-05-26 06:46:24 dev-python/multipledispatch,added,patrick,2014-05-26 07:42:23 lxqt-base/lxqt-session,added,jauhien,2014-05-26 14:03:42 lxqt-base/lxqt-common,added,jauhien,2014-05-26 14:03:42 x11-misc/obconf-qt,added,jauhien,2014-05-26 14:21:07 lxqt-base/liblxqt-mount,added,jauhien,2014-05-26 15:12:27 lxqt-base/libsysstat,added,jauhien,2014-05-26 15:21:15 lxqt-base/lxqt-globalkeys,added,jauhien,2014-05-26 15:30:07 lxqt-base/lxqt-panel,added,jauhien,2014-05-26 16:08:22 sys-power/upower-pm-utils,added,ssuominen,2014-05-26 19:37:42 dev-python/shortuuid,added,ercpe,2014-05-27 06:17:52 dev-python/cfgio,added,ercpe,2014-05-27 06:31:20 lxqt-base/lxqt-about,added,jauhien,2014-05-27 14:13:33 lxqt-base/lxqt-notificationd,added,jauhien,2014-05-27 14:41:31 lxqt-base/lxqt-config,added,jauhien,2014-05-27 14:54:04
