[00:50] <Riddell> cjwatson: meh I can't work out how to get the log off a virtual machine and need to wait until I'm home tomorrow morning before I can try it on a spare test machine
[01:14] <Riddell> cjwatson: yay got it
[01:14] <Riddell> http://people.ubuntu.com/~jr/tmp/syslog
[01:14] <Riddell> device-mapper: reload ioctl failed: No such file or directory
[01:14] <Riddell> bug 1276739
[01:15]  * Riddell snoozes
[03:12] <hallyn> infinity: stgaber: around?
[03:13] <infinity> hallyn: Ish.  What's up?
[03:13] <hallyn> inifinty: my qemu uplaod to trusty may have badly messed up
[03:14] <hallyn> i'm going to retry in a new vm;  it's possible something else messed me up, but given the severity here - it messed up binfmts entirely so i can't run dpkg/ls/etc
[03:14] <infinity> hallyn: The one with ~ppa in the version? :P
[03:15] <hallyn> yeah that one
[03:16] <infinity> When you say "can't run dpkg/ls/etc", do you mean "in an ARM chroot", or "at all"?
[03:16] <hallyn> at all
[03:16] <hallyn> -bash: /usr/lib/command-not-found: /usr/bin/python3: bad interpreter: Too many levels of symbolic links
[03:18] <infinity> Yeahp, you sure broke it.
[03:18] <hallyn> i haven't yet found where
[03:19] <infinity> I'd look, but I stupidly broke my machine checking.
[03:19] <infinity> Cause I used a chroot.
[03:19] <Logan_> the archive should reject uploads with a ~ppa suffix
[03:19] <infinity> So, let me reboot and then have a poke.
[03:20] <infinity> Logan_: He would have just reuploaded with a proper version and still broken the world. :P
[03:20] <infinity> hallyn: I'll delete the binary from the archive after I reboot and can, like, run stuff.
[03:20] <hallyn> infinity: thanks.
[03:23] <hallyn> that's why it passed all my tests.  apparmor kept me from hosing myself.
[03:36] <infinity> hallyn: So, comparing old and new debs, it looks like you're now shipping binfmts for the native arch.
[03:37] <infinity> hallyn: As in, I get binfmts for x86_64 and i386 on amd64 which I didn't before, so qemu is being tripped for native binaries.
[03:38] <hallyn> i'm not yet seeing *why* that's happening.  first ithought my wrong use of dpkg-verison in postinst was to blame, but nope
[03:42] <infinity> hallyn: No, it's actual shipped filed that differ.
[03:43] <infinity> http://paste.ubuntu.com/6883091/
[03:44] <infinity> Why that is, however, I'm not seeing immediately.
[03:44] <hallyn> infinty: right, that makes perfect sense,given the symptoms;  was just saying it wasn't what i originally expected to be the probelm
[03:52] <infinity> So, filter_binfmts is failing somehow, I guess?
[03:53] <stgraber> yeah, that's what the buildlogs indicate
[03:53] <stgraber> but I'm failing to see how
[03:53] <infinity> hallyn: Oh, possibly because you went and added a make conditional in the middle of a shell continuation.
[03:53] <infinity> hallyn: You can't do that.
[03:53] <infinity> hallyn: You need to write that bit as shell too, if it's in the middle of shell.
[03:54] <hallyn> i see
[03:54] <infinity> Oh well.  Gives you a chance to fix the version number on the next upload. :P
[03:54] <infinity> There's no reason to have the Ubuntu conditional in there anyway, is there?
[03:54] <hallyn> since we're not fully merging the qemu trees i'm going to pull all incidences of the dpkg-vendor for nwo anyway, but <arg>
[03:55] <infinity> The arm64 bit is just a no-op when not building on arm64...
[03:55] <hallyn> true
[03:56] <hallyn> so how long does it take before ppl are no longer exposed to that?
[04:00] <hallyn> (testing a new version...  wont' be pushing too soon)
[04:01] <infinity> hallyn: It's already gone from ftpmaster, just needs mirror pulses.
[04:02] <stgraber> hallyn: we probably want a fix uploaded soonish since until then, none of the binaries infinity removed exist at all (so nobody can install any version of those, which leads to other packages breaking and so on)
[04:02] <infinity> stgraber: To be fair, qemu-user-static has nearly 0 rdeps.
[04:02] <stgraber> my guess is that just dropping the ifdef in the middle of that block of shell is the safest bet to have something that builds, that you have already tested and which fixes our immediate problem
[04:03] <infinity> But yeah, a fix would be nice.  Dropping those two lines would fix it.
[04:03] <hallyn> stgraber: there's another snafu (using dpkg-version in postinst but not depending on devscripts);
[04:03] <infinity> Eww.
[04:03] <infinity> You mean dpkg-vendor.
[04:04] <hallyn> so yeah i'ts just http://paste.ubuntu.com/6883177/
[04:04] <hallyn> yes
[04:04] <infinity> But yeah, that should be subsituted in during build.
[04:04] <infinity> As in: if [ "@@VENDOR@@" = "ubuntu" ]
[04:05] <infinity> And then sed that in at build time when turning postinst.in into postinst.
[04:05] <stgraber> that diff looks safe enough and the real fix for a common source with Debian is indeed to add a new variable that's substituted from debian/rules (as you already seem to be using quite a bit ;))
[04:06] <infinity> hallyn: But go ahead and upload you current diff (looks good), and sort out the sed magic later, if you really care about the conditionals.
[04:06] <infinity> hallyn: Also, that should be 1.7.0+dfsg-3ubuntu1
[04:06] <hallyn> ok then, pushing.  thanks for removing those!
[04:06] <hallyn> oh,
[04:06] <hallyn> oh heh, right.
[04:09] <stgraber> I guess qemu could do with an autopkgtest to try and catch this kind of stuff next time around, can't hurt to have autopkgtest try to run a binary of each arch that are supported.
[04:09] <infinity> stgraber: You mean try to run a native binary to make sure the world isn't broken?
[04:09] <infinity> stgraber: Trying to run foreign binaries means having some available, which is a bit harder to sort out.
[04:10] <hallyn> yup, as i need to hack on adt anyway i was going to write a script for that at least locally
[04:10] <stgraber> infinity: well, I'd go with a simple test which grabs the supported core tarballs and try to chroot into them, which would incidently check that the host arch still works as otherwise you'd get an error when calling chroot :)
[04:11] <hallyn> i was just gonna go with each of the templates which lxc-download supports...
[04:15] <infinity> stgraber: Can the adt infra download from cdimage?
[04:17] <stgraber> infinity: I'm not aware of any location it can't download from. The LXC adt tests use gpg from outside servers and then grab stuff from external servers and those passed fine in adt, so it looks like they have unfiltered access to the outside.
[04:20] <stgraber> infinity: oh actually, no, it does seem to be restricted, I guess it was the test adt box I was using somewhere which wasn't... last run of lxc adt had two failures for things using our pre-built images...
[05:05] <hallyn> german mirror still offering me the broken version.  wonder how long that'll go :(
[05:14] <infinity> hallyn: Don't have much (any) control over third-party mirrors. :/
[06:46] <pitti> Good morning
[07:46] <tjaalton> fstrim cron spams when the ssd is not intel or samsung
[07:57] <pitti> tjaalton: oh, oops; can you please file a bug against util-linux with the mail and assign it to me?
[07:58] <tjaalton> yes, on it already
[07:59]  * zyga wonders if unity startup failure is that protobuf symbol he read about yesterday
[07:59] <tjaalton> hmm actually the spam is from a hdd
[08:00] <tjaalton> i've a raid mirror which it complains about
[08:00] <zyga> ara: hey
[08:00] <zyga> ara: are you on 14.04?
[08:01] <ara> zyga, yes
[08:01] <zyga> hmm
[08:01]  * zyga wonders why unity crashes and looks at logs
[08:02] <ara> zyga, I didn't update yesterday, though
[08:03] <ara> zyga, look at this thread: https://lists.ubuntu.com/archives/ubuntu-desktop/2014-February/004425.html
[08:03] <ara> zyga, might be related?
[08:06]  * zyga tries to recall how to copy paste in screen
[08:06] <zyga> yay
[08:07] <zyga> hmm, my protobuf is still 2.4.1, no 2.5 in sight
[08:07] <zyga> and seb isn't around yet
[08:08] <zyga> ara: yeah, that is what I suspected, wonder how to fix it now
[08:08] <ara> zyga, it seems that updating should be enough
[08:09] <zyga> ara: nope, the 2.5 version isn't out yet
[08:09]  * zyga adds proposed and checks
[08:11] <ara> zyga, did you apt-get update? protobuf is on 2.5 in trusty
[08:11]  * zyga is depressed by the whole release stuff
[08:11] <zyga> ara: yes, just a second ago
[08:11] <zyga> ara: not for me? which package did you check
[08:12] <zyga> (and it obviously didn't work which is another thing)
[08:12] <ara> protobuf
[08:12] <ara> https://launchpad.net/ubuntu/+source/protobuf/2.5.0-8ubuntu1
[08:12] <zyga> I checked libprotobuf7 it is 2.4.1, libprotobuf8 is at 2.5 (and I have it installed) but it still doesn't work
[08:13] <zyga> and it wasn't updated just now so I already had 2.5 when booting this morning
[08:13] <zyga> (not ubuntu release)
[08:17] <tjaalton> did we move from dmraid to mdadm?
[08:18] <tjaalton> according to the blueprint; not yet
[08:40] <fsvend`> i'm creating a ubuntu based distro and have issues due to udev not creating device nodes in /dev, which is because devtmpfs is not mounted. now, there's devtmpfs entry in /lib/init/fstab, and it works when mounting it manually via mount -a, but mountall doesn't mount it. anyone?
[08:40] <fsvend`> now i see the same behaviour on raring ringtail, ie. there's no devtmpsfs mounted on /dev.. so i guess you have created the device nodes manually? is that the case for raring?
[08:46] <tjaalton> udev on /dev type devtmpfs (rw,mode=0755)
[08:46] <tjaalton> looks fine here
[08:47] <fsvend`> tjaalton: on raring?
[08:48] <fsvend`> tjaalton: whats your udevd version?
[08:48] <tjaalton> no trusty
[08:48] <tjaalton> raring is EOL
[08:50] <fsvend`> tjaalton: i'm targeting saucy (for now) on my target (udevd version 204), but i see the same problem on raring (on host, udev version 175)
[08:50] <tjaalton> doing something wrong then
[08:50] <fsvend`> tjaalton: mountall --verbose just seem to ignore the devtmpfs entry
[08:51] <fsvend`> tjaalton: well, on my target, possibly yes.. but the raring version is as you made it
[08:54] <tjaalton> same thing on precise and quantal here, so yes it's wrong on your end
[08:56] <fsvend`> tjaalton: that's useful info.. btw, i got a quantal server here, and the output from mount doesn't mention devtmpfs. how do you retrieve that info?
[08:56] <tjaalton> mount
[08:58] <fsvend`> tjaalton: sorry. bad mad. grep helped me spot it :)
[08:59] <fsvend`> s/bad mad/my bad/
[09:03] <fsvend`> tjaalton: still no devtmpfs on target though. i have support for devtmpfs in the kernel, and it works when using mount -a
[09:04] <tjaalton> still not my problem :)
[09:04] <fsvend`> tjaalton: right :)
[09:42] <robert_ancell> mardy, can you upload the unity-control-center changes in gnome-control-center-signon now? We've switched the seed to u-c-c (bug 1257505)
[09:43] <mardy> robert_ancell: cool, will do soon
[09:43] <robert_ancell> thanks
[09:56] <pitti> lightdm  23418  0.0  0.0  56520 12088 ?        R    10:56   0:00 /usr/bin/python3 /usr/bin/click pkgdir com.ubuntu.clock
[09:57] <pitti> does anyone know what that is?
[09:57] <pitti> (on my amd64 desktop, trusty du jour)
[09:57] <pitti> it's been running for a long time already, and eating CPU
[09:58] <ogra_> curious
[09:58] <lool> Hmm I have some issue with the lightdm session startup on my desktop
[09:58] <lool> it seems racy; I get some vague g_dbus_connection_real error in the log, sometimes it comes up sometimes not
[09:58] <tvoss> hmmm, interesting, I cannot connect to 5Ghz wifi access points anymore
[09:59] <lool> lol
[09:59] <lool> 3 different bgus
[09:59] <ogra_> tvoss, ChickenCutlass had the same issue
[09:59] <lool> so if I stop lightdm + statr lightdm => no luck; if I restart lightdm, it works
[09:59] <ogra_> (he just pragmatically changed the channel on his AP though)
[09:59] <tvoss> ogra_, weird
[09:59] <tvoss> ogra_, I have got a devolo network over power thingy here :) need to see if that would work
[10:00] <ogra_> tvoss, well, still someone should tell the kernel team :)
[10:00] <tvoss> ogra_, I would think so
[10:00] <ogra_> (or cyphermox_, if it is NMs fault)
[10:00] <pitti> ah, it seems phablet-tools pulls in click now
[10:02] <pitti> click keeps getting respawned with the same command line, indefinitely
[10:02] <tvoss> sergiusens, ^
[10:03] <ogra_> but there were no changes since the 22nd
[10:03] <lool> bah and under strace it works 100% of the time of course
[10:03] <ogra_> intresting that you didnt notice this before then
[10:03] <lool> grmlblb
[10:04] <ogra_> lool, dont you love races ? :)
[10:05] <ogra_> lool, btw, restart never worked for me, i always had to stop/start (restart left a hanging lightdm around)
[10:06] <sergiusens> pitti, are you referring to th upstart stuff?
[10:07] <pitti> sergiusens: I don't know; I just heared my CPU fan go wild for 10 mins and checked in top that it's due to that
[10:07] <ogra_> pitti, did you upgrade between the 22nd and today (apart from today)
[10:07] <pitti> ogra_: certainly, I upgrade every day
[10:07] <sergiusens> pitti, it might be upstart jobs and rerunning apparmor and checking for clicks
[10:08] <ogra_> well, then it cant be phablet-tools itself i'd say
[10:08] <ogra_> there was an apparmor-click change tonight
[10:08] <pitti> ogra_: no, that's just what pulls in upstart-app-launch, click, etc.
[10:08] <ogra_> pitti, right, but since the 22nd already
[10:09] <pitti> I purged click and its rdepends and reinstalled phablet-tools, seems it's tame now
[10:09]  * sergiusens has a pending task to split the package into smaller bits
[10:09] <ogra_> * apparmor/click.py: adjust to add mock_testenv and honor it to skip
[10:09] <ogra_>     checking apparmor_dirs when set
[10:09] <lool> so it seems it's gnome-settings-daemon not happy about something
[10:09] <ogra_> pitti, might be that your PC has some mock stuff around others dont ;)
[10:09] <lool> http://paste.ubuntu.com/6884348/
[10:10] <lool> this is specific to failing startups:
[10:10] <lool> ** (gnome-settings-daemon:30698): WARNING **: Unable to register client: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files
[10:11] <pitti> hm, we don't install a .service for gnome-session as we don't dbus-activate it (and don't want to)
[10:11] <pitti> lightdm is supposed to just start it; so perhaps gnome-session crashed?
[10:12] <pitti> lool: do you have a .crash file for something like g-sessin?
[10:12] <lool> it's possible, albeit hard to tell
[10:12] <lool> no
[10:12] <lool> just susres, whatever that is
[10:12] <lool> ah suspend resume
[10:12] <lool> old
[10:15] <lool> pitti: it doesn't even start gnome-session
[10:18] <seb128> pitti, your click issue should be fixed by https://launchpad.net/ubuntu/+source/indicator-datetime/13.10.0+14.04.20140205-0ubuntu1
[10:18] <seb128> infinity, thanks for fixing libcmis
[10:19] <lool> so what I did was replace gnome-session with a wrapper script that calls strace gnome-session.real, and this never created a strace
[10:19] <lool> I did manage once to catch a strace of a failed startup of unity-greeter in the same way
[10:19] <lool> it never fails if I strace -f though
[10:20] <seb128> lool, what's your issue?
[10:20] <seb128> lool, greeter one?
[10:20] <lool> seb128: lightdm greeter not coming up
[10:20] <lool> but racy
[10:20] <lool> sometimes it does
[10:20] <seb128> lool, when did it start?
[10:21] <lool> seb128: it might have happened rarely previously; it's a new install; it started appearing a lot in the last days
[10:21] <lool> yesterday was when I first realized there was something bad going on
[10:21] <Unit193> seb128: Just a quick poke, mearly to make sure it hasn't fallen off the radar.
[10:21] <seb128> lool, ok, because the new indicator-datetime update from yesterday/the click issue pitti described made the greeter not load for kenvandine
[10:21] <lool> I did some changes to my own user session (to start an upstart job as ~lool) but that shouldn't affect greeter
[10:21] <lool> seb128: aha
[10:21] <seb128> lool, that's fixed in this night update (the one I Just pointed to pitti)
[10:22] <seb128> lool, indicator-datetime update that is
[10:22] <seb128> Unit193, what is "it"
[10:22] <seb128> ?
[10:22] <Unit193> indicator-sound pavucontrol alt recommend.
[10:22] <lool> seb128: but I dist-upgraded already
[10:23] <seb128> lool, did you restart the greeter since and still get the issue?
[10:23] <lool> seb128: Yes
[10:23] <pitti> seb128: ack, thanks; I got a load of new packages now, I'll reboot
[10:23] <seb128> lool, try uninstlal indicator-datetime in case? or maybe you have a different issue...
[10:23] <seb128> pitti, yw!
[10:24] <seb128> Unit193, I pinged people about it yesterday, let me check
[10:24] <Unit193> Cool, danke.
[10:24] <seb128> Unit193, approved
[10:24] <Unit193> Nice, thanks.
[10:25] <mardy> robert_ancell: can you please create a MP for this? https://code.launchpad.net/~robert-ancell/gnome-control-center-signon/unity-control-center
[10:25] <robert_ancell> mardy, syre
[10:25] <robert_ancell> sure
[10:25] <lool> hmmm why dont I see strings in execve but only pointers
[10:25] <lool> in my strace
[10:26] <robert_ancell> seb128, can you review too https://code.launchpad.net/~robert-ancell/gnome-control-center-signon/unity-control-center/+merge/205110
[10:26] <lool> http://paste.ubuntu.com/6884429/ is strace -e trace=process of unity-greeter
[10:28] <robert_ancell> lool, do you have lightdm.log
[10:29] <lool> robert_ancell: http://paste.ubuntu.com/6884441/
[10:29] <lool> sorry had to reproduce the issue
[10:30] <robert_ancell> lool, you have the same problem as Ken
[10:30] <lool> I have to do a roundtrip to school, brb
[10:30] <lool> robert_ancell: I have latest datetime though
[10:30] <lool> brb
[10:57] <smb> apw, Ok, I attached a debdiff for systemd (which contains the udev rules we have to modify) to bug 1277006
[11:11] <robert_ancell> fginther, did those jenkins jobs get set up OK?
[11:11] <robert_ancell> seiflotfy__, are you OK with ps-jenkins being added to ~activity-log-manager?
[11:14] <tseliot> cjwatson: any chances I can deliver one last fix? (apparently a regression)
[11:18] <lool> robert_ancell, seb128: I replaced indicator-datetime-service with /bin/true and I was still able to trigger the race
[11:18] <lool> like one time out of 4
[11:21] <seb128> lool, ok, maybe a redherring then
[11:21] <seb128> or another issue
[11:21] <cjwatson> tseliot: !
[11:22] <cjwatson> tseliot: um, I'm not sure that's realistic.  details?
[11:23] <tseliot> cjwatson: apparently my last upload of fglrx-pxpress keeps on writing "y" to a log file... two users reported this to me this morning
[11:23] <tseliot> cjwatson: and the log file keeps growing...
[11:24] <cjwatson> fglrx-pxpress isn't on images, right?
[11:24] <cjwatson> (hope not.)
[11:24] <cjwatson> it doesn't seem to be.  so delivering your fix is basically independent of 12.04.4
[11:24] <cjwatson> but yeah, let's get that in
[11:24] <tseliot> cjwatson: no but jockey can install it if the fglrx is installed. I assume we don't install fglrx in ubiquity
[11:25] <tseliot> *fglrx driver
[11:25] <tseliot> ok, good
[11:25] <tseliot> I'll come up with a fix soon
[11:25] <xnox> tseliot: y would it do that? =) silly driver... =)))))
[11:26] <tseliot> xnox: :D it's really an upstart job to handle multiple gpus that does that
[11:32] <pitti> smb: please don't upload bug 1277006 just yet
[11:32] <pitti> smb: I applied it to my local git, but that has staged changes
[11:33] <smb> pitti, I could not even if I wanted, but stop apw (in case he would)
[11:33] <smb> Which we should have now
[11:34] <pitti> smb: I'll upload it now
[11:34] <smb> pitti, ok
[11:35] <apw> pitti, hey .. we probabally want to include vesafb in the list of "non-primary" framebuffers while you are there
[11:35] <pitti> apw: hey Andy
[11:36]  * smb notes it would be called vesa-framebuffer
[11:36] <pitti> apw: good timing, two seconds away from dput :)
[11:36] <apw> heh :)
[11:36] <apw> i was lucky
[11:36] <apw> pitti, what smb said
[11:36] <pitti> smb, apw: http://paste.ubuntu.com/6884698/ ?
[11:37] <pitti> DRIVERS=="nouveau", GOTO="graphics_end"
[11:37] <pitti> hm, is that still current?
[11:37] <pitti> oh wait, fun
[11:37] <pitti> we have a first rule
[11:37] <pitti> DRIVERS=="nouveau", ENV{PRIMARY_DEVICE_FOR_DISPLAY}="1"
[11:38] <pitti> (or set of rules, for i916 and radeon, too)
[11:38] <smb> pitti, The vesa line looks good to me (DRIVER=vesa-framebuffer in one of my laptops)
[11:38] <pitti> ah, so the first set is for DRM, the second set for fb
[11:38] <apw> yeah that looks right to me, and smb has the kit to test it
[11:38] <apw> yeah two separate things in there
[11:38] <apw> to confuse the reader
[11:38] <pitti> $ udevadm info --export-db|grep 'DRIVER.*-framebuf'
[11:38] <pitti> E: DRIVER=efi-framebuffer
[11:39] <pitti> ack, adding vesa-framebuffer then
[11:39] <apw> smb, pitti, what about simple-framebuffer, wasn't that one you wanted smb ?
[11:40] <smb> pitti, both
[11:40] <apw> or am i getting confused
[11:40] <smb> Err
[11:40] <smb> wait
[11:40] <pitti> *-framebuffer would be too much?
[11:40] <smb> simple-framebuffer just in case we ever would have it and thats not likely for T... (except arm maybe)
[11:40] <pitti> there is never the  case that X would start on such a framebuffer, even if you don't have a "better" graphics card installed?
[11:40] <apw> yeah it would as we are only trying to ignore the "fallback franebuffer drivers"
[11:41] <apw> pitti, so all this affects is whether it is marked "PRIMARY", and if it is splash is started much earlier to get prettyness
[11:41] <pitti> so http://paste.ubuntu.com/6884708/ is the current version now
[11:41] <apw> if no PRIMARY is found, we will start splah on whatever it can cope with, which wold include the "excluded" ones you are adding
[11:42] <smb> pitti, ack
[11:42] <pitti> smb: thanks for checking; uploading then
[11:42] <apw> smb, i thought simple-framebuffer was the one at issue in your kvm spot, where it is being replaced
[11:43] <smb> apw, Yes, before we flipped the config to not build it at all
[11:43] <apw> oh ok
[13:22] <jdstrand> ogra_, sergiusens, pitti: I don't have all the context, but... the click-apparmor change ogra mentioned doesn't actually do anything with the installed package-- ie, it will behave the same as it did before the upgrade
[13:22] <ogra_> jdstrand, yeah, seems it was indicator-datetime that caused it
[13:23] <jdstrand> ok
[13:23] <jdstrand> cool
[13:25] <Riddell> anyone know anything about mythbuntu? (I'm trying to test 12.04.4 candidates)
[13:26] <ogra_> its a myth !
[13:27]  * xnox feels thrilled to use: try... except... else... finally... clause in python!
[13:28] <Riddell> using extern c {} can't be far away now
[13:33] <tseliot> cjwatson: I've just uploaded the fix in precise-proposed -  fglrx-pxpress (0.6~hybrid0.0.2) for bug #1277058
[13:45] <cjwatson> tseliot: thanks, reviewing
[13:56] <pitti> jdstrand: yes, I think the latest indicator-datetime fixed that
[14:09] <tseliot> cjwatson: thanks!
[14:11] <TheNano> Hi dear developers, I am loking for a project in C/C++ that needs contribution, the prgraming level I look for is Embdded programming or very close to hardware programming, not necessary hardware driver but things in that style. As I can't rignt now choose a project or part of Ubuntu by my own interest I am open for suggestion and probabaly if someone feels for it a Mentor trough my start. I am a hardware/embdded M.S.c. gradua
[14:27] <tomreyn> hi there
[14:27] <tomreyn> is it still possible to get debian packages into 14.04?
[14:27] <cjwatson> yes
[14:27] <tomreyn> i thinkt he deadline is today?
[14:28] <cjwatson> only for automatic operation
[14:28] <ogra_> no
[14:28] <tomreyn> what's "automatic operation"?
[14:28] <cjwatson> manual requests will be possible without any particular justification up to feature freeze (https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule)
[14:28] <ogra_> automatic imports from the debian archive
[14:28] <shadeslayer> tseliot: ping
[14:28] <cjwatson> up to today we automatically sync changes in Debian to packages we haven't modified in Ubuntu
[14:29] <cjwatson> (end of today, I expect)
[14:29] <tomreyn> so February 20th is the deadline for manual imports on request
[14:29] <tomreyn> thanks
[14:35] <tseliot> shadeslayer: pong
[14:35] <shadeslayer> tseliot: I was wondering, is there a way we can prevent aptdaemon from being pulled into the Kubuntu ISO? I believe the reason why it's pulled in right now is due to ubuntu-drivers-common
[14:36] <tseliot> shadeslayer: is it too big?
[14:36] <shadeslayer> apachelogger: ^^
[14:37] <apachelogger> tseliot: it is not used
[14:37] <apachelogger> we have qaptworker which pretty much is a qt version of aptdaemon
[14:37] <tseliot> pitti: any ideas? ^
[14:40] <pitti> shadeslayer, tseliot: it's being used for mapping modaliases to driver packages
[14:40] <tseliot> apachelogger: ^
[14:40] <shadeslayer> pitti: I thought that was done internaly in detect.py and the pkkit functionality was only a addon
[14:40] <shadeslayer> and not critical to ubuntu-drivers-common
[14:41] <pitti> yes, it is
[14:41] <pitti> i. e. if you don't need that functionality on the PackageKit API level, we can drop it to a suggests
[14:41] <pitti> u-d itself just uses python-apt for that
[14:41] <shadeslayer> pitti: yep, we don't really need the functionality on the pkkit API level
[14:41] <apachelogger> (we are not using any PK API on the KDE side of things)
[14:41] <apachelogger> all hard wired to qapt->libapt-pkg
[14:41] <shadeslayer> ^^
[14:43] <pitti> tseliot, apachelogger, shadeslayer: https://github.com/tseliot/ubuntu-drivers-common/commit/2a53800
[14:43] <shadeslayer> \o/
[14:43] <tseliot> pitti: great :)
[14:43] <apachelogger> pitti: thank you
[14:43] <pitti> how soon do you need this uploaded?
[14:45] <apachelogger> pitti: can wait, it's just wasting space, as long as it lands before release we should be fine ^^
[14:45] <pitti> yeah, still plenty of time
[14:46] <shadeslayer> pitti: on that note, could you also have a look at 1274605
[14:46] <shadeslayer> or maybe poke someone on the firefox packaging team^^
[14:47] <pitti> bug 1274605
[14:47] <pitti> yeah, not my area I think
[14:47] <dholbach> blueyed, happy birthday! :)
[14:47] <pitti> chrisccoulson: ^
[14:57] <fginther> robert_ancell, yes, the jobs are deployed and ready
[14:57] <robert_ancell> fginther, great, thanks!
[14:59] <rbasak> What should we do for Vcs-* control fields in merges? Leave them pointing them at Debian? Pull them out?
[14:59] <cjwatson> prepend XS-Debian-
[14:59] <shadeslayer> I believe they should be changed to : XSBC-Debian
[14:59] <cjwatson> not BC
[14:59] <shadeslayer> oh, ok
[14:59] <cjwatson> I mean you sort of can but it's redundant, they're source information so just XS-
[15:00] <shadeslayer> cjwatson: on that note, do you have a document that explains those?
[15:00] <shadeslayer> google doesn't give me anything
[15:00] <cjwatson> policy
[15:01] <cjwatson> I think ...
[15:02] <cjwatson> shadeslayer: at least it's in deb-src-control(5) under "USER-DEFINED FIELDS"
[15:03] <rbasak> Understood - thanks!
[15:04] <shadeslayer> cjwatson: ah, thx
[15:05] <Riddell> dobey: could you take a look at https://code.launchpad.net/~dpm/intltool/add-qtdesigner-support/+merge/145112 ?
[15:06] <dpm> Riddell, I think he mentioned you'd have to get hold of danilo to review that one. I tried to get in touch with him for this MP a while ago, but he wasn't around
[15:07]  * Riddell e-mails
[15:07] <dobey> you need to get danilo to re-review
[15:07] <dobey> i can't change danilo's vote for him on lp
[15:36] <shadeslayer> ev: ping, have a moment to talk about errors.ubuntu.com?
[15:37] <josepht> shadeslayer: ev is on holidays through the 14th
[15:37] <shadeslayer> oh
[15:37] <shadeslayer> josepht: thanks
[15:38] <shadeslayer> anyone else whom I can talk to about e.u.c ?
[15:39] <shadeslayer> We have a patch in Kubuntu that has started reporting crashes to e.u.c ( for eg https://errors.ubuntu.com/oops/fe95cba8-60c0-11e3-b76d-e4115b0f8a4a ) but the top 4-5 frames of that crash are from the crash handler, which might confuse e.u.c into thinking that KCrashHandler is crashing
[15:40] <shadeslayer> would daisy be need to modified so as to not think that kcrashhandler is crashing?
[15:40] <shadeslayer> or is everything fine and it'll work perfectly
[15:48] <shadeslayer> pitti:  tseliot: one of the other requests for ubuntu-drivers-common, drivers like nvidia-173 are super duper old and should probably have a key/value pair that says that these should be the least preferred driver
[15:49] <shadeslayer> and maybe even have generic labels such as "Wireless Card" so that users don't have to see "Broadcom ABCD a/b/g/n" in the ui
[15:51] <tseliot> shadeslayer: I'm going to change the packages descriptions, so that we get better descriptions in the UI
[15:51] <tseliot> that's not hardcoded in u-d-c
[15:51] <tseliot> it's in the single packages
[15:51] <shadeslayer> tseliot: yay \o/
[15:52] <shadeslayer> tseliot: I use short descriptions in my UI : http://im9.eu/picture/dz7621
[15:53] <robert_ancell> seiflotfy__, around?
[15:54] <tseliot> shadeslayer: I see. I'll take care of that as soon as I'm done with some more work in ubuntu-drivers-common
[15:54] <shadeslayer> cool
[15:54] <shadeslayer> tseliot: anything exciting coming up in ubuntu-drivers-common?
[15:55] <tseliot> shadeslayer: a program which handles multiple gpus or configuration changes on boot
[15:55] <tseliot> e.g. you unplug a graphics card, or add one card
[15:55] <shadeslayer> ah cool, I'll keep an eye out for those
[15:55] <tseliot> :)
[15:56] <shadeslayer> tseliot: something that came up during the development of the KDE Frontend, my ui is all C++ and I'm using a python script to export data over dbus
[15:56] <robert_ancell> ricotz, I'm trying to find someone who can add ps-jenkins to ~activity-log-manager. I think you could do that right?
[15:56] <shadeslayer> might be useful to have a dbus interface by default?
[15:57] <tseliot> shadeslayer: this is something you might want to discuss with pitti
[16:00] <shadeslayer> ack
[16:00] <seiflotfy__> robert_ancell: go crazy
[16:02] <ricotz> robert_ancell, yeah, can do, if seiflotfy__ doesnt beat me to it
[16:02] <robert_ancell> it's a race :)
[16:02] <robert_ancell> the prize is.... a beer at the next physical meetup
[16:02] <robert_ancell> or alternative drink
[16:02] <ricotz> done ;)
[16:02] <seiflotfy__> ricotz: won
[16:03] <robert_ancell> ricotz, ta!
[16:06] <shadeslayer> Anyone have a clue how firefox knows how to handle apt:// urls?
[16:07] <jussi> yeah, theres an ubuntu apt settings or some such package
[16:07] <jussi> shadeslayer: ^^
[16:08] <shadeslayer> jussi: I see, however it doesn't seem to work in Kubuntu
[16:08] <jussi> also... http://askubuntu.com/questions/336853/how-to-install-usign-the-apt-url-on-ubuntu-12-04
[16:08] <shadeslayer> jussi: yeah tried that, does not work
[16:09] <robert_ancell> fginther, I don't see unity-control-center in https://jenkins.qa.ubuntu.com/view/All/
[16:10] <mdeslaur> shadeslayer: the apturl-common package installs a desktop file to /usr/share/applications that contains the mime type for handling apt
[16:11] <shadeslayer> it most certainly does, but that doesn't work in Firefox under Kubuntu for some reason
[16:11] <shadeslayer> nor do I see the protocol registered in Firefox
[16:11] <fginther> robert_ancell, nothing will show up there until a job is executed and published. You can see the 'real' job here: http://s-jenkins.ubuntu-ci:8080/job/unity-control-center-ci
[16:11] <mdeslaur> shadeslayer: oh, I guess firefox doesn't have kde integration for mime types
[16:11] <robert_ancell> fginther, ah, thanks
[16:11] <shadeslayer> mdeslaur: yeah
[16:13] <mdeslaur> shadeslayer: I'm told there used to be a firefox patch for kde integration, but it got dropped as nobody wanted to maintain it
[16:14] <shadeslayer> mdeslaur: hmm, well, I do maintain patches for Firefox that do KDE integration, however I wouldn't want them in the archive
[16:15] <Logan_> mr_pouit: sent you an email - quick question about the xfce4-indicator-plugin merge
[16:32] <shadeslayer> hah
[16:32] <shadeslayer> apt urls don't even work on Ubuntu?
[16:32] <shadeslayer> this is what I see http://im9.eu/picture/vo7621
[16:33] <shadeslayer> chrisccoulson: ^^
[16:34] <spineau> mterry: hello, as you already approved a MIR of a future checkbox dependency, plainbox (it was bug 1265754). May I ask you to review bug 1276164 and bug 1276183? Both should be easy to do (just about code re-organization)
[16:35] <tomreyn> shadeslayer: i think the "apturl" package needs to be installed (i don't know whether it is by default), also you need to keep the ubuntu firefox extension enabled.
[16:36] <shadeslayer> tomreyn: The apturl package is installed
[16:36] <shadeslayer> that's from the ubuntu 13.10 live session
[16:36] <mterry> spineau, sure, I'll try to get to them today
[16:36] <spineau> mterry: thanks a lot
[16:37] <shadeslayer> tomreyn: http://im9.eu/picture/vl7621
[16:38] <tomreyn> shadeslayer: hmm i had expected that to work. i'm on a 13.10 installation here, using xubuntu (xfce), and clicking apt:// url spawns software center for me (which then displays info on the given package)
[16:38] <mdeslaur> shadeslayer: bug 1261178
[16:40] <shadeslayer> tomreyn: I see
[16:41] <infinity> seb128: No problem.  It always bugs me when I see something in binary NEW for all but one architecture. :)
[16:42] <tomreyn> shadeslayer: you could try updating the system you started from this live cd, and to restart firefox in the end of the process
[16:42] <tomreyn> might help
[16:46] <shadeslayer> tomreyn: downloading trusty
[16:46] <shadeslayer> to check if I can reproduce it in the latest images
[16:50] <seb128> infinity, hey
[16:51] <seb128> infinity, since you are an u-a admin, how would we go about adding somebody to the team? ;-)
[16:52] <infinity> seb128: We'd need to discuss it with the team internally, and with Laney, and then if all parties are cool with the idea, do a bit of training (if necessary), then add him.
[16:53] <infinity> seb128: It's an invite-only thing, for obvious reasons, not a "you volunteer, you get in" deal, but I suspect Laney's got more or less the skill needed.  We'll talk it out on Monday with various members of the team.
[16:53] <Laney> Ta
[16:53] <seb128> infinity, thanks
[16:54] <robert_ancell> fginther, still confused about the u-c-c Jenkins job - has it noticed https://code.launchpad.net/~larsu/unity-control-center/wrap-keyboard-label/+merge/205201?
[16:54] <tseliot> cjwatson: the fix for bug #1277058 has been tested
[16:55] <shadeslayer> so anyone else have an idea why this is not working? all the bits seem to be there
[16:56] <sarnold> shadeslayer: probably just lacks someone to spend the time to debug and fix it. and refix it every so often? :)
[16:59] <fginther> robert_ancell, hmm, looking
[17:00] <cjwatson> tseliot: released, thanks
[17:00] <tseliot> cjwatson: thanks a lot for your help
[17:02] <fginther> robert_ancell, the logs indicate that ps-jenkins is not authorized to do the review
[17:03] <fginther> robert_ancell, ps-jenkins is not a member of https://launchpad.net/~ubuntu-desktop
[17:03] <robert_ancell> fginther, it has to be the project maintainer not just a driver?
[17:04] <fginther> robert_ancell, drivers don't appear to have review/merge privilege
[17:05] <robert_ancell> fginther, I'm looking at other projects wondering how they work...
[17:09] <robert_ancell> fginther, e.g. for Mir - it is owned by ~pspmteam which ps-jenkins doesn't seem to be involved with and driven by ~mir-team
[17:10] <fginther> robert_ancell, ps-jenkins is an indirect member of https://launchpad.net/~mir-team
[17:10] <fginther> PS Jenkins bot → Canonical Product Strategy → Mir development team
[17:11] <fginther> robert_ancell, the original solution for enabling jenknis was that "Canonical Product Strategy" would be a member for all projects
[17:11] <robert_ancell> fginther, right, and it is a member of ~unity-control-center-team which is the equivalent
[17:12] <robert_ancell> fginther, oh, the branch is in ~ubuntu-desktop - I'll move it
[17:13] <fginther> doh!, didn't think to look at that
[17:14] <robert_ancell> fginther, ok, fixed - do we need to re-trigger jenkins?
[17:14] <robert_ancell> fginther, np, we have to move the MPs anywa
[17:15] <fginther> robert_ancell, in this case it should pick it up on the next poll starting now
[17:24] <infinity> cjwatson: Should binfmt-support perhaps do some hand-holding to make sure you don't install binfmts for formats the running system supports, without some angry override flag?
[17:24] <infinity> cjwatson: The oops in qemu-user-static yesterday where it accidentally installed itself as a handler for x86 on x86 was... Fun.
[17:27] <cjwatson> infinity: maybe; it's been a readme/todo kind of level item for me for a long time.  the trick is figuring out how to express that condition sensibly
[17:27] <cjwatson> preferably without ridiculous amounts of per-arch maintenance
[17:32] <infinity> cjwatson: I suspect a static arch table is going to be nearly unavoidable, unless there's a way to ask the kernel what it supports?
[17:33] <infinity> (A static arch table is what qemu-user-static uses, and that's what got broken in the upload :P)
[17:33] <cjwatson> infinity: really, I think the *kernel* should prevent you shooting yourself in the foot here
[17:33] <cjwatson> I appreciate that's buck-passing ... but it's really very easy to commit suicide via binfmt_misc
[17:33] <infinity> cjwatson: Perhaps, though there might be some esoteric reason for testing or fiddling why you might want the kernel to let you do such silly things.
[17:34] <infinity> And kernel interfaces very rarely have a --no-really-i-mean-it flag.
[17:35] <shadeslayer> tomreyn: I possibly have a fix
[17:35]  * shadeslayer is testing in a live session to make sure
[17:35] <infinity> cjwatson: I suppose /proc/sys/fs/binfmt_misc/ could grow an "unsafe" node, defaulting to 0.
[17:37] <shadeslayer> ah no :(
[17:40] <shadeslayer> so I do have it working, I just don't know how >.>
[18:49] <dobey> anyone else on trusty with intel video having weird graphic anomolies after updating to the latest kernel/xorg?
[18:50] <mdeslaur> dobey: I see some lines in windows from time to time which disappear when I click on them
[18:51] <dobey> mdeslaur: yeah, i'm getting that and some other similar things that look like maybe the framebuffer didn't get updated properly, but which "fixes" itself after some interaction
[18:52] <mdeslaur> dobey: do you see it on other windows than firefox and thunderbird?
[18:52] <mdeslaur> I seem to notice it's only on those windows, but haven't confirmed yet
[18:52] <dobey> mdeslaur: yes. am seeing it quite consistently in qt apps, and have seen it in a few gtk+ apps as well
[18:52] <mdeslaur> ok
[18:53] <dobey> qjackctl's buttons are always messed up when i start it now
[19:06] <Sarvatt> dobey: https://bugs.freedesktop.org/show_bug.cgi?id=74327 , it should be fixed in 2.99.910 probably tomorrow
[19:08] <dobey> Sarvatt: ok, thanks
[19:08] <Sarvatt> dobey: https://launchpad.net/~xorg-edgers/+archive/ppa/+files/xserver-xorg-video-intel_2.99.909%2Bgit20140206.823382d2-0ubuntu0sarvatt_amd64.deb if you dont want to wait :)
[19:09] <shadeslayer> pitti: btw ubuntu-drivers-common doesn't list linux-firmware-nonfree as something that can be installed
[19:09] <dobey> Sarvatt: i'll wait for now, unless i am forced to log out for some reason :)
[19:09] <shadeslayer> pitti: because my wireless drivers come from linux-firmware-nonfree but the ones from the Broadcom STA package don't work ( or didn't work last time I tried )
[19:10] <Sarvatt> dobey: it may actually be monday, uploading it on a friday would be sketchy :)
[19:14] <_nedr> WOW.. ubuntu finally gonna ditch nautilus!!!!! HALLELUJAH! DIE IN HELL NAUTILUS, OMG WTF OKTXBAI!!!
[19:29] <dobey> wow, someone likes poor journalism
[19:29] <shadeslayer> ^^
[19:30]  * shadeslayer rages at firefox instead
[19:56] <cjwatson> there we go, 12.04.4 out
[19:57] <ari-tczew> \o/
[19:57] <sarnold> cjwatson: woot, thanks :)
[19:57] <arges> bdmurray: hi
[19:58] <arges> bdmurray: how can I help you today with the sru queue?
[20:01] <mdeslaur> \o/ 12.04.4!
[20:01] <bdmurray> arges: I haven't looked at it at all yet.  I'd start with http://people.canonical.com/~ubuntu-archive/pending-sru.html
[20:01] <Noskcaj> xfce4-weather-plugin plz
[20:02] <arges> bdmurray: what would be most useful for me to look at first? should i go through the yellow bugs?
[20:03] <bdmurray> arges: yeah, since there are not any that are all green
[21:44] <genii> console-tools is not installable but referred to by another package, etc...
[21:44] <genii> ( 14.04 )
[21:49] <Ampelbein> genii: Debian bug 671342
[23:36] <sassyn> hi all
[23:36] <sassyn> I'm a new baby when it come to pbuilder
[23:37] <sassyn> howerver, I have a question like this
[23:37] <sassyn> I want to build a pkg from 13.10 to version 10.04
[23:37] <sassyn> I manage to do so, by someing some changes to the rule/control/compact files
[23:38] <sassyn> had to take 5 pkgs and compile then as well in 10.04
[23:38] <sassyn> so by now I had all deps
[23:38] <sassyn> pkg seems to be working with no issue
[23:39] <sassyn> howerver i want now to make the same for 10.10, 11.04 etc..
[23:39] <sassyn> so I used pbuilder
[23:39] <sassyn> configure also a local repo
[23:39] <sassyn> so far so good
[23:40] <xnox> sassyn: backportpackage command part of ubuntu-dev-tools is your friend.
[23:40] <sassyn> xnox, but I'm kind of lost
[23:40] <sassyn> like 4 days until I got how pbuilder works
[23:40] <xnox> sassyn: also #ubuntu-packaging or #ubuntu-motu are usually more appropriate for pure packaging questions.
[23:41] <sassyn> ok sorry
[23:41] <sassyn> will swith to it
[23:41] <xnox> sassyn: read $ man backportpackage
[23:41] <xnox> sassyn: no, stay, since you started here =)
[23:41] <sassyn> :-)
[23:41] <sassyn> thank u
[23:41] <xnox> sassyn: just read $ man backportpackage
[23:41] <sassyn> i did
[23:41] <xnox> sassyn: it's fairly trivial to operate, and it does all the pbuilder-foo and/or upload to a ppa for you.
[23:42] <xnox> sassyn: if you did changes just point backportpackage at your modified .dsc
[23:42] <sassyn> not sure I got u
[23:42] <sassyn> say I got ulogd2
[23:43] <xnox> sassyn: backportpackage -d quantal hello_2.3-3~sassyn1.dsc
[23:43] <xnox> ditto - natty, maverick, etc.
[23:43] <sassyn> ok
[23:43] <sassyn> checking
[23:44] <xnox> sassyn: note that 10.10 & 11.04 are long end-of-life so a ppa will not build them for you, and pbuilder needs to be pointed at "old-releases.ubuntu.com" as the archive/url to bootstrap from.
[23:44] <sassyn> so let me just understand
[23:44] <sassyn> I install 14.04 for example
[23:45] <sassyn> then I just do backportpackage -d quantal hello_2.3-3~sassyn1.dsc
[23:45] <sassyn> and I get the package for quantal?
[23:45] <xnox> yes.
[23:45] <sassyn> just need to add the /etc/apt/source.list to point to quantal
[23:45] <sassyn> repo
[23:46] <xnox> sassyn: no, you don't need to modify your own /etc/apt/source.list at all.
[23:46] <xnox> sassyn: why do you say that?
[23:46] <sassyn> cause 14.04 need to know which pkg are in the dest version
[23:47] <xnox> sassyn: it doesn't need that to start running backportpackage.
[23:47] <sassyn> i will read again
[23:48] <xnox> sassyn: backportpackage will first build a source package, and then invoke a quantal pbuilder => which has quantal packages only and source, and build the package in pristine quantal chroot.
[23:48] <xnox> sassyn: adding a quantal to /etc/apt/source.list will not make your machine suddently a quantal-capable one =)
[23:48] <sassyn> reading
[23:48] <xnox> sassyn: invoke backportpackage, and read the log.
[23:48] <sassyn> to better understand
[23:49] <sassyn> u are so lucky to know this
[23:49] <sassyn> :-)
[23:49] <xnox> sassyn: then you'll understand. no need to try to comprehend this ahead of trying it out.
[23:51] <sassyn> sorry I just don't get it
[23:52] <sassyn> i have a foo.dsc file which some from version 13.10 and I want to port it to work with 10.04
[23:52] <sassyn> come*
[23:53] <sassyn> if I go with 13.10 then I can build it localy, if I create a base image using pbuilder for 10.04 then some dep are missing. so what I did is start building one by one for 10.04
[23:54] <sassyn> create a local repo for 10.04 with the dep files
[23:54] <sassyn> so by the end I could create the foo.sc
[23:54] <sassyn> then I say there are some magic way to do it from me
[23:54] <sassyn> so I can add in 10.04 point to the 13.10 repo
[23:55] <sassyn> and in some magic way it download all deps
[23:55] <sassyn> but then it failed
[23:55] <sassyn> so I miss here something
[23:57] <sassyn> what do i miss here xnox
[23:59] <xnox> sassyn: backportpackage -> helps automate backporting one package at the time, if you need to backport additional debs, one would invoke it on each missing dependency and indeed create a repository with them somewhere and add it to the pbuilder used.