[06:43] <mborzecki> morning
[07:22] <zyga> good morning
[07:34] <Faults> Goood morning!
[07:45]  * zyga got a power plug adapter for south africa
[07:51] <mup> PR snapd#5845 closed: interface: add new `{personal,system}-files`  interface <Reviewed> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5845>
[08:05] <pstolowski|afk> mornings
[08:07] <mborzecki> zyga: pstolowski: hey
[09:17] <t1mp> hello
[09:17] <t1mp> is this the place for questions relating to snap packaging problems?
[09:17] <zyga> t1mp: hey, for various kinds of topics related to snaps
[09:22] <t1mp> I created a snap package, which has a python+qt app inside (using PySide2, and PyInstaller). It works on most systems, but when the host is running Wayland, it fails as follows:
[09:22] <t1mp> https://pastebin.ubuntu.com/p/whWXk2drjW/
[09:22] <t1mp> greyback is already helping me with it :)
[09:27] <t1mp> for reference, my snapcraft.yaml is here: https://pastebin.ubuntu.com/p/KN9qsVRdJ8/
[09:33] <Chipaca> morning all
[09:33] <popey> Good day
[09:36] <popey> t1mp: hey! don't you also need the 'wayland' plug?
[09:36] <popey> I have seen some options where you use x11 and wayland plug but disable wayland in the environment which triggers it to use xwayland
[09:37] <t1mp> popey: hello :)
[09:37] <t1mp> I have no idea. Is there documentation about the wayland plug somewhere?
[09:38] <t1mp> I thought all was working, but now when testing on different systems I found that the snap doesn't work on systems with wayland.
[09:38] <mup> PR snapd#5915 closed: interfaces/network-setup-control: allow calling netplan generate/apply <Created by ogra1> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/5915>
[09:38] <popey> https://forum.snapcraft.io/t/wayland-crash-with-electron-2/5752/4?u=popey
[09:39] <popey> t1mp: theres a similar thread, where they use DISABLE_WAYLAND=1 in the environment to force xwayland
[09:39] <popey> (I *think* that's how it works)
[09:39] <popey> The documentation for the wayland interface is somewhat lean https://docs.snapcraft.io/the-wayland-interface/7784
[09:40] <popey> https://github.com/notepadqq/notepadqq/blob/master/snap/snapcraft.yaml#L16
[09:40] <popey> someone else using that method
[09:42] <t1mp> shouldn't those kind of things be included in the desktop-helpers?
[09:42] <t1mp> I could try the DISABLE_WAYLAND env var
[09:42] <popey> possibly
[09:43] <t1mp> plugs are irrelevant as long as I'm using --devmode right?
[09:43] <popey> yes
[09:43] <popey> (I think)
[09:44] <popey> you can use "snappy-debug.security scanlog" to learn what's failing apparmor
[09:44] <popey> leave that running in another terminal when you run the app
[09:44] <popey> might be enlightening
[09:49] <zyga> brb
[09:58] <t1mp> greyback: interesting, if I run the app (packaged with PyInstaller), but outside of the snap, it works fine. But if I set QT_QPA_PLATFORM=wayland, then it starts but without window decoration or images in the app.
[09:59] <mup> Issue core18#93 closed: i386 support missing on core18-amd64 <Created by mmtrt> <Closed by sil2100> <https://github.com/snapcore/core18/issue/93>
[10:02] <t1mp> The missing images looks familiar. I think I had the same on X when I missed some files to have GLSL support
[10:10] <zyga> quick coffee to raise the pressure
[10:10] <zyga> it's so sleepy today
[11:06] <mup> PR snapd#6333 opened: daemon: intrduce /v2/connections snapd API endpoint <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6333>
[12:01] <t1mp> greyback, popey: https://github.com/notepadqq/notepadqq/blob/master/snap/snapcraft.yaml#L16 made the snap work for me
[12:01] <t1mp> I don't know if it is the most elegant solution, but the package works now, which is what I need
[12:01] <t1mp> thanks for the help :)
[12:01] <t1mp> I still need to test it on some PCs though
[12:02] <greyback> t1mp: ok, glad you got it working
[12:02] <greyback> it appears wayland support still needs work in desktop-helpers
[12:08] <popey> (bug reports welcome) :D
[12:10] <diddledan> bug reports? https://www.youtube.com/watch?v=S-s4lEk91ng
[12:11] <zyga> brb again
[12:14] <popey> diddledan: I'm doing my part!
[12:14] <pstolowski> mborzecki: hey, #6332 can land right?
[12:14] <mup> PR #6332: spread: make Fedora 29 auto again <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6332>
[12:15] <mborzecki> pstolowski: let me run the spread job again, sample of 2 is better than 1 ;)
[12:18] <mup> PR snapd#6318 closed: release-tools: display self-help <Simple 😃> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6318>
[12:18] <pstolowski> ok
[12:21] <zyga> thanks pawel!
[12:21] <zyga> running some spread tests, I will go for a walk with the dog
[12:21] <zyga> it's snowing like crazy here
[12:22] <zyga> I don't want to miss this ;0
[12:22] <zyga> :-)
[12:22] <MattJ> Where is $here? I want to come!
[12:22] <MattJ> (wait, that sounded creepy)
[12:23] <zyga> it's all bound to melt away, it will be +2 soon
[12:23] <zyga> but for now it's close to -1 so the view is very nice
[12:23] <zyga> (in Warsaw)
[12:32] <pedronis> mborzecki: hi, are you mostly blocked waiting on various reviews at this point?
[12:34] <mborzecki> pedronis: i'm advancing respective pieces in private branches and working on a small fontconfig fix for fedora, but yeah, opening new PR is blocked until some of the current ones land
[12:35] <pedronis> mborzecki: ok, I will get to your PRs but there are even older PRs that needs some attention too, I can point at some of the "small" cards I mentioned yesterday in the standup
[12:56] <mup> PR snapd#6334 opened: dirs, interfaces/builtin/desktop: system fontconfig cache path is different on Fedora <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6334>
[12:57] <mborzecki> ^^ maybe a bit late for .37 but we could squeeze it in .37.1
[13:00] <mup> PR snapd#6332 closed: spread: make Fedora 29 auto again <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6332>
[13:03] <mborzecki> off to pick up the kids
[13:15] <t1mp> greyback: yeah. Is any OpenGL stuff not working with Wayland now? That seems quite important ;)
[13:15] <t1mp> or is it just Qt? Or something specific that I'm using
[13:16] <greyback> t1mp: it has worked for me in the past. I don't know what broke for you, sorry
[13:16]  * Chipaca ⇝ lunch
[13:26] <zyga> re
[13:26] <zyga> t1mp: it probably depends
[13:45] <t1mp> okay, thanks. :) For me it just matters that it works for my snap now ;) I'm sure the snap is optimal, but I'll see if I can work on it again in the near future.
[13:46] <t1mp> *I'm sure my snap is NOT optimal :)
[13:56] <pedronis> Chipaca: hi, could you review #6121 when you have a bit of time?
[13:56] <mup> PR #6121: tests: new test for snapshots with more than 1 user <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6121>
[13:57] <Chipaca> pedronis: yes
[13:57] <Chipaca> I guess the current test that creates snapshots for root + testuser isn't enough?
[13:58] <pedronis> Chipaca: I suppose, it's  question for cachio
[13:59] <pedronis> mborzecki: btw, did you see the request for tweaks to #6317 ?
[13:59] <mup> PR #6317: overlord/snapstate/backend: call fontconfig helpers from the new 'current' <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6317>
[14:02] <mborzecki> pedronis: yup, saw that, it's in my queue
[14:02] <pedronis> ok
[14:31] <mup> Bug #1810948 opened: Internal Watcher Error <Snappy:New> <https://launchpad.net/bugs/1810948>
[14:43] <mup> Bug #1810948 changed: Internal Watcher Error <Snappy:Invalid> <https://launchpad.net/bugs/1810948>
[15:08] <cachio> zyga, https://travis-ci.org/snapcore/spread-cron/builds/476263240#L9952
[15:08] <zyga> looking
[15:08] <cachio> that should be fixed with the update in the repo?
[15:08] <zyga> so
[15:08] <zyga> you need to update & reboot
[15:08] <zyga> let me check that locally
[15:09] <cachio> zyga, I did that
[15:09] <zyga> in that case the fix is not out yet
[15:09] <zyga> let's wait and see, I'll check the bug report in suse
[15:09] <zyga> thanks for trying!
[15:09] <cachio> np
[15:54]  * cachio lunch
[16:12] <pedronis> jdstrand: thanks for adding the docs about personal/system-files, shouldn't the doc mention somehow that even just installation requires the snap-declaration ?
[16:12] <pedronis> (Not sure how we did this for other interfaces with the same requirement)
[16:18] <mborzecki> feels like we should parse /etc/fonts/fonts.conf to figure out fontconfig locations rather than use hardcoded ones
[16:19] <mborzecki> fedora/rhel/centos all use /usr/lib/fontconfig/cache, but amzn2 is behind with updates and uses /var/cache/fontconfig and obviously has ID_LIKE=".. fedora.."
[16:27] <zyga> mborzecki: how hard is it to parse?
[16:27] <mborzecki> zyga: rather easy, it's xml, encoding/xml should do just fine
[16:27] <zyga> oh, that's good
[16:28] <zyga> is the location easy to extract?
[16:29] <mborzecki> zyga: yes, it's quite trivial :)
[16:30] <mborzecki> zyga: btw. wonder if we shuld also use ~/.local/share/fonts and ~/.fonts, we're only using system locations now
[16:30] <zyga> it depends if the code runs in user contetxt
[16:31] <mborzecki> zyga: we setup those mounts in the desktop interface, i'd guess it does
[16:31] <zyga> but who would run the parser?
[16:33] <mborzecki> zyga: snapd could parse /etc/fonts/fonts.conf in destkop iface mount connected plug
[16:36] <jdstrand> pedronis: probably, yes. we don't do that elsewhere that I can see but that is no reason not to do it here
[16:36] <jdstrand> pedronis: I'll adjust
[16:44] <zyga> mborzecki: can we discuss this tomorrow morning?
[16:44] <zyga> I'm adding some tests still
[16:44] <jdstrand> pedronis: done. fyi, I also updated snapd-control and kernel-module-control similarly. maybe that will reduce some questions
[16:50] <pedronis> jdstrand: thanks
[16:53] <pedronis> pstolowski: I left a comment in the hotplug-connect PR, we can talk about it tomorrow
[16:54] <pstolowski> pedronis: ok, thanks
[16:55] <mborzecki> zyga: sure
[17:45] <t1mp> kenvandine: hello :)
[17:45] <t1mp> I just saw your comment on https://github.com/ubuntu/snapcraft-desktop-helpers/issues/172
[17:46] <kenvandine> hey t1mp
[17:46] <t1mp> the way I understand it, plugs don't make a difference if the snap runs with --devmode (or as classic). Is that correct?
[17:46] <kenvandine> oh
[17:46] <kenvandine> right
[17:46] <t1mp> hmm. I'm rebuilding my snap and (automatically, with jenkins) pushing it to the snap store, but I keep getting a 502 error
[17:47] <t1mp> Snap Store encountered an error while processing your request: bad gateway (code 502).
[17:47] <t1mp> The operational status of the Snap Store can be checked at https://status.snapcraft.io/
[17:47] <t1mp> script returned exit code 2
[17:49] <t1mp> I can see the revision though when I log in on snapcraft.io
[17:50] <t1mp> ah no, I cannot. It is a different revision number
[17:50] <t1mp> (just two digits swapped that's why I thought it is the same)
[17:53] <kenvandine> t1mp: try added QT_QPA_PLATFORM=wayland
[17:53] <kenvandine> i haven't  trying anything qt/qml with wayland myself
[17:54] <t1mp> kenvandine: I tried that. Still gives the same error.
[17:54] <t1mp> I will add a comment to the issue
[17:54] <kenvandine> greyback: ^^ do you have any ideas?
[17:54] <kenvandine> greyback: https://github.com/ubuntu/snapcraft-desktop-helpers/issues/172#issuecomment-452388662
[17:55] <t1mp> greyback: was already helping me with it :) So he is aware. For me the problem is solved with the DISABLE_WAYLAND: 1.
[17:55] <t1mp> That's enough for me, I have a working snap. But I guess it is still a workaround.
[17:55] <kenvandine> that's not a solution though :)
[17:55] <kenvandine> that makes it fall back to XWayland
[17:59] <t1mp> true
[17:59] <t1mp> but I need to release my snap this week :)
[18:03] <kenvandine> yeah... so probably good enough :)
[18:06] <kyrofa> Hey pedronis, you still around?
[18:08] <greyback> kenvandine: hey, yes I looked into it. I noticed the glvnd config was missing - $SNAP/usr/share/glvdn/egl_vendor.d/50_mesa.json - (stracing the binary, it was not opening any DRI drivers). When I hacked that file into the snap, the app worked for me on my wayland. So I recommended adding "libegl0-mesa0" to the stage packages, but that didn't help t1mp
[18:09] <kenvandine> hmm
[18:09] <greyback> kenvandine: I didn't try further tbh
[18:09] <kenvandine> understand
[20:45] <popey> cjwatson: do we have an eta for core18 builds in LP via build.snapcraft.io ?
[20:47] <cjwatson> popey: not yet
[20:55] <diddledan> is that the eta is "not yet" or the eta on the eta is "not yet"?
[20:56] <diddledan> kenvandine: I've done a lot of work yesterday and today on the gnome-extension POC that I created: https://github.com/snapcore/snapcraft/pull/2398
[20:56] <mup> PR snapcraft#2398: gnome extension <Created by diddledan> <https://github.com/snapcore/snapcraft/pull/2398>
[21:07] <mup> PR snapd#6335 opened: NOT-REVIEW: tests: fix "No space left on device" issue on amazon-linux <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6335>
[21:09] <kenvandine> diddledan: I noticed!
[21:09] <diddledan> it finally works
[21:09] <kenvandine> oSoMoN and I will look at it tomorrow
[21:09] <diddledan> :-p
[21:09] <kenvandine> Woot
[21:10] <diddledan> I've done a test build locally with my gnome-twitch snap which successfully built the snap and when installed it runs correctly
[21:10] <kenvandine> Excellent
[21:10] <diddledan> including libwebkitgtk!
[21:11] <diddledan> (I put a layout definition to fix that)
[21:11] <kenvandine> diddledan: thanks for that
[21:12] <diddledan> it also uses the gnome-3.xx-1x04 platforms
[21:14] <diddledan> I couldn't publish my test build of gnome-twitch to the store, though, because it rejected the `command-chain:` block because it doesn't believe such a config exists :-)
[22:17] <cjwatson> diddledan: yes
[22:18] <diddledan> :-)


