[10:26] <brendand> jodh, we want to run our test tool as soon as the system is ready to be tested. what that actually means may need discussion. i don't know that much about upstart
[10:27] <jodh> brendand: ok, well you need to know what environment your test tool needs to run in.
[10:27] <jodh> brendand: 'start on runlevel [2345]' is generally appropriate for jobs that need to run when disks are mounted and networks are up.
[10:27] <brendand> jodh, we do - but how to express that in upstart terms is beyond me at the moment
[10:28] <jodh> brendand: so what does your test tool need before it can run?
[10:28] <brendand> jodh, the best way to describe it would be to say that we should start testing when all initialisation that's going to happen has happened
[10:29] <jodh> brendand: what does the test tool test?
[10:29] <brendand> jodh, well we're testing hardware so all services that interact with hardware need to be started
[10:29] <jodh> brendand: can you give examples of such h/w services that you care about?
[10:29] <brendand> networking
[10:29] <brendand> usb
[10:30] <zyga> jodh: we talk to network manager, udisks, poke udev
[10:30] <brendand> zyga, actually on servers we don't touch NM
[10:30] <zyga> brendand: perhaps this also implies our jobs should be able to depend on upstart stuff being started? that would remove the requirement from plainbox itself and offset it to other parts of the system
[10:31] <brendand> jodh, on desktop systems we are just using xdg autostart to start after login
[10:31] <brendand> jodh, so we're thinking only about servers here
[10:31] <zyga> brendand: we could perhaps use upstart for that as well, without user sessions (jodh: we need to support precise +)
[10:36] <jodh> brendand: I'd go for the runlevel 'start on' then since nm isn't going to be available on the server.
[10:37] <zyga> jodh: meta-question, do you think backporting current upstart to precise would be a good idea?
[10:37] <brendand> jodh, http://upstart.ubuntu.com/cookbook/#normal-start seems to imply that using the runlevel start on would mean that you are okay with the service starting without a valid network interface
[10:39] <jodh> brendand: please just try the runlevel start on. I'll tweak the cookbook when I'm less busy ;)
[10:39]  * brendand is reading https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/701576
[10:39] <jodh> zyga: why?
[10:39] <zyga> jodh: so that stuff that targets 12.04 can take advantage of new features and can rely on stuff that upstart is good at
[10:41] <jodh> zyga: doesn't that argument apply to most packages in Ubuntu though?
[10:42] <zyga> jodh: yes but web apps typically sidestep normal packaging already
[10:42] <zyga> jodh: yet depend on upstart for getting started
[10:43] <jodh> zyga: upstart in precise works perfectly well. I don't understand your argument.
[10:44] <zyga> jodh: perhaps I miss something, let me explain that
[10:45] <zyga> jodh: I was looking for setgit/setuid but apparently those are in precise by now
[10:45] <zyga> jodh: I must have confused that with lucid
[10:46] <zyga> setgid
[10:49] <jodh> zyga: ok. You can compare 'rmadison upstart' with http://upstart.ubuntu.com/cookbook/#stanzas-by-category
[14:39] <fabiant7t> Is it possible for a service to stop itself and prevent further respawns for the current upstart session?
[14:41] <fabiant7t> My use case is to shut down a client service whose server (another system) rejected communication. The client exits but respawns immediately due to upstart.
[14:46] <xnox> fabiant7t: respawn can have limits, such that it will stop respawning.
[15:01] <fabiant7t> xnox: thx! I'll try to add a respawn limit to the upstart job
[15:04] <xnox> fabiant7t: http://upstart.ubuntu.com/cookbook/#respawn-limit
[15:05] <fabiant7t> xbox: Jap, I'm reading through it, just need to find the right place to apply it on saltstacks generic upstart job script (http://dpaste.com/1052456/)
[15:16] <SpamapS> fabiant7t: if the service exits with a normal exit, no respawn will ocurr
[15:16] <SpamapS> fabiant7t: so just exit(0)
[15:17] <fabiant7t> SpamapS: I tested that with sys.exit(0) in python, but it got respawned
[15:17] <SpamapS> fabiant7t: something went wrong then
[15:17] <SpamapS> fabiant7t: is it being run by a wrapper script that maybe doesn't exit cleanly?
[15:19] <fabiant7t> SpamapS: As far as I can tell (and read in the logs), it did exit property with a return code 0
[15:20] <fabiant7t> SpamapS: I'm trying to fix that issue here, btw: https://github.com/saltstack/salt/issues/4411
[15:20] <SpamapS> fabiant7t: oh I misunderstood actually
[15:20] <SpamapS> only tasks can exit 0 to avoid respawn
[15:21] <SpamapS> fabiant7t: to make non-tasks behave the same way you have to add 'normal exit 0'
[15:21] <fabiant7t> SpamapS: It's a system service, and it's running into a deadlock right now
[15:22] <fabiant7t> SpamapS: to this script? http://dpaste.com/1052456/
[15:23] <fabiant7t> I am pretty unfamiliar with upstart and the startup scripts, unfortunately :(
[15:23] <SpamapS> fabiant7t: oh thats a sysvinit. Wha?
[15:23] <fabiant7t> obviously it got automatically rewritten to upstart
[15:24] <SpamapS> fabiant7t: wait no, ignore that script
[15:24] <SpamapS> fabiant7t: /etc/init/$that_scripts_name.conf
[15:25] <fabiant7t> SpamapS: aaah, got it
[15:30] <fabiant7t> SpamapS: That fixes the loop, thanks a lot!


[00:01] <rickspencer3> robert_ancell, how is your scanner app coming along?
[00:02] <robert_ancell> rickspencer3, good, I spent monday's swap day adding multi page supprot
[00:03] <rickspencer3> oooh
[00:03] <rickspencer3> so are you think replacing xsane in Lucid?
[00:03] <robert_ancell> that is the plan :)
[00:03] <robert_ancell> at least try it in the alphas and see what the feedback is
[00:04] <robert_ancell> hopefully get some user testing done if the design team has the time for it...
[00:04] <dtchen> rickspencer3: hi, I've been pinged about reenabling flat volumes for 10.04. What are your thoughts?
[00:04] <rickspencer3> dtchen, I need to educate myself before I offer an opinion
[00:05] <rickspencer3> apparantly the feedback from users about that was not so good, thus the disabling
[00:05] <dtchen> rickspencer3: yes, confusion and all, but upstream PA is convinced that the misperception can be overcome by reading
[00:06] <rickspencer3> reading?
[00:06] <rickspencer3> you mean users reading documentation?
[00:06] <dtchen> yes
[00:06] <rickspencer3> uh
[00:06] <rickspencer3> has anyone ever watched a user use a computer?
[00:06] <rickspencer3> I mean no disrespect to upstream or to users ...
[00:06] <rickspencer3> but in my experience, users do not read
[00:07] <rickspencer3> they want to learn by doing, and if they can't learn something by using it, they consider it "crap"
[00:07] <rickspencer3> dtchen, what is your opinion, if you don't mind me asking?
[00:07] <dtchen> yes, sadly that part is pretty obvious given the amount of heat I've received across the blogosphere. Mostly FUD, but heat nonetheless.
[00:08] <dtchen> rickspencer3: personally it's useful but really relies on a perfect convergence of good (hardware|drivers)
[00:08] <dtchen> rickspencer3: slomo pinged me in here about it; I'd like to get his opinion about it, too
[00:10] <rickspencer3> dtchen, pulseaudio is working quite well for me in Karmic
[00:10] <dtchen> you've been lucky :-)
[00:11] <rickspencer3> heh
[00:11] <rickspencer3> dtchen, btw, don't worry about haters on the Internet
[00:12] <rickspencer3> I sure take plenty of heat from them, I can't help noticing how many people *don't* actually contribute
[00:12] <rickspencer3> but feel they know an aweful lot about delivering a distro
[00:12] <rickspencer3> ;)
[00:14] <dtchen> oh certainly. It just ends up feeding back into upstream's misperceptions, although Luke and I have been pushing back a lot harder these days.
[00:14] <rickspencer3> good
[00:15] <rickspencer3> in any case, if flat volumes requires a perfect alignment of hardware and drivers, and you don't see that happening, I don't see how we can commit to shipping it
[00:15] <rickspencer3> oth, if we want to turn it on for a while soonish and see what feedback we get, this would be the right time in the cycle to discuss that
[00:17] <TheMuso> I agree 100% with users not bothering to read documentation.
[00:24] <rickspencer3> hi all, I'm moments away from logging off until next Monday
[00:24] <rickspencer3> TheMuso, robert_ancell feel free to call if something comes up, probably wont' be online much
[00:25] <robert_ancell> rickspencer3, have a good time off!
[00:25] <rickspencer3> robert_ancell, thanks, it's much needed!
[00:26]  * rickspencer3 will look for new scanner tool on Monday
[00:26] <rickspencer3> (only half joking)
[00:26] <rickspencer3> robert_ancell, it occurs to me that time for expense reports is next week, good chance to get lots of canonical folks o try your scanner tool
[00:27] <robert_ancell> rickspencer3, good idea
[07:15] <pitti> Good morning
[07:16] <didrocks> Hello pitti
[07:16] <pitti> bonjour
[08:33] <huats> morning
[08:33] <didrocks> morning huats
[08:34] <didrocks> pitti: do you have any pointers on your straciatella session work (for guest session, I guess)? I want to work on the desktop UNE session
[08:35] <pitti> didrocks: guest and stracciatalla are quite different concepts; for UNE you probably want to look at the stracciatella one
[08:35] <pitti> didrocks: pointers> not really, except for the source package itself; it should be quite obvious, though
[08:35] <pitti> it's by and large a .desktop file
[08:36] <didrocks> pitti: ok, I'm looking at the source package right now. Very similar to what I had in mind
[08:36] <pitti> and a new session script which wraps gnome-session with an env var
[08:36] <pitti> does UNE use gnome-session as well?
[08:37] <pitti> or has its own session program?
[08:37] <vuntz> lalala
[08:37] <didrocks> pitti: not sure. At first glance, it should use gnome-session but I need to confirm first (building a VM right now)
[08:37] <pitti> if g-s, we probably need to change gnome-session package itself and make its .desktop files test the session type
[08:37] <didrocks> hey vuntz!
[08:37] <pitti> bonjour vuntz, comment vas-tu?
[08:37] <didrocks> pitti: ok
[08:38] <vuntz> pitti: long hacking night, with some satisfying code in the end :-)
[08:38] <pitti> good!
[08:38] <didrocks> gnome-panel? :)
[08:38] <pitti> erm, I meant, "tres bien!"
[08:38] <vuntz> pitti: what do you mean with "make its .desktop files test the session type" ?
[08:38] <vuntz> didrocks: nah, some opensuse stuff
[08:39] <pitti> vuntz: like, don't start a panel or nautilus in a netbook session
[08:39] <pitti> those are started by g-s from gconf keys right now, right?
[08:39] <vuntz> ah, it's just a matter of having other desktop files providing Panel and whatever nautilus uses
[08:39] <pitti> and some others are autostart .desktop files
[08:39] <vuntz> X-GNOME-Provides=filemanager
[08:40] <vuntz> so just drop somewhere a .desktop file with X-GNOME-Provides=filemanager;panel; and voilà!
[08:40] <vuntz> (as long as the .desktop file is in a directory with a higher priority than /usr/share/applications)
[08:41]  * didrocks gives a try and will ping pitti and vuntz when needed :)
[08:41] <pitti> yay
[09:11] <mac_v> hi.. why is the winbind package not installed by default?
[09:12] <mac_v> there is a bug filed for that , any specific reasons?
[10:03]  * mac_v wonders if everyone is still on US time ;)
[10:04] <seb128> US people probably
[10:04] <pitti> well, it's not really necessary to have by default
[10:04] <seb128> hello pitti
[10:04]  * pitti waves to seb128
[10:04] <seb128> pitti, is seahorse-agent working for you in lucid?
[10:05] <pitti> yes, apparently
[10:05] <seb128> ok
[10:05] <seb128> weird
[10:05] <pitti> well, I didn't reboot/restart after today's dist-upgrade yet
[10:06] <seb128> it's not working since uds there
[10:06] <seb128> I get a pinentry dialog
[10:06] <seb128> ie
[10:06] <seb128> env | grep GPG -> gpg-agent
[10:06] <seb128> not seahorse
[10:06] <pitti> apparnetly you have gnupg2 installed?
[10:06] <seb128> and the thing doesn't keep the token for my session
[10:07] <seb128> but for half an hour or something
[10:07] <seb128> indeed
[10:08] <seb128> it was installed in karmic too
[10:27] <mac_v> seb128: could you translate > Bug 487980 , Bug 487986 ... or comment on the bug asking the reporter to edit the bug in english...   I'm not sure If i reply in english he/she would understand :)
[10:28] <seb128> mac_v, it's not a language that I speak...
[10:28] <mac_v> seb128: oh.. it thought that was french... ah , nvm ;)
[10:29] <seb128> mac_v, no it's not ;-)
[10:30] <mac_v> lol... my french has *not* deteriorated ... i thought i had forgotten so much i couldnt understand a word ;p
[10:35] <seb128> pitti, do we still need to have user stories, etc in specs?
[10:35] <pitti> seb128: I don't care about them for most specs, where the rationale is obvious
[10:35] <seb128> ok thanks
[10:35] <pitti> like, desktop startup speed> forget it
[10:36] <seb128> I hate writing those when the purpose is clear
[10:36] <seb128> thanks
[10:36] <pitti> seb128: I am still interested in them for e. g. a rhythmbox -> banshee switch
[10:36] <pitti> because there it matters for justification
[10:36] <seb128> right
[11:07] <seb128> pitti, doh, sorry for the user stories question before
[11:08] <pitti> ?
[11:08] <seb128> I'm just reading your email now and you were quicker than me again ;-)
[11:08] <pitti> hah
[11:08]  * pitti changes his performance review to "answers questions before seb128 can raise them"
[11:09] <seb128> ;-)
[11:09]  * seb128 hugs pitti
[11:41] <seb128> pitti, spec ready for review = review or pending approval?
[11:41] <pitti> either
[11:41] <seb128> the "definition" for the blueprint
[11:41] <seb128> ok, I set it to review
[11:42] <seb128> pitti, https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-gnome-geoclue on your plate, I've drafted it for records but it's off map already for lucid...
[11:42] <seb128> desrt played with geoclue at uds and it's not ready
[11:42] <pitti> ok, thanks; I'll put it off the lucid list then
[11:42] <seb128> pitti, thanks
[11:44] <seb128> pitti, should I bother drafting the gnome3 one? it has been a discussion about GNOME changes coming this cycle and what we do for those
[11:44] <seb128> pitti, ie it's "informational"
[11:45] <seb128> I can write the record in the whiteboard but I don't fancy writing a wiki page for nothing
[11:45] <pitti> seb128: are there any work items for us in this cycle?
[11:45] <seb128> no
[11:45] <pitti> don't bother then
[11:45] <seb128> it's decisions on versions we will use
[11:45] <pitti> that sounds like work items :)
[11:45] <seb128> and some note about where we need to be careful
[11:45] <pitti> package version foo:
[11:45] <pitti> but still doesn't require a wiki page
[11:46] <seb128> package GNOME 2.30 for everything but...
[11:46] <pitti> so having just a list of things to watch out for/do seems sufficient
[11:46] <seb128> ok thanks
[11:46] <seb128> I will just use the whiteboard for this one
[11:46] <pitti> in general, keep it as simple as possible :)
[11:46] <seb128> I like that ;-)
[12:13] <asac> TheMuso: dtchen: where is the pulse packaging branch located?
[12:14] <asac> the core-dev one seems to be out of date?
[12:21] <seb128> didrocks, there?
[12:25] <seb128> pitti, about https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-compiz-effects
[12:25] <seb128> pitti, do we need a real blueprint wiki, or is https://wiki.ubuntu.com/Lucid/CompizDefaults good enough?
[12:28] <pitti> seb128: fine for me, but it's not pointing out what to do for lucid; these would need to become work items (which we need anyway)
[12:28] <pitti> so, that plus WIs -> good
[12:28] <seb128> pitti, I've added the wis to the whiteboard already ;-)
[12:30] <pitti> hm, what are djsiegels's settings?
[12:31] <seb128> pitti, the bzr just before in the whiteboard
[12:31] <pitti> I see
[12:31] <seb128> it's basically a collection of gconf settings
[12:31] <pitti> can I assign that spec to you?
[12:32] <seb128> sure
[12:32] <pitti> approved then
[12:32] <pitti> seb128: btw, https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-default-apps is ready for review, too :)
[12:32] <seb128> pitti, thanks
[12:51] <didrocks> seb128: here now :)
[12:52] <seb128> didrocks, do you want to be drafter for une session?
[12:52] <seb128> I saw you started on the wikipage
[12:52] <seb128> I'm drafter on the blueprint now but I'm happy to change that to you
[12:53] <didrocks> seb128: I can do it if you want as I'll certainly implement it
[12:53] <didrocks> should be quickly done
[12:53] <seb128> didrocks, thanks
[12:54] <didrocks> y/w
[12:54] <seb128> didrocks, not sure how busy you will be in the next weeks, should somebody take over your merges for lucid?
[12:54] <seb128> ie I was looking at clutter-1.0 yeasterday
[12:54] <seb128> should be easy, but it would be nice to send your change to the bts
[12:55] <didrocks> seb128: yeah, I prefer to focus on UNE session first if you don't mind and I'll have not so much time next week
[12:55] <seb128> ok
[12:55] <didrocks> thanks :)
[12:59] <didrocks> seb128: I still can do those on universe, but for main/desktop set, as I don't still don't have any access, waiting for cjwaston's answer, it's more a waste of time to ask you to sponsor them, that's why I think it's better not waiting for me :)
[13:00] <seb128> didrocks, sponsoring is easy nowadays, I only debsign and upload for oyu
[13:00] <seb128> you
[13:00] <seb128> but if you are busy I can handle those no worry
[13:01] <didrocks> seb128: I'll ping you if I have some time to do it. The only one you can sponsor is vino as it was my testcase for upload right yesterday
[13:01] <seb128> I didn't sponsor it on purpose, keeping it as a testcase
[13:02] <didrocks> ok :)
[13:05] <asac> TheMuso: there?
[13:15] <mvo> seb128: is there something like gconftool --dump --only-if-different-from-schema-default?
[13:15] <seb128> mvo, not that I know about no
[13:16] <mvo> hm, ok. I check what I can do with python
[13:17] <seb128> mvo, trying to backup compiz settings?
[13:17] <seb128> mvo, reading .gconf/apps/something is sort of doing that
[13:18] <mvo> seb128: yes, well, sort-of. first trying to get a diff from the ones we currently use compared to the ones that djsiegel has
[13:20] <seb128> mvo, gconftool-2 --config-source=xml:readonly:/home/mvo/.gconf --dump /apps/compiz
[13:20] <seb128> mvo, gconftool-2 --config-source=xml:readonly:/home/mvo/.gconf --dump /apps/compiz, try that one
[13:20] <mvo> seb128: cool, will do
[13:22] <seb128> mvo, well, that will read user changes
[13:22] <seb128> so that might not do the "if user_value != default_value"
[13:23] <seb128> but that's the best idea I've right now
[13:23] <mvo> yeah, it gives me too much. I try some gconf python now
[13:24] <tseliot> pitti: I've replied to your questions in the proprietary drivers spec. Feel free to move my answers to another place if you find their position to be confusing
[13:37] <pitti> tseliot: thanks
[13:38] <tseliot> np
[13:38] <mac_v> mvo: if backing up your compiz profile is the only thing you are looking for , you could do it , using ccsm
[13:39] <pitti> she
[13:41] <pitti> didrocks: oh, cool:
[13:41] <pitti> Archive Upload Rights for ubuntu-desktop: package set 'ubuntu-desktop' in lucid
[13:41] <pitti> the "lucid" one was missing yesterday
[13:41] <pitti> does it work now?
[13:59] <seb128> chrisccoulson, do you fancy try upload rights?
[13:59] <seb128> should be working now, not sure if you have anything to upload though
[14:00] <kklimonda> is archive reorganization scheduled for this cycle?
[14:01] <chrisccoulson> seb128 - i can try it, but i need to find something to upload first
[14:01] <seb128> chrisccoulson, don't bother if you don't have anything pending, next time you have something
[14:03] <seb128> chrisccoulson, bug #487224 maybe
[14:03] <chrisccoulson> seb128 - yeah, i can try that
[14:04] <chrisccoulson> i really need to start doing some merges tonight really
[14:15] <chrisccoulson> seb128 - my g-p-m upload was accepted
[14:16] <seb128> pitti, I guess what you are interested in for startup time is work items, right?
[14:16] <seb128> chrisccoulson, rock on!
[14:16] <seb128> \o/
[14:18] <pitti> chrisccoulson: yay!!
[14:18] <seb128> chrisccoulson, didrocks, kenvandine: you can upload
[14:18] <pitti> seb128: sure
[14:18] <pitti> and Robert, too
[14:18] <seb128> pitti, ok, ready to review for you then
[14:18] <slomo> seb128: did you sync vala already? also, why is it in main? is something in main depending on it already or just because it's nice to have? :)
[14:19] <seb128> pitti, yes, he's not around though, I will tell him tonight when he joins
[14:19] <pitti> seb128: I didn't take a look at the foundations wiki page yet; it has some desktop-ish bits, too, right?
[14:19] <seb128> slomo, not yet, will do that now, it's not in main but there was some mir because things want to build-dep on it
[14:19] <kenvandine> seb128, cool, thx!
[14:19] <pitti> slomo: it's not?
[14:19] <pitti> there's an approved MIR for it, but it won't get promoted until something actually pulls it in
[14:19] <pitti> on that note, I played with vala on the flight back home
[14:20] <pitti> quite nice, although horribly underdocumented
[14:20] <pitti> I like it
[14:20] <kenvandine> pitti, cool
[14:20] <seb128> pitti, fundation, I captured what was on https://wiki.ubuntu.com/FoundationsTeam/BootPerformance/Lucid/Desktop
[14:20] <seb128> pitti, I didn't look at the X part though
[14:20] <kenvandine> i gotta finish these specs so i can start writing something real
[14:20] <seb128> pitti, should I?
[14:21] <slomo> pitti: oh it's not, right... i thought someone yesterday said it was in main :)
[14:21] <seb128> slomo, I said the security team made the testsuite fail a requirement for main
[14:21] <seb128> so we are proactive there ;-)
[14:21] <pitti> seb128: if there's something for us to do Xorg-wise, we should have WIs, yes
[14:22] <seb128> pitti, ok, I will try to figure that's not something we discussed during the session at uds
[14:22] <slomo> seb128: oh, ok :)
[14:27] <chrisccoulson> slomo - i did the MIR for vala when tracker started using it, and i was packaging tracker from GIT. this was before i realised that the distributed tarballs all have the vala code compiled anyway
[14:30] <seb128> speaking about mir, does anybody fancy doing some of those?
[14:30] <seb128> we need some new libraries for gvfs
[14:30] <seb128> libiphone for example
[14:31] <seb128> pitti, ok, captured xorg wis for desktop speed and sent it your way now
[14:34] <pitti> and upload fu announced to -desktop@
[14:34] <pitti> seb128: you rock, thanks
[14:34] <seb128> pitti, you rock too, thanks ;-)
[14:34]  * seb128 hugs pitti
[14:46] <seb128> sabotage!
[14:46] <seb128> somebody cleaned the desktop-lucid-default-apps gobby document...
[14:48] <pitti> oh, does that mean the spec is cancelled? :-)
[14:50] <seb128> pitti, is that a lame try to sneak away from this one? ;-)
[14:50] <kenvandine> i guess that means we ship gimp :)
[14:50] <seb128> pitti, approved btw
[14:50] <pitti> \o/
[14:50]  * seb128 done with first round of drafting
[14:51]  * pitti bids farewell to gimp, chess, and tetravex
[14:51] <seb128> time to update the mini 10 to lucid and start bootcharting
[14:51] <seb128> and do some packaging work
[14:51] <pitti> seb128: yay
[14:51] <kenvandine> have fun seb128!
[14:51] <seb128> I will ;-)
[14:51] <pitti> seb128: try removing the pulse xsession.d and upgrade to mvo's new compiz
[14:51]  * kenvandine wants a mini 10, but will wait and see what arm devices come :)
[14:51] <seb128> I'm eager to try how much speedup the compiz do
[14:51] <seb128> pitti, right, will do
[14:52] <kenvandine> tired of using the portuguese keyboard on my classmate
[14:52] <kenvandine> very hard to use vi :)
[14:52] <pitti> kenvandine: what keeps you from switching to US?
[14:52] <mvo> seb128: its ftbfs because of some kde4 issues :/
[14:52] <kenvandine> the keyboard? i can't find one
[14:53] <kenvandine> i use the right layout
[14:53] <kenvandine> but the keys are a bit funky
[14:53] <kenvandine> if i used it everyday i would get used to it, but i only use it when i travel
[14:54] <seb128> mvo, not cool
[14:54] <kenvandine> it only bothers me in vim, but i use vim allot
[14:54] <seb128> try emacs?
[14:54]  * seb128 runs
[14:54] <kenvandine> bah!
[14:54] <kenvandine> i bet that would suck just as much on this keyboard :)
[14:55]  * kenvandine <3 vim
[14:55] <kenvandine> seb128, does your mini 10 have ssd?
[14:55] <seb128> yes
[14:55] <kenvandine> cool
[15:54] <seb128> bah, almost 60meg to install bootchart...
[15:54] <pitti> seb128: pybootchartgui FTW
[15:54] <pitti> avoids the java stuff
[15:54] <pitti> and works just as nicely
[15:54] <seb128> Keybuk, ^ which one do you use?
[15:54] <Keybuk> bootchart-java :)
[15:55] <Keybuk> though it doesn't work in lucid
[15:55] <Keybuk> so I may actually switch to finally using (and fixing up) the python one
[15:55] <seb128> Keybuk, is pybootchartgui buggy?
[15:55] <seb128> hum
[15:55] <seb128> worded differently I don't care about what is running I want something I can use to bootchart lucid desktop and start boot speed work
[15:56] <seb128> less to download is better if the python one works
[15:58] <Keybuk> yeah
[15:58] <Keybuk> settle on the python one
[15:59] <pitti> I have used nothing else in the past half year, and Keybuk didn't harass me for sending bad charts ... yet
[15:59] <Keybuk> I'm going to use that on the daily bootcharts I think
[15:59] <Keybuk> for a while, it gave ugly output
[15:59] <Keybuk> but I fixed that
[15:59] <Keybuk> and never got around to switching myself ;)
[15:59] <pitti> heh
[15:59] <seb128> ok thanks
[15:59] <seb128> much faster to get indeed ;-)
[16:04] <seb128> hum
[16:04] <seb128> doesn't work out of the box on karmic?
[16:04] <seb128> I rebooted and nothing in /var/log/bootchart
[16:05] <seb128> it's there now
[16:05] <seb128> it was probably processing datas
[16:22] <pitti> mvo: ooh, arch-build gone from update-notifier \o/
[16:22]  * pitti hugs bzr-bd
[16:23] <mvo> pitti: yeah, pretty much gone from all stuff since some time, bzr bd ftw!
[16:25] <pitti> mvo: what causes autoreconf to be called now?
[16:26] <mvo> its not done automatically anymore iirc
[16:27] <pitti> so how does bzr bd -S work then?
[16:30] <seb128> mvo, alter! how do I use an usb stick as a source for update?
[16:30] <seb128> I did apt-cdrom add it
[16:30] <seb128> but it doesn't find packages on it
[16:30] <mvo> pitti: eh, sorry. bzr-builddeb/default.conf has "pre-build = autogen.sh"
[16:30] <seb128> it's a current lucid iso writen on the key
[16:31] <mvo> seb128: just copy the debs to /var/cache/apt/archives
[16:31] <seb128> hum
[16:31] <seb128> I can't use the key as a cdrom?
[16:32] <mvo> seb128: that should work too, its just a bit tricky, easiest is probably to just make /cdrom point to it
[16:32] <mvo> so edit fstab, point /cdrom to the stick apt-cdrom add
[16:34] <seb128> I did apt-cdrom add -d mountpoint
[16:36] <seb128> hum
[16:36] <seb128> there is not a lot of deb on this image
[16:37] <seb128> mvo, how does the "dist-upgrade from cd" magic works?
[16:37] <seb128> everything is in the casper image no?
[16:38] <mvo> seb128: is this a regular cd? then it won't :/ only alternate or dvd iamges
[16:38] <seb128> oh ok
[16:39] <seb128> I though we had prompt for "new ubuntu version detected do you want to upgrade" for a while
[16:39] <seb128> I used to get those
[16:39] <seb128> nevermind then
[16:39] <seb128> I will just try a lucid install
[16:44] <mvo> seb128: hrm, odd. I can not reproduce the compiz build failure in a clean chroot
[17:16] <and471> mpt:hi
[17:16] <mpt> Hi and471!
[17:16] <and471> mpt: thanks for mentioning me at the software-center presentation, I watched it the other day :-)
[17:16] <mpt> ah, you're welcome
[17:16] <and471> mpt: hehe it was quite a suprise to have my name suddenly pop-up on screen :-)
[17:17] <and471> mpt: I have a question about the application details view
[17:17] <and471> mpt, at the moment we display a throbber until the image is loaded
[17:17] <and471> mpt, is this neccessary, or can we have the image just fade in
[17:17] <and471> mpt, I think it looks a bit better
[17:18] <mpt> and471, without seeing it, my inclination would be to keep the throbber. But do you have a throbberless demo branch on LP I could try?
[17:18] <and471> mpt: not yet
[17:19] <and471> mpt: I was just doing some work on making the throbber we use, be the one from the gtk theme
[17:19] <mpt> ah, cool
[17:19] <and471> mpt: I have done this for all throbbers except for this one, and I wanted to check I needed to do the work :-)
[17:20] <and471> mpt: would a video of it suffice?
[17:20] <mpt> and471, I think pushing a branch would be just as easy, and more thoroughly testable, than a video
[17:21] <and471> mpt: okay
[17:21] <and471> mpt: it just a bit of a hacky remove of the throbber atm, that is why :-)
[17:24] <and471> mpt, here is the branch (may have to wait for it to update) https://code.launchpad.net/~rugby471/software-center/appdetails-experiments
[17:31] <KelderP> Has anyone experience with an jaunty-karmic upgrade a system which is configured in an Active Directory environment?
[17:34] <mpt> thanks and471 -- I need to try that with a really slow Internet connection
[17:34] <mpt> mvo, what was that trick you used to make screenshots load slowly?
[17:35] <seb128> Keybuk, your uds bootchart was on the mini10?
[17:35] <Keybuk> yes
[17:35] <seb128> weird
[17:35] <seb128> mines are quite different
[17:35] <seb128> copying those online, one sec
[17:37] <seb128> Keybuk, http://people.canonical.com/~seb128/bootchart
[17:38] <Keybuk> your lucid one looks like mine
[17:38] <Keybuk> except you have sreadhead not ureadahead
[17:38] <Keybuk> (which explains the extra few seconds faster mine is <g>)
[17:38] <Keybuk> they just 403d
[17:39] <seb128> ok
[17:40] <Keybuk> I can't see the charts now :(
[17:40] <Keybuk> but if you add the ubuntu-boot PPA for karmic, you get ureadahead too
[17:40] <Keybuk> I include that in my charts because it's going to be uploaded ANY DAY NOW
[17:41] <seb128> Keybuk, ok thanks
[17:41] <seb128> I won't bother about karmic
[17:41] <Keybuk> err
[17:41] <seb128> just keep that box on lucid uptodate and measure weekly progress
[17:41] <Keybuk> I mean for lucid
[17:42] <seb128> right, my comment was about the ubuntu-boot ppa
[17:42] <Keybuk> I need to upload the separated out libnih to lucid
[17:42] <Keybuk> but the lucid valgrind is a *lot* pickier
[17:42] <Keybuk> so I need to update my suppressions file for my tests to pass
[17:42] <Keybuk> yeah, I put ureadahead in ubuntu-boot ppa for lucid too - until I upload it to lucid proper
[17:43] <seb128> Keybuk, at what point do you consider the box loaded?
[17:43] <Keybuk> when both the CPU and I/O charts fall flat
[17:43] <seb128> after the gnome-panel colored bar at ~26s?
[17:43] <Keybuk> I've got a bit of Python that works it out from the .tgz
[17:43] <Keybuk> since I ripped half the code out of pybootchartgui to make that bit of Python
[17:43] <Keybuk> I'm going to plug it back in and upload
[17:44] <seb128> ok, cool
[17:44] <Keybuk> yeah, 26s on yours
[17:44] <and471> mpt http://superuser.com/questions/66574/how-to-throttle-bandwidth-on-a-linux-network-interface
[17:45] <Keybuk> damnit
[17:45] <Keybuk> need to backport python-support to hardy
[17:51] <and471> mpt: I think there are some problems with the code (the image isn't loaded), however I could work it out
[17:55] <mvo> mpt: you can either use trickle or (simpler) just apply a small patch in the code that adds a sleep at the right place
[17:55] <mvo> and471: hey!
[17:55] <and471> mvo: hi there
[17:55] <mvo> and471: I guess I need to merge your branch :)
[17:56] <and471> mvo: if you wouldn't mind :-)
[17:56] <Keybuk> daily@zelda:~$ python /home/scott/guess-time.py 20091116/max/max-lucid-20091125-2.tgz
[17:56] <Keybuk> Total boot: 24.96
[17:56] <Keybuk> Kernel:     4.25
[17:56] <Keybuk>            (1.72)
[17:56] <Keybuk> Plumbing:   3.26
[17:56] <Keybuk> X:          4.01
[17:56] <Keybuk> Desktop:    13.44
[17:56] <Keybuk> sweeeeet
[17:57] <and471> mvo: just wait
[17:57] <and471> mvo, there is one thing I need to push
[17:57] <Keybuk> seb128: http://people.canonical.com/~scott/guess-time.py
[17:57] <and471> mvo: okay pushed now
[17:57] <Keybuk> seb128: could you run that over your chart for comparison
[17:58] <mvo> and471: merging now
[17:58] <mvo> and471: you removed all the progress.pngs?
[17:58] <and471> Keybuk, that link gives a 404
[17:58] <seb128> Keybuk, trying, I've fixed the permission issue btw sorry about that
[17:58] <and471> mvo: yup
[17:59] <and471> mvo, I am using one file now
[17:59] <mvo> aha, nice
[17:59] <and471> mvo, all the frames are in one file now
[17:59] <and471> mvo, a png
[17:59] <Keybuk> fixed
[17:59] <seb128> Keybuk, and what and471 says
[17:59]  * Keybuk puts it in public_html instead of calling it pubic_html
[18:03] <seb128> Keybuk, http://paste.ubuntu.com/327864/
[18:03] <Keybuk> seb128: that's on the lucid tgz?
[18:04] <seb128> yes
[18:04] <seb128> I didn't keep the karmic ones
[18:04] <Keybuk> ok
[18:04] <Keybuk> probably a bit lax on where it says it stops then
[18:04] <seb128> I've reinstalled the box was faster than upgrading
[18:04] <Keybuk> in the script, change the 3.0s to 2.0?
[18:05] <mvo> and471: thanks, that I a bit to review! I will do it tomorrow morning and merge/mail you about it
[18:05]  * mvo needs to leave early today
[18:06] <Keybuk> actually I guess I should actually find the first interval where the load is <25% *and the average for the next 3s is <25%
[18:06] <Keybuk> not just an average 3s
[18:06] <Keybuk> thanks :)
[18:06] <and471> mvo, sure I understand
[18:11]  * mvo waves
[18:26] <seb128_> re
[18:26] <seb128_> pitti, got what I was saying before disconnection?
[18:41] <pitti> good night everyone!
[21:05] <seb128> TheMuso, do you plan to drop the pulseaudio wrapper in lucid?
[21:11] <dtchen> it was already dropped in bzr
[21:12] <dtchen> ogra's upload didn't merge in those changes; I'll work on that now
[21:15] <TheMuso> Ogra couldn't find the bzr branch? Its in the debian/control file and shows up in apt-cache showsrc pulseaudio. :S
[21:17] <dtchen> well, reading his ping in ubuntu-devel, it looks like he saw it but was unsure how to proceed
[21:18] <dtchen> and IRC is really the worst way to reach me during USA east coast business hours due to a direct collision with my work hours :/
[21:18] <seb128> I think somebody said it was not uptodate
[21:20] <dtchen> bzr is 100% current with upstream's stable branches
[21:21] <dtchen> it isn't 100% current with HEAD; I have a separate bzr branch for that
[21:22] <TheMuso> Right, makes sense.
[21:36] <dtchen> ok, branch updated
[21:45] <TheMuso> dtchen: thanks
[22:07] <seb128> hey robert_ancell!
[22:07] <robert_ancell> seb128, hey, just upgraded to lucid.  gobject-introspection seems broken :(
[22:08] <seb128> right, good news is that you can fix it
[22:08] <seb128> uploads work for desktop team now
[22:08] <seb128> or probably I didn't check if those are in the desktop set
[22:09] <robert_ancell> yay!
[22:12] <Amaranth> seb128: Looks like the compiz without a shell script has been uploaded, did you see any speedup with it?
[22:12] <seb128> Amaranth, no but it failed to build first and got retried and built on i386 only so far
[22:13] <seb128> I will try again tomorrow
[22:13] <Amaranth> hrm, wonder why it failed
[22:14] <Amaranth> oh, that explains the flood of messages from launchpad :)
[22:14] <seb128> kde transition apparently...
[22:15] <Amaranth> ah, dang
[22:15] <Amaranth> yeah I see the log now
[22:15] <Amaranth> It failed to find the stuff to build kde4-window-decorator and didn't bail at that point so dh_install failed instead
[22:18] <seb128> time to go to bed there!
[22:18] <seb128> 'night
[22:19] <seb128> robert_ancell, no need to ask sponsoring for gnome updates, just upload now ;-)
[22:19] <seb128> bye
[22:29] <Amaranth> Hrm, where is the GNOME-Do guy when you need him?
[22:29] <Amaranth> I always forget his name :)
[22:29] <dtchen> "DBO"?
[22:34] <dtchen> Amaranth: Jason, IIRC
[22:34] <Amaranth> no no, I know who DBO is :)
[22:35] <Amaranth> djsiegel or something
[22:35] <Amaranth> I guess he is handling compiz settings in lucid so I need to talk to him before I drop extrawm from the defaults so we can push compiz-fusion-plugins-extra out to universe


