Re: [gentoo-dev] Enable format-security in the dev profiles
On 7/21/14, 6:02 AM, Samuli Suominen wrote: Why not generate a Portage QA warning out from the warning -Wformat-security produces instead? That way compile wouldn't abort needlessly. +1, and then it can be done globally. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2014-07-20 23h59 UTC
On Mon, 21 Jul 2014 00:25:02 + Robin H. Johnson robb...@gentoo.org wrote: Removals: net-misc/curl 2014-07-15 09:29:56 blueness Is this a joke? Isn't curl as basic package as wget?
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2014-07-20 23h59 UTC
Diamond wrote: On Mon, 21 Jul 2014 00:25:02 + Robin H. Johnson robb...@gentoo.org wrote: Removals: net-misc/curl2014-07-15 09:29:56 blueness Is this a joke? Isn't curl as basic package as wget? Look under additions. It's there. Dale :-) :-)
Re: [gentoo-dev] Need help with sys-fs/e2fsprogs-1.42.11 build failure
On Sun, 20 Jul 2014 11:12:17 -0400 Mike Gilbert wrote:
On Sun, Jul 20, 2014 at 11:09 AM, Mike Gilbert flop...@gentoo.org
wrote:
On Sun, Jul 20, 2014 at 6:47 AM, Lars Wendler
polynomia...@gentoo.org wrote:
Hi guys,
I just add e2fsprogs{,-libs}-1.42.11
Is there some reason that we continue to maintain these as two
separate packages? It seems like the e2fsprogs ebuild could
build/install both the binaries and the libraries, and that would
probably prevent weird failures like this one.
I see this in README.subset:
Oops, hit send too quickly.
I see this in README.subset:
---
This distribution contains a subset of the e2fsprogs package; it
contains the base libraries (ss, et, uuid, blkid) which may be used by
other non-ext2-related applications.
This may be useful for non-Linux operating systems that need these
libraries for GNOME, but who do not need the ext2/ext3 filesystem
utilities.
---
From what I can tell, e2fsprogs and e2fsprogs-libs have mostly the
same KEYWORDS with a couple of exceptions:
x86-fbsd
x86-freebsd
x86-solaris
It hardly seems worth the effort to maintain 2 ebuilds for these small
platforms.
I think vapier could shed some light on this.
--
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC
signature.asc
Description: PGP signature
Re: [gentoo-dev] Enable format-security in the dev profiles
Any -Werror=* flag will make random autoconf checks fail for no good reason, don't use them on profiles, it's silly. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 20 July 2014 20:28, Agostino Sarubbo a...@gentoo.org wrote: Hello, I'd like to enable by default format-security at least in the dev profiles. Thought? References: https://bugs.gentoo.org/show_bug.cgi?id=259417 https://fedoraproject.org/wiki/Format-Security-FAQ -- Agostino Sarubbo Gentoo Linux Developer
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2014-07-20 23h59 UTC
On Mon, 21 Jul 2014 02:35:45 -0500 Dale rdalek1...@gmail.com wrote: Diamond wrote: On Mon, 21 Jul 2014 00:25:02 + Robin H. Johnson robb...@gentoo.org wrote: Removals: net-misc/curl 2014-07-15 09:29:56 blueness Is this a joke? Isn't curl as basic package as wget? Look under additions. It's there. It is probable that the wrong package was auto-completed by accident. Removals: net-misc/curl 2014-07-15 09:29:56 blueness net-libs/cyassl 2014-07-15 10:09:41 blueness Additions: net-misc/curl 2014-07-15 09:40:13 blueness -- 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] Automated Package Removal and Addition Tracker, for the week ending 2014-07-20 23h59 UTC
On 21/07/14 12:30, Tom Wijsman wrote: On Mon, 21 Jul 2014 02:35:45 -0500 Dale rdalek1...@gmail.com wrote: Diamond wrote: On Mon, 21 Jul 2014 00:25:02 + Robin H. Johnson robb...@gentoo.org wrote: Removals: net-misc/curl 2014-07-15 09:29:56 blueness Is this a joke? Isn't curl as basic package as wget? Look under additions. It's there. It is probable that the wrong package was auto-completed by accident. Removals: net-misc/curl 2014-07-15 09:29:56 blueness net-libs/cyassl 2014-07-15 10:09:41 blueness Additions: net-misc/curl 2014-07-15 09:40:13 blueness Plus, blueness verified with infra@g.o that mirrors didn't sync in-between, so this was never visible to any users. :-) - Samuli
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2014-07-20 23h59 UTC
On 07/21/14 05:30, Tom Wijsman wrote: On Mon, 21 Jul 2014 02:35:45 -0500 Dale rdalek1...@gmail.com wrote: Diamond wrote: On Mon, 21 Jul 2014 00:25:02 + Robin H. Johnson robb...@gentoo.org wrote: Removals: net-misc/curl 2014-07-15 09:29:56 blueness Is this a joke? Isn't curl as basic package as wget? Look under additions. It's there. It is probable that the wrong package was auto-completed by accident. Removals: net-misc/curl 2014-07-15 09:29:56 blueness net-libs/cyassl 2014-07-15 10:09:41 blueness Additions: net-misc/curl 2014-07-15 09:40:13 blueness Yes, accidentally removed curl and then re-added it. -- 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
Re: [gentoo-dev] Using LINGUAS
On Mon, 21 Jul 2014 13:23:46 +0900 Thomas Kahle to...@gentoo.org wrote: the OCR software tesseract has many different plugins for language packs used for OCR for different languages. The ebuild uses the LINGUAS variable to pass the choice of which packages to install to the user. Every ebuild uses LINGUAS implicitly. What you mean is that you expand LINGUAS to USE Flags... A reverse dependency is app-text/pdfsandwich which roughly puts OCR'ed text in a scanned pdf. Since it uses tesseract it supports exactly those languages that tesseract supports. Should its ebuild have LINGUAS use flags and then depend on tesseract with at least those flags set? ... in which case you can simply use USE dependencies since you have USE-expanded flags matching LINGUAS. It should be easy to match one ebuild's IUSE with another's. linguas_tlh? ( app-text/tesseract[linguas_tlh] ) jer
Re: [gentoo-dev] Using LINGUAS
On 21/07/14 21:03, Jeroen Roovers wrote: On Mon, 21 Jul 2014 13:23:46 +0900 Thomas Kahle to...@gentoo.org wrote: the OCR software tesseract has many different plugins for language packs used for OCR for different languages. The ebuild uses the LINGUAS variable to pass the choice of which packages to install to the user. Every ebuild uses LINGUAS implicitly. What you mean is that you expand LINGUAS to USE Flags... Yes, I did not use the correct terminology. A reverse dependency is app-text/pdfsandwich which roughly puts OCR'ed text in a scanned pdf. Since it uses tesseract it supports exactly those languages that tesseract supports. Should its ebuild have LINGUAS use flags and then depend on tesseract with at least those flags set? ... in which case you can simply use USE dependencies since you have USE-expanded flags matching LINGUAS. It should be easy to match one ebuild's IUSE with another's. linguas_tlh? ( app-text/tesseract[linguas_tlh] ) I know how to specify USE dependcies. Since you deleted it, let me ask my question again: If I follow this method I will have 37 dependencies all of this form. This is pointless because a) Everytime tesseract gains or loses a language support (it does happen!) the pdfsandwich ebuild needs to be updated, b) Nobody wants to set different linguas on tesseract and pdfsandwich anyway. Cheers, Thomas -- Thomas Kahle http://dev.gentoo.org/~tomka/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Using LINGUAS
On Mon, 21 Jul 2014 21:26:09 +0900 Thomas Kahle to...@gentoo.org wrote: Since you deleted it sorry , let me ask my question again: If I follow this method I will have 37 dependencies all of this form. This is pointless because a) Everytime tesseract gains or loses a language support (it does happen!) the pdfsandwich ebuild needs to be updated, b) Nobody wants to set different linguas on tesseract and pdfsandwich anyway. Sounds like it's useful, not pointless at all. And you can have the ebuilds automatically generate those dependencies. It's a lot less work if you keep all the linguas in a variables and loop over it to generate IUSE+= and a dependency list. jer
Re: [gentoo-dev] Using LINGUAS
Dnia 2014-07-21, o godz. 13:23:46 Thomas Kahle to...@gentoo.org napisał(a): the OCR software tesseract has many different plugins for language packs used for OCR for different languages. The ebuild uses the LINGUAS variable to pass the choice of which packages to install to the user. A reverse dependency is app-text/pdfsandwich which roughly puts OCR'ed text in a scanned pdf. Since it uses tesseract it supports exactly those languages that tesseract supports. Do I understand correctly that pdfsandwich doesn't have any explicit switches for language support? In other words, adding support for another language requires rebuilding tesseract and not pdfsandwich? Should its ebuild have LINGUAS use flags and then depend on tesseract with at least those flags set? While it seems consistent to put the LINGUAS choice in the most user facing package, in this case I would actually not put it in here. It would introduces a point of failure and maintenance work for the each tesseract upgrade (since the language set slightly changes from time to time). A typical user would set LINGUAS in her make.conf anyway. In this case the same choice applies to both packages anyway. Maybe an einfo is sufficient to inform the user it? I have no idea where did you get the 'most user facing' idea from but this is not really true or useful. The whole idea of libraries like imagemagick is about hiding unnecessary dependencies under single interface -- now imagine every package using imagemagick declaring flags for all the formats supported by it... If pdfsandwich itself doesn't do anything with LINGUAS, don't declare it. The rule about USE flags not doing anything applies here. Moreover, LINGUAS are usually set globally so scope is not really an issue here. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2014-07-20 23h59 UTC
On Mon, 21 Jul 2014 07:01:00 -0400 Anthony G. Basile bluen...@gentoo.org wrote: Yes, accidentally removed curl and then re-added it. You refreshed curl! jer
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2014-07-20 23h59 UTC
On Mon, 21 Jul 2014 11:32:10 +0400 Diamond diam...@hi-net.ru wrote: Is this a joke? Isn't curl as basic package as wget? In Gentooland, curl is actually secondary to wget, but probably tertiary to none. :) jer
Re: [gentoo-dev] Enable format-security in the dev profiles
On Monday 21 July 2014 10:08:44 Diego Elio Pettenò wrote: Any -Werror=* flag will make random autoconf checks fail for no good reason, don't use them on profiles, it's silly. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ I don't see where I asked about -Werror instead of only - Wformat. -- Agostino Sarubbo Gentoo Linux Developer
Re: [gentoo-dev] Enable format-security in the dev profiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/07/14 11:07 AM, Agostino Sarubbo wrote: On Monday 21 July 2014 10:08:44 Diego Elio Pettenò wrote: Any -Werror=* flag will make random autoconf checks fail for no good reason, don't use them on profiles, it's silly. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ I don't see where I asked about -Werror instead of only -Wformat. You didn't, explicitly; jer mentioned -Werror because -Wformat has been enabled for years already (his words), so the assumption was that you meant -Werror and Diego is responding to that. (Diego's post was against the OP, so out-of-order, is all) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlPNLZ4ACgkQ2ugaI38ACPC40wEAhd7g3fuOewsbszeQhXb7F9t3 XHdhEB79CMhZ7eIIT3MA/iAJfDPxAVVkOQE3GoOQ8sUQMvFG+jY+3lmB6vzzjMQs =Q+Re -END PGP SIGNATURE-
Re: [gentoo-dev] Enable format-security in the dev profiles
On Monday 21 July 2014 08:52:51 Paweł Hajdan, Jr. wrote: On 7/21/14, 6:02 AM, Samuli Suominen wrote: Why not generate a Portage QA warning out from the warning -Wformat-security produces instead? That way compile wouldn't abort needlessly. +1, and then it can be done globally. Paweł This is fine for me too. -- Agostino Sarubbo Gentoo Linux Developer
Re: [gentoo-dev] Enable format-security in the dev profiles
On Mon, 21 Jul 2014 17:07:24 +0200 Agostino Sarubbo a...@gentoo.org wrote: I don't see where I asked about -Werror instead of only - Wformat. It's been enabled in stable GCC for four years and in unstable and the hardened profiles for much longer so asking about setting it in any profiles makes no sense. In trying to make sense of what you were asking, I thought it might be helpful to make mention of the -Werror=format-security that /you/ use in your new bug reports that block bug #259417 now. jer
[gentoo-dev] We should lastrite splashutils in it's current form and not allow it in tree before it's fixed.
media-gfx/splashutils fails to build, and it fails everytime one of it's reverse dependency changes dependencies because it fails to use pkg-config to query Libs: it's supposed to have proxy-maint, but nobody is pushing fixes for the supposed proxy-maint it's in no shape to be in tree as-is, and since spock@g.o has retired and was also the upstream of it, well, there is no upstream for it no upstream, no downstream, fails to build, bugs with patches but nobody to push them - lastriting the package in 2 weeks, this is the first heads up mail 17 bugs found: 326759 Gentoo S Vulnerab secur...@gentoo.org IN_P --- media-gfx/splashutils-1.5.4.3-r3: internal copy of vuln. libpng (CVE-2010-1205) 2013-10-13 307525 Gentoo S Auditing secur...@gentoo.org IN_P --- media-gfx/splashutils-1.5.4.3-r2: statically links to vulnerable jpeg and freetype 2013-06-16 354157 Gentoo L Core sys asaf.g...@gmail.com CONF --- media-gfx/splashutils-1.5.4.3-r3: does not copy the initrd.splash into the initrd 2013-06-16 354639 Gentoo L Applicat asaf.g...@gmail.com CONF --- media-gfx/splashutils-1.5.4.3-r3 does not go into verbose mode with 'nox' boot option 2013-06-16 233267 Gentoo L Unspecif asaf.g...@gmail.com CONF --- media-gfx/splashutils: fsck vs bootsplash 2013-06-16 271835 Gentoo L Applicat asaf.g...@gmail.com CONF --- media-gfx/splashutils: some password prompt would be great for silent mode 2013-06-16 434368 Gentoo L Unspecif asaf.g...@gmail.com CONF --- media-gfx/splashutils-1.5.4.4-r1: linking to freetype fails due to missing static library zlib (-lz) 18:49:49 443856 Gentoo L Applicat asaf.g...@gmail.com UNCO --- media-gfx/splashutils-1.5.4.4-r2 failed to build - asm/posix_types.h: No such file or directory 2014-07-01 473512 Gentoo L Applicat asaf.g...@gmail.com IN_P --- media-gfx/splashutils-1.5.4.4-r2 /usr/bin/i686-pc-linux-gnu-ld: error in /usr/lib/klibc/lib/libc.so(.eh_frame); no .eh_frame_hdr table will be created. 2014-02-18 488524 Gentoo L Applicat asaf.g...@gmail.com UNCO --- =media-gfx/splashutils-1.5.4.4-r1 - splash_geninitramfs --append corrupts initramfs with kernel-3.10.16 2013-10-19 490530 Gentoo L Applicat asaf.g...@gmail.com CONF --- =media-gfx/splashutils-1.5.4.4-r4 needs freetype2 fixed as it has gained a libpng dependency 2014-04-01 499654 Gentoo L Applicat asaf.g...@gmail.com UNCO --- media-gfx/splashutils-1.5.4.4-r4 with media-libs/libmng-2.0.2-r1 - .../work/libmng-2.0.2/libmng_cms.c:160: undefined reference to `cmsFreeToneCurve' 2014-06-17 506124 Gentoo L Applicat asaf.g...@gmail.com CONF --- media-gfx/splashutils[truetype] fails to build with =media-libs/freetype-2.5 18:51:59 398077 Gentoo L Applicat asaf.g...@gmail.com CONF --- media-gfx/splashutils: /sbin/fbtruetype links to libraries in /usr 2013-06-16 417375 Gentoo L New Ebui asaf.g...@gmail.com CONF --- media-gfx/splashutils: initramfs corruption when compression is not gzip (new genkernel feature) 2013-12-07 398075 Gentoo L Applicat asaf.g...@gmail.com CONF --- media-gfx/splashutils: please make the static linkage optional 2013-06-16 417439 Gentoo L Core sys asaf.g...@gmail.com UNCO --- media-gfx/splashutils should move cachedir /lib/splash/cache to /run
Re: [gentoo-dev] Enable format-security in the dev profiles
On 21/07/14 18:11, Ian Stakenvicius wrote: On 21/07/14 11:07 AM, Agostino Sarubbo wrote: On Monday 21 July 2014 10:08:44 Diego Elio Pettenò wrote: Any -Werror=* flag will make random autoconf checks fail for no good reason, don't use them on profiles, it's silly. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ I don't see where I asked about -Werror instead of only -Wformat. You didn't, explicitly; jer mentioned -Werror because -Wformat has been enabled for years already (his words), so the assumption was that you meant -Werror and Diego is responding to that. (Diego's post was against the OP, so out-of-order, is all) But only -Wformat=2 has -Wformat-security. Do we enable -Wformat with 1 or 2? I'm asking, I really don't know (and can't check immediately) - Samuli
Re: [gentoo-dev] We should lastrite splashutils in it's current form and not allow it in tree before it's fixed.
Besides, people should migrate to something with active upstream, like plymouth
Re: [gentoo-dev] Enable format-security in the dev profiles
On Mon, 21 Jul 2014 18:55:25 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: But only -Wformat=2 has -Wformat-security. Do we enable -Wformat with 1 or 2? The gcc info pages say: `-Wformat' [...] In Gentoo, this option is enabled by default for [...] `-Wformat-security' [...] In Gentoo, this option is enabled by default for [...] The relevant patches are found in cvs/gentoo/src/patchsets/gcc/*/gentoo/ and are generally named 10_all_default-fortify-source.patch 11_all_default-warn-format-security.patch jer
[gentoo-dev] Default HOMEPAGE for packages with unavailable website
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi everyone, currently there is no default link, when the website of a package becomes unavailable or never existed at all. I've created a wikipage, which can be used instead of filling HOMEPAGE with www.gentoo.org or non-valid urls like none. Please check your packages and update them to this link: HOMEPAGE=https://wiki.gentoo.org/wiki/No_homepage; Feel free to add further useful information to the wikipage. Cheers, Manuel -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTzT4+XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1 OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcIQ4P/2RI964BhJFXrewAGs7lD2gR 7RKWYRS8Psm68E5oR3p+4LNFASlEyZttFxEh++DnVxGAE9Te6A7nygnFQ3T39kEb 7htpADGPqWI4UGGKdck7+6Kgnfmr8SNhBCg4yFdiICxL6UM130/pnXdReH7eT5kQ SqD1ymPQCSwxNZLEAnKeyiBuseKilVxZTzvHMdwHSEdt1+YI6XiuB21TAsMF8PJI n1sWc6bUNaaoGSwQ6nqtSc4zMeTZTFEmNredxP+zr489R4znZeN3nsxqqOchVJ7o FNUilTuLFRjtvh6V+12Dum6dIwE+fOfpsf2lExWam1wpC3I+y70JAFUpoWkYHS7H tycA02byNM775FcAenewIhjVjyd+Fkqo+k6DgWz7O02Tt9oaHWy34y0Kku3ErFAH dcti82gPALGaLuiNUAxVZ0o2SQ3a/+neVr2xg7j4MC6dirxzG0pOCRaStWd7qu05 GSvSHnEd2q2/U9DVyIWj7ArTUtRpAs0o/rvviMM9EICR4eCp2qNF0fXbDPLgvuBM jwxXlGmubAIxcIuJ5hxcyj6BmjgJstIcQPB6fcqwza2SC/6Jjb2htSew1qZWXtqS TITi6jXKZI3o6Bkeow5PI0VdCYRz2fuqlFULee3+WZrsn1DxCtQaRMFbsnC6WOAG nXgo5EyRP4Tz8u63NtyX =Ygfo -END PGP SIGNATURE-
Re: [gentoo-dev] Enable format-security in the dev profiles
El lun, 21-07-2014 a las 17:22 +0200, Jeroen Roovers escribió: On Mon, 21 Jul 2014 17:07:24 +0200 Agostino Sarubbo a...@gentoo.org wrote: I don't see where I asked about -Werror instead of only - Wformat. It's been enabled in stable GCC for four years and in unstable and the hardened profiles for much longer so asking about setting it in any profiles makes no sense. In trying to make sense of what you were asking, I thought it might be helpful to make mention of the -Werror=format-security that /you/ use in your new bug reports that block bug #259417 now. jer Is -Werror=format-security so prone to give false warnings currently? I think Fedora and Ubuntu enabled it by default recently: https://fedorahosted.org/fesco/ticket/1185 https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wformat_-Wformat-security https://bugzilla.redhat.com/show_bug.cgi?id=1043495
Re: [gentoo-dev] Default HOMEPAGE for packages with unavailable website
On Mon, 21 Jul 2014 18:22:22 +0200 Manuel Rüger mr...@gentoo.org wrote: Please check your packages and update them to this link: HOMEPAGE=https://wiki.gentoo.org/wiki/No_homepage; In the same effort we could give all the Gentoo-specific packages which now have that homepage URI a more specific (proj-/wiki-based, even bugs.g.o-based etc.) URI. Feel free to add further useful information to the wikipage. I wonder how many might still be reachable through the Internet Archive. Worth a look in all particular cases before setting HOMEPAGE to the default. jer
Re: [gentoo-dev] Default HOMEPAGE for packages with unavailable website
On Mon, 21 Jul 2014 18:22:22 +0200 Manuel Rüger mr...@gentoo.org wrote: currently there is no default link, when the website of a package becomes unavailable or never existed at all. What's wrong with HOMEPAGE=() ? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] We should lastrite splashutils in it's current form and not allow it in tree before it's fixed.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/07/14 11:52 AM, Samuli Suominen wrote: media-gfx/splashutils fails to build, and it fails everytime one of it's reverse dependency changes dependencies because it fails to use pkg-config to query Libs: it's supposed to have proxy-maint, but nobody is pushing fixes for the supposed proxy-maint it's in no shape to be in tree as-is, and since spock@g.o has retired and was also the upstream of it, well, there is no upstream for it no upstream, no downstream, fails to build, bugs with patches but nobody to push them - lastriting the package in 2 weeks, this is the first heads up mail 17 bugs found: I'm not against dropping splashutils, but is there an alternative to creating or managing framebuffer-splash in the tree? fbsplash doesn't seem to be there (tho i don't know if that's the same upstream package or not) Note that this package is a DEPEND or RDEPEND for all of the splash-themes packages too, so they'll also need to be lastrite'd if we don't have an alternative utility. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlPNWOQACgkQ2ugaI38ACPDlLAD/VLhgdj/f+Ns7AGnUfsOZKOI2 wlkDTcLy6eV0s0s64VsA/iqIIcCAcj8lmOF1/zIv8aUQU/IRRgbuq+R3SDGW4p6z =Z6Dt -END PGP SIGNATURE-
Re: [gentoo-dev] We should lastrite splashutils in it's current form and not allow it in tree before it's fixed.
On Mon, Jul 21, 2014 at 9:16 PM, Ian Stakenvicius a...@gentoo.org wrote: I'm not against dropping splashutils, but is there an alternative to creating or managing framebuffer-splash in the tree? fbsplash doesn't seem to be there (tho i don't know if that's the same upstream package or not) Fbsplash is a part of splashutils. There is also an fbcondecor kernel patch, apparently maintained by someone else now. Splashutils have an extremely complex structure of daemons, control programs, and interaction with the kernel via UVESAFB — I had to revisit this structure every time I had to change something wrt. splashutils integration. Not to claim that plymouth is the solution — last time I tried it (~ 2 years ago) it was practically unusable with OpenRC. It took control of the console in some weird and buggy way, etc. I guess you could integrate it into a specific system with specific video driver, but I gave up on plymouth as a generic solution. Maybe it works well with systemd, but from what I gathered the last time, it is (or used to be) explicitly disabled on unsupported video cards by the relevant distros. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
[gentoo-dev] don't rely on dynamic deps
afaiu dynamic deps are broken and not defined in PMS still... people seem to fix deps without revbumping, causing users who either don't use dynamic deps (it's optional for portage through --dynamic-deps=y, although it's on by default) or who use a different PM to not get the fix, at worst resulting in broken dependency calculation suggestion: * stop fixing dependencies without revbumping * add an appropriate question to the dev quiz * remove dynamic deps from portage (afair that is already considered by the portage team)
Re: [gentoo-dev] don't rely on dynamic deps
On 21/07/14 22:37, hasufell wrote: afaiu dynamic deps are broken and not defined in PMS still... people seem to fix deps without revbumping, causing users who either don't use dynamic deps (it's optional for portage through --dynamic-deps=y, although it's on by default) or who use a different PM to not get the fix, at worst resulting in broken dependency calculation suggestion: * stop fixing dependencies without revbumping * add an appropriate question to the dev quiz * remove dynamic deps from portage (afair that is already considered by the portage team) Revision bumping for dependency change that doesn't cause the package's file content to change doesn't make sense; triggers useless rebuilds for users. Portage is the official package manager, and has dynamic deps enabled by default. And it's already in ebuild-quiz.txt to ensure knowing when to, or not to, revbump: *** Ebuild technical/policy questions 1. You change a package's ebuild to install an init script. Previously, the package had no init script at all. Is a revision bump necessary? Why? What about when adding a patch? So, -1, useless rebuilds is one of the biggest problems lately, it's an relatively new problem, people are revbumping packages for the simplest things like EAPI4-5 - Samuli
Re: [gentoo-dev] don't rely on dynamic deps
On Mon, 21 Jul 2014 22:42:23 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: people are revbumping packages for the simplest things like EAPI4-5 EAPI changing to 5 should always get a revbump, since it causes confusion if anyone has a USE dependency upon your package. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
Am Montag, 21. Juli 2014, 21:37:17 schrieb hasufell: afaiu dynamic deps are broken and not defined in PMS still... people seem to fix deps without revbumping, causing users who either don't use dynamic deps (it's optional for portage through --dynamic-deps=y, although it's on by default) or who use a different PM to not get the fix, at worst resulting in broken dependency calculation suggestion: * stop fixing dependencies without revbumping * add an appropriate question to the dev quiz * remove dynamic deps from portage (afair that is already considered by the portage team) Actually the quizzes are pretty much clear on that. Revision must be bumped when the on-disk files installed by the ebuild are changed. Nothing about dependencies. This has been policy for a LONG time, and we're not going to change it overnight just because you protest. Now... whether dynamic deps are technically the right thing to do is another question. It merits discussion, but we need to be really sure about the consequences of any change. -- 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] don't rely on dynamic deps
On Mon, 21 Jul 2014 21:53:04 +0200 Andreas K. Huettel dilfri...@gentoo.org wrote: Revision must be bumped when the on-disk files installed by the ebuild are changed. Nothing about dependencies. This has been policy for a LONG time, and we're not going to change it overnight just because you protest. Policy used to be that you'd do a revbump when you wanted users to reinstall stuff, and you wouldn't otherwise. The only complication is that sometimes you want users to reinstall stuff so that there's accurate dependency information available, rather than because something has changed. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On 21/07/14 22:50, Ciaran McCreesh wrote: On Mon, 21 Jul 2014 22:42:23 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: people are revbumping packages for the simplest things like EAPI4-5 EAPI changing to 5 should always get a revbump, since it causes confusion if anyone has a USE dependency upon your package. What kind of confusion? In my experience, Portage handles it well
Re: [gentoo-dev] don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/07/14 04:06 PM, Samuli Suominen wrote: On 21/07/14 22:50, Ciaran McCreesh wrote: On Mon, 21 Jul 2014 22:42:23 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: people are revbumping packages for the simplest things like EAPI4-5 EAPI changing to 5 should always get a revbump, since it causes confusion if anyone has a USE dependency upon your package. What kind of confusion? In my experience, Portage handles it well Says the guy that's emerging things with --nodeps most of the time... :D -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlPNdFUACgkQ2ugaI38ACPAtHgD/YIrBc6LpzTRXm2lxWWSEXkUo Wp6IM5mIthE1+0DepsYA/jTG85TGSHF7R326e8eaAlr02FT2g7M47wMjOLzzsvB/ =nDEq -END PGP SIGNATURE-
Re: [gentoo-dev] don't rely on dynamic deps
On 21/07/14 23:13, Ian Stakenvicius wrote: On 21/07/14 04:06 PM, Samuli Suominen wrote: On 21/07/14 22:50, Ciaran McCreesh wrote: On Mon, 21 Jul 2014 22:42:23 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: people are revbumping packages for the simplest things like EAPI4-5 EAPI changing to 5 should always get a revbump, since it causes confusion if anyone has a USE dependency upon your package. What kind of confusion? In my experience, Portage handles it well Says the guy that's emerging things with --nodeps most of the time... :D Portage's dependency calculation takes long time, but if you add useless rebuilds of packages on top of that, that makes things even worse (Yeah, I saw the :D)
Re: [gentoo-dev] don't rely on dynamic deps
On Mon, 21 Jul 2014 23:06:22 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 21/07/14 22:50, Ciaran McCreesh wrote: On Mon, 21 Jul 2014 22:42:23 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: people are revbumping packages for the simplest things like EAPI4-5 EAPI changing to 5 should always get a revbump, since it causes confusion if anyone has a USE dependency upon your package. What kind of confusion? In my experience, Portage handles it well The way (+) and (-) work depends upon the EAPI of the things they're being matched against (not the EAPI of the package with the dependencies). When developers are adding in = dependencies to restrict to matching against EAPI 5 things (as they have to do for multilib, for example), they would need to check the CVS log to see if any ebuild has *ever* been EAPI 5. It's less work and less error-prone for developers to just always do a bump when switching to EAPI 5. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
Samuli Suominen: So, -1, useless rebuilds is one of the biggest problems lately I am not sure if that is a joke. We have: * a broken PM which does incomplete dep calculation, gives wrong suggestions to the user, has totally useless error/debug output, randomly fails to remove files, allows to break your system in numerous ways and whatnot... and I'm not going through bugzilla now to prove it * overcomplex eclasses, because people try to avoid getting stuff into the PM, resulting in more confusion for the PM * repeatedly broken stable packages * people coding against a PM instead of PMS and thus relying on undocumented behavior and breaking the meta-distribution part of gentoo * a PM codebase no one wants to be involved in and you tell me the biggest problems are useless rebuilds? Reality check, please. (btw... I didn't come up with the subslot idea, so maybe check with those guys about useless rebuilds) Removing dynamic deps is an easy way to improve the strictness of portage, adhere better to PMS and improve compatibility with other PMs. After that, we can discuss if there is a _sane_ way to avoid such rebuilds.
Re: [gentoo-dev] We should lastrite splashutils in it's current form and not allow it in tree before it's fixed.
2014-07-21 23:29 GMT+04:00 Maxim Kammerer m...@dee.su: On Mon, Jul 21, 2014 at 9:16 PM, Ian Stakenvicius a...@gentoo.org wrote: I'm not against dropping splashutils, but is there an alternative to creating or managing framebuffer-splash in the tree? fbsplash doesn't seem to be there (tho i don't know if that's the same upstream package or not) Fbsplash is a part of splashutils. There is also an fbcondecor kernel patch, apparently maintained by someone else now. Splashutils have an extremely complex structure of daemons, control programs, and interaction with the kernel via UVESAFB — I had to revisit this structure every time I had to change something wrt. splashutils integration. Not to claim that plymouth is the solution — last time I tried it (~ 2 years ago) it was practically unusable with OpenRC. It took control of the console in some weird and buggy way, etc. I guess you could integrate it into a specific system with specific video driver, but I gave up on plymouth as a generic solution. Maybe it works well with systemd, but from what I gathered the last time, it is (or used to be) explicitly disabled on unsupported video cards by the relevant distros. Well, at the moment plymouth works fine for me with OpenRC. I've installed plymouth-openrc-plugin and it's ok, despite being old and rather unmaintained. FYI, I use plymouth with dracut initramfs generator. And I also heard from maintainer (I'm proxy maintainer of plymouth) that it works with systemd too. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/07/14 04:28 PM, hasufell wrote: Reality check, please. (btw... I didn't come up with the subslot idea, so maybe check with those guys about useless rebuilds) Removing dynamic deps is an easy way to improve the strictness of portage, adhere better to PMS and improve compatibility with other PMs. After that, we can discuss if there is a _sane_ way to avoid such rebuilds. subslot rebuilds aren't supposed to be useless; however if the subslot is changed unnecessarily then yes, it can trigger those rebuilds. I wonder if there may be some form of extension we could add to portage, such that it could do a VDB-only re-emerge somehow, when the in-tree ebuild doesn't match the in-VDB one. If that could be implemented properly (and i'm not sure that it could, tbh), maybe that would help reduce issues with dynamic deps, too... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlPNewMACgkQ2ugaI38ACPB67gEAnK/FOF+6xQjXg3R3in3B/WgG loDxg1XOpMDR6NQPE0QA/jeDo3Vxt5qawbohvpnoWVwPwxbpHSfWkQ0UIwnQcDRw =EiHA -END PGP SIGNATURE-
Re: [gentoo-dev] don't rely on dynamic deps
Dnia 2014-07-21, o godz. 20:28:24 hasufell hasuf...@gentoo.org napisał(a): * a broken PM which does incomplete dep calculation, gives wrong suggestions to the user, has totally useless error/debug output, randomly fails to remove files, allows to break your system in numerous ways and whatnot... and I'm not going through bugzilla now to prove it Just to add a single point, portage also randomly silently refuses to update stuff because of subslot operator (instead of causing rebuilds). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
Dnia 2014-07-21, o godz. 21:53:04 Andreas K. Huettel dilfri...@gentoo.org napisał(a): Am Montag, 21. Juli 2014, 21:37:17 schrieb hasufell: afaiu dynamic deps are broken and not defined in PMS still... people seem to fix deps without revbumping, causing users who either don't use dynamic deps (it's optional for portage through --dynamic-deps=y, although it's on by default) or who use a different PM to not get the fix, at worst resulting in broken dependency calculation suggestion: * stop fixing dependencies without revbumping * add an appropriate question to the dev quiz * remove dynamic deps from portage (afair that is already considered by the portage team) Actually the quizzes are pretty much clear on that. Revision must be bumped when the on-disk files installed by the ebuild are changed. Nothing about dependencies. This has been policy for a LONG time, and we're not going to change it overnight just because you protest. This is not an argument. Just because we're doing things wrong for a very long time doesn't mean we have to keep doing that. Especially now that the breakage is getting much more visible with spread of EAPI=5 and subslots. Now... whether dynamic deps are technically the right thing to do is another question. It merits discussion, but we need to be really sure about the consequences of any change. Yes, it does. I'm not sure if it leads anywhere, though. Dynamic deps are a pipe dream. You can't implement them properly, so we're using half-working implementation as an excuse to be lazy. Of course, the problem is that many developers just assume how dynamic deps work. They don't know the details, they don't test it. They just say 'I need not to revbump because dynamic-deps!' Then stuff breaks because dynamic deps don't work. Or sometimes because they actually work and the developer didn't think of them. Or sometimes because they randomly start and stop working depending on the phase of the moon. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Mon, 21 Jul 2014 20:28:24 + hasufell hasuf...@gentoo.org wrote: We have: * a broken PM which does incomplete dep calculation, gives wrong suggestions to the user, has totally useless error/debug output, randomly fails to remove files, allows to break your system in numerous ways and whatnot... and I'm not going through bugzilla now to prove it * overcomplex eclasses, because people try to avoid getting stuff into the PM, resulting in more confusion for the PM * repeatedly broken stable packages * people coding against a PM instead of PMS and thus relying on undocumented behavior and breaking the meta-distribution part of gentoo * a PM codebase no one wants to be involved in So you suggest we work around a bug in the PM which would be a single fix. Everywhere. jer
Re: [gentoo-dev] don't rely on dynamic deps
El lun, 21-07-2014 a las 20:55 +0100, Ciaran McCreesh escribió: On Mon, 21 Jul 2014 21:53:04 +0200 Andreas K. Huettel dilfri...@gentoo.org wrote: Revision must be bumped when the on-disk files installed by the ebuild are changed. Nothing about dependencies. This has been policy for a LONG time, and we're not going to change it overnight just because you protest. Policy used to be that you'd do a revbump when you wanted users to reinstall stuff, and you wouldn't otherwise. The only complication is that sometimes you want users to reinstall stuff so that there's accurate dependency information available, rather than because something has changed. Maybe this could be solved by having two kinds of revisions: - One would rebuild all as usually (for example, -r1...) - The other one would only regenerate VDB and wouldn't change the installed files (for example, -r1.1) But I am not sure if it could be viable from a technical point of view :(
Re: [gentoo-dev] don't rely on dynamic deps
On Mon, 21 Jul 2014 23:01:58 +0200 Jeroen Roovers j...@gentoo.org wrote: So you suggest we work around a bug in the PM which would be a single fix. Everywhere. Dynamic dependencies is not fixable. It's an irredeemably broken concept. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Mon, 21 Jul 2014 22:06:08 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 21 Jul 2014 23:01:58 +0200 Jeroen Roovers j...@gentoo.org wrote: So you suggest we work around a bug in the PM which would be a single fix. Everywhere. Dynamic dependencies is not fixable. It's an irredeemably broken concept. It works fine for me. jer
Re: [gentoo-dev] don't rely on dynamic deps
On Mon, 21 Jul 2014 23:06:07 +0200 Pacho Ramos pa...@gentoo.org wrote: Maybe this could be solved by having two kinds of revisions: - One would rebuild all as usually (for example, -r1...) - The other one would only regenerate VDB and wouldn't change the installed files (for example, -r1.1) Or the package manager looks at changed in *DEPEND between the repo and vdb and resolves those. Oh wait, portage already does. And we've been talking about this for something like six years now? Probably longer. jer
Re: [gentoo-dev] don't rely on dynamic deps
On Mon, 21 Jul 2014 23:13:06 +0200 Jeroen Roovers j...@gentoo.org wrote: On Mon, 21 Jul 2014 22:06:08 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 21 Jul 2014 23:01:58 +0200 Jeroen Roovers j...@gentoo.org wrote: So you suggest we work around a bug in the PM which would be a single fix. Everywhere. Dynamic dependencies is not fixable. It's an irredeemably broken concept. It works fine for me. You should read the relevant bugs before making such a bold claim... You're illustrating why we have the problem to begin with: you're confusing I've not noticed it go wrong, or realised that breakages I've seen are because of this with works fine. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On 21/07/14 23:56, Michał Górny wrote: Now... whether dynamic deps are technically the right thing to do is another question. It merits discussion, but we need to be really sure about the consequences of any change. Yes, it does. I'm not sure if it leads anywhere, though. Dynamic deps are a pipe dream. You can't implement them properly, so we're using half-working implementation as an excuse to be lazy. What's lazy is maintainer doing revision bump without thinking if it's really required, spreading his laziness upon every users machine (by triggering revision bump driven rebuild)
Re: [gentoo-dev] don't rely on dynamic deps
On Mon, 21 Jul 2014 23:15:41 +0200 Jeroen Roovers j...@gentoo.org wrote: On Mon, 21 Jul 2014 23:06:07 +0200 Pacho Ramos pa...@gentoo.org wrote: Maybe this could be solved by having two kinds of revisions: - One would rebuild all as usually (for example, -r1...) - The other one would only regenerate VDB and wouldn't change the installed files (for example, -r1.1) Or the package manager looks at changed in *DEPEND between the repo and vdb and resolves those. ...assuming that the ebuild hasn't been removed, and that it can be associated correctly when overlays are involved, and that the change wasn't a change where a saved pkg_prerm uses the old dependency, not the new one, or all the other ways this breaks. You need to think your cunning plan the whole way through. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
Dnia 2014-07-22, o godz. 00:13:13 Samuli Suominen ssuomi...@gentoo.org napisał(a): On 21/07/14 23:56, Michał Górny wrote: Now... whether dynamic deps are technically the right thing to do is another question. It merits discussion, but we need to be really sure about the consequences of any change. Yes, it does. I'm not sure if it leads anywhere, though. Dynamic deps are a pipe dream. You can't implement them properly, so we're using half-working implementation as an excuse to be lazy. What's lazy is maintainer doing revision bump without thinking if it's really required, spreading his laziness upon every users machine (by triggering revision bump driven rebuild) Yes, users much more prefer random breakage over time. And debugging the issues save us a lot of time! -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
Dnia 2014-07-21, o godz. 22:21:42 Ciaran McCreesh ciaran.mccre...@googlemail.com napisał(a): On Mon, 21 Jul 2014 23:15:41 +0200 Jeroen Roovers j...@gentoo.org wrote: On Mon, 21 Jul 2014 23:06:07 +0200 Pacho Ramos pa...@gentoo.org wrote: Maybe this could be solved by having two kinds of revisions: - One would rebuild all as usually (for example, -r1...) - The other one would only regenerate VDB and wouldn't change the installed files (for example, -r1.1) Or the package manager looks at changed in *DEPEND between the repo and vdb and resolves those. ...assuming that the ebuild hasn't been removed, and that it can be associated correctly when overlays are involved, and that the change wasn't a change where a saved pkg_prerm uses the old dependency, not the new one, or all the other ways this breaks. You forgot about slot operators. The funny thing is, almost none of the Gentoo developers even know that slot operators disable dynamic dependencies completely in portage. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Tue, Jul 22, 2014 at 12:25 AM, Michał Górny mgo...@gentoo.org wrote: The funny thing is, almost none of the Gentoo developers even know that slot operators disable dynamic dependencies completely in portage. So *that's* why I now have to change RDEPENDs in both the source ebuild and in VDB in order to augment package's dependencies before depclean... -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Friends, Michał has documented the shortcomings of dynamic deps in our wiki[0]. (Thank you!) This documentation also includes two of our possible solutions. 1. Improve dynamic-deps. This is, as Michał pointed out earlier in this thread a pipe dream. 2. Remove dynamic-deps. This is what I think currently makes sense. 3. This is undocumented in the Wiki, but it is certainly an option: do nothing. It is of course the worst option; but it is perhaps the most probably course of action as well... dynamic-deps do not work, and nobody is stepping up to fix them. PMS defines a static dependency model, and this is what other package managers use as far as I know. Julian, would you like to share your experiences with Paludis? My guess is that Paludis is more predictable in this respect. I.e., instead of breaking stuff, I expect Paludis to simply give up. Sebastian, I CC'd you because I would love to hear your opinion on this. Trofi, please share your opinion too! To sum up: My vote is disable dynamic-deps. And I would be happy to apply a patch that does this with the information I have today. [0] https://wiki.gentoo.org/wiki/Project:Portage/Dynamic_dependencies - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlPNi7oACgkQRtClrXBQc7UP6gEAnnWR7L7hDqvaL64ygDwqaBV/ 4upsbo6z2FJK4BehajgA/30wolmft/L9vTR/RzH9Wlsu6+NoUBTBMeJGNuIdBCIl =++4v -END PGP SIGNATURE-
Re: [gentoo-dev] Default HOMEPAGE for packages with unavailable website
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 +1. Nice idea Manuel! On 21/07/14 19:41, Ciaran McCreesh wrote: What's wrong with HOMEPAGE=() ? It is not very informative. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlPNjtkACgkQRtClrXBQc7UrUwD7BWqcE8r+J8v0VqXR3aIwKqfa 2g+lJZE6qgkP3XoRA8QBALcJVroyLSl10/2g7iiafiAozv4W4cIluBjNOs+VO3d8 =O6Nu -END PGP SIGNATURE-
Re: [gentoo-dev] don't rely on dynamic deps
I'm picking a random msg to reply to. My concern about doing a revbump just because the deps change is that the new revision has to be committed in ~arch, so we then have to hit the arch teams, which we know are overworked anyway, with stable requests just because we changed the dependencies. Isn't that causing a lot of possibly unnecessary work for our arch teams? William signature.asc Description: Digital signature
Re: [gentoo-dev] Default HOMEPAGE for packages with unavailable website
On Mon, Jul 21, 2014 at 5:06 PM, Alexander Berntsen berna...@gentoo.org wrote: On 21/07/14 19:41, Ciaran McCreesh wrote: What's wrong with HOMEPAGE=() ? It is not very informative. The wiki page is equivalently informative. What's the point of metadata that just says there's no metadata?
Re: [gentoo-dev] Default HOMEPAGE for packages with unavailable website
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/22/2014 01:20 AM, Gordon Pettey wrote: On Mon, Jul 21, 2014 at 5:06 PM, Alexander Berntsen berna...@gentoo.org mailto:berna...@gentoo.org wrote: On 21/07/14 19:41, Ciaran McCreesh wrote: What's wrong with HOMEPAGE=() ? It is not very informative. The wiki page is equivalently informative. What's the point of metadata that just says there's no metadata? Users expect a url, not something like () . none or anything else. The url gives information, that the website is not available anymore - as it is part of the url itself: No_homepage. The wikipage gives hints where to find further information about the package. Cheers, Manuel -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTzafuXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1 OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNceDUP/3BbUqqJz8uUXV35D9IDCFSZ /Ei3SxEy6/wCojyE9e/2hmuSo6fsdujNRB9VCGIHWoz8WfhZJSQktuXgXzyP8zbD M6CBWcnx2xWpqYZBECoh6+jdltySWVu5YWZXX6gShlID9dhfLt9hRzBeL9YNGQ7J deI8pDnbWP2LY+9CUPydXyQCr2N6hfXAfOhmTyQlfsr2JoA7AVFDTL0w+q5U4v/X ss92kpi+joCHeJKRLsyVQk8HQMTKUZ6bgbXXvt/eb9ppuc+U4uVpmejiflMnq2vL vfuH+KHNNrnj450UYgtaXnIn8Ot2VxC6X8+GR/PsDL7xqn6kcQgFk7mtgx/IZImq EhyjCpNc/DEfqSmGA7fe0feOlTCTsDymocS+2TAN+ZkLV/WdJzbmMzuK6gkdntOe MNRo05do2B2serYrOCFKm6ql7CrI0+68Dsnpd8P4tONugzL6g4Wg2uK3D3zrutD5 blS3m4rtS5VVMwhuNefFockJxkTVtR+q3Gc3ES9kYaTdA7TL5EYF/bHWVBdwk9BM b+ZtJUyo2PQXVRxdURRWF4IDQwDoCS1kjeovameLo3QdLMakMQTmGGUPzpqoOKgh 3u8cFg+RelmJzgxKvUfM2H892RLXpvhuSLY1wGicdJeOYpxlEl5wtaR6KlKpv0xS EUnC838zhcRGVSILaIx8 =ZtUb -END PGP SIGNATURE-
Re: [gentoo-dev] don't rely on dynamic deps
William Hubbs: I'm picking a random msg to reply to. My concern about doing a revbump just because the deps change is that the new revision has to be committed in ~arch, so we then have to hit the arch teams, which we know are overworked anyway, with stable requests just because we changed the dependencies. Isn't that causing a lot of possibly unnecessary work for our arch teams? Procedure over logic? Just commit it straight to arch if repoman doesn't complain.
Re: [gentoo-dev] don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/21/2014 06:52 PM, William Hubbs wrote: I'm picking a random msg to reply to. My concern about doing a revbump just because the deps change is that the new revision has to be committed in ~arch, so we then have to hit the arch teams, which we know are overworked anyway, with stable requests just because we changed the dependencies. Isn't that causing a lot of possibly unnecessary work for our arch teams? If you edit an ebuild in place, and that ebuild has stable keywords, how is that any different than revbumping it and keeping it with stable keywords? The two are functionally identical, people get a changed ebuild, and the arch teams do nothing. The only difference is that 1000 different ways dynamic deps are broken. And just for fun, since no one has mentioned it yet, dynamic deps don't work at all on binpkgs since the Packages file contains the deps (like vardb) and it doesn't get updated (just like vardb). Revbump or make dynamic deps actually work (ha). - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTzbjHAAoJEKXdFCfdEflKVL4P/2Sb88YYcbHJZ1pfnVukxvvi zYD00knmGiQOcmSxZMPnhVXjV+Z1SzyOPtmZa5KXLd2xwmVvNwJdUV0ssjfDi6Gg fxnAEWWuZ6xEvpIlm7WIXq5VFGL/AO4HUso6mHqSVZbbgYLPiFCooSAn291Epmjn vGIkUf5pNtRp6gLQFTqM2ksDzJWaOF9bmuapcCSumv3uhKK2Empy+6kHTKYVd/m5 Mvo10p7W8amozV+pl7Si7tWGOf/U+Xo3N0gt9VJzz8oxIpooXZ+nSB3p9bXSbKZN sspz9khHLKFyhOAfoBbtLB9cqwPfPqgMlt6h4n9l2uJ+E0nMz0vRIlQnMarKD2FE /3DG6zrvWU0eRuYM7c5iqOrlL1WYgAA3p6CEBo5U9+h+8eF2bgxAJt/c7txJG0Ws EpSlwOIFyfVOWaJeb1WpBt72sMH+URF/YRl6K0ZKmp7+X5Ga/39ZznRfhRblRp9h nBMyIer9Ai7wNbc7A1qMvjedqOknOwSJjKEDkaUAIn5RTFa5VmLAGURSeuQnIvjE ogel9ENjdoZJW0i8bEO8ArCS9X5vgdWiwZHcjZL62KNYoqc6ySrsTUm0Eo3vDevo wr782AzzLPVftPXNHMnEthBs5ztbLr6YlXv/V5jfCc1YRQGUeEMjBkny/Nxm1VLi /l1lbtaTcm5FcqSjen4Q =asgW -END PGP SIGNATURE-
Re: [gentoo-dev] Using LINGUAS
Hi, On 21/07/14 21:42, Michał Górny wrote: Dnia 2014-07-21, o godz. 13:23:46 Thomas Kahle to...@gentoo.org napisał(a): the OCR software tesseract has many different plugins for language packs used for OCR for different languages. The ebuild uses the LINGUAS variable to pass the choice of which packages to install to the user. A reverse dependency is app-text/pdfsandwich which roughly puts OCR'ed text in a scanned pdf. Since it uses tesseract it supports exactly those languages that tesseract supports. Do I understand correctly that pdfsandwich doesn't have any explicit switches for language support? In other words, adding support for another language requires rebuilding tesseract and not pdfsandwich? Exactly, pdfsandwich combines tesseract with some postprocessing that is not language specific. Should its ebuild have LINGUAS use flags and then depend on tesseract with at least those flags set? While it seems consistent to put the LINGUAS choice in the most user facing package, in this case I would actually not put it in here. It would introduces a point of failure and maintenance work for the each tesseract upgrade (since the language set slightly changes from time to time). A typical user would set LINGUAS in her make.conf anyway. In this case the same choice applies to both packages anyway. Maybe an einfo is sufficient to inform the user it? I have no idea where did you get the 'most user facing' idea from but this is not really true or useful. The whole idea of libraries like imagemagick is about hiding unnecessary dependencies under single interface -- now imagine every package using imagemagick declaring flags for all the formats supported by it... If I don't know anything about tesseract but only install pdfsandwich and then try to scan japanese it won't work out of the box. How should the user know that she has to put japanese in ther LINGUAS variable and rebuild tesseract afterwards? Probably a simple einfo in pdfsandwich should do it. If pdfsandwich itself doesn't do anything with LINGUAS, don't declare it. The rule about USE flags not doing anything applies here. Moreover, LINGUAS are usually set globally so scope is not really an issue here. I agree. Cheers, Thomas -- Thomas Kahle http://dev.gentoo.org/~tomka/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] don't rely on dynamic deps
On Mon, 2014-07-21 at 22:56 +0200, Michał Górny wrote: Yes, it does. I'm not sure if it leads anywhere, though. Dynamic deps are a pipe dream. You can't implement them properly, so we're using half-working implementation as an excuse to be lazy. Why not adapt the updates mechanism for modifying rdepends? Perhaps something like rdepends-add foo-bar/blah-3.14 wombat? ( =dev-libs/wombat-1.0 ) This would give the package manager all the benefits of static dep resolution while allowing us to dynamically make simple changes (like adding a missing dependency to an ebuild) without forcing users to rebuild the package.
Re: [gentoo-dev] Using LINGUAS
On 21/07/14 12:23 AM, Thomas Kahle wrote: Hi, the OCR software tesseract has many different plugins for language packs used for OCR for different languages. The ebuild uses the LINGUAS variable to pass the choice of which packages to install to the user. A reverse dependency is app-text/pdfsandwich which roughly puts OCR'ed text in a scanned pdf. Since it uses tesseract it supports exactly those languages that tesseract supports. Should its ebuild have LINGUAS use flags and then depend on tesseract with at least those flags set? While it seems consistent to put the LINGUAS choice in the most user facing package, in this case I would actually not put it in here. It would introduces a point of failure and maintenance work for the each tesseract upgrade (since the language set slightly changes from time to time). A typical user would set LINGUAS in her make.conf anyway. In this case the same choice applies to both packages anyway. Maybe an einfo is sufficient to inform the user it? Cheers, Thomas there are two possible scenarios here. 1. the dependency is COMPILE TIME (ABI, API, whatever). in this scenario, the depender *must* have appropriate LINGUAS, even if that means copying and pasting from the dependee. this is necessary for correct rebuilding, and everything else associated with automagic deps. 2. the dependency is RUN TIME. in this scenario, the case is the same with all other runtime USE dependencies; that is to say, the correct solution is USE_RUNTIME or something along those lines. [0] here, I would say that einfo is superior to copying IUSE, since these flags should be set globally anyways to make sense. [0] please no bikeshedding on whether to call it RUNTIME_USE or ǝsn‾ǝɯıʇunɹ. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] don't rely on dynamic deps
On 22/07/14 04:05, Rick Zero_Chaos Farina wrote: And just for fun, since no one has mentioned it yet, dynamic deps don't work at all on binpkgs since the Packages file contains the deps (like vardb) and it doesn't get updated (just like vardb). Known long standing pitfall. It's managable. Revbump or make dynamic deps actually work (ha). If they are really as broken people claim, why is the feature enabled by default in the official package manager? As in, why I'm not seeing a bug with title sys-apps/portage: disable dynamic deps by default with a Comment #0 listing all the culprits why it should be disabled by default? Or do people think it works well enough, so that it's pros overweight the cons? I do, and many others seem to think so as well.