[02:49] <billybigrigger> anyone alive?
[06:04] <macvr> billybigrigger: i guess no ;p
[06:12] <billybigrigger> any chance we're gonna see the shiki arc and gnome colors as default themes in karmic?
[06:12] <billybigrigger> i've been using them for the last week or so and should definitely be installed and an option by default
[06:13] <billybigrigger> i prefer them over human
[06:13] <billybigrigger> and im sure lots of people do :P
[06:25] <dashua> billybigrigger: sudo apt-get install shiki-colors :)
[06:26] <billybigrigger> yeah but, why isnt it installed by default
[06:26] <billybigrigger> when a new user checks out appearance, those 4 colored themes should be there by default
[06:26] <dashua> Oh default for sure probably not
[06:27] <billybigrigger> why?
[06:34] <BHSPitMonkey> because ubuntu isn't ever what we want it to be by default
[06:35] <billybigrigger> its 4 themes
[06:35] <billybigrigger> that look alot better than the default
[06:35] <billybigrigger> and are practical
[06:42] <BHSPitMonkey> billybigrigger: and that is why they will never ship :P
[06:42] <billybigrigger> oh the truth hurts haha
[06:55] <macvr> billybigrigger: kwwii_ was saying that they are thinking of using Humanity.
[06:55] <billybigrigger> is that the one that uses the nodoka engine that doesn't work?
[06:56] <billybigrigger> oh
[06:56] <billybigrigger> thats not on the karmic art wiki
[06:56] <billybigrigger> where can i find humanity?
[06:57] <macvr> billybigrigger: : http://sinecera.de/humanity-icon-theme_0.1_all.deb
[06:57] <billybigrigger> thats the newest?
[06:57] <billybigrigger> is there a ppa or anything for it to keep updated?
[06:57] <macvr> billybigrigger: wiki  >> https://wiki.ubuntu.com/Artwork/Incoming/Karmic/elebuntu_Icons
[07:03] <billybigrigger> oh i thought humanity was a gtk theme
[07:03] <billybigrigger> not just iconset
[07:06] <macvr> i dont , think they will change the theme.
[07:06] <macvr> billybigrigger: new theme might be only for karmic+1
[07:07] <billybigrigger> bah humbug
[07:10] <macvr> billybigrigger: well that is what the UX team says! they might also change the brown color
[07:10] <billybigrigger> good
[07:10] <billybigrigger> so what is the art team canonical hired doing for karmic then?
[07:10] <billybigrigger> nothing
[07:10] <billybigrigger> ??
[07:11] <macvr> billybigrigger: that is the silliest question i have heard!
[07:11] <billybigrigger> well if they're not changing the theme for karmic
[07:11] <billybigrigger> i thought mark said we're ditching brown for karmic?
[07:12] <macvr> billybigrigger: yes he did but he also said there wasnt enough time! you seem to be bordering on trolling!
[07:12] <billybigrigger> haha what do you mean?
[07:13] <billybigrigger> i my original question was about having shiki arc and gnome colors for 4 default themes
[07:13] <macvr> trash talking the canonical art team is not appropriate for this room
[07:13] <billybigrigger> no no
[07:13] <billybigrigger> i wasn't trash talking
[07:14] <billybigrigger> i just thought an art team was hired for jaunty+1 and wondered why no change in karmic
[07:14] <billybigrigger> im sorry if i offended you
[07:14] <billybigrigger> i don't mean to come off as rude
[07:14] <macvr> FYI , it is not the art team, it is the UX team , UX=user experience
[07:14] <billybigrigger> my bad
[07:15] <billybigrigger> maybe i should sub to the mailing list to catch up on some stuff
[07:15] <macvr> billybigrigger: dont worry , i'm not working for canonical ;p
[07:15] <billybigrigger> my info is outdated apparently
[09:46] <kwwii_> good morning
[09:47] <kwwii> w00t, I am back
[09:49] <thorwil> good morning, kwwii
[09:51] <kwwii> hi thorwil
[09:52]  * kwwii reads his email backlog...what fun!
[10:07] <kwwii> thorwil: I just sent an email to our lawyer, we'll see what she says
[10:07] <thorwil> kwwii: cool, ty
[10:10] <kwwii> wow, creating a flickr group is a lot of work
[10:11] <thorwil> kwwii: what, it's not just "add group" give a name and answer join requests?
[10:13] <kwwii> well, there are rules and an icon ans uch
[10:13] <kwwii> such
[10:13] <kwwii> and such...man my spelling is poor this morning
[10:14] <thorwil> may the spelling be with you later today!
[10:14] <kwwii> :p
[10:19] <SiDi> kwwii: back from spain ?
[10:19] <kwwii> SiDi: yepp
[10:19] <SiDi> how was it ?
[10:20] <kwwii> excellent ;)
[10:20] <kwwii> now I wish I would have stayed the rest of the week
[11:05] <kwwii> http://www.flickr.com/groups/ubuntu-artwork/ is the revamped flickr group
[11:05] <kwwii> maybe if everyone invites their friends and tell people about it we will get some new contributors
[11:07] <SiDi> kwwii: should we advertise the group on social networkz ?
[11:11] <SiDi> netsplit :o
[11:27] <kwwii> SiDi: yes, please do ;)
[11:27] <kwwii> several of the design team are going to blog about it, etc.
[11:28] <SiDi> i'll post on facebook n identi.ca then
[11:28] <SiDi> my blog is still offline
[11:36] <kwwii> cool
[11:44] <kwwii> lol, I forgot the password to my blog :p
[11:45] <kwwii> shows how much I blog :p
[11:47] <knome> :P
[11:57] <kwwii> http://kwwii.blogspot.com/
[11:57] <kwwii> ta-da
[11:57]  * thorwil marks the day in calendar
[12:00] <knome> so *that's* what you look like
[12:01] <kwwii> :p
[12:01] <kwwii> big and ugly
[12:01] <knome> naahh
[12:02] <thorwil> nah, at least not just a floating head like oh-so-many planet bloggers!!
[12:02] <kwwii> actually, I am not in 99% of those photos
[12:02] <knome> well you are in the profile photo...
[12:02] <kwwii> ahhh, on the blog, right
[12:02] <knome> yep
[12:02] <kwwii> I was thinking of my flickr page
[12:02] <knome> nah
[12:03] <kwwii> wow, about 3,200 people have looked at my profile :p
[12:04] <thorwil> http://people.ubuntu.com/~kirkland/Museum/
[12:04] <knome> heh
[12:04] <thorwil> https://wiki.ubuntu.com/Artwork/Archives
[12:04] <knome> saw that already, it's a nice idea, but why no xubuntu...
[12:04] <thorwil> hmm
[12:05] <thorwil> what's xubuntu?
[12:05] <kwwii> thorwil: did you make that logo?
[12:05] <kwwii> they had asked me for one but I got too busy
[12:05] <thorwil> kwwii: no
[12:05] <knome> it's a sexy flavor of ubuntu :P
[12:06] <thorwil> knome: does it come with a lingerie theme??
[12:06] <knome> thorwil, that's the xubuntu limited edition, with comes with a real lingerie
[12:06] <knome> you must've messed those up
[12:06] <kwwii> xfce edition
[12:07] <kwwii> erm, not edition but flavor ;)
[12:07] <thorwil> knome: fresh or used lingerie in the limited edition?
[12:07] <knome> you can choose while ordering
[12:08] <thorwil> wow!
[12:08] <knome> you also can choose from red, one or black and from different sizes, of course
[12:08] <knome> pink is doable, but it costs $10 extra
[12:08] <thorwil> oh, i suspected blue-only
[12:16] <kwwii> w00t, I received and answer from a lawyer within hours :p
[12:28] <knome> hah
[12:28] <knome> he must be a fake lawyer
[12:30] <thorwil> kwwii: got it, thanks. of course "sign" is funny, if all we ask of everyone is to just claim to be the photographer/model of the submitted picture
[12:31] <kwwii> well, in order to use someone photo we will really need a signed release form
[12:31] <kwwii> I assumed that was clear
[12:31] <kwwii> sorry
[12:32] <kwwii> something to have in hand in case someone tries to sue us for using their image :)
[12:32] <thorwil> kwwii: that needs to be on paper, sent to canonical, then?
[12:34] <kwwii> thorwil: I am not sure, maybe a scanned copy is enough
[12:36] <kwwii> wow, looking into it, there is a special release form for minors :p
[12:37] <kwwii> so, looking at what istockphoto does, you can sign the release form and then upload that scanned copy
[12:37] <thorwil> i know that istockphoto asks for signed model release forms for each and everyone
[12:37] <kwwii> http://www.istockphoto.com/tutorial_9.0_modelrelease.php
[12:37] <thorwil> lol
[12:38] <kwwii> it does not say it has to be the original piece of paper though...just that it has to be a copy which was signed by hand
[12:43] <thorwil> kwwii: so can we make this a very official project and your lawyer to prepare such model releases?
[12:44] <kwwii> thorwil: well, I think we can take a normal model release form, fill in the right names, etc and then send it to her for review
[12:44] <kwwii> well, both and adult version and a minor version
[12:49] <kwwii> http://www.betterphoto.com/article.asp?id=37 seems to have a link to word docs
[12:49] <thorwil> why am i doing this again? oh right, i'm not quite right in the head an think it's fun, somehow! :)
[12:49] <kwwii> :p
[13:07] <kwwii> thorwil: I will edit the ones on that page and send them to her and ask if that they are ok
[13:10] <thorwil> kwwii: great! keep in mind that it's about having a permissive license in contrast to what stock sites and co do. thanks!
[13:15] <kwwii> thorwil: sent...we will see what she says
[13:17] <thorwil> kwwii: i have a draft call-for-submissions, though without the model release business so far. working on an illustration for it
[13:21] <kwwii> cool
[13:22] <kwwii> I guess that the model release is only needed for the ones which are picked to be included
[13:22] <thorwil> yes, but i wouldn't consider submisions without it in the first place ...
[13:25] <kwwii> yeah, you are probably right
[13:25] <kwwii> in any case, the release forms should not be publicly vewable
[13:25] <kwwii> viewable
[13:27] <SiDi> meh
[13:27] <SiDi> chromium having trouble with freenode's webir
[13:27] <SiDi> c
[13:29] <thorwil> kwwii: how about a special email address for submissions? bad regarding bandwidth, but something virtually everyone can handle
[13:30] <kwwii> thorwil: true, we could use the ubuntu-art-devel list for that
[13:33] <thorwil> kwwii: huh? what i had in mind was an everyone can post with big attachments list
[13:34] <SiDi> i found a wikipage for the hall of fame
[13:34] <SiDi> https://wiki.ubuntu.com/Artwork/Incoming/Karmic/new_human_icons
[13:58] <kwwii> lol, guess I will erase that
[13:59] <SiDi> come on, you're weakening the community when you do such things :O
[13:59] <kwwii> hehe
[14:52] <kwwii> thorwil: http://www.youtube.com/watch?v=WfBlUQguvyw
[14:52] <kwwii> really cool video of using multiple videos
[14:52] <kwwii> time for a break, bbiab
[16:06] <kwwii> wow, two responses from two lawyers in one day
[16:06] <kwwii> thorwil: I sent them the release forms and they responded by saying that canonical has their own and that they will find them and send them to me
[16:22] <SiDi> kwwii: canonical has cool lawyers !
[16:27] <kwwii> SiDi: no doubt, I already got another response with the release
[16:27] <kwwii> that makes the legal team the most responsive team in canonical :p
[16:28] <kwwii> thorwil: I will forward the release to you, there is a catch in it :(
[16:28] <SiDi> meh
[16:28] <SiDi> tthe SiDi fan team is responsive too
[16:28] <knome> "the sidi fan team"?
[16:29] <SiDi> yeh knome
[16:29] <SiDi> im the main and unique member
[16:29] <SiDi> but i keep hoping
[16:29] <knome> haha..
[16:35] <thorwil> 0.0
[16:39] <SiDi> knome: wanna join ? D:
[16:39] <knome> hmm...
[16:39] <knome> let me think
[16:39]  * kwwii cooks dinner while thorwil reads his email
[16:40] <knome> SiDi, maybe once you're ready to take credit for what you've done :]
[16:40] <SiDi> knome: there is no credit i should take, what i do anyone else could do it
[16:40] <knome> that's a bed excuse.
[16:40] <knome> *BAD
[16:40] <knome> damn it...
[16:41] <SiDi> bed ?
[16:41] <SiDi> My invitation to join was _only_ about the fan club knome !
[16:41] <knome> hehe..
[16:44] <macvr> kwwii: awesome youtube video... amazing editing   0.0
[16:47] <SiDi> yeh i must say the concept is quire original
[16:49] <knome> which video?
[16:56] <SiDi> knome: http://www.youtube.com/watch?v=WfBlUQguvyw
[16:56] <SiDi> www.sidifanclub.com btw !
[16:57] <knome> open that site first :P
[16:58] <macvr> knome: i fell for that page too !
[17:00] <knome> SiDi, http://files.boardgamegeek.com/images/shake.gif
[17:01] <SiDi> knome: emonk.fi !
[17:01] <SiDi> very up-to-date :p
[17:01] <knome> wehmm.. isn't it?
[17:02] <knome> the fact that some section if updated last in mid-jaunuary 2009 doesn't mean it's not up-to-date
[17:03] <knome> i need something to drink
[17:03] <SiDi> macvr: http://img244.imageshack.us/img244/3119/capture3w.png
[17:04] <SiDi> my system is completely broken
[17:05] <macvr> SiDi: is that a mockup ? or is that the dialogue in xubuntu?
[17:05] <SiDi> it doesnt suspend when i close the lid, it kernel panics on wake up, it refuses to shutdown properly, terminals open in .cache instead of ~
[17:05] <SiDi> macvr: mockup
[17:06] <SiDi> wording is far from perfect but thats the last of my problems :p
[17:07] <macvr> SiDi: addressing directly like 'you havent' is not nice... rather things needs to be as "the system hasnt been"
[17:08] <SiDi> Ah true
[17:08] <SiDi> damn i need to gimp it again now
[17:11] <macvr> SiDi: also... the warning seems too "in your face" , maybe you are trying to keep it that way... but IMO that is a *very* scary warning for average users
[17:14] <SiDi> macvr: this would only appear after a week
[17:15] <SiDi> and its meant to be scary
[17:15] <SiDi> if you dont scare users they dont scare
[17:15] <SiDi> and as scottk pointed out the current problem is that they dont care
[17:15] <macvr> i know... but still, it is too much
[17:15] <macvr> just my 2 cents ;p
[17:15] <SiDi> so instead of bothering the 80% who already care, lets scare only the remaining 20%
[17:17] <SiDi> http://img199.imageshack.us/content.php?page=done&l=img199/7207/capture3j.png macvr
[17:19] <macvr> SiDi: the initial "It looks like" is not needed , Just "The system..."
[17:19] <SiDi> i have the feeling i'll reinstall xubuntu soon :|
[17:19] <SiDi> macvr: yeh i know :p
[17:19] <SiDi> also the 2nd § sucks a lot
[17:19] <SiDi> i just wanna convey the idea, the wording will come later
[20:17] <dashua> SiDi: https://wiki.ubuntu.com/Artwork/Incoming/Karmic/Human-Redux?action=AttachFile&do=view&target=gnome-themes-ubuntu_0.4_all.deb
[20:17] <dashua> Testing, when you get a chance.
[20:18] <SiDi> currently trying to prevent a kitten from being eaten by a bigger cat :|
[20:18] <dashua> Oh
[20:18] <dashua> Take of your little friend
[20:21] <SiDi> cats are STRICTLY forbidden here
[20:21] <SiDi> if im caught with her im fired off my home :p
[21:52] <ckontros> macvr: I didn't get the attachment on that email about the folder.
[21:53] <macvr> ckontros: oh... i didnt send ;p  its the same one from the submissions page
[21:53] <ckontros> And to answer you question "Is it better" (re nm icon revision) Yes. yes they are. ;)
[21:53] <macvr> ckontros: BTW , is the nm- icon better now?
[21:54] <macvr> ok.
[21:55] <ckontros> I'm going to make a big upload tonight. Mostly accumulated fixes.
[21:55] <macvr> ckontros: the face-sad needs fixing too.
[21:56] <ckontros> I have the latest rev from the wiki. Is there another?
[21:56] <macvr> i mean , i'v sent the corrected labels
[21:56] <macvr> nothing else , just the labels
[21:57] <macvr> ckontros: the wiki is the wrong one... the one from the mail i sent is labelled correctly
[21:57] <ckontros> Looks like mine is correct.
[21:57] <ckontros> So I guess I have the right one. As well as "face-sick".
[21:58] <macvr> ckontros: the emblem-default is new version too
[21:58] <macvr> on the sub page
[22:01] <macvr> ckontros: the appointment-soon , in the trunk , is blurry. did you check out the edit i had done? [aligned the pixels]
[22:02] <ckontros> Dont think I did.
[22:03] <ckontros> I'm grabbing all the emblems on the wiki but " emblem-readonly". Still not crazy about it.
[22:04] <macvr> ;p
[22:04] <macvr> ckontros: http://files.getdropbox.com/u/1325768/appointment-soon.png < appointment soon
[22:05] <ckontros> Email it. I'll throw it in this upload.
[22:05] <macvr> k...
[22:05] <kwwii> ckontros: hey dude
[22:05] <ckontros> yo yo
[22:05]  * kwwii returns from band practice
[22:05] <ckontros> \m/
[22:05] <kwwii> saw luis in las palmas
[22:05]  * ckontros has just returned from work and is doing email.
[22:05] <kwwii> I took a ride in his car
[22:06] <ckontros> kwwii: Oh nice. He's been kinda absent lately.
[22:06] <ckontros> Alot going on with work. Not that he's a full employee at SUN.
[22:07] <ckontros> Err... Oracle
[22:07] <kwwii> lol, well, he still works for sun
[22:07] <kwwii> but it is all the same, I gues
[22:07] <kwwii> s
[22:07] <ckontros> sure
[22:07] <ckontros> macvr: got it.
[22:07] <macvr> :)
[22:12] <macvr> SiDi: proposing any idea with tray icon wont be accepted ;p
[22:12] <macvr> mpt wont allow
[22:13] <macvr> oops ayatana discussion!
[22:13] <SiDi> macvr: yeh well find me another bug with 32 duplicates
[22:13] <SiDi> the new design is not satisfying at all
[22:14] <ckontros> bug #?
[22:14] <macvr> ckontros: https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/332945?comments=all
[22:15] <macvr> https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/332945
[22:16] <macvr> bots!
[22:23] <ckontros> (rendering latest Breathe updates)
[22:25] <ckontros> "We discussed it publicly at the Ubuntu Developer Summit in December." really doesn't mean anything. As much as I love them, things are mostly decided by then.
[22:25] <SiDi> hey mma
[22:25] <ckontros> yo
[22:25] <SiDi> took me time to notice you
[22:25] <ckontros> ;)
[22:25] <SiDi> ckontros: i was at uds, didnt notice the discussion
[22:25] <SiDi> but i was late
[22:25] <ckontros> Sure.
[22:26] <SiDi> anwyay i think its too drastic
[22:26] <SiDi> its ok for windows users who expect their OS to misbehave them and who are too lazy / scared to do the updates
[22:26] <SiDi> but many average level users took it bad
[22:26]  * ckontros is still sreading the bug.
[22:27] <ckontros> *reading
[22:27] <SiDi> basically they removed the tray icon and replaced it by auto popping update manager
[22:27] <SiDi> i understand why they did it
[22:27] <SiDi> i just cant accept it :|
[22:28]  * ckontros likes the tray icon as well. Thinks <PT knows F-all about UI design. But, Canonical will do what it wants to do.
[22:29] <ckontros> s/<PT/MPT
[22:31] <ckontros> But this is not to say I have a particular opinion about this issue quite yet. ;)
[22:32]  * ckontros keeps reading.
[22:32]  * macvr missed the icon at first but, now got used to it... still not happy about the pop-under :/
[22:33] <SiDi> i usually perform updates weekly unless security updates
[22:33] <SiDi> bandwidth issue... and i do it manually anyway
[22:33] <ckontros> Geeeeeeeeze 420 comments. Wow.
[22:33] <SiDi> but i HATE stuff popping up
[22:33] <macvr> SiDi: i changed the pop-under to daily
[22:33] <SiDi> and 32 dupes, ckontros
[22:33] <ckontros> ouch
[22:33] <SiDi> macvr: i changed to old behaviour
[22:34] <SiDi> never a feature has been so rejected by users
[22:34] <SiDi> and they DONT want to add a GUI-way to revert the change
[22:34] <SiDi> you have to change a gconf key by hand
[22:34] <ckontros> Such is the way of progress. ;)
[22:34] <macvr> SiDi: mot is working on a new Update manager design
[22:34] <macvr> mpt!
[22:34] <ckontros> In a year, this will be forgotten. ;)
[22:35] <macvr> ckontros: yeah! so true
[22:35] <SiDi> ckontros: its a progress if it addresses the aimed issue without pissing off a vast majority of the current userbase :D
[22:35] <macvr> there were atleast 10 comments/day when jaunty was released ... now no one cares ;p
[22:35]  * ckontros also wonders how much of this is driven by mobile?
[22:35] <macvr> except SiDi ;p
[22:36] <ckontros> SiDi: Canonical can do things to piss alot of people off. People will still stay.
[22:36] <ckontros> I will.
[22:37] <SiDi> macvr: i learnt it recently
[22:37] <SiDi> i mostly use xfce as you know :p
[22:37] <ckontros> Actually, I'd switch to Debian. But, I haven't been pushed that hard yet. :P
[22:37] <macvr> ckontros: the great thing about removal of the icon is > we dont think much about updates
[22:37] <macvr> SiDi: dont worry , u'll give up in a few days then
[22:37]  * ckontros still updates by CLI.
[22:37] <SiDi> ckontros: same here. and anyway debian seems to import upstream only the polemic changes
[22:38] <SiDi> macvr: i already gave up for ubuntu
[22:38] <SiDi> i know it'll stay like that unless something clearly preferable appears
[22:38] <macvr> ;p
[22:39] <SiDi> which i'm thinking off, but i'm not a designer at all :p
[22:39] <SiDi> anyway xubuntu doesnt ship it and will probably not ship it for the next years
[22:40] <macvr> SiDi: if they pop-up the update-window it will probably eat up the resources... i noticed that in an old netbook every time i opened the update window
[22:40] <SiDi> its not about that imo
[22:41] <SiDi> i think they just didnt like the design
[22:41] <SiDi> we dont ship PA either for instance
[22:58] <ckontros> [Breathe] Branches updated. https://code.launchpad.net/breathe-icon-set
[23:17] <kwwii> ckontros: do you have breathe in a ppa yet?
[23:17] <kwwii> if not, and you want/need my help I will put it in mine asap
[23:17] <ckontros> kwwii: You haven't been reading your email. ;)
[23:17] <kwwii> I have a bunch of other stuff to do as well
[23:17] <kwwii> lol
[23:18] <kwwii> yeah, I missed a lot of the breathe conversation
[23:18] <kwwii> ahhh
[23:18] <kwwii> yes
[23:18] <kwwii> ok
[23:18] <kwwii> sorry
[23:18] <ckontros> PPA is up and will get updated regularly and should go to REVU next week.
[23:18] <kwwii> did he use my packaging?
[23:19] <ckontros> I added your changes. He made more.
[23:19] <kwwii> cool
[23:19] <ckontros> Mostly license stuff.
[23:19] <kwwii> we should make an "ideal package" like we had in the past
[23:19] <kwwii> perhaps with instructions for change
[23:19] <kwwii> but that is another matter
[23:20] <ckontros> Like a base package for other sets?
[23:20] <kwwii> exactly
[23:20] <ckontros> Would be nice to add to the example-look stuff.
[23:21] <kwwii> not sure how many newbies want to start an icon theme
[23:21] <ckontros> Sure.
[23:21] <kwwii> but it would be good to add somewhere :p
[23:22] <kwwii> although after packaging the humanity theme I must say there is no one-size-fits-all solution
[23:22]  * ckontros notes that doing all the wiki linking is *not* fun but works pretty well. https://wiki.ubuntu.com/Artwork/BreatheIconSet/Icons/Emotes
[23:22] <ckontros> kwwii: What do they do differently?
[23:23] <kwwii> the whole set is svg and icon dirs are layed out differently than normal
[23:23] <kwwii> every size has svgs instead of pngs
[23:23] <ckontros> I wonder why?
[23:23] <ckontros> Oh neat.
[23:24] <ckontros> But maybe a little unnecessary.
[23:24] <kwwii> yeah
[23:24] <kwwii> I wonder why I say yeah all the time...in german is sounds different :p
[23:25] <ckontros> :)
[23:27] <kwwii> at least it makes sense to me
[23:37] <ckontros> macvr: There's 1 issue with the notification-* icons. The script still tries to make a SVG in scalable/ but they are empty. Gotta figure something out for that. For now, I'll remove them manually.
[23:40]  * kwwii heads out for the night...bis morgen!


