Summary: | sys-cluster/util-vserver-0.30.216_pre3025: fails to build | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
Component: | New packages | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | hardened, leho, orzel, patrick, sandino, treecleaner, vserver-devs+disabled |
Priority: | Normal | Keywords: | PMASKED |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://tinderboxlogs.s3.amazonaws.com/tbamd64.excelsior.flameeyes.eu/sys-cluster%3Autil-vserver-0.30.216_pre3025%3A20120627-094140.html | ||
Whiteboard: | Pending removal: 2014-08-27 | ||
Package list: | Runtime testing required: | --- |
Description
Diego Elio Pettenò (RETIRED)
2012-06-27 09:44:33 UTC
i don't support hardened. Too bad that this is not hardened then. Same failure here on non-hardened. Same version built a short while ago Possibly a change in one of the deps? Any info needed to narrow down the cause of the failure? ~amd64 (glibc 2.16) it breaks. amd64 stable works amd64 stable + dietlibc-0.33_pre20130103 works (both cases glibc 2.15) Diego's failure was with glibc 2.15 I still have no idea how this happens - the assert in dietlibc that is triggered does not call stpcpy in any way I've been able to find. Very "exciting" bug ;) This makes it "work" by not using dietlibc. No idea if this is a good idea, but I haven't been able to figure out why dietlibc blows up like this. --- util-vserver-0.30.216_pre3025.ebuild 2012-12-05 14:03:49.000000000 +0800 +++ util-vserver-0.30.216_pre3038.ebuild 2013-01-28 11:22:40.281700530 +0800 @@ -53,7 +53,8 @@ src_configure() { econf --with-vrootdir=${VDIRBASE} \ --with-initscripts=gentoo \ - --localstatedir=/var + --localstatedir=/var \ + --disable-dietlibc } src_compile() { not using dietlibc opens up some security holes (caused by the nss system) between vservers and the hosts system according to the linux-vserver kernel maintainer, so this should not be commited Well. Still very much broken. I've had the same error on 3 machines now - is there any sane fix on the horizon? (In reply to comment #5) > This makes it "work" by not using dietlibc. No idea if this is a good idea, > but I haven't been able to figure out why dietlibc blows up like this. > > --- util-vserver-0.30.216_pre3025.ebuild 2012-12-05 > 14:03:49.000000000 +0800 > +++ util-vserver-0.30.216_pre3038.ebuild 2013-01-28 > 11:22:40.281700530 +0800 > @@ -53,7 +53,8 @@ > src_configure() { > econf --with-vrootdir=${VDIRBASE} \ > --with-initscripts=gentoo \ > - --localstatedir=/var > + --localstatedir=/var \ > + --disable-dietlibc > } > > src_compile() { Probably related with bug 414629 Not since this also occurs in non-hardened :S I am still unable to build any version of it... and since we cannot use glibc, I would treeclean if nobody finds the fix (as this is being unbuildable for a long time) (i'm the author of bug #414629 which is marked as "maybe" linked to this one) I'm still using the workaround described on this other ticket : a local copy of the ebuild changed to not use dietlibc .. (using pre3038 though) Has anybody asked Bertl for help? linux-vserver is definitely not dead as a project. it compiles fine with the git dietlibc version on https://github.com/ensc/dietlibc.git supposedly that is version 0.34? would it make sense to create a snapshot tarball from the git version and push into portage? at least for the time being. i created a quick local dietlibc-0.34 ebuild, against which all util-vserver versions seem to compile fine. i can confirm, vserver is definitive not dead. seems like dietlibc is unmainted though -> the removal of dietlibc causes the removal of util-vserver. thats overkill imho :) personally, i would vote for a tarball snapshot of dietlibc until another course of action can be determined. that's what the 'lastrite' is for, a mail is set to gentoo-dev@ ML noticing the package might be removed in 30 days, every developer with commit access to Portage tree will see the mail and can take action on it so it doesn't really help to say in the bug "but I use this!" i didn't read the bug through but i can see no patches are attached here, so a patch that makes the package compile again, would propably be the first step of getting someone who doesn't use dietlibc, or doesn't use vserver, but happens to have a commit access, to commit the fix for you or if the correct solution is to create a dietlibc snapshot, new bug should be opened for that (if there isn't one already) and this bug should be made "Depends on: " that bug, and in that bug, an snapshot ebuild could be attached just trying to clarify the workflow. nobody is intrested in removing working packages, but i can understand why people are afraid of committing fixes to packages they don't know about... also, weird that vserver-devs@gentoo.org mail address wasn't even in CC list We are also having multiple unresolved bugs with dietlibc: https://bugs.gentoo.org/buglist.cgi?quicksearch=dietlibc&list_id=2435726 That is why I would have tried to use glibc at start... but later others shown us that it wasn't a good idea and, then, got blocked due both packages being really unattended (and dietlibc also being really poorly maintained by upstream, I remember I did a snapshot for it time ago and, even if it fixed some existing bug reports, also had some new issues :S) + 29 Jul 2014; Patrick Lauer <patrick@gentoo.org> + +util-vserver-0.30.216_pre3038-r1.ebuild: + Little revision bump that has deps changed to working dietlibc version Why do I have to beat things into shape! ;) |