[01:12] <TheMuso> ~/c
[03:52] <un214> just discovered leaving the grub packages in a chrooted system is a good way to fry the host
[06:12] <pitti> Good morning
[06:15] <ion> rning
[07:18] <pitti> zul: mysql question for you in https://bugs.edge.launchpad.net/ubuntu/+source/mysql-dfsg-5.1/+bug/608423/comments/6
[08:06] <dholbach> good morning
[08:06] <ion> that
[10:01] <LucidFox> Wow, I didn't know Upstart was used in so many systems now
[10:24] <diwic> How do I create a symlink (inside a make install target) that works in a .deb?
[10:26] <diwic> E g, the following does not work: ln -s $(DESTDIR)$(PREFIX)/dir1/file1  $(DESTDIR)$(PREFIX)/dir2/file2 - because when the deb is installed, the symlink will point to /buildd/debian/somewhere
[10:29] <TheMuso> diwic: You can use debian/packagename.links to create symlinks
[10:29] <TheMuso> man dh_link
[10:30] <diwic> TheMuso, thanks, I'll try that
[10:30] <TheMuso> np
[10:32] <azeem> diwic: in general, do relative symlinks
[10:33] <lool> cjwatson: ssh-import-lp-id man page mentions ssh-import-id in synopsys; mind fixing that in the packaging repo?  I'm too lazy to bug this
[10:33] <lool> Oh actually might not be a bug
[11:01] <Laney> It does say "ssh-import--id(1)" at the top though (two dashes)
[11:39] <soren> diwic: Leave out the $(DESTDIR) bit in the first argument, and you're golden.
[12:06] <diwic> soren, thanks. I think I tried that, but perhaps I removed it from the wrong path. Anyway, TheMuso's solution worked.
[12:48] <zul> pitti: *sigh* ok :)
[13:18] <pkramerruiz> Hi everyone!
[13:18] <pkramerruiz> Can anyone tell me if the developers of "software-sources" have an channel-sources?
[13:18] <pkramerruiz> Cause I want to run the process for selecting the best Mirror server, every time before making an update to some program, for obtain more speed downloading
[13:27] <zul> pitti: fixed
[13:33] <Chipzz> pkramerruiz: that would be pointless, since you would be running apt-get update each time, which would pull in several MB in itself
[14:28]  * apw is hearing rumours that the maverick CDs live dailies are borked at the moment, syslinux errors
[14:44]  * apw confirms that the i386 image is unbootable ... 'Unknown keyword in configuration file'
[14:56] <apw> pitti, it seems that maverick isos have the wrong version is SYSLINUX installed on them ... they are booting and indicating 3.63, but the version in maverick is 4.01
[14:56] <apw> i am suspicous that the config file has been updated to the new format, but the binary somehow not
[14:58] <pitti> zul: rejected mysql; it seems $ret is not initialized to '0' on success, and you need to upload with -v
[14:59] <pitti> zul: i. e. if $x is undefined, I get
[14:59] <pitti> $ LANG= [ $x -eq 0 ]
[14:59] <pitti> bash: [: -eq: unary operator expected
[14:59] <zul> pitti: k thanks
[15:00] <apw> pitti, who owns the generation of the maverick isos ?
[15:00] <pitti> apw: usually cron
[15:00] <pitti> apw: hm, not sure how syslinux comes into play here
[15:02] <apw> pitti, somehow the version on the images is out of step with the archive.  though the real issue is that the verson on there does not understand the configuration file built for it while building the iso ... so it errors out and does not boot
[15:02] <apw> its not clear how long the iso's have been broken
[15:03] <pitti> they kept failing to build quite often, too
[15:03] <pitti> kernel changed often, before langpacks rebuilt, etc.
[15:03] <pitti> not that easy to get something installable :)
[15:05] <apw> pitti heh .. typical
[15:06] <apw> pitti, so do we normally defer to mr. watson on this stuff ?  i think he is away
[15:06] <pitti> right, he's on holiday
[15:07] <apw> t'is a worry with a-3 fast approaching
[15:10] <ion> pitti: I prefer the paranoid style in sh programming: put *all* variable references in quotes, unless there’s a reason not to. :-)
[15:11] <pitti> ion: right, but it'd break either way
[15:11] <pitti> if $x is empty, [ "$x" -eq 0 ] still errors out
[15:11] <ion> Yeah, but the error would be about an illegal number, not a missing operand. :-)
[15:11] <pitti> apw: hm, I don't see anything relevant on http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/maverick/daily-live-20100727.log
[15:12] <pitti> and I don't see how it should be the livefs; syslinux should be a matter of the actual .iso build
[15:13] <apw> pitti, i assume there is some floppy which is combined with the live fs to make its an el-torito bootable what-sit
[15:13] <ogra> apw, right, thats what debian-cd does
[15:14] <apw> ogra, ok what makes the contents of the flippy ?
[15:14] <ogra> it pulls the livefs from the live builder and creates an iso around it
[15:14] <ogra> there is no "floppy" :)
[15:14] <ogra> its just syslinux copied into an iso or vfat
[15:14] <apw> ogra, ok but to make a bootable CD you have to supply a floppy don't you?  in the CD and magic point to it
[15:15] <ogra> no
[15:15] <apw> ogra, to re-cap.  maverick CD's stopped working sometime recently
[15:15] <ogra> you just copy the isolinix or syslinux binaries into the image file
[15:15] <apw> the issue looks to be a configuration issue for syslinux, which is oddly an older version
[15:15] <apw> 3.63 from lucid and not the one from maverick
[15:15] <ogra> right, it might be that the debian-cd scripts pull from the host machine
[15:15] <ogra> which would get you the hardy version
[15:16]  * pitti found ~/cdimage/debian-cd/tools/boot/maverick/boot-{i386,amd64} now, looking
[15:16] <ogra> right
[15:16] <ogra> thats the script
[15:16] <apw> so i wonder if its meant to be updated and the config in maverick is matching the new one
[15:16] <apw> ogra, its the one from lucid it seems
[15:16] <apw> BUT its possible the host was updated from hardy to lucid ...
[15:16] <pitti> apw: is that isolinux.cfg?
[15:16] <apw> i know one of our machines was so upgraded recently
[15:17] <apw> pitti, i am unsure, though if you have that i'd say so
[15:17] <ogra> ogra@antimony:~$ lsb_release -a 2>/dev/null|grep Code
[15:17] <ogra> Codename:	hardy
[15:17] <apw> ogra, ok the one on there is 3.63, which seems to be lucid level
[15:17] <ogra> right
[15:18] <apw> pitti, actualy isolinux sounds wrong
[15:18] <ogra> i gues there is some code missing to pull the maveric one into the image
[15:18] <ogra> isolinux is right for the isos
[15:18] <ogra> otherwise its syslinux for the vfat images
[15:18] <apw> pitti, oh but it does seem to be so
[15:18] <apw> syslinux.cfg/isolinux.cfg:
[15:18]  * pitti defers to ogra then; NFC about this stuff, and I'm betwen two meetings now
[15:18] <apw> is mentioned in the source for syslinux
[15:19]  * ogra hasnt any clue about the sys/isolinux changes either
[15:19] <ogra> but i'll take a look at the code
[15:19] <pitti> didrocks: ^ that just means that you can't get a (working) respin of the CD
[15:19] <apw> both packages were changed a long time ago, weeks in both cases
[15:19] <pitti> didrocks: I advise to take the alpha-2 image with a persistency file and upgrade packages in-place
[15:20] <didrocks> pitti: urgh, this ISO for Guadec sounds like a malediction :(
[15:20] <didrocks> ogra: pitti: yesterday's iso has the same iso?
[15:20] <didrocks> issue*
[15:22] <ogra> apw, colin changed the code on friday
[15:22] <apw> ogra, to ?
[15:22] <apw> i mean which bit did he change ?
[15:22] <apw> which package
[15:22] <ogra> making i386 and amd64 use syslinix-coomon instead of syslinux
[15:22] <ogra> *common
[15:22] <apw> hrm ...
[15:24] <ogra> apw, http://paste.ubuntu.com/469833/
[15:26] <apw> ogra, syslinux-common only exists in maverick ... but the version number reported on actual boot isn't that new one (4.01)
[15:26] <ogra> well, the code seems to pull syslinux-common from maverick
[15:26] <ogra> which was the last usable image ?
[15:27] <apw> ogra, yeah ... which may well make sense... except ... they say 3.63 when booting
[15:27] <ogra> there were some changes before ... though they dont touch syslinux code directly
[15:27] <apw> ogra, last one i booted was the 5th so i am not much use
[15:27] <ogra> hmm
[15:28] <ogra> well, its hard to tell which change broke it if i dont know the date
[15:28] <ogra> there is some new code that makes use of gfxboot.c32
[15:28] <apw> ogra, yeah only came to my attention today, do we keep any older ones?
[15:29] <ogra> 3 days of successfull builds usually
[15:30] <apw> ogra, so they would all be after the last change ... hrmph
[15:30]  * apw asks arround ... to find out who last booted one and when
[15:31] <ogra> is syslinux-common in main already ?
[15:32] <apw> ogra, how does one tell, the source claims to be in main
[15:33] <hallyn> to make a sync request, can i subscribe 'ubuntu-release' to the original bug, or should i file a new bug referencign the original (fixed) bug?
[15:33] <ScottK> apw: rmadison will tell you at least for non-ports archs.
[15:33] <apw> ogra, though from the binary he is trying to extract i'd be supprised if its in the -common file
[15:34] <ogra> apw, he pulls isolinux.bin, vesamenu.c32 and gfxboot.c32 out of that package
[15:35] <apw> ogra, and they do indeed seem to be in there somewhat supprisingly to me
[15:38] <superm1> apw, pitti: is the problem only present in maverick builds installed to usb with a lucid usb creator?
[15:38] <superm1> eg maverick isos directly on a cd or in a vm work fine
[15:38] <apw> superm1, i have put the iso on a grub booted disk and they boot there
[15:38] <ogra> apw,   * Adding recommends to libcrypt-passwdmd5-perl in syslinux-common   (Closes: #567649).
[15:39] <ogra> from the syslinux changelog
[15:39] <ogra> libcrypt-passwdmd5-perl is in universe
[15:39] <apw> i would expect the issue to affect every use model of an ISO though
[15:39] <apw> ogra, ok ... what would that mean
[15:39] <superm1> bug 608382
[15:39] <apw> that its not usable, and we fall back to an older one ?
[15:39] <apw> superm1, yes thats the error we are chasing
[15:40] <ogra> apw, thats what surprises me, i wouldnt expect it to fall back to anything but fail the image build
[15:40] <superm1> syslinux gets installed to the key from the usb-creator on the system, so the version in lucid is older than that in maverick
[15:40] <superm1> and hence doesn't support the new 'ui' keyword
[15:40] <apw> superm1, OH
[15:40] <apw> hrm
[15:40] <apw> so this is a bug in the usb-creator only ?
[15:41] <apw> ogra, ^^
[15:41] <apw> i'll try making a CD to confirm
[15:41] <ogra> apw, ah, that might be, try a real iso to confirm ;)
[15:42] <apw> making plastic now
[15:42] <superm1> if you use usb-creator on a maverick system it should in theory work fine (or if you backport syslinux to lucid)
[15:42] <apw> superm1, i can also try that combination
[15:42] <apw> though that is poor
[15:42] <apw> a backport seems more appropriate
[15:43] <superm1> well backporting it would cause usb-creator to fail to make lucid keys on lucid (beware)
[15:44] <apw> superm1, HRMPH
[15:44] <didrocks> I have the current iso which will be synced in 30 minutes, I'll try usb-creator there
[15:44] <apw> didrocks, thanks
[15:45] <pitti> didrocks: you could temporarily install maverick's syslinux for making the stick, I suppose?
[15:45] <didrocks> pitti: I'm already on maverick on my netbook, so, should be fine there, isn't?
[15:45] <pitti> ah, right
[15:45] <apw> pitti, this is a bit of a disaster :/
[15:46] <apw> so is the isolinux.cfg within the image ?
[15:46] <apw> but usbcreator uses a local binary to make the stick versiion?
[15:46] <ogra> yes, but i have no idea if usb-creator rewrites it
[15:46] <apw> perhaps we should be sucking it out of the image
[15:47] <apw> sounds like a bug in usb-creator rahter than anything else
[15:47] <ogra> usb-creator should use both from the image file
[15:47] <apw> yeah
[15:47] <ogra> but iirc it wasnt possible to just replace isolinux with syslinux before
[15:50] <apw> ogra, ok confirmed the real iso has 4.01 on it and boots as expected
[15:50] <apw> so this is not an image issue, panic off :)
[15:50] <ogra> phew
[15:51] <ogra> file a bug :)
[15:51] <apw> the bug is there already
[15:51] <ogra> oh, k
[15:51] <apw> just updatinging it now and adding a new task on usb-creator
[15:51] <ogra> file a patch then :)
[15:51]  * apw needs to find the author and rattle them
[15:51]  * ogra points apw to ev
[15:52] <superm1> an alternate way to solve this might be to set a fallback if gfxboot fails
[15:53] <superm1> so lucid and earlier users would see a different bootsplash screen that's more texty, but functional
[15:53] <apw> yeah though that makes the sexy installer less sexy
[15:53] <superm1> or even make lucid and earlier boot directly to installer and just not give them a menu
[15:55] <ev> branches welcome on usb-creator using syslinux from the ISO.
[16:10] <didrocks> ogra: pitti apw: just confirming that it works well with last nebook ISO and maverick usb creator
[16:10] <apw> ev, are the bits you need even on the CD ?
[16:10] <didrocks> pitti: can you make an UNE respin once unity is built so?
[16:11] <pitti> didrocks: sure
[16:11] <didrocks> pitti: thanks a lot!
[16:12] <ev> apw: the manifest says we have syslinux in the squashfs, yes.
[16:12] <apw> ev, ok so it should be possible to fix this using the image ...
[16:12] <ev> apw: correct
[16:13] <ev> it just requires someone to do it, and all my time is going to the installer redesign at the moment
[16:13] <ev> so, someone else :-P
[16:13] <ev> to finishing the*
[16:13] <apw> ev, pitti, ok i am getting further happy confirmations that using maverick to make the usb images of maverick boot just fine
[16:14] <apw> so at least we have a work-arround
[16:14] <apw> ev ack
[16:14] <superm1> aren't you running into similar problems if you are loop mounting the squashfs to get syslinux out?  you would need to match versions still
[16:14] <superm1> (match versions of squashfs that is)
[16:14] <ev> how so?
[16:15] <superm1> try to loop mount a maverick squashfs on a hardy kernel (or something oldish) and you'll see that it complains that the squashfs major/minor doesn't match
[16:15] <ev> ah
[16:16] <ev> damn
[16:16] <superm1> also you wouldn't be able to burn amd64 cds to usb sticks on 32 bit systems anymore since you couldn't run the syslinux binary from that squashfs
[16:17] <ev> right, indeed
[16:17]  * ev ponders if the eventual switch to grub2 buys us anything here
[16:18] <superm1> it'll probably be worse actually
[16:18] <superm1> at this point you can come up with hacks/workarounds for fallbacks in syslinux i believe
[16:19] <ev> yeah, seems like the fallback approach you suggested above is our only real option
[16:29] <shtylman> is there a reason that neither the xulrunner nor xulrunner-dev package create a libmozjs symlink in /usr/lib? one has it under the /usr/lib/xulrunner-1.9.2/ folder and the other in an sdk folder... what is the proper path to search for when linking against mozjs then?
[16:30] <apw> ev, well we could consider changing the ISO to contain the file we need (its only one right and tiny) in the un-squashed bit of the image
[16:31] <superm1> another alternate more hacky solution might be an SRU to older usb-creators to detect newer cds and s/ui\ gfxboot/gfxboot/
[16:31] <apw> yeah
[16:31]  * apw goes confirm that its just the mbr which is an issue
[16:34] <apw> ahh no we do run syslinux too ... so we'd fail there too ... bah
[16:44] <apw> superm1, i suspect your hacky solution is a 'fair' one for the moment
[16:45] <mkarnicki> It there a nice way to write binary masks in java? Should I use hex values, binary shift operator, or just 1, 2, 4, 8.. values?
[16:45] <mkarnicki> Argh, forgot to say Hi :)
[16:46] <apw> mkarnicki, for C i have always uses (1 << N) for bit N
[16:46] <apw> i assume java has the same semantics
[16:46] <mkarnicki> apw: same here, but I'm not sure what's the Java-fu or JAva-way of doing this :)
[16:47] <mkarnicki> apw: I'll use 1 << n for time being
[16:47] <mkarnicki> apw: thanks
[16:58] <apw> superm1, i've tested your sed incantation and it seems to work for this particular purpose
[16:58] <apw> so i've recorded it as a work-arround in the bug
[17:00] <ogra> we just need to copy the binaries into the vfat or the iso
[17:00] <ogra> that way you cant hit squashfs issues
[18:18] <geser> Riddell: are still removals in Debian unstable regularly "imported" into Ubuntu or should removal bugs get filed?
[18:19] <Riddell> geser: I guess I can do removals today
[18:26] <ansgar> To get a package imported from Debian that does not yet exist Ubuntu, should I just fill a sync request as usual?
[18:28] <geser> ansgar: yes
[18:39] <andreoli> Hi, i'd like to build my own modified ubuntu kernel package and host it through a PPA, Can I blindly follow https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage ?
[18:40] <Riddell> tjaalton: can libxxf86misc be removed?  it's gone in debian
[18:40] <andreoli> to supersede the official ubuntu name, is it sufficient to rename the package name by adding a ppan suffix? Or do I have to fiddle with files in the debian directory?
[18:41] <andreoli> Is this the right channel for *.deb and launchpad questions?
[18:43] <Riddell> andreoli: you can add a ppa suffix to the version number and that'll make it a newer version than the normal version
[18:43] <Riddell> andreoli: I believe there's a #ubuntu-packaging for packaging
[18:43] <andreoli> thx a lot
[19:00] <tjaalton> Riddell: if there are no reverse-deps left, then yes
[19:08] <zul> pitti: ping http://pastebin.ubuntu.com/469912/
[19:23]  * Riddell wonders if we want to follow debian in removing swfdec0.8 from the archive
[19:23] <maco> its about 18mo old isnt it?
[19:23] <maco> and while there've been commits to vcs since then, not many, and no new releases
[19:31] <pitti> zul: hm, where did the break go?
[19:31] <zul> pitti: i removed it...this might be a better solution
[19:31] <pitti> zul: but now you always ping 30 times
[19:32] <zul> pitti:good point
[19:33] <zul> pitti: at this point im open to suggests
[19:33] <zul> pitti: suggestions even
[19:34] <chrisccoulson> Riddell, i'm sure i remember rob savoye saying at UDS that swfdec is pretty much dead (although i might be wrong there)
[19:34] <chrisccoulson> and see here: http://lists.freedesktop.org/archives/swfdec/2010-January/002490.html
[19:34] <chrisccoulson> i don't think there's a reason to keep it in the archive really
[19:34] <pitti> zul: oh, hang on, "exec" -> that could work indeed
[19:35] <pitti> zul: I missed that
[19:35] <pitti> zul: at this point we know that $HOME/debian-start exists and is executable?
[19:36] <micahg> +1 for swfdec removal
[19:36] <zul> pitti: it should...if they didnt do any funky stuff while trying to uninstall mysql because they think its broken
[19:37] <pitti> zul: ah, it's mysql's $HOME, not any user's
[19:37] <zul> pitti: correct
[19:37] <rsavoye> swfdec is dead
[19:37] <pitti> zul: what sets mysql's $HOME here? upstart scripts are run as root?
[19:38] <rsavoye> they started shipping Gnash instwad of swfdec in GNOME
[19:38] <zul> pitti: lemme show you the whole upstart job
[19:38] <zul> pitti: http://pastebin.ubuntu.com/469922/
[19:39] <pitti> env HOME=/etc/mysql
[19:39] <pitti> ah
[19:40] <pitti> zul: ok, looks fine to me
[19:40] <zul> pitti: cool thanks
[19:40] <pitti> zul: "end scrip
[19:40] <pitti> -> cut&paste error, I presume?
[19:41] <zul> pitti: yeap cut&paste error
[21:20] <Sarvatt> Riddell: libxxf86misc and x11proto-xf86misc can both go - https://wiki.ubuntu.com/X/PackageNotes
[23:41] <RoAkSoAx> Hi all, I'm having a package that is FTBFS after updating my pbuilder (today) with "fatal error: ltdl.h: No such file or directory" . Any ideas why might this be?
[23:49] <TheMuso> RoAkSoAx: Sounds like you need to build-depend on libltdl-dev.
[23:50] <TheMuso> Without looking into it further, so thats at a glance at your error.
[23:50] <RoAkSoAx> TheMuso: yeah that's what I was thinking of, but what I wonder is why it was working yesterday and not today after updating my pbuilder
[23:51] <TheMuso> RoAkSoAx: no idea.
[23:52] <RoAkSoAx> TheMuso: Might it be because one of its build-deps requires libltdl3-dev? And i should amke a transition to libltdl7-dev?
[23:52] <TheMuso> Possibly
[23:54] <RoAkSoAx> TheMuso: thanks!