=== wedgwood_away is now known as wedgwood
=== wedgwood is now known as wedgwood_away
[02:29] <slangasek> stgraber: how is pulseaudio supposed to be starting in saucy?  Because it didn't for me
[02:30] <slangasek> hmmm, possibly because I have a non-standard ~/.pulse/default.pa that goes looking for consolekit
[03:23] <pitti> Good morning
[03:24] <pitti> stgraber: hey! had an ok trip back home, but fell to ubuflu again, so I was mostly offline yesterday, sorry
[03:25] <pitti> stgraber: hm, I changed the timezone yesterday with the indicator/g-c-c, that worked fine; so if it wasn't what seb128 said, we need to debug interactively
[03:29] <pitti> ScottK: we don't yet have saucy retracers for Launchpad, as we didn't enable LP uploading of crashes yet
[03:29] <ScottK> pitti: This was raring.
[03:29] <pitti> ScottK: they should go to errors.u.c. though; ev, did you create saucy retracers already?
[03:29] <pitti> ScottK: argh, then probably they crashed again and I didn't get cron mail
[03:29] <ScottK> The problem is that e.u.c was failing to retrace them.
[03:30] <pitti> indeed, since May 4; restarting
[03:30] <ScottK> So I re-enabled apport to send to LP in the hopes of getting something.
[03:30] <ScottK> Thanks.
[03:35] <pitti> cjwatson: that's because /usr/share/polkit-1/actions/org.freedesktop.accounts.policy only allows org.freedesktop.accounts.user-administration for local consoles
[03:35] <pitti> cjwatson: we could set allow_any to auth_admin for that
[03:36] <pitti> cjwatson: (that's not related to CK vs logind); you can check your session with "loginctl" (list) or "loginctl show-session c2" (details about a session)
=== jamesh_ is now known as jamesh
=== salem_ is now known as _salem
=== mmrazik is now known as mmrazik|afk
=== doko_ is now known as doko
=== mmrazik|afk is now known as mmrazik
[06:30] <dholbach> good morning
[06:35] <dholbach> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
=== smb` is now known as smb
=== Sargun_ is now known as Sargun
=== halfie|bbl is now known as halfie
[08:02] <cjwatson> pitti: Ah, OK, so ssh to a raring/CK system would've behaved the same way?  I guess that's a regression from, um, whenever I did the CK work in openssh originally.  Yeah, I'd found loginctl - just wasn't quite sure how to interpret it in the light of the behaviour I was seeing, so thanks
[08:03] <pitti> cjwatson: so your ssh integration was basically to create a session which was "local"?
[08:04] <cjwatson> pitti: No, in the original case it was to create a session at all
[08:04] <cjwatson> pitti: And I think to accurately pass DISPLAY
[08:05] <pitti> for a non-local ConsoleKit session, PK in raring behaves the same way, yes
[08:05] <pitti> e. g. you cannot mount any USB devices and the like
[08:05] <pitti> for control-center, the policy could certainly allow authentication in remote sessions
[08:05] <cjwatson> pitti: I suspect that it's still true that logind doesn't accurately know about DISPLAY for an X-forwarded ssh connection, but I don't know if/where that matters
[08:06] <pitti> ssh -X joe@localhost
[08:06] <pitti> $ echo $DISPLAY
[08:06] <pitti> localhost:10.0
[08:06] <pitti> joe@donald:~$ xeyes
[08:06] <pitti> that works for me at least
[08:07] <pitti> logind doesn't know about the display indeed (as it's not on a seat), but ssh does the forwarding just fine apparently
[08:07] <cjwatson> Sure, that's what I meant :)
[08:07] <cjwatson> DISPLAY forwarding on its own has nothing to do with logind
[08:08] <cjwatson> I guess that if the display is necessarily associated with a seat in logind-speak then given that the docs say there's no seat for ssh connections it's OK for logind not to know about it
[08:08] <pitti> yes, that's how I understand it
[08:10] <cjwatson> (though it seems a bit odd to *specify* no seat for ssh connections, but whatever)
[08:24] <dholbach> can somebody please reject https://code.launchpad.net/~bkerensa/ubuntu/saucy/kde-artwork-active/fix-for-1169931/+merge/162656? (there was a debdiff already available for it)
[08:29] <dholbach> can somebody please reject https://code.launchpad.net/~bkerensa/ubuntu/saucy/software-center-aptdaemon-plugins/fix-for-1175101/+merge/162654 as well? (same reason)
[08:30] <dholbach> mvo, does software-center-aptdaemon-plugins have its own LP project or can I just go ahead and upload a fix to the archive?
[08:31] <dholbach> nevermind, found it
[08:32] <dholbach> mvo, can you pull from lp:~dholbach/software-center/software-center-aptdaemon-plugins?
[08:32] <mvo> dholbach: sure
[08:32] <dholbach> mvo, hugs!
[08:33] <mvo> dholbach: well, not really, you need to propose a merge and I can approve it
[08:34] <dholbach> ...
[08:34] <dholbach> sure
[08:34] <mvo> dholbach: its tarmac that is doing the merging these days
[08:34] <dholbach> ah ok :)
[08:34] <dholbach> mvo, https://code.launchpad.net/~dholbach/software-center/software-center-aptdaemon-plugins/+merge/162729
[08:35] <dholbach> mvo, you might be interested in https://code.launchpad.net/~mitya57/software-properties/lp1047424/+merge/161625 too
[10:29] <dholbach> ogra_, does the patch in https://bugs.launchpad.net/ubuntu/+source/live-build/+bug/1174791 make sense?
[10:29] <ubottu> Launchpad bug 1174791 in live-build (Ubuntu) "missing raring version string "13.04" in ./.disk/info" [Medium,New]
[10:44] <ogra_> dholbach, hmm, i thought xnox did some testing of usb-creator prior to release
[10:45] <ogra_> i wonder if he just uses a very old usb-creator
[10:57] <ogra_> dholbach, the patch makes sense but i'm curious why that issue doesnt/didnt show up in pre-release testing at all
[10:57] <zyga> hrw: hi
[10:57] <hrw> zyga: ho
[10:57] <zyga> hrw: back in canonical? :-)
[10:57] <hrw> zyga: not yet
[11:00] <ogra_> dholbach, though on a sidenote i think we originally put .disk/info in place using debian-cd
[11:00] <dholbach> I have no idea - I just thought you'd be a good person to review it
[11:01] <ogra_> well, it definitely isnt wrong to add this ... but i suspect it might not help
[11:04] <dholbach> hm
[11:04] <dholbach> ok
[11:13] <dholbach> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[11:58] <hoangchuongduong> hi every body
=== greyback is now known as greyback|lunch
[12:07] <pjotr> Hello, does anyone of you deal with langpacks for the localizations?
[12:07] <pjotr> I'm a member of the Dutch Ubuntu translators team, and I've noticed that a .mo file is missing from the Dutch langpack (and possibly from other langpacks as well)
[12:07] <pjotr> This concerns xscreensaver. I've filed a bug report about it: https://bugs.launchpad.net/ubuntu/+source/xscreensaver/+bug/1177324
[12:07] <ubottu> Launchpad bug 1177324 in xscreensaver (Ubuntu) "xscreensaver: there's no translation file in the Dutch langpack anymore" [Undecided,New]
[12:11] <pjotr> micahg: maybe you can take a look at it? This bug is pretty visible in Xubuntu...
[12:15] <infinity> pjotr: Fix uploaded.
[12:21] <pjotr> infinity: great! Is it still in Proposed?
[12:21] <vibhav> dholbach: thanks for sponsoring im-switch
=== Nigel_ is now known as G
[12:23] <infinity> pjotr: I literally uploaded it when I said I did, so yes. :)
[12:24] <infinity> pjotr: https://launchpad.net/ubuntu/+source/xscreensaver/5.15-2ubuntu2 <-- Still building.
[12:26] <pjotr> infinity: thanks for your immediate help!  :-)
[12:33] <dholbach> vibhav, no worries
=== greyback|lunch is now known as greyback
=== _salem is now known as salem_
[13:33] <infinity> diwic: D'oh.  Nice catch on the autogenerated alsa header.
[13:35] <diwic> infinity, yeah, what bothers me is how the original patch could sort-of work, because it did resolve the error for you, or didn't it?
[13:36] <infinity> diwic: I probably only tested on a locally-installed header, instead of rebuilding, reinstalling, and building against it. :/
[13:36] <diwic> infinity, ok...autopkgtests ftw?
[13:37] <infinity> diwic: An autopkgtest that tries to build a few random rdeps might catch this sort of thing, yeah.
[13:37] <infinity> kees: Your changelog for faketime/raring seems to be living in the past (glibc 2.7 indeed).
[13:37] <diwic> infinity, also it bothers me that other rdeps should have been failed building during the time it was in the archive
[13:38] <infinity> diwic: You'd think, right?  Maybe it was just sheer luck that nothing tripped on it.
[13:39] <infinity> diwic: I know the bug report I was initially responding to was someone building something out-of-archive, not an FTBFS in Ubuntu.
[13:39] <infinity> diwic: So maybe we just never (re)built anything that was affected.
[13:39] <diwic> infinity, like, all the others just happened to include sys/types.h above asoundlib.h or something?
[13:40] <infinity> diwic: Something like that, yeah.  It's not exactly uncommon to pull in types.h via other means.
[13:41] <diwic> infinity, on another note, upstream shouldn't ship asoundlib.h if it is generated during build. IMO.
[13:41] <infinity> diwic: That would certainly have eased my confusion. :P
[13:41] <infinity> (And yes, I'm a big fan of clean/distclean targets removing autogenerated files)
[13:43] <infinity> kees: Also, you didn't fix it in saucy (or were you planning to copy from raring to saucy once it was built?)
[13:49] <ekarlso> anyone here concidering https://bugs.launchpad.net/precise-backports/+bug/1162529 ?
[13:49] <ubottu> Launchpad bug 1162529 in Quantal Backports "Please backport openvswitch 1.9.0-0ubuntu1 (main) from raring" [Undecided,New]
[13:51] <tumbleweed> ekarlso: someone needs to do the testing
[13:55] <stokachu> could I get someone on SRU team to approve bug 1169740 for precise/quantal?
[13:55] <ubottu> bug 1169740 in rsyslog (Ubuntu Quantal) "rsyslog hangs loading modules" [Undecided,New] https://launchpad.net/bugs/1169740
[14:11] <cjwatson> Daviey: You seem to have discarded several Ubuntu-specific changes from debmirror?
[14:17] <stokachu> vanhoof: do you have bits for the sgs2 for ubuntu touch?
[14:42] <zyga> tedg: hey
[14:42] <zyga> tedg: in http://bazaar.launchpad.net/~ted/+junk/upstart-app-launch/view/head:/application.conf.in you can probably use env UBUNTU_APPLICATION_ISOLATION=1 and use exec rather than script
[14:43] <tedg> zyga, Ah, cool.
[14:43] <tedg> zyga, Still learning the upstart job stuff :-)
[14:44] <zyga> tedg: it's not much different but it's pretty cool
[14:44] <zyga> tedg: I love the concept
[14:44] <zyga> tedg: I wonder and worry, though, about child processes
[14:45] <zyga> tedg: so if you run gedit and gedit runs python console and there you subprocess.call("") something that won't be killed
[14:45] <zyga> tedg: but that's upstart limitation I think (and jodh correct me if I'm wrong)
[14:45]  * zyga would wish people would use git repos rather than lp/+junk 
[14:46] <tedg> zyga, There is some discussion on whether it should use cgroups to overcome that limitation.
[14:46] <tedg> zyga, Though, that's above my pay-grade :-)
[14:47] <tedg> zyga, Not sure of all the trade-offs
=== francisco is now known as Guest2384
[14:47] <zyga> tedg: yeah, I guess that's the only viable option
[14:47]  * zyga would love to be allowed to write that code
[14:48] <jodh> zyga: upstart can only follow two forks, as daemons shouldn't need to perform more. However, now we have upstart in the user session, that may need to be reconsidered. See too https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-upstart-overcome-ptrace-limitations.
[14:48] <zyga> ahh
[14:48] <zyga> thanks for that link
[14:49] <zyga> jodh: to be fair I think that deamons can easily do more than that
[14:49] <zyga> jodh: eg, celery having children
[14:49] <zyga> jodh: apache using forks
[14:49] <zyga> jodh: or ssh having client connections
[14:51] <jodh> zyga: there are a very small number of exceptions, but most well-behaved daemons follow conventions to fork up to twice before being "ready". However, wrt the exceptions, you might want to look at https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-upstart-service-readiness
[14:51] <zyga> jodh: looking at that blueprint I don't see "0) Cannot track processes spawned by the job at all" which seems like the root of all of the other issues
[14:52] <zyga> jodh: yeah, some daemons don't need that but there are some widely used exceptions :/
[14:52] <zyga> jodh: service readiness is orthogonal a bit but I see why it is relevant
[14:52] <zyga> s/relevant/important/g
[14:55] <jodh> zyga: ...and we've dealt with those exceptions by, for example, running sshd in non-backgrounding mode.
[14:56] <stgraber> cyphermox: any idea on bug 1174418? I'm clearly not seeing this behaviour on any of my desktop machines and it looks like it's a desktop thing so might be somehow related to NM.
[14:56] <kirkland> infinity: ping
[14:56] <ubottu> bug 1174418 in netbase (Ubuntu) "Privacy Extensions are set by default on Ubuntu 13.04, but no temporary address will be generate" [Undecided,New] https://launchpad.net/bugs/1174418
[14:56] <infinity> kirkland: Sup?
[14:56] <kirkland> infinity: re: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1173209, what if we just set stamp=/var/run/release-upgrade-available
[14:56] <ubottu> Launchpad bug 1173209 in ubuntu-release-upgrader (Ubuntu) "Prompted about New Release for 13.04 again after dist-upgrade and a restart" [Low,Triaged]
[14:56] <zyga> jodh: apache? celery?
[14:56] <cyphermox> stgraber: NM doesn't do privacy addresses for you; let me check
[14:56] <kirkland> infinity: so that it gets cleared on reboot?
[14:56] <zyga> jodh: I don't see any way to deal with those in general
[14:56] <kirkland> infinity: simple/clean/easy fix, right?
[14:56] <zyga> jodh: you'd need new semantics to trace that
[14:57] <kirkland> infinity: (and the upgrade check would run at least once per boot)
[14:58] <infinity> kirkland: I suppose you could abuse /var/run for that, but then you'd still have long-running systems showing you upgrade available to the "wrong" thing.
[14:59] <infinity> kirkland: Say, people who ksplice through a release, and we now want to tell them there's a new new one available.
[14:59] <cyphermox> stgraber: I don't know, I have temporary addresses here?
[14:59] <kirkland> infinity: fair enough;  part of the do-release-upgrade process should clearly rm that flag
[14:59] <stgraber> cyphermox: right, I definitely have that stuff working as expected here, so I'm a bit confused as to what that user is actually seeing...
[14:59] <infinity> kirkland: I just see two bugs here.  1) The upgrader should wipe out the file entirely, and 2) update-motd fragment shouldn't assume "populated = good", and still refresh occasionally.
[15:00] <kirkland> infinity: agreed
[15:01] <cyphermox> stgraber: possibly not seeing the temporary addresses because there is no prefix received?
[15:01] <cyphermox> or because they use the wrong tool to try and display it?
[15:01] <stgraber> cyphermox: yeah, that's what I'm wondering. I'm posting a comment asking specifically how is his IPv6 setup
[15:02] <cyphermox> anyway, if they don't get a temporary address maybe it's the kernel not generating one?
[15:02] <stgraber> cyphermox: because you clearly won't get a temporary address if you're using static or stateful DHCPv6. You only get the privacy stuff if you're doing stateless
[15:04] <smb> infinity, Bloody heck. I brain-dead uploaded lucid ec2 to main archive instead of ckt ppa. If you could rip that out of the new queue please (Lucid). Given it will not be accepted I believe I can redo the upload to the ppa
[15:04] <stgraber> cyphermox: alright, commented asking for a whole lot more information
[15:04] <cyphermox> stgraber: indeed, no way to correctly generate tempaddrs for dhcpv6 :)
[15:05] <infinity> smb: Rejected.
[15:05] <smb> infinity, thanks
[15:09] <pitti> stgraber: hey Stephane, how are you?
[15:10] <pitti> stgraber: FYI, I integrated the veth setup into NM's autopkgtests, that works fine so far; NM does recognize the devices, I thought you said that regressed?
[15:10] <pitti> (or was I talking to cyphermox about this?)
[15:11] <stgraber> pitti: yep, that was a regression from quantal. Back in quantal a veth device was considered equivalent to a physical device if it's not called "veth*"
[15:11] <pitti> stgraber: NM recognized the renamed "eth2", but ignores the non-renamed veth0
[15:11] <pitti> (in raring and upstream)
[15:12] <tedg> zyga, thanks!  http://bazaar.launchpad.net/~ted/+junk/upstart-app-launch/revision/10
[15:12] <stgraber> pitti: hmm, weird, I don't quite see that here, hold on a sec, re-testing
[15:12] <pitti> stgraber: I'll add some actual tests for these now, perhaps I just wasn't looking deep enough yet
[15:12] <pitti> stgraber: don't worry about re-testing for now, I was mostly interested in understanding what you saw
[15:13] <zyga> tedg: cool, my pleasure :)
[15:13] <stgraber> pitti: so are you seeing that if you do:
[15:13] <cyphermox> pitti: well your test seems to be proving that things might be fine?
[15:13] <stgraber> ip link add type veth
[15:13] <zyga> tedg: do you plan on landing that in saucy desktop?
[15:13] <zyga> tedg: for user sessions?
[15:13] <stgraber> ip link set name eth2 dev veth0
[15:13] <stgraber> pitti: you then get a usable eth2 in NM?
[15:14] <tedg> zyga, I think there's still more discussion to be had, as well as figuring where it belongs.  But, I'm positive on it right now.
[15:14] <stgraber> *saying
[15:14] <pitti> stgraber: that's what I'm about to write a test for; so far I just created the devs, but didn't use them yet
[15:14] <pitti> stgraber: so in that scenario you expect eth2 to work, but veth1 to be ignored, right?
[15:14] <stgraber> pitti: correct
[15:14] <zyga> tedg: ok, I cannot wait to see what's discussed at UDS then
[15:14] <pitti> stgraber: ack, thanks
[15:14] <stgraber> pitti: but what I'm actually seeing is both of them be ignored (not showing up in nm-tool)
[15:15] <cyphermox> stgraber: gah, you didn't mention this when we spoke about it :)
[15:16] <stgraber> cyphermox: what part didn't I mention? :)
[15:16] <cyphermox> NM will only detect the devices when they are attached; if there is enough of a delay between addition and rename, it won't be seen as a non-veth device :)
[15:17] <stgraber> cyphermox: oh, that's interesting
[15:17] <zyga> tedg: have you thought about using upstart for things like updating apps?
[15:17] <pitti> oh, that's it perhaps; I'm doing coldplug tests for the most part
[15:17] <pitti> I also have a hotplug test, I'll add veth hotplugging there, too
[15:17] <pitti> coldplug -> set up devices and AP, then start NM
[15:17] <pitti> hotplug -> start NM, then set up devices/APs
[15:18] <pitti> it usually takes NM some 30 seconds to pick up a newly appearing AP, thus these tests are painfully slow
[15:18] <pitti> and I do most of them in coldplug mode
[15:18] <tedg> zyga, ?  In what way?  You mean to shut them down after upgrade?
[15:19] <cyphermox> stgraber: well, it's also apparently not the issue; even if you actually add the right device it doesn't seem to be picked up
[15:20] <zyga> tedg: no, for just upgrading, like 'start update-app APP_ID=...' which would figure out how to update that particular application
[15:21]  * zyga feels that all the task names should have rev dns notation :P
[15:23] <pitti> NetworkManager[8164]: <info> (eth42): carrier is OFF
[15:23] <pitti> nmcli dev -> eth42      802-3-ethernet    unmanaged
[15:23] <mlankhorst> eth42?
[15:24] <tedg> zyga, I don't think that'd work as most apps work with a system level DB of upgrade items.  But, it is an interesting concept.
[15:24] <pitti> "guaranteed not to exist in the environments we are concerned about" :)
[15:24] <infinity> mlankhorst: It's the network that connects him to life, the universe, and everything.
[15:24] <zyga> tedg: sure but that could be customized
[15:24] <pitti> cyphermox: there doesn't seem to be an nmcli command to connect to eth, is there?
[15:25] <cyphermox> yes
[15:25] <pitti> running "dhclient -v eth42" works fine
[15:25] <zyga> tedg: eg, it could be 'apt-get install $(packages-for-app $APP_ID)' in the general case
[15:25] <cyphermox> nmcli con up id "name of connection"
[15:25] <cyphermox> stgraber: btw: sudo ip link add name foo1 type veth peer name bar1
[15:25] <pitti> cyphermox: ah, "nmcli con list" doesn't have anything
[15:25] <cyphermox> pitti:
[15:26] <cyphermox> try nmcli con up id "Wired connection 1"
[15:26] <cyphermox> let me double check that's the correct name
[15:26] <infinity> Mine's called "Auto Ethernet".
[15:26] <pitti> I guess it doesn't see a link beat on that one yet; the veth apparently only sends a link beat when it's up
[15:26] <pitti> chicken-egg
[15:27] <pitti> nope, not that one
[15:27] <pitti> I guess it actually has to appear in nmcli con list
[15:28] <cyphermox> pitti: well, it wouldn't, because that's an automatically created connection
[15:28] <cyphermox> there has to be a trick
[15:29] <mlankhorst> infinity: oh btw since lts-raring kernel is now in precise-proposed, can I upload the rest of xserver stack to precise-proposed too?
[15:29] <pitti> cyphermox: I guess I can request it via libnm-glib (I'm using the gir bindings in the tests)
[15:29] <mlankhorst> it should be just a matter of rerunning lts-stack raring at this point
[15:29] <pitti> cyphermox: nmcli is just handy for manual testing
[15:30] <cyphermox> pitti: yeah, see what the list of connections give you
[15:30] <infinity> mlankhorst: Sure.  I won't get to reviewing it this week, but maybe someone will.
[15:30] <pitti> stgraber: ok, I can reproduce your issue
[15:30] <cyphermox> pitti: maybe you just can't do that with nmcli yet
[15:30] <pitti> cyphermox: there's none
[15:30] <pitti> cyphermox: yes, apparently
[15:30] <cyphermox> :/
[15:30] <cyphermox> pitti: let dcbw know :)
[15:30] <pitti> cyphermox: I actually had expected NM to auto-connect to ethernet without explicitly telling it
[15:30] <mlankhorst> I pity the poor person reviewing, it's actually less work for me to generate the entire stack at this point ;)
[15:30] <cyphermox> yeah
[15:31] <cyphermox> pitti: that's what should happen
[15:31] <pitti> cyphermox: but I guess real ethernet devices would have a link beat
[15:31] <cyphermox> pitti: well, a veth alone won't if it's not hooked to another end
[15:32] <cyphermox> pitti: sudo ip link add name foo1 type veth peer name bar1   <-- I get both recognized
[15:32] <pitti> cyphermox: I gave the other end an IP and added dnsmasq on it
[15:32] <pitti> cyphermox: oh, "peer name" -> what's bar1?
[15:32] <cyphermox> they get brought up immediately
[15:32] <cyphermox> just a random interface name
[15:33] <pitti> cyphermox: nice, I used "ip link add type veth; ip link set name eth41  dev veth1"
[15:33] <pitti> cyphermox: so with that single command that should even be atomic
[15:34] <pitti> niice!
[15:34] <pitti> cyphermox: thanks
[15:34] <pitti> NetworkManager[8164]: <info> Added default wired connection 'Wired connection 1' for /sys/devices/virtual/net/eth42
[15:34] <cyphermox> yeah ;D
[15:34] <zyga> pitti: what are you guys doing?
[15:34] <pitti> zyga: pretending to have ethernet :)
[15:35] <cyphermox> zyga: figuring out how to test fake ethernet devices
[15:35] <zyga> oh
[15:35] <zyga> testing?
[15:35] <pitti> zyga: I am adding ethernet tests to NM's autopkgtest
[15:35] <zyga> awesome
[15:35] <pitti> zyga: I already have a nice collection of wifi tests
[15:35] <zyga> pitti: we should organize a mini sprint one day, so that our wireless/wired network tests could be themselves tested without real hardware
[15:36] <pitti> zyga: the wifi tests don't use real hw either
[15:36] <pitti> mac80211_hwsim FTW
[15:36] <zyga> pitti: yeah I understand
[15:36] <zyga> pitti: my point is that we (Certification) have tests that validate if hardware actually works
[15:36] <zyga> pitti: and those tests are sometimes buggy or regress
[15:37] <zyga> pitti: we'd love to be able to run tests against 'virtual' hardware for each merge for example
[15:37] <pitti> yeah, that's what we do with autopkgtest
[15:37] <zyga> pitti: to essentially be able to unit test a script that checks if wifi works
[15:37] <pitti> once autopkgtest is properly wired into britney, a NM, dhclient, wpasupplicant, kernel, some library, or whatever that breaks any of those will cause the package to not get into ubuntu
[15:39] <zyga> pitti: it would be equally good if we could write and run tests that our vefification programs (test is so overloaded in this context) would never regress
[15:39] <zyga> pitti: and not having to run them against, eg, real access point and wifi card
[15:39] <pitti> well, we still need tests against real hw
[15:39] <zyga> pitti: I don't yet understand how those would work
[15:39] <zyga> pitti: we do
[15:39] <zyga> pitti: and we run tests on real hardware for cerfification
[15:39] <pitti> above autopkgtests ensure that the userland is okay, but they don't cover any driver of course
[15:39] <zyga> pitti: but for each commit that lands to our project, we should also tests stuff that normally depends on hardware
[15:40] <zyga> pitti: testing on real hw is much more problematic and we don't do it
[15:40] <zyga> pitti: (for development)
[15:49] <Laney> mterry: yo dawg, any chance I can hassle you to look at / merge https://code.launchpad.net/~laney/lightdm/fix-lightdm-qt-pcfile/+merge/162797 quickly?
[15:50] <Laney> I want to upload it to saucy soonish as it's needed to unstick lightdm from proposed
[15:50] <zyga> plars: hey
[15:50] <zyga> plars: do you have the time for utah sync meeting?
[15:50] <mterry> Laney, I believe I already updated that in trunk
[15:50] <Laney> you did for qt5 but not the other one
[15:51] <kirkland> infinity: fyi, https://code.launchpad.net/~kirkland/ubuntu-release-upgrader/1173209/+merge/162798
[15:51] <mterry> Laney, guh, I must have misread it then.  Thought the qt4 one had already been changed
[15:51] <Laney> :-)
[15:51] <Laney> for an upload, can I just distropatch as normal?
[15:52] <mterry> Laney, yeah.  I approved the branch
[15:52] <Laney> sweet, doing that then
[15:52] <Laney> merci
[15:52] <plars> zyga: probably not today
[15:52] <zyga> plars: could you please move the meeting to a slot that suits you?
[15:54] <plars> zyga: sure, I'll look in a bit
[15:54] <zyga> plars: thanks!
[16:01] <Laney> hmm, do we not have up-to-date udd branches for saucy yet?
[16:01] <Laney> xnox: ^?
[16:01] <pitti> cyphermox: would you know why "ip link set dev eth42 up" (i.e. the peer) works and brings up both devices, but up'ing veth42 doesn't work?
[16:01] <pitti> well, I guess that's just a quirk of veth
[16:02] <pitti> I wouldn't like to up the client-side eth myself, as NM is supposed to do that
[16:02] <pitti> but without it I don't seem to get a link
[16:03] <pitti> ah, when I run that while NM is already running, it works
[16:03] <pitti> it just doesn't pick it up at startup
[16:06] <Laney> xnox: ah, nm, it's just that ubuntu:package gets release not proposed
[16:08] <cyphermox> pitti: not sure, like you think i'd say it's a quirk of veth
=== wedgwood_away is now known as wedgwood
[16:30] <ekarlso> I get gpg: /tmp/debsign.Cw0XdNLo/openvswitch_1.9.0-0ubuntu1~ubuntu12.04.1~ppa1.dsc: clearsign failed: secret key not available
[16:30] <cjwatson> you can ignore that if you don't have a key set up
[16:31] <ekarlso> when doing: backportpackage -u ppa:endre-karlson/virtualization -s raring -d precise openvswitch
[16:31] <ekarlso> cjwatson: yeah, but it fails ...
[16:31] <cjwatson> ah, if you're planning to upload to a PPA then you do need to fix that
[16:31] <ekarlso> :)
[16:31] <cjwatson> look up your key ID in 'gpg --list-keys' and put DEBSIGN_KEYID=that-key-id in ~/.devscripts
[16:31] <cjwatson> is the simplest way to override if it's not autodetecting
[16:32] <cjwatson> lack of autodetection probably means that your key doesn't have an ID for the e-mail address you're using in your changelogs
[16:42] <Riddell> siretart: who maintains UEHS?
=== mmrazik is now known as mmrazik|afk
[17:06] <bdmurray> stgraber: bug 1176580 doesn't seem possible to me but I don't see anything in casper preventing it
[17:06] <ubottu> bug 1176580 in casper (Ubuntu) "Raring Suspend on Install" [Undecided,New] https://launchpad.net/bugs/1176580
[17:09] <stgraber> bdmurray: I don't remember casper having any code for that, however ubiquity sets a bunch of gsettings key which IIRC includes suspend settings
[17:10] <bdmurray> stgraber: having it ubiquity would make more sense for using live media
[17:12] <stgraber> bdmurray: I'm also susprised that suspending messes up the install. We clearly don't recommen closing the lid or installing on low battery but I'm not sure why this would lead to failed data copy.
=== wedgwood is now known as wedgwood_away
=== mitya57_ is now known as mitya57
[18:33] <siretart> Riddell: what's uehs?
[18:34] <mitya57> http://qa.ubuntuwire.com/uehs/
[18:39] <Riddell> wgrant: is uehs your baby?
=== sraue_ is now known as sraue
=== apachelogger is now known as Phonon
[21:42] <wgrant> Riddell: Yes, though it hasn't been "maintained" as such in probably 5 years.
=== salem_ is now known as _salem
[22:01] <Riddell> wgrant: is the source code somewhere?
[22:02] <wgrant> Riddell: lp:dehs, IIRC
[22:02] <wgrant> I just import it from Debian and rebrand it slightly, I think
[22:32] <infinity> Daviey: You dropped a ton of changes from debmirror when you force-synced it...
[22:33] <cjwatson> infinity: Yeah, I commented on that earlier too.  I guess he's busy sprinting
[22:33] <infinity> cjwatson: I uploaded a proper merge just now.
[22:34] <cjwatson> infinity: Thanks
[22:55] <bdmurray> stgraber: could you have a look at bug 1176046?
[22:55] <ubottu> bug 1176046 in isc-dhcp (Ubuntu) "isc-dhcp dhclient listens on extra random ports" [Medium,Triaged] https://launchpad.net/bugs/1176046
[22:58] <Daviey> infinity / cjwatson: Ugh. My bad.  Thanks for resolving.
[22:59] <Daviey> infinity: In future, do just raise it - i'll clean up my mess. But thanks for doing it. :)
[23:02] <stgraber> bdmurray: I saw the bug report but I don't think we should disable the feature so for now I'm just keeping it as it's waiting for more people to comment (or will just won't fix it in a little while if nobody does)
[23:02] <stgraber> (we're no different from Debian on that bit, I don't think it's a big security risk and corp environments need the feature)
[23:04] <bdmurray> stgraber: okay, sounds good
[23:05] <stgraber> mdeslaur: maybe you have a different opinion on this, but to me this sounds like a feature that's actually used, has been around for years and isn't a huge security risk (considering dhclient runs under apparmor anyway).
[23:10] <mdeslaur> stgraber: I agree