[gentoo-dev] Duplicate bug reports, resolution status and Bug 426262
(First, I don't care how the autoconf.in-autoconf.ac migration is handled at a code level. This isn't about that. I'd appreciate if that were largely handled in a separate thread. This (I think) is about policy around bug reporting.) Timeline: 1) *Bug 426262* https://bugs.gentoo.org/show_bug.cgi?id=426262 was filed 2) SpanKY mailto:vap...@gentoo.org committedhttp://sources.gentoo.org/eclass/autotools.eclass?r1=1.165r2=1.166 , and marked #426262 RESOLVED/FIXED, with the intent of flushing out configure.in use cases. http://sources.gentoo.org/eclass/autotools.eclass?r1=1.165r2=1.166 3) I hit SpanKY's eqawarn, and filed #530478. 4) Jer marked #530478 as a dupe of #426262, which was still marked #426262. 5) Being the only one who's apparently filed anything following this eqawarn, I kicked off an emerge -e @world to trawl for more use cases on my system. (I'd rather not have my system break when autotools is eventually upgraded.) (then there's a spat between Justin Lecher and Jer, but that's not relevant yet.) I'm confused about two things. First, if something is supposed to have attention paid to it (which I take to be the purpose of the eqawarn), I don't see how it makes sense for bug reports responding to the eqawarn to be marked as duplicate of a bug that's in the RESOLVED/FIXED state; who's going to pay attention to that, in the general case? (In this case, Justin saw it, unmarked the dupe, set up a tracker for the issue and marked my bug as a blocker for that.) Second, having my bug report marked as a dupe of one already in the RESOLVED/FIXED state tells me that my bug report was a waste of time. Reading the content of #426262 suggests to me that any further filings will also be marked as duplicates of the RESOLVED/FIXED bug, and thus also wastes of time. I don't mind burning a few CPU cycles if it's useful, but if it's just going to waste time, there's obviously no point, and I should kill the emerge I started. So...could I get some clarification here? I don't get the dupe-marking pattern, and I don't know whether or not I should kill off my emerge -e. http://sources.gentoo.org/eclass/autotools.eclass?r1=1.165r2=1.166
[gentoo-dev] tb logs attacher
Hi, did you end up running the script only for RESO/NEEDINFO or for all of them? If you have a chance to run it for every bug I will just turn down the S3 account afterwards. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 20 November 2014 at 16:04, Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/11/14 09:47 AM, Ian Stakenvicius wrote: On 19/11/14 09:51 PM, Rich Freeman wrote: On Wed, Nov 19, 2014 at 8:41 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 31 October 2014 09:28, Diego Elio Pettenò flamee...@flameeyes.eu wrote: So who wants to pick up the pieces now? Because I'm almost pissed off enough to turn down the tinderbox and give a big FU to Gentoo already. https://bugs.gentoo.org/show_bug.cgi?id=527608 More! https://bugs.gentoo.org/show_bug.cgi?id=529788 Again, is somebody going to stand up and do something or can I shut down my tinderbox and spend my free time playing Baldur's Gate? Guys, can we please give the volunteers who are going around uploading logs time to do their jobs before we go closing bugs as invalid? The logs are going to get attached. If somebody is in a mad rush to actually resolve the bug (heaven forbid), then just click on the link. My script is running every 10 minutes; I can do it more often than that but I don't want to hammer b.g.o if I don't have to. Also, as of now, it *does not* upload to bugs that are marked RESOLVED. I think I'll adjust that so it will upload to bugs marked RESO/NEEDINFO (and re-open them), but please, ^^^ And finally, if anyone sees an issue, including if bugs are not getting their attachments in a timely manner, please attach the bug to tracker bug 527870 and I'll do my best to fix things. Thanks, Ian Ok, added the RESO/NEEDINFO case, and bumped my polling time to 5 minute intervals. Diego, please keep going, your efforts are still very much appreciated. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlRuESgACgkQ2ugaI38ACPDR8AEAgdIvuivmg++PiDlUPfLOy7SR XUL5q4H+PFWRz077musA+gIbaPVFRBivJg11IXHHZtJVxj924iz/uyvNV+NlQyVF =YNpA -END PGP SIGNATURE-
Re: [gentoo-dev] Packages up for grabs
I would like to take care of the following packages but I would need a proxy-maintainer. hasufell hasuf...@gentoo.org writes: app-admin/clustershell dev-python/simplegui dev-python/jedi dev-libs/mathjax net-misc/youtube-viewer co-maintained by games ga...@gentoo.org dev-games/mygui games-action/armagetronad games-strategy/liquidwar6 co-maintained with Patrick Lauer patr...@gentoo.org sci-mathematics/flint
Re: [gentoo-dev] Packages up for grabs
On 2014-11-23 20:17, hasufell wrote: dev-python/jedi I'll help maintain this. Tim pgpeY1d3cCgA7.pgp Description: PGP signature
Re: [gentoo-dev] tb logs attacher
On Tue, Nov 25, 2014 at 5:45 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: Hi, did you end up running the script only for RESO/NEEDINFO or for all of them? If you have a chance to run it for every bug I will just turn down the S3 account afterwards. Would it make sense to start logging the URLs that have been uploaded and send them to you in batches? That could be used with a script to purge no-longer-needed logs. -- Rich
Re: [gentoo-dev] tb logs attacher
On 26 November 2014 at 02:19, Rich Freeman ri...@gentoo.org wrote: Would it make sense to start logging the URLs that have been uploaded and send them to you in batches? That could be used with a script to purge no-longer-needed logs. It's a bit tricky. Becuase the vast majority of the logs were never filed a bug against, so I could easily just remove them and will probably end up well below S3's freebie quota. I'm more hoping that since there won't be any *new* bug logged, processing the past would be easy. I don't mind waiting even an year to turn it off: it would account to maybe 5% of the cost of one month of bare server hosting. For myself, this is just closure. I was tired already of the situation and I just want to get over it now. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
[gentoo-dev] Packages up for grab
Trying to dump first the packages I no longer use/I'm no longer interested in: app-crypt/sgeps app-emacs/actionscript-mode dev-java/jcommander dev-perl/CHI dev-perl/Data-Uniqid dev-perl/Digest-JHash dev-perl/Filesys-SmbClient dev-perl/google-api-adwords-perl dev-perl/Hash-MoreUtils dev-perl/String-RewritePrefix dev-perl/Test-MockModule games-board/cockatrice media-gfx/entangle media-gfx/pixie net-misc/lksctp-tools net-misc/miredo net-misc/teamviewer net-misc/tsclient net-proxy/c-icap net-proxy/squidclamav net-proxy/ufdbguard sys-apps/timer_entropyd sys-block/hpacucli x11-themes/constantine-backgrounds x11-themes/gentoo10-backgrounds x11-themes/goddard-backgrounds x11-themes/laughlin-backgrounds x11-themes/leonidas-backgrounds x11-themes/lovelock-backgrounds x11-themes/solar-backgrounds x11-themes/verne-backgrounds (Proxy maintained by Pavel Stratil) dev-db/drizzle dev-db/haildb dev-db/mydumper dev-php/pecl-drizzle dev-php/pecl-gearman sys-cluster/gearmand www-apache/mod_auth_token Please update the metadata and get the bugs if you want to maintain them, otherwise they'll stay assigned to me untl either I retire or I find time to fix them for good.
Re: [gentoo-dev] Packages up for grab
On Wed, 26 Nov 2014, Diego Elio Pettenò wrote: Trying to dump first the packages I no longer use/I'm no longer interested in: app-emacs/actionscript-mode The Emacs team will take this one. Ulrich pgprd4tytV5NQ.pgp Description: PGP signature
[gentoo-portage-dev] [PATCH] Force the SELinux user during relabel operation (530192)
From: Sven Vermeulen sven.vermeu...@siphos.be
When Portage relabels the files of the package, it currently calls
setfiles (which is correct) but does not use the -F option (force). As a
result, the files only get assigned the right SELinux type, but not the
right SELinux user and SELinux role.
By using setfiles -F, the SELinux user (and role, but role almost
always remains object_r) is set to the right one (system_u mostly).
Without this, a multi-user system with different SELinux users and with
User Based Access Control (UBAC) enabled (the local ubac USE flag)
might find that some software fails to work for different SELinux users
than the one used to install the software, until a full forced relabel
operation is done.
X-Gentoo-Bug: 530192
X-Gentoo-Url: https://bugs.gentoo.org/show_bug.cgi?id=530192
---
bin/misc-functions.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bin/misc-functions.sh b/bin/misc-functions.sh
index 6e6fcb4..8d5df78 100755
--- a/bin/misc-functions.sh
+++ b/bin/misc-functions.sh
@@ -392,7 +392,7 @@ preinst_selinux_labels() {
addwrite /selinux/context
addwrite /sys/fs/selinux/context
- /usr/sbin/setfiles ${file_contexts_path} -r
${D} ${D}
+ /usr/sbin/setfiles -F ${file_contexts_path}
-r ${D} ${D}
) || die Failed to set SELinux security labels.
else
# nonfatal, since merging can happen outside a SE kernel
--
2.0.4
Re: [gentoo-portage-dev] [PATCH] Force the SELinux user during relabel operation (530192)
On Tue, 25 Nov 2014 10:22:44 -0800
Zac Medico zmed...@gentoo.org wrote:
From: Sven Vermeulen sven.vermeu...@siphos.be
When Portage relabels the files of the package, it currently calls
setfiles (which is correct) but does not use the -F option (force).
As a result, the files only get assigned the right SELinux type, but
not the right SELinux user and SELinux role.
By using setfiles -F, the SELinux user (and role, but role almost
always remains object_r) is set to the right one (system_u mostly).
Without this, a multi-user system with different SELinux users and
with User Based Access Control (UBAC) enabled (the local ubac USE
flag) might find that some software fails to work for different
SELinux users than the one used to install the software, until a full
forced relabel operation is done.
X-Gentoo-Bug: 530192
X-Gentoo-Url: https://bugs.gentoo.org/show_bug.cgi?id=530192
---
bin/misc-functions.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bin/misc-functions.sh b/bin/misc-functions.sh
index 6e6fcb4..8d5df78 100755
--- a/bin/misc-functions.sh
+++ b/bin/misc-functions.sh
@@ -392,7 +392,7 @@ preinst_selinux_labels() {
addwrite /selinux/context
addwrite /sys/fs/selinux/context
- /usr/sbin/setfiles
${file_contexts_path} -r ${D} ${D}
+ /usr/sbin/setfiles -F
${file_contexts_path} -r ${D} ${D} ) || die Failed to set
SELinux security labels. else
# nonfatal, since merging can happen outside
a SE kernel
It's fine with me if you fine with it. I just thought you would have
acked it in the bug.
--
Brian Dolbec dolsen
