[gentoo-dev] Re: New global use flag: ayatana
On Sun, 12 Feb 2012 10:44:41 + Markos Chandras wrote: > Just a heads up. There are more than 5 packages using the 'ayatana' > use flag so I will add it to global use flags in 48 hours. Post the description so we can bikeshed it to death. -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] About masking net-misc/mDNSResponder for removal
"Paweł Hajdan, Jr." wrote: > On 2/13/12 11:55 AM, Pacho Ramos wrote: >> El jue, 09-02-2012 a las 12:41 +0100, Pacho Ramos escribió: >>> Hello >>> >>> Looks like our net-misc/mDNSResponder packages are orphan and >>> unmaintained for a looong time, they also have some opened bugs (with >>> hangs, build problems...) and looks like avahi with mdns compat can >>> replace it. >>> >>> OK with masking it for removal? If not, is anyone willing to maintain >>> it? >> >> OK to start dropping it from dependencies and mask it for removal? > > Since there was no response to the original e-mail... I second this. > > +1 to remove the mess. > I just noticed this: kde-base/kdelibs-4.8.0-r1 (!bindist ? net-misc/mDNSResponder) kde-base/krdc-4.8.0 (zeroconf ? net-misc/mDNSResponder) media-libs/libgphoto2-2.4.11-r1 (zeroconf ? net-misc/mDNSResponder) net-misc/ntp-4.2.6_p4 (zeroconf ? net-misc/mDNSResponder) I'm assuming this is not going to break something. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] profiles/features/64bit-native/package.use.mask contents redundancy
On Mon, Feb 13, 2012 at 11:16 AM, Sergei Trofimovich wrote: > some mips profiles are scary too: > http://dev.gentoo.org/~slyfox/profiles_mips.png Weird. I'll take a look at that.
Re: [gentoo-dev] profiles/features/64bit-native/package.use.mask contents redundancy
On 02/13/2012 08:16 AM, Sergei Trofimovich wrote: > Another alternative would be to skip double-inclusion of identical profiles at > the portage level, but it sounds very fragile and counterintuitive. > > Maybe, a bit less fragile, than current state. Either way is prone to unintended results, so it's better to fix the root problem which is poor profile structuring. If we did skip the double-inclusions automatically, then that would be a PMS change, and I doubt that any of the PMS folks would be in favor of it. -- Thanks, Zac
Re: [gentoo-dev] RFC: Application name in metadata.xml
On 13 February 2012 21:35, Markos Chandras wrote: > This field wont be useful to users but to GUI applications that want > to show a pretty name instead of a weird PN. It would be fully > optional but it would have a standard syntax. You can't use > for that to extract the real package name because > each developer use this tag in a different way. Same for description. > The proposed tag would have a single strict syntax, that is a single > string just for the real package name so it would be easily > extractable. And of course it would be fully optional. After all, it > is just an addition in metadata.dtd > I think it makes sense to also support there being multiple fields of this kind, because packages like libreoffice bundle multiple applications in the one. I'd propose a structure like You could have a proviso somewhere for multiple provides sections and each section being dependent on some atom match, but I think that's really over-engineering it. I thought about putting in stuff to allow for extra metadata for aliases and such to relate to what people are really looking for ( ie: people who are still wanting openoffice should get given libreoffice as a result ) but also smells of over-engineering and nasty messes. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
Re: [gentoo-dev] profiles/features/64bit-native/package.use.mask contents redundancy
On Sun, 12 Feb 2012 12:40:04 -0800 Zac Medico wrote: > On 02/12/2012 10:15 AM, Sergei Trofimovich wrote: > > Feature request: > > Can we add a double-inclusion detector for profiles to repoman? > > If it's not too noisy. Right now, profiles.desc contains 83 profiles > with double inclusions like this. See attached data and scripts. Looks nice! 'desktop/*' thing needs serious effort to restructure that. If teams are willing to make things saner, I would go for warning addition (maybe, guarded by --include-dev option). some mips profiles are scary too: http://dev.gentoo.org/~slyfox/profiles_mips.png Another alternative would be to skip double-inclusion of identical profiles at the portage level, but it sounds very fragile and counterintuitive. Maybe, a bit less fragile, than current state. -- Sergei signature.asc Description: PGP signature
[gentoo-dev] dev-java/ant-core slot conflicts
I'm getting an annoying slot conflict while arch testing: !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: dev-java/ant-core:0 (dev-java/ant-core-1.7.1-r4::gentoo, ebuild scheduled for merge) pulled in by ~dev-java/ant-core-1.7.1 required by (dev-java/ant-junit4-1.7.1::gentoo, ebuild scheduled for merge) (dev-java/ant-core-1.8.1::gentoo, ebuild scheduled for merge) pulled in by >=dev-java/ant-core-1.8.0 required by (dev-java/groovy-1.7.5::gentoo, ebuild scheduled for merge) ~dev-java/ant-core-1.8.1 required by (dev-java/ant-junit-1.8.1::gentoo, ebuild scheduled for merge) (and 4 more with the same problems) I'm pretty sure this isn't a problem with my system, but rather a dependency problem (using the "~" at the beginning of the dependency). What's the best way to get this fixed? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Application name in metadata.xml
Markos, there are also webapps. -- Fabio Erculiani http://lxnay.com
[gentoo-dev] Lastrites: dev-dotnet/db4o, app-text/man2html, net-misc/pavuk, app-admin/pcihpview, net-print/xpp, app-admin/gtkdiskfree, media-libs/libdlna, media-video/ushare, dev-libs/libtranslate, ap
# Pacho Ramos (13 Feb 2012) # Outdated, useless, hard to bump, without maintainer. # Removal in a month (bug #234846) dev-dotnet/db4o # Pacho Ramos (13 Feb 2012) # Unmaintained and problems with its packaging (bug #261347) # Use man2html provided by sys-apps/man instead. # Removal in a month. app-text/man2html # Pacho Ramos (13 Feb 2012) # Broken, unmaintained and unstable (bug #262504), # removal in a month. net-misc/pavuk # Pacho Ramos (13 Feb 2012) # As talked with its maintainer, it's dead and nothing # needs it (bug #298349). Removal in a month. app-admin/pcihpview # Pacho Ramos (13 Feb 2012) # Buffer overflow, upstream dead since 2004, bug #339455 # Removal in a month net-print/xpp # Pacho Ramos (13 Feb 2012) # Dead for a long time, use baobab # (from gnome-extra/gnome-utils) instead, bug #370605 # Removal in a month. app-admin/gtkdiskfree # Pacho Ramos (13 Feb 2012) # Fails to build and unmaintained, bug #385295 # Removal in a month. media-libs/libdlna media-video/ushare # Pacho Ramos (13 Feb 2012) # Broken and upstream dead since 2005, bug #387381 # Removal in a month. dev-libs/libtranslate # Pacho Ramos (13 Feb 2012) # Unmaintained, nobody willing to take it as also # looks to have a poor quality (bug #400689). # Removal in a month. app-arch/q7z signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About masking net-misc/mDNSResponder for removal
On 2/13/12 11:55 AM, Pacho Ramos wrote: > El jue, 09-02-2012 a las 12:41 +0100, Pacho Ramos escribió: >> Hello >> >> Looks like our net-misc/mDNSResponder packages are orphan and >> unmaintained for a looong time, they also have some opened bugs (with >> hangs, build problems...) and looks like avahi with mdns compat can >> replace it. >> >> OK with masking it for removal? If not, is anyone willing to maintain >> it? > > OK to start dropping it from dependencies and mask it for removal? Since there was no response to the original e-mail... I second this. +1 to remove the mess. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About masking net-misc/mDNSResponder for removal
El jue, 09-02-2012 a las 12:41 +0100, Pacho Ramos escribió: > Hello > > Looks like our net-misc/mDNSResponder packages are orphan and > unmaintained for a looong time, they also have some opened bugs (with > hangs, build problems...) and looks like avahi with mdns compat can > replace it. > > OK with masking it for removal? If not, is anyone willing to maintain > it? OK to start dropping it from dependencies and mask it for removal? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: upstream/watch in metadata.xml
On Mon, Feb 13, 2012 at 10:59 AM, Corentin Chary wrote: > On Mon, Feb 13, 2012 at 10:52 AM, Robin H. Johnson wrote: >> On Mon, Feb 13, 2012 at 10:33:11AM +0100, Corentin Chary wrote: >>> Currently, if you run euscan on this package, it doesn't work at all: >>> http://euscan.iksaif.net/package/media-plugins/vdr-softdevice/ >>> 1/ it's hosted on gentoo mirrors, and scanning them takes too long >>> because all files are in the same directory >> I've been wondering if it would help to have a pregenerated index go out >> to the mirrors from our master box, would that be useful for you? > > Would be better, but the index would still be pretty big (and > currently euscan doesn't cache anything, maybe it should). > Note that even with a HTTP cache, scanning it would take a lot of CPU if it is too big :/. -- Corentin Chary http://xf.iksaif.net
Re: [gentoo-dev] RFC: upstream/watch in metadata.xml
On Mon, Feb 13, 2012 at 10:52 AM, Robin H. Johnson wrote: > On Mon, Feb 13, 2012 at 10:33:11AM +0100, Corentin Chary wrote: >> Currently, if you run euscan on this package, it doesn't work at all: >> http://euscan.iksaif.net/package/media-plugins/vdr-softdevice/ >> 1/ it's hosted on gentoo mirrors, and scanning them takes too long >> because all files are in the same directory > I've been wondering if it would help to have a pregenerated index go out > to the mirrors from our master box, would that be useful for you? Would be better, but the index would still be pretty big (and currently euscan doesn't cache anything, maybe it should). -- Corentin Chary http://xf.iksaif.net
Re: [gentoo-dev] RFC: upstream/watch in metadata.xml
On Mon, Feb 13, 2012 at 10:50 AM, Dirkjan Ochtman wrote: > On Mon, Feb 13, 2012 at 10:33, Corentin Chary > wrote: >> One other thing, metadata.xml already contain a remote-id tag, which >> would be very great to help euscan do its job, but a lot of package >> are lacking it: >> - Should we patch repoman to scan SRC_URI and issue a warning when it >> looks like an URI that match a well known remote-id >> - Should we write a script to update metadata.xml ? It would be easy >> for rubygem, pypi and pear packages. >> >> Any comment ? Objections ? Ideas ? > > I like the idea for keeping the data somewhere for known-insane cases, > and metadata.xml sounds like it might be fine. But I don't think we > should add anything for the likes of PyPI, if we can easily derive > that we should look on PyPI some other way (i.e. for python, many > packages list a PyPI page in their HOMEPAGE). For pypi (and some others), looking at SRC_URI is enought: it starts with mirror://pypi/. Still for those *must* be set because the package name is not always exactly the same as in gentoo. Currently euscan tries to guess it, but it is not always accurate. Most of the time, if remote-id is set, we don't need "version-scan" because upstream provides a stable API to list versions. -- Corentin Chary http://xf.iksaif.net
Re: [gentoo-dev] RFC: upstream/watch in metadata.xml
On Mon, Feb 13, 2012 at 10:33:11AM +0100, Corentin Chary wrote: > Currently, if you run euscan on this package, it doesn't work at all: > http://euscan.iksaif.net/package/media-plugins/vdr-softdevice/ > 1/ it's hosted on gentoo mirrors, and scanning them takes too long > because all files are in the same directory I've been wondering if it would help to have a pregenerated index go out to the mirrors from our master box, would that be useful for you? > - Should we write a script to update metadata.xml ? It would be easy > for rubygem, pypi and pear packages. CPAN should be easy as well. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFC: upstream/watch in metadata.xml
On Mon, Feb 13, 2012 at 10:33, Corentin Chary wrote: > One other thing, metadata.xml already contain a remote-id tag, which > would be very great to help euscan do its job, but a lot of package > are lacking it: > - Should we patch repoman to scan SRC_URI and issue a warning when it > looks like an URI that match a well known remote-id > - Should we write a script to update metadata.xml ? It would be easy > for rubygem, pypi and pear packages. > > Any comment ? Objections ? Ideas ? I like the idea for keeping the data somewhere for known-insane cases, and metadata.xml sounds like it might be fine. But I don't think we should add anything for the likes of PyPI, if we can easily derive that we should look on PyPI some other way (i.e. for python, many packages list a PyPI page in their HOMEPAGE). Cheers, Dirkjan
Re: [gentoo-dev] RFC: Application name in metadata.xml
On 2/11/12 2:00 PM, Fabio Erculiani wrote: I think this is not the first time it's been discussed here, but maybe I'm wrong. Other distros associate a more user-friendly package name (application name) to packages. Say, they bind libreoffice-writer to "LibreOffice Writer" in package metadata. How about expanding metadata.xml (adding to its .dtd) to also support this? It would be nice to show this info in GUI package managers instead of the actual, and ugly (for the newbies), CP or CPV. It would be just a small addition that would make a big diff. So? Let's do that. lu
[gentoo-dev] RFC: upstream/watch in metadata.xml
As some may know, I'm working on euscan, and currently euscan only use CPV and SRC_URI to find new upstream versions. This works well if upstream url and version scheme is sane or if upstream has an API for that (rubygem, pypi, pecl, pear), but it's far from optimal. Debian use a specific file for that: debian/watch and it looks like that (for media-plugins/vdr-softdevice): opts=downloadurlmangle=s/prdownload/download/ \ http://developer.berlios.de/project/showfiles.php?group_id=2051 \ http://prdownload.berlios.de/softdevice/vdr-softdevice-(.+).tgz opts specify some options to mangle the final url, and then there is a list of url to scan. man uscan for more informations. Currently, if you run euscan on this package, it doesn't work at all: http://euscan.iksaif.net/package/media-plugins/vdr-softdevice/ 1/ it's hosted on gentoo mirrors, and scanning them takes too long because all files are in the same directory 2/ the url doesn't contain the version So, to help euscan (and other tools) for some package, I think we could introduce some hints in metadata.xml. This would extend the existing "upstream" element: http://developer.berlios.de/project/showfiles.php?group_id=2051 \ http://prdownload.berlios.de/softdevice/vdr-softdevice-(.+).tgz The format is not defined yet, but it would probably look like debian/watch, that would allow to write a script to import (valid) debian/watch files into associated metadata.xml when needed. One other thing, metadata.xml already contain a remote-id tag, which would be very great to help euscan do its job, but a lot of package are lacking it: - Should we patch repoman to scan SRC_URI and issue a warning when it looks like an URI that match a well known remote-id - Should we write a script to update metadata.xml ? It would be easy for rubygem, pypi and pear packages. Any comment ? Objections ? Ideas ? Thanks, -- Corentin Chary http://xf.iksaif.net
Re: [gentoo-dev] RFC: Application name in metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/13/2012 12:42 AM, Thomas Sachau wrote: > Alexandre Rostovtsev schrieb: >> Users know a package's "natural name", not the occasionally >> cryptic ebuild name, and certainly not the category. If I want to >> install a game called "Neverwinter Nights", it may not be >> immediately apparent to me that I should emerge something called >> "games-rpg/nwn". >> >> Adding the natural name to metadata would allow users to more >> easily find the packages they need via packages.gentoo.org and >> tools like eix. >> >> -Alexandre >> >> >> > > If people have to look into a file to find a name for a package > different from the package name, they can also directly look into > the ebuild or, even more simple, just use the search ability of > portage or other tools, which are able to search the DESCRIPTION. > > So if package name really differs from the ebuild name, put it into > the description and you can find the package with portage or tools > like. eix ;-) > > If you really, for whatever reasons, dont want to place it into > DESCRIPTION, metadata.xml already has longdescription. If you place > the full natural name of the package into that field together with > an extended description, i am pretty sure, that noone will > complain. > > So from my point of view, i currently dont see any need for a > special field in metadata.xml to specify the natural name of a > package. > This field wont be useful to users but to GUI applications that want to show a pretty name instead of a weird PN. It would be fully optional but it would have a standard syntax. You can't use for that to extract the real package name because each developer use this tag in a different way. Same for description. The proposed tag would have a single strict syntax, that is a single string just for the real package name so it would be easily extractable. And of course it would be fully optional. After all, it is just an addition in metadata.dtd - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJPOMtJAAoJEPqDWhW0r/LCykQP/35WxHYWrJx1p5EiJtqG+VGg /MfUq/5s25lOSW8RjR51HexHh/rkKXEmBA5lhzDVdO9G+tg+yveHoRBYVwy+zbz7 GXyHqb967n2TiR2AIq9zEVPR/9hmoo8mInItevW6UNiy/rIPs+Y1+KImm45R8ujK ja10r+SDB9Xr629MYsiCwJbbjEDTwmcH82ivctFqJAL6bBUYDYuOGAmphbO2VBmU J1Y1U1SAxugL1H/x/hpUFlX1e7lzbi7BWa7J5FIzSPtXjNwsj3Wgk9GK9/ENV96W ktWapjnpJkRv6zR+nRoaKE8Nn2OwBVRHdGk1Yw8WPpVAKxwySQh+xboqhMExzudj 4Ll7Rdlg7wAAT/nnWuQdDtDhr1++GKQyYRWw23rO+8Jf6LFUd3TWPoUuN1lyDp/t XFKdqGL71Rlhi9zaZRyWA34cgDYNV1bZH/jhlnv3mm9rj7hWr21XXLkMvP4BuAt7 jwkI6twuB4PP11NMCjx0teE5AgDdNlofrxBO/F3j+ZZ3u/U56h+VdKLPArk2UNyl lcgqSAkylDlKAP0UGclDYpK5/gOwm/4L2fYCVjGYt8ZIR7BOTvhnuRdbYsW5awjE YZVa14WvyJ7W6SxfFXB9XkAGt+KWj5pX6p8ZNjhW2DMEIfwDUe5xsEoL6X+C4RH4 ds5JsoHi8tGCYm0KqpKc =QGwW -END PGP SIGNATURE-
