Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl
Matthew Summers: > On Sun, Jul 13, 2014 at 12:59 PM, hasufell wrote: >> Dirkjan Ochtman: >>> On Sat, Jul 12, 2014 at 2:37 PM, hasufell wrote: So libressl is meant as a drop-in replacement for openssl. >>> >>> Some caveats have already been discovered: >>> > > So, libressl is really nowhere near ready for prime time or even late > night TV (perhaps the day time talk shows, but that is a stretch given > the PRNG situation). I think preparing a virtual and updating > dependent ebuilds for the explosion of replacements is grand, however > we should make it _very_ clear to everyone that issues exist that make > libressl unsafe for anything other than play time. > Yep, it's pretty rough currently. Also, it seems a lot of upstreams (like python) rather want to wait until the libressl API gets somewhat stable before starting to throw patches around. But we can certainly start to introduce the virtual with dev-libs/openssl as the only provider.
Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl
On Sun, Jul 13, 2014 at 12:59 PM, hasufell wrote: > Dirkjan Ochtman: >> On Sat, Jul 12, 2014 at 2:37 PM, hasufell wrote: >>> So libressl is meant as a drop-in replacement for openssl. >> >> Some caveats have already been discovered: >> So, libressl is really nowhere near ready for prime time or even late night TV (perhaps the day time talk shows, but that is a stretch given the PRNG situation). I think preparing a virtual and updating dependent ebuilds for the explosion of replacements is grand, however we should make it _very_ clear to everyone that issues exist that make libressl unsafe for anything other than play time. Thanks, Matthew Summers Gentoo Foundation Inc. GPG: 111B C438 35FA EDB5 B5D3 736F 45EE 5DC0 0878 9D46
Re: [gentoo-dev] systemd + postgresql is non-obvious to me
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/07/14 07:36 AM, Pacho Ramos wrote: > El mar, 15-07-2014 a las 13:31 +0200, Alexander Berntsen escribió: > [...] >> To alleviate this I needed to run "systemd-tmpfiles --create". >> This was non-obvious to me. Sounds like a packaging issue that I >> need to do it in the first place? > > It's: https://bugs.gentoo.org/show_bug.cgi?id=462118 > > The problem is that it's not clear to us how to make it > automatically without needing to call it manually from every ebuild > installing a tmpfiles.d file :( > > Wasn't there a plan to make an eclass helper to process tmpfiles.d files that get installed, during pkg_postinst ? ...and now that I think about it, did I say that I was going to write it? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlPFJCIACgkQ2ugaI38ACPDQZQD9HpwM9B/UfJBGY9e0bH4FQkXI v558HKt9u39E2TTWUioBAJpi8xjnvOpCYIufe5YUvId46D0npaUuycn3RgQPEJlS =drKc -END PGP SIGNATURE-
Re: [gentoo-dev] systemd + postgresql is non-obvious to me
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/07/14 13:36, Pacho Ramos wrote: > It's: https://bugs.gentoo.org/show_bug.cgi?id=462118 Thank you for the info. > The problem is that it's not clear to us how to make it > automatically without needing to call it manually from every > ebuild installing a tmpfiles.d file :( Maybe consider adding ebuild output for ebuilds where this step is somewhat critical, like for PostgreSQL. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF0EAREIAAYFAlPFI8UACgkQRtClrXBQc7XRwQD8D+Who0CD2pavniG/D67d/w3j VmBmhwVjMTMDJIk9At4A+MNTozzlGDR97dsCZGs9Sq5ha4IjzBBTEJg8P5prFes= =fyIP -END PGP SIGNATURE-
[gentoo-dev] Re: find ${D} -delete in src_install() ?
Peter Stuge posted on Tue, 15 Jul 2014 12:24:31 +0200 as excerpted: > If $D was in my root I sure would not want ebuilds to randomly delete > files only based on filename. FWIW, I was looking at some other ebuild the other day and saw something similar, that threw me for a loop for a moment... but then I remembered that $D was NOT root, but rather, the pre-qmerge image's root. So you're no the only one to come across something like that and have a lapse. It's just weird to see an rm like that, and the sysadmin instincts kick in! OTOH, I had a brown-paper-bag incident with one of my own scripts doing something similar a couple years ago. The problem was a typo in the varname, so the var I set wasn't used and the var that was used ended up empty! And I made the mistake of running it as root before proper testing! Oops!!!111! Two lessons learned: 1) Test such scripts as non-root first. 2) When setting up scripted rms and the like, do something like [[ -d $var ]] && rm ... . That way, if there's a typo or the var ends up empty for whatever reason, it doesn't do the rm at all! The find -type f -name xxx -exec rm avoids the problem with a different technique, checking both name and type (normal file, not a directory!), thus strictly limiting the damage even if somehow "${D}" ended up empty and it did go off the rails. The embarrassing bit for me was that I was in the middle of bisecting a pre-release kernel bug at the time, and kernel devs were waiting on the results in ordered to get a fix in before release when it happened and I had to drop that for the moment and do a working system restore from backup! Brown paper bag time, indeed! =8^0 But I've seen it explained as a mistake every admin must make at some point, and if it hasn't happened yet, that simply means the mistake is still waiting in your future, so keep those backups ready! Of course one you've done it, those alarm bells are primed and ready, which is why they go off so easily reading things like the OP's ebuild excerpt. But that's actually a GOOD thing! =:^) Meanwhile for portage, sandbox and userpriv during at least part of the merge do help, but obviously they can't be used during the entire merge. -- 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] systemd + postgresql is non-obvious to me
El mar, 15-07-2014 a las 07:40 -0400, Rich Freeman escribió: > On Tue, Jul 15, 2014 at 7:36 AM, Pacho Ramos wrote: > > El mar, 15-07-2014 a las 13:31 +0200, Alexander Berntsen escribió: > > [...] > >> To alleviate this I needed to run "systemd-tmpfiles --create". This > >> was non-obvious to me. Sounds like a packaging issue that I need to do > >> it in the first place? > > > > It's: > > https://bugs.gentoo.org/show_bug.cgi?id=462118 > > > > The problem is that it's not clear to us how to make it automatically > > without needing to call it manually from every ebuild installing a > > tmpfiles.d file :( > > > > Isn't this a bit like automatically getting all open shells to source > /etc/profile? (Obviously that is even harder to do, so we don't > bother trying.) For that we're satisfied with a notice to the user. > > Rich It would be like: https://bugs.gentoo.org/show_bug.cgi?id=487504 that could be used by icon/mime caches and similar too ;)
Re: [gentoo-dev] The request to abolish games team policy
> 's/disband the games team/move mr_bones_ to the lead of the current > team, as what's what he has been for couple of years de facto/' > *that's what (stupid typing error)
Re: [gentoo-dev] The request to abolish games team policy
On 15/07/14 14:18, Sergey Popov wrote: > 14.07.2014 22:11, hasufell пишет: >> I will continue to work with Mr_Bones_, but if any1 says there is no >> problem with the games project, then he either doesn't know anything >> about the situation or he doesn't want to know. >> >> Again, you seem to be the only council member who cares to mediate here. >> That is pretty frustrating. >> > Just disband the games team and make the new one with you and Mr_Bones > as a members. > > There is no point in having games team that actually does nothing. > Sometimes you just need to takeover the power and do things on your own, > like we do with arm team. > > vapier was not angry when we took leadership from him(leaving him as > ordinary team member), so i think you could do this for games team as well. 's/disband the games team/move mr_bones_ to the lead of the current team, as what's what he has been for couple of years de facto/'
Re: [gentoo-dev] systemd + postgresql is non-obvious to me
El mar, 15-07-2014 a las 13:31 +0200, Alexander Berntsen escribió: [...] > To alleviate this I needed to run "systemd-tmpfiles --create". This > was non-obvious to me. Sounds like a packaging issue that I need to do > it in the first place? It's: https://bugs.gentoo.org/show_bug.cgi?id=462118 The problem is that it's not clear to us how to make it automatically without needing to call it manually from every ebuild installing a tmpfiles.d file :(
[gentoo-dev] systemd + postgresql is non-obvious to me
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 # emerge postgresql-server ... # emerge --config dev-db/postgresql-server:9.3 ... # systemctl start postgresql-server-9.3 Job for postgresql-9.3.service failed. See 'systemctl status postgresql-9.3.service' and 'journalctl -xn' for details. # systemctl status postgresql-9.3.service ● postgresql-9.3.service - PostgreSQL database server ... Process: 24145 ExecStart=/usr/lib/postgresql-9.3/bin/pg_ctl start -D ${PGDATA} -s -l ${DATA_DIR}/postmaster.log -o -p ${PGPORT} - --data-directory=${DATA_DIR} -w -t 300 (code=exited, status=1/FAILURE) ... Jul 15 13:17:23 hackintosh pg_ctl[24145]: pg_ctl: could not start server Jul 15 13:17:23 hackintosh pg_ctl[24145]: Examine the log output. Jul 15 13:17:23 hackintosh systemd[1]: postgresql-9.3.service: control process exited, code=exited status=1 Jul 15 13:17:23 hackintosh systemd[1]: Failed to start PostgreSQL database server. Jul 15 13:17:23 hackintosh systemd[1]: Unit postgresql-9.3.service entered failed state. # cat /var/lib/postgresql/9.3/data/postmaster.log FATAL: could not create lock file "/run/postgresql /.s.PGSQL.5432.lock": No such file or directory *** To alleviate this I needed to run "systemd-tmpfiles --create". This was non-obvious to me. Sounds like a packaging issue that I need to do it in the first place? - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlPFEQcACgkQRtClrXBQc7U73QD/bsI/9hp9XhNT9rBuNwiZUVu/ u4YbjfuN5KztqwM8XR4BAJZvsdAz9AxkpIJoOgeOfCKTEytTv27RmiGsSZnLND96 =9lQr -END PGP SIGNATURE-
Re: [gentoo-dev] The request to abolish games team policy
14.07.2014 22:11, hasufell пишет: > I will continue to work with Mr_Bones_, but if any1 says there is no > problem with the games project, then he either doesn't know anything > about the situation or he doesn't want to know. > > Again, you seem to be the only council member who cares to mediate here. > That is pretty frustrating. > Just disband the games team and make the new one with you and Mr_Bones as a members. There is no point in having games team that actually does nothing. Sometimes you just need to takeover the power and do things on your own, like we do with arm team. vapier was not angry when we took leadership from him(leaving him as ordinary team member), so i think you could do this for games team as well. And then, when people who actually do the stuff will be in team, they, as legitimate team members could create policy for their ebuilds - all are happy. Of course, if we have Council blessing for all this stuff, it would be more... legitimate, i'd say -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop-effects project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] find ${D} -delete in src_install() ?
Samuli Suominen wrote: > > Is it really acceptable for an ebuild to delete all files in $D > > which have a particular name? > > Of course, why wouldn't it be? $D is the image directory of the > package before it's merged to actual filesystem, Ah yes! Of course - no problem! > and even if it weren't, it specifies -name as well, so it's double-safe If $D was in my root I sure would not want ebuilds to randomly delete files only based on filename. Thanks for the explanation! //Peter
Re: [gentoo-dev] find ${D} -delete in src_install() ?
On 15/07/14 13:00, Peter Stuge wrote: > I came across this in sys-power/pm-utils-1.4.1-r2.ebuild src_install(): > > # NetworkManager 0.8.2 is handling suspend/resume on it's own with UPower > find "${D}" -type f -name 55NetworkManager -exec rm -f '{}' + > > This seems baroquely reckless, but it has been like that since 2010 > with one revbump and a bunch of stabilizations, so maybe it's fine? I don't see anything reckless about it. > Is it really acceptable for an ebuild to delete all files in $D > which have a particular name? > > > //Peter > Of course, why wouldn't it be? $D is the image directory of the package before it's merged to actual filesystem, and even if it weren't, it specifies -name as well, so it's double-safe
[gentoo-dev] find ${D} -delete in src_install() ?
I came across this in sys-power/pm-utils-1.4.1-r2.ebuild src_install(): # NetworkManager 0.8.2 is handling suspend/resume on it's own with UPower find "${D}" -type f -name 55NetworkManager -exec rm -f '{}' + This seems baroquely reckless, but it has been like that since 2010 with one revbump and a bunch of stabilizations, so maybe it's fine? Is it really acceptable for an ebuild to delete all files in $D which have a particular name? //Peter
Re: [gentoo-dev] news item: dhcpcd-6.4.2 defaults to stable private ipv6 addresses
> On Mon, 14 Jul 2014, William Hubbs wrote: > We did receive a report [...] > I recommend [...] Use either plural or singular throughout, but not both. Ulrich pgpg5DceWygRS.pgp Description: PGP signature