[15:01] <juliank> o/
[15:02] <waveform> o/
[15:02] <bdmurray> o/
[15:02] <rbalint> o/
[15:03] <juliank> #startmeeting Weekly Ubuntu Foundations team
[15:03] <meetingology> Meeting started Thu Aug 15 15:03:02 2019 UTC.  The chair is juliank. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:03] <meetingology> Available commands: action commands idea info link nick
[15:03] <juliank> #topic Lightning rounds
[15:03] <juliank> echo $(shuf -e vorlon bdmurray xnox tdaitx doko sil2100 rbalint infinity cyphermox mwhudson juliank waveform)
[15:03] <juliank> bdmurray tdaitx vorlon mwhudson doko infinity xnox sil2100 juliank rbalint waveform cyphermox
[15:04] <bdmurray> finished conversion of daisy to python-cassandra (not retracer code though)
[15:04] <bdmurray> submitted MP and RT regarding updating daisy in production (x2)
[15:04] <bdmurray> discovered that daisy wasn't really updated in production / got it done again
[15:04] <bdmurray> research into daisy w/ python-cassandra causing OOM kills
[15:04] <bdmurray> reverted daisy to previous version without python-cassandra
[15:04] <bdmurray> resolved issue with Error Tracker daily user count cronjob
[15:04] <bdmurray> review of u-r-u MP regarding calculating snap size requirements
[15:04] <bdmurray> fixed a Traceback when writing to CouldNotBucket in cassandra
[15:04] <bdmurray> triage of ubuntu-bug failing LP: #1814611
[15:04] <bdmurray> review of MP regarding sru-report re: block-proposed tag
[15:04] <bdmurray> something of a short week as I was out yesterday
[15:04] <bdmurray> ✔ done
[15:05] <bdmurray> no tdaitx
[15:05] <bdmurray> vorlon: ?
[15:05] <vorlon> oh noes
[15:05] <vorlon> ok
[15:05] <vorlon>  * discussions around secureboot on ARM for a customer
[15:06] <vorlon>  * proposed-migration
[15:06] <vorlon>   * includes kicking off the mysql8 transition and trying to address long-stuck packages
[15:06] <vorlon>  * reviewing an ubuntu-image request from sil2100
[15:06] <vorlon> * NEW reviews in SRU
[15:06] <vorlon> (done)
[15:07] <doko> no mwhudson ...
[15:07] <doko> * back from vacations
[15:07] <doko> * catch up with things
[15:07] <doko> (done)
[15:07] <juliank> No infinity
[15:07] <juliank> xnox:
[15:08] <xnox> * uc20:
[15:08] <xnox>   consoleconf & core20 now works
[15:08] <xnox> * s390x stuff:
[15:08] <xnox>   bug #1837016
[15:08] <xnox>   bug #1836532
[15:08] <xnox>   bug #1839123
[15:08] <xnox>   bug #1835048
[15:08] <xnox> * atlas progressing on z14 optimizied builds
[15:08] <xnox> done
[15:08] <xnox> next
[15:09] <juliank> sil2100 is out
[15:09] <juliank> It's my turn
[15:09] <juliank> .. some weird clicking later ..
[15:09] <juliank>  * uploaded gpgme1.0 to bionic to fix FTBFS there (LP: #1813581)
[15:09] <juliank>  * otherwise, it's been kind of an *apt* week.
[15:09] <juliank>  * released apt 1.8.3, (fake-ish)-synced to disco, 1.8.3~deb10u1 for Debian stable (LP: #1838771 amongst others)
[15:09] <juliank>  * fixed a segmentation fault introduced in apt 1.9.2 (https://salsa.debian.org/apt-team/apt/merge_requests/73, LP: #1839714)
[15:09] <juliank>  * wondering why dpkg SRU was released on disco and xenial but not bionic (that's not a sane order ;))
[15:09] <juliank>  * learned more about AppStream and what the needs are on a package management daemon side
[15:09] <juliank>  * started preparing to run black on python-apt code
[15:09] <juliank> also as a special announcement: APT PATTERNS (for packages) ARE HERE! (https://salsa.debian.org/apt-team/apt/merge_requests/74)
[15:09] <juliank>  * Purge config files: apt purge ?config-files
[15:09] <juliank>  * Remove autoremovable packages: apt remove ?garbage
[15:09] <juliank>  * Install packages with weird queries: apt install ?or(?name(^apt$),?and(?true,?false))
[15:09] <juliank>  * Show all upgradable packages: apt-cache show ?upgradable
[15:09] <juliank>  * Caveats: It's not working for search and inside preferences files so far
[15:10] <juliank>  * https://people.debian.org/~jak/apt-search-terms.html contains more info (but is badly rendered; it's apt-patterns(5) manpage).
[15:10] <juliank>  * Patterns for versions coming at a later point, but trying to get them in before feature freeze
[15:10] <juliank>  * Will be writing a blog post about that stuff, it's super exciting.
[15:10] <juliank> (done)
[15:10] <juliank> rbalint:
[15:10] <rbalint> * tried to migrate a 243-rc1 then got it dropped from eoan-proposed and rebuilt rev deps that needed that
[15:10] <rbalint> * now preparing 241 for eoan and continuing fixing up 243 for eoan+1
[15:10] <rbalint> * partner work
[15:10] <rbalint> (done)
[15:10] <waveform> * Pi 4 boot:
[15:10] <waveform> * Got u-boot working reliably across pi versions but only with conditional sections (separate u-boot for 2, 3, and 4); still no fb or kbd for u-boot on pi4 though (lacking drivers)
[15:10] <waveform> * Tidying up mkknlimg usage by pi for bug #1805668 (appears mkknlimg is no longer required; have removed it apparently successfully from the experimental u-boot package)
[15:10] <waveform> * Got a kernel working with both pi3 and pi4 \o/ (still stripping out irrelevant patches)
[15:10] <waveform> * Kernel appears fully functional on the 3, but not fully on 4 (ethernet and framebuffer working, but neither USB2 nor USB3 - lacking some config)
[15:10] <waveform> * With a bit more work should be possible to have a single classic distribution that works on all (supported) pi platforms
[15:10] <waveform> * Upgrade path for older versions is under consideration
[15:10] <waveform> (done)
[15:10] <cyphermox> I was out Friday, Monday and Tuesday.
[15:11] <cyphermox> visited wineries, looked at Legos and stuff
[15:11] <cyphermox> preparing netplan release
[15:11] <cyphermox> (done)
[15:12] <juliank> I guess no questions on status?
[15:12] <juliank> #topic Release incoming bugs (eoan)
[15:12] <juliank> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ee-incoming-bug-tasks.html#foundations-bugs
[15:13] <bdmurray> bug 1840122
[15:15] <xnox> bdmurray:  so, we had those squashfs error on subiquity iso during disco release.
[15:15] <xnox> bdmurray:  the "fails to reboot" i wonder if it's again "waiting for someone to press enter"
[15:15] <vorlon> finalrd?
[15:16] <xnox> because the squashfs_read_data hides the messages.
[15:16] <vorlon> are we doing finalrd yet?
[15:16] <xnox> hmmmm
[15:17] <xnox> i remember writting a finalrd hook, but i can't remember if i shipped it or not
[15:17] <vorlon> I'm sure you didn't
[15:17] <vorlon> something something late in cycle
[15:18] <vorlon> so do we want to commit to this?
[15:21] <xnox> apw:  remember squashfs errors during disco sprint on subiquity image? now happening on regular desktop image too as reproduced by jibel......
[15:21] <xnox> apw:  did we ever look into squashfs, as in are we building them wrong? is media bad? or kernel too strict?
[15:21] <juliank> #topic Release incoming bugs (bionic)
[15:21] <juliank> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-incoming-bug-tasks.html#foundations-bugs
[15:22] <apw> xnox, i remember vaguly, do we have an example of a thing which is bad ?
[15:23] <vorlon> [ACTION] xnox and apw to get to the bottom of LP: #1840122 and report back
[15:23] <meetingology> ACTION: xnox and apw to get to the bottom of LP: #1840122 and report back
[15:23]  * apw fades into the backgroun
[15:24] <gaughen> d
[15:26] <apw> *a spooky voice says* "its there bug faded out"
[15:26] <juliank> that's what I said!
[15:29] <vorlon> the only bug there is a 'low' systemd bug that appears to be in someone else's hands, not for us
[15:29] <vorlon> move on?
[15:29] <juliank> ok!
[15:29] <juliank> ?
[15:30] <xnox> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1837700
[15:30] <xnox> Need fix landing in bionic before 31st of August.
[15:34] <xnox> ddstreet:  can we chat about systemd SRU bugs? they don't quite make sense to me, and I'm not sure if things were tested on non-dell systems, and like upgrades from xenial with ifupdown.
[15:34] <xnox> juliank:  NEXT
[15:34] <juliank> #topic Team proposed-migration report
[15:34] <juliank> #link http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#foundations-bugs
[15:35] <cyphermox> I'm already looking at pyyaml (since last week)
[15:35] <rbalint> prometheus-blackbox-exporter can't be installed and to fix it it needs breaking a build cycle
[15:35] <rbalint> i'm already on it
[15:35] <ddstreet> xnox sure anytime
[15:36] <juliank> cyphermox: hang on, I have a card for that
[15:36] <cyphermox> juliank: ok, well it's /mostly/ rerunning the tests with the right trigers
[15:37] <rbalint> can i just badtest prometheus-blackbox-exporter for a little to migrate debconf?
[15:38] <gaughen> are we talking btrfs?
[15:38] <vorlon> btrfs-progs: xnox has already got an mp to curtin for this
[15:38] <vorlon> so that's in progress
[15:38] <gaughen> cool
[15:38] <juliank> what's broken there? it says candidate
[15:38] <seb128> vorlon, xnox, apw, commenting a bit later, but that reboot issue is what is making daily ISO testing fail in UTAH and daily-proposed desktop not moving to current (so would be nice to get to the bottom of it)
[15:38] <gaughen> then the debconf one
[15:38] <vorlon> rbalint: if prometheus-blackbox-exporter can't be installed, is that an autopkgtest failure that we should ignore?
[15:38] <gaughen> rbalint has debconf
[15:38] <xnox> seb128:  ah, interesting! thanks.
[15:40] <vorlon> prometheus-blackbox-exporter badtest added
[15:40] <vorlon> golang-defaults, I've previously flagged to mwhudson's attention
[15:40] <gaughen> vorlon, I'll put on his plate
[15:40] <vorlon> juliank: you know to look in update_output.txt for things that are lingering in 'candidate'?
[15:40] <juliank> vorlon: no
[15:41] <vorlon> juliank: 'candidate' only means that this package meets all the policies (built, tests) for it to be considered for migration.  It can still block, if migrating it would make other packages uninstallable
[15:41] <vorlon> and that information is in update_output.txt
[15:42] <juliank> skipped: btrfs-progs (9, 33, 80)
[15:42] <juliank>     got: 41+0: a-16:a-7:a-7:i-5:p-3:s-3
[15:42] <juliank>     * amd64: curtin, subiquity, subiquity-tools
[15:42] <juliank> that's super readable
[15:42] <vorlon> ;)
[15:42] <juliank> Can't we have britney output that to the html
[15:42] <vorlon> no
[15:42] <vorlon> it's a completely second pass
[15:42] <juliank> ugh
[15:42] <juliank> not a good ux :D
[15:42] <vorlon> nope
[15:42] <vorlon> but it's what exists today
[15:43] <cyphermox> I had started discussing that with upstream
[15:43] <cyphermox> (ie. outputting some json or whatnot that could then be used)
[15:43] <vorlon> also that file is basically log output of a process that may run multiple times
[15:43] <cyphermox> yeah :/
[15:43] <juliank> anyway...
[15:43] <cyphermox> and outputting it is performance-sensitive
[15:43] <vorlon> anyway, something better would be nice, but is non-trivial :)
[15:43] <vorlon> yes
[15:44] <juliank> let's continue with libvpx?
[15:44] <vorlon> libvpx is a library transition; seb128 was looking at it the other day
[15:44] <cyphermox> I kinda half know what I'm getting into there, but I'm volunteering to help seb128 with it if necessary
[15:44] <seb128> I didn't get far and I'm off tomorrow so if someone wants to look as well please do
[15:44] <vorlon> ffmpeg had a failing autopkgtest on armhf; xpra fails on ppc64el; and it's entangled with mysql via mythtv (which might be transiently removable)
[15:45] <cyphermox> we can still move it forward a bit
[15:45] <seb128> ffmpeg got updated to a new version at the same time as the libvpx update, we would try the previous version on armhf to see if that one works
[15:46] <gaughen> thanks cyphermox
[15:46] <seb128> I wanted to do that today but didn't get to it
[15:46] <juliank> python-tz caused pandas to regress
[15:47] <vorlon> juliank: python2-only regression?
[15:47] <vorlon> do we resolve that by dropping python2 from pandas? :)
[15:47] <juliank> unittests            FAIL non-zero exit status 137
[15:47] <juliank> unittests3           PASS
[15:47] <juliank> I mean looks like it
[15:48] <vorlon> there are a few revdeps that would need unwinding, but it's tractable and probably a better use of time than fixing the python2-specific ppc64el pandas test failure
[15:49] <juliank> ../../../usr/lib/python2.7/dist-packages/pandas/tests/series/test_analytics.py::TestSeriesAnalytics::test_isin Killed
[15:49] <xnox> http://autopkgtest.ubuntu.com/packages/p/pandas/eoan/amd64 -> triggered by pytest => fails in both py2 and py3
[15:49] <xnox> because of newer pytest
[15:50] <xnox> https://pandas-docs.github.io/pandas-docs-travis/whatsnew/v0.25.0.html
[15:51] <vorlon> a volunteer to drop python2 support for pandas and its revdeps?
[15:51] <gaughen> do it vorlon
[15:51] <vorlon> ok
[15:51] <vorlon> I'll take it
[15:53] <gaughen> aptdaemon
[15:53] <juliank> So
[15:53] <juliank> this was passing once
[15:53] <juliank> it normally does not
[15:53] <juliank> there is some weird hang on arm64 most of the time
[15:53] <vorlon> once upon a time once, or exactly once once?
[15:53] <vorlon> so it's flaky and we should badtest it?
[15:54] <juliank> and it's only regressing now because it suddenly passed
[15:54] <juliank> yeah
[15:54] <rbalint> juliank, i'm adding a badtest
[15:55] <xnox> http://autopkgtest.ubuntu.com/packages/m/mysql-connector-c++ good url
[15:57] <rbalint> hints for today https://code.launchpad.net/~rbalint/britney/autopkgtest-eoan-hints/+merge/371356
[16:01] <juliank> let's skip the rest of the list, it's getting long
[16:01] <juliank> #topic Chair selection for next meeting
[16:01] <cyphermox> I volunteer
[16:01] <juliank> acknowledged!
[16:01] <juliank> #topic AOB
[16:02] <juliank> any other business?
[16:02] <vorlon> rbalint: merged; were you going to add mysql-connector-c++ hints also?
[16:03] <rbalint> vorlon, i pushed that as well a few secs ago :-)
[16:03] <vorlon> ok
[16:03] <rbalint> i'm rebasing
[16:03] <rbalint> a sec
[16:03] <vorlon> rbalint: you forgot the word 'force-badtest' at the start of that hint ;)
[16:04] <rbalint> ahh
[16:04] <vorlon> juliank: no other business
[16:04] <juliank> #endmeeting
[16:04] <meetingology> Meeting ended Thu Aug 15 16:04:17 2019 UTC.
[16:04] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2019/ubuntu-meeting.2019-08-15-15.03.moin.txt
[16:04] <vorlon> thanks, all!
[16:05] <rbalint> vorlon, fixed the hint, thanks!
[16:07] <vorlon> and re-merged
[16:07] <vorlon> xnox: ^^ see? that easy


