[gentoo-dev] Re: OT: Precedence: bulk
On 06.08.2008 11:11, Thilo Bangert wrote: > "Robin H. Johnson" <[EMAIL PROTECTED]> said: >> Please do NOT use out-of-office, vacation or any other auto-responders >> on the lists. It's bad list etiquette. > > decent vacation mail software ignores mail marked with a 'Precedence: > bulk' header, as mailing list mail usually is (including mails sent by > gentoo lists)... > > I wish somebody would finally write up a RFC for this. They already did: http://tools.ietf.org/html/rfc3834 Eray
Re: [gentoo-dev] An official Gentoo wiki
On 12.11.2008 11:44, Michael Hammer wrote: > * Mark Loeser <[EMAIL PROTECTED]> [081112 00:46]: >> What are others feelings on this? > > I like the idea! > >> What issues do you see with having a wiki? > > Pages of poor quality with wrong informations. > >> Do you see anyway to resolve the issue you see with us having a >> wiki? > > We should develop some kind of review process Ugh, got lots of free time? If you want to help, provide hosting or such. A hands off approach should be preferred for wiki. We know it is written by users and some poor quality and even wrong info is expected. Wikis are good for pointers and ideas only. We know that and act accordingly. Moreover, we have official gentoo docs anyway. Developer time is better spent doing, well, developer stuff rather than reviewing some wiki. If you insist on review, it will be at best a stale small site and at worst will cut into your developer time. For what it is worth, as a user I vote you spend time developing gentoo. -- Eray > and at least the > possiblity to lock and hide pages of poor quality. In the most cases > the howtos are related to some herds. What if we have a "reviewed > section" where herds can approve pages and user can be sure that the > infos provided have a minimum of quality. > > g, mueli >
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 2012-06-15 7:56 AM, Greg KH wrote: > Distributing a first-stage bootloader blob, that is signed by Microsoft, > or someone, seems to be the only way to easily handle this. Fedora agrees: http://mjg59.dreamwidth.org/12368.html Other distros haven't decided yet afaik although there have been some discussions. > Also, some people might really want to sign their own bootloader and > kernel, and kernel modules (myself included) Yes, that is the goal we should try to achieve, i.e. to give the option to our users to sign all the way to userland. > Oh, and on the first-stage bootloader front, I already know of 2 simple, > and open source, examples that will work for Linux, so getting something > like that signed might not be very tough. It's the "where does the > chain-of-trust stop" question that gets tricky... Exactly. Do you have any concrete proposals? -- Eray Aslan signature.asc Description: OpenPGP digital signature
[gentoo-dev] news item: upgrading to postfix-2.9
I'd like to commit the following news item on 2012-07-21. Any comments? -- Eray Aslan Title: Upgrading to postfix-2.9 Author: Eray Aslan Content-Type: text/plain Posted: 2012-07-17 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: =mail-mta/postfix-2.9 are installed under /usr/libexec/postfix. Please do not forget to adjust your main.cf by running etc-update/dispatch-conf or similar and accepting the new daemon_directory setting. Otherwise, postfix will not be able to find the binaries it is looking for.
Re: [gentoo-dev] news item: upgrading to postfix-2.9
On 07/17/2012 01:34 PM, Agostino Sarubbo wrote: > Imho, no need a news for it. > emerge -DuN world;revdep-rebuild;dispatch-conf is what you normally do. Well, the sysadmin runs dispatch-conf, a new daemon_directory setting comes up and he goes WTF? I am trying to avoid that WTF moment. There was a few complaints in gentoo-user ML and a bug report when it was introduced to ~arch. It seems people do not pay too much attention to ewarn messages. Having said that, I am not sure if it is really news-item material. If the general consensus is that a news item is not needed, I will follow along. -- Eray Aslan
Re: [gentoo-dev] news item: upgrading to postfix-2.9
On 07/17/2012 02:00 PM, Dirkjan Ochtman wrote: > It may be a small issue, but since the potential pain is quite large, Yes, that's the idea. > since postfix config file changes are usually > pretty hard to review for merges. Hmm, that's a failure on our part. >=postfix-2.9 ebuilds is better in this regard. Ideally, only readme_directory and html_directory settings should come up in dispatch.conf. If you are still having problems during upgrades in postfix-2.9.x versions, please let me know. -- Eray Aslan
Re: [gentoo-dev] news item: upgrading to postfix-2.9
On 07/17/2012 05:49 PM, Michael Orlitzky wrote:
> Do we really need to include them in main.cf?
Yes, as long as we want the docs under /usr/share/doc/${PF}/ - the
Gentoo norm. Alternative might be not to install the readme|html files
via the doc USE flag.
Not that I mind, but this is getting off-topic.
--
Eray Aslan
[gentoo-dev] default mta
The current default mta in gentoo - ssmtp - has a more or less dead upstream and has some outstanding bugs. It is prudent to change our default mta. Both mail-mta/nullmailer and mail-mta/msmtp are lightweight good mtas. Both packages have active development and provide AUTH and SSL/TLS support. Our current mta list is: mail-mta/ssmtp mail-mta/courier rest of the list ... As net-mail herd, we would like to have the following mta list: mail-mta/nullmailer mail-mta/msmtp mail-mta/ssmtp rest of the list ... If there are no objections, the above change will be committed in ~10 days. -- Eray Aslan pgp7zvCneOR9E.pgp Description: PGP signature
Re: [gentoo-dev] default mta
On Wed, Dec 26, 2012 at 06:42:36AM -0500, Mike Pagano wrote: > Would it be prudent to coordinate Gentoo documentation changes with the above? Ugh, I wasn't aware of any documentation that needs to be changed and a quick look/search did not turn out anything. But if there are any, sure, I will open the bugs and have it block the move. -- Eray Aslan pgpstzpk2Z0nR.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests
On Wed, Feb 13, 2013 at 09:35:56AM -0700, Denis Dupeyron wrote: > If you want people to handle security properly you have to tell them > how to. In details. If not everybody will figure it out in his or her > own way, all of them wrong. Get off your high horse and write > documentation if you know how things work. Amen. I know it's not sexy but please document / help with documentation if you can. -- Eray Aslan
Re: [gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests
On Wed, Feb 13, 2013 at 05:22:14PM +, Aaron W. Swenson wrote: > I agree. This is officially documented by GnuPG. [1] That would be the > best source to use. It details everything one needs to do to manage a > key pair. Good luck having people find and read it. Similar to (or perhaps linking to) something along the lines of http://keyring.debian.org/creating-key.html might be appropriate (by adding an expiry date section perhaps). This is not about expiry dates or even gnupg in particular. Our documentation is not up to par anymore. We need to spend more effort in documentation in general. Please do so if you can. -- Eray Aslan
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Mon, Feb 18, 2013 at 11:27:46PM +, Robin H. Johnson wrote: > Bare minimum requirements: > -- [...] > 3. Key expiry: 5 years. I am assuming we are requiring a maximum of 5 years for key expiry. We might want to make it explicit. On first reading, it sounded like key expiry >= 5 years as a bare minimum. Thanks for the write-up. -- Eray Aslan pgpa5Y0CBt3i2.pgp Description: PGP signature
Re: [gentoo-dev] kerberos, virtuals, rattling cages
On Sun, Feb 24, 2013 at 09:25:37PM -0500, Michael Mol wrote: > 2) Is it possible to slot mit-krb5 and heimdal instead of pulling them > through a virtual? My suspicion is "no", but I don't know enough about > kerberos to say whether or not it would work, even as a hack. You can't eselect the kerberos implementation under an application. These two packages do provide different symbols. And you can't just make both packages installable concurrently and hope everything works out. There are too many assumptions built into too many applications about what library from which package provides what symbol. That way lies madness. The bugs you mantion are old ones. I suggest you (and net-fs and samba herds) to check if they still apply and if they do see what prevents the said package from using the alternative implementation and solve it there - where it really belongs anyway. -- Eray Aslan pgpAQ4UcXnyKi.pgp Description: PGP signature
Re: [gentoo-dev] kerberos, virtuals, rattling cages
On Sun, Feb 24, 2013 at 11:43:06PM -0800, Alec Warner wrote: > This is incorrect, or at least, was incorrect last time I looked > (circa...uhh..2009?) > > They work 'ok' together. Heimdal clients could talk to MIT servers at > least. and vice-versa. > Of course, there were quirks, and incompatible command line > syntax, hence my fierce recommendation to 'not do that.' Yes. > > I don't think samba will support MIT, since it's kinda windows focused. Ugh, no. MIT is not windows focused (although it does ship a windows client for better integration with *nix kdcs). Apple uses heimdal in recent macos'es and employs some main developers of heimdal and samba (hence samba - heimdal tight integration). There was some work from red hat to make samba4 work with mit-krb5 but it stalled and did not go anywhere (yet?) afaik. -- Eray Aslan pgpXAuWmotvL_.pgp Description: PGP signature
Re: [gentoo-dev] =net-fs/samba-4* vs. dev-libs/openssl[kerberos]
On 06/12/13 19:14, "Paweł Hajdan, Jr." wrote: > Now for a better solution: make samba also work with MIT Kerberos, and > make OpenSSL work with Heimdal. That's a big effort. If we decide not to serve the bundled heimdal libraries, we can declare samba4 server components and openssl[kerberos] unsupported. -- Eray Aslan
[gentoo-dev] Last rites: net-mail/fetchyahoo
# Eray Aslan (26 Apr 2014) # Non-functional and no longer needed - bug #450116 # Removal in 30 days net-mail/fetchyahoo pgpairzkrJI3T.pgp Description: PGP signature
Re: [gentoo-dev] The request to abolish games team policy
On Mon, Jul 07, 2014 at 11:45:02PM +0200, Michał Górny wrote: > I would like to ask the Council to abolish the following policies that > have been established by the games team: Why? What's the use case? Or in other words, what has ticked you off to request the abolishment of status-quo? > The most notable issues with the specific use of games group include: While undoubtedly serious, I do not feel that these issues call for such a radical change. What's the background for this change request? Is this a multilib issue? Need more info. Thanks. -- Eray
Re: [gentoo-dev] Packages up for grabs
On Wed, Jan 07, 2015 at 03:06:08PM +0100, Pacho Ramos wrote: > Done, this packages are now up for grabs: > net-libs/libecap Got it. Need it as a dependency for net-proxy/squid. Help is always welcome. -- Eray
Re: [gentoo-dev] Anti-spam changes: proposal to drop spammy mail
On Mon, May 11, 2015 at 04:26:01AM +, Robin H. Johnson wrote: > TL;DR: As of May 17, @gentoo.org will drop incoming spammy mail instead of > delivering it. Speak now or hold your peace. Believe me I understand your pain. Been there done that. However, dropping mail is never a good idea. You are mucking with the dependebility of the email. I would never be able to trust my gentoo mail if you start dropping spammy mails. There will always be false positives. I suggest: - Stop forwarding mail. Have devs pop their mails to whatever account they like. I believe gmail -biggest complainer?- provides this option. - If the above option is not OK for whatever reason, at least let us opt-out of the proposed policy of dropping mails provided we do not forward our emails. -- Eray
Re: [gentoo-dev] Anti-spam changes: proposal to drop spammy mail
On Mon, May 11, 2015 at 04:47:31PM -0400, Michael Orlitzky wrote: > On 05/11/2015 04:08 PM, Robin H. Johnson wrote: > > By drop, I will clarify that they should ideally be rejected at SMTP > > time, not silently dropped. > > I believe those logs show a rejection after the message has been > accepted initially (if I'm wrong, you can ignore the rest of this). The analysis is correct. Pre-queue filtering will help as we can safely -meaning without causing backscatter- lower the threshold we reject spam at. There will still be some spam making its way to gmail but perhaps it will be low enough to stay under gmail's radar. The correct solution is to stop forwarding spam and the easiest way is just stopping forwarding. There are valid policy reasons for not going that route but continuing forwarding because it is too difficult to configure gmail is, well, not something I'd be comfortable with. I do expect more from gentoo devs. In this case (in most cases?), infra should not be looking for consensus but rather do what is right. Anyway, I believe infra has all the info it needs at this point and I am fine with whatever decision they make. -- Eray
Re: [gentoo-dev] samba (and related) packages are in desperate need of help
On Tue, Sep 01, 2015 at 03:24:05PM +0200, Lars Wendler wrote: > * We should really get heimdal and mit-krb5 packages in a shape where > we can install them in parallel [2]. Using the bundled heimdal from > samba is no valid option [3] While bundling a copy of a kerberos implementation is certainly not ideal, I think this is the only sensible option at the moment. Re-evaluate when samba's changes end up in a heimdal release we can package. Some of the changes landed upstream in July, so there has been some progress recently. -- Eray
Re: [gentoo-dev] About XFCE, renames, eclass, etc
On 03.09.2009 05:38, Jeremy Olexa wrote: > - xfce4-meta : former name xfce-base/xfce4. Renamed to reflect reality. > This meta package is the *core* of XFCE, it *only* has in it what is > required to run. Thus, returning XFCE to a minimalistic status in Gentoo > Linux. This is desired because most XFCE users are looking for a > lightweight WM, not a heavy DE. So, users will have to add a terminal, > orage, thunar, etc to the world file instead of relying on a meta package. Thanks a lot for the update and for the awesome work. One note for the future: An ewarn would have been nice for the above point. emerge --depclean output was a surprise (wanted to unmerge terminal etc) and surprise is bad. We don't want any surprises. Thanks again. -- Eray
Re: [gentoo-dev] openrc-0.5.1 arrived in the tree
On 14.10.2009 03:17, Mike Frysinger wrote:
> On Tuesday 13 October 2009 19:30:52 Joshua Saddler wrote:
>> All that to say, Tommy (et al), is that the idea of expecting users to
>> magically know everything and not to offer any documentation *in advance*
>> . . . is a silly idea. Good lord, can you imagine the shitstorm the X11
>> team would have gone through if they'd tried *that* without first writing
>> up xserver 1.5 and 1.6 migration guides?!
>
> we arent talking migrations that are forced onto everyone. we're talking
> about new code that users have to *opt in* for ("new net") that is only
> available in unstable. expecting everything in testing to be documented up
> front is unreasonable.
While true in general, I cannot agree with you in this case. This is
not some random app we are talking about. It is a change in init
scripts that might render our servers inaccessible if things go wrong.
Please bear in mind that we have servers operating in datacenters in
other countries and network loss is the worst kind of bug you can
inflict upon us.
There is no documantation upstream. At least we have some docs in g.o
(kudos to whomever wrote it) but it is old (there is no mention of
oldnet USE flag for example). And IUSE="... +oldnet ..." is too fragile
a solution.
All I am saying is that this is a so important change that we should
have gotten it right from the beginning. Openrc should not have been
unmasked without proper documentation.
--
Eray
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
Just replying randomly. On 05.04.2010 04:33, Tobias Heinlein wrote: > I think this is a good starting point to get rid of the "some important > questions are too hard to answer" dilemma that can be implemented > relatively fast. On top of that I like Sebastian's idea to order the > quizzes by difficulty -- this means just ordering by the categories I > just mentioned would be sufficient: 1 first, then 2, then 3. I am not against this idea but frankly, I do not understand what is so demotivating about the ebuild quiz. If you get demotivated because of a single exam, perhaps the problem is with the motivation and not with the exam itself. I took the published quiz just for the fun of it and to see where I missed. It is not that long. What is demotivating is a) lack of response from your mentor/proxy-maintainer etc. It is demotivating when you have to wait for days for each question you ask. b) infighting and name calling one sees on irc, gentoo-dev etc. "Do I really want to be a part of this?" pops into mind. Suggestions: 1. Bring your responsibilities in line with your capabilities. If you are always falling behind, either increase the time you spend on Gentoo or decrease your responsibilities. It is no fun playing catch-up. 2. Streamline the recruitment process so that existing devs do not spend too much time and effort during mentoring. Objective is to make recruitment not a burden on the dev, i.e streamline for the dev not for the candidate. 3. Take it down a notch in gentoo-dev, irc. No ad hominem attacks and no flame wars please. You are supposed to enjoy this. Easier said than done I suppose. -- Eray
Re: Notify people about empty herds (Was: Re: [gentoo-dev] FTR: media-opti...@g.o has no developers)
On Thu, Jun 03, 2010 at 04:28:57PM +0200, "Paweł Hajdan, Jr." wrote: > 1) kerberos herd is empty :( FWIW, I proxy maintain app-crypt/heimdal, app-crypt/mit-krb5, app-crypt/mit-krb5-appl and sys-auth/pam_krb5. Thanks to darkside and flameeyes for their help. -- Eray
[gentoo-dev] /bin and /sbin to /usr
[Following a similar discussion in another mailing list]
As you know, only a few directories can be assumed to be available after
boot[1]. Notably, /usr and /var are not among them. Binaries in /bin
and /sbin should be enough to do basic maintanence/repair and to mount
other volumes. Since we are using the binaries in /bin and /sbin to
potentially mount /usr, they should not depend on them. Or can they?
On my laptop:
# for f in /bin/* /sbin/*; do if [ "$(file $f | grep ELF)" != "" ] ;
then if [ "$(ldd $f | grep /usr)" != "" ] ; then echo $(equery belongs
$f) $f; ldd $f; fi; fi; done
net-firewall/iptables-1.4.6 /sbin/iptables-multi
linux-vdso.so.1 => (0x7fffc77e8000)
libip4tc.so.0 => /usr/lib/libip4tc.so.0 (0x7f27e4781000)
libxtables.so.4 => /usr/lib/libxtables.so.4 (0x7f27e4579000)
libm.so.6 => /lib/libm.so.6 (0x7f27e42f8000)
libc.so.6 => /lib/libc.so.6 (0x7f27e3f9f000)
libdl.so.2 => /lib/libdl.so.2 (0x7f27e3d9b000)
/lib64/ld-linux-x86-64.so.2 (0x7f27e4988000)
sys-apps/hal-0.5.14-r2 /sbin/umount.hal
linux-vdso.so.1 => (0x7fff6b5f3000)
libhal.so.1 => /usr/lib/libhal.so.1 (0x7fd52e637000)
libhal-storage.so.1 => /usr/lib/libhal-storage.so.1 (0x7fd52e42c000)
libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x7fd52e1ec000)
libc.so.6 => /lib/libc.so.6 (0x7fd52de93000)
libpthread.so.0 => /lib/libpthread.so.0 (0x7fd52dc77000)
librt.so.1 => /lib/librt.so.1 (0x7fd52da6e000)
/lib64/ld-linux-x86-64.so.2 (0x7fd52e848000)
Questions:
1. Is this OK or should we file bugs against binaries in {/bin,/sbin} linking
against libraries in /usr/lib? Fix is relatively easy in general (give
--libdir=/lib against the config script)
2. Is the below acceptable? (symlinking from /bin to /usr/bin)
# ls -l $(find {/bin,/sbin}/ -type l)|grep /usr
lrwxrwxrwx 1 root root 20 Oct 28 2008 /bin/igawk ->
/usr/bin/igawk-3.1.6
lrwxrwxrwx 1 root root 14 Aug 10 13:29 /bin/mail -> /usr/bin/mailx
lrwxrwxrwx 1 root root 20 Oct 28 2008 /bin/pgawk ->
/usr/bin/pgawk-3.1.6
Corollary to both: If yes, tinderbox/buildbot against other packages
are probably in order as well.
Thanks
--
Eray
[1]
/dev
/etc
/lib
/bin
/sbin
/proc (Linux)
/sys (Linux-2.6)
/libexec (*BSD)
Re: [gentoo-dev] /bin and /sbin to /usr
On 11.08.2010 00:00, Mike Frysinger wrote: > file a bug. Done. Thanks for looking into it. -- Eray
[gentoo-dev] keepdir /var/run/package/?
It is perfectly legal to clear /var/run across reboots. Below is a bug
from a user that ran into some trouble because an init script assumes that
/var/run/package/ exists for its PID file:
http://bugs.gentoo.org/show_bug.cgi?id=332397
A quick grep through the tree shows 73 packages that keepdirs
/var/run/package/. Perhaps not all of them are bugs but they are
certainly redundant.
A mass bug-filing is probably not the correct thing to do but perhaps we
should document somewhere (devmanual?) that keepdir'ing a temp location
should be avoided. Suggestion:
--- a/ebuild-writing/common-mistakes/text.xml
+++ b/ebuild-writing/common-mistakes/text.xml
@@ -41,6 +41,18 @@ elog "They are listed in the INSTALL file in
/usr/share/doc/${PF}"
+
+Invalid use of keepdirin src_install
+
+The keepdir function should only be used to prevent directory removal
+during uninstallation. In particular, using keepdir for a temporary
+location - such as /var/run/package/ for a PID file - should be avoided. In
+such a case, init script either should make sure that /var/run/package/ exists
+or the package should use /var/run directly. Please note that /var/run can and
+will be cleaned across reboots.
+
+
+
--
Eray
Re: [gentoo-dev] keepdir /var/run/package/?
On Thu, Aug 12, 2010 at 02:36:40PM -0400, Michael Sterrett wrote: > What you're saying doesn't agree with > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARRUNRUNTIMEVARIABLEDATA I do not understand. In the above link, it says: "/var/run: [...]Files under this directory must be cleared (removed or truncated as appropriate) at the beginning of the boot process." So we cannot assume that a directory exists under /var/run during boot. Hence, keepdiring a dir that will most probably be cleared during boot is pointless. Am I missing something? -- Eray
Re: [gentoo-dev] keepdir /var/run/package/?
On 08/12/2010 09:48 PM, Samuli Suominen wrote: It says "Files under this directory", not "Files and directories under this directory." Fair enough. So our policy basically is "tmpfs is not supported for /var/run" (and also for /var/lock I suppose). It will be somewhat more work but instead of the above, we can say "tmpfs might be used for /var/run and /var/lock and the init scripts should handle this correctly". It feels (for want of a better word) better. -- Eray
[gentoo-dev] sys-libs/db and dll hell
Hi, app-crypt/heimdal looks for db header files in db4/db.h db3/db.h db.h db_185.h - in that order - and links with ldb. In Gentoo, we do not have a db4 directory but rather db3 db4.7 db4.8 db5.0 etc. Consequently, when both sys-libs/db-3 and sys-libs/db-4 are present, heimdal links against libdb, which is a symlink against libdb-4.x, but uses headers from db-3. Result is a segfault in heimdal - serves it right for mixing it up :) . * I am guessing this is not the first time. Any pointers on how to solve this gracefully? inheriting db-use in ebuild and sedding works but - is ugly - there is a bunch of #ifdef db4/db.h's in the source so sedding the configure script is not enough - this is a security related package so I try to refrain from patching * I can submit upstream a proper patch that will make the code look at db.h first and db4/db.h db3/db.h later. Is there a (unwritten?) rule that says look at db.h first? Any links? * All linuxes I checked work correctly if the code looks at db.h first. What's the case in *BSD, Solaris, etc? Is Linux a special case in this regard? Thanks -- Eray
Re: [gentoo-dev] sys-libs/db and dll hell
On 01.09.2010 00:05, Robin H. Johnson wrote: > Unfortunately there isn't really any graceful fix. The buildsystem needs > to be patched, ideally to allow explicit passing of the DB include > directory Patch for the above accepted by upstream [1]. So, all is good. Nice to have a responsive upstream. Thanks for the pointers. -- Eray [1] http://github.com/heimdal/heimdal/commit/a1c14b231996ebd72de69df1de472f08e82c2288
Re: [gentoo-dev] openrc stabilization update
On 20.09.2010 16:37, Richard Freeman wrote: > One argument I've heard against newnet is that you can't bring > individual interfaces up and down. openrc[newnet] used to have problems with ppp interfaces. I do not know if it is still the case but there are some open bugs on bugzilla.g.o regarding ppp and openrc. This is a serious show stopper for newnet. So, either 1. both oldnet and newnet or 2. oldnet only would be the prudent alternatives (again, assuming problems with newnet and ppp exist). -- Eray
Re: [gentoo-dev] Re: .la files removal news item (GLEP 42)
On Fri, Oct 01, 2010 at 05:04:15PM +0200, Diego Elio Pettenò wrote: > Il giorno ven, 01/10/2010 alle 17.31 +0400, Peter Volkov ha scritto: > > It's better to avoid suggesting this as such things tend to stay for a > > very long time on user's systems and since this'll became redundant > > once > > portage 2.1.9 will go stable soon it'll la files will be "fixed" twice > > for no reason. > > It won't hurt anyway, and it'll definitely avoid people having to re-run > lafilefixer manually from time to time. Stabilize 2.1.9 and get rid of the post_src_install() stuff alltogether in the news item? A distro should not ask its users to fiddle with package management software lightly. Besides, if it is such a good idea -and it is- it should be part of portage. Why not push for stabilization of 2.1.9 and then do the news item? Am I missing something? -- Eray
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdemu: metadata.xml ChangeLog cdemu-1.3.0.ebuild
On 21.10.2010 07:57, Peter Volkov wrote: > Why unwanted? I remember there was never consensus... Well, in that case there is a discrepency with the devmanual: http://devmanual.gentoo.org/general-concepts/use-flags/index.html#noblah-use-flags -- Всего доброго Эрай
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdemu: metadata.xml ChangeLog cdemu-1.3.0.ebuild
On 21.10.2010 10:30, Peter Volkov wrote: > Nothing there applies here, since this USE flag has nothing to do with > archs/profiles... which will force some users to use double negative (-nocdemud, i.e. no no cdemud) which is rather convulated and should be avoided imho. While at it, we should try to make the wording on the devmanual clearer, that it only applies to arches/profiles or just don't use noblah USE flags. This is just a friendly suggestion and the decision is yours to make. Over and out. -- Eray
[gentoo-dev] [PATCH] openrc: make exit codes comply with Linux Standard Base
Linux Standard Base[1] states that for init scripts:
* status command for a stopped service should have a return code of 3
* starting an already started service or stopping an already stopped
service should be considered as successful
The trivial patch below makes openrc comply with LSB. I am not aware of
any service depending on the changed behaviour.
Use case: One can use Gentoo init scripts with cluster management
software - such as sys-cluster/pacemaker - instead of writing a resource
agent or trying to work around their limitations for each managed
service.
[1]
http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
Signed-off-by: Eray Aslan
---
sh/runscript.sh.in |2 +-
src/rc/runscript.c | 12
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/sh/runscript.sh.in b/sh/runscript.sh.in
index 3d7252a..ea40573 100644
--- a/sh/runscript.sh.in
+++ b/sh/runscript.sh.in
@@ -89,7 +89,7 @@ _status()
return 0
else
einfo "status: stopped"
- return 1
+ return 3
fi
}
diff --git a/src/rc/runscript.c b/src/rc/runscript.c
index f3f0517..a264535 100644
--- a/src/rc/runscript.c
+++ b/src/rc/runscript.c
@@ -596,8 +596,10 @@ svc_start_check(void)
fcntl(exclusive_fd, F_SETFD,
fcntl(exclusive_fd, F_GETFD, 0) | FD_CLOEXEC);
- if (state & RC_SERVICE_STARTED)
- ewarnx("WARNING: %s has already been started", applet);
+ if (state & RC_SERVICE_STARTED) {
+ einfo("%s has already been started", applet);
+ exit(EXIT_SUCCESS);
+ }
else if (state & RC_SERVICE_INACTIVE && !in_background)
ewarnx("WARNING: %s has already started, but is inactive",
applet);
@@ -845,8 +847,10 @@ svc_stop_check(RC_SERVICE *state)
fcntl(exclusive_fd, F_SETFD,
fcntl(exclusive_fd, F_GETFD, 0) | FD_CLOEXEC);
- if (*state & RC_SERVICE_STOPPED)
- ewarnx("WARNING: %s is already stopped", applet);
+ if (*state & RC_SERVICE_STOPPED) {
+ einfo("%s is already stopped", applet);
+ exit(EXIT_SUCCESS);
+ }
rc_service_mark(service, RC_SERVICE_STOPPING);
hook_out = RC_HOOK_SERVICE_STOP_OUT;
--
1.7.3.4
pgpUIPqeqKJny.pgp
Description: PGP signature
Re: [gentoo-dev] [PATCH] openrc: make exit codes comply with Linux Standard Base
On Sat, Jan 08, 2011 at 05:09:21PM -0500, Mike Frysinger wrote: > this belongs in bugzilla, not the gentoo-dev mailing list Well, this is the upstream ML but anyway, no big deal: https://bugs.gentoo.org/show_bug.cgi?id=351160 -- Eray Aslan Developer, Gentoo Linux eras gentoo.org pgp0j1t4ekdHW.pgp Description: PGP signature
[gentoo-dev] masking mailwrapper
Only virtual/mta remains as an old style virtual in the net-mail herd. I will be changing it to a new style virtual in a few days. While at it, I would like to get rid of mailwrapper USE flag and finally mask net-mail/mailwrapper for removal - bug #158003. If there are any objections, hold requests, don't-touch-my-package notices etc regarding net-mail/mailwrapper, please let me know. -- Eray Aslan signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rejecting unsigned commits
On 2011-03-25 1:59 PM, Dane Smith wrote: > Having said that, for those that just use "keys" for e-mails (most of > us), it would make more sense to use full blow SSL certs in the long run. Please no. PKI is a naive design and for all intents and purposes will remain a pipe-dream. All security relationships that is worth anything is bilateral and no trusted third party is willing to accept enough risk to warrent full trust. Using public keys for auth is a good security model and the rest of x509 certs is just unnecessary overhead. Let's not go there. GPG is good enough. -- Eray Aslan Developer, Gentoo Linux eras gentoo.org signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: rejecting unsigned commits
On 2011-03-28 2:54 PM, Rich Freeman wrote: >> 3. If I'm going to start using GPG, I might as well use it for a few things. >> Anyone got pointers for cross-platform use, i.e., Thunderbird on Windows? > > Enigmail. Haven't actually used it on windows but it is pretty > transparent and I believe it supports windows. Aye, enigmail and thunderbird works on windows. And gpg4win if you have to use outlook and/or claws. > No graceful solution > to keyring management that I know of WinPT is our preferred solution on windows. -- Eray Aslan Developer, Gentoo Linux eras gentoo.org
[gentoo-dev] lastrite: net-mail/mailwrapper net-mail/mailer-config
# Eray Aslan (29 Mar 2011) # Abandoned project. Last release in 2005. Bugs #158003, #97589, # #359411. # Removal in 90 days net-mail/mailwrapper net-mail/mailer-config
Re: [gentoo-dev] Please enhance your USE descriptions!
On Wed, Mar 30, 2011 at 04:41:25PM -0500, Dale wrote: > +1 Some descriptions may as well not have one at all. May as well > Google the flag and the package and see what, if anything, it returns. I would say working as intended. If you do not know what a package does, chances are you don't need to enable it. And if you do want to tinker, USE flags gives you enough of a hint to start googling. Having said that, we should at least have gramatically correct English in descriptions. One might also lean towards more verbosity in end-user oriented packages (versus server/backend/toolchain packages). In any case, 10-15 words should be more than enough to explain what a USE flag does. -- Eray Aslan Developer, Gentoo Linux eras gentoo.org
[gentoo-dev] RDEPENDing on packages from overlays?
https://bugs.gentoo.org/show_bug.cgi?id=364445 https://bugs.gentoo.org/show_bug.cgi?id=364401 Basically, there are requests to add packages to RDEPEND in virtual/mda and virtual/mta that are not in the official tree but in sunrise. On one side, *DEPENDing on a package outside the tree doesn't seem right. Additionally, keeping track of all the overlays and their package versions, USE flags and flag changes are potentially too much to track. We will be making changes to a virtual package without testing whether it works. On the other hand, we are making life (unneccesarily?) difficult for overlay users by not incorporating the requested changes to the official tree. Comments on how to proceed? Is it OK for a virtual to list a package which is in an overlay in RDEPEND? -- Eray Aslan Developer, Gentoo Linux eras gentoo.org
Re: [gentoo-dev] RDEPENDing on packages from overlays?
Replying randomly On Sat, Apr 23, 2011 at 08:24:59AM -0700, Zac Medico wrote: The consensus seems to be to leave it for the package maintainer to decide. I, for one, will be making the necessary changes to include packages from overlays until, for whatever reason, it either * becomes too burdensome * hinders the main tree Thanks for the feedback. -- Eray Aslan Developer, Gentoo Linux eras gentoo.org pgpox9djzdHzo.pgp Description: PGP signature
Re: [gentoo-dev] RDEPENDing on packages from overlays?
On Sun, Apr 24, 2011 at 07:39:55AM +0200, Ulrich Mueller wrote: > I can live with that, as long as the responsibility that packages work > with dependencies from overlays stays entirely with the overlay's > maintainer. Good point. Agreed. > But could you please add a comment in the virtual's ebuild where (i.e. i> in which overlay) the additional dependencies can be found? Done. -- Eray Aslan Developer, Gentoo Linux eras gentoo.org pgpDvU1shNxas.pgp Description: PGP signature
Re: [gentoo-dev] Camellia?
On Wed, Apr 27, 2011 at 03:38:16PM -0400, James Cloos wrote: > Is there any specific reason why smtp.gentoo and pigeon.gentoo use > camellia for their outbound smtp starttls connections? Probably it is the strongest cipher supported. One can do $ openssl ciphers -v 'ALL:@STRENGTH' on those machines and see what comes up top. An upgrade might be in order. -- Eray Aslan Developer, Gentoo Linux eras gentoo.org
Re: [gentoo-dev] Camellia?
On Thu, Apr 28, 2011 at 09:14:07AM -0400, Dane Smith wrote: > I find it somewhat hard to believe that they are using a version of > OpenSSL that doesn't have AES-256. It's been around since 0.9.7. It does have AES256 just lower in the list: eras@woodpecker ~ $ openssl ciphers -v ALL:@STRENGTH | head -n5 ADH-CAMELLIA256-SHA SSLv3 Kx=DH Au=None Enc=Camellia(256) Mac=SHA1 DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1 CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1 ADH-AES256-SHA SSLv3 Kx=DH Au=None Enc=AES(256) Mac=SHA1 eras@woodpecker ~ $ openssl version OpenSSL 0.9.8o 01 Jun 2010 Presumably smtp.g.o and pigeon.g.o has the same setup. ssl_create_cipher_list() makes the above list if you want to check its history. -- Eray Aslan Developer, Gentoo Linux eras gentoo.org
Re: [gentoo-dev] Camellia?
On Thu, Apr 28, 2011 at 06:59:05PM +0300, Panagiotis Christopoulos wrote: > Please, can you continue this somewhere more privately? I wouldn't like it if > I were a sysadmin and someone was posting information about versions of > software of production machines publicly. I hope you understand. Security through obscurity does not work. It especially will not work for the infrastructure of a Linux distribution. -- Eray Aslan Developer, Gentoo Linux eras gentoo.org
[gentoo-dev] git? [was: Re: Devmanual text on ChangeLogs]
On Sun, May 01, 2011 at 12:06:47PM +0300, Samuli Suominen wrote: > ... the time alone if you have to stop on each package to wait for > echangelog to get done just doubles the amount of time you have to put > into committing them. That's just not worth the effort. Won't moving the tree to git will make this a moot discussion? These and similar solutions look more and more lika a band-aid to the defecencies of cvs. What is it really that is holding us up? A dev to spearhead the move? -- Eray Aslan Developer, Gentoo Linux eras gentoo.org
Re: [gentoo-dev] rfc: use of the /run directory
On Wed, May 18, 2011 at 03:36:48AM +0200, Jeroen Roovers wrote: > wrt /var/run on tmpfs, I recall packages installing daemons that expect > their specific directories to be present in /var/run, and that do not > play nice when that directory turns out empty, but we should be able to > work around that by creating the directory in the init.d script before > we execute the daemon. Yes. Some examples: https://bugs.gentoo.org/show_bug.cgi?id=332633 https://bugs.gentoo.org/show_bug.cgi?id=334245 https://bugs.gentoo.org/show_bug.cgi?id=334437 https://bugs.gentoo.org/show_bug.cgi?id=342049 https://bugs.gentoo.org/show_bug.cgi?id=333783 Basically, if we are going to to do the move to /run, we should have a policy of "/var/run and /var/lock can and will be on tmpfs and init scripts should handle this correctly" or something similar. -- Eray Aslan Developer, Gentoo Linux eras gentoo.org pgpq76fWyxOul.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: better policy for ChageLogs
On 2011-06-02 8:09 AM, Peter Volkov wrote: > ChangeLog files are text to be distributed to our users so they are > completely independent of vcs we use. Just ditch the Changelogs and be done with it. The only objection I know is that changelogs act as a NEWS file. Well, it is not a good enough reason in my humble opionion. Find another way to present NEWS if it is deemed necessary. > Is git faster then rsync? I've never done any checks but it'll be > surprising if it will. Git usually is faster - except the initial clone. Basically, rsync protocol scales with the project size not with change size. And lastly, while I don't really care either way, I think at least some of the push back is the result of unfamiliarity with git. And my impression is that unless a dev with enough political capital spearheads the move, this issue will continue to come up for a long time yet. -- Eray signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-mail/gml
# Eray Aslan (4 June 2011) # Dead upstream. Not needed as Google supports # IMAP access to mailboxes now. Bug #151470 # Removal in 30 days net-mail/gml pgpgHNAuXmazo.pgp Description: PGP signature
[gentoo-dev] Last rites: net-mail/vm-pop3d
# Eray Aslan (14 Jun 2011) # Dead upstream. Does not work properly - bug #179497 #370145. # Several good alternatives, including dovecot, cyrus, mailutils. # Removal in 30 days net-mail/vm-pop3d -- Eray Aslan Developer, Gentoo Linux eras gentoo.org pgpQaNUw77DfL.pgp Description: PGP signature
[gentoo-dev] Last rites: net-mail/signature
# Eray Aslan (14 Jun 2011) # Last release in 2000. Possible buffer overflow - bug #349786. # Alternative net-mail/signify but better still most mail # clients provide this service now. # Removal in 30 days net-mail/signature -- Eray Aslan Developer, Gentoo Linux eras gentoo.org pgpKkasWF2FyE.pgp Description: PGP signature
[gentoo-dev] Last rites: net-mail/teapop
# Eray Aslan (18 Jun 2011) # No upstream. Does not work correctly. Bugs #275764 #370171. # Several working alternatives, including dovecot, cyrus, mailutils. # Removal in 30 days net-mail/teapop -- Eray Aslan Developer, Gentoo Linux eras gentoo.org pgp6NX2fNKZ50.pgp Description: PGP signature
[gentoo-dev] Last rites: mail-client/smtpclient
# Eray Aslan (18 Jun 2011) # Dead upstream. Lots of alternatives including mailx, # nail, ssmtp, postfix... # Removal in 30 days mail-client/smtpclient -- Eray Aslan Developer, Gentoo Linux eras gentoo.org pgp2bU8jMnaZR.pgp Description: PGP signature
[gentoo-dev] Last rites: net-mail/freepops
# Eray Aslan (20 Jul 2011) # Dead upstream. Does not compile. Bugs 205442, 354865, 370459. # Removal in 30 days. net-mail/freepops -- Eray Aslan signature.asc Description: Digital signature
Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?
On 2011-08-01 10:23 AM, Samuli Suominen wrote: > that's my impression now too since nobody has managed to provide useful > case for separate /usr, or they have been very vague I will switch if I have to but saying / and /usr on the same filesystem is the better technical solution just annoys me. I understand if going against upstream and keeping them seperate is not worth the hassle and noone steps up to do it. But then we should say so. Please don't kid yourself (or others). -- Eray Aslan signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] /usr vs. initramfs redux
On 2011-08-11 12:56 AM, Robin H. Johnson wrote: > The problem of filling up > / is PEBKAC primarily, and can happen equally for / (think /root), /usr > on /, /var on /. This does not match with my experience. Over the years, I have seen /var filling up several times on servers, but not /. Please be careful with where you are going with this. As a side note, I do admire BSD now and then. Simplicity is good. -- Eray Aslan signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: using /libexec
On 2011-09-08 11:19 AM, Joshua Kinard wrote: > Whoever said we had to do what everyone else did? We're Gentoo, not a > pack of lemmings. If we have to, we should be able to create an > entirely new solution, never thought of before, that fixes the problem > for all parties involved, yet allows us to keep the bit in our security > guide about keeping /usr (and other partitions) separate. I also certainly do not like this systemd crusade and having initramfs and friends forced down our throats. Solving it properly would give Gentoo an advantage over other distros and I feel that this is the road we should take. Problem is this is more or less a doacracy. We are governed by the doers. Choices come down to: * Voice your concern and then hush up if noone takes it up * Spend some non-trivial brain and cpu cycles, not to mention time, to get to a proper solution * Search for alternative, possibly non-Linux, solutions > PS, yell if using PGP/MIME messes this message up. Thunderbird + > Enigmail apparently is very unfriendly to inlined PGP for some odd > reason. The two fight over the bloody line-wrapping mechanics. Looks good. -- Eray Aslan signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: using /libexec
On 2011-09-08 6:58 PM, Michał Górny wrote: > Could you stick to facts rather than pointless accusations? It is not an accusation and it is not pointless. For the last time: Seperate /usr without initramfs used to work. Now it doesn't. What you are proposing is going to make it well neigh impossible to correct later on. We could have done a proper fix instead of going with the flow. But I am not the one doing the coding (or employ the one who does). So, it is not my call. So, I am shutting up. Please do not rehash the same arguments in every email. Having an opinion is fine but being opiniated is not. And it is getting tiresome. -- Eray Aslan signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: using /libexec
On 2011-09-09 1:15 AM, Joshua Kinard wrote: > Under what setup does it not work now? I would very much like to know > if some recent OpenRC thing just hosed something. I'm dealing with > torrential rain here, thunderstorms, and I cannot predict when my next > power outage will be. Last thing I need on my plate is a Linux box not > coming back online because separate /usr was suddenly deprecated. Sorry, I should have qualified it as "it doesn't work reliably for all use cases now". Nothing to do with OpenRC. Mostly, it is udev or rather the binaries that its rules want to run that are in /usr or linked against libraries in /usr before /usr is mounted. Check the archives. There was a discussion I believe. As a side note, most of this discussion seems to result from different paradigms of end users (and companies that cater to them) vs server admins. Priorities and what is important hence their solutions differ. -- Eray Aslan signature.asc Description: OpenPGP digital signature
[gentoo-dev] Lastrites: mail-filter/libdomainkeys
Abandoned project. Historical standard. Use one of the DKIM implementations, which provide domainkeys verification as well, instead. mail-filter/opendkim is a good alternative. Removal in 30 days. -- Eray Aslan signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 2012-01-01 11:50 PM, Olivier Crête wrote: > systemd/dracut/etc handles /usr on its own filesystem just fine. What is > required is that /usr must be mounted before the pivot_root away from > the initramfs. Nitpick: I don't think pivot_root is used anymore. It is basically unlink, mount, chroot and exec now (i.e. switch_root). RedHat made some bad design decisions on RPM (.rpmnew files anyone?) and udev. Udev was probably salvagable before systemd but noone has the motivation or the man-power to manage the huge delta that would result now. It would probably amount to forking udev. So people are following along even if they are unhappy. Plus Redhat did not support in-place upgrades last time I checked. So they don't really care for a lot of problems that are important for us. Regarding the original question, I belive there are 2 issues here: 1. Requiring initramfs (or dracut or whatever) for separate /usr 2. Migrating /bin to /usr/bin, /sbin to /usr/sbin etc. For the first point, we should start requiring initramfs of some sort for separate /usr now. That train has passed. For the second point, we should hold on as long as we deem appropriate. Then reconsider and -most probably- move ahead with the migration. Main point is not to break existing installations by making the move too quickly. Give sysadmins time to to adjust, resize partitions if necessary etc. Do not go for half way solutions (i.e. number 2 in the original email). As a side note, thank you and keep up your good work on OpenRC. I find it is easier, cleaner and in general superior to systemd especially in server settings. And for my laptop, I don't really care which init system is used anyway. -- Eray Aslan signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, Jan 03, 2012 at 01:50:25PM -0500, Olivier Crête wrote: > On Mon, 2012-01-02 at 10:41 +0200, Eray Aslan wrote: > > RedHat made some bad design decisions on RPM (.rpmnew files anyone?) and > > udev. Udev was probably salvagable before systemd but noone has the > > motivation or the man-power to manage the huge delta that would result > > now. It would probably amount to forking udev. So people are following > > along even if they are unhappy. > > This is completely unrelated to RPMs. The same packages are moving towards a system where config files reside under /usr/lib with users overriding the defaults in /etc (/usr/lib/udev/rules.d/ and /etc/udev/rules.d). I doubt this would have come about if RPM had a sensible way of dealing with config files -if they had etc-update/dispatch-conf for example. -- Eray Aslan signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, Jan 04, 2012 at 07:26:05PM +0100, Marc Schiffbauer wrote: > For example, to make that FHS definition be reality there are (can > be) runlevels that will only boot a system with all basic stuff > required to mount the rootfs and make root being able to login to > the local text console. These are the things that make a unixoid > system valuable over other kind of systems. There are benefits to the proposed changes, especially for rpm based distros and especially for non-server settings. Are they good enough? No, I don't think they are. But since forking all those packages is not a realistic proposition, we will have to follow along. We should try and not break existing installations when we do though. > I do not like the idea to throw away all those benefits just because > so many (younger/newer) people do not know about the possibilities > an "old fashioned" unix system tends to have. Hey, this is web 2.0 era. Being mostly right most of the time is good enough. -- Eray Aslan signature.asc Description: Digital signature
Re: [gentoo-dev] Packages up for grabs
On Thu, Mar 01, 2012 at 10:17:12PM +, Markos Chandras wrote: > mail-client/nmh net-mail will co-maintain it. -- Eray Aslan pgpw6E6otB0aq.pgp Description: PGP signature
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Fri, Mar 09, 2012 at 08:15:11AM -0800, Zac Medico wrote: > They may or may not have issues. Our goal is to minimize our > vulnerability to these kinds of issues as much as possible. Being able > to obtain the ebuild EAPI without the expense of sourcing it is one > small step toward this goal. EAPI is metadata and is best treated as such. In other words, history aside, it does not belong inside an ebuild. Making EAPI info part of the filename does look like a reasonable solution - similar to seen/replied flags in the filenames in maildir directories. Heck, even version numbers in an ebuild filename is similar. I don't understand why there is a strong objection to it. But anyway, it is Friday night and I am out of here. Have fun. -- Eray Aslan pgpgziRXSe880.pgp Description: PGP signature
Re: [gentoo-dev] RFC: Change mail-mta/msmtp to be the default in virtual/mta instead of mail-mta/ssmtp ?
On 2012-03-12 10:20 PM, Robin H. Johnson wrote: > One of the greatest things that bugs me about ssmtp is that if the > mailserver is not available, it hangs for a while, and then it loses the > email. To be fair, a queue-less design does keep it simple. > Where I need a simple mail relay, I've gone with nullmailer instead, > because it supports the features, and it explicitly has a lightweight > daemon mode that queues mail to send. msmtp: TLS/SSL and AUTH support. Config can be easier. No queue. nullmailer: AUTH support. No TLS/SSL. Easy to configure and use. Has a queue. I like nullmailer better but usually go with msmtp. TLS/SSL is usually mandatory for login when emails go to some central mail hub and not directly to MX hosts - which is pretty much guaranteed nowadays. I am not sure if we should install a TLS-less mailer by default. Some documantation would be nice in either case. -- Eray Aslan signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: mail-filter/dk-milter mail-filter/dkim-milter
# Eray Aslan (10 Apr 2012) # Dead upstream. Use mail-filter/opendkim instead. # Removal in 30 days - bug 411429 mail-filter/dkim-milter # Eray Aslan (10 Apr 2012) # Dead standard. Dead upstream. # Use mail-filter/opendkim instead. # Removal in 30 days - bug 411427 mail-filter/dk-milter -- Eray Aslan pgp0PF8mOXPQQ.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: Enable FEATURES=config-protect-if-modified by default?
On 2012-05-16 12:13 PM, Andreas K. Huettel wrote: >>> make.conf(5) man page: >>> This causes the CONFIG_PROTECT behavior to be skipped for files that >>> have not been modified since they were installed. > > +1 very good idea Hmm, does that mean that when a default changes in (or some new setting is added to) an app config file, I'll get no prompt and no warning assuming I go with the default settings in the app? That presumes that the new default or the new setting does not break my setup. That is a big assumption. Even if we go with enabling it by default, please have a news item so that one can turn it off if necessary. Even then, new installs will have to remember to turn it off. -- Eray Aslan signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: RFC: Enable FEATURES=config-protect-if-modified by default?
On 2012-05-16 12:56 PM, Fabio Erculiani wrote: > Generally, several PMS (I think apt does it as well) make this assumption: > if config file C owned by package P has never been modified, meaning > that md5 or whatever is the same, the old C of P was fine, so is the > new C. Yep, and I always thought that Gentoo way of dealing with config files was much better -both compared to .deb and .rpm land- in this regard. Presenting the diff is a quick and efficient way to highlight the changes and ask the sysadmin to make the necessary changes if any. I am not bothered with the (frequency of?) diffs but I guess people are. > This also helps a lot in the scenario where critical configuration > files are not updated before reboot, which might result in an > unbootable system (ouch!). Well, that is true. If you forget to dispatch-conf, it might bite you. Anyway, no big deal either way though I prefer the status quo. If we make the change, make it with enough fanfare that users notice. -- Eray Aslan signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-libs/courier-unicode/
On Wed, Nov 18, 2015 at 11:07:50PM +0100, Michał Górny wrote: > This version is required by courier-imap-4.16.0 [1], so you've caused > a depgraph breakage. Please either revert this, Done. Thanks for the email. -- Eray
Re: [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.)
On Fri, Jun 30, 2023 at 03:38:11AM -0600, Tim Harder wrote: > Why do we have to keep exporting the related variables that generally > cause these size issues to the environment? I really do not want to make a +1 response but this is an excellent question that we need to answer before implementing EGO_SUM. -- Eray
Re: [gentoo-dev] RFC: Setting default HOME_MODE in /etc/login.defs
On Sun, Feb 11, 2024 at 10:10:13AM +, Sam James wrote: > I'm in favour, although I'd be curious as to why upstream shadow don't > just set it. It would be interesting to see if the discussion already > happened there at some point (surely it has?) and find out their > reasoning. (But that's not a blocker for proceeding.) I believe it is for historical reasons. Computer networks and terminals used to be much friendlier places. > I want to hear more opinions first though. Thanks for raising this, > it's been in the back of my head. Even though I do not really care either way, what problem exactly are we trying to solve? Better security is just too vague an argument. I can see the argument if we were selling to business (*cough*red hat*cough*) but on the other hand, an argument can also be made for keeping to the roots of computer networks and their naivete (keep information free and all that stuff). In this regard, it is telling that only debian and gentoo keep 022. Consider taking it upstream as someone else (ulm?) already mentioned in the discussion. Thanks -- Eray
[gentoo-dev] net-mail/cyrus-imap-admin dev-libs/cyrus-imap-dev Mask for removal
# Eray Aslan (17 May 2017) # Functionality merged to cyrus-imapd-2.5.x series. # cyrus-imapd-2.5.10 was stabilized in Jan 2017. Upgrade # if you haven't already done so. Removal in 30 days. net-mail/cyrus-imap-admin dev-libs/cyrus-imap-dev # Masking for end-user convenience. Will be dropped once # net-mail/cyrus-imap-admin and dev-libs/cyrus-imap-dev # are tree cleaned. =net-mail/cyrus-imapd-2.4* https://bugs.gentoo.org/show_bug.cgi?id=618716 -- Eray
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On Tue, Jan 09, 2018 at 10:20:56PM +0100, Andreas K. Huettel wrote: > * Posting to the list will only be possible to Gentoo developers and > whitelisted additional participants. This is so contrary to what I and I thought Gentoo stands for: openness, transparency, inclusiveness even when these require a rather thick skin and result in high noise. It's a price worth paying. I guess I should a) pay more attention to council elections b) consider the idea that the whole council thing as it stands now is just not working. -- Eray
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On Wed, Jan 10, 2018 at 08:55:11AM +0100, Lars Wendler wrote: > Seems we're turning into an elitist club or something... Elitist seems too kind a word. Knee-jerk reaction, petty vendetta, impulsive emotional reaction comes to mind - instead of articulating and implementing a vision for the distribution, principled action, making all devs work together towards the goals that have been set. Not day to day reactions and bad ones at that. Council is failing its one main task - it prolly has been for some time, this one also fails "first, do no harm" test. Mind you they are not harming willingly. I am pretty sure they are all well intentioned. They, as a group, just do not have, I dont know, the vision, the experience, the personality to lead a distro. We need a change as otherwise I am afraid the future is not bright. I think with this last straw I lost faith in the current setup. Death by a committee. Yey. -- Eray
Re: [gentoo-dev] Mailing list moderation and community openness
On Tue, Mar 20, 2018 at 10:28:48AM -0500, Matthew Thode wrote: > While I personally do no agree with mailing list moderation infra has > been tasked with moving forward on it. You can always resign from infra. That was a somewhat tongue-in-cheek comment but not wholly. You cant cop out by saying it was an order from council. I understand if you dont but do consider it. Fight the good fight. -- Eray
Re: [gentoo-dev] Mailing list moderation and community openness
On Wed, Mar 21, 2018 at 10:44:48AM -0400, Alec Warner wrote: > [1] Which isn't to say that I would accept 'orders' to commit crimes, or > other obviously bad things. This is the crux of the problem. There are certain lines you will not cross. I am saying that my line is different and by voicing that, hopefully, making you re-consider yours. > I'm again asserting that this idea is not > fundamentally bad. The community has a 'toxic people problem' and our > previous attempts at resolution have not really produced great results. > Will this also produce great results? Not sure. But willing to try it. Openness, transparency, inclusiveness. Those are some pretty fundemental values. Reconsider. But if you decide to go ahead, I am not going to judge you. You (or the council members who voted yes) are not bad persons. Just somewhat different values - which is surprising in a sad way. -- Eray
[gentoo-dev] package up for grabs: net-proxy/squid
Hi, net-proxy/squid is a populer web proxy cache. I do not use squid for a while now and cannot really test any changes. Package needs some love but we have a responsive upstream. Feel free to take it if you are interested. I have removed myself from metadata and assigned the bugs to maintainer-needed. Thanks -- Eray
Re: [gentoo-dev] (Lots of) Packages up for grabs due to net-mail@ project disbanding
On Tue, Mar 26, 2019 at 04:24:07PM -0500, William Hubbs wrote: > On Tue, Mar 26, 2019 at 09:02:07PM +0100, Michał Górny wrote: > > mail-mta/postfix > > I have an interest in this one since my employer uses it. > I don't know how fast I'll work the bugs right now, but I'll take a > look. :-) > > Eray, go ahead and co-maintain with me if you still want to. I've maintainer postfix for the last several years and I will continue maintaining it. Anyone is more than welcome to co-maintain if they wish. Cheers, -- Eray
[gentoo-dev] RFC: UID/GID assignment for postfix (207)
I would like to reserve UID/GID 207 for postfix (mail-mta/postfix). This fixed ID is what we have provided historically and differs from Arch (73) and RedHat (89). -- Eray signature.asc Description: PGP signature
[gentoo-dev] RFC: GID assignment for postdrop (208)
I would like to reserve GID 208 for postdrop (mail-mta/postfix) This fixed ID is what we have provided historically and differs from Arch (75) and RedHat (90). -- Eray signature.asc Description: PGP signature
[gentoo-dev] RFC: UID/GID assignment for dovecot (97)
I would like to reserve UID/GID 97 for dovecot (net-mail/dovecot) This fixed ID is what we have provided historically and is the same as RedHat but differs from Arch (76). -- Eray signature.asc Description: PGP signature
[gentoo-dev] RFC: UID/GID assignment for dovenull (484)
I would like to reserve UID/GID 484 for dovenull (net-mail/dovecot). Arch uses uid 74 for dovenull while Redhat uses next available. -- Eray signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: UID/GID assignment for dovecot (97)
On Wed, Aug 07, 2019 at 11:32:48AM +0300, Alexander Tsoy wrote: > В Ср, 07/08/2019 в 09:29 +0300, Eray Aslan пишет: > > I would like to reserve UID/GID 97 for dovecot (net-mail/dovecot) > > This GID is currently used by the input group (sys-apps/baselayout and > acct-group/input). > > https://bugs.gentoo.org/688390 So do we ask acct-group/input to change their GID? why add an already used fixed gid to baselayout in the first place (and one that is used on other distros as well)? whats the thinking here? or we can change dovecot uid/gid. I dont mind but how do we decide? -- Eray signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: UID/GID assignment for dovecot (97)
On Wed, Aug 07, 2019 at 10:59:48AM +0200, Ulrich Mueller wrote: > Historically dovecot came first, but OTOH the ID was added to baselayout > five years ago, and changing baselayout requires some effort. So I'd > suggest to change dovecot. > > The UIDs and GIDs used by Arch might be good: >dovenull 74 >dovecot 76 Alright. I'll re-send the emails with the revized IDs Thanks -- Eray signature.asc Description: PGP signature
[gentoo-dev] RFC: UID/GID assignment for dovecot (76)
I would like to reserve UID/GID 76 for dovecot (net-mail/dovecot) This id differs from what we have provided historically (97) but gid/97 is used by acct-group/input. So use 76 instead. This id is the same in Arch (76) but differs from Redhat (97). -- Eray signature.asc Description: PGP signature
[gentoo-dev] RFC: UID/GID assignment for dovenull (74)
I would like to reserve UID/GID 74 for dovenull (net-mail/dovecot). Arch also uses uid 74 for dovenull while Redhat uses next available. -- Eray signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: UID/GID assignment for dovecot (76)
On Thu, Aug 15, 2019 at 02:58:17PM -0400, Michael Orlitzky wrote: > On 8/7/19 5:24 AM, Eray Aslan wrote: > > I would like to reserve UID/GID 76 for dovecot (net-mail/dovecot) > > > > This id differs from what we have provided historically (97) but gid/97 > > is used by acct-group/input. So use 76 instead. > > > > This id is the same in Arch (76) but differs from Redhat (97). > > Can we please go back to posting the patches for these new packages? > Personally, I couldn't care less what integer people pick out of a hat. > I review these to prevent situations like this: For the record, it wasnt me who wrote those acct-user ebuilds. > # acct-user/postmaster > DESCRIPTION="Postmaster user" > ACCT_USER_ID=14 > ACCT_USER_HOME=/var/spool/mail > ACCT_USER_HOME_OWNER=root:mail > ACCT_USER_HOME_PERMS=03775 > ACCT_USER_GROUPS=( mail ) > > # acct-user/mail > DESCRIPTION="Mail program user" > ACCT_USER_ID=8 > ACCT_USER_HOME=/var/spool/mail > ACCT_USER_HOME_OWNER=root:mail > ACCT_USER_HOME_PERMS=03775 > ACCT_USER_GROUPS=( mail ) > > These two now need to be kept in-sync forever, because otherwise one is > going to clobber the permissions on the other's home directory. Not > having to worry about that was an explicit goal of GLEP81. > > Given that both of those users are pulled in only by net-mail/mailbase > at the moment, you probably want to set those permissions in the ebuild I dont want to set permissions in the ebuild if possible. Thats not a proper solution. Why do we need a postmaster account at all? Does anyone have a clue? > and leave those two users' home directories at the default. The > net-mail/mailbase package certainly doesn't need their home directories > set to anything in particular. (It doesn't need the user at all, but > that's probably a larger issue with mailbase.) Getting rid of mailbase is certainly another option. -- Eray
Re: [gentoo-dev] [PATCH v2 4/6] app-crypt/openpgp-keys-miniupnp: Package keys used by miniupnp upst
On Tue, Oct 06, 2020 at 06:17:23PM +, Robin H. Johnson wrote: > I'm worried about the proliferation of tiny packages just to convey the > keys; and how versioning should work if upstream rotates their keys. That was my initial reaction as well. The app-crypt/openpgp-keys-* will potentially double the number of packages in the tree. We can probably come up with a better design. I agree with the need to make it easier for developers to check sigs before signing the manifest btw. Thanks for that -- Eray
[gentoo-dev] last rite: mail-filter/dovecot_deleted_to_trash
# Eray Aslan (2020-12-14) # Dead. Last release in 2014. Only works with vulnerable dovecot version. # Recent Outlook versions should have this functionality built in. Switch to a # better mail client if you are still using this package. Removal in 30 days. # Bug #756217 mail-filter/dovecot_deleted_to_trash -- Eray
Re: [gentoo-dev] RFC: new category for container related packages, instead of app-emulation
On Sat, Aug 07, 2021 at 01:17:00AM -0400, Ionen Wolkens wrote: > On Sat, Aug 07, 2021 at 05:56:55AM +0100, Sam James wrote: > > > > > > > On 6 Aug 2021, at 23:27, Louis Sautier wrote: > > > > > > On 06/08/2021 02:57, Alec Warner wrote: > > >> Do people actually care what category things are in? I just use > > >> --search or eix or whatever and the category is just this...bad > > >> concept we attach to packages for silly historical reasons.. > > > > > > I also care about categories: if I want to find a Python MySQL library, > > > I'll run "eix -C dev-python mysql" (3 results) instead of a plain "eix > > > mysql" (33 results). And, as William said, they really help with > > > ambiguous package names such as docker. > > > > This is definitely my approach too. > > > > Anyway, I'm supportive of the new category. If it makes things clearer for > > people, why not? > > While it wouldn't hurt to consider revisiting the system eventually > (mostly to avoid pkgmoves), I feel that's not a debate that needs to > come up every time consider new categories given they're still cheap > to add and a system change wouldn't happen overnight. Categories are just one piece of metadata about the package and incorporating - one somewhat arbitrary - metadata in a name is in general not a good idea. I think that was all Alec was saying and I tend to agree. But it is not an easy fix so go ahead afaic. -- Eray
[gentoo-dev] [PATCH] ssl-cert.eclass: EAPI 8 support and add guard
---
eclass/ssl-cert.eclass | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/eclass/ssl-cert.eclass b/eclass/ssl-cert.eclass
index 36945be3cd6..e5dfbbb141c 100644
--- a/eclass/ssl-cert.eclass
+++ b/eclass/ssl-cert.eclass
@@ -6,7 +6,7 @@
# maintainer-nee...@gentoo.org
# @AUTHOR:
# Max Kalika
-# @SUPPORTED_EAPIS: 1 2 3 4 5 6 7
+# @SUPPORTED_EAPIS: 1 2 3 4 5 6 7 8
# @BLURB: Eclass for SSL certificates
# @DESCRIPTION:
# This eclass implements a standard installation procedure for installing
@@ -19,13 +19,15 @@ case "${EAPI:-0}" in
0)
die "${ECLASS}.eclass: EAPI=0 is not supported. Please upgrade
to EAPI >= 1."
;;
- 1|2|3|4|5|6|7)
+ 1|2|3|4|5|6|7|8)
;;
*)
die "${ECLASS}.eclass: EAPI=${EAPI} is not supported yet."
;;
esac
+if [[ ! ${_SSL_CERT_ECLASS} ]]; then
+
# @ECLASS-VARIABLE: SSL_CERT_MANDATORY
# @PRE_INHERIT
# @DESCRIPTION:
@@ -283,3 +285,6 @@ install_cert() {
ewarn "Some requested certificates were not generated"
fi
}
+
+_SSL_CERT_ECLASS=1
+fi
--
2.33.0
[gentoo-dev] [PATCH 2/2] ssl-cert.eclass: drop support for EAPI < 6
Thank you for the comment. Dropped EAPI < 6 support.
Signed-off-by: Eray Aslan
---
eclass/ssl-cert.eclass | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/eclass/ssl-cert.eclass b/eclass/ssl-cert.eclass
index e5dfbbb141c..428956a4290 100644
--- a/eclass/ssl-cert.eclass
+++ b/eclass/ssl-cert.eclass
@@ -6,7 +6,7 @@
# maintainer-nee...@gentoo.org
# @AUTHOR:
# Max Kalika
-# @SUPPORTED_EAPIS: 1 2 3 4 5 6 7 8
+# @SUPPORTED_EAPIS: 6 7 8
# @BLURB: Eclass for SSL certificates
# @DESCRIPTION:
# This eclass implements a standard installation procedure for installing
@@ -14,16 +14,9 @@
# @EXAMPLE:
# "install_cert /foo/bar" installs ${ROOT}/foo/bar.{key,csr,crt,pem}
-# Guard against unsupported EAPIs. We need EAPI >= 1 for slot dependencies.
-case "${EAPI:-0}" in
- 0)
- die "${ECLASS}.eclass: EAPI=0 is not supported. Please upgrade
to EAPI >= 1."
- ;;
- 1|2|3|4|5|6|7|8)
- ;;
- *)
- die "${ECLASS}.eclass: EAPI=${EAPI} is not supported yet."
- ;;
+case "${EAPI}" in
+ 6|7|8) ;;
+ *) die "EAPI=${EAPI:-0} is not supported" ;;
esac
if [[ ! ${_SSL_CERT_ECLASS} ]]; then
@@ -55,7 +48,7 @@ if [[ "${SSL_DEPS_SKIP}" == "0" ]]; then
fi
case "${EAPI}" in
- 1|2|3|4|5|6)
+ 6)
DEPEND="${SSL_DEPEND}"
;;
*)
--
2.33.0
[gentoo-dev] [PATCH v2] ssl-cert.eclass: add EAPI 8 support
- drop support for EAPI < 6
- add guard
Signed-off-by: Eray Aslan
---
eclass/ssl-cert.eclass | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/eclass/ssl-cert.eclass b/eclass/ssl-cert.eclass
index 36945be3cd6..9d01fd10f50 100644
--- a/eclass/ssl-cert.eclass
+++ b/eclass/ssl-cert.eclass
@@ -6,7 +6,7 @@
# maintainer-nee...@gentoo.org
# @AUTHOR:
# Max Kalika
-# @SUPPORTED_EAPIS: 1 2 3 4 5 6 7
+# @SUPPORTED_EAPIS: 6 7 8
# @BLURB: Eclass for SSL certificates
# @DESCRIPTION:
# This eclass implements a standard installation procedure for installing
@@ -14,18 +14,14 @@
# @EXAMPLE:
# "install_cert /foo/bar" installs ${ROOT}/foo/bar.{key,csr,crt,pem}
-# Guard against unsupported EAPIs. We need EAPI >= 1 for slot dependencies.
-case "${EAPI:-0}" in
- 0)
- die "${ECLASS}.eclass: EAPI=0 is not supported. Please upgrade
to EAPI >= 1."
- ;;
- 1|2|3|4|5|6|7)
- ;;
- *)
- die "${ECLASS}.eclass: EAPI=${EAPI} is not supported yet."
- ;;
+case "${EAPI}" in
+ 6|7|8) ;;
+ *) die "EAPI=${EAPI:-0} is not supported" ;;
esac
+if [[ ! ${_SSL_CERT_ECLASS} ]]; then
+_SSL_CERT_ECLASS=1
+
# @ECLASS-VARIABLE: SSL_CERT_MANDATORY
# @PRE_INHERIT
# @DESCRIPTION:
@@ -53,7 +49,7 @@ if [[ "${SSL_DEPS_SKIP}" == "0" ]]; then
fi
case "${EAPI}" in
- 1|2|3|4|5|6)
+ 6)
DEPEND="${SSL_DEPEND}"
;;
*)
@@ -283,3 +279,5 @@ install_cert() {
ewarn "Some requested certificates were not generated"
fi
}
+
+fi
--
2.33.0
Re: [gentoo-dev] [PATCH v2] ssl-cert.eclass: add EAPI 8 support
On Wed, Sep 15, 2021 at 09:26:59AM +0300, Eray Aslan wrote: > - drop support for EAPI < 6 > - add guard > > Signed-off-by: Eray Aslan Committed. -- Eray
Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval
On Sun, Nov 14, 2021 at 09:15:36PM +0100, Thomas Deutschmann wrote: > On 2021-11-11 11:59, Ulrich Mueller wrote: > > We could: > > > > - Open some part of the range between 500 and 1000. For example, > >500..799, which would leave 200 IDs for dynamic allocation. > > > > - Open part of the range 60001..65533. Not sure if all software will be > >happy with that. > > > > - Admit that the concept of static allocation has failed, and return to > >dynamic allocation. > > Only the third option is really possible. FWIW, I agree with this sentiment. 1/ Static allocation does not really solve a problem. Not really not nowadays 2/ We cant keep adding new IDs to a distribution as new software gets added - one side is unbounded. This is losing game. Switching back to dynamic allocation seems to be the best option. -- Eray
