[02:44] <robert_ancell_> how do I get a build to restart?  I updated file-roller a few days ago and it failed to build due to libgtk being broken at the time (https://edge.launchpad.net/ubuntu/+source/file-roller/2.29.2-0ubuntu1)
[02:51] <RAOF> robert_ancell: Does https://edge.launchpad.net/ubuntu/+source/file-roller/2.29.2-0ubuntu1/+build/1378313 have a "rebuild" button for you?  I think that's where it'd be (I don't have main priviledges, so I can't see it)
[02:53] <robert_ancell> RAOF, no it doesn't for me.  I only have MOTU privileges but I don't have a rebuild option for Universe packages either
[02:53] <ScottK> robert_ancell: Is it just amd64 or all archs you want done?
[02:54] <robert_ancell> ScottK: all arches for this one.  I also did an xscreensaver one a while back that needs rebuilding for ia64 and sparc
[02:58] <ScottK> robert_ancell: file-roller retried on all archs
[02:59] <robert_ancell> ScottK, thanks.  This seems to happen quite a lot - do I just ping someone with main privileges when it occurs?
[02:59] <ScottK> Yep.
[03:05] <Amaranth> weird, robert_ancell should be able to trigger a rebuild of file-roller
[03:05] <Amaranth> since he has ubuntu-desktop access
[03:05] <Amaranth> I can trigger rebuilds of compiz, anyway
[03:06] <Amaranth> maybe the extra layer of indirection screws it up
[03:06] <robert_ancell> Amaranth, how do you trigger them?
[03:06] <Amaranth> robert_ancell: iirc from the build page, let me check the armel failed build to be sure
[03:07] <robert_ancell> Amaranth, they've all failed build but at least now I can see the problem
[03:07] <Amaranth> robert_ancell: on https://edge.launchpad.net/ubuntu/+source/compiz/1:0.8.4-0ubuntu6/+build/1379618 I have a "Retry this build" option
[03:07] <robert_ancell> Amaranth, I don't
[03:08] <Amaranth> is compiz in the ubuntu-desktop set? it should be but you never know
[03:08] <robert_ancell> Amaranth, not sure but file-roller definitely is (I did the upload directly)
[03:09]  * Amaranth looks for something in universe that failed to build
[03:09] <jmarsden> Amaranth: Yes, you can do   tasksel --task-packages ubuntu-desktop | grep compiz     # to check
[03:09] <micahg> is there a place where I can see the list of stuff waiting to be approved for -proposed?
[03:09] <Amaranth> jmarsden: Is that the same data launchpad uses for permissions?
[03:10] <jmarsden> Amaranth: I have no idea :)  As a user/sysadmin, it is how I check what is in the various task bundles...
[03:10] <robert_ancell> Amaranth, can you see a rebuild option here: https://edge.launchpad.net/ubuntu/+source/xscreensaver/5.10-3ubuntu1/+build/1375403
[03:10] <Amaranth> no
[03:10] <Amaranth> did ScottK already trigger a rebuild for that though?
[03:11] <ajmitch> no
[03:11] <ajmitch> it shows up for me
[03:11] <Amaranth> oh, it's in main
[03:11] <ScottK> Amaranth: No, I just did file-roller
[03:11] <ajmitch> (since I'm in core-dev)
[03:11] <Amaranth> I only have compiz and MOTU access :)
[03:11] <ajmitch> maybe you can retry compiz builds because of direct permissions to upload it
[03:11] <Amaranth> right
[03:11] <micahg> ScottK: is there a place where I can see the list of stuff waiting to be approved for -proposed?
[03:12] <Amaranth> but motu access is based on teams too so it's a bug caused by robert_ancell only having access via a team you'd think it'd be broken there too
[03:12] <Amaranth> so if it's*
[03:12] <robert_ancell> Amaranth, how come you see them for compiz?
[03:12] <ajmitch> motu access is based on the component, I think the packe sets are overlaid on that
[03:12] <Amaranth> robert_ancell: I have direct compiz upload permissions
[03:12] <ajmitch> it's all confusing :)
[03:13] <Amaranth> ok, so it most likely is a bug caused by robert_ancell only having access via a team
[03:13] <ajmitch> possibly
[03:13] <robert_ancell> ajmitch, totally :)
[03:13] <ajmitch> file a bug about it :)
[03:13]  * Amaranth points to robert_ancell
[03:14] <robert_ancell> anyone know what to file against?  LP?
[03:14] <ScottK> micahg: launchpad.net/ubuntu/[release] and click on uploads and look at unapproved
[03:14] <ajmitch> either LP or against soyuz, I think
[03:14] <micahg> ok, ScottK, thanks :)
[06:16] <slytherin> anyone who maintains linux-ports-meta package? We need a version bump for this package in karmic-security.
[06:43] <evolio_> hi guys
[06:43] <evolio_> is there a reason why no vpn clients are shipped by default in ubuntu?
[06:43] <evolio_> for networkmanager
[06:49] <crypt-0> no idea
[06:49] <crypt-0> the devs seem to be asleep
[06:50] <RAOF> evolio_: The immediate answer is: there aren't any network manager vpn clients in main.
[06:52] <RAOF> A fuller answer will include: they're not in main because no one has asked for (and done the security/code maintenance/upstream health check/etc) them to be in main.
[06:58] <crypt-0> still no update for jre in 9.10
[06:58] <crypt-0> stuck at 1.6.16
[06:59] <crypt-0> hardy has had 1.6.17 for  almost a week now
[07:02] <slangasek> james_w: I have an awesome failure mode for bzr merge-package w/ brltty
[07:14] <dholbach> good morning
[07:25] <siretart`> slangasek: teaching upstream symbol versioning is both fun and exhausting :-)
[07:28] <pitti> Good morning
[07:36] <crypt-0> good night.
[07:37]  * crypt-0 is waiting for cryptsetup 1.10 to be finalized, its still at RC3
[07:37] <crypt-0> then a suspend could ask for the passphrase/keyfile
[07:39] <crypt-0> and SHA1 hashes will be no more, any supported by libgcrypt (SHA2, and Whirlpool sound nice)
[08:37] <pitti> james_w: the python-launchpadlib packaging bzr branch is horribly out of date; I'll just redo it from scratch and import the current packaging, branching from upstream; hope you don't mind?
[08:38] <pitti> (it was also missing files from upstream)
[08:43] <micahg> mdke: ping
[08:43] <mdke> micahg: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back)
[08:46] <micahg> mdke: nevermind
[09:10] <slytherin> What does it take to bump version for linux-ports-meta package so that it depends on latest version form karmic-security?
[09:45] <tseliot> cjwatson: where do you deal with "safe mode" (i.e. vesa) in ubiquity?
[09:45] <tseliot> I mean, the boot option
[10:09] <cjwatson> ogra: I didn't touch them
[10:09] <cjwatson> slytherin: it's all calculated from the changelog version
[10:09] <cjwatson> tseliot: I'm not sure we do at the moment, but we need to
[10:10] <slytherin> cjwatson: So someone will have to bump the version for ports-meta right?
[10:10] <cjwatson> tseliot: actually, is "safe mode" still needed? can we use bullet-proof-x instead? we have a spec that calls for that ...
[10:10] <cjwatson> slytherin: yes
[10:11] <slytherin> cjwatson: TheMuso usually bumps the version for ports-meta. But he is not around. Any idea who is the best person?
[10:12] <slytherin> I mean 'next best person'.
[10:12] <tseliot> cjwatson: we were discussing the use case in which you need to pass vesa and nomodeset. Bullet-proof-x wouldn't work in this case
[10:13] <cjwatson> tseliot: but we don't pass nomodeset anywhere right now?
[10:13] <tseliot> cjwatson: right but we might need to
[10:14] <tseliot> cjwatson: otherwise vesa may fail
[10:15] <cjwatson> hm, ok. will need to update foundations-lucid-gfxboot-updates for that
[10:15] <tseliot> cjwatson: thanks
[10:23] <ogra> cjwatson, armel squashfs builds currently die with:
[10:23] <ogra> Can't find a SQUASHFS superblock on livecd.ubuntu-imx51.squashfs
[10:23] <ogra> Failed to read existing filesystem - will not overwrite - ABORTING!
[10:24] <ogra> cjwatson, any objection to me adding a rm before the mksquashfs call so we make sure there is no existing squashfs around ?
[10:24] <ogra> (in livecd-rootfs)
[10:25] <cjwatson> ogra: fine by me
[10:25]  * ogra wonders if there is a reson that we dont have that yet
[10:25] <ogra> great :)
[10:26] <cjwatson> (rm -f, please)
[10:26] <ogra> indeed :)
[10:44] <tseliot> cjwatson: I'm forwarding you the email in which we're discussing the safe mode thing
[10:49] <lool> When is meta-release usually updated to list the new devel release?
[10:49] <lool> after A1 or before A1?
[11:00] <lool> Hmm I see lucid in -development
[11:09] <lucas> I'd like to ask for the removal of some packages (~100) that are not in debian, have not been updated in ubuntu since hardy, and have a low popcon. What would be the best way to give the list of those packages? 1 LP bug/package sounds suboptimal
[11:10] <lool> lucas: main + universe?
[11:10] <lool> lucas: Perhaps you should send a list of candidates to ubuntu-devel?
[11:10] <lucas> universe+multiverse, as a first step
[11:10] <ogra> ++
[11:10] <lool> or -motu if you start with -universe+-multiverse
[11:11] <lucas> ok, will do that
[11:17] <pitti> eww, macaroni (ddebs.u.c.) ran out of space
[11:19]  * pitti kills intrepid
[11:31] <ogra> The following packages have unmet dependencies:
[11:31] <ogra>   python-wadllib: Depends: python-lazr.uri but it is not installable
[11:31] <ogra> E: Broken packages
[11:31] <ogra> GRMPF ...
[11:32] <pitti> hm, they all have replaces/conflicts
[11:32] <ogra> mind the dot
[11:32] <pitti> yeah, they were renamed in Debian unfortunately
[11:32] <ogra> looks like a typo on first sight
[11:32] <pitti> no, that was intentional (although not exactly clever)
[11:33] <ogra> i didnt know dots in package names are even allowed
[11:33] <pitti> but it should remove lazr-uri and install lazr.uri
[11:33] <lool> ogra: openoffice.org
[11:34] <ogra> lool, oh, right
[11:34] <ogra> ogra@osiris:~$ apt-cache madison python-lazr.uri
[11:34] <ogra>   lazr.uri |    1.0.2-1 | http://de.archive.ubuntu.com lucid/main Sources
[11:34] <ogra> ogra@osiris:~$
[11:34] <ogra> hmm, there doesnt seem to be a binary at least my machine thinks so
[11:37] <pitti> ogra: ah, so perhaps you just need to wait a little until the mirror synced up
[11:37] <ogra> hmm, k
[11:37] <pitti> some two hours ago I uploaded a new p-launchpadlib and ubuntu-dev-tools to finish the migration
[11:37] <ogra> ok, i just tried a local livefs build ... so i'll wait
[11:40] <ogra> hmm, but LP says python-lazr.uri built two days ago already
[11:40] <ogra> ogra@osiris:~$ LANG=C apt-cache show python-lazr.uri
[11:40] <ogra> W: Unable to locate package python-lazr.uri
[11:40] <ogra> E: No packages found
[11:41] <ogra> according to https://launchpad.net/ubuntu/+source/lazr.uri/1.0.2-1/+build/1379851 python-lazr.uri_1.0.2-1_all.deb should exist though
[11:41] <pitti> oh, hang on
[11:41] <pitti>         500 http://archive.ubuntu.com lucid/universe Packages
[11:41] <ogra> http://archive.ubuntu.com/ubuntu/pool/main/l/lazr.uri/ disagrees
[11:41] <ogra> aha !
[11:42] <pitti> someone NEWed it to universe
[11:42]  * pitti promotes
[11:42] <ogra> thanks !
[11:42] <pitti> with restfulclient
[11:42] <pitti> done
[11:43] <cjwatson> I dumped it into universe largely automatically since it was a sync from Debian
[11:50] <pitti> StevenK: haha! yada wants to go back to main, thanks to libapache2-mod-auth-pam
[11:55]  * soren shudders
[12:55] <geser> ScottK: does your ACK to bug 490731 imply that I can proceed with upload?
[13:27] <StevenK> pitti: Yeah, I've been working on it.
[13:52] <ScottK> geser: Yes.
[14:11] <ttx> cjwatson: At this point it's expected that the NC installer can't find the preseed file from the CC, right ?
[14:11] <cjwatson> ttx: hmm, no?
[14:11] <ttx> hm
[14:11] <cjwatson> I did rename it but I thought I put it all the necessary aliases
[14:11] <cjwatson> s/put it/put in/
[14:12] <cjwatson> and indeed the NC tries the old name as well
[14:12] <ttx> cjwatson: I installed a Lucid alpha1 CLC+CC+Walrus+SC and tried to install an NC
[14:13] <ttx> cjwatson: it doesn't seem to get a preseed file. When I tried the 9.10 NC installer, euca_find_cluster doesn't find anything
[14:13] <cjwatson> anything useful in logs?
[14:13] <ttx> cjwatson: I'll retry now that I know it /should/ be working
[14:14] <ttx> with the 9.10 installer, euca_find_cluster doesn't return an IP address
[14:15]  * ttx tries again
[14:15] <pitti> cjwatson: do you have any objections/gotchas wrt. bug 493139? if not, I'm happy to do the change in bzr now
[14:18] <apw> mvo, do we have update-manager -d to lucid yet?
[14:18] <mvo> apw: not quite yet, but I want to enable it today
[14:19] <apw> that'd explain why it doesn't work then, ok, by hand it is
[14:19] <ogra> pitti, hrm
[14:19] <ogra> The following packages have unmet dependencies:
[14:19] <ogra>   python-lazr.uri: Conflicts: python-lazr-uri (< 1.0.2-1) but 1.0-0ubuntu1 is to be installed
[14:19] <ogra> E: Broken packages
[14:19] <ogra> thats what i get now
[14:20] <cjwatson> pitti: ym "decreases boot speed" or "increases boot time" in that bug, I think ;-)
[14:20] <ogra> so there is still something out of sync
[14:20] <ttx> cjwatson: ignore me. The CC publication was borked, probably due to bug 493523 preventing it to start on first boot. Now that it's rebooted, it is detected correctly
[14:20] <cjwatson> pitti: fine by me, go ahead and commit
[14:20] <mvo> apw: if you wait a little bit I fix it and you can test?
[14:20] <pitti> cjwatson: erm, yes :)
[14:20] <cjwatson> ttx: oh good
[14:20] <apw> mvo how long?
[14:20] <ttx> cjwatson: NC install is still failing due to bug 493582, but that's an easy fix
[14:20] <mvo> apw: now
[14:20] <mvo> apw: :)
[14:21] <apw> ok that works as i want to test something on lucid today
[14:21] <mvo> apw: ok, its just a server side thing, I have karmic->lucid enabled now (for update-manager -d or do-release-upgrade -d)
[14:22] <mvo> apw: please let me know if it works (and how well)
[14:22] <apw> well it appears, that is a start
[14:22]  * apw hits it
[14:25] <apw> mvo, its not eaten my machine yet, which is something
[14:26] <apw> mvo 752 packages to download, so its doing something
[14:26] <mvo> good, good :)
[14:30] <cjwatson> jdstrand: see my comment on bug 493582 for a simpler proposed implementation
[14:32] <cjwatson> ttx: how would I go about exposing a preseed file on a machine running only a CLC?
[14:33] <cjwatson> ttx: a CLC-only machine doesn't seem to run apache, at least as far as I can see
[14:33]  * pitti pushes the 12th MB of ubiquity branch data to LP... I thought stacked branches would avoid that..
[14:34] <cjwatson> you can just commit directly to ~ubuntu-core-dev/ubiquity/trunk you know?
[14:34] <cjwatson> oh, no you can't
[14:34] <cjwatson> it's ~ubuntu-installer
[14:34] <pitti> right; I'll just submit a MP
[14:34] <cjwatson> ok
[14:34] <jdstrand> cjwatson: ack
[14:35] <ttx> cjwatson: it should be running jetty, I'll have to look in more details how to make it serve a static file
[14:35] <cjwatson> aha
[14:35] <cjwatson> this is the last major thing blocking completion of foundations-lucid-uec-installer-enhancement :)
[14:38] <pitti> cjwatson: just to avoid a1 damage, do you plan to merge console-setup for alpha-1?
[14:39] <cjwatson> probably not - a2
[14:39] <mdz> cjwatson: I noticed that grub still has last-good-boot cruft in it. would it be a good idea to strip that out for lucid?
[14:39] <pitti> (currently uploaded xorg assumes that the keyboard layout is still in /etc/default/console-setup)_
[14:39] <pitti> cjwatson: ok, thanks
[14:39] <cjwatson> mdz: only grub 1, I think?
[14:39] <mdz> cjwatson: oh, you may be right. I am still on grub 1 on this system as upgrading to grub2 failed
[14:39] <cjwatson> mdz: I'm sure it wouldn't hurt, although I want to avoid caring about grub 1 as much as possible
[14:40] <mdz> cjwatson: confirmed, it's only in grub 1
[14:40] <mdz> (though it's left behind in conffiles on my grub2 systems)
[14:41] <mdz> it should be inert in any case
[14:48]  * cjwatson wades through incomprehensible XML configuration
[14:49] <ttx> cjwatson: for the jetty thing ?
[14:49] <cjwatson> ys
[14:49] <cjwatson> yes
[14:49] <ttx> cjwatson: we must be looking at the same page :)
[14:49] <cjwatson> http://jetty.mortbay.org/apidocs/index.html is not really the sort of help interface I want for this kind of thing
[14:50] <cjwatson> I have http://docs.codehaus.org/display/JETTY/Static+Content, but it doesn't help with serving just a single file
[14:50] <ttx> cjwatson: it's probably a matter of dropping a modified http://docs.codehaus.org/display/JETTY/Static+Content snippet into /etc/eucalyptus/cloud.d/www/
[14:50] <ttx> cjwatson: I'll test it locally
[14:50] <cjwatson> I don't want to serve all of /etc/eucalyptus/ though, just one file
[14:50] <ttx> cjwatson: right
[14:50] <cjwatson> and symlinking would involve turning off alias detection which the help warns against
[14:51] <ttx> cjwatson: does the preseed file *have to* be in /etc/eucalyptus to be served downstream ?
[14:52] <ttx> cjwatson: I mean components could fetch it from CLC's /etc/eucalyptus/preseed directory and copy it to /etc/eucalyptus
[14:52] <cjwatson> ttx: its filesystem location doesn't matter at all
[14:53] <ttx> might end up having two copies on CLC+* setups
[14:53] <cjwatson> let's not
[14:53] <cjwatson> we should serve it from a single place
[14:53] <cjwatson> I don't care where that place it
[14:53] <cjwatson> is
[14:53] <cjwatson> but there's no sane reason to have two copies
[14:53] <cjwatson> Apache can Alias it from anywhere
[14:55] <ttx> cjwatson: ok. I'll test a snippet as soon as I'm done with that alpha1 test
[14:56] <cjwatson> ttx: I was actually hoping to get the CLC preseed file stuff into a1, indeed ;)
[14:56] <ttx> cjwatson: sure, I just want to make sure i caught the biggest existing showstoppers first :)
[15:01] <pitti> cjwatson: ah, it's finally uploaded (ugh); MP sent
[15:06] <pitti> ogra: that's from a dist-upgrade?
[15:07] <ogra> pitti, livefs testbuild
[15:07] <pitti> ogra: anything which still depends on python-lazr-uri?
[15:07] <ogra> i dont see python-launchpadlib
[15:07] <ogra> the one you uploaded
[15:08]  * pitti checks
[15:08] <pitti> right, seems it's not built
[15:08] <pitti> Missing build dependencies: python-lazr.restfulclient
[15:08] <pitti> that would be because it was in universe
[15:09] <pitti> now it's in main, so it should work now; rebuilding
[15:09] <ogra> thanks
[15:10] <pitti> ogra: thanks for pointing out; should be good in 2 hours
[15:11] <ogra> :)
[15:12]  * pitti NBS-removes the old package names
[15:16] <fagan> mpt: in the software center in lucid I found a funny piece of text. "it is used by 1 piece of installed software" it seems like a very strange choice of words
[15:17] <mpt> fagan, the text "it is used by" is not present anywhere in <https://wiki.ubuntu.com/SoftwareCenter>, so it's a bug one way or another :-)
[15:17] <mpt> Most likely, it's something that isn't specified yet
[15:18] <mpt> fagan, so please report it
[15:18] <mpt> preferably with a screenshot
[15:18] <fagan> cool I will
[15:18] <mpt> thanks
[15:18] <fagan> ill have a look for it and make a patch too if thats ok
[15:20] <ttx> cjwatson: with http://pastebin.ubuntu.com/336616/ as /etc/eucalyptus/cloud.d/www/preseed.xml, it will serve https://CLC:8443/preseed/hello
[15:21] <ttx> ...it will serve /etc/eucalyptus/preseed/hello when asked for https://CLC:8443/preseed/hello
[15:25] <ScottK> cjwatson: We uploaded a new qt4-x11 over the weekend.  It still FTBFS on armel, but it's no longer an ICE.  The error now is /tmp/ccQlrjoC.s: Assembler messages: /tmp/ccQlrjoC.s:6402: Error: selected processor does not support `swp r6,r4,[r3]' - I was thinking it might be helpful to try the Thumb workaround you suggested/tried on the previous release again?
[15:33] <cjwatson> ttx: ok, something like that should be workable. thanks!
[15:33] <cjwatson> ScottK: yes, I think so, that sounds more like https://wiki.ubuntu.com/ARM/Thumb2
[15:33] <ScottK> cjwatson: Would you be able to try this (no hardware here)?
[15:34] <cjwatson> ScottK: ok
[15:34] <ScottK> Thank you.
[15:48] <fagan> mpt: Bug #493618
[15:49] <mpt> thanks fagan
[15:49] <fagan> np
[16:07] <ogra> Keybuk, did anyone check plymouth with std framebuffers (i.e. i'm intrested if its supposed to work on armel)
[16:07] <Keybuk> ogra: I don't have the hardware
[16:08] <ogra> well *should* it work with non KMS HW ?
[16:08] <Keybuk> should do, yes
[16:08] <ogra> ok
[16:08] <Keybuk> it has a framebuffer backend
[16:08] <Keybuk> if it doesn't, it should be easy to fix
[16:08] <ogra> perfect, then it should just work
[16:09] <Keybuk> I've only tested it with the vga16fb - and that required some porting of code from BOGL into it to make it work with the reduced colours
[16:09] <LaserJock> ogra: where was lucas' list of possible archive removals sent?
[16:09] <Keybuk> (not in the code I uploaded yet)
[16:09] <ogra> yeah, i'll report back in case i see breakage
[16:09] <ogra> LaserJock, -motu
[16:09] <Keybuk> I've had it working with i915.modeset=0 as well
[16:09] <ogra> we have full coulor support on the arm platforms we support
[16:09] <ogra> (X runs in framebuffer too)
[16:10] <ogra> so that shouldnt be an issue
[16:29] <fagan> mpt: what else is planned for this cycle for the software center?
[16:30] <mpt> fagan, <https://wiki.ubuntu.com/SoftwareHandling> has a "Work for Lucid" section that links to the various blueprints
[16:30] <mpt> fagan, and the blueprints in turn link to the relevant sections of <https://wiki.ubuntu.com/SoftwareCenter>
[16:30] <fagan> Cool I just want to have an idea so I can test the features as they land
[16:31] <mpt> fagan, if you want to try implementing something small yourself, <https://wiki.ubuntu.com/SoftwareCenter#features>
[16:31] <mpt> fagan, if you want to test and report bugs, you don't need to wait for new features to land -- there are plenty of unreported bugs in the existing features :-)
[16:32] <fagan> :) true
[16:32] <fagan> ill have a look and ping if I have any questions
[16:32] <mpt> Many of the paragraphs in the specification have test cases
[16:32] <mpt> I'll add more as I have time
[16:32] <mpt> thanks for helping out!
[16:32]  * fagan trys to find the dodgy string 
[16:34] <ueu001> Will we have packagekit,devicekit,policykit in lucid ?
[16:35] <fagan> mpt: It is used by %s piece of installed software."
[16:35] <fagan> What would be better than that?
[16:35] <mpt> fagan, first I need to know what it's there for
[16:35] <mpt> Is it something to do with dependencies?
[16:35] <fagan> yep
[16:36] <fagan> for packages
[16:36] <fagan> I think it should be "This package is used by...
[16:36] <mpt> So does it mean "X other packages depend on this one?" (not saying that's a good replacement, just trying to understand it)
[16:36] <fagan> It does
[16:37] <fagan> There are also recommended and suggested strings too
[16:37] <mpt> So if you click "Remove", you should get the alert shown here <https://wiki.ubuntu.com/SoftwareCenter#removing>
[16:37] <mpt> Do you?
[16:38] <fagan> nope is shows that in the info
[16:38] <pitti> mbiebl, Keybuk: Debian's dbus installs the library into /lib now, but the daemon is still in /usr/bin/; does upstart need the daemon in /bin, too?
[16:38] <fagan> I attached a screenshot to the bug of how it looks now
[16:38]  * pitti isn't sure whether to keep our change for this
[16:39] <Keybuk> pitti: no, doesn't need the Daemon
[16:39] <Keybuk> though if Debian put it in /bin now, we don't *need* it in /usr
[16:39] <mpt> fagan, ok, so it's a bug to report that that alert isn't implemented -- we can remove the need for it in the software item screen itself by showing the information inline, but not everyone will be on that screen when they choose to remove the item.
[16:40] <pitti> Keybuk: other way round; we install the daemon into /bin so far, but Debian doesn't
[16:40] <Keybuk> pitti: oh right
[16:40] <pitti> Keybuk: Debian only moved the library to /lib, not the rest
[16:40] <Keybuk> ah
[16:40] <Keybuk> I remember
[16:40] <Keybuk> things break if you have /usr-on-NFS if dbus isn't in /
[16:40] <Keybuk> since you need D-Bus to get networking
[16:40] <pitti> ah, alrighty
[16:40] <pitti> will move it then
[16:41] <pitti> but adapt our changes to use the debian configure flags, so that our delta gets smaller
[16:41] <Keybuk> *nods*
[16:41] <fagan> mpt: ah, so we should have some sort of alert that they are removing something that has a depends on that package
[16:41] <fagan> But not of suggests or reccomends
[16:41] <mpt> fagan, yes, i.e. the alert shown in step 5 in the spec
[16:42] <mpt> fagan, Suggests and Recommends, I don't know
[16:42] <mpt> Some collected examples of that situation might make that easier to design
[16:44] <fagan> Well a program might suggest or reccomend a plugin but it doesnt affect the program if its not installed. So I dont think we need an alert for them
[16:47] <ScottK> fagan: If it doesn't affect the program, it probably shouldn't be recommends.
[16:48] <fagan> hmmm I always thought that recommends was just a slightly more important suggests
[16:50] <ScottK> No, recommends should be installed except in unusual circumtances.  Suggests is pure nice to have.
[16:50] <fagan> Oh
[16:51] <fagan> So then maybe we should warn if a reccomended package is removed
[16:52] <fagan> mpt: should we be using the word "package" or is that a term humans would have trouble with?
[16:53] <mpt> fagan, see <https://wiki.ubuntu.com/SoftwareCenter#def-software-item> for why we don't refer to "packages" unless we're really sure that's what we mean
[16:53] <mpt> fagan, having said that, it might make sense to use "package" in that specific case, because it's packages which are dependent, not software items
[16:54] <fagan> mpt: thats what I was thinking
[16:54] <fagan> (because we are refering to the packages themselves)
[16:56] <fagan> I have a patch if you want to switch from "pieces of installed software" to "installed packages"
[16:56] <fagan> mpt: ^ is that good?
[16:57]  * fagan attaches it to the bug report
[16:57] <mpt> fagan, changing it to "installed software packages" would be better than it is now. The next step would be thinking about whether it should list the dependent packages somewhere.
[17:00] <cjwatson> ScottK: I'm afraid -Wa,-mimplicit-it=thumb makes no difference to the build failure on qobject.cpp
[17:01] <fagan> mpt: Oh ill upload a patch for that then
[17:01] <ScottK> cjwatson: OK.  Thanks for checking.  I guess I'll see if I can punt this back to NCommander then.
[17:01] <mpt> thanks fagan
[17:02] <cjwatson> ScottK: the assembler output indicates that the problem is in explicit asm on line 361 of src/corelib/arch/qatomic_arm.h
[17:02] <cjwatson> ScottK: https://wiki.ubuntu.com/ARM/Thumb2 has advice for dealing with those
[17:02] <ScottK> Thanks.
[17:04] <fagan> mpt: the attachment .diff is on Bug #493618
[17:04] <mpt> thanks
[17:07] <cjwatson> ScottK: I think possibly telling Qt to use armv6 not merely arm might help
[17:08] <cjwatson> ScottK: trying that now ...
[17:08] <ScottK> Excellent.  Thanks.
[17:09] <ogra> cjwatson, or -marm
[17:10] <pitti> ogra: p-launchpadlib is in now; should work now
[17:10] <ogra> that will keep v7
[17:10] <ogra> pitti, will try a build soon
[17:12] <cjwatson> ogra: qt has explicit asm for armv6 which differs from arm
[17:12] <cjwatson> ogra: I don't mean the gcc architecture
[17:13] <ogra> ah
[17:13] <cjwatson> ogra: the armv6 asm looks at least a bit closer to the recommendations in the wiki page
[17:13] <ogra> i though you did :)
[17:13] <ogra> yeah
[17:18] <cjwatson> ScottK: I note that qt4-x11/debian/rules does not set DEB_HOST_ARCH nor DEB_HOST_ARCH_OS despite referring to them. I wonder what the difference between -platform linux-g++ and -platform glibc-g++ is?
[17:19] <ScottK> Lex79: ^^^ didn't you do the qt4-x11 coordination with Debian?
[17:20] <ScottK> We get that unmodified from Debian, so I'm not sure.
[17:22]  * ScottK is asking the Debian maintainer.
[17:27] <cjwatson> ScottK: well, I'll tell you next week or so whether it built or not ...
[17:27] <ScottK> OK.
[17:28] <ogra> heh
[17:31] <Lex79> ScottK: the part of DEB_HOST_ARCH is a bit mess in that rules and I didn't understand what fabo has done, so I didn't touch it
[17:31] <cjwatson> it's not that complicated, it's just wrong ;-)
[17:31] <ScottK> Lex79: OK.  I asked him on #deiban-qt-kde.
[17:37] <ogra> seb128, The following packages have unmet dependencies:
[17:37] <ogra>   libgnomekbd4: Conflicts: libgnomekbdui4
[17:37] <ogra> E: Broken packages
[17:37] <ogra> getting that with a test livefs build
[17:37] <seb128> and?
[17:38] <ogra> libgnomekbdui4 doesnt seem to be built anymore at all
[17:39] <seb128> ogra, right, that's on purpose, change coming from debian
[17:39] <ogra> oh, you didnt upload gnome-c-c and gnome-applets yet, right ?
[17:39] <seb128> ogra, libgnomekbd4 provides it
[17:39] <seb128> not yet
[17:39] <ogra> yeah, but there seem to be deps still
[17:40] <ogra> which breaks my testbuilds
[17:40] <ogra> i'll wait then
[17:40] <seb128> weird that the provides doesn't work
[17:40] <highvoltage> shew I read that horribly wrong the first time
[17:40] <seb128> are you sure you picked the current version?
[17:41] <ogra> livecd-rootfs just picks whats in the archive
[17:41] <seb128> can you see what version it picked for your arch?
[17:41] <ogra> root@babbage2:/# apt-cache showsrc libgnomekbd4|grep Version
[17:41] <ogra> Version: 2.28.0-2ubuntu2
[17:41] <ogra> armel
[17:42] <seb128> showsrc will show the source
[17:42] <seb128> not the binaries
[17:42] <seb128> https://edge.launchpad.net/ubuntu/+source/libgnomekbd/2.28.0-2ubuntu2/+build/1383201
[17:42] <seb128> it built 2 hours ago only on armel
[17:42] <ogra> root@babbage2:/# apt-cache show libgnomekbd4|grep Version
[17:42] <ogra> Version: 2.28.0-0ubuntu2
[17:42] <ogra> right, publisher
[17:42] <seb128> I would not be surprised if it was not published yet
[17:42] <ogra> hmm, k
[17:43] <seb128> next run I guess
[17:43] <ogra> yep
[17:46] <jcastro> mpt: random thought, have you thought about keyboard shortcuts for USC? (I don't see any mention in the spec)
[17:48] <mpt> jcastro, yes, I plan to fill them out once it does more of Synaptic does, so that I don't end up assigning a keyboard equivalent to an early feature that would make much more mnemonic sense for a later one.
[17:48] <jcastro> ok
[17:50] <jcastro> mpt: I guess I just wanted reassurance that they'll make sense and be easy. :p
[17:51] <jcastro> like: super-i, gimp, i, y or whatever
[17:51] <jcastro> for invoke, search, install, then hit yes.
[17:51] <jcastro> something gnome do-ish
[17:52] <mpt> ah, I hadn't even thought about keyboard equivalents for sections
[17:53] <mpt> as in, a key combo for "Get Software", another key combo for "Installed Software", etc
[17:53] <jcastro> something that would make it easy to derive different bits, sort of how you can guess a URL hack for lp and it mostly is correct.
[17:57] <yofel> hi, would bug 402188 qualify for an SRU?
[17:58] <mpt> jcastro, I've made a note of that for later. <https://wiki.ubuntu.com/SoftwareCenter?action=diff&rev2=269&rev1=268>
[17:58] <jcastro> woo
[18:07] <ybit2> so why night dh_make might not be doing anything
[18:47] <apw> slangasek, i wonder if you could cast your eye over an nfs-kernel-server change i am looking to make on bug #493145 ... i am sure i am doing it wrong it being a debian package and all
[19:15] <nat2610> where can I get supprot for app development on ubuntu ?
[19:32] <tjaalton> anyone available to sync a few xorg drivers from unstable? xserver-xorg-video-apm, -ark and -neomagic are the ones that should be synced
[19:33] <cjwatson> ScottK: obviously it hasn't anywhere near finished yet, but this qt4-x11 build is well past the previous failure
[19:34] <cjwatson> ScottK: I added 'DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH)' before the stuff that uses that, and this after the ifeq ($(DEB_HOST_ARCH),arm) block:
[19:34] <cjwatson> ifeq ($(DEB_HOST_ARCH),armel)
[19:34] <cjwatson>         extra_configure_opts += -arch armv6
[19:34] <cjwatson> endif
[19:34] <ScottK> cjwatson: Great news then.  Armel seems to be a lot of two steps forward, one step back.  At least we've got some forward moment.
[19:34] <ScottK> moment/momentum
[19:36] <cjwatson> of course that change isn't syncable with Debian, unless you do an explicit "if I'm Ubuntu" conditional
[19:36] <cjwatson> the proper fix would be to use gcc's __sync_* intrinsics, if at all possible
[20:06] <cr3> I'm getting E: broken packages after upgrading lucid (from lucid, not karmic), apparently, ubuntu-desktop: Depends: xorg but it is not going to be installed
[20:13] <slangasek> Keybuk: how often is MoM running now?  Or is it failing to complete?
[20:13] <slangasek> apw: 493145> looking
[20:14] <slangasek> apw: perhaps it's better to check exclusively for 'nfsd_server', if it's been around since 2005?
[20:18] <nxvl> james_w: ping
[20:18] <highvoltage> how does this work? https://lists.ubuntu.com/archives/hardy-changes/2009-December/012337.html
[20:18] <james_w> hi nxvl
[20:19] <nxvl> james_w: i'm having a problem sponsoring a branch
[20:19] <highvoltage> zarafa isn't currently in the archives, how can it be added to hardy?
[20:19] <nxvl> james_w: bzr builddeb does not accept -k or -u
[20:19] <ScottK> highvoltage: Look at which component it's in.
[20:19] <Keybuk> slangasek: just about every run fails on a new package
[20:20] <Keybuk> today it is unhappy about drupal
[20:20] <james_w> nxvl: not your fault, but you have to spell it "-- -k..."
[20:20] <slangasek> I am unhappy about drupal most days; but why does that make MoM fail? :)
[20:20] <Keybuk> slangasek: because it can't unpack it
[20:20] <slangasek> wasn't that supposed to be fixed with a dpkg backport onto the server?
[20:20] <nxvl> james_w: so "bzr builddeb -S -- -knvalcarcel@ubuntu.com" will work?
[20:20] <Keybuk> slangasek: it clearly hasn't fixed it
[20:21] <highvoltage> ScottK: hmm, I seem to miss it on that actual message, but I assume it's probably in -partner then. thanks.
[20:21] <ScottK> highvoltage: Yes.  It is.
[20:21] <slangasek> ok; this is news to me
[20:22] <slangasek> Keybuk: any chance there are some error logs I could look at?
[20:22] <slangasek> (to at least get the precise error message...)
[20:23] <Keybuk> slangasek: I just get an exit status
[20:23] <Keybuk> I just blacklist the package and let it run until someone notices it's failed again
[20:23] <slangasek> blergh
[20:24] <Keybuk> if you want to take over MoM maintenance, BE MY GUEST! :D
[20:24] <Keybuk> REALLY
[20:24] <Keybuk> PLZ!!!
[20:24] <Keybuk> :D
[20:24] <slangasek> Keybuk: what's the version of dpkg-dev in use?
[20:24] <slangasek> I don't believe I have access to the server... :)
[20:25] <james_w> nxvl: it should, does it?
[20:25] <Keybuk> dpkg-dev	1.15.4ubuntu2~0.CAT.8.04
[20:25] <Keybuk> slangasek: RT ;)
[20:25] <cjwatson> slangasek: it's the one in chinstrap:~cjwatson/
[20:25] <Keybuk> slangasek: seriously though, I don't have any time to look at MoM atm
[20:25] <Keybuk> which is why unless someone tells me it's broke, it stays broke
[20:26]  * slangasek nods
[20:26] <Keybuk> and I don't really spend any time fixing the problem, I just blacklist the package
[20:29] <apw> slangasek, ack will sort that
[20:29] <tjaalton> slangasek: could you sync a few xorg drivers from unstable? it would help making X installable again ;)
[20:31] <slangasek> tjaalton: oh, I suppose I can do that
[20:31] <slangasek> tjaalton: bug #?
[20:32] <tjaalton> slangasek: no bugs filed, pitti did a bunch of them earlier today, but I missed some. there are no ubuntu changes in xserver-xorg-video-apm, -ark and -neomagic
[20:32] <tjaalton> so those three
[20:32] <slangasek> ok
[20:33] <tjaalton> then it's synaptics, vmmouse, cirrus and savage left to merge
[20:33] <slangasek> generally, filing a sync bug guarantees it gets in front of the eyeballs of the archive admin on duty; though on Monday, there tends to be a backlog, so...
[20:33] <tjaalton> and that should be all
[20:33] <tjaalton> right
[20:33] <cjwatson> Keybuk: do you know which script is exiting non-zero, even? I was wondering if I might be able to run a little bit of it locally, without a full pool
[20:33] <Keybuk> cjwatson: dpkg-source
[20:34] <Keybuk> ie. I know that dpkg-source -x fails on a given .dsc file
[20:34] <cjwatson> oh, I meant which script from cron.daily really, but OK, that's useful information too
[20:34] <cjwatson> I'll put together a hardy chroot
[20:36] <slangasek> tjaalton: synced
[20:36] <tjaalton> slangasek: excellent, thanks
[20:38]  * Keybuk cackles
[20:39] <Keybuk> I love how easy it is to debug Upstart
[20:39] <Keybuk> all software should come with a feature to crash on demand and leave a core file in a given directory
[20:43] <Daviey> Keybuk: my software always crashes, if i demand it or not :)
[20:44] <Keybuk> I was actually thinking of having a hidden command in there, which would fork a child process and give you the pid
[20:44] <Keybuk> so you could attach gdb to it
[20:44] <Keybuk> thus "initctl gdb" would give you a gdb attached to init ;)
[20:44] <Keybuk> I suspect kees just exploded at the very thought
[20:47] <smoser> i uploaded a package to a ppa, but before it built i found an error. is there a way to kill the pending build ?
[20:50] <maxb> smoser: No, but if you upload new source, the old build will be skipped without building once it reaches the head of the queue
[20:50] <smoser> oh. ok. thanks maxb
[20:56] <nxvl> james_w: yup, it worked
[20:58] <james_w> nxvl: great. I plan to make it so that you don't need that non-obvious bit.
[20:58] <nxvl> james_w: that would be great
[20:58] <kees> Keybuk: root can already do that, so why would it be bad?
[21:06] <apw> cjwatson, that font switch patch is not actually gone, just on the list to conider dropping.  i'll merge your info into the patch so we have it for posterity
[21:07] <slangasek> wgrant: what was the reason for dpkg v3 support slipping this LP release?  That came as a surprise to me, and we're really hurting from it on the archive admin side of things (over 70 source packages already blacklisted for this issue, more every week), so I want to be sure this is landing in January
[21:07] <cjwatson> apw: right, I knew it wasn't gone yet, but I like to avoid problems before they happen when I can :)
[21:07] <wgrant> slangasek: The next LP release is next week.
[21:08] <wgrant> slangasek: It got caught up in review and upgrade-dpkg-everywhere madness.
[21:08] <slangasek> wgrant: oh, that's a much better timeline then. :)  Is the v3 support in?
[21:08] <apw> cjwatson,  ahh ... message got skewed on the way.   and threatening to remove thing often engenders such a desired responce ... reasons why it is needed.
[21:08] <wgrant> The code has been done for weeks...
[21:08] <slangasek> ah
[21:10] <cjwatson> apw: right :)
[21:14] <cjwatson> Keybuk: would you mind double-checking the exact name of the package you had to blacklist? there's no 'drupal' package in Debian, and both drupal5 and drupal6 are still Format: 1.0
[21:14] <cjwatson> Keybuk: the name of any other test case would be fine too
[21:17] <cjwatson> Keybuk: (plus, neither drupal5 nor drupal6 appears to be in need of a merge)
[21:19] <cjwatson> Keybuk: shame you don't get anything more than the exit status - I tried unpacking a random 3.0 package (fakeroot) here with my backport, and it seems to work
[21:27] <Keybuk> cjwatson: it was drupal6
[21:29] <hedkandi> hi
[21:29] <cjwatson> Keybuk: ok, extracts fine here with my backport :-(
[21:29] <hedkandi> folks, what happens when you have an unsigned int n and you do n>>32?
[21:29] <cjwatson> Keybuk: is it reproducible from a shell?
[21:30] <cjwatson> hedkandi: 0, assuming 32-bit unsigned int
[21:30] <Keybuk> cjwatson: not sure which version it tried
[21:30] <Keybuk> it may have been an old one that it's already cleaned out
[21:30] <hedkandi> cjwatson, could you prove that by reference to the standard?
[21:31] <cjwatson> hedkandi: yes, C99 section 6.5.7 para 5
[21:31] <hedkandi> is that online?
[21:31] <cjwatson> hedkandi: "If E1 has an unsigned type [or other stuff], the value of the result is the integral part of the quotient of E1 / 2^E2"
[21:31] <cjwatson> hedkandi: probably not
[21:32] <cjwatson> C standards tend to be payware
[21:32] <hedkandi> roger well I have to go. It's not what I'm seeing.
[21:33] <Keybuk> he was pleasnt
[21:33] <ScottK> Probably just frustrated because he was having trouble with his homework.
[21:35] <cjwatson> actually I missed a spot in the standard
[21:35] <cjwatson> but his loss, if he wants to leave
[21:36] <cjwatson> "If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined."
[21:36] <cjwatson> so nasal demons
[21:36] <Keybuk> nasal demons? :p
[21:37] <Keybuk> is that your example of something permitted when the behaviour is undefined? :p
[21:37] <cjwatson> it's the standard example :)
[21:37] <cjwatson> have you not heard that before?
[21:37] <Keybuk> not that particular example, no
[21:37] <cjwatson> http://groups.google.com/group/comp.std.c/msg/dfe1ef367547684b
[21:37] <cjwatson> (from the jargon file)
[21:40] <ebroder> it looks like gcc 4.0.1 whines at you for doing something that dumb, and then gives you back n, unshifted
[21:40] <cjwatson> yes, it certainly emits a warning, which is what made me look again at the standard
[22:03] <smoser> maxb, it seems that uploading new source to override a queued build will fail if the queued build was a new upstream version (ie, included orig.tar.gz)
[22:04] <smoser> i tried re-uploading with the .orig, and it warns me about multiple orig.tar.gz and then i get a failed email message
[22:04] <smoser> Rejected:<lp.archiveuploader.permission.CannotUploadToPocket object at 0x76a2ad0>
[22:04] <smoser> if i try without the .orig.tar.gz, i get "Unable to find ec2-api-tools_1.3.45772.orig.tar.gz in upload or distribution." failure
[22:55] <cjwatson> ScottK: failed again, but the failure looks much more tractable, I suspect. http://paste.ubuntu.com/336873/
[22:58] <cjwatson> ScottK: might be due to the missing DEB_HOST_ARCH_OS define, perhaps. I've set that and will leave it to run again overnight.
[23:09] <ScottK> Definite progress.  Thanks cjwatson.
[23:34] <ccheney> does cp use prealloc on ext4?
[23:57] <crypt-0> im reluctant to use EXT4
[23:57] <crypt-0> from my tests etx3 has better throughput
[23:57] <crypt-0> and XFS even more
[23:57]  * ccheney wishes there was something other than xfs that could defrag well
[23:57] <ccheney> last time i used xfs it tried to eat all my data
[23:57] <crypt-0> what problem do you have with XFS?
[23:58] <crypt-0> [eat data] pleas enlighten me
[23:58] <ccheney> the old 0 filled data issue that wasn't solved for about 6 years (aiui)
[23:58] <crypt-0> i have ahd good lick and good throughput with XFS
[23:58] <ccheney> it would randomly fill your files with 00's
[23:58] <ccheney> aka NULLs
[23:58] <crypt-0> never happened to me, is it patched now?
[23:59] <ccheney> yea i think for the past year or two
[23:59] <crypt-0> yea i know a bit about zeros, and nulls
[23:59] <ccheney> but the fact it existed so long in the code makes me leery to ever use xfs
[23:59] <crypt-0> well i have been using XFS for the past 3
[23:59] <crypt-0> im using RAID