[03:29] <JoseeAntonioR> Hello, guys! I'm organizing this OpenWeek, and I'd like to know if any of you is willing to do a 1-hour session explaining what you do and what can people do for the Kernel Team. Schedule is here: https://wiki.ubuntu.com/UbuntuOpenWeek/quantal/Timetable Thanks!
[21:19] <zenx> Hi how can I find out if a device is suported by the kernel. In this case a nic card with chipset AR8032
[21:19] <zenx> i did a grep in th kernel source but nothing, does this mean it probably isnt supported?
[22:08] <lamont> why are migration/N taking up about 10% of the cpu(s) each?


[00:28] <astraljava> len: I wouldn't concentrate much on packaging the docs. By nature, they're bound to change (link URLs, contents), so you would have to update the package every time someone updates a wiki, for instance.
[00:29] <astraljava> len: Just a pointer to Studio wiki should be enough, and users should be able to navigate from there.
[00:30] <astraljava> len: But otherwise, a HUGE THANK YOU for spending time on docs!
[00:31] <astraljava> len: I'll try to participate, too, but it seems every time I am almost catching a break, something awry happens, and I have to concentrate on something else.
[01:18] <len> astraljava: So you want this stuff on the wiki then?
[01:51] <astraljava> len: It'd be easier, maintenance-wise, but I'm not adamant on this.
[01:58] <len> astraljava: Not having any idea what I would have to go through
[01:59] <len> to update a package...
[01:59] <len> The creation would not be hard, getting it on the repository might be.
[02:00] <len> At least it seems that way...
[02:06] <astraljava> len: Making the package isn't hard. Getting it into the repository isn't hard either. But having it updated every time something changes in the docs would be tiresome.
[02:07] <astraljava> len: Unless you just packaged links to the docs somewhere, in which case it becomes redundant, and quite frankly, useless.
[02:52] <len> astraljava: I guess I should just try keeping up with it as a link.
[02:53] <len> Some of the info has been the same for long time so I wasn,t thinking it would need that much updating.


