[01:41] <ChinnoDog> Speaking of thanksgiving, where is our turkey?
[01:48] <teddy-dbear> hiding
[02:27] <InHisName> Guess you'll have to settle for Thanks Giving Hot Dogs this year, ChinnoDog
[02:33] <ChinnoDog> :-(
[02:42] <InHisName> Of the 50-60 ThanksGivings My siblings and I have lived thru, The Hot Dogs T'Giving was the one we reminise about when we get together.       We lost electric 3 hours before begining baking the turkey and it did not come back one until Sun.   Transformer furniture?
[18:12] <ChinnoDog> Transformer like Megatron or like a bed that converts into a table?
[18:18] <JonathanD> I like the chair that turns into a stove, though.
[18:18] <JonathanD> pleia2: this does not look like a persons blog.
[18:18] <pleia2> JonathanD: yeah, I'm thinking I'm just going to user my superpowers to just remove it from planet
[18:19] <JonathanD> I want a stove chair for christmas.
[18:19] <JonathanD> I think everyone needs one of those.
[18:19] <JonathanD> ChinnoDog: beds that convert into tables. Or toilets. Or stoves.
[18:20] <JonathanD> a coffee table that becomes a fireplace.
[18:27] <lamalex> pleia2, i thought my blog was taken off the planet
[18:28] <lamalex> lamalex.net is no longer owned by me so "hacked" isn't the right work
[18:28] <lamalex> word
[18:28] <pleia2> lamalex: I removed it from the pennsylvania planet, but it's still going to planet.ubuntu.com, you should remove it :)
[18:28] <JonathanD> That makes sense :)
[18:30] <lamalex> that sounds awesome, what's the problem
[18:30] <lamalex> sounds like it's putting out much better content than i was
[18:31] <JonathanD> haha :)
[18:31] <JonathanD> The chair oven is kinda cool lamalex . I have to admit.
[18:31] <JonathanD> sorry, chair stove.
[18:31] <JonathanD> I'm going to invent the chair oven. You'll see.
[18:33] <lamalex> a clear progression from chair stove
[18:33] <lamalex> tranformer furnitures top engineers are working feverishly
[18:33] <JonathanD> I agree.
[18:34] <JonathanD> There needs to be a fridge chair, too.
[18:34] <JonathanD> Get those, and that puzzle piece table, and you're living room turns into a kitchen just like that.
[18:41] <JonathanD> InHisName: mine came yesteryda.
[18:44] <ChinnoDog> JonathanD: the bed toilet is a bad idea. You would pee yourself in the morning while trying to fold up your bed to get to the toilet.
[18:46] <ChinnoDog> Stove chair would put you in the hot seat if into adequately insulated
[18:46] <JonathanD> fridge chair would dump everythin all over the place when you flipped it.
[18:47] <ChinnoDog> There are ways to avoid tipping stuff but you would have to get up every time you wanted to get a beer out of the fridge. That is too much work.
[18:48] <jedijf> ChinnoDog: did you buy lamalex.net?
[18:48] <ChinnoDog> lol
[18:49] <ChinnoDog> no but apparently it is a gold mine
[18:54] <pleia2> removed
[19:00] <ChinnoDog> I'd like a desk / wet bar
[19:01] <ChinnoDog> Converts from work time to play time and back
[19:05] <JonathanD> Wait, it converts work time into play time?
[19:05] <JonathanD> Sign me up.
[23:54] <InHisName> Still have problems getting https trackers to work in my backup system.   Maybe I should start over from scratch.
[23:55] <InHisName> I have 3 partitions:  1. /   2. /home  3/boot      Is there way to leave /home alone  and only rebuild / without touching /home ?
[23:56] <InHisName> I'll check back after 8 for notes.