[02:23] <eloist> Hello
[02:23] <eloist> I have trouble with an upstart script (on ubuntu 12.04lts) that I've been banging my head against and can't seem to figure out
[02:24] <eloist> all I am trying to do is have a script export some env vars before running the actual process, for this i have the following in the script block: ". /root/env.sh"
[02:25] <eloist> trying to start the service, I get the following in my log file: /proc/self/fd/9: 4: .: Can't open /root/env.sh
[02:25] <eloist> file is definitely there though and the permission seem to be right :(
[03:18] <eloist> i believe I found the reason and it's perforce changing the line feeds to windows line feeds
[08:29] <munderwo-work> Hi all. I have a process that is being handled by upstart. I've got it handling SIGTERM signals, and I understand that this is what upstart emits when doing a stop <service>.the problem is that upstart doesnt seem to be waiting for my process to handle the signal and shutdown gracefully. Is there an extra timeout that I need to give upstart to make it wait longer?
[08:31] <munderwo-work> AM I misunderstanding what SIGTERM is supposed to do?
[08:35] <jodh> munderwo-work: upstart will indeed send SIGTERM by default (you can change that using the 'kill signal' stanza). It will then wait for up to 5 seconds by default for the job to end. If it doesn't end, upstart will send SIGKILL. If your job needs longer, specify 'kill timeout'. See init(5) for details of both kill options.
[08:39] <SpamapS> jodh: well, good morning. Been watching the commits to upstart. Lots of weird new stuff .. still no fix for "my pid is stuck"
[08:39] <SpamapS> doh
[14:12] <mangoman> Hello, Upstart noob here. I created a new job but when I try to run it I get "Unknown job".  When I run `initctl list` it doesn't show up there, but it does show up in the /etc/init/ folder.
[14:15] <mangoman> How can I get it to recognize it? Using this script: http://wiki.nginx.org/Upstart
[14:24] <xnox> mangoman: try $ sudo initctl start nginx
[14:27] <mangoman> xnox: still "unknown job"
[14:28] <xnox> mangoman: $ initctl check-config nginx
[14:28] <afournier> hi there !
[14:29] <xnox> mangoman: $ initctl status nginx
[14:29] <xnox> if that all fails, try $ initctl reload-configuration
[14:29] <afournier> is it possible to start a task at the end, ie. the login prompt ?
[14:30] <afournier> i know the question is a bit stupid as upstart is based on events
[14:31] <afournier> but it's not like the prompt login has too much depencies, at the same time when it spawns, upstart is still starting other task, and the prompt is hidden by the output
[14:31] <mangoman> xnox: thank you
[14:32] <afournier> maybe the best solution would be to turn upstart silent, so only the prompt appears, and other tasks can continue to be started, what do you think ?
[14:33] <xnox> afournier: what do you want to achieve?
[14:33] <xnox> afournier: during boot plymouth usually owns the consolse so one should talk to plymouth to display/ask user questions.
[14:34] <afournier> i just want a clean terminal when the machine is starting :)
[14:34] <afournier> plymouth ?
[14:34] <afournier> i dont have plymouth
[14:34] <xnox> =/ then i think your machine is broken horibbly.
[14:34] <afournier> it's a headless device with a serial for interface
[14:34] <xnox> i think you do have plymouth, and maybe not know about it.
[14:34] <xnox> yeah, that's fine.
[14:35] <afournier> is plymouth embedded in upstart ?
[14:35] <xnox> no.
[14:35] <xnox> no, that would be silly.
[14:35] <afournier> then my distro is broken...
[14:35] <xnox> afournier: i guess you should configure upstart to log to files only and not to the console / output.
[14:35] <xnox> afournier: see cookbook linked from the topic.
[14:35] <afournier> xnox: i'll do that, but i am not gonna add plymouth :)
[14:36] <xnox> afournier: =) sure, do what you like ;-)
[14:37] <afournier> until my distro is not horibbly broken :)
[16:49] <xnox> I'm not entirely happy with upstart-udev-bridge =/
[16:49]  * xnox hoped for some better way to encode matching variables
[16:55] <xnox> hmm... i must "exit 0" from pre-start script?
[17:06] <xnox> jodh: in the usb-creator branch, there is a scary upstart job for you to review =))))
[17:07] <xnox> it's a poor-man's user session job.
[20:41] <JanC> afournier: you don't need plymouth to use upstart, but it might still be interesting to look at Ubuntu's default upstart job configs to see how it handles that sort of things
[20:42] <JanC> (oh, and plymouth can do text-mode boot, it's not necessarily graphical...)


[09:40] <JamesTait> Good morning all; happy Parfait Day! :-D
[14:37] <FunnyLookinHat> Hey - word on the street is that you guys are in control of the application lens development going on right now that will replace the need for Software Center.  Do any of you have any links to blueprints or more information on this?  Just trying to get my head wrapped around it early on
[14:41] <davmor2> FunnyLookinHat: I have a feeling that it is a holiday in Argentina where most of the devs are based today. dobey is this something you can help with at all or is it one for Argentinians?
[15:02] <dobey> FunnyLookinHat: i don't think there are any blueprints for the changes to the scope, no
[15:03] <FunnyLookinHat> Oh ok - thanks :)
[15:11] <dobey> FunnyLookinHat: what were you looking to know?
[15:16] <FunnyLookinHat> dobey, If the App lens was ( more or less ) in the form that it would be when Software Center goes away
[15:16] <FunnyLookinHat> i.e. is it safe to say that, at this point, if I didn't use Software center and only the App lens, would I be evaluating the solution that's coming down the pipeline
[15:17] <dobey> software-center isn't going away in 14.04
[15:18] <dobey> we'll be adding app purchasing to the click scope in 14.04 though, so people will be able to sell their click packaged apps on phone/tablet
[15:35] <FunnyLookinHat> Right - but after 14.04 it's going away, yes?
[15:35] <FunnyLookinHat> ( Going off of this doc ) https://docs.google.com/spreadsheet/ccc?key=0AiT4gOXSkmapdGdFejk0MjFydUlNMDVoMXNRdGdkbFE#gid=1
[15:37] <dobey> well, there are 2 whole years before 16.04. it will likely go away before then, but we don't have an exact timeline for removing it at the moment
[15:38] <FunnyLookinHat> Ah ok - thanks dobey !
[15:39] <dobey> it won't be going away before there is either a way to purchase/install debs directly from the dash, or everything becomes click packages
[15:41] <dobey> the ubuntuone packages listed in that doc are also very unlikely to be ported to python 3 ever


