infinitycjwatson: Yeah, I mentioned postinst in my above rambling.00:45
infinity12:54 < infinity> cjwatson: Something like http://paste.ubuntu.com/1492918/ perhaps.00:46
infinity12:55 < infinity> (And a similar munging of postinst)00:46
infinitycjwatson: Just without a nick hilight, I guess.00:46
=== hggdh_ is now known as hggdh
=== Noskcaj is now known as Noskcaj_afk
tjaaltoninfinity: yo, about the sssd rejection.. I forgot to add a pointer to bug 1086304 in the changelog, would that have made a difference?06:35
ubot2Launchpad bug 1086304 in sssd (Ubuntu Precise) "new upstream bugfix release from the LTM branch" [High,In progress] https://launchpad.net/bugs/108630406:35
=== Noskcaj_afk is now known as Noskcaj
infinitytjaalton: Unless we have a bug for every single fix in that new upstream release, it's going to need an MRE, or at least some serious review.07:42
infinitytjaalton: (And I'm guessing you don't have bugs with testcases for every change)07:43
tjaaltoninfinity: no I don't08:06
tjaaltonhmm, technical-board@ is not listed on lists.u.c08:09
tjaaltoninfinity: sent the MRE :)08:37
=== doko_ is now known as doko
psivaawould anyone know why precise desktop i386 images are not yet published to cdimage despite 'Build successfully added to the tracker' in the logs10:03
tjaaltoncjwatson: so, would something like this work for livecd-rootfs? http://pastebin.com/b3gzhpnf10:54
* ogra_ wuld rather put it into a flavour based case function instead of making it arch based11:28
ogra_(if you actually mean what you say in the changelog ;) )11:29
cjwatsontjaalton: on leave today11:29
cjwatsonogra_: well it should probably go alongside the kernel -lts-quantal handling11:29
ogra_cjwatson, yes but then the changelog describes it wrongly11:30
ogra_since it says it is for ubuntu/edubuntu only11:30
ogra_so just adjust the changelog to say i368/amd64 instead of mentioning the flavours11:30
cjwatsonit's per-flavour too11:31
cjwatsonso definitely not "instead of"11:31
tjaaltonyeah the diff just doesn't show the context fully :)11:32
ogra_right, and i didnt look at the actual code only at the diff ... sorry, technically it looks fine11:33
gemaogra_: any idea who's on duty for the release team today?12:02
gemaogra_: we are missing precise desktop i386 images and unsure who to ask for them :)12:03
ogra_gema, no idea, i just got back from vac. yesterday12:04
gemaogra_: oh, welcome back!12:04
brendandgema, there was a problem with yesterdays image and the kernels included12:04
* ogra_ will look for logs though, i havent got any failure mails for broken builds 12:04
gemaogra_: thanks !12:04
brendandgema, which might explain why i386 is not there since the issue only affected that12:04
gemabrendand: precise?12:04
gemabrendand: ok, that may be it then12:05
brendandgema, yes the 12.04.2 dailies12:05
gemabrendand: is there a bug for that?12:05
ogra_ah, yeah there were some kernel related uploads12:05
ogra_and i dont get failure mails for 12.04 builds i think12:05
psivaabrendand: gema: ogra_: but the images were built successfully12:06
gemapsivaa: yesterday?12:06
psivaagema: today as well12:06
gemapsivaa: so the only thing that failed is the publishing?12:06
brendandgema, cjwatson was looking at it, not sure if there is a bug number12:06
gemabrendand: ack12:06
Laneymv: cannot stat `/srv/cdimage.ubuntu.com/scratch/ubuntu/precise/daily-live/tmp/precise-i386/CD1/casper/filesystem.kernel-generic-pae': No such file or directory12:06
Laneymake: *** [/srv/cdimage.ubuntu.com/scratch/ubuntu/precise/daily-live/tmp/precise-i386/bootable-stamp] Error 112:06
gemaoh, so there is a problem :D12:07
psivaagema: as far as i understood, yes it was a publishing issue, http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/precise/daily-20130104.log12:08
gemaok, thanks12:09
Laneythat's the alternate12:09
Laneywhich is on there12:09
ogra_has the same error12:10
cjwatsonI know about the precise thing and will fix it on Monday when I'm back12:10
cjwatsonno bug12:10
ogra_gema, ^^^12:10
cjwatsonhm, mind you maybe I can make a really quick stab at it now12:10
gemaogra_, cjwatson ack, monday is fine, as long as you guys are on the case, I am happy12:11
cjwatsonI've had a shot at fixing it; may or may not work12:15
cjwatsonif it doesn't work it'll have to wait 'til Monday or somebody else will have to figure it out12:15
cjwatsonIf somebody wants to spend a bit of time tracking down an image build bug, I'd really appreciate somebody working out why the Chinese edition build is failing12:52
cjwatsonIt seems to be producing a full log but no actual output, or exiting non-zero, or something12:53
=== yofel_ is now known as yofel
lamontshould I be at all concerned that raring seems to not debootstrap atm?14:35
xnoxlamont: do you have a log? (with/without -proposed/universe)?14:38
lamontxnox: I suppose I could cause one to exist.  let me do that14:39
lamontdpkg-deb: file `.//var/cache/apt/archives/libglib2.0-0_2.34.3-1_amd64.deb' contains ununderstood data member data.tar.xz     , giving up14:42
lamontthat's debootstrapping raring on a lucid box14:42
lamontand sounds like a dpkg-deb bug in lucid, albeit a feature request14:43
lamontand a bug against dpkg to s/ununderstood/nonunderstood/14:43
lamontI suspect that we don't want to call debootstrapping raring on precise "unsupported", so something gets a bug14:44
* xnox thought all /relevant/ lucid boxes had dpkg backported with xz patch.14:44
xnoxlamont: precise should be fine, as it does have .xz support in dpkg.14:44
lamontii  dpkg                                 Debian package management system14:44
lamont0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.14:44
lamontit's fully currnet14:44
lamontlucid, lucid-updates, lucid-security14:45
xnoxlamont: yeah, we didn't upload xz support into lucid backport. Only into prod-ppa or something like that.14:45
lamontso, iow, we didn't actually fix it for lucid. :(14:45
stgraberlamont: looking around, you want >=
lamontstgraber: that is not available to our customers14:46
lamontwhich package do I file the bug against that joe user cannot debootstrap raring on a lucid machine?14:47
xnoxlamont: can lucid bootstrap precise? & then bootstrap raring from that =))))14:47
* xnox hides14:47
lamontxnox: IOW, lucid is no longer supported?14:47
lamontalso, HARDY is still supported, no?14:47
xnoxlamont: it is, on the server & what not. https://wiki.ubuntu.com/Releases14:48
stgraberxnox: lucid should be able to bootstrap precise, yes.14:48
xnoxlamont: lucid until April 2015 (Server), hardy until April 2013 (Server).14:48
stgraberlamont: the right package to file a bug against would be dpkg14:48
xnoxlamont: but you are asking for new features, not "support".14:48
stgraberlamont: does lucid's debootstrap even know what raring is?14:49
lamonttrue enough14:49
lamontI'll file the bug against dpkg and we'll see where it goes14:50
stgraberls: cannot access /usr/share/debootstrap/scripts/raring: No such file or directory14:50
stgraberthe most recent release in lucid's debootstrap is precise14:50
stgraberwhich is the last one that's guaranteed to work14:51
lamonteveryone knows that's just a matter of ln -s gutsy /usr/share/debootstrap/scripts/raring14:51
lamontI'll include that little tidbit in the bug for purposes of full disclosure14:51
stgrabersure, just wanted to confirm that we're not shipping something that's broken (an SRUed debootstrap with the raring symlink) :)14:51
lamontI have 1.0.39~0.IS.10.0414:52
* lamont shames14:52
xnoxstgraber: /me ponders if can be rebased on top of 4.6 and published somewhere (ppa or backports)14:52
stgraberxnox: well, it should probably be rebased on 4.6, yes, as it seems to be currently held to the by puppet to avoid loosing the required features14:53
stgraberpushing to a PPA should be fine, not sure it matches the backports policy as it's not an actual full backport14:54
xnoxScottK: can we "cherry-pick" a feature into lucid-backport? (dpkg xz support in lucid, without bringing a full new dpkg)14:56
lamontgenerally speaking, in the case of dpkg, if we backported a higher rev of it, it was because either (1) we had to, or (2) it was invasive enough that the gods of distro promised us that they were pretty sure it wouldn't regress anything (though I belive that said promise is specifically not intended to be sufficient for the purposes of this channel)14:56
ScottKGenerically, a cherry pick is fine.14:57
lamont[do you like all that handwaving non-promise in (2)?]14:57
ScottKSpecifically, any dpkg backport would have to have significant testing.14:57
xnoxlamont: are you after "make it work" (with ppa/backports/whatever) or are you after "it should be SRUed into lucid" (which will not happen as far as I can see)14:58
ScottKxnox: Also, I don't remember if lucid backports is NotAutomatic or not.  If it is, then that makes this less concerning.14:58
lamontxnox: the current state is that before the porterbox gets any new chroots, it'll have to upgrade to precise14:58
xnoxScottK: the xz cherry pick in question is extensively tested by a few production machines.14:58
Laneynotautomatic is natty14:58
xnoxlamont: why can you not pin ISPATCHED.10.04 version?14:59
lamontxnox: hence it's actually me wearing my coredev hat going "da&*^*(it this should work"14:59
lamontxnox: well, I could trivially add the suite so that we get the ISPATCHED version14:59
lamontOTOH, ISTR that machine should get scheduled for a precise upgrade anywya15:00
xnoxprecise is the way to go....15:00
lamontthere's a schedule, and then there are the "this doesn't work on lucid, works on precise, ok" escalations to the head of the schedule15:01
lamontso s/get/be/ in my prior statement15:01
xnoxlamont: yeah.... if it can linger another year there will be a new LTS =)))))15:02
* xnox remembers upgrading potato machine all the way to squeeze without reboots =) that was fun.15:03
xnoxonly had to fetch a couple of packages from snapshots to do lockstep upgrade but overall it was fine.15:03
lamontI'm not entirely sure that "without reboots" is an option these days15:03
xnoxlamont: heck I didn't even fully dist-upgraded to the intermittent release =)15:04
lamontthat would be an interesting test for someone: does the hardy -> lucid -> precise -> quantal (and maybe -> raring) path require reboots at any point in the path?15:04
lamontI remember crosgrading sarge(?) to warty.  that was a wonderfully crazy time15:04
* xnox is pondering about crosgrading to x32, when we get it ;-)15:05
xnoxthe crazy 64bit machine with 32bit long pointers.15:07
cjwatsonmm, IMO we should backport the dpkg xz patch to lucid-proposed; I'm pretty confident in standing behind it by now15:31
cjwatsonbut not going to do so today15:31
* ScottK likes that plan.15:36
xnoxinfinity: https://launchpad.net/ubuntu/+source/cunit/2.1-0.dfsg-10ubuntu1 can you make it build faster? =)23:31
infinityxnox: Your debian/rules changes don't seem to be accounted for in the changelog...23:33
xnoxinfinity: and?! =) it's not an SRU and the preferred way to do autoreconf.23:34
infinityxnox: Sure, but you're submitting this to Debian, right?  (That was the other condition of the MIR)23:34
xnox*sigh* /me missed that bit.23:35
infinityPretty sure we don't want to end up maintaining this when we haven't been so far.23:36
infinityWhich was the point. :)23:36
xnoxinfinity: well I can do a more minimal fix. drop the "-ansi" flag and not add checks for c99, but imho I'm not sure what's best to do here. Minimal wise.23:36
xnoxjust ignore the "implicit declaration of snprintf" warning from the compiler and get on with things?23:37
infinityIgnoring implicit declarations is generally never the right thing to do.23:37
infinitySo, no, I'm okay with more intrusive and correct fixes, but they should go to Debian and get a second set of eyes.23:37
xnox(snprintf is not in ansi (C90) only in C99, yet upstream currently builds with -ansi & uses snprintf)23:38
* xnox has a stack of patches to push to debian from recent FTBFS fixes.....23:38
infinityYeah, upstream's clearly wrong about their target C.23:39
infinity(Though, with no switches/defines, you'll end up with C11, not C99, so your changelog is still a lie)23:39
infinityNot that C11 is a bad idea. :P23:39
infinity(I love that we stuck with two digit dates for that, and 11 << 99... NOT CONFUSING AT ALL)23:40
xnoxinfinity: I added AC_PROG_CC_C99 which defines C99 for a given compiler, if it supports it.23:41
infinityAhh, right, missed that bit.23:41
* xnox liked C0x23:42
xnoxinfinity: but that macro is not available in autoconf2.59 ...... hence autoreconf to a brave new world.23:42
infinityxnox: Just dropping -ansi would likely be fine too.23:43
infinityxnox: Your fix is more complete for upsteam, mind you, if they care deeply.23:43
infinity(Personally, I think people who insist on targetting a specific C standard instead of just keeping current are Doing It Wrong, but whatever)23:43
* xnox tries to recall last upstream commit - was it in this century?23:43
xnoxinfinity: well it's a unit-test framework for C, any C, hence the original goal to target lowest one..... a bit of a fail with a single call to snprintf.23:44
infinityOh, fair point.  The other solution could be to not call snprintf. :P23:45
xnoxyeah, could do that. but sprintf is "less safe".23:48
infinitySure is.23:49
infinityBut our fancy overflow detection should catch that anyway, I would think?23:49
infinityOf course, if they're doing tricky things with snprintf's return, that would need rethinking.23:50
xnoxno, they don't. Where can I learn about overflow detection?23:50
infinityActually, I'm only assuming that sprintf gets covered by FORTIFY_SOURCE, but I suspect it does.23:53
infinityYeah, it does.23:54
infinityNot that snprintf isn't still saner, but if they really want to be targetting C89, it makes some sense to fudge it...23:55
infinityAnd fudging it by calling a function that may not be defined isn't the right answer. :P23:55

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!