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
[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] 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
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] 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
[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] 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 :(
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] 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] 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 pa...@gentoo.org 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 ;)
[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
-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-
Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl
On Sun, Jul 13, 2014 at 12:59 PM, hasufell hasuf...@gentoo.org wrote: Dirkjan Ochtman: On Sat, Jul 12, 2014 at 2:37 PM, hasufell hasuf...@gentoo.org 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] [RFC] LibreSSL, introduce virtual/openssl
Matthew Summers: On Sun, Jul 13, 2014 at 12:59 PM, hasufell hasuf...@gentoo.org wrote: Dirkjan Ochtman: On Sat, Jul 12, 2014 at 2:37 PM, hasufell hasuf...@gentoo.org 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.
