[00:24] <RAOF> What?  Gah!  There should be an easier way of testing armel builds than failing on the buildd.
[00:25] <slangasek> there's a porter machine
[00:25] <slangasek> and there's qemu
[00:25] <RAOF> Yeah, there's the porter machine.
[00:25] <slangasek> RAOF: apt-get install qemu-user-static; /usr/sbin/qemu-debootstrap -aarmel [...]
[00:25] <RAOF> The buildds take *8 hours* to build mesa; a local build would still be going from yesterday.
[00:26] <slangasek> there's a cross-compiler package :)
[00:26] <RAOF> I've got an armel schroot, and for things smaller than mesa it's very nice :)
[00:28] <RAOF> This typo was in the install target of debian/rules though, so… urgh.
[00:28] <directhex> slangasek: an ubuntu porter machine?
[00:28] <slangasek> you've inspired me to check whether I can get away with cross-installing all the mesa build-deps with mulitarch
[00:29] <slangasek> directhex: a Canonical ubuntu porter machine, sorry :/
[00:29] <slangasek> shell access in the DC, company policy, etc etc
[00:29] <directhex> yeah, that's fine. i've never encountered an arm bug on ubuntu's smp omap4 target that i haven't hit on a single-core efikamx
[00:29] <directhex> no, wait, the opposite of what i just said
[00:30] <slangasek> the porter machine isn't an smp omap4 anyway
[00:30] <directhex> winnar
[00:30] <RAOF> When will multiarch stop killing update-manager?
[00:31] <RAOF> :)
[00:37] <slangasek> RAOF: oh, how's it killing it for you?  It works for me! :)
[00:37] <directhex> i'm sure i can badger access to a pandaboard in the office if i need to (note: this is a lie)
[00:38] <RAOF> Hm.  Last time I tried it would kinda refresh the apt cache and then die with an inscrutable error message.
[00:38] <RAOF> And I went back to apt-get update && apt-get dist-upgrade…
[00:38] <RAOF> I'll try again once apt's finished :)
[00:38] <slangasek> RAOF: so as of the last u-m changes before the natty release, all those issues have been resolved for me
[00:40] <RAOF> I'll try again, and this time report bugs when they fail.
[00:41] <slangasek> yay :)
[00:41] <RAOF> So, does this mean we're actually quite close from being able to drop mesa from ia32-libs?
[00:41] <RAOF> What's left before i386 is a default foreign arch?
[00:42] <slangasek> we wouldn't drop mesa from ia32-libs, we would want to drop ia32-libs itself from the archive
[00:43] <slangasek> "what's left" - we need to be satisfied that turning on i386+amd64 isn't going to carry so much a penalty in index download time that it makes it (more) painful to run apt-get update
[00:46] <RAOF> Hm.  Looks like update-manager's perfectly happy now.
[00:46] <RAOF> Yeah.  I'm now downloading ~50MB of apt indexes.
[00:59] <RAOF> slangasek: Ah.  The partial-upgrade tool seems be spinning indefinitely.  Is there any debugging information I can nab before killing it?
[00:59] <slangasek> RAOF: mm, no idea on that, sorry
[00:59] <RAOF> Not something you've run into?
[01:00] <RAOF> Ok.  Well, I'll file a bug and see.
[01:01] <slangasek> RAOF: nope, not run into it that I can recall
[01:13] <RAOF> slangasek: bug 798478
[01:14] <RAOF> Ah, need to update the title.  It doesn't spin indefinitely, it waits for you to submit a bug and then throws up an error message :)
[01:19] <slangasek> heh :)
[01:37] <Keybuk> slangasek: http://online.wsj.com/article/SB10001424052702304066504576345782284098222.html?KEYWORDS=telecommuting+tax
[01:37] <Keybuk> ouch
[01:37] <Keybuk> which state is Canonical Inc incorporated in, again? :)
[01:38] <directhex> isle of man, iirc?
[01:38] <Keybuk> directhex: that's Canonical Ltd
[01:39] <micahg> New York and New Jersey have extremely punitive tax codes
[01:39] <Keybuk> http://www.manta.com/c/mtvfcjz/canonical-usa-inc
[01:39] <directhex> Keybuk: handy. maybe there's more reason for collabora.ca than i thought
[01:40] <Keybuk> directhex: well, .ca has that law that defines the difference between an employee and a contractor, right?
[01:40] <directhex> dunno, but we have plenty of contractors on the payroll :p
[01:40] <Keybuk> there is, I believe, also a Canonical Canada Ltd
[01:41] <Keybuk> it's funny how sladen stopped his Canonical tax accounting stalking when he joined ...
[01:41] <directhex> it's also funny that he's not a DD
[01:41] <micahg> hehe
[01:42] <Keybuk> it's also funny that he eats ice cream with chopsticks
[03:30] <amit> Hello all. Seeking assistance in finding procedure for updating /etc/motd w/o reboot:
[03:30] <amit> distro: ubuntu server 10.04
[03:30] <amit> /etc/motd gets modified to the value of /etc/lsb-release:DISTRIB_DESCRIPTION. But this only takes effect after rebooting (more specifically, I think it's already modified before the reboot, when switching to RUNLEVEL 1).
[03:30] <amit> Can /etc/motd be auto-modified w/o a reboot?
[03:34] <micahg> amit: you might want to try #ubuntu-server
[03:36] <amit> micahg: ok, 10x.
[03:44] <bradm> ubuntu wiki upgrade is done, please let us know if there are any troubles
[03:48] <micahg> bradm: login seems to be taking forever
[04:29] <slangasek> kees: Canonical, USA is incorporated in Delaware, like all corporations worth their salt
[04:29] <slangasek> eh
[04:29] <slangasek> kees: not you, the Keybuk who dodged :P
[06:05] <pitti> Good morning
[06:24] <pitti> hmm -- wiki, where are thou?
[06:24] <StevenK> pitti: It was upgraded, do you have an issue?
[06:25] <pitti> trying to login, it times out
[06:25] <pitti> anonymous viewing works
[06:27] <nigelb> I can duplicate that
[06:38] <pitti> SpamapS: darn, lucid's launchpadlib doesn't yet work with the launchpadlib queue count; I reverted that change to screenscraping again to get the queue counts back on pending-sru.html
[07:55] <dholbach> good morning
[08:31] <pitti> WTH -- does https://wiki.ubuntu.com/ReleaseTeam/Meeting/Agenda work for anyone?
[08:31] <pitti> I get redirected to some http://www.releaseteam.com commercial page
[08:34] <micahg> pitti: broken wiki redirect
[08:35] <micahg> pitti: just asked in #is
[09:01] <mvo> pitti, dpm: I'm just looking at the merge of myspell-hr and the only change is to add a (or) dependency to language-support-writing-hr. it appears like this is the only of hte hypen packages doing this, can we drop that delta and sync the pkg?
[09:02] <hrw> morning
[09:02] <dpm> hey mvo, I'm not sure, I'll let pitti answer that one
[09:08] <pitti> mvo: confirmed
[09:08] <pitti> language-support-* are gone
[09:10] <mvo> pitti: thanks, I will request the sync
[09:25] <cjwatson> pitti: some discussion on the internal foundations list raised an interesting possibility: purge .pyc files from the live filesystem, and have ubiquity byte-compile them after copying the filesystem
[09:25] <cjwatson> pitti: .pyc files are about 12MB right now
[09:25] <cjwatson> we have to be careful to avoid making installed systems inconsistent between d-i and ubiquity, but if that can be avoided it does seem worth pursuing
[09:27] <pitti> cjwatson: indeed, that came up recently
[09:27] <pitti> cjwatson: but as the .pyc files are generated at package install time, and not shipped in the .debs, it should not be more inconsistent than a live vs. alternate install already is?
[09:28] <cjwatson> well, if you removed them from the live filesystem and didn't have ubiquity do the byte-compile step, nothing would ever generate them until the packages in question are upgraded
[09:28] <cjwatson> if ubiquity does that work, though, it's feasible
[09:28] <pitti> right, that's what I meant
[09:29] <pitti> I meant that it shouldn't matter much whether it was live-builder or ubiquity which triggers the pyc building
[09:29] <cjwatson> it costs a bit of extra time at installation; but 12MB isn't small change
[09:29] <pitti> even compressed that should be some 5 MB perhaps
[09:29] <cjwatson> I'm quoting the compressed size
[09:30] <cjwatson> it's more like 40MB uncompressed
[09:30] <pitti> !
[09:30] <pitti> by the looks of man pycompile, we wouldn't even need to iterate over all packages, it seems it can build them all
[09:30] <cjwatson> $ sudo find /mnt -name \*.pyc | xargs cat | gzip -9c | wc -c
[09:30] <cjwatson> 11812952
[09:31] <cjwatson> I'll check out exactly what dh_python2 etc. causes to happen, to make sure it matches
[09:31] <pitti> thanks!
[09:32] <cjwatson> we might want to trigger a fake python runtime update or something rather than calling pycompile directly
[09:33] <pitti> oh, that indeed seems easier
[09:33] <pitti> interesting that it doesn't seem to differ between pysupport, pycentral, and dh_python2
[09:34] <pitti> oh, wait
[09:34] <cjwatson> those three have quite different .rtinstall files
[09:34] <pitti> it only seems to rebuild its own pycs, not for all python-* packages
[09:34] <cjwatson>         for hook in /usr/share/python/runtime.d/*.rtinstall; do
[09:34] <cjwatson>             [ -x $hook ] || continue
[09:34] <cjwatson>             $hook rtinstall python2.7 "$2" "$version"
[09:34] <cjwatson>         done
[09:34] <cjwatson> is basically what python does to byte-compile stuff
[09:36] <cjwatson> I'll check safety with doko
[09:43] <DktrKranz> mvo: hi! I implemented some new features in gdebi, I plan to upload to experimental soon, then sync it in oneiric. Does it sound good to you?
[10:24] <lag> Why do random applications (browser, instant messenger etc) keep greying out and locking up?
[10:27] <pitti> this often happens if you do heavy I/O, such as copying big files, rsyncing cd images, etc.
[10:28] <pitti> if not, then the browser/IM is just busy (which is a bug, as it shoudln't stop responding to the UI)
[10:28] <lag> pitti: The browser is doing nothing, but has locked
[10:29] <lag> pitti: When the IM locked up, it was doing nothing
[10:29] <lag> pitti: They just become unresponsive and lock
[10:29] <pitti> bugs
[10:29] <lag> pitti: My mail client does the same, again whilst doing nothing
[10:29] <pitti> it's not "desired behaviour" of course
[10:30] <lag> pitti: Must be a Ubuntu bug, can't be all these different applications
[10:35] <cjwatson> check syslog in case you have a disk device that's returning I/O errors
[10:37] <ogra_> might be a hint from your system that you should probably stop doing nothing then :P
[10:38] <micahg> I get it when I have incredibly high i/o wait
[10:40] <lag> ogra_: HA - jerk!
[10:40] <micahg> !coc | lag
[10:40] <lag> ogra_: My terminal is extremely busy (but it's not failing)
[10:41] <pitti> micahg: the problem with Linux is unfortunately that merely doing an rsync or copying 2 GB around already counts as "incredibly high" :(
[10:41] <lag> micahg: I'd love to open it, but my browser is locked ;)
[10:41] <lag> micahg: Why did you send that to me?
[10:41] <ogra_> lag, see, that supports my theory ;)
[10:42] <apw> lag, i find i get the same greying with no load, things grey out one by one, resolving when an OSD message finally spits out
[10:42] <micahg> lag: we don't tolerate insults here
[10:42] <lag> micahg: ogra is a good friend of mine - he knows I was joking
[10:43] <apw> somehow they cause a log jam which can even affect gnome-terminal ... which makes no sense, but its happened often enough that i've mannaged to killall the notifier to confirm its definatly that thats causing the blockage
[10:43] <lag> apw: I am used to momentary greying out, but when these go, they are perm and the only way I can resolve is to kill the app
[10:43] <apw> and its always for me an xchat OSD thats trying to display
[10:43] <lag> apw: I haven't seen an OSD message for ages
[10:44] <lag> apw: Let me try
[10:44] <apw> how long is perm, i see minutes of grey during which a restart of notify-osd fixes it
[10:44] <psurbhi> jhunt, I am trying to stop a job on "stopped udev"
[10:44] <apw> not that anyone believes me
[10:44] <psurbhi> but this never happens
[10:44] <apw> psurbhi, udev runs all the time doesn't it?
[10:44] <psurbhi> so, I put post-stop script ; echo "in post stop"; end script
[10:44] <cjwatson> udev doesn't stop (except on shutdown)
[10:44] <psurbhi> and i cant see that either
[10:44] <psurbhi> cjwatson
[10:44] <psurbhi> exactly
[10:45] <lag> apw: As long as I am patient enough to leave it - I need my browser and mail client, so I guess I've left it for 10-15 mins
[10:45] <psurbhi> but i want to do something similar in the initramfs
[10:45] <psurbhi> and somehow i cant see udev in the "stopped" case
[10:45] <psurbhi> it always reaches "stopping" and thats it
[10:45] <cjwatson> ah, I'll leave you alone then, not sure what that would be
[10:45] <psurbhi> i want to stop upstart-udev job on "stopped" udev
[10:45] <psurbhi> and then run the pivot command
[10:46] <psurbhi> right now, to achieve the same effect
[10:46] <psurbhi> i am stopping the upstart-udev-bridge
[10:46] <lag> cjwatson: Just checked syslog, looks like I have problems!
[10:46] <psurbhi> on stopping udev
[10:46] <cjwatson> pitti: could you ack my debian-installer/lucid-proposed upload, please?
[10:46] <psurbhi> and then in the post-stop of upstart-udev-bridge, i execute kill all udev
[10:46] <cjwatson> lag: busted disk?
[10:46] <cjwatson> lag: past time to check those backups :)
[10:47] <lag> cjwatson: Seemingly: https://pastebin.canonical.com/48644/
[10:47] <psurbhi> jhunt ^^
[10:47] <pitti> cjwatson: diff looks fine, accepted
[10:47] <lag> cjwatson: I'm all backed up ;)
[10:47] <cjwatson> pitti: ta
[10:47] <psurbhi> i was wondering if anyone has seen that udev really stops on shutdown
[10:47] <psurbhi> atleast?
[10:47] <jhunt> psurbhi: how do you know it only reaches stopping?
[10:47] <psurbhi> because i have put echos in the scripts
[10:47] <cjwatson> oh good, it's so rare that I say that and it's actually true
[10:47] <pitti> lag: doesn't seem related at all to IO errors; it just says that your keyboard has unknown keys
[10:47] <psurbhi> i.e post-stop script
[10:47] <psurbhi> and pre-stop script
[10:48] <jhunt> psurbhi: where are the echoes going?
[10:48] <psurbhi> and also, the job that should execute on stopped
[10:48] <psurbhi> never gets executed
[10:48] <psurbhi> running upstart in --debug mode
[10:48] <psurbhi> never shows udev in the "stopped" state
[10:48] <pitti> lag: by any chance, does the blocking start when you press a particular key?
[10:48] <psurbhi> it says "stopping" udev
[10:48] <cjwatson> lag: yeah, those don't look like serious disk problems to me either
[10:48] <psurbhi> but i did not see anything more than that
[10:48] <pitti> lag: we had that problem with many Samsung laptops, they have a BIOS bug which needs to be worked around
[10:49] <cjwatson> some filesystem consistency problems, but not I/O
[10:49] <psurbhi> jhunt?
[10:49] <pitti> lag: try pressing Ctrl+Alt+F1, then Ctrl+Alt+F7 (or F8, whatever gets you back to the graphical desktop), and check whether it's gone
[10:49] <psurbhi> i did not get the question - where are the echoes going
[10:49] <psurbhi> sorry
[10:49] <pitti> lag: then find out whether pressing that magic Fn+something key triggers it
[10:49] <lag> pitti: I was referring to the 1587 ext2 errors I have in there
[10:49] <lag> pitti: Jun 17 10:48:14 system1 kernel: [11052.251178] EXT2-fs (sdb1): error: ext2_lookup: deleted inode referenced: 3268621
[10:50] <ogra_> wow
[10:50] <apw> lag, is that an internal drive?  cirtainly needs unmounting and checking properly
[10:50] <ogra_> that doesnt look good
[10:50] <cjwatson> yeah, worth unmounting and doing a manual fsck
[10:50] <lag> Not at all :(
[10:50] <lag> Yes, it's mounted at /home/lag/
[10:50]  * apw suggests crossing anything you have more than one of
[10:51]  * lag lols @ apw
[10:51] <apw> lag, well we know there is nothing in there thats important :)
[10:51] <lag> Right, BBS (if all goes well)
[10:51] <lag> apw: You lot are rude!
[10:51] <lag> ;)
[10:51] <apw> lag, is my job
[10:51] <lag> apw: Quite
[10:52] <lag> Right, I'm off to fsck
[10:52] <apw> heres hoping its your git trees, as most files in there are regenerrable :)
[10:53] <lag> apw: /home/lag/projects are mounted separately ;)
[10:54] <psurbhi> jhunt, i can see the echoes in the pre-stop scripts for mountall.conf and udevd.conf
[10:54] <psurbhi> but i cant see the echoes in the post-stop script
[10:55] <jhunt> psurbhi: I've just done a test and I have a simple job which successfully starts on "stopping udev".
[10:55] <psurbhi> jhunt - yes that works
[10:55] <psurbhi> but can you try starts on "stopped udev"
[10:55] <psurbhi> the stopping clause works
[10:55] <psurbhi> but the "stopped" doesnt for me
[10:56] <jhunt> psurbhi: I think just aren't seeing the messages - rsyslog stops on the same condition as udev - try logging to the console/serial device
[10:56] <psurbhi> jhunt, the job does not start too
[10:56] <psurbhi> :-/
[10:56] <psurbhi> can you please let me know if the job starts on "stopped udev" ? for you?
[10:56] <apw> psurbhi, how can you tell if its not started if the logging output is not logged>
[10:56] <psurbhi> jhunt, yes, i am getting the messages on the serial console
[10:57] <psurbhi> apw, you could stop the logging on "stopped udev"
[10:57] <psurbhi> instead of "stopping udev"
[10:57] <jhunt> works for stopped udev too...?
[10:57] <apw> still too late though right as your job also starts then
[10:57] <psurbhi> jhunt, does your job work?
[10:57] <psurbhi> apw, then you can stop logging after stopping your test-job
[10:57] <jhunt> psurbhi: it runs, so yes :)
[10:57] <psurbhi> ok!
[10:58] <psurbhi> jhunt, thanks
[10:58] <psurbhi> i will probably send you the initramfs
[10:58] <psurbhi> can you please let me know what you think is wrong in there?
[10:58] <jhunt> psurbhi: can you show me your .conf file?
[10:58] <apw> i had to log directly to /dev/.foo i think the only reliable way to get diagnostics, when i was playing with the vesafb stuff
[10:58] <psurbhi> yes, exactly
[10:59] <jhunt> psurbhi: (from other channel) - yes, lets take this offline now...
[10:59] <cjwatson> yeah, I've always logged to /dev/.initramfs/<something> when trying to debug this kind of thing
[10:59] <cjwatson> (/run will reduce typing ...)
[12:05]  * ogra_ wonders what changed in upower recently ... i get battery discharge notifications every few mins since my last upgrade
[12:13] <hrw> ogra_: maybe your battery started dying?
[12:13] <hrw> ;D
[12:14] <ogra_> its brand new
[12:14] <ogra_> charged for the first time yesterday
[12:16] <nigelb> bad purchase? :)
[12:18] <ogra_> nah
[12:18] <ogra_> it was fine before the upgrade
[12:20] <nigelb> well, mine started showing zero recently, but it ever had a good battery. Like its totally drained. I thought that was a bug fixed to show it correctly ;)
[12:20] <nigelb> *never
[13:03] <cjwatson> mvo: have you seen bug 774999?
[13:05] <cnd> I was hoping to upload a package to ubuntu today, but I tested in a pbuilder and found that it failed to install build deps due to bug 775546
[13:05] <mvo> cjwatson: no, sorry, I have a look now
[13:05] <cnd> should I upload it anyways? or should I wait until the bug is fixed?
[13:09] <cjwatson> mvo: np, thanks
[13:16] <cjwatson> cnd: is that actually the reason it's failing?  that bug suggests that it's cosmetic
[13:17] <cnd> cjwatson, yeah, I think you are right after I googled some more
[13:17] <cnd> let me pastebin the error message I see
[13:18] <cnd> I just assumed that was the reason since it was the first error/warning message I saw
[13:19] <cnd> cjwatson, here's what I believe is the relevant snippet: http://paste.ubuntu.com/628382/
[13:24] <cjwatson> cnd: right, I was actually in the middle of a test live filesystem build to track that down, since it broke those too
[13:24] <cnd> cjwatson, ok
[13:25] <cnd> so should I hold off on uploading packages until it's fixed?
[13:25] <cnd> or should I upload now, and just retry builds as necessary?
[13:25] <cjwatson> it doesn't *hugely* matter; if you don't hold off, you'll have to retry
[13:25] <cjwatson> I wouldn't worry too much about it
[13:25] <cjwatson> if you have relevant upload privileges, retrying isn't too much of a hassle
[13:26] <cnd> ok, thanks!
[13:35] <YokoZar> What's the best way to have a package build with gcc 4.4 on Lucid, 4.5 on maverick (whose default is 4.4), and 4.5 on natty?
[13:37] <directhex> a big ol' conditional in debian/rules
[13:37]  * Laney conditions directhex goooooooooood
[13:38] <YokoZar> directhex: so I take it we don't provide some sort of gcc-latest symlink?
[13:39] <directhex> YokoZar, nafaik, just gcc as a symlink to the default
[13:40] <Daviey> Anyone else noticed archive builds failing for odd reasons atm?
[13:41] <cjwatson> Daviey: see discussion with cnd above, perhaps
[13:41] <cjwatson> I'm just trying to pinpoint it with a livefs build here, since the logs are awkwardly unhelpful (failure distant from cause)
[13:41] <directhex> what's the deal with powerpc right now? buildds seem backed up
[13:41] <Daviey> cjwatson: ok, thanks
[13:42] <cjwatson> it would probably help if dpkg rejected packages with syntactically invalid triggers files at unpack time rather than later
[13:42] <cjwatson> Daviey: however, can you point to a build log to make sure we're looking at the same thing?
[13:42] <Daviey> https://launchpad.net/ubuntu/+source/cvs/2:1.12.13+real-5ubuntu1/+build/2575050
[13:42] <Daviey> cjwatson: that is the second build attempt
[13:43] <Daviey> first one failed for "sh: gcc: not found"
[13:43] <Daviey> sadly, i didn't save the log
[13:43] <cjwatson> "sh: gcc: not found" appears in lots of build logs due to something being run in the wrong chroot, and isn't normally fatal
[13:43] <Daviey> I also saw one of slangasek's builds fail a few hours ago, but worked locally here - so hit rebuild and it worked.
[13:44] <Daviey> (seeing this on i386 and amd64)
[13:44] <cjwatson> anyway, yeah, that's the same thing that I'm looking at
[13:45] <cjwatson> though perhaps a livefs build isn't the most efficient way to do it, but I might as well wait for it now ...
[13:45] <Daviey> rocking
[13:50] <mvo> DktrKranz: gdebi> thats fine of course, many thanks for working on it, I noticed a bunch of fixes :)
[14:39] <cjwatson> slangasek: hmm, looks like multiarch+triggers breaks world
[14:39] <cjwatson> $ cat chroot/var/lib/dpkg/triggers/Unincorp
[14:39] <cjwatson> aspell-autobuildhash dictionaries-common:all
[14:48] <cjwatson> aha, I think it's a non-updated trigdeferred.c
[15:21] <seb128> cjwatson, the gtk3 cpp bindings landed in debian unstable, should be on ubuntu on next new-source run then
[15:21] <seb128> cjwatson, it might make easier the work for the gparted guys, dunno what distro they run
[15:25] <hrw> jdstrand: can I get my armhf cross toolchain from NEW?
[15:25] <jdstrand> hrw: yeah, I am going to be working on it today
[15:26] <jdstrand> hrw: what are the packages?
[15:26] <hrw> jdstrand: cool, thanks
[15:26] <hrw> jdstrand: all with armhf in name: armhf-cross-toolchain-base, gcc-4.[456]-armhf-cross, gcc-defaults-armhf-cross
[15:26] <hrw> jdstrand: I will take care of build order once they will be out of NEW
[15:28] <cjwatson> seb128: thanks
[15:33] <stgraber> win 39
[15:33] <stgraber> oops
[15:53] <slangasek> cjwatson: doh, sorry for the mismerge; are you fixing/uploading, or do you need me to do something?
[15:53] <cnd> cjwatson, do you have a bug number for the bug we were hitting with the Unincorp trigger?
[15:56] <cjwatson> Daviey,cnd: new dpkg should fix it
[15:56] <cjwatson> cnd: no
[15:56] <cjwatson> I couldn't see a reported bug anywhere particularly obvious, so just fixed it
[15:56] <cnd> ok, knowing it's a dpkg bug is good enough :)
[15:56] <cjwatson> slangasek: done now.  oddly, I couldn't see anything in your upload that should have broken it
[15:57] <slangasek> huh
[15:57] <cjwatson> trigdeferred.c was out of date in the same way in the old version too
[15:57] <cjwatson> and the changes to trigcmd.c that tickled it were in the old version
[15:58] <cjwatson> but meh, I tested my change and it fixed the problem in my chroot
[15:59] <slangasek> ah, an out-of-date generated file rather than a missing merge, doh
[16:00] <cjwatson> slangasek: merry hell to find
[16:09] <Daviey> cjwatson: awesome, thanks
[16:34] <apw> mdeslaur, you about?  seems the fix for kernel 3.0 version issue in lm-sensors-3 (bug #797001) is only good for 3.0, i've re-fixed it up and pushed a branch to the bug ... testing is in the bug ... perhaps you could review
[16:46] <mdeslaur> apw: hold on a sec
[16:53] <mdeslaur> apw: ah, yes, that makes more sense
[16:53] <mdeslaur> apw: I'll upload it in a sec
[16:53] <apw> mdeslaur, thanks
[17:05] <jelmer> barry: hi
[17:05] <mdeslaur> apw: uploaded, thanks
[17:05] <apw> mdeslaur, thank you
[17:07] <pitti> charlie-tca: oh, your goal is to not ship libgtk-3-0?
[17:07] <ogra_> vs porting the whole of xfce on his own ? :)
[17:07] <pitti> charlie-tca: I thought you were using evince and other GNOME apps
[17:09] <seb128> not using gtk3 is not going to work
[17:09] <ogra_> hmm ?
[17:10] <ogra_> you think all of universe will be ported by release date ?
[17:10] <seb128> it's going to hard to find a gtk application to use
[17:10] <seb128> no, but I think if you want to get ride of gedit, eog, file-roller, evince, etc it's not a win
[17:10] <ogra_> ah, yeah
[17:11] <seb128> well you can but you will corner yourself at shipping applications which don't have an active upstream
[17:11] <seb128> because those who have one will be ported
[17:11] <seb128> it's not really a winning option
[17:11] <ogra_> but what do you do if your DE upstream doesnt move ?
[17:11] <seb128> you ship 2 gtk versions
[17:12] <RoAkSoAx> cjwatson: howdy!! I was wondering if you managed to look into providing some kind of file with info in the Ubuntu mini.iso after discussing it at the UDS (with kirkland as well)
[17:12] <seb128> we do that for Ubuntu...
[17:12] <seb128> you can have a shell on gtk2 and application on gtk3
[17:12] <seb128> that's basically what oneiric is
[17:12] <kirkland> RoAkSoAx: grab that bug number, i think cjwatson upped it from won'tfix to triaged, as i recal
[17:12] <seb128> well until next week when unity-gtk3 lands
[17:12] <ogra_> sure, but that eats CD space
[17:12] <cjwatson> RoAkSoAx: I closed that bug with an explanation of what I'd done
[17:12] <cjwatson> bug 765254
[17:13] <seb128> ogra_, welcome to our world ;-)
[17:13] <ogra_> heh
[17:13] <cjwatson> I guess you don't read your bug mail either? ;-)
[17:13] <seb128> ogra_, you just summarize oneiric :p
[17:13] <ogra_> (me hugs his ARM world for not having these restrictions)
[17:13] <RoAkSoAx> cjwatson: ah cool!! I somehow missed that :) Thanks!!
[17:14] <RoAkSoAx> kirkland: Will now get the import with cobbler to automatically detect it
[17:20] <kirkland> cjwatson: thanks
[17:27] <apw> cjwatson, i am wondering if this was the message which was the dpkg bug: bug #798800
[17:29] <SpamapS> pitti: hah, ok, I was just thinking you had been really good about getting them all done. OOPS!
[17:30] <pitti> SpamapS: well, I still did quite a few of them this mornign :) basically all that could be accepted, there were some which need further discussion or wait for the current proposed pacakge
[17:30] <smoser> slangasek, ping.
[17:31] <slangasek> smoser: ohai
[17:31] <smoser> bug 798803
[17:31] <smoser> i'm thinking its related to your dpkg upload/merge
[17:31] <slangasek> smoser: already fixed in the preceding dpkg upload by cjwatson
[17:32] <smoser> well there ya go. i'm slow.
[17:33] <hallyn> bug 798798 looks unrelated to libcap.  First error comes from tex, and the rest all seems somehow unicode related.  Not sure what to target the bug at.
[17:33] <hallyn> ah
[17:33] <hallyn> same as smoser's
[17:33] <hallyn> i'll just mark it as a dup then
[17:33] <slangasek> yes please
[17:34] <smoser> i just moved mine to dpkg, and marked fix released.
[17:34] <slangasek> sorry for the breakage :/
[17:35] <hallyn> oh feh it was the same guy :)
[17:36] <smoser> @pilot in
[17:41] <slangasek> Daviey: do you know why my one-line edit of debian/control has broken builds of libapache2-mod-perl2? :)
[17:41] <cjwatson> apw: yes
[17:41] <nigelb> heh
[17:42] <Daviey> slangasek: developers not testing uploads? ... :)
[17:42] <apw> cjwatson, is there a master bug to dup it to?
[17:42] <cjwatson> apw: not that I know of
[17:42] <slangasek> Daviey: that's orthogonal! :)
[17:42] <Daviey> slangasek: heh.. no - it was an interim issue.. NFI what caused it.. built locally here, so i fired rebuild.. and it worked
[17:42] <slangasek> Daviey: I didn't test that it still built because I only edited a Recommends to a Suggests :-)  ok
[17:42] <apw> ok i'll just cloose it off
[17:43] <apw> cjwatson, actually it looks like bug #798803 is becoming the master
[17:43] <Daviey> slangasek: seems to be unreleated to the dpkg issue. :/
[17:43] <Daviey> it just needed some pixie dust i think
[17:43] <cjwatson> apw: feel free to make it so then
[17:43] <cjwatson> I couldn't find one when I was fixing it
[17:44] <apw> cjwatson, that one has a couple of dups now, but yeah i think yours was first, duped, thanks
[17:47] <cjwatson> I posted recovery instructions to that bug - it can be tricky to get out of
[17:47] <cjwatson> and off for the weekend, please somebody else field any followup :)
[17:59] <smoser> anyone able to review/sponsor https://code.launchpad.net/~smoser/ubuntu/oneiric/rsyslog/merge-debian-5.8.1-1/+merge/63761
[18:00] <Daviey> smoser: request a review from ~ubuntu-sponsors :)
[18:01] <smoser> Daviey, well its already on the sponsorship queue
[18:03] <Daviey> so it is.
[18:05] <Daviey> smoser: You really need to be uploading this stuff yourself.
[18:05] <Daviey> :)
[18:10] <slangasek> RAOF: ok, all the build-deps of mesa are fixed up now to be multiarch-installable in unstable except for one :)
[18:26] <micahg> apw: sorry about that partial fix for lm-sensors-3, the upstream ML actually has a slightly better one that ignores the extra parenthesis, so it's still a one line fix, I'll get it uploaded next week
[18:46] <astraljava> Hey all, I know this is a bit out of the scope for this channel, but since none of the "support" channels can help in this, I wonder whether any developer could spare a couple of their brain cycles and tell me where I can save applications into a session, the functionality that used to be in Startup Applications. This is natty we're talking about.
[19:09] <hv> What does cannonical/ubuntu use for conference planning?
[19:09] <hv> what software or service, that is
[19:12] <slangasek> which aspects of planning are you referring to?
[19:12] <slangasek> there's the summit.ubuntu.com software
[19:12] <slangasek> most of the logistical planning of the conferences themselves is done in wetware, not software :)
[19:15] <hv> umm, I am looking for a simple but good conference planning (at least, should handle online registrations + payments)
[19:16] <broder> hmm...who's responsible for http://reports.qa.ubuntu.com/reports/sponsoring-stats/? the most recent data point on # of entries in the queue is 10 or so. while that would be *awesome*, there are actually about 70 things in the queue
[19:18] <hv> is summit.ubuntu.com available for external use (possibly paid)?
[19:18] <slangasek> hv: Ubuntu conferences have no associated registration fees, so I don't think that'll be much help :-)
[19:19] <broder> hv: maybe look at what linux plumbers is using?
[19:19] <broder> theirs definitely does online registration + payments
[19:19] <hv> slangasek, broder: thanks
[19:20]  * hv wishes academic conferences do away with registration fees ...
[19:22] <nigelb> hv: summit.ubuntu.com code is open source
[19:22] <nigelb> If you want to run it for your own conference that's totally fine
[19:23]  * nigelb reads scrollback.
[19:26]  * hv bzr branches summit ...
[19:29] <nigelb> hv: #ubuntu-website would be the right place to ask for doubts/questions you may have
[19:29] <hv> nigelb: thanks.
[19:58] <jono> it seems GNOME Settings Daemon is broken in Oneiric - is this known?
[19:59] <RoAkSoAx> jono: what's your issue?
[20:01] <seb128> jono, no
[20:15] <RoAkSoAx> cjwatson: in the mini-disk info file, http://pastebin.ubuntu.com/628555/, will the release always appear as "oneiric" or will it be "Oneiric Ocelot" and the arch will always be i386 or "Beta i386" as it shows with the regular server ISO?
[20:19] <Ampelbein> hi! I'm trying to find the cause for a FTBFS on current oneiric, the package in question is gridsite. This is the log: http://paste.ubuntu.com/628557/ - The package builds fine on debian/unstable. Can someone give any hints on what might be wrong?
[20:22] <micahg> Ampelbein: looks like an --as-needed failure
[20:23] <slangasek> I don't see how
[20:23] <slangasek> these are from libcrypto, which is on the commandline
[20:23] <slangasek> btw, someone seems to have typoed '-D_LARGEFILE64_SOURCE' :)
[20:24] <Ampelbein> micahg: hmm, you are right. with -Wl,--no-as-needed it works... but... why?
[20:25] <micahg> Ampelbein: with --as-needed order of the arguments matter, http://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries
[20:25] <slangasek> true, but -lgridsite -lssl -lcrypto is the correct order :)
[20:26] <slangasek> so why does *this* fail?
[20:26] <slangasek> oh, no
[20:26] <slangasek> it's that gridsite-storage.c doesn't need libcrypto, libgridsite.so does
[20:26] <slangasek> so -lcrypto needs to be passed when linking *libgridsite.so*
[20:27] <slangasek> it's a mislinked library, which gets exposed when trying to link against it
[20:27] <slangasek> (and also, btw, in a dpkg-shlibdeps warning that's been in the log output for several years before this I'm sure)
[20:28] <slangasek> oh, it's an entirely new package, so scratch the "several years" part :-)
[20:28] <Ampelbein> slangasek: I was about to say that it never actually built in ubuntu ;-)
[20:29] <Ampelbein> micahg, slangasek: thank you, with your help I found the error.
[20:29] <Ampelbein> I think
[20:36] <Ampelbein> ok, yes. so the root of the problem was that http://paste.ubuntu.com/628565/ made libgridsite.so not correctly linked with crypto (and xml2). adding -lcrypto and -lxml2 AFTER the objects made the compile succeed. Thanks again micahg and slangasek!
[20:36] <slangasek> sure :)
[20:56] <Daviey> slangasek: I've seen you mention this a few times, so i wanted to clarify something.. regarding calling an upstart reload... I understand in package maintainer scripts should invoke-rc.d.. but what about debian/*logrotate scripts?
[20:56] <Daviey> Is it ok for them to call "reload" directly?
[20:57] <slangasek> Daviey: it's ok, but it does increase the delta with Debian
[20:58] <slangasek> Daviey: '/etc/init.d/$service reload' should do the same thing in both Debian and Ubuntu, with an insignificant increased overhead for Ubuntu
[20:58] <Daviey> slangasek: TBH.. one line change in a fairly hunky delta anyway, doesn't make me cry so much :)
[20:58] <slangasek> yeah... general principle though :)
[20:58] <smoser> you should drop that change though
[20:58] <smoser> yeah.
[20:58] <smoser> i just assumed that 'reload' wasn't going to do anything for upstart... or that there was some other reason that it was like it was.
[20:58] <Daviey> smoser: it's your merge proposal!
[20:59] <smoser> yes, and i will admit that i'm wrong.
[20:59] <smoser> or that i should have dropped that.
[20:59] <Daviey> smoser: Oh no, i wasn't pointing fingers.
[20:59] <smoser> but i dont tihnk it ever should have been added.
[20:59] <Daviey> smoser, agreed - but there is clearly some uncertainity about handling upstart in scripts.
[21:00] <smoser> i can modify my proposal if you want
[21:00] <Daviey> So the original delta introduction wasn't evil either.
[21:00] <smoser> that was one of the only things that wasn't straight forward to me.
[21:01] <Daviey> smoser: I don't really care TBH.. both work, and 1 line isn't a big deal.. especially as it's not totally /wrong/
[21:01] <smoser> if we drop it, and theres no regression due to it, then the next person wont be confused or have to think about it.
[21:01] <Daviey> as we seem to have no clear policy on this
[21:01] <smoser> well, the policy that is clear is "don't change debian just because"
[21:01] <Daviey> heh
[21:02] <Daviey> smoser: there are two uses of that, that changes everything... do it!
[21:06] <smoser> Daviey, revision 43 pushed up
[21:14] <Daviey> ta
[21:15] <smoser> oh shoot
[21:16] <smoser> yea...
[21:16] <smoser> so Daviey , slangasek debian now has:
[21:16] <smoser>  invoke-rc.d rsyslog rotate
[21:16] <smoser> not 'reload', but 'rotate'.
[21:17] <slangasek> that's not a standard argument at all
[21:17] <smoser> and they have a target for that in the init script that sends -HUP
[21:17] <smoser> right
[21:17] <smoser> so we have a delta in that file one way or another
[21:17] <slangasek> do they have a different definition of 'reload' in the init script?
[21:17] <smoser> and 'reload rsyslog' will send -HUP
[21:17] <smoser> no, they dropped the 'reload'
[21:18] <smoser> only 'force-reload' now, which does 'stop; start'
[21:18] <slangasek> ...
[21:18] <smoser> its in their changelogs too... i knew i had some reason for this to be left as it was
[21:18] <Daviey> smoser: i thought i saw rotate, i was *just* checking that
[21:19] <smoser> rotate was in the merged stuff from debian
[21:19] <smoser> it changed between that.
[21:19] <smoser> so then... i ask slangasek, i think. we're back to having a choice between:
[21:19] <smoser> reload rsyslog
[21:19] <smoser> or
[21:20] <smoser> invoke-rc.d rsyslog reload
[21:20] <smoser> where the invoke-rc.d path is still delta from debian
[21:20] <slangasek> smoser: I think the init script should ditch this silly non-standard option, and the logrotate script should call 'kill -HUP $(cat /var/run/rsyslogd.pid)' directly in Debian, which would happen to work right in Ubuntu as well
[21:21] <slangasek> and we should never call invoke-rc.d from logrotate scripts
[21:21] <Daviey> smoser: sounds to me that leaving it as it was makes better sense, and raising a debian bug suggesting reload does a -HUP :)
[21:21] <Daviey> slangasek: ok?  why never call invoke-rc.d from logrotate scripts?
[21:22] <slangasek> Daviey: the reason not to do a HUP with reload in the init script is that it doesn't actually reload the configs, so doesn't fit the definition of the target (Debian bug #580897, Policy 9.3.2)
[21:23] <slangasek> Daviey: because invoke-rc.d is used to apply a local admin policy on whether maintainer scripts are allowed to start and stop services, which is entirely irrelevant to the question of whether a running daemon needs to reopen logfiles after rotation
[21:23] <slangasek> at best, invoke-rc.d is a no-op; at worst it causes you to lose your log data
[21:23] <Daviey> *sigh*
[21:23] <smoser> ok.
[21:23] <smoser> i'll push up the revert of that.
[21:24] <slangasek> no-op compared to direct invocation of the init script, I mean
[21:25] <Daviey> slangasek: yeah, thanks for that
[21:26] <Daviey> smoser: BTW, your regular commit approach makes it much easier to review (and presumably useful to peeps in the future).  Thanks.
[21:30] <smoser> pushed again
[22:34] <natschil> Hello. I made a kind of custom ubiquity (i.e. added one or two lines), and I was wondering if anyone could tell me whether ubiquity is run as root or not, as the code in question needs to mount stuff and thus would need to run with certain privilidges