[04:25] <manchicken> Hey all, I've got a problem where libcunit1 builds and links, but when I run it gives me an error code 20 with error string "No Error." However, if I build a fresh copy of CUnit from SF directly, things work just fine. What is the best way to report this issue, keeping in mind that I'm willing to help if nobody is currently interested in maintaining that package?
[04:30] <ScottK> manchicken: Did you build the new version as a debian package or from source directly?
[04:30] <RAOF> manchicken: A bug on launchpad.net would be the most appropriate way to report the issue; I'd also check the bugs in Debian.
[04:31] <manchicken> ScottK: Directly from source.
[04:31] <manchicken> ScottK: That's how I built it on the Mac when I was testing this code there, too.
[04:33] <ScottK> Next thing I'd do then is update the package to build the new upstream and see if the .deb you get when you build it works or not.
[04:33] <ScottK> That should tell you then if it's a packaging issue or a new upstream issue.
[04:34] <manchicken> Well, what I'm thinking of doing is just whipping up a quick test program, testing it with the source version to make sure it works, and then try it with the main package, and then include that source file in the bug report if it fails.
[04:34] <ScottK> A reduced test case is always good.
[04:35] <manchicken> Yeah, and an automated test seems strangely appropriate as a way of demonstrating a bug in an automated test framework.
[04:36] <ScottK> It's automated tests all the way down.
[04:39] <manchicken> I like automated tests.
[04:59] <pitti> hallyn: hey
[04:59] <pitti> good morning
[06:40] <dholbach> good morning
[08:33] <seb128> doko_, hey, did you debug the gtk/gcc/arm issue further since yesterday? (don't want to dup work)
[09:08] <m4n1sh> ev: can you please have a look at #1192777 and  #1192778 when free
[09:29] <zyga> hi
[09:29] <zyga> I'm trying to understand why python3-requests is not in saucy
[09:29] <zyga> was it removed for any reason?
[09:30] <zyga> and if so, is there a record of such removals?
[09:30] <zyga> http://packages.ubuntu.com/search?suite=all&section=all&arch=any&keywords=python-requests&searchon=names
[09:30] <zyga> this shows that python3-requests was in precise, quantal and raring
[09:30] <zyga> and up until recently I recall it was in saucy as well
[09:30] <cjwatson> https://launchpad.net/ubuntu/saucy/i386/python3-requests
[09:30] <zyga> looking at debian I can see the package is there
[09:31] <cjwatson> It's there
[09:31] <cjwatson> Don't trust packages.ubuntu.com
[09:31] <zyga> oh
[09:31] <zyga> too bad
[09:31] <zyga> btw, debian has a more recent version
[09:31] <zyga> and we found that the version in saucy is broken when you are using a http proxy
[09:31] <cjwatson> BTW, we're in Debian Import Freeze
[09:31] <zyga> will the package sync again?
[09:32] <zyga> oh
[09:32] <cjwatson> Or we were until that was due to be undone this morning :)
[09:32] <cjwatson> I just haven't got round to preflight checks before turning auto-sync back on
[09:32] <zyga> ah
[09:32] <zyga> thanks
[09:32] <zyga> so it should re-sync again?
[09:32] <cjwatson> Yes
[09:32] <zyga> cjwatson: btw, is there anything I could do to make packages.ubuntu.com reliable again?
[09:32] <zyga> I really like that service
[09:33] <cjwatson> Dunno, it's community-maintained
[09:33] <cjwatson> I think Rhonda runs it?
[09:33] <cjwatson> May be waiting for an IS deployment of some kind, I don't know; feel free to chase up
[09:35] <zyga> ok, thanks
[09:42] <ev> mpt: when you have a chance, can you help me understand how we calculate the "rate for matching machines" in "what's unusual about this problem?"
[09:42] <ev> In the case of evaluating whether the architecture is relevant, is it:
[09:42] <ev> Take the reports for i386. Filter down to reports for the current day. Get the systems responsible for each of these reports. Divide the number of reports by the number of unique systems. Do the same for each other day, then average out across all days.
[09:42] <ev> Compare the average value for i386 against the value for amd64 and armhf. If i386 is significantly greater, highlight it.
[09:43] <ev> Apologies, I know we discussed this before, but I'm struggling a bit understanding how we get the error rate for a subset of instances in the bucket.
[10:01] <cjwatson> Daviey,jamespage: copies of public source to archives owned by private teams should be fully safe now; the fix for /builders visibility is deployed
[10:11] <doko> \O/
[10:22] <tvoss> cjohnston, hey there. We are running into static ctor/dtor issues right now. Could you give us a hand?
[10:22] <tvoss> cjwatson, ^ that was meant for you :)
[10:22] <tvoss> cjohnston, sorry for the noise
[10:23] <cjwatson> doko: ^- Could you help tvoss?  You're probably better at this than I am
[10:25] <doko> cjwatson, tvoss: vacation days today and tomorrow, so won't have much time
[10:25] <Daviey> cjwatson: Super!  Thanks :)
[10:25] <tvoss> doko, ack, here is the issue in case you are bored during vacation :) http://pastebin.ubuntu.com/5798108/
[10:26] <doko> tvoss, has this something to do with the gmock build failure?
[10:26] <tvoss> doko, nope, mir carries its own in-tree version of gmock for historic reasons
[10:29] <doko> tvoss, just saucy, or raring as well?
[10:30] <tvoss> doko, just saucy as far as I can tell
[10:48] <jamespage> cjwatson, great! - thanks for fixing that up
[11:00] <ev> pitti: if and when you have a minute, I've got a small change to our apport packaging. It enables core dumps of setuid processes, now that kees says it's okay: https://code.launchpad.net/~ev/apport/raring-suid_dumpable/+merge/171270
[11:13] <pitti> hey ev
[11:14] <pitti> ev: hm, doesn't that also affect normal core dumps?
[11:14] <pitti> ev: (and I guess that's for saucy then)
[11:15] <ev> oh whoops
[11:15] <ev> yes, I'll apply it to saucy as well :)
[11:15] <ev> pitti: affect normal core dumps how? 0 is the default, as I understand it.
[11:15] <pitti> ev: ah, =2 is only applied for pipes
[11:16] <pitti> ev: so, I haven't checked whether a suid program actually ends up being owned by the target user, but if that happens, that looks fine to me
[11:16] <pitti> nice, thanks!
[11:17] <xnox> ubiquity wrapper with pexec works: if .desktop specifies "Terminal=true", or if ubiquity wrapped with an extra shell script around it.
[11:20] <cjwatson> jibel: libreoffice autopkgtest failures are "build slave doesn't have enough disk space", aren't they?
[11:26] <cjwatson> schedule amended to move DIF to week 13; mail sent to ubuntu-release@; auto-sync running
[11:27] <pitti> yay
[11:34] <cjwatson> [Updating] requests (1.2.0-2 [Ubuntu] < 1.2.3-1 [Debian])
[11:34] <cjwatson> zyga: ^-
[11:36] <zyga> cjwatson: awesome, thanks!
[11:42] <cjwatson> automake1.11 binary is heading back into the archive, for whoever it was who was asking about that
[11:45] <pitti> cjwatson: ISTR it was seb128
[11:46] <seb128> cjwatson, pitti: yeah, it was me, thanks
[12:06] <chrisccoulson> this build failed earlier, any idea who restarted it? https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+build/4742188#
[12:06] <chrisccoulson> i hadn't had a chance to look at the old build log....
[12:07] <cjwatson> I did, because it failed due to a broken builder
[12:07] <jibel> cjwatson, yes, I increased disk size already but it's clearly still not enough. I'll have to make a specific setup for LO to run it on a bigger partition.
[12:07] <cjwatson> heka chrootwaited its next eight builds after that, and the end of the chromium-browser log was all invalid-character-in-source-file stuff
[12:07] <chrisccoulson> cjwatson, ah, thanks
[12:08] <cjwatson> jibel: Right, thanks.  I've forced proposed-migration to ignore (that version of) libreoffice for the time being
[12:08] <cjwatson> chrisccoulson: Now, unfortunately it got retried on heka, albeit after it was nominally fixed ... hopefully it won't eat it again
[12:08] <chrisccoulson> cjwatson, yeah, fingers crossed...
[12:11] <xnox> jibel: adt keyword: needs-libreoffice-amounts-of-disk-space ?! =)
[12:11] <cjwatson> chrisccoulson: https://launchpadlibrarian.net/143317414/buildlog_ubuntu-precise-armhf.chromium-browser_28.0.1500.52-0ubuntu<IP_ADDRESS>_FAILEDTOBUILD.txt.gz is still accessible if you have the URL, FWIW
[12:12] <cjwatson> So you can double-check me, but complaints about "WebGesttrdEvemt" are a pretty good sign of an insane builder
[12:12] <cjwatson> :)
[12:14] <tvoss> doko, in case you are around: seems like saucy already has the binutils and gcc version you were mentioning: http://pastebin.ubuntu.com/5798341/
[12:14] <tvoss> doko, or do you want me to force the ppa version?
[12:16] <smb> infinity, If you got not too much liquid related (or other issues), is there a possibility that you may get bored enough to look at the crash backports?
[12:45] <tkamppeter> OdyX, hi
[12:46] <OdyX> tkamppeter: hoy
[12:51] <ev> pitti: *nods* I'll confirm it does
[12:51] <ev> thanks
[12:57] <hallyn> pitti: hey
[13:03] <tkamppeter> OdyX, I would like to change the pstops priority again so that PostScript jobs for PostScript printers go through pstops instead of pstopdf+pdftopdf+pdftops. Do you know why "make test" fails then? Do you have an idea why the test fails and how one could fix it? Or should I change the cost factors after "make test" and before "make install" in the package build?
[13:06] <tkamppeter> OdyX, see also https://bugs.linuxfoundation.org/show_bug.cgi?id=1138
[13:07] <OdyX> tkamppeter: I'm all for re-enabling the ps-to-ps, but we have to find a sane way to have the tests working; and having them run in a setup which is not what we ship is not something I'd be happy with.
[13:12] <jdstrand> tyhicks: hey, so I uploaded my apparmor packages to the ppa
[13:12]  * tyhicks looks
[13:13] <jdstrand> tyhicks: I'll be uploading another set to the archive in a few minutes (without dbus patches)
[13:13] <jdstrand> tyhicks: what is the timeframe for uploading dbus to saucy?
[13:13] <dholbach> cjwatson, thanks!
[13:14] <jdstrand> (and by 'to the archive', I of course meant to saucy)
[13:14] <tyhicks> jdstrand: it is hard to say with the policy language still up in the air
[13:14] <tyhicks> jdstrand: there's not much left to do, but we do have to settle that first
[13:15] <OdyX> tkamppeter: see Debian #712237
[13:15] <jdstrand> tyhicks: right. I thought we said that it didn't need to be finalized. ie, when sbeattie gets back, we can finalize it but in the meantime, upload. or are you saying we are still waiting on jj for the ipc implications? (I am a bit behind on email right this second)
[13:16] <tyhicks> jdstrand: yes, waiting on jj's input on future ipc implications
[13:17] <jdstrand> tyhicks: I see. ok. my thoughts are that this is talking too long and we need to get the code out there-- the only ones that will be affected by the policy changes is us for the most part in the short term. when the language is finalized and uploaded, then we can blog
[13:17] <jdstrand> s/talking/taking/
[13:17] <pitti> hey hallyn
[13:17] <jdstrand> tyhicks: that came out wrong. the dbus syntax iterations are taking a long time, which conflicts with us getting things into the archive, on the images, etc
[13:18] <jdstrand> tyhicks: and the code exercised by others
[13:18] <tyhicks> jdstrand: so you're suggesting that we push what we have now into the archive something this week?
[13:19] <jdstrand> tyhicks: anyhoo-- this isn't anything against the good work you guys are doing, it is just taking longer than we planned
[13:19] <tyhicks> s/something/sometime/
[13:19]  * jdstrand checks something
[13:20] <tyhicks> jdstrand: should uploading the userspace changes to dbus and apparmor depend on the kernel changes being in place?
[13:21] <hallyn> pitti: did you want to talk about something?
[13:21] <pitti> hallyn: not from my side, but you said "hey" half an hour ago
[13:21] <tyhicks> jdstrand: to allow people to test the code, we'll need the aa3.0 patches in the saucy kernel
[13:21] <jdstrand> tyhicks: well, we have a monthly goal to have the syntax finalized. that won't be met unfortunately. I'd like for us to work through the ipc implications and then upload something based on that
[13:22] <jdstrand> tyhicks: and that shouldn't be blocked on sbeattie's vacation
[13:22] <jdstrand> tyhicks: but, it probably doesn't matter, sbeattie is back next week
[13:23] <jdstrand> tyhicks: re kernel patches> jj sent out pull requests for the phablet kernels a few minutes ago
[13:24] <hallyn> pitti: that was bc you'd said hey about 8 hours ago :)  probably bc I pinged you yesterday - ttyl :)
[13:24] <jdstrand> tyhicks: the desktop kernel we could keep waiting on
[13:24] <tyhicks> jdstrand: and sbeattie did respond to the thread - I don't think that we're blocked by his vacation at all
[13:25] <jdstrand> tyhicks: ok, it sounds like we just need to have the ipc implication discussion, then we can make the cahnges and upload?
[13:25] <pitti> hallyn: heh, fun; so, enjoy your day :)
[13:25] <jdstrand> tyhicks: then refine as needed
[13:25] <jdstrand> tyhicks: is that accurate?
[13:25] <tyhicks> jdstrand: yes, exactly
[13:26] <jdstrand> tyhicks: ok. I think some testing I did yesterday showed this to be the case, but if there are dbus rules present in the policy and we boot into a non-v3 kernel, everything works like it does now (ie, the dbus rules are effectively ignored). correct?
[13:27] <tyhicks> jdstrand: yes, dbus-daemon detects that /sys/kernel/security/apparmor/features/dbus/ does not exist and does not try to enforce any apparmor mediation
[13:28] <jdstrand> tyhicks: ok, perfect. so, actually, have phablet kernels with v3 and desktop kernels without exercises different code paths nicely
[13:29] <tyhicks> jdstrand: yes, both paths will be exercised
[13:30] <jdstrand> tyhicks: are you comfortable with the path forward then?
[13:30] <tyhicks> jdstrand: yes, it is clear
[13:32] <mpt> Is it possible for the PC/phone to know the battery charge level of a connected Bluetooth headset? (cyphermox?)
[13:38] <jdstrand> tyhicks: awesome, thanks! :)
[13:40] <tkamppeter> OdyX, perhaps we should somehow change the cost factors in the cups-filters package to get the desired workflows?
[13:41] <cyphermox> mpt: in theory yes, I've seen it :)
[13:41] <mpt> excellent
[13:42] <cyphermox> mpt: I'll look up the details
[13:44] <OdyX> tkamppeter: I don't oppose that, certainly. What I want is that the cups IPP tests run with the cost factors that are shipped in the packages.
[13:50] <mpt> cyphermox, https://wiki.ubuntu.com/Power#Indicator
[14:02] <mpt> ev, "average out across all days" will result in very-nearly-zero rates for every error that started less than a year ago. Probably you want to collect only the past week or something like that.
[14:03] <ev> ah yes, but generally does that look like the right algorithm?
[14:04] <mpt> I'll rewrite it without looking and see if I get the same result...
[14:06] <mpt> Architecture is most important if absolute_value(rate(some_architecture) - rate(others)) > any_other_difference
[14:08] <mpt> ev, i.e. for a given period, errors(architecture)/machines(architecture) - errors(all_other_architectures)/machines(all_other_architectures)
[14:10] <ev> mpt: was about to pastebin some code I already wrote to that effect, but immediately realised it looks like really bad Perl. :-/
[14:10] <ev> thank you though
[14:10] <mpt> Don't worry, I wouldn't be able to tell the difference between really bad Perl and really good Perl
[14:11] <ScottK> No one can, it's write only.
[14:11] <ev> amazing
[14:12] <mdeslaur> there's really good Perl?
[14:12] <mpt> Thanks ScottK, I thought it would take at least two minutes for someone to take that and run with it. ;-)
[14:12] <ScottK> There is actually.
[14:12] <ScottK> It's just rare.
[14:13] <mdeslaur> hehe :P
[14:22] <maxiaojun> hi, i just note that Ubuntu's 'chmsee' package struck at version 1.3.0-2ubuntu2
[14:22] <maxiaojun> can we re-sync with Debian? Debian has latest upstream version in sid
[14:23] <cjwatson> It's presumptively up to the last uploader (chrisccoulson) to either do it or delegate it
[14:23] <seb128> maxiaojun, we sure can, if you want to work on it please do and subscribe sponsors?
[14:23] <maxiaojun> seb128, what do you mean by "please do"?
[14:24] <seb128> maxiaojun, if you want to update the package/rebase it on the current debian version that would be welcome help
[14:25] <maxiaojun> i still don't understand what exactly should i do. file a bug? link a branch?
[14:26] <mitya57> maxiaojun: http://developer.ubuntu.com/packaging/html/udd-merging.html
[14:27] <jbicha> chmsee is a difficult package as it was patched to build with webkit instead of xulrunner
[14:35] <maxiaojun> are the patches still needed? as the upstream is keeping up with Firefox change (though i think they should set slight larger MaxVersion) while webkit branch seems unmaintained
[15:21] <pitti> ev: splendid, thanks!
[15:32] <ev> pitti: sure thing. Tracking in https://bugs.launchpad.net/ubuntu/raring/+source/apport/+bug/1194541
[15:37] <pitti> ev: ah, the saucy one didn't have that bug ref, closing manually
[15:40] <ev> thanks
[15:43] <jdstrand> jodh: hi! I can't remember, what was the eta for upstart/apparmor with mdeslaur's distro patch?
[15:45] <jodh> jdstrand: plan was "by tomorrow" as of last week, but we've had a nasty merge to perform which has slowed things rather I'm afraid. That merge is now done so once I've got an ack on a couple of other upstart branches we can get a new upstart release out.
[15:49] <jdstrand> jodh: ack, thanks for the update and your work on this :)
[17:08] <ricotz> mdeslaur, hi :), could take a look at http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0037 which would mean to get at least raptor2 2.0.7-1 into precise
[17:10] <mdeslaur> ricotz: we fixed that already: http://www.ubuntu.com/usn/usn-1480-1/
[17:11] <ricotz> mdeslaur, ok, this is about libraptor2-0 too
[17:12] <ricotz> which librdf0 uses
[17:12] <mdeslaur> ricotz: ah! I see, ok, I'll reopen the CVE and add raptor2 to it. Thanks!
[17:13] <ricotz> mdeslaur, thanks
[18:56] <Spee_Der> G'day folks....
[19:13] <barry> @pilot in
[19:50] <jbicha> barry: since you're piloting, you saw my 2 mp's for xdiagnose, right?
[19:51] <barry> jbicha: nope.  they don't show up on the sponsoring page, but send me the urls and i'll take a look
[19:52] <jbicha> https://code.launchpad.net/~jbicha/xdiagnose/fix-installing-icon-and-tweak-desktop/+merge/170927
[19:52] <jbicha> https://code.launchpad.net/~jbicha/xdiagnose/mark-apply-close-translatable/+merge/170928
[19:54] <barry> jbicha: i don't want to step on bryce's toes (his review claim is pending).  but maybe that was a few days ago
[19:54] <barry> and he's on to other things?
[19:55] <jbicha> never mind, I saw a B name and mixed you two up
[19:55] <barry> jbicha: np
[19:55]  * barry will leave it to bryce then
[19:56] <barry> jbicha: but it looks like you do have a few other things in the queue, so maybe it's your luck day :)
[20:02] <xnox> what was the story around GL and armhf? Or any pointers about fixing https://launchpadlibrarian.net/141550690/buildlog_ubuntu-saucy-armhf.qtiplot_<IP_ADDRESS>-4ubuntu1_FAILEDTOBUILD.txt.gz
[20:02] <xnox> as far as I can tell glu.h does exist during build ...
[20:06] <slangasek> xnox: GL on armhf should be EGL, but that shouldn't matter; I don't see libglu1-mesa-dev being installed as part of that build log?
[20:06] <slangasek> you need an additional -dev package for glu vs. gl
[20:07] <xnox> ok, thanks =)
[20:12] <barry> robru, kenvandine okay, that was beautiful!  i was just using the friends app to post a new message.  i got as far as "say hell" and it crashed :)
[20:12] <robru> barry, nuh uh!! nyanyanyanyanyanyanya i can't hear you!!!!
[20:12] <slangasek> barry: you have the special version that's limited to 14 chars
[20:12] <barry> robru: say hell!
[20:13]  * barry has a new motto for today
[20:13] <robru> barry, yeah, I'm getting lots of crasher bug reports for friends-app lately. I can't reproduce it, and i don't know much about Qml to fix it. I think kenvandine needs to step in here...
[20:13] <kenvandine> humm
[20:14] <kenvandine> not much going on there to cause it to crash
[20:14] <kenvandine> i've seen it crash on startup if you don't have an account enabled
[20:15] <kenvandine> but while you're typing all it does it change the counter
[20:15] <kenvandine> barry, got a crash file?
[20:16] <robru> kenvandine, also: https://bugs.launchpad.net/ubuntu/+source/friends-app/+bug/1176498 read the comments for two *different* crashes
[20:17] <barry> kenvandine: i just ubuntu-bugged it
[20:18]  * Laney wanted to congratulate barry in #debian-devel but he's not there so couldn't
[20:18] <Laney> well done ;-)
[20:21] <barry> Laney: thanks!
[20:23] <barry> kenvandine: lp: #1194638
[20:30] <slangasek> sw33t, the Foundations team has K DDs and can launch its own GRs now \o/
[20:30] <slangasek> barry: grats ;)
[20:31] <barry> slangasek: \o/
[20:31] <xnox> slangasek: right, I did a build with libglu1-mesa-dev before, and armhf FTBFS with this now http://paste.ubuntu.com/5799672/ which in turn means one shouldn't include both GLES2 and GL =/
[20:32] <kenvandine> barry, thx
[20:32] <slangasek> xnox: it's true that it should not... is glu GL-only?
[20:34] <xnox> slangasek: not sure. but I'm now discovering bug 707794
[20:35]  * slangasek nods
[20:35] <kenvandine> barry, you filed that against friends, is there a crash file for friends-app?
[20:36] <barry> kenvandine: oops, sec
[20:38] <xnox> slangasek: looks like it was added for fit FTBFS with qt4.8 hmmm.....
[20:38] <xnox> https://bugs.launchpad.net/ubuntu/+source/qtiplot/+bug/925652
[20:44] <barry> kenvandine: oops, there was a crash reporter window buried.  i'll use that to report the bug on friends-app
[20:45] <cjwatson> barry: ah, excellent, good to see advocatees make it through :)
[20:49] <kenvandine> barry, thanks!
[20:49] <tkamppeter> OdyX, I have changed the cost factors of cups-filters, now setting the cost factor of pstops in CUPS is not necessary any more. See current BZR state of cups-filters, rev. 7072. https://bugs.linuxfoundation.org/show_bug.cgi?id=1138
[20:51] <barry> kenvandine: lp: #1194646
[21:02]  * xnox finds https://code.google.com/p/glues/
[21:12] <jcastro> hey slangasek
[21:12] <jcastro> http://blog.utlemming.org/2013/06/psa-ubuntu-server-1104-natty-archives.html
[21:13] <jcastro> If I wanted to file a bug like "we shouldn't break people's servers just because a distro is EOL" where should I file it?
[21:13] <jcastro> or is this something I can bring up on the devel list?
[21:18] <slangasek> jcastro: maybe -devel; it's not really a bug in the OS that we don't have infinite space to keep EOLed releases on the mirrors forever, and it's not clear to me we should actually be putting a lot of effort into making it a more pleasant experience to continue running a release with no security support
[21:19] <jcastro> sure, I understand that.
[21:19] <jcastro> I would think sharing slow bandwidth with all the other bad kids would be encouragement enough
[21:20] <infinity> jcastro: How do you propose we not break things?
[21:20] <jcastro> or perhaps spit out a warning via apt or something instead of just 404'ing people
[21:20] <jcastro> infinity: I would say something like "this distro is EOL, we've moved you to slow mirrors no one cares about, but this is the least of your problems, please see this wiki page"
[21:21] <jcastro> right now we just 404 them
[21:21] <infinity> jcastro: Automatically editing people's sources.lists just because they start 404ing would be fraught with peril.
[21:21] <jcastro> maybe we can do a motd or something?
[21:21] <infinity> jcastro: In fact, automatically doing it at any point (even based on a more clever meta-release hint) seems bad.
[21:22] <slangasek> we already motd about new upgrades available, right?
[21:22] <infinity> jcastro: We already do an motd telling them there are new releases to upgrade to... Which they ignored for two years.
[21:22] <slangasek> s/upgrades/releases/
[21:22] <slangasek> infinity: sure, but admins are going to "if it ain't broke I'm not upgrading"
[21:22] <slangasek> which is reasonable
[21:22] <jcastro> yeah but there's a difference between "new version, I don't care, this server works" and "if you don't listen apt will break."
[21:22] <slangasek> and I think it would be a worthwhile improvement to have the motd have another check and announce "you're EOL"
[21:23] <infinity> Yeah, we could add an motd hook to yell at you if you're running an EOL release.
[21:23] <infinity> Well, it would be in the same upgrade-check hook.
[21:23] <infinity> Since the same info comes from the same place.
[21:23] <jcastro> right so I think it's probably better to not spend the cost on moving people to old-releases, but maybe instead being more in your face when you're EOL
[21:23] <slangasek> should arguably be made part of the existing ubuntu-release-upgrader-core hook
[21:23] <jcastro> infinity: ok so I can just do a wishlist on the motd package?
[21:24] <infinity> slangasek: I think I just said that. :)
[21:25] <infinity> So, check-new-release would need to grow an option (or a sister binary) for check-eol.
[21:25] <infinity> And the rest is trivial.
[21:25] <jcastro> ubuntu-release-upgrader-core is the package I want?
[21:25] <infinity> jcastro: Wishlist on ubuntu-release-upgrader with proposed tasks for some stables as well.
[21:25] <slangasek> yep
[21:26] <slangasek> actually
[21:26] <slangasek> /usr/lib/ubuntu-release-upgrader/check-new-release, line 116
[21:26] <jcastro> thanks fellas
[21:26] <slangasek>   if m.no_longer_supported is not None:
[21:26] <slangasek>     url = "http://www.ubuntu.com/releaseendoflife"
[21:26] <slangasek>     print(_("Your Ubuntu release is not supported anymore."))
[21:26] <slangasek>     print(_("For upgrade information, please visit:\n"
[21:26] <slangasek>             "%(url)s\n") % { 'url' : url })
[21:26] <infinity> Err, oh.
[21:26] <infinity> Indeed.
[21:26] <infinity> jcastro: So, it already claims to do this. :P
[21:27] <slangasek> jcastro: already fixed; if these users were running a newer release they wouldn't have had this problem!

