[gentoo-dev] Last rites: mail-filter/dk-milter mail-filter/dkim-milter
# Eray Aslan e...@gentoo.org (10 Apr 2012) # Dead upstream. Use mail-filter/opendkim instead. # Removal in 30 days - bug 411429 mail-filter/dkim-milter # Eray Aslan e...@gentoo.org (10 Apr 2012) # Dead standard. Dead upstream. # Use mail-filter/opendkim instead. # Removal in 30 days - bug 411427 mail-filter/dk-milter -- Eray Aslan e...@gentoo.org pgp0PF8mOXPQQ.pgp Description: PGP signature
[gentoo-dev] About how to handle wxGTK based packages with gnome profiles
Currently gnome profiles enable automatically gtk USE flag and, then, most gtk based GUIs are installed by default on systems using that profile. A special situation occurs when the package is based in wxGTK as explained in: https://bugs.gentoo.org/show_bug.cgi?id=411053 Currently, packages like mkvtoolnix simply builds without no gui at all when using gnome profile because its gui is build with wxwidgets USE flag. At first, I suggested to move from wxwidgets to gtk USE flag for that package because that wxwidgets based gui is the only gtk gui offered by that package. The problem is that their maintainers disagree with that approach as explained in referred bug report. Other option would be to enable wxwidgets by default for that profiles. What do you think? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About how to handle wxGTK based packages with gnome profiles
On 4/10/12 8:58 AM, Pacho Ramos wrote: Other option would be to enable wxwidgets by default for that profiles. I prefer this. Changing USE flag meaning in a counter-intuitive way (to let gtk mean wxwidgets) would seem frustrating to me. With wxwidgets enabled by default people will get the most likely desired result (i.e. GUI) out of the box, and setting USE=-wxwidgets will have desired effect. Note that with USE=gtk really meaning USE=wxwidgets, -wxwidgets would have no effect on such a package, which is the potentially surprising behavior I mentioned earlier. signature.asc Description: OpenPGP digital signature
[gentoo-dev] pybugz call for testers
All, I have updated pybugz- to work with the xmlrpc interface of bugzilla. I can name a couple of issues that are api limitations that we can't do anything about: - you can't add keywords to a bug with the post command, but you can with the modify command. - you can't search on cc: or keywords fields. I haven't done a release yet, since there may be other issues.But, if you are up to it, feel free to emerge pybugz- and test and report any issues you find. Thanks, William pgpnbol9JFg83.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
On Sun, Apr 08, 2012 at 03:04:22PM -0700, Greg KH wrote:
On Sun, Apr 08, 2012 at 04:30:01PM +0200, Ulrich Mueller wrote:
New udev and separate /usr partition
Decide on whether a separate /usr is still a supported configuration.
If it is, newer udev can not be stabled and alternatives should be
investigated. If it isn't, a lot of documentation will have to be
updated. (And an alternative should likely still be provided.)
There is no disagreement about whether or not separate /usr will be
supported. No one has said that you can't have a separate /usr
partition.
Was the council aware of the tracker bug we have open where we are
tracking the documentation changes explaining how to build an initramfs
if you have a separate /usr partition [1]?
Also, I am going to reiterate what Greg said. This is not an issue with
udev, but with the entire linux ecosystem.
There are binaries in /{bin,sbin} which link against libraries in
/usr/lib for example.
Also, with the appropriate documentation changes, which are being worked
on (see [1]), I feel that the statement above that newer udev can't be
stabled should be re-evaluated.
William
[1] https://bugs.gentoo.org/show_bug.cgi?id=407959
pgpUAdzbT64Xc.pgp
Description: PGP signature
[gentoo-dev] glibc-2.14 for stable
there's one known bug (with a patch posted), so if you guys have anything that'd block glibc-2.14 for stable, nows' the time to file the bugs (and mark it a blocker of 370409). -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] glibc-2.15 for unstable
once glibc-2.14 starts stabilizing, i'll be moving 2.15 into unstable -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Are we allowed to provide valid SRC_URI for fetch restricted packages?
On Sunday 26 February 2012 06:34:13 Kacper Kowalik wrote: I've been asked by a user to remove valid SRC_URI for a package that has RESTRICT=fetch. The package in question requires you to go to upstream's webpage, sign license agreement and then you're fed with download link. User argues that by giving people valid download link hardcoded in ebuild we may encourage them to bypass the registration step[1] and that may pose a legal threat. Can anyone more law-aware comment on that? i don't see a problem here. although this is something that you'd prob want to post to the trustees and let them make a decision. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] glibc-2.14 for stable
On Tuesday 10 April 2012 15:35:39 Mike Frysinger wrote: there's one known bug (with a patch posted), so if you guys have anything that'd block glibc-2.14 for stable, nows' the time to file the bugs (and mark it a blocker of 370409). -mike I'd say to proceed directly in 393477 -- Agostino Sarubboago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Are we allowed to provide valid SRC_URI for fetch restricted packages?
On Tue, Apr 10, 2012 at 3:38 PM, Mike Frysinger vap...@gentoo.org wrote: i don't see a problem here. although this is something that you'd prob want to post to the trustees and let them make a decision. -mike This is a bit of a stale thread. This particular package was modified to remove the SRC_URI, so it is no longer outstanding. The Trustees have discussed, and i'd say a majority would prefer not to have SRC_URI for fetch-restricted files. However, I don't believe we put it to a vote. Personally, I tend to not see an issue here, but am open-minded to specific precedents/etc that raise concerns. I think others are a bit more conservative. Rich
Re: [gentoo-dev] Gentoo CJK team empty, or anyone knows about ibus?
On Monday 02 April 2012 22:29:47 Naohiro Aota wrote: Pacho Ramos pa...@gentoo.org writes: Will CC cjk team then to let them know you are interested to join (looks like there are four devs in cjk alias...) Any updates on this? I didn't notice him been working to return dev, I sent him invitation with ebuild-quizes :/. Then I got response from him asking me about CJK docs to read or bugs to take a look at. Jack, I'm adding you to cjk alias and herd.xml. We don't have any special docs to read nor bugs to solve as a team for now. But LDFLAGS bugs (334601, 334763, or such) would be good to start with, I think. And personaly, I'd like to improve im-chooser support (i.e. confirm it working, fix any bugs, and writing documentation) if you need another body to ease ibus updating, let me know. i'd like very much to keep these guys alive and working. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] glibc-2.14 for stable
On Tuesday 10 April 2012 15:44:05 Agostino Sarubbo wrote: On Tuesday 10 April 2012 15:35:39 Mike Frysinger wrote: there's one known bug (with a patch posted), so if you guys have anything that'd block glibc-2.14 for stable, nows' the time to file the bugs (and mark it a blocker of 370409). I'd say to proceed directly in 393477 not really sure what you're referring to here. that bug is already fixed in latest glibc-2.14 ebuild. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] glibc-2.14 for stable
On Tuesday 10 April 2012 15:51:33 Mike Frysinger wrote: not really sure what you're referring to here. that bug is already fixed in latest glibc-2.14 ebuild. I mean, no need to open a new bug, just continue in that security bug, because the fixed version has never had stable keyword. -- Agostino Sarubboago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] About how to handle wxGTK based packages with gnome profiles
El mar, 10-04-2012 a las 09:12 +0200, Paweł Hajdan, Jr. escribió: On 4/10/12 8:58 AM, Pacho Ramos wrote: Other option would be to enable wxwidgets by default for that profiles. I prefer this. Changing USE flag meaning in a counter-intuitive way (to let gtk mean wxwidgets) would seem frustrating to me. With wxwidgets enabled by default people will get the most likely desired result (i.e. GUI) out of the box, and setting USE=-wxwidgets will have desired effect. Note that with USE=gtk really meaning USE=wxwidgets, -wxwidgets would have no effect on such a package, which is the potentially surprising behavior I mentioned earlier. OK, looks like I misunderstood how wxwidgets work and most opinions point to enable wxwidgets by default in gnome profiles, ok with that solution? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] pybugz call for testers
On 4/10/12 7:54 PM, William Hubbs wrote: I have updated pybugz- to work with the xmlrpc interface of bugzilla. Cool, thank you for working on that. I can name a couple of issues that are api limitations that we can't do anything about: - you can't search on cc: or keywords fields. That's going to be a problem for arch testing needs (e.g. STABLEREQ keyword and x86@ cc-ed). How about doing the searches the old way that allowed the above. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] pybugz call for testers
On Tue, Apr 10, 2012 at 10:45:14PM +0200, Paweł Hajdan, Jr. wrote: On 4/10/12 7:54 PM, William Hubbs wrote: I have updated pybugz- to work with the xmlrpc interface of bugzilla. Cool, thank you for working on that. I can name a couple of issues that are api limitations that we can't do anything about: - you can't search on cc: or keywords fields. That's going to be a problem for arch testing needs (e.g. STABLEREQ keyword and x86@ cc-ed). How about doing the searches the old way that allowed the above. That is not so easy to do since we have completely gotten rid of the old method of communicating with bugzilla. That method was not reliable and had broken several times with bugzilla upgrades, but using the web services will be more stable. Here is the documentation for their search command [1]. It would probably be better for us to open a bug against bugzilla itself and request those changes be put in the api. What are your thoughts? William [1] http://www.bugzilla.org/docs/4.2/en/html/api/Bugzilla/WebService/Bug.html#search pgpT2yL2vhpuE.pgp Description: PGP signature
[gentoo-dev] Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
Zac Medico wrote:
On 04/09/2012 11:09 AM, Steven J Long wrote:
One thing that has bothered me with the mooting of an initramfs as the
new rescue system that rootfs has traditionally been, is at the we are
told at the same time that the initramfs can be very minimal. If so, how
does it provide the same capabilities as rootfs (for those of us who can
localmount without udev-configured devices)?
We've had some discussion on this before [1], and I've suggested to copy
the content of livecd/usb recovery disk onto a spare partition so that
you can boot into that if necessary. The advantage of using this
approach is that it eliminates the burden of maintaining the / is a
self-contained boot disk that's independent of /usr use case.
It's a nice idea, and could also be done without an initramfs, ofc. You
mention configuring initramfs to mount that as the root if something goes
wrong with your real root.
Thing is, for most desktop/laptop installs, if something goes wrong mounting
root from hard-disk, it's likely that booting into another partition will go
wrong too. It's pretty rare to get errors just on rootfs, that aren't to do
with the whole drive, and aren't fixed by fsck on a stable fs like ext3. (If
you do, you have to go to backups ofc, and would be wise to suspect the
whole drive.) At least, that's been my experience using separate partitions
for everything.
In that circumstance, if a rescue shell weren't available, (you're able to
boot the kernel or the the spare partition can't be booted to) I would just
boot the latest sysresccd that was around, if not able to download from
another box. If it were really that bad, I'd likely want to reinitialise any
failing partition, and would probably want a recent minimal install disk.
Boot up problems which need admin-work on Gentoo, ime, tend to be about
system upgrades not playing nicely, rather than the kernel unable to boot at
all (once you know which drivers you need for eg PCI/SATA drives built-in,
you usually are able to get at least root consistently, on an older kernel
if you're upgrading.)
Again, being able to boot into the machine, and have the rootfs at hand for
say dispatch-conf and rc-update, works nicely. A rescue partition would
effectively work the same as a live-disk, in that you'd need to do all the
chrooting etc afaics, and would need to be maintained to stay current.
I suppose you could script that, but again, it just seems like a lot of
bother to implement an alternative that doesn't actually gain anything
over the traditional setup (plus making sure that partitions are mounted
before udev starts.)
As for the burden of ensuring that binaries installed to /{s,}bin don't link
to libs in /usr, why not just automate a QA check for that, and let
developers decide whether a fix is necessary? After all, core packages that
do that even when configured with prefix and execprefix = /, aren't so
portable, and Gentoo has always championed doing the right thing wrt
helping upstream fix portability issues.
I realise core is subjective, but it amounts to what our lovely devs
decide on for us which is part of the reason you choose a distro, and the
trust you place in its developers.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
On 04/10/2012 07:28 PM, Steven J Long wrote:
I suppose you could script that, but again, it just seems like a lot of
bother to implement an alternative that doesn't actually gain anything
over the traditional setup (plus making sure that partitions are mounted
before udev starts.)
At least in the case of udev, we gain from not having to maintain a fork.
As for the burden of ensuring that binaries installed to /{s,}bin don't link
to libs in /usr, why not just automate a QA check for that, and let
developers decide whether a fix is necessary? After all, core packages that
do that even when configured with prefix and execprefix = /, aren't so
portable, and Gentoo has always championed doing the right thing wrt
helping upstream fix portability issues.
If the relevant ebuild developers really want to support that, it's fine
I guess. Hopefully that won't involve using static links as workarounds
for cross-/usr dependencies.
--
Thanks,
Zac
Re: [gentoo-dev] pybugz call for testers
On Tue, Apr 10, 2012 at 5:17 PM, William Hubbs willi...@gentoo.org wrote: Here is the documentation for their search command [1]. It would probably be better for us to open a bug against bugzilla itself and request those changes be put in the api. I did some digging on Bugzilla's Bugzilla. There is already a bug open with patches to expose additional search functionality via the web service api. This bug has open since 2009, but it has seen some recent activity (within the last few months). https://bugzilla.mozilla.org/show_bug.cgi?id=475754
Re: [gentoo-dev] Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
On Tue, Apr 10, 2012 at 09:09:03PM -0700, Zac Medico wrote:
On 04/10/2012 07:28 PM, Steven J Long wrote:
I suppose you could script that, but again, it just seems like a lot of
bother to implement an alternative that doesn't actually gain anything
over the traditional setup (plus making sure that partitions are mounted
before udev starts.)
At least in the case of udev, we gain from not having to maintain a fork.
As for the burden of ensuring that binaries installed to /{s,}bin don't link
to libs in /usr, why not just automate a QA check for that, and let
developers decide whether a fix is necessary? After all, core packages that
do that even when configured with prefix and execprefix = /, aren't so
portable, and Gentoo has always championed doing the right thing wrt
helping upstream fix portability issues.
If the relevant ebuild developers really want to support that, it's fine
I guess. Hopefully that won't involve using static links as workarounds
for cross-/usr dependencies.
Another issue to consider is binaries that want to access things in
/usr/share/*. If a binary in /{bin,sbin} needs to access something in
/usr/share/*, you have two choices. move the binary to /usr or move the
thing it wants to access to / somewhere which would involve creating
/share. Actually there is another choice, but I don't want to go there.
That would be writing patches.
The best way to solve all cross / - /usr dependencies imo is the /usr
merge (moving everything from /{bin,sbin,lib*} to the counterparts in
/usr), which has been discussed pretty extensively on this list, and
there hasn't been a lot of opposition to it.
William
pgppMLDuqUmiW.pgp
Description: PGP signature
