[05:27] <pitti> kees: thanks for adding me back
[05:27] <pitti> good morning
[05:34] <elmo> 0
[06:33] <cpatrick08> i think oneiric will be better than natty even in this very early stage of development it is better than natty
[06:49] <cpatrick08> is there any way to get the gnome-shell on oneiric
[07:11] <didrocks> good morning
[08:00] <mdke> does anyone have an idea what might be causing bug 788949. I've seen a couple of them for ubuntu-docs but have no idea what the dpkg error message means
[08:08] <geser> mdke: looks like the harddisk is dying if I read the dmesg correctly
[08:10] <mdke> geser: aha, what do I look for in there? I have a couple of other similar bugs that I need to check too
[08:12] <geser> mdke: see the lines with "sd 0:0:0:0" and "ata1.00" at the end of dmesg.txt where the kernel logs it unsuccessfull attempts to write something to the harddisk
[08:13] <mdke> geser: that's great, thanks a lot for the help
[08:30] <DktrKranz> mvo: hi! I checked your branch yesterday, it looks good. I also tested it with a GNOME3 box, and worked fine
[08:36] <mvo> DktrKranz: awsome, thanks a lot, sounds like a candidate for uploading then :) what is the state of the gir stuff in debian? is it in unstable yet or would this be experimental?
[08:37] <DktrKranz> mvo: still experimental, there are some pieces still to be fixed, and release team to assign a spot to schedule transitions
[08:38] <DktrKranz> probably, it won't happen before 3.2
[08:39] <DktrKranz> some pieces are in unstable, but at least not vte. so experimental is the only way right now
[08:45] <Laney> broder: No, I didn't. But it looked OK to me (since there are no rdepends and the reporter says he test it runs)
[08:45] <Laney> tested
[08:46] <mvo> DktrKranz: ok, thanks. that should be fine, I guess its best to push it in ubuntu first then so that it gets wider testing (but I feel its pretty solid)
[08:56] <micahg> good morning pitti, would you be able to pocket copy chromium from -proposed to -security/-updates for lucid-natty, bug 787846
[08:59] <pitti> micahg: yes, can do
[08:59] <cjwatson> mdke: I've no idea why we still file bugs for "Input/output error" - it's defined to mean physical read/write errors, i.e. almost exclusively not software bugs
[08:59] <micahg> pitti: thanks
[09:00] <DktrKranz> mvo: sounds good. we could also asking for testing via planet debian, I see it attracts more people
[09:00] <cjwatson> I assume it's simply because at the apport level it's awkward to figure out reliably which errno was involved, e.g. due to translations
[09:03] <pitti> micahg: all done
[09:03] <micahg> pitti: great, thanks, have a good day
[10:03] <zaytsev> hi! does anyone know of the top of their head, how the livecd decides if it will autologin in casper or show the dialog "install or try ubuntu blah-blah-blah"?
[10:04] <cjwatson> zaytsev: the 'maybe-ubiquity' boot parameter causes the latter to happen
[10:04] <zaytsev> I am trying to remaster the official natty livecd as per LiveCDCustomization wiki page and everything was fine, but now I updated the packages in the chroot and somehow the resulting image autologins without showing this standard window
[10:05] <zaytsev> cjwatson, oh, thanks! it means that somehow I unknowingly changed the boot options :-/
[10:07] <cjwatson> zaytsev: our gfxboot theme adds 'maybe-ubiquity' if it's booting in splash mode, which happens if 'hidden-timeout=1' is in /isolinux/gfxboot.cfg
[10:07] <cjwatson> it's a bit convoluted, I'm afraid
[10:08] <infinity> Just a tad...
[10:08] <infinity> I know how it works, and that still confused me. :P
[10:08] <cjwatson> it confuses me and I wrote it
[10:08] <zaytsev> oh right, so I have hidden-timeout=2 in gfxboot.cfg, I didn't change it though. It was like this in the official media.
[10:09] <cjwatson> =2 should be fine too
[10:09] <StevenK> infinity: What's wrong with Canadian lamb? :-)
[10:09] <infinity> StevenK: A general lack thereof.
[10:09] <infinity> StevenK: Canadian ranchers are silly and keep letting them grow up.
[10:09] <infinity> StevenK: And mutton is crap.
[10:09] <cjwatson> zaytsev: also I don't think it will take you into the try/install dialog if you press a key at the CD boot splash screen to get the boot menu
[10:13] <zaytsev> nah, I didn't press a key and still it autologins :-/ I am trying to boot my kvm test vm off the official media and it shows the prompt. when I do the same with my remastered one it doesn't. and now that I sort the files by date the only thing that really changed is the chroot which I updated with the latest packages from natty-updates. what a looser...
[10:14] <cjwatson> zaytsev: you could just hardcode maybe-ubiquity into the kernel parameters
[10:14] <cjwatson> (kind of wrong, but whatever)
[10:15] <fta> doko_, hi, here are my ld-gold results: http://paste.ubuntu.com/613663/
[10:16] <fta> doko_, i wonder if it has to do with the PIE hardening
[10:16] <doko_> fta: ok. please cc kees on hardening issues too
[10:22] <apw> ev, are you aware that usb-creator-gtk is now triggering 4-5 "not permitted by policy" popups per install ?
[10:23] <zaytsev> cjwatson, so I should add maybe-ubiquity to the first (default) boot option in /boot/grub/loopback.cfg ? and how to reliably achieve the opposite effect, is there something like no-ubiquity ?
[10:23] <zaytsev> the thing that bugs me here is that I updated the chroot and now it autologins. tomorrow I will do this again and it will show ubiquity instead. I would kind of like a defined behavior.
[10:25] <ev> apw: yeah, it was to fix a security issue.  I plan to dig into making it less of a pain in the ass a bit later in the cycle
[10:25] <apw> ev, eek
[10:27] <cjwatson> zaytsev: wait, you're using grub to boot this?
[10:28] <zaytsev> cjwatson, I have no idea :-) I have downloaded the original image and use whatever it uses. then I found an article on Ubuntu wiki how to unsquashfs the filesystem and make your customizations (install/update packages). then I remastered the image again using the updated chroot
[10:29] <zaytsev> also, the difference is that when the image that boots to ubiquity starts, it changes purple background to black and yellow letters and when it autologins directly it stays purple
[10:30] <cjwatson> zaytsev: /isolinux/isolinux.cfg, then
[10:30] <cjwatson> zaytsev: if I were you, rather than just comparing file lists, I would loop-mount the old and new images and use 'diff -ru' to compare them
[10:30] <cjwatson> one of the changes listed by that will be responsible
[10:31] <zaytsev> cjwatson, in isolinux.cfg I would just add a line that says maybe-ubiquity ?
[10:31] <infinity> diff -ruN even, could be a new file poviding an override to something.
[10:31] <zaytsev> cjwatson, ok, reasonable I will do that. thanks.
[10:33] <cjwatson> zaytsev: sorry, I meant /isolinux/txt.cfg.  change the 'append' line corresponding to the relevant menu label.  (but analyse the image with diff first; this is just a fallback option for if you can't find what changed.)
[10:34] <private_> I am looking for a programmer to hire to clean up some code
[10:37] <zaytsev> hmm, manifests are different (updated packages), filesystem size, filesystem AND /isolinux/isolinux.bin has a different checksum. weird.
[10:40] <zaytsev> and compared to the original image, there are even more differences. I wonder it it's rsync's fault, maybe I called it with the wrong flags. ok, will try to figure after lunch
[10:42] <zaytsev> actually, it seems that the md5sum generation command is wrong
[10:43] <zaytsev> find -type f -print0 | sudo xargs -0 md5sum | grep -v isolinux/boot.cat | sudo tee md5sum.txt <--- should be grep -v isolinux, because the original md5sum doesn't include any of the isolinux stuff.
[10:44] <zaytsev> https://help.ubuntu.com/community/LiveCDCustomization
[10:45]  * doko_ looks away from NBS
[10:52] <jibel> pitti, are these files useful on the ISO ? http://paste.ubuntu.com/613655/
[10:52] <jibel> pitti, The raw size is 25MB but that would save something like 3 to 4MB of CD space
[10:52] <pitti> jibel: apt lists are, I think
[10:52] <pitti> 4.3M 2011-05-27 10:22 srcpkgcache.bin
[10:53] <pitti> that's something I keep asking mvo about
[10:53] <pitti> we just ditched it in a project, and it doesn't seem to be very useful
[10:53] <pitti> but I keep forgetting why we need it
[10:53] <jibel> *bin files are regenerated on first run of apt
[10:54] <pitti> right, we could remove it from the CD certainly
[10:54] <pitti> and I think the dpkg -old files can certainly go
[10:55] <pitti> jibel: thanks for pointing these out!
[10:55] <jibel> and apt list files are regenerated on first run of apt-get update.
[10:55] <pitti> these are pretty much "nice to have", if you do an apt-get install etc.
[10:55] <pitti> in the live system
[10:56] <didrocks> maybe we can run an apt-get update as soon as internet is available?
[10:56] <didrocks> on the live/ubiquity
[10:56] <didrocks> (well s/internet/any network/)
[10:57] <jibel> if you don't have an internet access you only need cd rom list, if you have one we can run an update at some point
[10:57] <pitti> right
[10:58] <geser> hmm, if available-old is 1.3M, I guess available is around the same size. What was the purpose of available again?
[10:58] <jibel> and since the update timestamp on the CD is far behind the time the user actually uses the CD, update-manager will propose to run a check anyway
[10:58] <cjwatson> jibel: that's already going away with live-build
[10:58] <cjwatson> (pkgcache.bin etc.)
[10:58] <cjwatson> no point analysing the current CD
[10:58] <cjwatson> the -old files go away with live-build too
[10:59] <pitti> nice
[10:59] <jibel> cjwatson, oh cool, not analyzing the CD, just playing with the freshly backed isos, and found this.
[11:05] <superm1> cjwatson, there's a plan to switch to live-build for this cycle?
[11:06] <cjwatson> yes
[11:07] <cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-live-build
[11:07] <ohsix> is live build cooler than casper and sealing up your own images
[11:07] <cjwatson> live-build and casper are apples and oranges
[11:07] <ohsix> ok
[11:08] <ohsix> last time i looked it was casper, dunno what's on live images now
[11:08] <superm1> ah v. good thanks.
[11:08] <cjwatson> ohsix: casper stays where it is.  live-build replaces livecd-rootfs.
[11:08] <ohsix> i see
[11:09] <cjwatson> as would be clear if you'd looked at my URL
[11:10] <ohsix> did
[11:10] <ohsix> no idea what role that stuff plays, going to read about livecd-rootfs
[12:36] <zaytsev> cjwatson, Binary files image-orig/isolinux/boot.cat and image-new/isolinux/boot.cat differ, Binary files image-orig/isolinux/isolinux.bin and image-new/isolinux/isolinux.bin differ, is that normal when re-generating the ISO file?
[12:37] <zaytsev> I checked up on isolinux.bin and it shows one bit flipped: http://paste.ubuntu.com/613701/
[12:37] <zaytsev> are these cosmic rays or what?
[12:38] <cjwatson> I think it probably depends on your installed syslinux(-common) packages
[12:39] <zaytsev> oh, I'm on maverick, and re-generating image from natty, but I'm just using mkisofs, I don't even have syslinux installed. I'm not doing the bootstrapping from scratch
[12:42] <zaytsev> and also same 82 -> 83 byte flipped in boot.cat
[12:43] <cjwatson> I don't know if that's relevant, anyway
[12:43] <cjwatson> it may just be because the rest of the ISO is different and so mkisofs needs to fiddle with the catalog
[12:43] <zaytsev> I think it's mkisofs, because the file has the modification date is when I ran it
[12:45] <cjwatson> I doubt it's relevant to your problem
[12:49] <zaytsev> well, all the other changes that diff picked up are in package lists (updated packages) and squashfs file system
[12:50] <zaytsev> so it can only be the file system, but that's a bit big to diff :-(
[12:58] <zaytsev> ok, I added append  file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/casper/initrd.lz quiet splash maybe-ubiquity -- to live
[12:58] <zaytsev> it still logins directly
[12:59] <cjwatson> are you sure you still have ubiquity in your squashfs?
[12:59] <cjwatson> (at this point, I would loop-mount the squashfses and diff them, particularly /etc)
[12:59] <zaytsev> and when I press esc on boot it shows my modified commandline. so this is fine.
[13:00] <zaytsev> no I am not sure, although I didn't remove it. will do as you say. thanks.
[13:03] <zaytsev> diff -Naur on etc only revealed differences in fs-old/etc/ld.so.cache fs-new/etc/ld.so.cache... hmmm. will do whole fs.
[13:09] <zaytsev> hopeless, there was a libreoffice upgrade, so the diff is polluted by 200 mb of binary files :-(
[13:09] <mdeslaur> @pilot in
[13:14] <zaytsev> here are the updated packages: http://paste.ubuntu.com/613720/ ... I don't see anything dangerous in here.
[13:15] <zaytsev> could it have to do with motd? I changed the motd.
[13:18] <cjwatson> no ...
[13:19] <zaytsev> is there like a way to debug stuff?
[13:20] <zaytsev> I now see it's being launched by upstart
[13:20] <zaytsev> the file /usr/bin/ubiquity-dm is in place
[13:21] <zaytsev> ok, I have an idea of what could have gone wrong
[13:22] <zaytsev> maybe it's initctl, there was an advice to add a diversion on the wiki, maybe I screwed it up
[13:22] <cjwatson> you'd certainly need to undivert that at the end of the build
[13:23] <zaytsev> I'VE GOT IT~!, it's initctl. somehow in the new image it doesn'
[13:23] <zaytsev> exist anymore at all. maybe I ran some command twice
[13:23] <zaytsev> many thanks for all your help
[13:23] <zaytsev> I learned a lot
[13:24] <cjwatson> glad you got it sorted
[13:55] <fta> doko_, I tried ld.gold on natty without PIE, it still crashes.
[13:56] <tkamppeter> Any UDEV expert around? Is there some mechanism which removes files from /etc/udev/rules.d/?
[13:56] <tkamppeter> pitti, ping
[13:56] <pitti> hey tkamppeter
[13:56] <pitti> tkamppeter: how do you mean, mechanism? there are standard recipes for removing obsolete conffiles, yes
[13:57] <tkamppeter> pitti, what I do is connecting an HP LaserJet 1020 (the ugly thingy which needs firmware loaded).
[13:58] <tkamppeter> pitti, this triggers the command "sudo hp-plugin" to be run and this installs a bunch of fresh files into /etc/udev/rules.d/. You can try "sudo hp-plugin" manually and then see what you get in /etc/udev/rules.d/.
[13:58] <pitti> er,what?
[13:59] <pitti> an udev rule calls sudo?
[13:59] <pitti> no, I don't think I'll run a program like that
[13:59] <tkamppeter> pitti, probably the rule does it without sudo.
[13:59] <tkamppeter> pitti, the rule simply runs hp-plugin.
[14:00] <tkamppeter> pitti, now I check whether the newly installed rules in /etc/udev/rules.d/86-hpmud-hp_laserjet_1020.rules actually load the firmware into the printer.
[14:01] <pitti> hm, I only see /lib/udev/rules.d/56-hpmud_support.rules
[14:01] <pitti> tkamppeter: how does the file get there?
[14:01] <tkamppeter> pitti, these rules get installed if you run hp-plugin.
[14:01] <pitti> so we have an udev rule which calls hp-plugin which installs udev rules into /etc/?
[14:02] <tkamppeter> pitti, so run "sudo hp-plugin" on a console and you get the files.
[14:02] <tkamppeter> pitti, they get into /etc because HP does it this way.
[14:02] <pitti> can we please kill hp-plugin?
[14:03] <tkamppeter> pitti, and how do we support these printers then?
[14:03] <pitti> and perhaps just ship the sensible part of their rules directly in hplip, in /lib/udev/rules.d/
[14:03] <pitti> ?
[14:03] <tkamppeter> pitti, we must support rules in /etc, to support third-party software.
[14:03] <pitti> yes, but hplip is not a third-party software, it's an Ubuntu package
[14:04] <cjwatson> having udev rules themselves go around installing udev rules is a different matter, though!
[14:04] <pitti> which aren't supposed to install rules into /etc/udev/rules.d
[14:04] <pitti> and as such it shoudn't do crazy things like that
[14:04] <pitti> right, what cjwatson says
[14:04] <tkamppeter> pitti, but the proprietary driver plugin of HPLIP is a third-party software, as it gets installed separately.
[14:05] <pitti> tkamppeter: how is that related to the initial rules?
[14:05] <tkamppeter> pitti, the initial rules which we ship in /lib are 100% OK.
[14:05] <pitti> tkamppeter: what are the rules that hp-plugin installs doing?
[14:06] <tkamppeter> pitti, the rules which get installed by HP's proprietary plugin are doing the auto-upload of firmware into HP's cheapo lasers.
[14:08] <tkamppeter> pitti, the problem which I am experiencing is that these rules get executed once (the first time when I power-cycle the printer) and after that the rules file (only the one for my printer) gets removed.
[14:09] <geser> who removes them?
[14:09] <tkamppeter> geser, pitti, I do not know.
[14:10] <geser> hopefully not the script doing the firmware upload
[14:10] <pitti> can we stilll kill hp-plugin, or the part of it that does the crazy rules install?
[14:11] <cjwatson> nothing in the standard distribution should be removing files in /etc/udev/rules.d/.  However, given that you already have a crazy thing automatically installing rules into /etc/udev/rules.d/ (rather than using a single static rule which uses IMPORT or something to import properties from a program), all bets are off
[14:12] <pitti> tkamppeter: so, to get back to your original question, we certainly don't have a "standard mechanism" to remove any files from /etc, as this is EBW
[14:13] <tkamppeter> geser, pitti, the script gets removed exactly after its first use. After having run "hp-plugin" and completed the wizard I wait some seconds and power-cycle the printer. The printer loads its firmware and the /etc/udev/rules.d/86-hpmud-hp_laserjet_1020.rules is gone. All other 86-hpmud-hp_*.rules files stay.
[14:14] <pitti> so I guess the rules that it puts into /etc/ have a builtin auto-destruct and delete themselves?
[14:15] <tkamppeter> pitti, here is the rules file: http://paste.ubuntu.com/613748/
[14:16] <pitti> so, apart from them using an outdated syntax, it seems that /usr/bin/hp-firmware removes them?
[14:20] <tkamppeter> pitti, /usr/bin/hp-firmware is a Python program and I do not find anything in it which deletes the UDEV rule.
[14:23] <tkamppeter> pitti, I have copied 86-hpmud-hp_laserjet_1020.rules into /lib/udev/rules.d/ now and there it survives. I can do as many power-cycles as I want and the file survives and every time the firmware gets uploaded.
[14:26] <tkamppeter> pitti, is there a way to find out which program has deleted a file?
[14:28] <hallyn_afk> seriously, people, "Development is completed for the 'natty' version of Ubuntu, so you should use technical support channels unless you know for certain it should be reported here?' is not a question
[14:29] <Laney> what?
[14:32] <hallyn> kirkland: thanks for the quick byobu (uh, screen) fix :)  now lemme see if i can reliably reproduce it before upgrading
[14:33] <tkamppeter> pitti, still there?
[14:44] <pitti> tkamppeter: not retroactively; you could grep your entire file system for files which contain the name, though
[14:52] <geser> tkamppeter: try setting the rules file in /etc to immutable and check if something complains that it couldn't remove it
[14:52] <pitti> I thought nothing would remove it again?
[14:52] <pitti> and this is entirely after-the-fact debugging?
[14:53] <tkamppeter> geser, how does one set /etc/ to immutable?
[14:54] <geser> tkamppeter: not the whole directory but only /etc/udev/rules.d/86-hpmud-hp_laserjet_1020.rules
[14:54] <geser> sudo chattr +i /etc/udev/rules.d/86-hpmud-hp_laserjet_1020.rules (as long as the file exists)
[14:58] <tkamppeter> geser, the "chattr +i" actually protects the file, but I did not see any error. Nothing in syslog.
[14:58] <geser> hmm
[15:02] <geser> then I'm out of ideas
[15:02] <pitti> few programs actually check the result of unlink()
[15:03] <tkamppeter> pitti, I have also two other files in /etc/udev/rules.d/ which seem to be generated by programs from our distro: 70-persistent-cd.rules and 70-persistent-net.rules.
[15:03] <pitti> I'd go with grepping the file system for "86-hpmud-hp_laserjet_1020.rules"
[15:03] <pitti> might take ages, but it's effective
[15:03] <pitti> tkamppeter: those are expected
[15:06] <tkamppeter> pitti, I have started the search now.
[15:08] <jibel> ev, can you look at bug 789152 when you have a minute or maybe that's expected at this stage of the release.
[15:08] <cjwatson> jibel: dup of bug 788859?
[15:08] <ev> almost certainly is a duplicate
[15:09] <cjwatson> ev: (are you planning to upload ubiquity today, BTW?)
[15:09] <charlie-tca> jibel: I tried yesterday from the cd menu to just get to a live desktop in VBox, and got the same screen with top and bottom panels
[15:09] <ev> cjwatson: yes
[15:09] <charlie-tca> There was no icon to install, though
[15:10] <cjwatson> excellent
[15:10] <ev> more towards EOD though, might see how well this pygi stuff works
[15:10] <ev> but probably without that merged in
[15:12] <kirkland> hallyn: its only a partial fix
[15:12] <kirkland> hallyn: but you should be okay, as long as you don't split screens
[15:12] <kirkland> hallyn: i need to cherry pick a couple of patches from git against screen to get the real fix going
[15:13] <kirkland> hallyn: but before doing that, I need a way to reproduce it ;-)
[15:16] <jibel> cjwatson, yes maybe, but I was unsure because on this report there's a mix of "try/install" doesn't start and some 3D/2D bits with "oh no" dialogs, that's a bit confusing.
[15:22] <tkamppeter> pitti, geser, I did more tests: I renamed the file to /etc/udev/rules.d/00-x.rules and did NOT make it immutable and it survives. After having done so I have created an empty file /etc/udev/rules.d/86-hpmud-hp_laserjet_1020.rules and after the rules which are actually in 00-x.rules being executed the file 86-hpmud-hp_laserjet_1020.rules gets removed, 00-x.rules still surviving.
[15:24] <infinity> tkamppeter: Sounds like a recursive grep of doom is in your future.
[15:32] <tkamppeter> pitti, any file fitting the mask ??-hpmud-hp_laserjet_1020.rules gets removed.
[15:33] <hallyn> kirkland: yeah i can't reproduce it...  (and i dno't split screens)
[15:33] <pitti> tkamppeter: ah, so extend your grep to search for "hpmud-hp_laserjet_1020"?
[15:38] <kirkland> hallyn: darn
[15:38] <hallyn> i assume a flaky connection is the key
[15:47] <pitti> cjwatson: I assume it's ok for you if I steal the gnome-python merge from you?
[15:51] <cjwatson> pitti: absolutely, I think I marked it as "feel free to take" on MoM
[15:56] <doko_> sladen: ping
[16:29] <ogra_> pitti, any idea why the WI tracker didnt pick up all specs for ubuntu-armel yet ?
[16:29] <ogra_> they should all be in approved state, targeted to oneiric and have a priority set
[16:30] <ogra_> so i dont get why http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel.html isnt picking them up
[16:31] <james_w> ogra_, have an example of one that isn't showing up?
[16:32] <ogra_> https://blueprints.edge.launchpad.net/ubuntu/+spec/other-o-arm-netinstall
[16:32] <ogra_> and all the others from https://blueprints.edge.launchpad.net/~davidm?searchtext=o-arm
[16:33] <pitti> ogra_: it's just proposed for oneiric, not accepted
[16:33] <james_w> ogra_, "Proposed for oneiric", it needs to be accepted
[16:33] <ogra_> davidm_, ^^^
[16:34] <ogra_> davidm_, you need to accept all our specs for oneiric
[16:34] <ogra_> approving isnt enough
[16:34] <lool> Hmm language-support-en isn't in the archive anymore; are these deprecated?
[16:34] <lool> (and language-support-writing-*)
[16:34] <davidm_> ogra_, working it now
[16:34] <ogra_> davidm_, thx
[16:34] <davidm_> Sorry missed that step
[16:34] <ogra_> me too
[16:34] <pitti> lool: yes, they're gone
[16:35] <ogra_> else i would have shouted earlier :)
[16:35] <pitti> lool: https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-clean-up-language-support FYI
[16:35] <lool> pitti: thanks
[16:35] <pitti> lool: we have had the split l-support-* and the dynamic check-language-support for a while, but that's a bit of a mess
[16:37] <lool> pitti: Ok; makes sense
[16:37] <lool> (more dynamic language support)
[16:39] <kirkland> pitti: finally just started using lp-project-upload :-)
[16:39] <kirkland> pitti: awesome :-)
[16:39] <pitti> kirkland: :)
[16:39] <kirkland> pitti: i have wasted too many clicks, for too long
[16:39] <kirkland> pitti: question for you...  is it possible to pass the changelog as stdin or a file argument, or something?
[16:40] <kirkland> pitti: i can easily carve that out of my debian/changelog, from the top entry
[16:40] <pitti> kirkland: hm, haven't tried that; I just :e them in vim, and then edit them a bit
[16:40] <Bagatelle> who can help me with this? A username and password are being requested by http://localhost:49810. The site says: "bookmarkable-user-auth"
[16:40] <kirkland> pitti: yeah;  i take care to maintain my debian/changelog so that it doubles as my upstream release changelog
[16:41] <Bagatelle> it seems there are problems with a port, but I dont know anything else
[16:41] <kirkland> pitti: if i patch lp-project-upload to optionally take the changelog text on STDIN, would you accept that change?
[16:41] <pitti> kirkland: of course; it's in ubuntu-dev-scripts, have at it :)
[16:41] <kirkland> pitti: ie, if there's input on STDIN, use it as the changelog text?
[16:41] <kirkland> pitti: sweet, thanks
[16:49] <pitti> kirkland: just keep in mind that there's two editors -- one for changelog, one for release notes
[16:49] <pitti> you can add options for both, and allow one to be '-'
[16:50] <kirkland> pitti: right
[16:51] <kirkland> pitti: i was wondering how to handle that
[16:51] <pitti> good night everyone, have a nice weekend!
[16:51] <kirkland> pitti: i only ever use changelog, and always leave releasenotes
[16:51] <kirkland> blank
[16:51] <pitti> kirkland: you could do --changelog --notes /dev/null or so
[16:51] <kirkland> pitti: yeah
[16:51] <pitti> or --notes ''
[16:51] <kirkland> pitti: that would work
[16:52] <kirkland> pitti: i'll get to it
[16:52] <kirkland> pitti: thanks for the awesome tool;  i feel dumb for not having used it before :-)
[16:52] <pitti> kirkland: so you'll use some dpkg-parsechangelog | sed | lp-project-upload chain?
[16:52] <pitti> kirkland: heh, one day I got so fed up with the 20 clicks you have to do, that I just wrote it
[16:52] <pitti> and since then I'm actually making more releases, as it's a lot less painful
[16:52] <kirkland> pitti: yeah, something like that
[16:53] <kirkland> pitti: currently, i'm using:
[16:53] <kirkland> grep -B 10000 -m1 '^ \-\- ' debian/changelog
[16:53] <pitti> heh, that'd work
[16:53] <kirkland> pitti: yeah, it gets me what I want
[16:53] <kirkland> pitti: see bikeshed's 'release' and 'release-build' scripts
[16:53] <kirkland> pitti: it's the two scripts I use to release and publish 20+ upstream projects and packages
[16:53] <pitti> ah, grep -B, clever
[16:54] <kirkland> pitti: i use a standard naming scheme for all my projects/packages
[16:54] <pitti> I had used sed -n '/^ --/ q; p' or so
[16:54] <kirkland> pitti: always register both the team name and the project name in LP
[16:54] <kirkland> pitti: always create a ppa
[16:54] <kirkland> pitti: and when I release, I always release backports of the package to PPA for each of the supported ubuntu releases
[16:54] <pitti> kirkland: I have "do-release" scripts, too, with that I could actually integrate the uploading as well
[16:55] <kirkland> pitti: so people can track ppa:powernap/ppa for current powernap on older ubuntu releases
[16:55] <kirkland> pitti: this is my step 1: http://paste.ubuntu.com/613820/
[16:55] <kirkland> pitti: release-build ^
[16:56] <kirkland> pitti: and my step 2 is http://paste.ubuntu.com/613821/
[16:56] <kirkland> pitti: release ^
[16:56] <pitti> I bet if we throw together everyone's release scripts, everything would be fully automatic
[16:56] <pitti> well, build recipes in LP certainly went a long way towards automation
[17:04] <mdeslaur> @pilot out
[17:08] <slangasek> doko_: you comment that the rpcbind dependency is "still outstanding" for the nfs-utils merge, but there's an MIR for it?
[17:28] <cjwatson> smoser: I already had a busybox merge partly done :-(
[17:28] <cjwatson> do I have to reconcile it all now?
[17:28] <cjwatson> that's about twice as much work as just doing it (I was touched-it-last)
[17:29] <smoser> cjwatson, bah. sorry.
[17:29] <smoser> well, you can take a look at my diff. i think it is done. but if you want to pitch it, feel free.
[17:30] <smoser> sorry for not asking first.
[17:30] <smoser> take a quick look, and if it doesn't look like you think it should, then ditch it.
[17:31] <smoser> i pretyt throughally went through all the changes from debian and made sure that everything in the changelog delta list was accounted for and that nothing else really was.
[17:42] <smoser> theres a ppa build of my merge at https://launchpad.net/~smoser/+archive/ppa/+packages
[18:23] <smoser> is 'lsb-release -is' the "right way" to determine if this release is ubuntu versus if it is debian ?
[18:23] <j1mc> dpm: i'm not sure if you're the right person for this, but the openstack team just updated some of their site, and they
[18:24] <j1mc> they've done some interesting stuff on their community page: http://www.openstack.org/community/
[18:25] <j1mc> i like the 'developers in action' bit that shows real-time commits
[18:25] <j1mc> they use launchpad, so i'd be curious to know how they did that.
[18:25] <j1mc> ... just thought i would pass that along
[18:51] <ScottK> smoser: I think dpkg-vendor is preferred.
[18:52] <ScottK> That avoid a need for an lsb depends.
[18:55] <smoser> ScottK, well that comes from dpkg-dev which is 'optional' in debian
[18:55] <maco> smoser: but build-depends pulls it in
[18:55] <maco> erm i mean
[18:55] <maco> build-essential
[18:57] <smoser> yeah, in ubuntu its probably goign to be there. but my interest was in getting something into 'jigit' to take a different path if "this is ubuntu"
[19:02] <slangasek> build-essential isn't going to be pulled in on the runtime
[19:03] <slangasek> lsb_release is preferred for that - you don't even need to depend on it really, if the command is missing you can just assume Debian
[19:03] <slangasek> (since it's part of ubuntu-minimal)
[19:08] <slangasek> barry: --package-merge> duuuude
[19:08] <slangasek> when'd that get there?
[19:13] <sladen> doko_: dong
[19:16] <barry> slangasek: dunno, but i just found out about it yesterday!
[19:50] <janimo> james_w, thanks for fixing up my BPs whiteboard ! I completely forgot LP ID is to be used
[19:50] <james_w> np
[20:13] <petar> why is update-initramfs executing scripts i put into /etc/initramfs-tools/scripts/* ?  i thought thats what hooks/* is for?
[20:13] <petar> (thats on 11.04)
[20:17] <slangasek> petar: you're correct, that is the difference between hooks and scripts; I haven't heard of this issue you describe
[20:19] <petar> slangasek: i have one script in scripts/init-bottom and after every update-initramfs it gets executed..  and it doesn't get executed during a subsequent boot.. i remember that feature working pretty well on 9.10
[20:20] <slangasek> a brief scan of 11.04's initramfs-tools code doesn't show me anything that explains why this would be
[20:20] <slangasek> can you trace it?
[20:21] <petar> to be honest i cant even see where this scripts stuff comes into it when reading update-initramfs
[20:22]  * slangasek nods
[20:22] <petar> there is not much sourcing either..
[20:25] <petar> i need to eat something.. will try again, when i'm back
[20:47] <NCommander> @pilot out
[20:47] <NCommander> oops
[21:23] <petar> slangasek, its called cache_run_scripts and i have no idea why mkinitramfs uses that to run my scripts on update-initramfs -u
[21:24] <petar> it seems that i could set NOEXEC but how can i set something that i dont understand in order to solve something that i dont understand either? ;)
[21:26] <slangasek> petar: oh, yes, because it's trying to query the scripts to find out what their dependencies are
[21:27] <slangasek> petar: does your script not handle the 'prereqs' option?
[21:29] <petar> hmm, no, i thought i have no prereqs so...
[21:29] <slangasek> right; but initramfs-tools still needs to call it with prereqs to find that out, so the script has to behave sensibly when this is done
[21:30] <petar> aaaa.. i see now.
[21:30] <slangasek> the only new behavior here is that we do this at update-initramfs time, to cache the order once instead of having an expensive query on every boot
[21:31] <petar> ok, i'll add that.. makes sense.
[21:31] <petar> thanks for your help!
[21:31] <slangasek> sure :
[21:31] <slangasek> )
[21:33] <petar> very good, seems to work now
[21:50] <slangasek> bdmurray: looking at bug #781874 still; is your thought that this should supersede the SRU currently in -proposed, or that that one should be published to -updates and the new one uploaded?
[22:37] <bdmurray> slangasek: is the order important?
[22:38] <slangasek> bdmurray: it impacts what -v option needs to be passed when uploading; I don't have a preference per se
[22:40] <bdmurray> slangasek: well the one in proposed has been there for quite some time now
[22:41] <slangasek> yep, apparently without verification
[22:41] <bdmurray> and without testcases
[22:42] <broder> ScottK: do you have thoughts on bug #787383? since u-d-t 0.124 introduces a versioned dependency on a current version of devscripts, dholbach's suggestion to just backport the bitsize bugfixes makes sense to me, but i'd like a second opinion
[22:43] <bdmurray> I wrote a bug pattern for 781874 already so either way is fine with me.  I just didn't want the fix not making it into Natty.
[22:44] <slangasek> well, let me prod the bugs to see if we can get a test case
[22:45] <slangasek> no sense in uploading the next SRU either way if it's going to stay wedged forever on verification of the current SRU bugs
[22:49] <slangasek> stgraber: do you happen to have a reproducible test case for bug #742935?
[23:12] <psusi> is there someone I need to poke to activate my universe-contributors membership?
[23:24] <ScottK> broder: I think just backporting bitesize makes sense.
[23:24] <bdrung_> psusi: normally the chair of the meeting
[23:25] <bdrung_> psusi: feel free to poke him
[23:27] <psusi> hrm.. seems the minutes haven't been posted yet
[23:28] <psusi> and the irclogs for ubuntu-meeting are empty...
[23:28] <psusi> err, oops, that was lp-meeting
[23:33] <psusi> cjwatson, bug #770600 has been waiting for a while now for a sponsor, could you handle it?  it's a release regression in dmraid from the 64bit pdc patch that I added... branch proposed to simply disable the patch.
[23:34] <psusi> ppa tested and fix verified by multiple users
[23:38] <stgraber> slangasek: nope
[23:38] <cjwatson> psusi: it's end of week for me now, but my patch pilot day is coming up so I'll handle it then if not before
[23:38] <cjwatson> (it's 23:38 here)
[23:39] <psusi> cjwatson, cool
[23:40] <slangasek> stgraber: k; was worth a shot
[23:40] <cjwatson> I'm only still here because I was finishing up debugging bug 728088 in order to release a kind user's test machine
[23:46] <psusi> cjwatson, it used to be recommended to create a raid1 partition for /boot and install grub to those disks, then raid5 for / ( assuming you want a raid5 )... with grub2 you can now just make a single raid5 for /, and install grub to all of the disks, so should that now be the recommended method?
[23:49] <cjwatson> psusi: probably, if it's working well
[23:49] <cjwatson> separate /boot isn't harmful of course, it's just extra work
[23:51] <psusi> right, and so if it isn't necessary, best to avoid it...
[23:51] <cjwatson> it is more complexity in the boot loader, of course, and some people like to avoid *that*
[23:52] <cjwatson> depends on your point of view really