[21:28] <slangasek> though actually, the changelog implies this code should've been in natty
[21:28] <infinity> And it may well be.  It could fail to trigger due to the stale lock bug.
[21:28] <slangasek> the which?
[21:29] <infinity> The bug wherein, once you've been informed of an upgrade, that snippet never runs again.  Ever.
[21:29] <infinity> (This is fixed in precise and onward in SRUs, I believe...)
[21:29] <slangasek> ah
[21:30] <jcastro> oh ok
[21:30] <jcastro> so tldr, it's fixed in newer releases
[21:30] <slangasek> yes
[21:30] <jcastro> it would then make sense why ben sees people complaining about natty, but not q
[21:30] <infinity> Probably.  Would be worth a bit of testing by artificially EOLing precise locally or something.
[21:31] <infinity> jcastro: Q isn't EOL, why would they complain about it?
[21:31] <jcastro> infinity: because I suck at arithmetic
[21:31] <jcastro> infinity: so theoretically, when Q EOLs, we shouldn't see this as much as with Natty
[21:31] <infinity> oneiric is EOL, but we've not removed it from the mirrors due to OEM SLAs.
[21:32] <infinity> jcastro: Well, even if the release-upgrader/motd bits are all working better now, I wouldn't bet we'd see people complain less. :P
[21:32]  * cjwatson awards software-properties the title of "most frustrating autopkgtest failures"
[21:32] <cjwatson> so ... close ...
[21:32] <infinity> jcastro: But I don't think forcefully mangling people's apt sources without warning is a particularly friendly thing to do either, so...
[21:33] <infinity> jcastro: We're going to get people whining about the 404s, and we always have had.
[21:33] <jcastro> yeah I get that
[21:33] <infinity> (Yeah, I'm a pessimist)
[21:34] <infinity> Anyhow, given that the lock bug wasn't actually about fixing THIS, I doubt anyone's tested the EOL case specifically.  Probably worth a poke to see if it works as expected for future releases.
[21:34] <jcastro> XP is 11 years old and it's mirrors don't 404. They gracefully just stop updating it
[21:34] <infinity> Shame it's too late to SRU back to oneiric.
[21:34] <jcastro> "gracefully" is up to interpretation there.
[21:35] <infinity> jcastro: If I could think of a reliable way to auto-rewrite people to old-releases, that would get us the same "doesn't 404, but doesn't update" thing.
[21:35] <jcastro> I wonder if just a url rewrite would do the trick?
[21:36] <slangasek> that only helps for mirrors we control
[21:36] <sarnold> jcastro: despite appearances, MS says XP is supported for another 10 months or so..
[21:36] <infinity> jcastro: But given that we specifically allow (and even encourage) people to mangle sources.list to their heart's content, it's not the easiest thing in the world to do sanely.  release-upgrader tries (and when it fails, just gives up and writes a new one), but that's interactive, and it warns you.
[21:36]  * jcastro nods
[21:37] <jcastro> I think the motd warning does the job
[21:37] <jcastro> I didn't know we had fixed that
[21:37] <dobey> infinity: make an apt archive with the release name "eol" that has empty Packages/Sources/etc… and use mod_rewrite to just send dead releases to that?
[21:37] <infinity> dobey: I'm not sure how that solves... Anything.
[21:38] <infinity> dobey: Other than "ugliness", empty Packages files and 404s are the same thing.  Can't install software anymore.
[21:38] <jcastro> we should totally just turn the tty blood red with white text when something EOLs
[21:38] <infinity> jcastro: Then they'll just think they accidentally launched a NetWare installer.
[21:38] <infinity> (Okay, as if any kid in IT today remembers NetWare...)
[21:38] <slangasek> U+1258930 LATIN SMALL LETTER I DRIPPING WITH BLOOD
[21:39] <dobey> wouldn't that be U+666?
[21:39] <infinity> dobey: Anyhow, if mod_rewrite tricks worked (as in, if we had control of the server side), we'd just rewrite people to old-releases.
[21:39] <infinity> dobey: Which we clearly can't, because mirrors.
[21:40] <dobey> well. it's ok. they just all go on askubuntu and ask jcastro to fix it for them anyway :)
[21:41] <jcastro> only 23k views on the question
[21:41] <infinity> I'm okay with that solution.
[21:41] <jcastro> which is neither a huge problem nor a trivial problem
[21:41] <cjwatson> Auto-rewrite: be careful of people within corporate networks where they can't talk to old-releases.
[21:42] <cjwatson> (Just one reason forceful mangling would be scary.)
[21:44] <jcastro> infinity: in better news, I've seen the "problem with MergeList" problems nearly disappear
[21:44] <jcastro> wrt. apt
[21:44] <infinity> jcastro: The one that was the hard limit on combined list sizes?
[21:45] <jcastro> i think part of it was when you connected to a guest wifi with like a disclaimer page apt would append that text to a file or something crazy like that
[21:45] <jcastro> so basically everyone who was in a hotel would hit the problem
[21:46] <infinity> Daviey: Say, weren't your minions meant to be attending to MIRs for all of puppets new deps?  That seems to have been not happening for... Months.
[21:46] <infinity> jcastro: Ahh, yeah, I think the captive portal case is mostly catered for, except for a few corner cases.
[21:46] <infinity> jcastro: It's still not completely fool proof.  We keep finding better fools.
[21:55] <Daviey> infinity: err, yeah - we'll look at that this week.
[22:01] <ScottK> So this autopackagetest block for britney blocks other packages too?
[22:01] <ScottK> I'm looking at pykde4 and it's apparently blocked by an apport autopackagetest.
[22:02] <cjwatson> Reverse dependencies are checked as well as the packages themselves
[22:02] <cjwatson> However it's currently buggy and forgets about failures, so ...
[22:02] <ScottK> pykde4 in the release pocket is currently broken.
[22:02] <cjwatson> You know about force-autopkgtest, right? :P
[22:03] <cjwatson> I put that there precisely so people wouldn't need to complain
[22:03]  * ScottK tries.
[22:03] <cjwatson> That said, by the time you've done that the test might well have completed
[22:03] <cjwatson> (Note that the thing to force-autopkgtest is the tested package, not the triggering package)
[22:05] <ScottK> So in this case pykde4?
[22:06] <cjwatson> No, the tested package is apport/2.10.2-0ubuntu2, the triggering package is pykde4/4:4.10.80-0ubuntu1
[22:06] <ScottK> It is slightly frustrating to set something up, have to go offline for ~8 hours for $work and then come back to find yet another roadblock.
[22:06] <cjwatson> IOW the point is to test that the new pykde4 doesn't break apport
[22:06] <cjwatson> But it's possible to say "this autopkgtest is funted right now, ignore its failure"
[22:07] <ScottK> What's "I don't care, migrate it."
[22:07] <ScottK> I guarantee you it's broken in the release pocket right now.
[22:07] <ScottK> (due to a new sip4 I messed up in Debian and it autosynced)
[22:07] <cjwatson> "force-autopkgtest apport/2.10.2-0ubuntu2, the triggering package is pykde4/4:4.10.80-0ubuntu1
[22:07] <cjwatson> err
[22:08] <cjwatson> "force-autopkgtest apport/2.10.2-0ubuntu2" will make it eligible.  But you really really need to let update_output look at things beyond that.
[22:08] <cjwatson> So how did sip4 get in and break it?
[22:08] <ScottK> It should go if autopackagetest isn't stopping it.
[22:08] <ScottK> I missed an API version change when I packaged it in Debian.
[22:09] <cjwatson> Ah, it's been broken for a week then?
[22:09] <xnox> plus added unfortunate timing in a rebuild from me to add autopkgtest.
[22:09] <xnox> yeah, for quite a while now.
[22:09] <ScottK> Not to mention pykde4 from 4.10.80 hit the archive about one publisher cycle before it would have migrated.
[22:10] <ScottK> Then it was blocked on the kde4libs/armhf mess.
[22:10] <cjwatson> I'm not wild about using maximum force to shove it in then.  Use minimum force so that it actually happens right this time.
[22:11] <cjwatson> But as you say it does look as though force-autopkgtest should be enough.
[22:11] <ScottK> OK.  Fixed.
[22:11] <Laney> are there still bugs around tests being left at RUNNING?
[22:12] <ScottK> BTW, this particular issue is proving harder to fix in Ubuntu than Debian.
[22:12] <cjwatson> I saw a bunch of armhf-only migrations while kde4libs/armhf was broken that went in suspiciously easily.  I'm still concerned that those will be left uninstallable even after the dust settled.
[22:12] <cjwatson> Laney: I think that's fixed
[22:12] <cjwatson> The bug I know of at the moment is that failure states are forgotten after the run that initially collects them
[22:12] <Laney> Hmm, alright. I'm suspicious about glib2.0 -> bluez/firefox
[22:13] <Laney> Jenkins says they both ran at 17:20ish today
[22:13] <cjwatson> adt-britney collected statuses for those six minutes ago that said running
[22:14]  * ScottK needs to go retrieve a $CHILD from ballet lessons.
[22:14] <cjwatson> hm, but
[22:14] <Laney> Maybe jenkins is lying then
[22:15] <cjwatson> $ cat ../../autopkgtest/data/adt/saucy-proposed/amd64/archive/2013/06/25/saucy_amd64_bluez_20130625-172427.result
[22:15] <ScottK> Probably remove some autopackage tests when I get back.  Seems like more harm than good to me.
[22:15] <cjwatson> saucy amd64 bluez 4.101-0ubuntu8b1 PASS kmod 9-3ubuntu1 systemd 204-0ubuntu4 pcmciautils 018-8 lsb 4.1+Debian11ubuntu2 alsa-lib 1.0.25-4ubuntu4 dbus 1.6.12-0ubuntu1 glib2.0 2.37.3-1ubuntu1 gstreamer0.10 0.10.36-1.2ubuntu1 eglibc 2.17-0ubuntu5 bluez 4.101-0ubuntu8b1 gst-plugins-base0.10 0.10.36-1.1ubuntu1 dbus-python 1.2.0-2 readline6 6.2-9ubuntu1 libusb 2:0.1.12-23.2ubuntu1 cups 1.6.2-9 dpkg 1.16.10ubuntu2
[22:15] <cjwatson> ScottK: Please let us sort out the infrastructure a bit before you do anything precipitate
[22:16] <barry> cjwatson: oops. sorry if i stepped on your toes with software-properties
[22:16] <cjwatson> barry: s'ok, just one upload more than strictly necessary, not a problem
[22:17] <barry> cjwatson: we can always make more version numbers
[22:17] <cjwatson> Ah, the above was an archived result I think
[22:18] <cjwatson> 2013-06-25 17:12:08,498 INFO Checking status for: saucy bluez
[22:18] <cjwatson> 2013-06-25 17:12:08,551 INFO == New version of dependency 'libglib2.0-0 2.37.3-1ubuntu1'.
[22:18] <cjwatson> which is a bit odd given that that's the version number in the archived result
[22:20] <Laney> If that's what it says when it triggers a new run then the timestamps could be feasible
[22:20]  * Laney bed
[22:21] <cjwatson> I think adt-britney thinks it's still running on i386
[22:21] <cjwatson> $ cat ../../autopkgtest/data/adt/saucy-proposed/amd64/work/saucy-proposed_amd64_bluez.20130625-171230.state
[22:21] <cjwatson> {"status": {"i386": "RUNNING", "amd64": "PASS", "all": "RUNNING"}, "package": "bluez", "depends": {"libglib2.0-0": "2.37.3-1ubuntu1", "libbluetooth3": "4.101-0ubuntu8b1", "pcmciautils": "018-8", "lsb-base": "4.1+Debian11ubuntu2", "libdbus-1-3": "1.6.12-0ubuntu1", "libudev1": "204-0ubuntu4", "udev": "204-0ubuntu4", "bluetooth": "4.101-0ubuntu8b1", "bluez": "4.101-0ubuntu8b1", "libasound2": "1.0.25-4ubuntu4", "cups": ...
[22:21] <cjwatson> ... "1.6.2-9", "libusb-0.1-4": "2:0.1.12-23.2ubuntu1", "bluez-alsa": "4.101-0ubuntu8b1", "python3-dbus": "1.2.0-2", "libgstreamer-plugins-base0.10-0": "0.10.36-1.1ubuntu1", "upstart": "1.8-0ubuntu7", "libgstreamer0.10-0": "0.10.36-1.2ubuntu1", "multiarch-support": "2.17-0ubuntu5", "libc6-dev": "2.17-0ubuntu5", "libc6": "2.17-0ubuntu5", "dpkg": "1.16.10ubuntu2", "dbus": "1.6.12-0ubuntu1", "libbluetooth3-dbg": ...
[22:21] <cjwatson> ... "4.101-0ubuntu8b1", "bluez-gstreamer": "4.101-0ubuntu8b1", "libreadline6": "6.2-9ubuntu1", "module-init-tools": "9-3ubuntu1"}, "version": "4.101-0ubuntu8b1", "release": "saucy", "causes": {"glib2.0": "2.37.3-1ubuntu1"}}
[22:21] <cjwatson> But I run with -a amd64 ...
[22:23] <cjwatson> OK, I've stopped it caring about i386 for now, I think
[22:24] <cjwatson> ScottK: BTW, I'm always happy to offer assistance with migrations that are proving difficult.
[22:24] <cjwatson> Just ask.
[22:26] <cjwatson> I: [Tue Jun 25 22:26:15 2013] - Collected autopkgtest status for bluez_4.101-0ubuntu8b1: PASS
[22:26] <cjwatson> better
[22:26] <cjwatson> I: [Tue Jun 25 22:26:15 2013] - Collected autopkgtest status for firefox_22.0~b6+build1-0ubuntu1: FAIL
[22:27] <cjwatson> ScottK: Apparently not quite enough.  I'll look into the rest, until I need to sleep
[22:27] <cjwatson>     * i386: epigrass, pymca, python-acidobasic, python-guiqwt, python-qwt3d-qt4, python-qwt5-qt4, python-taurus, spykeviewer
[22:27] <cjwatson>     * amd64: pymca, python-guiqwt, python-qwt3d-qt4, python-qwt5-qt4
[22:27] <cjwatson>     * armhf: pymca, python-guiqwt, python-qwt5-qt4
[22:27] <cjwatson>     * powerpc: pymca, python-guiqwt, python-qwt3d-qt4, python-qwt5-qt4
[22:33]  * infinity watches another batch of acl2 builds fail.
[22:34] <cjwatson> Whee.
[22:34] <cjwatson>  python-sip : Breaks: python-qwt3d-qt4 (< 0.1.7~cvs20090625-11+) but 0.1.7~cvs20090625-11build1 is to be installed
[22:34] <cjwatson>               Breaks: python-qwt5-qt4 (< 5.2.1~cvs20091107+dfsg-6+b4) but 5.2.1~cvs20091107+dfsg-6+b3build2 is to be installed
[22:34] <cjwatson> Overly-specific Breaks 'r' us.
[22:35] <xnox> infinity: I didn't think canadian television is that bad, that you prefer watching build logs instead..... =)))))))
[22:36] <infinity> xnox: Build logs are exciting.  It's like rubbernecking at car accidents and train wrecks.
[22:38]  * cjwatson tweaks sip4's Breaks.  This should work a bit better.
[22:39] <cjwatson> Any release team member want to double-check that for me and unblock it?
[22:39] <cjwatson> http://paste.ubuntu.com/5799998/
[22:41] <infinity> cjwatson: The second one seems fine (and upstreamable), I'd probably just reupload pyqwt5 as +b4 to deal with the first, though.
[22:41] <infinity> Since +b3build2 is silly anyway. :P
[22:42] <cjwatson> I was suspicious since it's rare for +b3 to make it into *source* version numbers.
[22:42] <infinity> It was an attempt to fool the Debian breaks, I believe.
[22:42] <cjwatson> But apparently ... yes, it really was manually inserted.  Weird.
[22:42] <infinity> So, if we're already on that path, may as well upload a +b4
[22:42] <cjwatson> Unfortunately I've already uploaded sip4.
[22:43] <infinity> Oh, so much for the double-checking. :)
[22:43] <cjwatson> So might be better to stick with that change if it's at least minimally acceptable
[22:43] <cjwatson> Sorry, that was double-check before unblock rather than before upload.  Maybe I should have done the latter
[22:44] <infinity> Breaks against binNMU versions are amazingly broken and wrong anyway.  Someone needs to yell at the Debian maintainer.
[22:44] <infinity> Cause any new port (for instance) will have to binNMU 4 times to make things installable, for no good reason. :P
[22:45] <cjwatson> I don't know what that's there for.  I assumed there was some arcane apt-fooling reason, but it does seem odd.
[22:45] <cjwatson> Your reasoning is indeed sound.
[22:46] <cjwatson> pyqwt5 is just long enough that waiting for it to finish would push me past bedtime, so I think for the moment I'll not upload that
[22:47] <infinity> cjwatson: Sure, there's no need for us to unwind this mess, except that it's remarkably unpretty.
[22:47] <infinity> cjwatson: I'll unblock sip4 after I ingest some food.
[22:48] <cjwatson> I need to do some laundry, but I'll come back to make sure this mess all works.
[22:59] <barry> @pilot out
[23:03] <sarnold> barry: freenode netsplit put the /topic back -- you may want to re-run @pilot out
[23:04] <barry> @pilot out
[23:04] <barry> sarnold: thanks ;)
[23:04] <sarnold> barry: woo :)
[23:05] <ScottK> cjwatson: Thanks.
[23:07] <ScottK> infinity: I can take care of the unblock.
[23:08] <ScottK> cjwatson: Don't worry, that's mostly just me being really frustrated at the moment.  I'll get over it.
[23:08] <cjwatson> Well, the offer stands in any case; I know we don't require notification of transitions the way debian-release does, and of course you're on ubuntu-release anyway, but it can still help to have more eyes on things if only to nudge them along at appropriate times.
[23:21] <infinity> ScottK: Okay, then I'll blissfully ignore it unless you poke me with an issue.
[23:21] <ScottK> OK.
[23:21] <ScottK> Just finished, so we'll know in 40 minutes.
[23:30] <TheMuso> @pilot in
[23:32] <ScottK> I love how things have improved (new rant):
[23:32] <ScottK> $ pbuilder-dist raring login
[23:33] <ScottK> raises the error "distro_info.DistroDataOutdated: Distribution data outdated." and quits.
[23:33] <ScottK> Yes, it's been a while since that box got updated, but it's ridiculous to bail out of doing stuff about releases it knows about.
[23:33]  * ScottK tries to remember where to file the bug.
[23:36] <cjwatson> distro-info, probably either Debian or Ubuntu is fine
[23:37] <cjwatson> Or post a love letter to bdrung :)
[23:37] <ScottK> Yeah, just filed it in Ubuntu.