[00:05] <Ankman> ah, dpkg
[00:06] <clache> Ankman: With dpfg -i. Or with gdebi in graphic.
[00:07] <clache> *dpkg i-
[00:07] <Musashimaru> Ankman, click on it.... :)
[00:08] <Musashimaru> then click install :)
[00:08] <Musashimaru> This is too difficult... :)
[00:09] <Ankman> install "was greyed out
[00:09] <Ankman> anyway, instaled gmail phone plugin
[00:10] <Ankman> now need someone to ocall ;-)
[00:16] <clache> "Gdebi est installé par défaut dans Ubuntu versions 8.04 LTS à 10.04 LTS.  Dans les versions ultérieures d'Ubuntu, les fonctions d'installations  de paquets locaux sont désormais intégrées à la Logithèque Ubuntu; Gdebi n'est donc plus nécessaire. " <----Il était encore présent sur lubuntu 11.10 qui n'avait pas la logithèque mais synaptic. Plus dans la 12.04.
[00:20] <Ankman> scanning myself (ubuntu) from my server in the intranet i get only port 3689 "rendezvous" open
[00:20] <Ankman> wonder what that is
[00:20] <Ankman> more important. will i get laid tonight? ;-)
[01:04] <Musashimaru> Ankman, usually it is greyed because of unsatisfied dependency
[01:06] <Ankman> i assume because i wasn't root
[01:06] <Ankman> it installed without problems using dpkg -i
[01:07] <Musashimaru> Ankman, usually it asks for root password when you click install... but never tried on 12.04
[01:08] <Ankman> it didn't :-)
[01:08] <Ankman> i assume when i reboot (is usb stick) it is all gone again
[01:08] <Ankman> just wanna test if gmail phone works. not installing this plugin on a "real" linux as i don't trust googe
[01:09] <Ankman> google
[01:15] <Musashimaru> ok, Teletoon is dead... no Simpsons
[01:30] <Ankman> oooh
[01:30] <Ankman> dead?
[01:33] <Musashimaru> now it's back....
[01:53] <Ankman> good
[01:54] <Ankman> f*cking thunderstorm
[01:57] <Musashimaru> non, c'est bien l'orage
[02:01] <Ankman> getting water in here again :-(
[02:02] <Musashimaru> here too...
[02:02] <Musashimaru> that's fun
[02:27] <Ankman> in the room?
[02:27] <Ankman> that's not fun
[02:36] <Musashimaru> don't need to wake up to deink
[02:36] <Musashimaru> drink
[02:43] <Ankman> and to go fishing you don't need to leave the room