[08:35] <dholbach> good morning
[10:20] <ogra_> mvo, Chipaca, do you guys know if we expose the package version somewhere in the environment of snap services/binaries (i.e. how would my app know it has just been upgraded)
[10:21] <ogra_> i think we need some mechanism to make the package know when it needs to run any confi migration scripts
[10:22] <ogra_> *config
[10:22] <mvo> ogra_: it should be available via SNAP_VERSION
[10:22] <ogra_> ah, thanks !
[10:22] <mvo> ogra_: hm, there was discussion about providing a native hook for this from snappy itself
[10:23] <JamesTait> Good morning all; happy Monday, and happy Computer Security Day! 😃
[10:23] <ogra_> yeah, that would be cool ... but for the moment i can use that var ... (just updating a stamp file and compare on service start)
[10:27] <ogra_> geez, "snappy build" is amazingly slow o armhf :/
[10:27] <ogra_> *on
[10:27] <ogra_> 11min for a package that takes 2min to build on amd64
[10:30] <longsleep> Is /writable/cache somehow used on boot again? I see some service duplication and the only location where the old service file exits is in /writable/cache/system
[10:32] <ogra_> it should be readonly mounted after boot ... but nothing else
[10:32] <ogra_> /writable/cache/system that is
[10:33] <longsleep> ogra_: yes it is mounted ro there, but something seems to copy all the files in there on boot
[10:33] <longsleep> ogra_: could that be?
[10:33] <ogra_> i dont think so
[10:33] <ogra_> it is your "other" readonly partition
[10:34] <longsleep> right - this is very strange
[10:34] <longsleep> i delete a file from /etc/systemd/service and disable the service with systemctl as well, reboot then it is there again
[10:34] <ogra_> probably some generator ?
[10:35] <ogra_> though even that should respect that you disabled it
[10:35] <longsleep> the service comes from a snap - snap is still installed as newer version
[10:35] <longsleep> the version the service gets generated for is not on the disk - at least i cannot find it
[10:36] <longsleep> i see the issue for more than one snap though. It seems like when a builtin snap is updated, the systemd service of the version which is oem is recreated on boot for unknown reason
[10:37] <ogra_> that sounds definitely like a bug
[10:37] <longsleep> ogra_: yeah, though i was unable to figure out how that even happens yet
[10:41] <longsleep> so, before reboot the service was only in /writable/cache/system/etc/systemd/system, after reboot it is in /etc/systemd/system - so something must copy it
[10:43] <ogra_> longsleep, i guess the issue is that it is in /writable/cache/system/etc/systemd/system at all ...
[10:43] <ogra_> thats a readonly system ... no snap should be able to put anything there ever
[10:43] <longsleep> ogra_: true, but those are put there by u-d-f i think
[10:44] <longsleep> ogra_: the snaps are preinstalled with the oem snap
[10:44] <ogra_> hmm, sounds wrong to me to put them in the readonly partition
[10:45] <longsleep> yeah, they will never go away
[10:45] <longsleep> i would be fine with that, but how are they cloned on boot?
[10:45] <longsleep> i mean that causes the problem after all
[10:49] <longsleep> ogra_: i think it is synced in the initrd
[10:51] <ogra_> longsleep, i wouldnt see how
[10:51] <longsleep> ogra_: well, there is some code in the ubuntu-core-rootfs of the initrd which does some copying
[10:51] <ogra_> yes
[10:51] <longsleep> ogra_: maybe i use ancient version again
[10:51] <ogra_> one sec
[10:52] <ogra_> bah, i was hoping for a wrong setting in /etc/system-image/writable-paths ... but seems the cache path is actually hardcoded
[10:53] <ogra_> hmm, k ...
[10:53] <ogra_> the initrd doesnt mount it at all
[10:54] <ogra_>         if [ -n "$other" ]; then
[10:54] <ogra_>                 echo "$other /writable/cache/system auto defaults,ro 0 0" >> "$fstab"
[10:54] <ogra_>         fi
[10:54] <longsleep> right
[10:54] <ogra_> thats all it does ... right before run-init
[10:54] <ogra_> so if there is any syncing thats not happening in the initrd
[10:54] <longsleep> maybe it runs into one of the other conditions which do cp -A
[10:55] <longsleep> i mean the file ending up in /etc/systemd/system has the same timestamp as the one in /writable/cache/system/etc/systemd/system
[10:56] <ogra_> well, there must be some systemd unit that copies it
[10:56] <ogra_> when processing fstab
[10:56] <longsleep> ok let me check if i can find something there
[11:33] <longsleep> ogra_: well, i could not find it and now i even removed the file from /writable/cache/system/ and it still gets recreated magically in /etc/systemd/system
[11:33]  * longsleep has no idea where it comes from
[11:39] <fgimenez> hi Chipaca, have a minute?
[11:55] <dholbach> mvo, can you (or somebody else) help with https://code.launchpad.net/~jdstrand/click-reviewers-tools/click-reviewers-tools.snappy1604/+merge/278218?
[12:46] <ogra_> Nov 30 13:44:32 aleph2 systemd[1]: Starting minidlna DLNA server...
[12:46] <ogra_> Nov 30 13:44:32 aleph2 ubuntu-core-launcher[26252]: /apps/upnp-server-amd64.sideload/IGccOWeCMeET/minidlnad: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /apps/upnp-server-amd64.sideload/IGccOWeCMeET/usr/lib/x86_64-linux-gnu/libsnappy.so.1)
[12:46] <ogra_> Nov 30 13:44:32 aleph2 systemd[1]: Reloading.
[12:46] <ogra_> woah
[12:46] <Chipaca> jdstrand_: tyhicks: ping about snapd and ACLs
[12:48] <Chipaca> well, not ACLs, but permissions on the unix socket and SO_PEERCRED
[12:59] <mvo> dholbach: I have a look after the meeting, thanks
[13:00] <longsleep> Chipaca: Hey, maybe you can help me in finding the script which creates snappy systemd services in /etc/systemd/system/ on boot. I have the problem that a service keeps appearing there while that snap version is not installed
[13:01] <mvo> longsleep: do you install something that has a service duing your u-d-f run?
[13:01] <longsleep> mvo: yes
[13:02] <longsleep> mvo: the oem snap has several snaps as built-in
[13:02] <mvo> longsleep: I think there is a bug in u-d-f
[13:02] <longsleep> mvo: when updating those, the old systemd service gets not removed and recreated on boot
[13:02] <longsleep> mvo: yeah that makes sense, though where does u-d-f store the information so the service can actually be recreated
[13:07] <dholbach> mvo, cool, thanks
[13:21] <ogra_> jdstrand_, is the chwon blocking really necessary given we cant actually chown anything outside of the writable area of the snap anyway ? i have massive probs with it atm trying to package something that uses two services which both call fchown/fchown32
[14:39] <tyhicks> Chipaca: hey - I need some more context as I don't know if I've heard anything about that yet
[14:40] <Chipaca> tyhicks: you probably haven't :)
[14:40] <Chipaca> tyhicks: you remember snapd, the snappy daemon that runs as root, that you connect to over a unix socket?
[14:40] <tyhicks> Chipaca: yep
[14:40] <Chipaca> tyhicks: that socket is 0600 root:root right now
[14:41] <Chipaca> tyhicks: wanting to relax that so regular users can connect
[14:41] <Chipaca> tyhicks: so, server uses SO_PEERCREDS on the socket to determine uid, deny access to privileged ops to non-privileged users
[14:41] <tyhicks> ok
[14:42] <Chipaca> tyhicks: would like you or jamie to go over what/how we're doing that before actually lowering the 0600
[14:42] <tyhicks> Chipaca: is there a MP?
[14:43] <Chipaca> tyhicks: the code that does SO_PEERCRED is already in master
[14:43] <Chipaca> tyhicks: 1 sec and i'll point you at the relevant file itself
[14:44] <Chipaca> tyhicks: https://github.com/ubuntu-core/snappy/blob/master/daemon/ucrednet.go
[14:44] <tyhicks> Chipaca: ack, I should be able to have a look in a day or two
[14:44] <Chipaca> tyhicks: that's the wrapper that knows about SO_PEERCRED and uses it to get the uid for unix connections
[14:44] <tyhicks> (maybe today)
[14:45] <Chipaca> tyhicks: and then https://github.com/ubuntu-core/snappy/blob/master/daemon/daemon.go#L67 checks things before allowing access
[14:46] <tyhicks> ok
[14:46] <Chipaca> tyhicks: it's a rather hackish first pass that stuffs the uid in the RemoteAddr of the transfer, but modulo that it seems sane to me
[14:47] <Chipaca> transport*
[14:47] <Chipaca> tyhicks: yeh, no hurry
[14:47] <Chipaca> well, no hurry beyond the usual :-)
[15:38] <rickspencer3> mvo, can you please give me a link to the correct rolling image for rpi2 if I want to install and test 16.04 rolling?
[15:38]  * rickspencer3 notes the web site still points (correctly, I think) to 15.04
[15:39] <mvo> rickspencer3: we don't have a pre-build xenial image right now (unless ogra_ did some for rpi2). you can use ubuntu-device-flash to build an image. maybe it would be a good idea to make a snapshot available for easier testing
[15:40] <rickspencer3> ack
[15:57] <longsleep> so, what other tool on a snappy system can create systemd services for snaps? I still have not found the reason why old services keep appearing on boot. They are not generated by /usr/bin/snappy :/
[16:00] <Chipaca> longsleep: what are the files that won't die?
[16:00] <ogra_> mvo, no, i didnt, i would like us to eventually produce whole images for xenial in an automated way though
[16:01] <ogra_> s/for xenial//
[16:01] <longsleep> Chipaca: i have snaps with services installed via oem built-in - when those get updated everything seems fine. But on reboot the service files reappear in /etc/systemd/system/
[16:02] <longsleep> Chipaca: i have looked and looked but seem unable to find out how these files are generated / where they come from :/
[16:03] <Chipaca> longsleep: you mean you have a snap that you include from oem, that in an update removes a service? or is it services for old versions that appear?
[16:04] <longsleep> Chipaca: spreedbox-led_ledd_0.0.9-4.service is the new service, spreedbox-led_gnatsd_0.0.6-1.service the old. spreedbox-led_gnatsd_0.0.6-1.service is removed after update. Then reboot and spreedbox-led_gnatsd_0.0.6-1.service is there again
[16:05] <longsleep> Chipaca: it is the same problem for all services installed via oem
[16:05] <longsleep> Chipaca: on update, the old service gets removed fine. Then reboot and it is back (and fails to start)
[16:05] <longsleep> Chipaca: what troubles me is that i seem to be unable to figure out where it comes from
[16:06] <Chipaca> longsleep: could i see the output of 'sudo journalctl' on a reboot with these things happening?
[16:06] <Chipaca> longsleep: firstboot is the thing that might be doing that, but it shouldn't be running
[16:07] <longsleep> Chipaca: sure
[16:07] <Chipaca> and ... yeah, it doesn't make sense
[16:09] <longsleep> Chipaca: it says started firstboot setup every time
[16:10] <longsleep> let me check when i remove the firstboot stamp and run it manually
[16:11] <longsleep> Chipaca: no, removing the stamp and running snappy firstboot did not create the service file again
[16:11] <Chipaca> phew
[16:12] <longsleep> Chipaca: i have a patched version of snappy, which adds a custom X- header to the service file when snappy generates it, for the file which keeps reappearing it does not have that header
[16:12]  * Chipaca looks up phone numbers of exorcists
[16:12] <longsleep> Chipaca: it is either copied from some place or created from some other tool
[16:12] <Chipaca> longsleep: ooh, nice
[16:12] <Chipaca> ogra_: pingu
[16:12] <ogra_> yo yo
[16:13] <Chipaca> ogra_: is there anything in initrd/early boot that could be copying a service file?
[16:13] <ogra_> no
[16:13] <ogra_> hmm
[16:13] <ogra_> well
[16:13] <longsleep> It also needs to copy it from some place, i have removed all locations below /writable where that file could be found
[16:13]  * ogra_ checks something
[16:14] <Chipaca> longsleep: can you mount and see if it's in /etc *under* writable?
[16:14] <longsleep> Chipaca: mount what exactly?
[16:14] <Chipaca> longsleep: umm... system-a? partition #3 iirc
[16:15] <Chipaca> longsleep: on a brand new image
[16:15] <longsleep> Chipaca: sure - hold on
[16:15] <Chipaca> longsleep: (or on a booted one, really)
[16:15] <longsleep> Chipaca: brand new booted one - without upgrading?
[16:15] <Chipaca> longsleep: yep
[16:16] <longsleep> Chipaca: flashing now, takes 70 seconds
[16:16] <Chipaca> longsleep: ok. just mounting the image locally would also work :-)
[16:16] <longsleep> Chipaca: that would not be booted though
[16:17] <Chipaca> ah, sorry i meant booting it or not shouldn't make a difference to that partition
[16:17] <Chipaca> although, having said that, if it _did_ make a difference that'd be interesting in and of itself
[16:17] <ogra_> Chipaca, so the entry for /etc/systemd/system in /etc/system-image/writable-paths is "synced none none" so yes, content from the readonly fs will be synced on boot
[16:17] <longsleep> ah
[16:18] <ogra_> and etc gets processed from initrd
[16:18] <ogra_> (remember, we had to move it because of races)
[16:18] <longsleep> finally the mystery solved!
[16:18] <ogra_> well, the bug is that fragments from snaps are on the readonly partition
[16:19] <ogra_> that shouldnt be
[16:19] <longsleep> /media/longsleep/system-a/etc/systemd/system/spreedbox-led_gnatsd_0.0.6-1.service
[16:19] <longsleep> that is the non booted image
[16:19] <ogra_> right
[16:19] <Chipaca> so the bug is that those are getting created by snappy during the u-d-f unpack/install thing
[16:19] <ogra_> yeah
[16:20] <ogra_> they would have to go into the writable space
[16:20] <longsleep> i see - so this needs fixing in u-d-f
[16:20] <ogra_> since they are from snaps :)
[16:20] <Chipaca> longsleep: in snappy, actually
[16:20] <ogra_> (all of the snaps shuld go into the writable space in fact)
[16:20] <longsleep> Chipaca: right
[16:20] <Chipaca> (u-d-f calls into snappy)
[16:20] <longsleep> Chipaca: so add a flag or something, similar to the existing ones
[16:20] <Chipaca> yep
[16:21] <Chipaca> flag already exists
[16:21] <Chipaca> InhibitHooks
[16:21] <ogra_> Chipaca, but if udf doesnt set up the mounting in a way that the snap bits land in writable places you have lost
[16:21] <ogra_> not necessarily a snappy bug imho
[16:21] <Chipaca> ogra_: the service files should not be created at udf time; firstboot creates them
[16:21] <longsleep> that would be easy to fix
[16:22] <longsleep> so for testing, i could remove the snap services from system-a and then do a boot
[16:22] <longsleep> right?
[16:22] <Chipaca> longsleep: yep
[16:23]  * longsleep gives it a try
[16:23] <ogra_> Chipaca, aha ... nontheless, snap fragments should not live in the readonly rootfs
[16:24] <ogra_> and i assume there is no "boot" happening when udf assembles the img ... whihc means if you do anything chrooted in the img you wont have the mountpoints set up
[16:25] <ogra_> (i can be wrong indeed ... just guessing)
[16:25] <longsleep> well, i removed the service files before firstboot, but firstboot did not create them
[16:27] <longsleep> Chipaca: yeah not installing the services in u-d-f is bad as they are not created again and update fails as the service is not loaded
[16:27] <Chipaca> :'-(
[16:27]  * Chipaca forgot how to emoticon
[16:28] <longsleep> Where do you want to have the bug for this? github snappy or udf on launchpad?
[16:28] <Chipaca> sergiusens: mvo: ping
[16:28] <Chipaca> longsleep: gimme a sec
[16:29] <Chipaca> so the easy way would be to hack udf to set things up properly
[16:29] <Chipaca> i think a better way would be to make snappy not activate anything from udf, and instead add that to firstboot (which i thought was one of the things oemconfig was doing anyway)
[16:29] <Chipaca> but there might be a reason not to do it this way
[16:29] <longsleep> Chipaca: yeah, i guess we can do that and somehow move the things to writable
[16:30] <Chipaca> hence me pinging mvo and sergiusens :-)
[16:30] <Chipaca> longsleep: writable is there at udf time, just needs bind-mounting properly (or things moved to the right place post hoc, which is tricky because of random cruft in /etc/systemd/system (that shouldn't be there anyway (but I digress)))
[16:31] <ogra_> +1 for firstboot, that is where it belongs
[16:31] <longsleep> Chipaca: so the other cruft in there should stay readonly ?
[16:32] <longsleep> ogra_: yes, though that is unlikely to happen for 15.04 right?
[16:32] <ogra_> yeah, for that the hack might be a better approach
[16:35] <sergiusens> Chipaca, the plan is to move it to firstboot
[16:35] <sergiusens> Chipaca, if you care to create the PR for it, great ;-)
[16:35] <ogra_> the PR ?
[16:36] <sergiusens> ogra_, pull request
[16:36] <ogra_> event planning ? cheerleaders, free food and flyers ? as in public relations ?
[16:36] <ogra_> aahh !
[16:36] <sergiusens> Chipaca, in any case, I'd prefer if the image creator just dropped the snaps (except kernel and os) into a defined location and firstboot do its thing
[16:37] <ogra_> +1
[16:37] <ogra_> isnt that what we do on the phone ?
[16:37] <ogra_> (for custom tarballs)
[16:38] <ogra_> jdstrand, i assume you missed my ping from this morning ?
[16:38] <sergiusens> ogra_, no; sadly no
[16:38] <sergiusens> unless it changed recently
[16:39] <ogra_> oh, i thought we did
[16:39] <ogra_> we really should :)
[16:40] <Chipaca> sergiusens: for 15.04 also?
[16:40] <mvo> Chipaca: sorry, I was in a meeting - so I think the issue that longsleep is seeing is fixed with something like http://bazaar.launchpad.net/~snappy-dev/goget-ubuntu-touch/all-snaps/revision/226
[16:40] <mvo> Chipaca: but I think that your idea of installing them on first boot is better, however this won't work for the OS snap (as it needs to be ready for first-boot)
[16:41] <Chipaca> no no
[16:41] <mvo> no?
[16:41] <Chipaca> my idea was *activating* them on first boot
[16:41] <Chipaca> not installing them
[16:41] <Chipaca> in squashfs world that might be the same thing tho :-)
[16:42] <Chipaca> but in 15.04 having the unpack done at build time, and the activation at first boot, seems sane and should be easily doable
[16:42] <Chipaca> but i don't know if we want to, and if there is going to be a release of this
[16:42] <Chipaca> hence, calling you
[16:43] <ogra_> well, we didnt stop doing monthlies for 15.04, did we ?
[16:43] <ogra_> to have the images pick up -security and -updates
[16:45]  * Chipaca waits for mvo to confirm that
[16:46] <longsleep> Chipaca: to hack it, where exactly do the files need to go on the writable partition? i see a system-data folder there
[16:47] <longsleep> Chipaca: create etc/systemd/system in there ?
[16:47] <mvo> Chipaca: ups, sorry. indeed, this does make sense. I'm not sure if/when we do a 15.04 release though either, maybe worth bringing up at the next standup?
[16:48] <mvo> longsleep, Chipaca: I need to run very soon to play hockey, however I'm happy to discuss this further tonight/tomorrow
[16:48] <ogra_> mvo, we'll need to sit down tomorrow too to talk about allsnaps and the build system
[16:48] <Chipaca> i'll look at getting a branch up with this
[16:48] <Chipaca> also, we need to get edge working on arm again
[16:48] <mvo> ogra_: sure
[16:49] <Chipaca> and plan the next monthly 1504 (which i think we've slipped, unless time has done its usually stretchy snappy thing)
[16:49] <mvo> Chipaca: yeah, no idea about the test failure right now :/ still need to investigate on a porter machine
[16:49] <longsleep> mvo: sure, i think i understood the problem and might figure out a hack for now - but it would be awesome if there would be a fix for 15.04
[16:49] <Chipaca> mvo: blame ogra_, then he'll fix it :-p
[16:50] <longsleep> mvo: also this one would be nice on https://github.com/ubuntu-core/snappy/issues/189 - we have patched it locally but i guess others might have the issue as well
[16:50] <ogra_> Chipaca, heh, ask davmor2 ... that only works sometimes
[16:50] <Chipaca> longsleep: i can't be sure offhand. easiest way would be to see on upgraded machine what /writable looks like
[16:50] <longsleep> Chipaca: good idea thanks
[16:50] <mvo> longsleep: aa, nice
[16:50] <davmor2> ogra_: no it works all the time, you just go blame the right person :D
[16:53] <longsleep> sync
[16:53] <longsleep> ups :)
[16:55] <rickspencer3> ogra_, are there steps I can follow to make a rolling 16.04 rpi2 image today?
[16:58] <Chipaca> rickspencer3: u-d-f doesn't work?
[16:58] <rickspencer3> Chipaca, I did not say that, I was looking for documentation
[16:59] <rickspencer3> :)
[16:59] <ogra_> rickspencer3, once sec i can give you a cmdline (the rpi püage needs updating for that)
[17:02] <longsleep> Chipaca: ok i got scripting which fixes the problem: http://paste.ubuntu.com/13579233/
[17:02] <longsleep> Chipaca: i think i can add that as a post process step to our image builder
[18:19] <ogra_> rickspencer3, sudo ubuntu-device-flash core rolling --channel edge --oem pi2.canonical --enable-ssh --device raspi2_armhf --output raspi2-rolling.img
[18:19] <ogra_> (sorry, i had not forotten you :) )
[18:19] <ogra_> (and ignore the moaning about azure :) )
[18:55] <jdstrand> Chipaca: hey, fyi, going through old irc (I was on holiday last week). I updated /usr/share/apparmor/easyprof/policygroups/ubuntu-core/15.04/snapd to have /run/snapd.socket in 15.04.12~ppa12 on Nov 13. I looks like stable hasn't been updated since then
[18:57] <Chipaca> jdstrand: a'yup
[18:57] <Chipaca> jdstrand: welcome back to the world of the living, and all that
[18:59]  * rickspencer3 tries
[19:03] <Chipaca> ogra_: unless you've uploaded a pi2 since the channels work, that needs to be pi2.canonical/stable
[19:03] <ogra_> Chipaca, really ? udf cares ?
[19:03] <Chipaca> no, it doesn't care, which is why that works :-)
[19:04] <ogra_> ah :)
[19:04] <Chipaca> it's just passing that on to the CPI REST API
[19:04] <ogra_> rickspencer3, ^^
[19:04] <Chipaca> and CPI cares. In fact that's all it cares about ;-)
[19:04] <Chipaca> sudo ubuntu-device-flash core rolling --channel edge --oem pi2.canonical/stable --enable-ssh --device raspi2_armhf --output raspi2-rolling.img
[19:04] <Chipaca> ^ seems to work
[19:04] <rickspencer3> oh
[19:05] <Chipaca> that /stable is a temporary workaround until we get things into the edge channel itself
[19:05]  * rickspencer3 tries again ;)
[19:06]  * rickspencer3 happily kicks off his "azure" image
[19:08] <rickspencer3> ogra_, Chipaca seemed like it downloaded the parts and built the image quite quickly
[19:08]  * rickspencer3 prepares to dd
[19:08] <ogra_> good
[19:08] <rickspencer3> ogra_, just dd it to sbx as per usual, right?
[19:08] <ogra_> yeah
[19:08] <ogra_> all the same for all images :)
[19:10]  * rickspencer3 dds and waits
[19:28] <Chipaca> http://people.canonical.com/~john/wow-so-peercred-much-access-levels.gif btw
[19:29] <Chipaca> tyhicks: ^ might be relevant (or not)
[19:34] <tyhicks> Chipaca: that's showing that the access checks aren't working as expected?
[19:34] <Chipaca> tyhicks: no, it's showing that they are
[19:35] <tyhicks> ah, right
[19:35] <Chipaca> tyhicks: in retrospect i should have paused before hitting enter on 'sudo !!'
[19:35] <Chipaca> assuming that is what tripped you up :)
[19:36] <tyhicks> opening up the socket to be world read/write today means that root is still required
[19:36] <tyhicks> yes, I think that is what tripped me up
[19:37] <Chipaca> tyhicks: root is still required <- for privileged operations you mean?
[19:39] <sandGorgon> hey guys... is there a snappy based ISO that I can try out and play with ? I'm looking at http://cdimage.ubuntu.com/daily-live/current/xenial-desktop-amd64.iso but dont know if it is intended with dpkg or snappy
[19:40] <Chipaca> sandGorgon: not an ISO. What are you wanting to play _on_?
[19:40] <tyhicks> Chipaca: yes - your gif is showing that root is required for privileged operations even though anyone can write to the socket - correct?
[19:40] <Chipaca> tyhicks: correct
[19:40] <tyhicks> got it
[19:41] <sergiusens> elopio, do you feel good about releaseing current master as 0.6?
[19:41] <Chipaca> tyhicks: didn't create the gif just for you, but thought it might be useful for you as well
[19:42] <Chipaca> sandGorgon: the snaps you can download from https://developer.ubuntu.com/en/snappy/start/ work in kvm, or you can dd them onto a sd card or usb stick and boot off of that
[19:42] <sandGorgon> Chipaca, this may sound stupid... but there were all these articles that mentioned that the next version of ubuntu will have a snappy-based flavor . so I was wondering if there were any builds of a desktop version with snappy.
[19:43] <Chipaca> sandGorgon: no, it does not sound stupid
[19:43] <tyhicks> Chipaca: it will be helpful - thanks!
[19:44] <Chipaca> sandGorgon: but things might have been lost in translation / repetition, as as far as I know there isn't a plan to have a snappy desktop version, but to be able to use snappy on the desktop, which is not quite the same
[19:45] <Chipaca> sandGorgon: i don't know how far along those plans are, though
[19:48] <sandGorgon> Chipaca, "Ubuntu 16.04 LTS will be able to run Snappy packages
[19:48] <sandGorgon> Will Cooke, the Ubuntu Desktop lead, announced during a Unity 7 discussion at the Ubuntu Online Summit that they are working to bring Snappy packages to the regular Ubuntu flavor, with Unity 7."
[19:48] <sandGorgon> I was wondering if I could start playing with it on the desktop... but maybe I'm jumping in too early. my bad... I can wait ;)
[19:49] <lotuspsychje> sandGorgon: install xenial development branch and apt-cache search snappy
[19:49] <lotuspsychje> and start fool around
[19:49] <Chipaca> sandGorgon: yes, snappy packages, but not a snappy system
[19:49] <sandGorgon> lotuspsychje, will do ;)
[19:55] <lotuspsychje> sandGorgon: ive also tested unity8 on xenial
[19:55] <lotuspsychje> sandGorgon: also early stage now, so it looks pretty much like the phone version
[19:55] <sandGorgon> lotuspsychje, oh.. is it usable ?
[19:56] <lotuspsychje> sandGorgon: yes, mouse support, browsing
[19:56] <sandGorgon> lotuspsychje, ah ok.. i'll survive probably (P.S. im more of a gnome guy)
[19:58] <lotuspsychje> sandGorgon: then test the ubuntu-gnome xenial development branch
[19:58] <sandGorgon> lotuspsychje, that's what's downloading right now
[20:09] <sergiusens> elopio, https://github.com/ubuntu-core/snapcraft/pull/127
[22:03] <jdstrand> sergiusens: catching up on irc backscroll from holiday
[22:03] <jdstrand> < sergiusens> Chipaca, 2015/11/24 08:43:59.067839 security.go:205: [sc-filtergen --include-policy-dir=/var/lib/snappy/seccomp --policy-vendor=ubuntu-core --policy-version=15.04 --template=network-status --policy-groups=networking] failed
[22:04] <jdstrand> sergiusens: you probably figured this out, but --template=network-status is wrong. the template is 'default' (ie, unspecified) and you should use caps: [ network-client, network-status ]
[22:07] <sergiusens> jdstrand, I haven't looked too much into it, it is just related to https://bugs.launchpad.net/snapcraft/+bug/1519251
[22:13] <jdstrand> sergiusens: based on the sc-filtergen denial, the package yaml is using 'security-template: network-status'. It shouldn't do that
[22:14] <jdstrand> s/denial/error/
[22:16] <jdstrand> Chipaca: fyi, I see in backscroll you pinged me about snapd and ACLs and that tyhicks responded. I will leave that topic to the two of you them
[22:19] <tyhicks> jdstrand: yes, I'm going to review the code
[22:19] <tyhicks> (card already created)
[22:20] <jdstrand> ogra_: re chown for services-- you mentioned massive problems. what are the problems? what are they chowning to? there is nothing they can legitimately chown to other than root, which is the user
[22:21] <jdstrand> ogra_: but to more simply answer your question-- it is a valid point that you need write access to the file to chown it. therefore, it makes some sense to allow these syscalls since apparmor blocks the file access
[22:22] <jdstrand> ogra_: however, we did not allow all of chown yet because we didn't understand the scope of issues at first and because, again, nothing valid to chown to
[22:24] <jdstrand> ogra_: couple that with seccomp arg filtering that we will hopefully have for 16.04. with that we'll say you can chown to 'root' for example (probably fixing your issue but in a different way), but disallow chown to 'nobody' or 'www-data'. if we decide to allow per-app user ids, we'd allow chown to that too
[22:25] <jdstrand> ogra_: but I didn't want to open the floodgates on that just yet, cause apps might hardcode things and do odd stuff, changing ownership to invalid things which might cause unexpected interactions
[22:26] <jdstrand> so proceeding with caution there. but as mentioned, the seccomp arg filtering alone will likely fix the obstacle you are facing
[22:26] <jdstrand> (with the accompanying policy updates)
[22:26] <jdstrand> tyhicks: thanks
[22:28] <ogra_> jdstrand, well, lighttpd and sqlite both only use fchown when they are run as root to chown files to the right UIDs ...
[22:28] <ogra_> and as it happens i'm just assembling something that uses both :)
[22:30] <jdstrand> ogra_: yeah, I talked about sqlite in snappy-app-devel-- I think we should probably patch it. lighthttpd is doing the exact same thing or chowning to some other user?
[22:30] <ogra_> ("to the right UIDs" typically to the UIDs defined in the config file)
[22:30] <jdstrand> what are you putting in that config file?
[22:31] <jdstrand> we don't have per-app user ids yet (see mailing list)
[22:31] <ogra_> well, i'm not really clear what lighttpd does, i cant find any trace of "chown" in the source
[22:32] <ogra_> i indeed dont put a user into that config file ... interesting fact is that lighttpd doesnt complain about fchown on amd64
[22:32] <jdstrand> ogra_: is this a xenial system?
[22:32] <ogra_> amd64 is 15.04 edge ... armhf is xenial edge
[22:33] <jdstrand> ogra_: on the xenial system, you can do the security-override method to unblock you while you investigate. eg:
[22:33] <jdstrand> services:
[22:33] <jdstrand>   - name: foo
[22:33] <jdstrand>     security-override:
[22:33] <ogra_> i use lighttpd's webdav module ... i guess that links in some sqlite stuff or so
[22:33] <jdstrand>       syscalls: [ fchown32, chown, ... ]
[22:33] <jdstrand> perhaps
[22:33] <jdstrand> and sqlite is doing the chown to root unconditionally to root
[22:33] <ogra_> yeah, i had that working at some point (and then threw everything away and started to patch the apps :P )
[22:34] <ogra_> right
[22:34] <ogra_> so it is just a pointless syscall
[22:34] <ogra_> but it is as pointless that we block it imho
[22:35] <jdstrand> well, I don't know about that
[22:35] <ogra_> given you cant chown anything outside of your confinement
[22:35] <jdstrand> I mentioned interactions
[22:37] <ogra_> jdstrand, btw, one thing that struck me ... how do we protect maintainers/developers from spp vulnerabilities ... i mean ... my https runs as root ... since i need to mangle the config it lives in $SNAP_APP_DATA_PATH ... where also my webroot needs to live ... if there is an issue with the webserver someone can just later my config remotely
[22:37] <ogra_> s/spp/app/
[22:37] <ogra_> s/later/alter/
[22:38] <ogra_> i was wondering if there is any way to protect us from such things
[22:39] <jdstrand> ogra_: snappy doesn't help with that. if there is a vulnerability in the app itself and it can scribble out to files, it could overwrite its configuaration, db files, etc. I mentioned this in my email on user ids-- this is one reason to support them
[22:40] <ogra_> oh, so you want to do some extrausers magic on a per-snap base ?
[22:40] <jdstrand> the easiest thing we can do which everyone already understands is allow for opt-in app ids
[22:40] <jdstrand> eg (and this is otoh, not designed or talked about beyond that thread and a couple of conversations):
[22:40] <jdstrand> services:
[22:40] <jdstrand> wait
[22:40] <jdstrand> name: foo
[22:40] <jdstrand> services:
[22:40] <jdstrand>   - name: bar
[22:41] <jdstrand>     app-user: true
[22:41] <jdstrand> then on install, that create the foo_bar user
[22:41] <jdstrand> creates
[22:41] <ogra_> hmm
[22:41] <jdstrand> that is a sort of 'system' user in that it is passwordless, etc
[22:41] <jdstrand> then the seccomp policy allows chowning to that user, etc
[22:42] <jdstrand> there are other ways to do that
[22:42] <jdstrand> but the basic idea is come up with something that namespaces the users to the package name
[22:42] <ogra_> i wonder if we couldnt teach libnss-extrausers to accept something like a passwd.d/ dir where snaps could drop their snippets
[22:42] <jdstrand> s/snaps/snappy install/ :)
[22:43] <ogra_> :)
[22:43] <jdstrand> app-user: true might be artificially limiting. perhaps a single service wants more than one app user. perhaps the users shouldn't be tied to the service at all, etc
[22:44] <jdstrand> anyway, those are the types of things to work out. I think there are some pretty good reasons for supporting them (see email thread) based on dev input
[22:44] <ogra_> right
[22:46] <jdstrand> maybe this is something we can discuss at the upcoming sprint if there is time
[22:47] <ogra_> the feb. one you mean ? yeah
[22:47] <jdstrand> no, the one I am going to next week :)
[22:47] <ogra_> ah
[22:47] <jdstrand> but sometime this cycle, sure
[23:06] <jdstrand> beuno, pindonga: hey, when is the next scheduled store rollout? I have a big merge to the review tools for all snaps that I'd rather get in sooner this week or wait until after next (and continue with manual reviews until then)
[23:06] <jdstrand> beuno, pindonga: basically, I don't want it hitting on the weekend or while I am sprinting in case I need to react quickly to something
[23:36] <ogra_> jdstrand, oh, btw ... if i put the above into my snapcraft.yaml i get
[23:36] <ogra_> Issues while validating snapcraft.yaml: 'apparmor' is a required property
[23:36] <ogra_> seems security-override wants an apparmor line too
[23:36] <jdstrand> ogra_: I think snapcraft needs to be updated for the new 16.04 yaml
[23:37] <jdstrand> sergiusens: I mentioned this elsewhere, but fyi ^
[23:37] <jdstrand> ogra_: oh, is that click review tools?
[23:37] <jdstrand> ogra_: yes, there is an MP about to land for that
[23:37] <ogra_> might be ... i get it on "snapcaft clean"
[23:37] <jdstrand> ogra_: can you paste the output?
[23:38] <ogra_> well, that was all output
[23:38] <ogra_> root@localhost:/upnp-server# snapcraft clean
[23:38] <ogra_> Issues while validating snapcraft.yaml: 'apparmor' is a required property
[23:38] <ogra_> root@localhost:/upnp-server#
[23:38] <jdstrand> sergiusens: fyi, not sure if snapcraft needs to be updated or not (just fyi)
[23:38] <jdstrand> that sounds like it does
[23:39] <ogra_> yeah
[23:40]  * ogra_ still doesnt get why lighttpd behaves different on armhf vs amd64 ... there is no fchown32 call on amd64 it seems
[23:40] <jdstrand> yeah, there will be different syscalls between those
[23:41] <ogra_> well, different, sure ... but having the call on one arch and not on the other ?
[23:41] <jdstrand> fchown and fchown32 are maybe what you need
[23:41] <jdstrand> yeah, that is common
[23:42] <jdstrand> or at least, not uncommon
[23:42] <ogra_> really ?
[23:42] <ogra_> wow
[23:42] <jdstrand> I didn't know that either til having to look at all these
[23:49] <ogra_> oh man
[23:49]  * ogra_ slaps forehead
[23:50] <ogra_> so i was seeing the syscall issue on armhf but not on amd64 ... because my snapcraft.yaml has a copy plugin that copies libsqlite to usr/lib/x86_64-linux-gnu ...
[23:50]  * ogra_ blushes


