[gentoo-dev] Packages up for grabs (ruby applications)
Over time a number of packages have ended up in the ruby herd due to maintainers leaving and being dropped from metadata. These packages really need dedicated maintainers who understand what these applications are meant to do and who can do proper testing for them. As such, I'll be adding maintainer-needed as the primary maintainer to these packages in a week or so unless someone picks them up. Most of these packages currently require version bumps and may have open bugs. app-admin/rudy app-misc/booh app-office/rabbit app-office/tpp app-text/webgen games-util/rubygfe net-news/raggle www-apps/nanoc www-servers/mongrel www-servers/mongrel_cluster www-servers/thin
[gentoo-dev] Lastrites: media-libs/openinventor, dev-cpp/libebt, sys-kernel/ksymoops, net-p2p/bitstormlite, net-p2p/mutella, dev-cpp/IceE
# Pacho Ramos (21 Jul 2013) # Doesn't compile with gcc-4.7 (#414143), lib is no longer # opensource or free. Removal in a month. media-libs/openinventor # Pacho Ramos (21 Jul 2013) # Doesn't compile with boost-1.50 and with automake-1.13 # (#425448). Removal in a month. dev-cpp/libebt # Pacho Ramos (21 Jul 2013) # Doesn't compile and not useful with kernel >= 2.6 (#428728). # Removal in a month. sys-kernel/ksymoops # Pacho Ramos (21 Jul 2013) # Fails to build with glibc-2.16 (#428738), upstream dead. # Removal in a month. net-p2p/bitstormlite # Pacho Ramos (21 Jul 2013) # Fails to build with gcc-4.7, upstream dead (#429362). # Removal in a month. net-p2p/mutella # Pacho Ramos (21 Jul 2013) # Doesn't build with gcc-4.7, nothing requires it. # (#465896). Removal in a month. dev-cpp/IceE
[gentoo-dev] vserver herd is empty
Will remove the herd if nobody joins in a week. Thanks!
[gentoo-dev] Packages up for grabs
Due sbriesen lack of time: app-cdr/mkcdtoc app-text/sigil dev-db/lib_mysqludf_fPROJ4 dev-db/lib_mysqludf_json dev-db/lib_mysqludf_log dev-db/lib_mysqludf_preg dev-db/lib_mysqludf_stem dev-db/lib_mysqludf_stat dev-db/lib_mysqludf_str dev-db/lib_mysqludf_sys dev-db/lib_mysqludf_ta dev-db/lib_mysqludf_xql dev-db/lib_mysqludf_udf dev-db/mysql-udf-base64 dev-db/mysql-udf-http dev-db/mysql-udf-infusion dev-db/mysql-udf-ipv6 dev-libs/libyaml dev-python/crcmod dev-python/gmpy dev-python/pycdio dev-python/pydns dev-python/pysyck dev-python/pyyaml dev-python/tagpy dev-python/tlslite dev-python/xmpppy media-gfx/exiv2 media-gfx/iscan-data media-gfx/iscan media-gfx/peps media-libs/leptonica media-sound/alac_decoder media-sound/declick media-sound/neroaac media-sound/shnflacverify media-sound/vbrfixc net-dns/ez-ipupdate net-print/adobeps sys-apps/idle3-tools sys-apps/nca sys-apps/pcfclock sys-block/scsiadd sys-fs/fuse-convmvfs net-misc/capi4hylafax
[gentoo-dev] Packages up for grabs
Due phosphan lack of time: app-admin/lcap app-admin/fetchlog app-misc/mepl app-text/epstool dev-db/vbisam dev-lang/tinycobol dev-util/cdecl media-gfx/sane-backends media-gfx/sane-frontends media-libs/libemf net-analyzer/prelude-nessus net-ftp/weex net-mail/libdbx net-mail/vacation
Re: [gentoo-dev] sgml herd has no maintainers (again)
El vie, 21-06-2013 a las 18:35 +0200, Pacho Ramos escribió: > El dom, 17-03-2013 a las 11:02 -0400, Mike Gilbert escribió: > > I just dropped myself due to lack of interest. > > > > If anyone cares for any of the packages please take them over. > > > > > > Will dissolve it next week if nobody joins then > > > This packages are up for grabs now: app-doc/halibut app-office/passepartout app-text/asciidoc app-text/build-docbook-catalog app-text/docbook-dsssl-stylesheets app-text/docbook-sgml-dtd app-text/docbook-sgml-utils app-text/docbook-sgml app-text/docbook-xml-dtd app-text/docbook-xml-simple-dtd app-text/docbook-xsl-stylesheets app-text/docbook2X app-text/gentoo-guide-xml-dtd app-text/grutatxt app-text/html-xml-utils app-text/html2text app-text/html401 app-text/htmlrecode app-text/htmltidy app-text/linuxdoc-tools app-text/openjade app-text/opensp app-text/robodoc app-text/sablotron app-text/sgml-common app-text/sgmltools-lite app-text/sgrep app-text/txt2tags app-text/xhtml1 app-text/xml2 app-text/xmlformat app-text/xmlto www-client/htmlview
Re: [gentoo-dev] gdesklets herd is empty
El dom, 16-06-2013 a las 11:38 +0200, Pacho Ramos escribió: > Feel free to join to it or will be removed in two weeks > > Thanks! > > > The following packages are up for grabs then: gnome-extra/gdesklets-core x11-plugins/desklet-Genesis x11-plugins/desklet-ImageSlideShow x11-plugins/desklet-Mouse x11-plugins/desklet-SlideShow x11-plugins/desklet-WeeklyCalendar x11-plugins/desklet-ftb x11-plugins/desklet-iCalendarEvent x11-plugins/desklet-justanicon x11-plugins/desklet-sudoku
Re: [gentoo-dev] Packages up for grabs
Am Sonntag, 21. Juli 2013, 11:10:26 schrieb Pacho Ramos: > Due sbriesen lack of time: > (...) > media-gfx/exiv2 kde team can take this, however we'd be happy about co-maintainers... gnomies? :) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
El mar, 03-07-2012 a las 10:02 +0200, Michał Górny escribió:
> On Mon, 02 Jul 2012 13:45:26 -0700
> Zac Medico wrote:
>
> > On 07/02/2012 01:36 PM, viv...@gmail.com wrote:
> > > Il 02/07/2012 22:01, Zac Medico ha scritto:
> > >> On 07/02/2012 12:48 PM, Pacho Ramos wrote:
> > >>> El lun, 28-05-2012 a las 14:34 -0700, Zac Medico escribió:
> > Hi,
> >
> > In case you aren't familiar with FEATURES=userpriv, here's the
> > description from the make.conf(5) man page:
> >
> > Allow portage to drop root privileges and compile packages as
> > portage:portage without a sandbox (unless usersandbox is also
> > used).
> >
> > The rationale for having the separate "usersandbox" setting, to
> > enable use of sys-apps/sandbox, is that people who enable
> > userpriv sometimes prefer to have sandbox disabled in order to
> > slightly improve performance. However, I would recommend to
> > enable usersandbox by default, for the purpose of logging
> > sandbox violations.
> >
> > Note that ebuilds can set RESTRICT="userpriv" if they require
> > superuser privileges during any of the src_* phases that
> > userpriv affects.
> >
> > I've been using FEATURES="userpriv usersandbox" for years, and I
> > don't remember experiencing any problems because of it, so I
> > think that it would be reasonable to have it enabled by default.
> > Objections?
> > >>> Looks like non important problems arised and, then, these could
> > >>> probably be enabled by default, no? :)
> > >> I'm not sure about the best way to handle migration for directories
> > >> inside $DISTDIR that are used by live ebuilds, since src_unpack
> > >> will run with different privileges when userpriv is enabled.
> > > tell the user to chown/remove the files/directories if and when
> > > needed,
> >
> > How should we tell them? Elog message, news item, or both?
>
> I think this deserves a news item anyway.
>
> > > unless there is a very good reason (try) to automate it.
> >
> > I guess something like this might work in pkg_postinst of the portage
> > ebuild:
> >
> > find "$DISTDIR" -maxdepth 1 -type d -uid 0 | xargs chown -R
> > portage:portage
>
> find "$DISTDIR" -maxdepth 1 -type d -uid 0 -exec \
> chown -R portage:portage {} +
>
> > I would only trigger something like this once, when upgrading from a
> > version that doesn't have userpriv enabled by default.
>
> This will work only for users who actually keep those in DISTDIR. Some
> of them actually redefine E*_STORE_DIR to a more sane location. But
> that's probably irrelevant.
>
Then, is there any other blocker? (apart of the needing of add a news
item)
Thanks :)
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
El sáb, 31-03-2012 a las 17:33 -0700, Zac Medico escribió: > On 03/31/2012 04:25 PM, Walter Dnes wrote: > > On Sat, Mar 31, 2012 at 10:42:50AM -0700, Zac Medico wrote > >> On 03/31/2012 06:34 AM, Pacho Ramos wrote: > >>> About the wiki page, I can only document reiserfs+tail usage as it's the > >>> one I use and I know, about other alternatives like using squashfs, loop > >>> mount... I cannot promise anything as I simply don't know how to set > >>> them. > >> > >> Squashfs is really simple to use: > >> > >>mksquashfs /usr/portage portage.squashfs > >>mount -o loop portage.squashfs /usr/portage > > > > Don't the "space-saving filesystems" (squashfs, reiserfs-with-tail, > > etc) run more slowly due to their extra finicky steps to save space? If > > you really want to save a gigabyte or 2, run "eclean -d distfiles" and > > "localepurge" after every emerge update. I've also cobbled together my > > own "autodepclean" script that check for, and optionally unmerges > > unneeded stuff that was pulled in as a dependancy of a package that has > > since been removed. > > Well, in this case squashfs is more about improving access time than > saving space. You end up with the whole tree stored in a mostly > contiguous chunk of disk space, which minimizes seek time. Would be possible to generate and provide squashed files at the same time tarballs with portage tree snapshots are generated? mksquashfs can take a lot of resources depending on the machine, but providing the squashed images would still benefit people allowing them to download and mount them
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
Dnia 2013-07-21, o godz. 13:42:17 Pacho Ramos napisał(a): > El sáb, 31-03-2012 a las 17:33 -0700, Zac Medico escribió: > > On 03/31/2012 04:25 PM, Walter Dnes wrote: > > > On Sat, Mar 31, 2012 at 10:42:50AM -0700, Zac Medico wrote > > >> On 03/31/2012 06:34 AM, Pacho Ramos wrote: > > >>> About the wiki page, I can only document reiserfs+tail usage as it's the > > >>> one I use and I know, about other alternatives like using squashfs, loop > > >>> mount... I cannot promise anything as I simply don't know how to set > > >>> them. > > >> > > >> Squashfs is really simple to use: > > >> > > >>mksquashfs /usr/portage portage.squashfs > > >>mount -o loop portage.squashfs /usr/portage > > > > > > Don't the "space-saving filesystems" (squashfs, reiserfs-with-tail, > > > etc) run more slowly due to their extra finicky steps to save space? If > > > you really want to save a gigabyte or 2, run "eclean -d distfiles" and > > > "localepurge" after every emerge update. I've also cobbled together my > > > own "autodepclean" script that check for, and optionally unmerges > > > unneeded stuff that was pulled in as a dependancy of a package that has > > > since been removed. > > > > Well, in this case squashfs is more about improving access time than > > saving space. You end up with the whole tree stored in a mostly > > contiguous chunk of disk space, which minimizes seek time. > > Would be possible to generate and provide squashed files at the same > time tarballs with portage tree snapshots are generated? mksquashfs can > take a lot of resources depending on the machine, but providing the > squashed images would still benefit people allowing them to download and > mount them I'm experimenting with squashfs lately and here's a few notes: 1. I didn't find a good way of generating incremental images with squashfs itself. I didn't try tools like diffball (those that were used in emerge-delta-webrsync) but I recall they were very slow (you'd have to use 56K modem to get them faster than rsync) and I doubt they'll fit squashfs specifics. 2. squashfs is best used with union filesystem like aufs3. However, that basically requires patching the kernel since FUSE-based union filesystems simply don't work. a) unionfs-fuse doesn't support replacing files from read-only branch, b) funinonfs gets broken with rsync somehow. I haven't tested le ol' unionfs, but aufs3 I get working great. 3. squashfs+aufs3 really benefits from '--omit-dir-times' rsync option. Otherwise, it recreates the whole directory structure on each rsync. This also causes much less output. We should think about making this the default. 4. 'emerge --sync' is ultra-fast with this combo. very big sync goes in less than a minute. 5. I have doubts about 'emerge -1vDtu @world' speed. It is very subjective feeling but I feel like reiserfs was actually faster in this regard. However, space savings would surely benefit our users. 6. if we're to do squahfs+aufs3, we need a clean dir structure for all of it, including squashfs files, intermediate mounts and r/w branches. 7. we could probably get incremential squashfs+aufs3 through squashing old r/w branches and adding new ones on top of them. But considering the 'emerge --sync' speed gain, I don't know if this is really worth the effort, and if increase in branches wouldn't make it slow. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
El dom, 21-07-2013 a las 13:57 +0200, Michał Górny escribió: [...] > 5. I have doubts about 'emerge -1vDtu @world' speed. It is very > subjective feeling but I feel like reiserfs was actually faster in this > regard. However, space savings would surely benefit our users. > I also feel it faster (or, at least, not slower) with reiserfs, but going from ~300 MB to 79. Not sure if it would benefit from putting squashed image in a different filesystem (it was placed in /root, that is ext4 in my case). Maybe it would be faster if generated image was put in /var/tmp/portage (that is tmpfs in my case) But I am testing it with plain squashfs (without write support)
Re: [gentoo-dev] Packages up for grabs
On 21/07/2013 10:10, Pacho Ramos wrote: > media-gfx/iscan-data > media-gfx/iscan I'll pick up these two (soon as my laptop gets back working).. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
Dnia 2013-07-21, o godz. 14:06:12 Pacho Ramos napisał(a): > El dom, 21-07-2013 a las 13:57 +0200, Michał Górny escribió: > [...] > > 5. I have doubts about 'emerge -1vDtu @world' speed. It is very > > subjective feeling but I feel like reiserfs was actually faster in this > > regard. However, space savings would surely benefit our users. > > > > I also feel it faster (or, at least, not slower) with reiserfs, but > going from ~300 MB to 79. Not sure if it would benefit from putting > squashed image in a different filesystem (it was placed in /root, that > is ext4 in my case). Maybe it would be faster if generated image was put > in /var/tmp/portage (that is tmpfs in my case) Using different block size may make a difference. I suspect that most important reason for the slowdown is due to random accesses. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/21/2013 01:42 PM, Pacho Ramos wrote: > Would be possible to generate and provide squashed files at the > same time tarballs with portage tree snapshots are generated? > mksquashfs can take a lot of resources depending on the machine, > but providing the squashed images would still benefit people > allowing them to download and mount them I've establish a cron job on my server to generate gzip and xz squashed snapshots. I sync distfiles from utwente at 6:05 and generate the squashfs at 6:35 after verifying the gpg signatures. There's a 10,5h lag between snapshots and squashfs files - we could improve if I'm allowed to sync against master rsync/dinstfiles. [1] http://lore.xmw.de/gentoo/genberry/snapshots/ - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlHr744ACgkQknrdDGLu8JAuNAD/YB8f+Pee7FNkjnNfnjaCYyMM kdYw2JnbGyH4Srvqlj8A/A/yC37W7MFOZSESLFipkvG01zQ6EvTM0576dC1Z9kdI =lBLB -END PGP SIGNATURE-
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
On 7/21/13 4:26 PM, Michael Weber wrote: > On 07/21/2013 01:42 PM, Pacho Ramos wrote: >> Would be possible to generate and provide squashed files at the >> same time tarballs with portage tree snapshots are generated? >> mksquashfs can take a lot of resources depending on the machine, >> but providing the squashed images would still benefit people >> allowing them to download and mount them > > I've establish a cron job on my server to generate gzip and xz > squashed snapshots. I sync distfiles from utwente at 6:05 and generate > the squashfs at 6:35 after verifying the gpg signatures. > There's a 10,5h lag between snapshots and squashfs files - we could > improve if I'm allowed to sync against master rsync/dinstfiles. > > [1] http://lore.xmw.de/gentoo/genberry/snapshots/ > > I am creating them as well. Perhaps we can bundle the effort. What I also found out that using zsync is quite efficient with squashfs images. I normally don't sync more then 20-30% of the image. Justin signature.asc Description: OpenPGP digital signature
[gentoo-dev] Peculiarities of gentoo-dev-announce
Just for your general enlightenment, gentoo-dev-announce now silently discards (!) messages without Reply-To header. Thought you might want to know. Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer (council, kde) dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] remove sci-geosciences/googleearth from the tree
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I am maintaining it for some months now and it has reached a state
where we should think about treecleaning it.
reasons:
a) bundles tons of libs since ages (security and stability issues,
many of them can not be unbundled)
https://bugs.gentoo.org/show_bug.cgi?id=212373
b) segfaults randomly; the new version as well
https://code.google.com/p/earth-api-samples/issues/detail?id=957
https://code.google.com/p/earth-issues/issues/detail?id=1608
https://bugs.gentoo.org/show_bug.cgi?id=470684
c) random runtime bugs
https://bugs.gentoo.org/show_bug.cgi?id=474462
d) upstream ignores bug reports or is unable to fix them
e) upstream is unable to upload tarballs with a version in the
filename which leads to checksum failure and trouble for users if they
want to install an older version, because the new one is broken again
Maintaining a package in gentoo implies a few things for me:
We are able to support it properly which either means that we can
communicate with upstream or at least (if that fails) fix bugs on our
own. Currently, both does not apply to googleearth which means we
cannot resolve a lot of bugs in any way.
Also... software in the tree should meet a minimum of quality and we
should not support vulnerable and broken software officially.
solution: Treeclean it and maintain it in an overlay (maybe
science-overlay). That's exactly what overlays are for... experimental
stuff.
alternatives to googleearth:
- - lots of web services ("google maps", "openstreet maps", ...)
- - "nasa world wind" (not in the tree afais but opensource and java)
- - kde-base/marble
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJR6/ywAAoJEFpvPKfnPDWzHjMIAKqEUw5AKmuSxLe8hicFDqbN
lR92Hq6cKMqhJDrIB/uohT+PdjnBfC4hZabCFLPSB9uijOXpR2cliwFeKuq6eeJE
3HW1UuaVd71s0r8cCGO6sFhuoN56DJapF0OvU6TU7CouZcpR7gIuN7jhGcj4uVf2
JDI8HT+n4f9L5cTSb65YhLYZjuUGEHqZn6g6X6o2G01kZaoYPyFHatUkfXyb7FSm
jpJWCLWv4CdmEZWb+YbN+afHGYU4rkbW7XLJ6gLmvJxx/TtHg9FFU6xJotAlMvTL
X5lHQDep2iWwYm7hA5r1h9xM98ElucI4Eg+lsiLbkmCj3mIR3QS5Nq+b2VaN9lc=
=Qslh
-END PGP SIGNATURE-
Re: [gentoo-dev] Packages up for grabs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/21/2013 12:41 PM, Andreas K. Huettel wrote: > Am Sonntag, 21. Juli 2013, 11:10:26 schrieb Pacho Ramos: >> Due sbriesen lack of time: (...) media-gfx/exiv2 > > kde team can take this, however we'd be happy about > co-maintainers... gnomies? :) i can take care. i wanted to do a multiabi version anyway. - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlHsDDwACgkQknrdDGLu8JBaDwD+IvOYWCRmKi1EwDuD52ryUiSY RwP/jujj+c1yRDwjvMcA/R1zYwyVj0vVUd59A2Xb1XESK401o7cujkzTbWsOtu7t =Z3/a -END PGP SIGNATURE-
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
El dom, 21-07-2013 a las 16:46 +0200, justin escribió: > On 7/21/13 4:26 PM, Michael Weber wrote: > > On 07/21/2013 01:42 PM, Pacho Ramos wrote: > >> Would be possible to generate and provide squashed files at the > >> same time tarballs with portage tree snapshots are generated? > >> mksquashfs can take a lot of resources depending on the machine, > >> but providing the squashed images would still benefit people > >> allowing them to download and mount them > > > > I've establish a cron job on my server to generate gzip and xz > > squashed snapshots. I sync distfiles from utwente at 6:05 and generate > > the squashfs at 6:35 after verifying the gpg signatures. > > There's a 10,5h lag between snapshots and squashfs files - we could > > improve if I'm allowed to sync against master rsync/dinstfiles. > > > > [1] http://lore.xmw.de/gentoo/genberry/snapshots/ > > > > > > I am creating them as well. Perhaps we can bundle the effort. > > What I also found out that using zsync is quite efficient with squashfs > images. I normally don't sync more then 20-30% of the image. > > Justin > Maybe infra could be contacted to try to share the effort (and also offer the snapshot in a bit more "official" way, I mean, similar to tarballs with snapshots)
Re: [gentoo-dev] remove sci-geosciences/googleearth from the tree
On Sun, Jul 21, 2013 at 11:22 AM, hasufell wrote: > I am maintaining it for some months now and it has reached a state > where we should think about treecleaning it. ++ > Maintaining a package in gentoo implies a few things for me: > We are able to support it properly which either means that we can > communicate with upstream or at least (if that fails) fix bugs on our > own. Currently, both does not apply to googleearth which means we > cannot resolve a lot of bugs in any way. > Also... software in the tree should meet a minimum of quality and we > should not support vulnerable and broken software officially. >From your description it seems like Google Earth is really pushing it. I wouldn't call it "vulnerable" and "broken" though - software is only vulnerable if there is a known exploit. Bundling libraries is bad practice because it increases the risk of such vulnerabilities existing, but on its own shouldn't be grounds for removal. It certainly has the potential to increase the workload for maintainers though. My sense is that none of the problems you listed should really be considered a reason that something MUST be removed from the tree, but they certainly tend to add up. If somebody wants to take over wrestling with it I don't think we should look down on that though. Rich
Re: [gentoo-dev] remove sci-geosciences/googleearth from the tree
On 07/21/2013 07:42 PM, Rich Freeman wrote: > On Sun, Jul 21, 2013 at 11:22 AM, hasufell wrote: >> I am maintaining it for some months now and it has reached a state >> where we should think about treecleaning it. > > ++ > >> Maintaining a package in gentoo implies a few things for me: >> We are able to support it properly which either means that we can >> communicate with upstream or at least (if that fails) fix bugs on our >> own. Currently, both does not apply to googleearth which means we >> cannot resolve a lot of bugs in any way. >> Also... software in the tree should meet a minimum of quality and we >> should not support vulnerable and broken software officially. > > From your description it seems like Google Earth is really pushing it. > I wouldn't call it "vulnerable" and "broken" though - software is > only vulnerable if there is a known exploit. Bundling libraries is > bad practice because it increases the risk of such vulnerabilities > existing, but on its own shouldn't be grounds for removal. It > certainly has the potential to increase the workload for maintainers > though. > > My sense is that none of the problems you listed should really be > considered a reason that something MUST be removed from the tree, but > they certainly tend to add up. If somebody wants to take over > wrestling with it I don't think we should look down on that though. > > Rich > I have no problem with maintaing it, but that does not change my opinion that it's simply not fit for the tree. I'd maintain it in an overlay then where we can play with hacks and whatnot to get it working. But people should expect that things work somehow in the tree, even on ~arch. Even worse: the stable googleearth builds are unfetchable and that's not how I'd define any stable ebuild in the tree.
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
On 07/21/2013 04:57 AM, Michał Górny wrote: > a) unionfs-fuse doesn't support replacing files from read-only branch, Maybe you've got some kind of configuration problem (did you forget to enable the cow option?), because unionfs-fuse seems to work fine for me. -- Thanks, Zac
Re: [gentoo-dev] remove sci-geosciences/googleearth from the tree
On Sun, Jul 21, 2013 at 1:55 PM, hasufell wrote: > But people should expect that things work somehow in the tree, even on > ~arch. Even worse: the stable googleearth builds are unfetchable and > that's not how I'd define any stable ebuild in the tree. You'll get no argument from me on any of that. At the very least something like this probably needs to be repackaged and hosted, assuming this is legally permissible. Rich
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On 07/21/2013 03:53 AM, Pacho Ramos wrote:
> El mar, 03-07-2012 a las 10:02 +0200, Michał Górny escribió:
>> On Mon, 02 Jul 2012 13:45:26 -0700
>> Zac Medico wrote:
>>
>>> On 07/02/2012 01:36 PM, viv...@gmail.com wrote:
Il 02/07/2012 22:01, Zac Medico ha scritto:
> On 07/02/2012 12:48 PM, Pacho Ramos wrote:
>> El lun, 28-05-2012 a las 14:34 -0700, Zac Medico escribió:
>>> Hi,
>>>
>>> In case you aren't familiar with FEATURES=userpriv, here's the
>>> description from the make.conf(5) man page:
>>>
>>>Allow portage to drop root privileges and compile packages as
>>>portage:portage without a sandbox (unless usersandbox is also
>>> used).
>>>
>>> The rationale for having the separate "usersandbox" setting, to
>>> enable use of sys-apps/sandbox, is that people who enable
>>> userpriv sometimes prefer to have sandbox disabled in order to
>>> slightly improve performance. However, I would recommend to
>>> enable usersandbox by default, for the purpose of logging
>>> sandbox violations.
>>>
>>> Note that ebuilds can set RESTRICT="userpriv" if they require
>>> superuser privileges during any of the src_* phases that
>>> userpriv affects.
>>>
>>> I've been using FEATURES="userpriv usersandbox" for years, and I
>>> don't remember experiencing any problems because of it, so I
>>> think that it would be reasonable to have it enabled by default.
>>> Objections?
>> Looks like non important problems arised and, then, these could
>> probably be enabled by default, no? :)
> I'm not sure about the best way to handle migration for directories
> inside $DISTDIR that are used by live ebuilds, since src_unpack
> will run with different privileges when userpriv is enabled.
tell the user to chown/remove the files/directories if and when
needed,
>>>
>>> How should we tell them? Elog message, news item, or both?
>>
>> I think this deserves a news item anyway.
>>
unless there is a very good reason (try) to automate it.
>>>
>>> I guess something like this might work in pkg_postinst of the portage
>>> ebuild:
>>>
>>> find "$DISTDIR" -maxdepth 1 -type d -uid 0 | xargs chown -R
>>> portage:portage
>>
>> find "$DISTDIR" -maxdepth 1 -type d -uid 0 -exec \
>> chown -R portage:portage {} +
>>
>>> I would only trigger something like this once, when upgrading from a
>>> version that doesn't have userpriv enabled by default.
>>
>> This will work only for users who actually keep those in DISTDIR. Some
>> of them actually redefine E*_STORE_DIR to a more sane location. But
>> that's probably irrelevant.
>>
>
> Then, is there any other blocker? (apart of the needing of add a news
> item)
>
> Thanks :)
>
I can't think of anything else. I've filed this bug:
https://bugs.gentoo.org/show_bug.cgi?id=477664
--
Thanks,
Zac
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On 21/07/13 02:25 PM, Zac Medico wrote:
> On 07/21/2013 03:53 AM, Pacho Ramos wrote:
>> El mar, 03-07-2012 a las 10:02 +0200, Michał Górny escribió:
>>> On Mon, 02 Jul 2012 13:45:26 -0700
>>> Zac Medico wrote:
>>>
On 07/02/2012 01:36 PM, viv...@gmail.com wrote:
> Il 02/07/2012 22:01, Zac Medico ha scritto:
>> On 07/02/2012 12:48 PM, Pacho Ramos wrote:
>>> El lun, 28-05-2012 a las 14:34 -0700, Zac Medico escribió:
Hi,
In case you aren't familiar with FEATURES=userpriv, here's the
description from the make.conf(5) man page:
Allow portage to drop root privileges and compile packages as
portage:portage without a sandbox (unless usersandbox is also
used).
The rationale for having the separate "usersandbox" setting, to
enable use of sys-apps/sandbox, is that people who enable
userpriv sometimes prefer to have sandbox disabled in order to
slightly improve performance. However, I would recommend to
enable usersandbox by default, for the purpose of logging
sandbox violations.
Note that ebuilds can set RESTRICT="userpriv" if they require
superuser privileges during any of the src_* phases that
userpriv affects.
I've been using FEATURES="userpriv usersandbox" for years, and I
don't remember experiencing any problems because of it, so I
think that it would be reasonable to have it enabled by default.
Objections?
>>> Looks like non important problems arised and, then, these could
>>> probably be enabled by default, no? :)
>> I'm not sure about the best way to handle migration for directories
>> inside $DISTDIR that are used by live ebuilds, since src_unpack
>> will run with different privileges when userpriv is enabled.
> tell the user to chown/remove the files/directories if and when
> needed,
How should we tell them? Elog message, news item, or both?
>>>
>>> I think this deserves a news item anyway.
>>>
> unless there is a very good reason (try) to automate it.
I guess something like this might work in pkg_postinst of the portage
ebuild:
find "$DISTDIR" -maxdepth 1 -type d -uid 0 | xargs chown -R
portage:portage
>>>
>>> find "$DISTDIR" -maxdepth 1 -type d -uid 0 -exec \
>>> chown -R portage:portage {} +
>>>
I would only trigger something like this once, when upgrading from a
version that doesn't have userpriv enabled by default.
>>>
>>> This will work only for users who actually keep those in DISTDIR. Some
>>> of them actually redefine E*_STORE_DIR to a more sane location. But
>>> that's probably irrelevant.
>>>
>>
>> Then, is there any other blocker? (apart of the needing of add a news
>> item)
>>
>> Thanks :)
>>
>
> I can't think of anything else. I've filed this bug:
>
> https://bugs.gentoo.org/show_bug.cgi?id=477664
>
userpriv and usersandbox don't work in pypy because os.setgroups isn't
implemented there.
I had a go at it a while back, but the complete and utter lack of any
documentation whatsoever... kinda threw me off.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On Sun, Jul 21, 2013 at 2:30 PM, Alex Xu wrote: > userpriv and usersandbox don't work in pypy because os.setgroups isn't > implemented there. > > I had a go at it a while back, but the complete and utter lack of any > documentation whatsoever... kinda threw me off. > I don't think we need to tailor the default configuration to meet the limitations imposed by an experimental python interpreter. If it can be worked around, great, but it should not stop us from enabling userpriv and usersandbox by default.
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
Dnia 2013-07-21, o godz. 11:00:46 Zac Medico napisał(a): > On 07/21/2013 04:57 AM, Michał Górny wrote: > > a) unionfs-fuse doesn't support replacing files from read-only branch, > > Maybe you've got some kind of configuration problem (did you forget to > enable the cow option?), because unionfs-fuse seems to work fine for me. It is possible. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-dev-announce] Council constituent meeting 30 July 2013 at 19:00 UTC
On 2013.07.21 15:30, Andreas K. Huettel wrote: > > Hello everybody, > [snip] > - vote for holding meetings every 2nd Tuesday of the month at 2000 > UTC > (or > 1900 UTC depending on daylight savings) In any timezone in particular? [snip] > 1: "the open floor is the mailing list > discussion", > i.e. no open floor during the meeting anymore The open floor is a part of the openness and approachability of the council. Its 60 seconds well spent, even if nobody says anything. > - vote on meeting format 2: "shift council votes to mail instead of > IRC" Please keep voting in public. Its good for accountability. If not in IRC, find a way to publish who voted and now. Council do not get a secret ballot. [snip] > - general discussion on the introduction of a "Bikeshed of the month" > (basically the plan to tidy off one unresolved mailing list > discussion > each > month) Ok, so what colour should it be? [with apologies to Douglas Adams] [snip] > > Best, > Andreas > > -- > Andreas K. Huettel > Gentoo Linux developer (council, kde) > dilfri...@gentoo.org > http://www.akhuettel.de/ > -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpOBoQV65j2k.pgp Description: PGP signature
[gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
hasufell posted on Sun, 21 Jul 2013 17:22:24 +0200 as excerpted: > solution: Treeclean it and maintain it in an overlay (maybe > science-overlay). That's exactly what overlays are for... experimental > stuff. What's the pros/cons of overlay vs. in-tree-but-masked for something like this? In-tree-but-masked is at least available for those who want it, without having to load an overlay, but I don't see that discussed at all, here. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
On 07/22/2013 12:07 AM, Duncan wrote: > hasufell posted on Sun, 21 Jul 2013 17:22:24 +0200 as excerpted: > >> solution: Treeclean it and maintain it in an overlay (maybe >> science-overlay). That's exactly what overlays are for... experimental >> stuff. > > What's the pros/cons of overlay vs. in-tree-but-masked for something like > this? In-tree-but-masked is at least available for those who want it, > without having to load an overlay, but I don't see that discussed at all, > here. > pros: - consistency of tree quality - less user confusion (the checksum failures alone get us a lot of bugs every release without people realizing what it means...) and people expect packages to work in the tree - less bugs no one can do anything about - easier contribution of users in an overlay, testing of hacks or other stuff to make it work - making clear that gentoo does not support software with such low QA - making clear that this software is experimental cons: - users have to run "layman -a foo" ...I hope they will manage (and the masking reason will be updated to explain where to look for googleearth ebuilds)
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
On Sun, Jul 21, 2013 at 11:16 PM, hasufell wrote: > pros: > - consistency of tree quality > - less user confusion (the checksum failures alone get us a lot of bugs > every release without people realizing what it means...) and people > expect packages to work in the tree > - less bugs no one can do anything about > - easier contribution of users in an overlay, testing of hacks or other > stuff to make it work > - making clear that gentoo does not support software with such low QA > - making clear that this software is experimental > Half of those apply also to p.mask'd packages as Duncan pointed out. Maybe even more than half. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
Dnia 2013-07-22, o godz. 00:16:31 hasufell napisał(a): > On 07/22/2013 12:07 AM, Duncan wrote: > > hasufell posted on Sun, 21 Jul 2013 17:22:24 +0200 as excerpted: > > > >> solution: Treeclean it and maintain it in an overlay (maybe > >> science-overlay). That's exactly what overlays are for... experimental > >> stuff. > > > > What's the pros/cons of overlay vs. in-tree-but-masked for something like > > this? In-tree-but-masked is at least available for those who want it, > > without having to load an overlay, but I don't see that discussed at all, > > here. > > > > cons: > - users have to run "layman -a foo" ...I hope they will manage (and the > masking reason will be updated to explain where to look for googleearth > ebuilds) Then to get *a single package* they start using the whole overlay. If it's a sane overlay, fine. But some overlays really replace a lot of stuff silently and trigger failures we didn't even imagine before. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/22/2013 12:33 AM, Michał Górny wrote: > Dnia 2013-07-22, o godz. 00:16:31 hasufell > napisał(a): > >> On 07/22/2013 12:07 AM, Duncan wrote: >>> hasufell posted on Sun, 21 Jul 2013 17:22:24 +0200 as >>> excerpted: >>> solution: Treeclean it and maintain it in an overlay (maybe science-overlay). That's exactly what overlays are for... experimental stuff. >>> >>> What's the pros/cons of overlay vs. in-tree-but-masked for >>> something like this? In-tree-but-masked is at least available >>> for those who want it, without having to load an overlay, but I >>> don't see that discussed at all, here. >>> >> >> cons: - users have to run "layman -a foo" ...I hope they will >> manage (and the masking reason will be updated to explain where >> to look for googleearth ebuilds) > > Then to get *a single package* they start using the whole overlay. > If it's a sane overlay, fine. But some overlays really replace a > lot of stuff silently and trigger failures we didn't even imagine > before. > No. I'd either use a separate single-purpose overlay or add it to science-overlay. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR7GI8AAoJEFpvPKfnPDWzVrQH/3o8FrgSaCFpWEAJj1qeFpQP /01wJzMsTV3YWZ9ZqvIZ7txPls+KBlV7hrm0SSNdP5SWO/tdXPllwNu7B+3rdcKN UOP56hlGtRRT2xw1/M/EWX76+hQmMUSYncMJ5kwqWwWGiKYRgJqR6WYH99igxwSV 7OOewcdU9p56l1MY5TxyH0tG/7KkJADSmYCf6xIK7Lkz1yU9G/e2I1WQsMGVnIBR TUkV+q1gM9zDwjKtK64X4rA4l2KiTDfoksyBgSelVMYNPcNEGYZgwmrXCJhKZK7B dYONlBDp/9BG+ihhsNTAXewxsDuVPtXTdFX4dzLciXgGdFw81r+LoNFViH7pRVM= =4JPG -END PGP SIGNATURE-
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
On 07/22/2013 12:22 AM, Diego Elio Pettenò wrote: > On Sun, Jul 21, 2013 at 11:16 PM, hasufell wrote: > >> pros: >> - consistency of tree quality does not apply to p.mask'd packages >> - less user confusion (the checksum failures alone get us a lot of bugs >> every release without people realizing what it means...) and people >> expect packages to work in the tree maybe >> - less bugs no one can do anything about does not apply >> - easier contribution of users in an overlay, testing of hacks or other >> stuff to make it work does not apply >> - making clear that gentoo does not support software with such low QA does not apply >> - making clear that this software is experimental applies >> > > Half of those apply also to p.mask'd packages as Duncan pointed out. Maybe > even more than half. > >
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
On Mon, 2013-07-22 at 00:35 +0200, hasufell wrote: > On 07/22/2013 12:33 AM, Michał Górny wrote: > > Dnia 2013-07-22, o godz. 00:16:31 hasufell > > napisał(a): > > > >> On 07/22/2013 12:07 AM, Duncan wrote: > >>> hasufell posted on Sun, 21 Jul 2013 17:22:24 +0200 as > >>> excerpted: > >>> > solution: Treeclean it and maintain it in an overlay (maybe > science-overlay). That's exactly what overlays are for... > experimental stuff. > >>> > >>> What's the pros/cons of overlay vs. in-tree-but-masked for > >>> something like this? In-tree-but-masked is at least available > >>> for those who want it, without having to load an overlay, but I > >>> don't see that discussed at all, here. > >>> > >> > >> cons: - users have to run "layman -a foo" ...I hope they will > >> manage (and the masking reason will be updated to explain where > >> to look for googleearth ebuilds) > > > > Then to get *a single package* they start using the whole overlay. > > If it's a sane overlay, fine. But some overlays really replace a > > lot of stuff silently and trigger failures we didn't even imagine > > before. > > > > No. > > I'd either use a separate single-purpose overlay or add it to > science-overlay. If it's a separate overlay, then googleearth overlay in gentoo's github account for easy access for users, both to get and contribute. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/22/2013 01:03 AM, Brian Dolbec wrote: > On Mon, 2013-07-22 at 00:35 +0200, hasufell wrote: >> On 07/22/2013 12:33 AM, Michał Górny wrote: I'd either use a >> separate single-purpose overlay or add it to science-overlay. > > > If it's a separate overlay, then googleearth overlay in gentoo's > github account for easy access for users, both to get and > contribute. > This is scope of proxy-main, imho. starting overlays for single pckages is hilarious. - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlHsbKUACgkQknrdDGLu8JDlZQD/fnk1Z869tY0DUVjSedW/TDnm bVuv0IrCjn/UJoDvjIMBAJCMgLNF2QUBprZMVjw5Fj6zFiWqGckCM+Q0aHBieUJ7 =DH1b -END PGP SIGNATURE-
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
On 07/22/2013 01:20 AM, Michael Weber wrote: > On 07/22/2013 01:03 AM, Brian Dolbec wrote: >> On Mon, 2013-07-22 at 00:35 +0200, hasufell wrote: >>> On 07/22/2013 12:33 AM, Michał Górny wrote: I'd either use a >>> separate single-purpose overlay or add it to science-overlay. > > >> If it's a separate overlay, then googleearth overlay in gentoo's >> github account for easy access for users, both to get and >> contribute. > > This is scope of proxy-main, imho. starting overlays for single > pckages is hilarious. > > You are ignoring the rest of the arguments. The main concern is not how people can contribute. And I said more than once that we can probably move it to science-overlay. The only question now is if we want to keep it p.masked or remove it. I don't like pmasking package indefinitely. Afaiu pmasks are rather meant for a) new, very hot versions of libraries/tools that can break your system in more than one part b) security masks, temporary masks and other masks we expect to remove in the future
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
On 21/07/2013 23:38, hasufell wrote: >>> - consistency of tree quality > does not apply to p.mask'd packages p.mask says that the package is in _bad_ quality, explicitly, and you can say how, so "does not apply" are not really the words I'd use. >>> - less user confusion (the checksum failures alone get us a lot of bugs >>> every release without people realizing what it means...) and people >>> expect packages to work in the tree > maybe Not p.masked packages they don't. Just state it outright, maybe even fetch-restrict the package and warn them... >>> - less bugs no one can do anything about > does not apply *How* does making it into a semi-official one-purpose overlay reduce the number of bugs users report? Either you're banning it into a non-Gentoo-owned overlay, or you're just betting they would get the reason why it's not in an overlay, same applies to p.mask. >>> - easier contribution of users in an overlay, testing of hacks or other >>> stuff to make it work > does not apply I'm afraid I have to agree with Michael here. Proxies would do that, and users are still free to experiment with overlaid version, I don't see how this makes much of a difference. >>> - making clear that gentoo does not support software with such low QA > does not apply It applies perfectly. It's a p.mask for a reason, and can convey reasons. It's your package, do what you want, but stop just trying to force your views into suggestions, just because you already reached your conclusion, please. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-07-21 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2013-07-21 23h59 UTC. Removals: dev-python/pypy-bin 2013-07-19 17:12:39 floppym rox-extra/downloadmanager 2013-07-21 07:13:21 pacho sys-cluster/mpi-dotnet 2013-07-21 07:18:00 pacho media-tv/livestation2013-07-21 07:18:53 pacho dev-lang/boo2013-07-21 07:19:37 pacho gnome-extra/contacts2013-07-21 07:20:30 pacho x11-themes/pekwm-themes-hewphoria 2013-07-21 07:21:51 pacho net-im/qutecom 2013-07-21 07:22:24 pacho net-fs/djmount 2013-07-21 07:24:08 pacho sys-fs/archfs 2013-07-21 07:25:18 pacho dev-python/gtkhtml-python 2013-07-21 07:25:53 pacho app-office/osmo 2013-07-21 07:26:07 pacho dev-python/gdl-python 2013-07-21 07:29:08 pacho app-office/taxbird 2013-07-21 07:30:51 pacho dev-util/monodoc2013-07-21 07:35:24 pacho dev-dotnet/njb-sharp2013-07-21 07:36:16 pacho net-wireless/ipw39452013-07-21 07:36:52 pacho net-wireless/ipw3945-ucode 2013-07-21 07:37:16 pacho net-wireless/ipw3945d 2013-07-21 07:37:40 pacho dev-util/acgmake2013-07-21 07:40:42 pacho dev-php/ezc-Base2013-07-21 07:44:02 pacho dev-php/ezc-Graph 2013-07-21 07:44:21 pacho mail-client/postler 2013-07-21 07:45:56 pacho games-emulation/xmess 2013-07-21 07:46:33 pacho Additions: sys-kernel/raspberrypi-image2013-07-15 06:28:00 xmw sys-boot/raspberrypi-firmware 2013-07-15 06:58:46 xmw games-arcade/nottetris2 2013-07-15 15:28:56 hasufell dev-python/contextlib2 2013-07-15 19:46:14 mgorny sys-fs/bedup2013-07-15 19:54:09 mgorny sci-libs/fplll 2013-07-15 22:41:41 hasufell games-misc/little-inferno 2013-07-16 15:20:41 hasufell games-rpg/dear-esther 2013-07-16 15:23:18 hasufell games-action/awesomenauts 2013-07-16 19:31:44 hasufell games-action/intrusion2 2013-07-16 19:35:52 hasufell games-puzzle/tiny-and-big 2013-07-16 20:00:39 hasufell dev-libs/snowball-stemmer 2013-07-18 09:03:07 graaff xfce-extra/xfce4-whiskermenu-plugin 2013-07-18 12:56:08 hasufell net-libs/cppzmq 2013-07-18 14:07:17 jlec sci-chemistry/molequeue 2013-07-18 14:13:57 jlec virtual/service-manager 2013-07-18 19:18:00 williamh sys-boot/raspberrypi-mkimage2013-07-19 14:28:35 xmw sys-kernel/raspberrypi-sources 2013-07-19 14:33:47 xmw dev-python/pypy-bin 2013-07-19 15:00:21 idella4 app-leechcraft/liblaretz2013-07-20 20:18:03 maksbotan app-leechcraft/laretz 2013-07-20 20:21:29 maksbotan sci-geosciences/osgearth2013-07-21 17:45:28 hasufell -- 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-python/pypy-bin,removed,floppym,2013-07-19 17:12:39 rox-extra/downloadmanager,removed,pacho,2013-07-21 07:13:21 sys-cluster/mpi-dotnet,removed,pacho,2013-07-21 07:18:00 media-tv/livestation,removed,pacho,2013-07-21 07:18:53 dev-lang/boo,removed,pacho,2013-07-21 07:19:37 gnome-extra/contacts,removed,pacho,2013-07-21 07:20:30 x11-themes/pekwm-themes-hewphoria,removed,pacho,2013-07-21 07:21:51 net-im/qutecom,removed,pacho,2013-07-21 07:22:24 net-fs/djmount,removed,pacho,2013-07-21 07:24:08 sys-fs/archfs,removed,pacho,2013-07-21 07:25:18 dev-python/gtkhtml-python,removed,pacho,2013-07-21 07:25:53 app-office/osmo,removed,pacho,2013-07-21 07:26:07 dev-python/gdl-python,removed,pacho,2013-07-21 07:29:08 app-office/taxbird,removed,pacho,2013-07-21 07:30:51 dev-util/monodoc,removed,pacho,2013-07-21 07:35:24 dev-dotnet/njb-sharp,removed,pacho,2013-07-21 07:36:16 net-wireless/ipw3945,removed,pacho,2013-07-21 07:36:52 net-wireless/ipw3945-ucode,removed,pacho,2013-07-21 07:37:16 net-wireless/ipw3945d,removed,pacho,2013-07-21 07:37:40 dev-util/acgmake,removed,pacho,2013-07-21 07:40:42 dev-php/ezc-Base,removed,pacho,2013-07-21 07:44:02 dev-php/ezc-Graph,removed,pacho,2013-07-21 07:44:21 mail-client/postler,removed,pacho,2013-07-21 07:45:56 games-emulation/xmess,removed,pacho,2013-07-21 07:46:33 Added Packages: sys-kernel/raspberrypi-image,added,xmw,2013-07-15 06:28:00 sys-boot/raspberrypi-firmware,added,xmw,2013-07-15 06
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
On Sun, Jul 21, 2013 at 6:33 PM, Michał Górny wrote: > Dnia 2013-07-22, o godz. 00:16:31 > hasufell napisał(a): >> - users have to run "layman -a foo" ...I hope they will manage (and the >> masking reason will be updated to explain where to look for googleearth >> ebuilds) > > Then to get *a single package* they start using the whole overlay. If > it's a sane overlay, fine. But some overlays really replace a lot of > stuff silently and trigger failures we didn't even imagine before. > We're starting to drift off topic here, but I've always felt that this is something that could be improved on. I'm not saying that any of this should just be thrown together, but some of the following might be useful: 1. Overlay dependencies (depends on a particular package from a particular overlay). 2. Overlay package.* (accept one version of one package from a particular overlay, mask all packages in an overlay that aren't explicitly unmasked, don't apply package.(un)mask from one overlay to packages in another unless the mask references that overlay specifically, etc). 3. Repository priority (paludis handles this fairly well I think) - where you can control which overlays override which other ones. I've never really liked the all-or-nothing design of overlays as they currently stand. Even simply prioritizing them is a pretty crude approach. It makes them fairly useless for general-purpose distribution of packages. Rich
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
On 07/22/2013 01:49 AM, Diego Elio Pettenò wrote: > On 21/07/2013 23:38, hasufell wrote: - consistency of tree quality >> does not apply to p.mask'd packages > > p.mask says that the package is in _bad_ quality, explicitly, and you > can say how, so "does not apply" are not really the words I'd use. > I did not know that p.mask is used indefinitely for low quality packages and I don't like that concept. - less user confusion (the checksum failures alone get us a lot of bugs every release without people realizing what it means...) and people expect packages to work in the tree >> maybe > > Not p.masked packages they don't. Just state it outright, maybe even > fetch-restrict the package and warn them... > - less bugs no one can do anything about >> does not apply > > *How* does making it into a semi-official one-purpose overlay reduce the > number of bugs users report? Either you're banning it into a > non-Gentoo-owned overlay, or you're just betting they would get the > reason why it's not in an overlay, same applies to p.mask. It will reduce the number of bugs, because there will be no bugtracker, but only pull-requests. It would not be hosted on o.g.o. which means gentoo bugs are not allowed. > - easier contribution of users in an overlay, testing of hacks or other stuff to make it work >> does not apply > > I'm afraid I have to agree with Michael here. Proxies would do that, and > users are still free to experiment with overlaid version, I don't see > how this makes much of a difference. Well, I actually only mentioned that point as a side effect. Until now... no one was able to provide a patch to fix one of the bugs you can read in a hundred forums and bug trackers. But it wouldn't make much of a difference, that's probably true. > - making clear that gentoo does not support software with such low QA >> does not apply > > It applies perfectly. It's a p.mask for a reason, and can convey reasons. > It does not apply, because we still support it officially in our main tree as a distribution, no matter if it's p.masked or not. One could probably argue that no one cares about this difference, but it's still true. Anyway... if people disagree, then it doesn't make much sense to remove it. Otherwise it will pop up in the tree sooner or later again.
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
On Sun, Jul 21, 2013 at 5:34 PM, Rich Freeman wrote: > We're starting to drift off topic here, but I've always felt that this > is something that could be improved on. I'm not saying that any of > this should just be thrown together, but some of the following might > be useful: > > 1. Overlay dependencies (depends on a particular package from a > particular overlay). In EAPI 5-progress, there's support for atom::repo deps. > 2. Overlay package.* (accept one version of one package from a > particular overlay, mask all packages in an overlay that aren't > explicitly unmasked, don't apply package.(un)mask from one overlay to > packages in another unless the mask references that overlay > specifically, etc). These things are all supported by portage, through use of atom::repo in /etc/portage/package.* (or profile with EAPI 5-progress) and repo-level configurations in $repo/profiles/package.* (which only apply to packages from that repo). > 3. Repository priority (paludis handles this fairly well I think) - > where you can control which overlays override which other ones. Portage also supports priority setting in /etc/portage/repos.conf. > I've never really liked the all-or-nothing design of overlays as they > currently stand. These days, they should be much more flexible than they have been in the past. > Even simply prioritizing them is a pretty crude > approach. It makes them fairly useless for general-purpose > distribution of packages. > > Rich >
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/22/2013 02:34 AM, Rich Freeman wrote: > 2. Overlay package.* (accept one version of one package from a > particular overlay, mask all packages in an overlay that aren't > explicitly unmasked, don't apply package.(un)mask from one overlay > to packages in another unless the mask references that overlay > specifically, etc). Inside /etc/portage, */*::xmw is a valid token for p.mask, p.keyword etc. p.mask:*/*::xmw p.unmask:virtual/xmwce::xmw works. - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlHsx+sACgkQknrdDGLu8JD+uQD9E3iEX8p3zAC2Isbb8r1SJfWr xUSK7P3F3Q3iFajBhXIA/0r2F4qyhidkjqGD8aUlJ+o+vcReCmBXegsEGbDUL496 =2xcw -END PGP SIGNATURE-