[12:25] <lamont__> lifeless: you around?
[12:28] <lifeless> no
[12:28] <lifeless> ovoid
[12:28] <lamont__> heh
[01:33] <jamesh> I stayed logged into Launchpad over night
[01:33] <jamesh> nice
[01:37] <kiko-zzz> the wonders of db-persistent sessions
[01:37] <kiko-zzz> tomorrow
[01:47] <lifeless> actually I think its shared sessions
[01:48] <lifeless> more than the persistence ;0
[01:51] <jamesh> in theory, you should remain logged in between production upgrades too ...
[02:09] <lifeless> jamesh: as long as session formats dont change
[02:46] <mpt> Gooooooooooooooood afternoon Launchpadders!
[02:48] <jamesh> hi mpt
[02:48] <jamesh> mpt: I got brad to test that javascript patch, and have committed it
[02:49] <mpt> ok, great
[02:57] <njs> a question: as a project maintainer, why should I use rosetta over one of the other centralized translation project thingies?
[02:57] <njs> (there seem to be a lot of these thingies, and little information to choose between them on)
[03:03] <mpt> njs, what other ones have you seen?
[03:04] <mpt> The only other one I know of is Irma, which has the problem that it's Linspire-only
[03:09] <njs> Pootle, the Translation Project, ...
[03:09] <njs> there is, of course, https://wiki.launchpad.canonical.com/RosettaCompetitors
[03:15] <lifeless> njs: because it rocks
[03:15] <lifeless> njs: because its not bound to one distro
[03:16] <lifeless> njs: and because it will be bzr integrated in the future
[03:16] <lifeless> making it non centralized
[03:18] <njs> bzr integration is somewhat less interesting to me than some things, for reasons you might be able to imagine :-)
[03:18] <njs> though I suppose it is nice for language teams to have such a thing!
[03:18] <njs> neither pootle nor the translation project are distro-associated
[03:19] <njs> though TP is clearly a less modern architecture
[03:43] <njs> mpt: :-)
[04:45] <mpt> jamesh, can I bother you some more about backslashreplace()?
[04:45] <jamesh> sure.
[04:45] <mpt> First I tried putting it in __init__.py, under smartquote()
[04:45] <mpt> and then in test.py itself
[04:46] <mpt> but either way I get NameError: name 'backslashreplace' is not defined
[04:46] <jamesh> if you put it in webapp/__init__.py, you'll need to do "from canonical.launchpad.webapp import backslashreplace" in the page test .txt file
[04:47] <jamesh> the alternative is to put the function definition in the page test file itself, where needed
[04:47] <jamesh> I'd suggest either putting the function in the page test, or canonical/launchpad/helpers.py
[04:47] <mpt> well, it'll be needed in multiple pagetests
[04:47] <mpt> so I'll use helpers.py
[04:58] <mpt> AttributeError: 'LaunchpadBrowserResponse' object has no attribute 'decode'
[04:59] <mpt> at least it's importing now :-)
[05:01] <mpt> jamesh, how do I turn a LaunchpadBrowserResponse into a str?
[05:02] <jamesh> mpt: str()?
[05:02] <mpt> ha, should have guessed
[05:03] <mpt> hmm, str() gives me a whole pile of "\n"s
[05:03] <mpt> but there's something else in helpers.py for that
[05:04] <jamesh> really?
[05:05] <mpt> at least, I thought there was
[05:05] <mpt> hmm, no there isn't
[05:05] <jamesh> the repr() of a string with newlines will show '\n'
[05:05] <jamesh> but if you use "print" to display it, they'll come up as newlines (as the page tests do at the moment)
[05:05] <mpt> I have >>> backslashreplace(str(http(r"""...
[05:06] <mpt> ah, now we're cooking with gas
[05:09] <jamesh> maybe it'd make sense to put the str() call inside backslashreplace()
[05:09] <mpt> yes, if I'm going to be doing that every time anyway
[05:09] <jamesh> yahoo accesses https://launchpad.net/robots.txt a lot
[05:10] <lifeless> yahoo are just about criminal in the bw use
[05:10] <mpt> "bw"?
[05:10] <jamesh> > 3000 times in the same period as google accessed the file ~ 200 times
[05:11] <jamesh> bw == bandwidth
[05:11] <lifeless> nope
[05:11] <lifeless> yahoo are just silly
[05:12] <lifeless> i have a unmodified for months robots and they did not reduce their hit rate last time I checked.
[05:13] <jamesh> googlebot is using two user-agents:
[05:13] <jamesh> "Googlebot/2.1 (+http://www.googlebot.com/bot.html)" and "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
[05:13] <lifeless> probably different dc's
[05:13] <mpt> http://help.yahoo.com/help/us/ysearch/slurp/slurp-03.html
[05:14] <mpt> hmm, that's not quite relevant
[05:14] <lifeless> indeed
[05:14] <mpt> http://help.yahoo.com/help/us/ysearch/slurp/slurp-06.html
[05:15] <jamesh> the google page says they access robots.txt at most once a day
[05:15] <jamesh> (usually)
[05:16] <mpt> so we could add stuff to robots.txt to tell Yahoo "there is nothing for sale here" and "there are no interesting images here"
[05:16] <lifeless> mpt: or we could blacklist them
[05:16] <jamesh> or maybe actually, that might be once per day per googlebot instance
[05:16] <lifeless> or give them a single page that says 'please use google.'
[05:17] <mpt> What is the number of visitors we get with yahoo.com referers, divided by the number of visitors we get from google.com referers?
[05:17] <jamesh> I'm not saying it is necessarily a problem; I was just surprised at the numbers
[06:29] <dilys> Merge to devel/launchpad: [trivial]  configs for production launchpad instance on gandwana (r2972: Stuart Bishop)
[06:32] <elmo> stub: we need to get the librarian onto mizuho at some point - I assume there's no further blockers for that?
[06:34] <stub> elmo: Nope. Whenever your ready really. We can take the librarian down and it will only minimally affect Launchpad.
[06:36] <elmo> stub: hmm, what timezone are you on?
[06:37] <elmo> stub: anyway, I don't suppose now is a good time, but I've setup mizuho as a mirror of macaroni, including your account etc. so if you could login in, check it out, see if anything is missing
[06:37] <stub> UTC+7 now
[06:38] <stub> Now if fine if you have the slot. I don't think the migration is urgent through if you have other things to look at or are just having a bad hair day.
[06:38] <elmo> crap your core hours are basically my sleeping hours - that's so unuseful
[06:39] <elmo> stub: nah, I really need to go to bed, and karl won't be up for another of couple of hours in case it all goes Pete Tong
[06:39] <lifeless> I can help
[06:39] <lifeless> my hours are before stubs
[06:39] <elmo> stub: and it's reasonably urgent, as macaroni is down to 20Gb :P
[06:39] <elmo> lifeless: yeah, I know I just mean in general
[06:40] <stub> I've split my core hours, with a big break in the middle, so I'm available on UK time.
[06:40] <elmo> StaffCalendar says 04:00-12:00 UTC?
[06:40] <elmo> if that's got a big break in a middle, someone's getting short changed ;-P
[06:41] <stub> Bah
[06:42] <elmo> anyway, gone, night
[06:42] <lifeless> night elmo
[06:44] <LetterRip> hello all
[06:44] <LetterRip> I have two questions related to translation and documentation
[06:45] <LetterRip> Blender has an out of tree translation for the Chinese language
[06:45] <LetterRip> and would like to know if the section on Chinese translation for Blender can be pointed to their site
[06:46] <LetterRip> The other question, is that we have a many hundered page manual that is online in wiki format
[06:46] <LetterRip> that has translations in various states of completion
[06:46] <LetterRip> for about 6 languages in addition to english
[06:47] <LetterRip> is there anyway to get that into the rosetta system as well?
[07:55] <mick_home> hi everyone
[07:55] <mick_home> there are a few things that I'd like to fix in launchpad (a few things annoy me)
[07:56] <mick_home> is it possible to get the source (via cvs/svn)?
[07:56] <mick_home> or is it closed source?
[07:57] <mpt> mick_home, it's not open source yet
[07:57] <mpt> though the plan is for it to be released over time
[07:57] <mpt> What things annoy you in particular?
[07:57] <mick_home> missing ical support
[07:57] <mick_home> a calendar does very little for me ;-)
[07:57] <mick_home> but ical support does a lot
[07:58] <mick_home> mpt: is there a particular reason why it isn't OSS right now?
[08:01] <mick_home> i'd also like to see how the bts is tied into it (and see if it is possible to replace it with bugzilla)
[08:02] <mick_home> a local install would also be nice to have
[08:03] <mpt> well, much of the benefit of Launchpad comes from people using a single instance
[08:03] <mick_home> well, yes
[08:04] <mick_home> but many people won't touch it if it isn't OSS
[08:04] <mpt> for example, the Big Idea of the bug tracker is to let multiple distributors, and upstream developers, collaborate on fixing the same bug
[08:04] <mpt> similarly, the advantage of Rosetta is that multiple distributors and upstreams can share each others' translations
[08:05] <njs> this seems like a logically inconsistent argument.  if there's such a benefit to having a single install, then people will continue to use that install, because they get benefits; even if the source code is open.
[08:05] <njs> but on the other hand, many people will _not_ use that central install on philosophical grounds, if the source code is not open.
[08:05] <mick_home> well gforge didn't kill sf.net - i doubt that releasing it as oss would harm launchpad in any way (it would only benefit)
[08:06] <mpt> njs, but then it would take *years* for the economies of scale to bring people into a single installation
[08:07] <mick_home> to be honest... i see only benefits
[08:07] <mpt> mick_home, what does sourceforge do to let distributors cooperate with each other?
[08:07] <mick_home> for instance, you have a huge amount of people that won't touch launchpad atm (the DDs for instance)
[08:08] <mick_home> mpt: i just compared opening up the sf.net code (gforge) and the success of sf.net in general
[08:08] <mpt> I understand that argument
[08:08] <mpt> (though I have less respect for it if such people also use Google:-)
[08:08] <mick_home> heh
[08:09] <jamesh> mick_home: you can get an ICalendar export at webcal://launchpad.net/people/username/+calendar/+icalendar
[08:09] <jamesh> (replace "webcal" with http or https, if you want)
[08:10] <njs> one lesson I have learned as a maintainer is that whether I respect my users or not they still are important :-)
[08:10] <mpt> mick_home: but the management have made the decision that the benefit from forcing the economies of scale early on is greater than the harm from however many developers won't use it for as long as it's closed
[08:10] <mpt> and I think they're probably right
[08:10] <mick_home> blog would also be nice
[08:10] <mick_home> since homepage != blog
[08:11] <mpt> mick_home, you mean a Weblog field for a registered person?
[08:11] <mick_home> blog link
[08:11] <mick_home> blogging possibilities (via launchpad)
[08:11] <mpt> yes
[08:11] <mpt> we've just been considering that in the past week
[08:11] <mick_home> and the possibility to parse an rss feed of a blog
[08:11] <mpt> https://wiki.launchpad.canonical.com/BlogIntegration
[08:11] <jamesh> mick_home: allowing people to give a link to their web log / syndication feed is being considered
[08:12] <jamesh> mick_home: to make it easy to generate a planet config from a LP team, for instance
[08:12] <mpt> so that Launchpad can Planetize teams
[08:12] <mpt> snap ;-)
[08:12] <mick_home> well, i'm just adding stuff that i'd be interested in (using and developing)
[08:14] <mick_home> mpt - would you mind shooting me an email if it ever does go open source
[08:17] <mick_home> mpt: are you a dev of launchpad?
[08:17] <mpt> mick_home, I am a developer
[08:18] <mpt> the plan as far as I know is to open source it parts at a time
[08:18] <mpt> Are you interested in particular parts, or just the whole shebang? :-)
[08:18] <mick_home> well, i can't test in parts now can i ;-)
[08:20] <mpt> mick_home, if you just want to play around with various features, you can use https://staging.ubuntu.com/
[08:20] <mpt> (which really should be staging.launchpad.net, but anyway)
[08:21] <mick_home> i'm interested in coding features (not testing new features)
[08:22] <mpt> ah
[08:22] <jamesh> mpt: staging.launchpad.net does go to the same server as staging.ubuntu.com, but seems to show the shipit interface
[08:22] <mpt> jamesh, yes, there's something in my Inbox about rationalizing the various domains
[08:23] <mpt> actually, for me it redirects
[08:23] <mpt> mick_home, have you done much with Zope before?
[08:23] <ajmitch> mpt: will there be many differences from production? or is staging what is made production each week?
[08:23] <mpt> ajmitch, the latter
[08:23] <ajmitch> zope 3 is fun, really ;)
[08:24] <mick_home> python yes... zope no
[08:24] <mpt> so it's somewhat newer than production about 5/7 of the time
[08:24] <ajmitch> ok
[08:24] <mick_home> mpt: like i said, mind sending me an email when/if the source ever becomes available?
[08:26] <mick_home> i understand if you say "no" btw (since I'm probably not the first person to ask)
[08:26] <jamesh> mick_home: when things are released, we won't keep it a secret
[08:26] <jamesh> you can be sure of that
[08:27] <mpt> mick_home, you're not the first person to ask for the source, but you're the first to ask for e-mail notificaiton :-)
[08:27] <mick_home> well ya i get that
[08:27] <mpt> I'd probably forget
[08:27] <mick_home> but i don't check the site 24/7 ;-)
[08:27] <mpt> mick_home, do you read Slashdot?
[08:27] <ajmitch> mpt: have parts been freed already?
[08:27] <mick_home> mpt: oh god no... i used to
[08:28] <mick_home> it will probably make it on /. though
[08:28] <mick_home> mpt: my experience is with python/wxPython apps
[08:28] <mpt> yes, that's why I asked
[08:28] <mick_home> not really python web apps
[08:28] <mpt> mick_home, ok, e-mail<EMAIL_ADDRESS>and I'll reply when it's all open-sourced :-)
[08:29] <mick_home> thanks :-)
[08:29] <mpt> ajmitch, not as far as I know
[08:29] <jamesh> ajmitch: no Launchpad specific bits -- we have fed back improvements to open source projects we make use of though
[08:29] <jamesh> e.g. psycopg, pyme, etc
[08:30] <ajmitch> jamesh: yes, I've seen that, which is great
[08:31] <mick_home> mpt: thanks (email sent)
[08:41] <carlos> morning
[08:41] <carlos> stub, hi
[08:41] <carlos> stub, when are you going to do the production update?
[08:46] <jamesh> carlos: yesterday
[08:46] <carlos> oh, fuck
[08:46] <carlos> hmm, I need a cherrypick then
[09:01] <carlos> daf, ping
[09:30] <mick_home> hi guys (i'm back)
[09:31] <mick_home> i am curious to know if launchpad supports only gettext or other means
[09:31] <mick_home> like RC files
[09:35] <carlos> mick_home, only gettext
[09:35] <carlos> mick_home, but there are many tools that gives you a .po file from many other resources to translate
[09:35] <mick_home> so i would convert from RC -> .po then have that go from .po -> RC ?
[09:36] <carlos> right
[09:36] <mick_home> carlos: have a link?
[09:41] <carlos> mick_home, is the RC file like 'key=value' content?
[09:43] <mick_home> standard Windows .rc
[09:45] <carlos> mick_home, sorry, I don't remember the details of that format... could you show me an example, please?
[09:53] <mick_home> nm i found what i'm looking for
[09:54] <mick_home> carlos: http://icu.sourceforge.net/userguide/localizing.html#Sample_rc
[09:54] <mick_home> if you want to see a real example, check out the ReactOS bugzilla setup
[09:55] <mick_home> all the localizations are .rc files
[09:55] <carlos> hmmm
[09:56] <carlos> I'm not sure how to get that into a .po file...
[09:56] <carlos> It looks like openoffice's files
[09:56] <mick_home> i'll be back once launchpad goes open source... there are too many features missing atm that i obviously can't impliment w/o the source
[09:56] <carlos> mick_home, but you can request us to implement them and we can try to do it...
[09:57] <mick_home> yes, but I don't like asking when I can do it myself at a later date ;-)
[09:57] <mick_home> my list of wants:
[09:57] <mick_home> - blog integration
[09:57] <mick_home> - ical support
[09:58] <mick_home> - rss parsing of blogs
[09:58] <mick_home> - rss /rdf support in general
[09:58] <mick_home> - support for other formats than gettext
[09:59] <mick_home> - IM clients should be listed (not irc / jabber specific imo)
[09:59] <daf> carlos: pong
[10:00] <carlos> mick_home, most of those features are planned or being discussed atm
[10:01] <carlos> daf, I'm with #1681. Could you confirm that the final decission to fix it was to allow '\r\n' stored into our database if the msgid had them?
[10:01] <carlos> mick_home, if you file bugs about them I'm sure that the ones that are not planned would be implemented
[10:02] <carlos> Ubugtu, you are sleeping....
[10:03] <daf> carlos: I can't remember off the top of my head
[10:03] <carlos> daf, ok
[10:04] <carlos> I think that was the last thing we talked but I'm not sure if with the triage you are doing with SteveA you decided something else
[10:04] <daf> if we decided something else, we would have said so in the bug :)
[10:04] <daf> I'll look at the LP mail
[10:05] <sivang> morning all!
[10:07] <carlos> sivang, morning!!
[10:08] <sivang> carlos: morning carlos, good to be back.
[10:08] <carlos> sivang, Welcome back then
[10:08] <carlos> I hope you are at 100% ;-)
[10:09] <sivang> carlos: yes, back to myself , thanks you.
[10:09] <daf> hi Sivan
[10:09] <daf> glad you're better
[10:09] <daf> carlos: hmm, have we ever seen a msgid with '\r' in it
[10:09] <daf> carlos: I'm wondering whether this is a YAGNI
[10:10] <sivang> daf: thanks :-)
[10:11] <carlos> launchpad_staging=> SELECT count(*) from pomsgid where msgid like '%\r%';
[10:11] <carlos>  count
[10:11] <carlos> -------
[10:11] <carlos>     39
[10:11] <carlos> (1 row)
[10:11] <daf> ok
[10:12] <daf> my next question is: which templates do these belong to?
[10:12] <carlos> daf, I suppose they will be related to Mono applications
[10:12] <carlos> let me check
[10:13] <daf> it kind of sucks to expose translators to \r
[10:13] <daf> you can always convert from logical to physical newlines in the code
[10:13] <carlos> daf, any developer that uses Windows to write the application is adding this "problem"
[10:14] <daf> 39 / X million is not much
[10:14] <daf> obviously it's > 0
[10:15] <daf> just to check:
[10:15] <daf> you plan is to strip newlines from translations unless the msgid contains \r?
[10:16] <carlos> 14 templates have the \r
[10:16] <daf> ok
[10:16] <daf> maybe nopaste the PTNs?
[10:16] <carlos> daf, if the msgid only has '\n', we strip the translation
[10:17] <carlos> if it has \r\n, we leave it (or fix it if is missing them)
[10:17] <daf> or if it has no '\n' :)
[10:17] <carlos> I need to check if we have just '\r'
[10:17] <daf> good idea
[10:17] <carlos> but that's from the old MacOS <= 9 systems...
[10:17] <daf> or if somebody is doing something weird
[10:18] <daf> APT uses \r to do progress bars
[10:18] <daf> but I don't think it exposes that to translators
[10:18] <njs> exposing that to translators seems like an unambiguous bug :-)
[10:19] <carlos> One of the templates with \r chars belongs to "The Ubuntu package descriptions for the releases." product...
[10:19] <daf> njs: to sensible people like you and me, sure :)
[10:20] <daf> carlos: see, I think that should be fixed
[10:20] <carlos>     name
[10:20] <carlos> -------------
[10:20] <carlos>  blender
[10:20] <carlos>  gnue-forms
[10:20] <carlos>  hercules
[10:20] <carlos>  kvirc
[10:20] <carlos>  libchipcard
[10:20] <carlos>  ncpfs
[10:20] <carlos>  shadow
[10:20] <carlos>  simplecdrx
[10:20] <carlos>  slrn
[10:21] <carlos>  somaplayer
[10:21] <carlos>  zssh
[10:21] <carlos> (11 rows)
[10:21] <carlos> that's the list of the other sourcepackages that use the \r char
[10:21] <daf> hmm
[10:21] <carlos> daf, so we can fix it on import/submit time without asking the user to pay attention to it
[10:21] <carlos> but only when the '\r' is used as '\r\n'
[10:22] <daf> I'm not sure I understand what you mean
[10:22] <daf> by changing the msgids?
[10:22] <carlos> if \r is alone... as you suggests with apt.. that would be a bit more difficult to fix
[10:22] <carlos> daf, no, the translations
[10:22] <daf> right
[10:22] <daf> changing the msgids would be dodgy
[10:22] <carlos> daf, changing msgids is broken ;-)
[10:22] <daf> yes
[10:23] <daf> so, I say we go with your plan
[10:23] <daf> but it would be nice to generate a warning if somebody imports a template with '\r'
[10:23] <carlos> It makes no sense to add a visual way to represent the \r
[10:23] <carlos> ok
[10:23] <daf> how difficult do you think that would be?
[10:23] <daf> we can use lpnotification for web uploads
[10:23] <carlos> not really....
[10:24] <daf> no?
[10:24] <carlos> the web upload is not doing the import
[10:24] <carlos> so we cannot know that at that point
[10:24] <daf> sure, it's not doing the import
[10:24] <carlos> daf, but we need to add notification mails when the .pot file is imported
[10:24] <carlos> so we can add there the warning
[10:24] <daf> but I think parsing the PO file should be quick enough that it's not a problem to check there
[10:25] <daf> ah, good point
[10:25] <daf> is there a bug open on that?
[10:26] <carlos> daf, About if it's difficult or not... I need to finish POMsgSetPage implementation first or I will get a ton of conflicts, but is not too complicate the fix of that bug
[10:26] <carlos> for .pot notifications?
[10:26] <daf> yep
[10:26] <carlos> I don't think so
[10:26] <carlos> at least I don't remember it
[10:26] <daf> ok
[10:26] <daf> I propose:
[10:26] <daf> do the fix you suggested
[10:26] <daf> file a bug on notificatoins for POT imports
[10:26] <jamesh> mick_home: you can use gettext's msgfmt utility to generate a .Net resource file.  That might be similar to a Windows resource file
[10:26] <daf> mention that we should warn about \r
[10:27] <daf> did I miss anything out?
[10:27] <carlos> ok, sounds like a plan
[10:27] <daf> good :)
[10:27] <carlos> daf, thanks for your input
[10:27] <daf> you're welcome
[10:27] <carlos> later
[10:27] <daf> carlos: oh, maybe say in #1681 what the plan we agreed is
[10:37] <mick_home> jamesh: ty
[10:37] <mick_home> .resx file?
[10:38] <jamesh> mick_home: no idea
[10:38] <SteveA> hi folks
[10:38] <Kinnison> hi steve
[10:38] <jamesh> mick_home: I'm just looking at the "msgfmt --help" output
[10:38] <SteveA> i'm getting ready to catch a plane to london
[10:38] <SteveA> is there anything urgent that i should do here?
[10:38] <lifeless> test
[10:38] <jamesh> mick_home: the xgettext utility also says it supports pulling strings from C# code
[10:38] <SteveA> i don't think i need to do any testing right now, lifeless
[10:39] <lifeless> SteveA: test that you have everything needed for the sprint
[10:39] <mick_home> jamesh: i saw mixed docs on that
[10:40] <jamesh> mick_home: anyway, it would probably be worth testing.
[10:40] <SteveA> lifeless: you mean, construct a miniature stub sprint, and briefly attend that?
[10:41] <lifeless> SteveA: no, just mock it up and walk through the responses
[10:43] <daf> SteveA: have a good flight
[10:45] <Nafallo> lol
[10:46] <daf> Honey, I Shrunk the DBA
[10:47] <Kinnison> jamesh: he'd probably cope so long as you didn't inject him into elmo's arse or anything
[10:49] <sivang> Kinnison: hi daniel! 'sup?
[10:51] <Kinnison> hi sivang
[10:51] <Kinnison> I heard you were ill
[10:51] <sivang> Kinnison: yep, I'm better now
[10:52] <Kinnison> sivang: excellent.
[10:52] <sivang> Nafallo: re-energated for sure :)
[10:52] <sivang> Kinnison: Have you had any chance to practice some herbew during the holidays?
[10:53] <Kinnison> sivang: when I was unwell, I lay in bed reading the book
[10:53] <Kinnison> sivang: I still don't recognise all the letters :-(
[10:53] <Nafallo> everyone has been ill except me? :-P
[10:53] <Kinnison> Nafallo: possibly :-)
[10:54] <sivang> Kinnison: ill again? during holiday time? bad :-/
[10:54] <Kinnison> sivang: aye, just my luck
[10:54] <Nafallo> I broke my damn toe instead though :-/
[11:36] <daf> lifeless: any chance of getting PQM's duplicate newline bug fixed -- it's bloody annoying
[11:37] <Kinnison> daf: I gave lifeless a patch for that almost a year ago
[11:37] <lifeless> daf: patches gratefully accepted
[11:37] <lifeless> Kinnison: I have no idea where that is
[11:37] <jamesh> just put up a branch to include logs of executed statements in OOPS reports
[11:37] <Kinnison> lifeless: you suck
[11:37] <lifeless> Kinnison: yes I do, for the right person
[11:37] <Kinnison> lifeless: baddumtish
[11:37] <jamesh> lifeless: where is pqm's bzr branch?
[11:37] <lifeless> daf: http://people.ubuntu.com/~robertc/pqm/trunk
[11:37] <lifeless> jamesh: ^^
[11:37] <lifeless> TDD is mandatory for patches
[11:38] <daf> jamesh: re OOPSes: that's great
[11:39] <jamesh> we'll also be able to start generating OOPS reports for requests that take a while, but don't hit the hard timeout
[11:39] <daf> that's also great :)
[11:40] <matsubara> good morning!
[11:40] <daf> good morning Brasil!
[11:40] <sivang> morning matsubara !
[12:01] <jamesh> lifeless: are items in the "output" list of CommandRunner objects meant to be newline-terminated or not?
[12:01] <jamesh> (in pqm)
[12:07] <lifeless> I think the problem is its never been defined properly
[12:08] <lifeless> so it needs a mini audit for how its used, and then the best choice taken - not hard
[12:08] <lifeless> I would be inclined to say 'yes' because thats how python 'for line in file' works - so its predictable to people
[12:10] <carlos> stub, hi, around?
[12:24] <daf> lifeless: bug 2263 -- can you take a look?
[12:24] <Ubugtu> Malone bug 2263: "cscvs tests fail and leave cruft behind" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: David Allouche, Status: Unconfirmed http://launchpad.net/bugs/2263
[12:24] <cprov> morning guys
[12:24] <daf> hi cprov
[12:24] <cprov> daf: hi daf
[12:25] <lifeless> daf - take a look at what precisely ?
[12:27] <daf> lifeless: do you know if it's still a problem?
[12:27] <daf> lifeless: if so, I'll mark it confirmed
[12:28] <daf> maybe I should be poking ddaa instead
[12:28] <ddaa> mh?
[12:28] <daf> the bug is assinged to you
[12:29] <ddaa> oh, right, I'm the guy most often poking around this code base
[12:29] <ddaa> I have not in months
[12:29] <ddaa> Anyway, the whole test dir handling of cscvs is brain damaged
[12:30] <LarstiQ> ddaa: branch scanning, very cool
[12:31] <ddaa> daf: I'll confirm along the lines of "yes, cscvs tests temp dir handling is brain damaged, will fix when I come around to".
[12:31] <daf> ddaa: thanks, that's what I wanted :)
[12:31] <ddaa> low priority
[12:35] <ddaa> LarstiQ: thank you, but I'm just the messenger, neumeyer, jblack and sabdfl have all made very significant direct contributions.
[12:37] <daf> cprov: where's kiko today?
[12:38] <cprov> daf: coming, I hope ;)
[12:38] <LarstiQ> ddaa: you may message my appreciation back to them ;)
[12:38] <daf> cprov: ah, just being slow, yes?
[12:39] <cprov> daf: certainly
[12:40] <ddaa> daf: bug 6563 is needinfo, why?
[12:40] <Ubugtu> Malone bug 6563: "No easy way to go to branch listings from a branch page" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: Needs Info http://launchpad.net/bugs/6563
[12:41] <daf> ddaa: because I wanted a response to my comment from you
[12:42] <daf> perhaps I should have made that clearer
[12:42] <ddaa> Uh... well, I reply something...
[12:43] <ddaa> daf: I know nothing about breadcrumbs.
[12:43] <daf> to put it another way:
[12:43] <daf> I'm trying to find concrete things we can do to resolve the problems you have perceived
[12:44] <daf> breadcumbs are the list of links on the top left hand of the page
[12:44] <ddaa> Mh... I made a suggestion, but it was not very clear.
[12:44] <ddaa> Certainly a good thing, at least for consistency...
[12:44] <ddaa> Oh yes, I know what they are, but I do not know how to use them, in terms of UI design and in terms of coding.
[12:45] <daf> that's fine, I'm not expecting you to :)
[12:45] <daf> just because you filed the bug doesn't mean you should fix it
[12:52] <ddaa> daf is there a bug filed about transferring ownership of launchpad objects?
[12:54] <ddaa> daf: bug 6563 updated, like it better?
[12:54] <Ubugtu> Malone bug 6563: "No easy way to go to branch listings from a branch page" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: Needs Info http://launchpad.net/bugs/6563
[12:54] <daf> ddaa: hmm, not sure
[12:54] <ddaa> Mh... anyway, that would deserve a spec methink...
[12:54] <ddaa> I have some ideas about how that should be done.
[12:55] <daf> but yes, thanks for the clarification
[12:55] <daf> "not sure" was in reference to ownership transfer
[12:55] <ddaa> got it
[01:02] <ddaa> lifeless: what about closing all the baz bugs in launchpad with "wontfix"?
[01:02] <daf> jamesh: perhaps your OOPS analysis script could tell us what proportion of OOPSes are triggered by Launchpad developers ;)
[01:04] <ddaa> what about a launchpad skin (or port or something) where oopses are ignored by the statistics? So debugging does not skew them.
[01:04] <ddaa> Mh... isn't what staging is for... okay...
[01:04] <lifeless> ddaa: wontfix does not mean 'no resources' it means 'no matter what this wont be fixed'
[01:04] <ddaa> lifeless: hello, hello, reality? reality?
[01:04] <lifeless> ddaa: i.e. its a variation on notabug.
[01:05] <ddaa> No matter what, there is not development comunity for baz anymore.
[01:05] <ddaa> tla, okay, baz, no.
[01:06] <jamesh> lifeless: which config-manager branch is needed by pqm?
[01:06] <lifeless> jamesh: devel
[01:06] <jamesh> where is that?
[01:06] <jamesh> I could only find references to bazaar 1.x branches
[01:06] <lifeless> debian/ubuntu or http://www.robertcollins.net/config-manager/trunk
[01:07] <ddaa> should I forward that to sabdfl?
[01:07] <jamesh> thanks
[01:08] <jamesh> I looked at http://www.robertcollins.net/config-manager.html and on http://people.ubuntu.com/~robertc/, and didn't see it
[01:08] <SteveA> kiko phoned.  he's going to be in a little late today.
[01:14] <ddaa> SteveA: random UI idea, what about making the current facet more persistent. For example, when in bugs, and clicking on my name in the top right, to right to $me/+assignedbugs. Or when in branches, and clicking on a product link, go right to $product/+branches.
[01:14] <ddaa> If you think that sounds halfway sane, I'll file a bug.
[01:17] <stub> carlos: pong
[01:17] <carlos> stub, did you see my merge request into production?
[01:18] <SteveA> ddaa: yes, that is a good idea.  actually, it's been discussed before, looking at the number of clicks people typically make.  you can file a bug on interactions that you have wanted yourself.
[01:21] <daf> stub: can you tell me the name of the person with ID 414153?
[01:21] <stub> carlos: Got it
[01:23] <stub> daf:  plug-min | Philippine Linux Users' Group-Mindanao
[01:23] <daf> aha
[01:24] <daf> somebody managed to request a password for a team
[01:25] <carlos> stub, would be possible to have it merged today? or at least anytime soon?
[01:26] <stub> carlos: I rolled out 2966, so 2961 and 2966 are already out there
[01:27] <stub> carlos: I'll have a look at 2971
[01:27] <stub> Anyone feel like telling me how to cherry pick with bzr ?
[01:28] <daf> bzr merge -r X..Y, I suspect
[01:28] <daf> (bzr merge --help)
[01:31] <kiko> hey there
[01:31] <daf> kiko!
[01:31] <daf> now, what was I going to harass you about?
[01:32] <kiko> well, my friend's mother had a stroke so I will be out at the hospital up till 16:00 utc; you'll have plenty of time to remember
[01:32] <daf> oh no
[01:33] <ddaa> daf: me think bug 2110 needs an assignee...
[01:34] <daf> well, it can certainly be confirmed
[01:34] <ddaa> I cannot, I'm the reporter :)
[01:34] <daf> done
[01:34] <daf> as for assignee, I don't know who it would be
[01:35] <ddaa> kiko: !
[01:35] <ddaa> I would like someone to be responsible for bug 2110.
[01:35] <kiko> hey ddaa
[01:35] <kiko> what is that bug
[01:35] <ddaa> Ubugtu: hello?
[01:36] <ddaa> it's "Autogenerated forms do not have correct tab order"
[01:36] <kiko> okay
[01:36] <kiko> that's currently mpt + bjornt on a spec that has the word "form" in it
[01:36] <sivang> ddaa: Ubugtu is probably away :)
[01:36] <kiko> there's even an implementation plan
[01:36] <kiko> so either mpt or bjornt
[01:36] <carlos> stub, oh, cool
[01:36] <carlos> stub, thanks
[01:37] <daf> kiko: where's this spec?
[01:37] <ddaa> it's linked from the bug...
[01:37] <kiko> daf, where are all our specs?
[01:37] <ddaa> why do we have all those nifty cross-referencing features if NOBODY CARES?
[01:37] <kiko> heh
[01:38] <daf> ddaa: I can't see it
[01:39] <daf> oh, ther
[01:39] <daf> e
[01:39] <ddaa> daf: then please file an usability bug :)
[01:39] <kiko> https://wiki.launchpad.canonical.com/FormLayout
[01:39] <daf> we have plenty of bugs about portlets being invisible
[01:39] <kiko> boomboomboom
[01:40] <daf> *cough*
[01:40] <kiko> doh doh doh
[01:41] <daf> I did that too :)
[01:41] <kiko> I should be put on the rack
[01:41] <daf> ok, this spec has code and UI changes
[01:41] <daf> I suspect the tabindex thing will be a code change
[01:41] <kiko> right
[01:42] <daf> so if it's going to be assigned to anybody, it would be Bjrn
[01:42] <kiko> it needs to be done a bit smartly
[01:42] <daf> but I don't think assigning for the sake of assigning is worth it
[01:42] <kiko> well
[01:42] <kiko> agreed.
[01:42] <daf> getting a milestone on it would have more impact
[01:43] <daf> which I think is up to kiko or Steve
[01:44] <hno73> Hi.  The general ubuntu FAQ including ShipIt info has now moved to http://www.ubuntu.com/support/faq so it would be good to update the link on https://shipit.ubuntu.com/
[01:44] <hno73> I've filed a malone bug here: https://launchpad.net/products/shipit/+bug/6605
[01:44] <Ubugtu> Malone bug 6605: "ShipIt FAQ link" Fix req. for: shipit (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/6605
[01:44] <kiko> thanks hno73
[01:47] <daf> Kinnison: when are you bringing me cake^W^W^Wcoming over to work?
[01:48] <Kinnison> daf: thursday?
[01:49] <daf> sounds good
[01:49] <Kinnison> hmm, actually 'tis lunchtime now
[01:59] <Seveas> launchpad is OOPSing out whenever I want to edit a team member...
[01:59] <Seveas> it actually did edit, but redirects to /+member/$name/+members instead of /+members
[02:01] <daf> Seveas: this is a known bug
[02:01] <daf> Seveas: I'm working on a fix
[02:01] <daf> Seveas: bug 6372
[02:01] <Ubugtu> Malone bug 6372: "approving members broken" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Dafydd Harries, Status: In Progress http://launchpad.net/bugs/6372
[02:03] <daf> cprov: bug 5765
[02:03] <Ubugtu> Malone bug 5765: "Absence of fmt:datetime for code generated datetime.datetime instances" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/5765
[02:03] <daf> cprov: got a doctes for it?
[02:04] <cprov> daf: not yet, it happens in the new +builds pages (when now is returned from the view class)
[02:04] <Seveas> daf, I guess you know, but it's also broken for rejecting ;)
[02:05] <ddaa> bug 6607
[02:05] <Ubugtu> Malone bug 6607: "More persistent facets" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/6607
[02:05] <ddaa> daf: SteveA said it was a good idea and was discussed before
[02:06] <ddaa> ooooh, scheduled maintenance notice!
[02:06] <ddaa> should probably be much louder
[02:06] <sivang> does anyone know if bzr support 'publishing' as in , bzr publish sivan@host.tld:~/.../public_html
[02:06] <sivang> even if there wasn't any branch there before?
[02:07] <ddaa> link blinking red or something
[02:07] <daf> bzr push is what you want, I think
[02:07] <ddaa> sivang: yup, bzr push
[02:08] <sivang> sivan@ubuntu:~/devel/pkg/db2/db2-dependencies/db2-dependencies-1.0$ bzr push sivan@mercury.linuxguru.net:~/public_html/
[02:08] <sivang> bzr: ERROR: Remote location is not a bzr branch (or empty directory)
[02:08] <lifeless> blink is a ticket to hell
[02:08] <ddaa> lifeless: I was not _really_ serious
[02:08] <lifeless> ddaa: neither was I
[02:08] <ddaa> sivang: error reporting sucks, give hell to folks in #bzr
[02:08] <sivang> hehe
[02:08] <lifeless> if I was serious it would have been zandrus seventh hell
[02:09] <daf> the road the hell is paved with bad HTML
[02:09] <lifeless> ddaa: dude thats exactly correct - that dir is neither a bzr branch nor a empty fdir
[02:09] <ddaa> try "bzr push sftp://sivan@mercury.linuxguru.net:/home/sivan/public_html"
[02:09] <lifeless> sivang: put the path you want it published at on the end.
[02:09] <lifeless> i.e. db2-dependencies
[02:09] <ddaa> lifeless: everytime I mistype a url for push I get this obnoxious error
[02:10] <lifeless> propose a better one then
[02:10] <daf> it should say "perhaps put the name of the branch on the end of the path"
[02:10] <lifeless> btw
[02:10] <daf> perhaps?
[02:10] <lifeless> you said you found some bad-O stuff
[02:10] <sivang> lifeless: ah, oops I'll try that
[02:10] <ddaa> This should be something like "directory does not exist: $dirname [on host $hostname] ", where the bit in bracket in the host part of the URL if applicable.
[02:10] <lifeless> can you please push the branch with that in it somewhere so we can pull it ?
[02:11] <ddaa> Alternatively, "directory is not a bzr branch: blah blah"
[02:11] <sivang> daf: yes, after checking that you've forgotten to specify the target location
[02:11] <ddaa> Alternatively, "this branch has a diverged history, blah blah. If you really mean it, use --overwrite".
[02:11] <sivang> lifeless: yay, it works
[02:12] <lifeless> ddaa: you get those warnings separately
[02:12] <lifeless> ddaa: already
[02:12] <daf> perhaps if the remote directory exists, it should push to remote path + branch tag
[02:12] <lifeless> daf: uhm, hell no
[02:12] <ddaa> well, that's not the experience I had... but nevermind.
[02:12] <lifeless> ddaa: anyway #bzr, or<EMAIL_ADDRESS>or file a bug.
[02:12] <daf> (exists and is not a branch)
[02:12] <sivang> my thyinking was that it could take the topest level dir for the source branch and create the same one at the target
[02:13] <lifeless> ddaa: and -please- give me your performance tuned branch
[02:13] <lifeless> sivang: thats what will probably be supported in repositories but for standalone branches its a minefield of 'whoops' waiting to happen
[02:13] <ddaa> Okay, I'll look at it right now, but It got mostly supersed by other patches, mostly from geofreddo
[02:13] <stub> carlos: cherry picked
[02:13] <lifeless> ddaa: you had a workingtree iterator fix of some sort
[02:13] <lifeless> thats definately not superceded
[02:13] <ddaa> ha... right
[02:14] <ddaa> -> #bzr
[02:17] <sivang> lifeless: what do you mean in 'supported repositories' ?
[02:18] <daf> bzr is going to support code repositories
[02:18] <daf> rather than just individual branches
[02:20] <sivang> daf: ah cool
[02:25] <stub> carlos: poimport is still dying - a missing AND at the end of a query
[02:30] <daf> ENOTEST?
[02:41] <uws> Is the LP web site down atM?
[02:44] <daf> yes, it is down for maintenance
[02:44] <daf> we expect it to be back again shortly
[02:44] <uws> daf: Any clue on how long it will take?
[02:45] <daf> no, I'm afraid not
[02:46] <daf> I think it has taken longer than it usually has
[02:52] <bradb> jamesh: Hi. Any news on the status notes as comment review?
[03:11] <uws> yay, it's back online
[03:13] <stub> carlos: I've disabled poimport for the time being as it isn't doing much besides spamming us
[04:04] <Kinnison> Does Ubugtu get bugs from all products or only some?
[04:04] <Kinnison> daf: Are you doing triage/confirmation? If so, bug#6611 should be easy for you to confirm
[04:09] <LarstiQ> Kinnison: all afaik
[04:09] <LarstiQ> it knows about bug 1 and about bug 3281
[04:50] <daf> Kinnison: wow, what a weird bug
[04:50] <Kinnison> it looks like it is using the binarypackagename to look up in the sourcepackagename table or something
[04:51] <Kinnison> Hmm, perhaps not
[04:51] <Kinnison> https://launchpad.net/distros/ubuntu/hoary/amd64/libdisplaymigration0/0.28-3
[04:52] <Kinnison> that shows the -dev package
[04:52] <Kinnison> but the source package is without the 0 on the end
[04:52] <Kinnison> so there goes my theory
[04:52] <daf> it's not a gina fubar, is it?
[04:53] <Kinnison> I don't see how it could be
[04:53] <Kinnison> given on one hand we're using a binarypackagename of lua50 and on the other hand it's displaying one of lua50-doc
[04:53] <Kinnison> it's a code bug somewhere
[04:53] <daf> off-by-one error?
[04:53] <Kinnison> in what? it'll be a selectery error somewhere
[04:53] <Kinnison> probably in the magic binary package stuff
[04:53] <daf> mmm
[04:53] <Kinnison> umm distroreleasebinarypackagerelease
[04:54] <daf> not distroarchreleasebinarypackagerelease?
[04:55] <Kinnison> oops yes
[04:55] <Kinnison> darbpr
[04:57] <daf> hmm -- is salgado still on holiday?
[04:59] <matsubara> Kinnison: isnt't bug 6611 a dupe of bug 3516?
[04:59] <matsubara> daf: yes, he is.
[04:59] <daf> ok, thanks
[04:59] <daf> back next week?
[04:59] <matsubara> daf: I think he'll be back on 16th
[04:59] <daf> great
[05:00] <Kinnison> matsubara: It may be the same issue manifesting itself
[05:00] <Kinnison> matsubara: or it may not
[05:01] <daf> the symptoms look identical
[05:02] <daf> I'll dup them for now
[05:04] <Kinnison> okay
[05:04] <Kinnison> Can you make sure that whichever is left usable is filed against soyuz please?
[05:04] <Kinnison> All soyuz UI bugs should be against the soyuz product
[05:04] <Kinnison> otherwise I don't spot things when filing bugs
[05:04] <daf> ok
[05:04] <daf> I've been a bit lax about reassigning to soyuz
[05:04] <daf> I'll try and do so more
[05:04] <Kinnison> thanks
[05:05] <Kinnison> I find it hard to keep track when bugs aren't grouped
[05:05] <daf> I sympathise
[05:06] <daf> besides, reassigning does wonders for the bug count ;)
[05:19] <daf> bradb: what do you about omitting the "not filed elsewhere" text
[05:19] <daf> bradb: I find it distracting
[05:21] <bradb> daf: I think SteveA filed a bug on it. We can probably just remove it.
[05:22] <daf> yay
[05:25] <bradb> Launchpad developers won't get any bugmail for any bugs opened before today--I set the bugcontacts today--unless they reported the bug, or someone happened to explicitly add Launchpad Developers to the Cc list on the bug.
[05:26] <bradb> Feel the user love.
[05:27] <Kinnison> daf: I think you got a touch reassign-happy
[05:27] <Kinnison> daf: why is 1527 a soyuz ui bug?
[05:28] <daf> oh, hmm
[05:29] <daf> I was thikning soyuz == package-y bits of Launchpad, not soyuz == package UI bits of Launchpad
[05:29] <daf> do we have a product for gina?
[05:29] <daf> or for the uploader/dominator/gantry etc.?
[05:31] <Kinnison> there's launchpad-upload-and-queue
[05:31] <Kinnison> launchpad-publisher
[05:31] <dilys> Merge to devel/launchpad: [trivial]  capitalise distribution/release names in sample data (r2973: Dafydd Harries)
[05:31] <Kinnison> launchpad-buildd
[05:31] <Kinnison> and soyuz
[05:31] <daf> I see
[05:31] <Kinnison> gina stuff probably ought to remain against the main launchpad product
[05:32] <daf> I'll try and get them right
[05:32] <daf> if I don't, scold me and feel free to reassign again
[05:32] <Kinnison> you're too cuddly for that
[05:33] <Kinnison> ta
[05:33] <daf> hmm, Soyuz needs a 1.1 milestone
[05:34] <daf> oh, it has one
[05:34] <daf> odd
[05:34] <daf> must be Malone being silly
[05:37] <ddaa> bradb: is there a way to tell launchpad: okay, I reported that bug, but I'm not interested in it anymore, really, don't clutter my +reportedbugs page with that anymore, please!
[05:37] <daf> bradb: "Bug #NNNN has not yet been reported in foo. Do you want to report it in foo?" -- it would be nice if it also had a button to reassign
[05:37] <bradb> ddaa: Not yet, but that sounds like an interesting idea.
[05:37] <daf> perhaps: if you reported but are unsubscribed, don't list it
[05:38] <ddaa> I did not manage to unsubscribe from a reported bug...
[05:38] <ddaa> maybe I was just not awake yet
[05:39] <ddaa> bradb: the use case is making my +reportedbugs page useful again by getting rid of all those baz bugs that lifeless does not want to close because maybe next christmas santa claus will take over maintenance of baz.
[05:40] <bradb> right
[05:40] <sivang> what do I need to have isntalled in order for bzr push to be rcognized and use the rsync method?
[05:40] <sivang> I get unknown command error
[05:41] <daf> do you have bzrtools installed?
[05:41] <bradb> daf: Everything is competing for space at the top of the bug page. ;)
[05:41] <daf> bradb: true that :)
[05:41] <ddaa> jeff mum is not
[05:41] <bradb> Portlet allergies?
[05:42] <sivang> daf: pff rightho, thank you
[05:42] <ddaa> no, reference to an old quote
[05:42] <ddaa> "what is soyuz" "soyuz is an application built on the launchpad API" "like everything else" "no, my mum is not an application built on the launchpad API"
[05:43] <sivang> daf: is it in main btw?
[05:43] <daf> sivang: universe
[05:43] <daf> sivang: though I use jbailey's snapshots
[05:44] <daf> I like my revision control systems fresh :)
[05:44] <daf> (undercooked, sometimes)
[05:44] <sivang> daf: true, I will add his sources from the RFS page
[05:45] <sivang> daf: I also can't find it in breezy's universe. weird
[05:45] <daf> oh!
[05:45] <daf> it's dapper/universe, sorry
[05:45] <sivang> uh-ha!
[05:46] <sivang> I had a fishy instinct about that :)
[05:46] <sivang> then guess to add Jeff's snapshots is the way
[05:49] <sivang> daf: does bzr catches import expection to know which capabilities to present to a user? (in man page as well??)
[05:49] <sivang> *exceptions
[05:51] <ddaa> that's not the way it works, the push plugin decorate the push bultin
[05:52] <daf> it used to catch import exceptions for celementtree
[05:52] <Kinnison> daf: pah
[05:52] <Kinnison> daf: I use my own branches, I like my revision control systems hacked
[05:52] <LarstiQ> hah, that's nicelt quotabl
[05:53] <daf> Kinnison: well, when I hack them, I can't be bothered to keep them up to date with the mainline :)
[05:53] <Kinnison> daf: aah
[05:54] <sivang> Kinnison: you're own branches? you mean, you keep your own syncing scripts?
[05:54] <Alinux> hello all...
[05:55] <Kinnison> hi Alinux
[05:55] <Alinux> I have a problem, rosetta doesn't updates translation from an updated .po file.
[05:55] <daf> see you sivang
[05:56] <daf> Alinux: hmm, sounds like it could be a bug
[05:56] <Alinux> mmm I think so
[05:56] <daf> carlos: have we done confirmation emails for imports yet?
[05:56] <Alinux> this 2 days I have updated a valid .po files ... and no changes on site :(
[05:58] <Alinux> :(
[05:59] <daf> carlos: ping
[05:59] <carlos> daf, pong
[05:59] <daf> carlos: have we done confirmation emails for imports yet?
[05:59] <daf> or is it only error email?
[06:00] <Alinux> "Your upload worked. The translation content will appear in Rosetta in a few minutes."
[06:00] <Alinux> but no changes :(
[06:01] <LarstiQ> Aren't there some technical issues on the lp side atm?
[06:05] <Kinnison> the cronscripts might not be running right now
[06:05] <Kinnison> because of database speed issues
[06:22] <Alinux> still no changes :(
[06:22] <Alinux> "Your upload worked. The translation content will appear in Rosetta in a few minutes." - 20 minutes past.
[06:22] <LarstiQ> Alinux: did you see our discussion of what might cause that?
[06:22] <Alinux> is it normal?
[06:23] <Alinux> LarstiQ, yes.
[06:23] <LarstiQ> Alinux: well then
[06:24] <Alinux> but it worked in the past.
[06:24] <Kinnison> It may be because bits of launchpad are currently disabled for performance reasons
[06:25] <Alinux> I hope work is still in progress :)
[06:26] <Alinux> witout you (developers) we (translators) can do nothing :)
[06:26] <Alinux> so we are waiting for yuo :)
[06:26] <Alinux> thanks boys!:D
[06:27] <carlos_> hmmm seems like I was disconnected...
[06:28] <carlos> daf, Alinux, did you see my answer?
[06:31] <LarstiQ> carlos: nope
[06:31] <carlos> Alinux "Your upload worked. The translation content will appear in Rosetta in a few minutes."
[06:31] <carlos> Alinux but no changes :(
[06:31] <carlos> carlos daf, we do confirmations for .po imports
[06:31] <carlos> carlos and also errors
[06:31] <carlos> carlos Alinux, we have some problems with the imports
[06:31] <carlos> carlos Alinux, I hope tomorrow it will be fixed
[06:31] <carlos> * Disconnected (Connection timed out).
[06:37] <daf> carlos: cool
[06:37] <daf> carlos: about the imports cronscript: is there a missing case in the tests?
[06:38] <carlos> seems like that
[06:38] <carlos> I wrote a test and it worked with our test data
[06:38] <carlos> but seems like there is another problem that our tests didn't detect
[06:38] <carlos> so I need to do another fix
[06:39] <daf> aha, I see
[06:43] <daf> carlos: perhaps we can open a bug on fixing the import script tests
[06:45] <carlos> I guess it would be a good idea, but fixing the bugs we are going to fix/add tests also
[06:46] <daf> true
[06:53] <sistpoty> hi
[06:53] <sistpoty> is there any mailing list, where changes like the change to malones email-interface are announced?
[07:00] <Zerlinna> hey, is smb here who could help me with my launchpad / ubuntuwiki account
[07:00] <Zerlinna> ?
[07:05] <bradb> sistpoty: Not yet.
[07:05] <Kinnison> Zerlinna: we can try. what's your problem?
[07:06] <Zerlinna> Kinnison: ya I accidently disabled my ubuntuwiki account.. is there any way to re-enable?
[07:06] <sistpoty> bradb: would be good to have one... for motu merges we parse malone emails and I noticed only now that s.th. didn't work any longer :/
[07:06] <bradb> sistpoty: We have https://wiki.launchpad.canonical.com/LaunchpadWhatsNew being thought about.
[07:07] <Kinnison> Zerlinna: Hmm, what's your launchpad name?
[07:07] <Zerlinna> MirjamWaeckerlin
[07:08] <Zerlinna> on launchpad the wiki account's still there, but I can't login to ubuntuwiki
[07:08] <Kinnison> Odd
[07:08] <Kinnison> are you using your launchpad registered email/password to log into the wiki?
[07:08] <Zerlinna> yes
[07:09] <Kinnison> I wonder if the authserver is hiccoughing again
[07:09] <Zerlinna> hmm, I think I made the mistake
[07:09] <sistpoty> bradb: oh, the spec for the lp-news is nice :)
[07:10] <Zerlinna> Kinnison: I didnt see that I can change the wikiname on launchpad, but I couldnt on the wiki, so I disabled my account on the wiki to create a new one... but I'm just blocked
[07:10] <bradb> sistpoty: If you have any feedback about those ideas, please feel free to bring them up in #launchpad.
[07:10] <Kinnison> Zerlinna: I'm afraid you've lost me
[07:11] <Zerlinna> Kinnison: you mean you don't know how to fix it?
[07:11] <sistpoty> bradb: if I read it right, the news feature will be rss (only?)... I guess some people (including me) would like to have this by mail as well... but that's just an idea
[07:11] <Kinnison> Zerlinna: I mean, I'm not sure what I need to fix :_)
[07:11] <sistpoty> bradb: apart from that the spec looks pretty complete
[07:11] <Kinnison> Zerlinna: If it's that your moin user needs to be re-enabled then I'm not able to do that
[07:12] <Zerlinna> Kinnison: lol.. ok, status quo: I can login on launchpad, but on the wiki (always tells me wrong pw, but I KNOW that it's right, tried about a 100 times)
[07:12] <Zerlinna> Kinnison: sorry: NOT on the wiki
[07:12] <Zerlinna> Kinnison: hmm.. you know smb who can?
[07:13] <bradb> sistpoty: I'm not deeply familiar with the spec, but it does seem to favour syndication instead of mailing lists.
[07:13] <bradb> sistpoty: I guess you're thinking of a launchpad-announce@?
[07:14] <sistpoty> bradb: exactly...
[07:14] <sistpoty> bradb: maybe once this news-feature is there, it could auto-deliver mails to some ml for convenience, but as I wrote before, that's just an idea
[07:14] <bradb> sistpoty: I'll add an XXX to the spec
[07:15] <sistpoty> bradb: cool, thx
[07:16] <Zerlinna> Kinnison: or do you have any ideas where I could get help?
[07:17] <Kinnison> Zerlinna: You need someone who understands the launchpad<->wiki linkage
[07:17] <Kinnison> Zerlinna: I think spiv is the right person to ask
[07:18] <Zerlinna> Kinnison: ...or I just create another account on launchpad.. what do you think?
[07:18] <bradb> sistpoty: np, XXX added.
[07:18] <Kinnison> Zerlinna: Seems a bit overkill to do that
[07:18] <daf> Zerlinna: perhaps you're experiencing this bug https://launchpad.net/products/launchpad/+bug/6283
[07:18] <Ubugtu> Malone bug 6283: "Logging in thru the wiki with my password for launchpad won't work" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/6283
[07:19] <Zerlinna> Kinnison: I have just the impression it's difficult to get help..
[07:20] <Kinnison> Zerlinna: It's only hard in real-time because we're spread out all over the world so timezones can cause realtime support to be a bit hard
[07:20] <daf> Zerlinna: it depends who happens to be around when you turn up
[07:20] <sistpoty> ok, gotta go now... thx again for your help ;)
[07:20] <bradb> np, see ya
[07:20] <sistpoty> cya
[07:21] <Zerlinna> daf and Kinnison I have to admit I'm a bit impatient
[07:22] <daf> Zerlinna: did you take a look at the bug I mentioned?
[07:23] <Zerlinna> daf: I visited the link it's said that admin rights are required to recreate the account on moin
[07:23] <Zerlinna> but I can create a new account and merge it with the old one, maybe that works :-)
[07:41] <Zerlinna> nope, not working :-(
[07:42] <Zerlinna> daf: Kinnison : any other idea... ?
[07:44] <Zerlinna> Kinnison: thank you though and good night :-)
[07:44] <Kinnison> Sorry
[07:44] <Zerlinna> Kinnison: never mind, I'll find a solution.. if it doesn't work I'll create a new account ;)
[07:50] <daf> Zerlinna: perhaps it's bug 3987 that's causing you problems
[07:50] <daf> bug #3987
[07:50] <Ubugtu> Malone bug 3987: "Launchpad wiki UserPreferences causes mismatched passwords" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Andrew Bennetts, Status: Needs Info http://launchpad.net/bugs/3987
[07:53] <Kinnison> ciau all
[08:05] <Zerlinna> daf: ok I've done it now.. thank for the link! It brought me on the right way :-)
[08:05] <daf> Zerlinna: glad I could help
[08:06] <Zerlinna> daf: it wasn't very difficult in the end with the merging option it worked :-) thank you very much!
[08:06] <Zerlinna> so.. I'm off launchpad now... thx again and bye
[10:28] <mpt> Gooooooooooooood morning Launchpadders!
[10:28] <gneuman> mornig mpt
[10:35] <kiko-afk> hello there
[10:42] <mpt> What's wrong with production?
[10:47] <kiko> it's hung :-(
[11:02] <lifeless> and non running on gandwana
[11:03] <lifeless> we're getting timeouts on some sockets
[11:04] <lifeless> I wonder if the db is awol
[11:04] <lifeless> indeed
[11:09] <lifeless> emperor is down, I'm contacting znarl.
[11:09] <kiko> thanks
[11:17] <gneuman> is anyone experiencing failures in make check?
[11:18] <mpt> gneuman, did you remake the database?
[11:19] <mpt> there have been quite a few schema changes recently
[11:19] <gneuman> make schema?
[11:19] <gneuman> yes
[11:19] <mpt> make in schema/, yes
[11:19] <mpt> oh, can you just "make schema" instead?
[11:19] <mpt> nifty!
[11:19] <gneuman> thats waht i allways did
[11:23] <kiko> mpt, you're welcome
[11:41] <ajmitch> is launchpad currently undergoing 'corrective maintenance'?
[11:43] <mpt> yes, Launchpad's been very naughty
[11:43] <ajmitch> oh dear
[11:43] <carlos> kiko, hi, do you have time for a new fast review?
[11:43] <carlos> kiko, https://chinstrap.ubuntu.com/~dsilvers/paste/fileBoQ4wN.html
[11:43] <kiko> not really but
[11:43] <kiko> ouch
[11:44] <carlos> ok
[11:44] <kiko> can you test both codepaths there, carlos?
[11:44] <carlos> which codepaths?
[11:45] <kiko> there's an if clause in getPOTemplateByPath
[11:45] <kiko> make sure you are testing both branches
[11:45] <carlos> oh, right
[11:47] <carlos> hmmm
[11:47] <carlos> kiko, the if is not needed, the first if entry point will never be reached
[11:47] <kiko> carlos, good thing I asked that question then!
[11:48] <carlos> ;-)
[11:48] <carlos> done
[11:49] <kiko> and self.query is never None?
[11:50] <carlos> kiko, no, it's set as part of __init__ method
[11:53] <carlos> kiko, can I use r=kiko?
[11:53] <kiko> carlos, sure.
[11:53] <carlos> ok, thanks
[11:57] <elmo> stub/lifeless: ?
[11:59] <lifeless> yo
[11:59] <lifeless> is the king in the house ?
[11:59] <elmo> lifeless: can we make launchpad do something better?  like display the down for maintenance page
[11:59] <elmo> emperor's going to be down for another 5-10 mins at least
[11:59] <lifeless> ok
[12:00] <lifeless> uhm, I was hoping to leave it running
[12:00] <lifeless> the maintenance page shows when its turned off
[12:00] <lifeless> any idea what broke emperor ?
[12:02] <kiko> not me
[12:02] <lifeless> kiko: you sure now ? :)
[12:02] <elmo> lifeless: yes, will explain later, fix now
[12:03] <elmo> lifeless: how is it useful to leave it running without a backend?
[12:03] <kiko> lifeless, I won't admit to it in a public channel dammit
[12:03] <lifeless> kiko: DOIT


[13:30]  * smartboyhw is not happy that no Ubuntu TV update from jhodapp for 2 weeks:(
[15:26] <tgm4883> smartboyhw, literally nothing to update
[15:26] <tgm4883> * Bug fixes
[15:29] <smartboyhw> LOL


[14:10] <elhoir> hello everybody
[14:10] <elhoir> i wanted to ask if you know which kernel version will be shipped in Ubuntu Yakkety
[14:11] <elhoir> as im installing mainline kernels, but dont want to install the same version that will be in 16.10
[14:11] <elhoir> thanks!
[14:19] <DJones> elhoir: Looked this up, suggest it may come with 4.7 or 4.8 http://news.softpedia.com/news/ubuntu-16-10-yakkety-yak-will-soon-be-powered-by-linux-kernel-4-6-503812.shtml
[14:20] <DJones> But no doubt will be subject to bug testing & other developments, article is dated in May, so maybe some changes
[14:20] <elhoir> DJones, thanks, im currently running 4.5
[14:21] <elhoir> and i will run LTS kernel when available
[20:02] <mustmodify> I'm using upstart with ubuntu 16.1. 'setuid' doesn't seem to do what I'm expecting. Am I using it correctly?
[20:02] <mustmodify> https://gist.github.com/mustmodify/ba42c621a3ddcadb7a41eba78fea2279
[20:03] <teward> mustmodify: Ubuntu 16.04+ uses SystemD by default, are you absolutely certain you're using upstart still?
[20:03] <mustmodify> Yes.
[20:03] <k1l> mustmodify: there is no ubuntu 16.1
[20:03] <k1l> !releases | mustmodify
[20:03] <mustmodify> Oh uh...
[20:03] <mustmodify> please hold...
[20:04] <teward> I assumed they meant 16.10, but they need to clarify, yes.
[20:04] <mustmodify> Yep, I was rounding to the nearest decimal.
[20:04] <mustmodify> 16.04
[20:04] <mustmodify> not really but it's a decent excuse.
[20:04] <teward> mustmodify: first: it's not a decimal number
[20:04] <teward> it's a string
[20:05] <teward> secondly, go back go #ubuntu 'cause I assumed 16.10 not 16.04
[20:05] <k1l> mustmodify: details matter. 16.04 is a totally different release than the 16.10.
[20:19] <mustmodify> Yes, I'm sorry.
[20:19] <mustmodify> tweard: Yes, that was a joke.
[20:19] <mustmodify> k1l: Yes, I'm sorry. I'm aware that it matters. That was a joke.
[20:20] <mustmodify> albeit not (apparently) a funny one.
[20:20] <k1l> …