[01:35] <dantti_laptop> I can't find libqtsolutions-soap headers am I missing something?
[01:36] <ahoneybun> I'm don't have the knowledge about that
[01:40] <ahoneybun> how do you make that blue text
[06:37] <smartboyhw> Eh there are 1380 unread emails in my inbox
[06:44] <valorie> oh, I wish
[06:47] <soee> yofel, do you know whats the 4.10.3 status ?
[06:48] <smartboyhw> soee: Heck, be patient;)
[06:48] <soee> smartboyhw, one guy asked on #kubuntu when its ready
[06:48] <soee> i just wanted to give him some info :)
[06:50] <smartboyhw> soee: Should be today or tomorrow, depending on packager's time. I don't have time for packaging, I have two tests tmr:(
[06:50] <soee> smartboyhw, ok thank you
[07:57] <Riddell> dantti: we don't have libqtsolutions-soap packaged except as part of hupnp
[08:55] <Riddell> fregl: did you see the kscreen update you needed got in -proposed?
[08:55] <Riddell> hmm no it didn't, it's still in the queue
[08:57] <Phonon> invasive changes or something
[09:00] <fregl> Riddell: I don't recall asking for kscreen :) but I'll be happy to try how it will work with my external screen and tv anyway ;)
[09:03] <Riddell> fregl: you had a crash in 13.04 caused by having nvidia?
[09:03] <Riddell> kscreen causes a crash in kded on login
[09:06] <soee> kded - monster that eats my whole memory on laptop
[09:06] <fregl> Riddell: actually my crash was an outdated wayland build in /usr/local (me hides in shame)
[09:24] <Riddell> fregl: you don't get https://bugs.kde.org/show_bug.cgi?id=318907 ?
[09:26] <fregl> Riddell: no, I have the nvidia binary blob and only one screen configured with nvidia-settings on my desktop here
[09:26] <fregl> never had that crash
[09:32] <smartboyhw> Riddell: Oh good, even our bot left:(
[09:33] <Riddell> kubotu?
[09:33] <smartboyhw> Riddell: Or didn't ir?
[09:33] <smartboyhw> s/ir/it/
[09:33] <kubotu> smartboyhw meant: "Riddell: Or didn't it?"
[09:33] <smartboyhw> Oh good it didn't
[09:34] <smartboyhw> I thought I saw it leaving due to *.net *.split
[09:34] <smartboyhw> Riddell: Kubuntu 10.04 LTS and Kubuntu 11.10 will reach EOL tomorrow!
[09:41] <Riddell> ah, farewell lucid and oneiric, we knew thee well
[09:43] <smartboyhw> Riddell: LOL
[09:43] <smartboyhw> Heck, I got an EOL announcement to send for Ubuntu Studio tmr
[10:09] <smartboyhw> Riddell: I just voted for the Council election!
[10:11] <shadeslayer> smartboyhw: did you vote before I sent my reply? :P
[10:12] <smartboyhw> shadeslayee: No.
[10:12] <shadeslayer> also, you can change your vote AFAIK
[10:12] <smartboyhw> I JUST voted, 1.5 min ago
[10:12] <shadeslayer> aha :)
[10:12] <smartboyhw> shadeslayer: I won't change it unless absolutely necessary
[10:12] <shadeslayer> ack :)
[10:13] <smartboyhw> Heh, I doubt whether you guys want to know who I votedP
[10:13] <smartboyhw> :P
[10:13] <shadeslayer> Lord Vader?
[10:13] <smartboyhw> shadeslayer: Who's that? Voldemort?
[10:14] <shadeslayer> :O
[10:14] <smartboyhw> …
[10:14] <shadeslayer> kids these days
[10:14] <smartboyhw> shadeslayer: ?
[10:14] <shadeslayer> can't tell the difference between Voldemort and Lord Vader
[10:14]  * smartboyhw has been too bothered with tests this week
[10:14] <smartboyhw> shadeslayer; I don't even KNOW what is Lord Vader…
[10:14] <smartboyhw> Is it edible?
[10:14]  * shadeslayer faints
[10:15] <shadeslayer> smartboyhw: http://www.youtube.com/watch?v=8kpHK4YIwY4
[10:15] <smartboyhw> shadeslayer: Nope
[10:15] <smartboyhw> I will not watch it:P
[10:15] <smartboyhw> kubotu: send coffee for shadeslayer
[10:16] <smartboyhw> Meh wrong
[10:16] <smartboyhw> kubotu: send coffee to shadeslayer
[10:16] <smartboyhw> Meh I forgotten, just used it yesterday;(
[10:16] <smartboyhw> kubotu: help
[10:16] <kubotu> help topics: 10 core modules: auth, basics, config, filters, httputil, irclog, remote, unicode, userdata, wordlist; 57 plugins: alias, autoop, autorejoin, bans, bar, botsnack, chanserv, debug, dns, eightball, excuse, factoids, googlefight, greed, greet, hangman, host, identica, insult, iplookup, karma, keywords, lart, map, markov, modes, newpackage, nickrecover, nickserv, note, poll, q, quote, reaction, remind, ri, roshambo,
[10:16] <kubotu> rot, rss, salut, script, search, sed, seen, shiritori, spotify, time, topic, translator, tumblr, twitter, uno, urban, usermodes, wheeloffortune, wserver, youtube; 32 plugins ignored: use help ignored plugins to see why; 1 plugin failed to load: use help failed plugins to see why (help <topic> for more info)
[10:16] <smartboyhw> oops
[10:16] <shadeslayer> kubotu: order vader for kubotu
[10:16]  * kubotu slides vader down the bar to kubotu
[10:16] <shadeslayer> xD
[10:17] <smartboyhw> kubotu: order breakfast for shadeslayer
[10:17]  * kubotu slides a cigarette, a cup of hot coffee and a bagel with cream cheese down the bar to shadeslayer.
[10:17] <smartboyhw> kubotu: order dinner for smartboyhw
[10:17]  * kubotu slides dinner down the bar to smartboyhw
[10:17] <smartboyhw> Meh
[10:17] <shadeslayer> breakfast at a bar?
[10:17]  * shadeslayer passes the cigarette to apoi
[10:17] <shadeslayer> erm
[10:17] <shadeslayer> Phonon: ^^
[10:18] <smartboyhw> shadeslayer: lol
[10:19] <smartboyhw> kubotu: order Kubuntu Council votes to all Kubuntu menbers
[10:19]  * kubotu slides kubuntu council votes to all kubuntu menbers down the bar to smartboyhw
[10:19] <smartboyhw> …
[10:19] <Phonon> shadeslayer: poor apoi?
[10:19] <smartboyhw> kubotu: order Kubuntu Council vote ballots for all Kubuntu members
[10:19]  * kubotu slides kubuntu council vote ballots down the bar to all Kubuntu members
[10:19] <smartboyhw> Good
[10:20] <smartboyhw> ScottK: Use that next time ^^
[10:20] <shadeslayer> Phonon: poor? :P
[10:21] <Phonon> having to smoke because you fail to autocomplete
[10:21] <shadeslayer> ah
[10:21] <shadeslayer> he can choose not to
[10:21] <shadeslayer> it's his choice
[10:21] <shadeslayer> I need coffee
[10:21] <shadeslayer> but no milk
[10:21] <shadeslayer> someone should go shopping
[10:21] <smartboyhw> kubotu: order milk for shadeslayer
[10:22]  * kubotu slides milk down the bar to shadeslayer
[10:22] <Riddell> shadeslayer: is there a shopping list?
[10:22] <shadeslayer> Riddell: dunno, I heard there was something being formulated
[10:22] <shadeslayer> Riddell: come outside, it's really good outside
[10:23] <smartboyhw> Riddell: Is shadeslayer sitting next to you again? *sigh*
[10:23] <shadeslayer> nope, I'm outside
[10:23] <shadeslayer> with afiestas_
[10:24] <smartboyhw> shadeslayer: Oh.
[10:24] <smartboyhw> Riddell, shadeslayer, afiestas_ you guys have a shared office or what?
[10:29] <Riddell> smartboyhw: a shared gazeebo http://blogs.kde.org/2013/05/08/notes-breakout-sessions-mataro-sessions-ii
[10:34] <smartboyhw> Riddell: OK
[10:38] <smartboyhw> Riddell: I like the automated copyright file bit
[10:43] <Riddell> fregl: ping
[10:44] <Riddell> fregl: this kscreen update for nvidia, are you able to test?
[10:50] <dantti> Riddell: ok, I'll use it from git them... thanks
[11:03] <Riddell> Mirv: nice blog on qt 5 packaging :)
[11:06] <shadeslayer> Indeed ^^
[11:09] <Mirv> Riddell: thanks :)
[11:10] <afiestas_> anybody with nvidia card can help?
[11:10] <afiestas_> I will need first the output of the following command: "kscreen-console bug"
[11:24] <BluesKaj> Hello folks
[11:26] <soee> hi
[11:42] <Riddell> ScottK: for the kscreen update we are having trouble finding a nvidia tester, could it be let into -proposed and tested from there rather than testing before? (i've already tested it on intel)
[11:53] <BluesKaj> Riddell, nvidia here
[11:54] <BluesKaj> but I'm on 13.10
[11:55] <Riddell> BluesKaj: could you see if you can install the raring screen packages in saucy?
[11:56] <Riddell> download the .debs from https://launchpad.net/ubuntu/+source/kscreen and https://launchpad.net/ubuntu/+source/libkscreen and dpkg --install ?
[11:58] <BluesKaj> ok Riddell , DL'd , will install
[12:00] <markey> crashing issue in Amarok is fixed (in Git)
[12:01] <markey> turns out, it's really a bug in QtWebKit. whenever a page contains an <audio> tag, it does something with GStreamer, and that has a high probability of crashing
[12:01] <markey> this affects Rekonq too
[12:02] <BluesKaj> Riddell, kscreen installed ..reboot ?
[12:10] <BluesKaj> well. kscreen accepts my monitor configuration just fine , Riddell
[12:11] <BluesKaj> the 64 bit version , 'kscreen-dbg_0.0.92-0ubuntu1_amd64.deb'
[12:16] <smartboyhw_> Riddell: yofel: shadeslayer: apachelogger: http://www.theorangenotebook.com/2013/05/people-behind-ubuntu-quality-howard.html?m=1
[12:17]  * BluesKaj shrugs ...well anyway , it's working
[12:17] <smartboyhw_> LOL
[12:42] <Riddell> markey: oh?  able to point us to a patch/bug report?
[12:42] <Riddell> BluesKaj: you installed the raring debs and plugged in a second monitor?
[12:43] <markey> Riddell: http://lists.kde.org/?l=kde-commits&m=136800978907117&w=2
[12:44] <smartboyhw_> Good thing to SRU probably
[12:45] <BluesKaj> Riddell, no my other monitor isn't here atm , it's in our "studio" :(
[12:46] <BluesKaj> didn't realize kscreen was meant for multiple monitors
[12:48] <Riddell> BluesKaj: ah that's needed for testing for this beastie
[12:48] <Riddell> markey: know any problematic artists?
[12:49] <markey> Riddell: Deep Purple
[12:49] <BluesKaj> Riddell, FWIW I rebooted after installing and this plasma monitor works fine , still
[12:50] <BluesKaj> markey, yeah Richie Blackmore's ego :)
[12:50] <markey> hehehe
[12:51] <markey> Riddell: anyway, you can reproduce it with Rekonq too. keep reloading this page for a while: http://en.wikipedia.org/wiki/Deep_Purple
[12:52] <markey> you don't have to do anything besides reloading it
[12:56] <Riddell> yay Amarok and Rekonq crashed!
[13:19] <smartboyhw_> Riddell: lol
[13:53] <Riddell> ScottK: sru for your reviewing bug 1177781
[14:12] <ScottK> Riddell: Accepted.
[14:14] <Mamarok> wohoo!
[14:14] <smartboyhw> \o/
[14:14] <Mamarok> Riddell, ScottK: that was fast, thanks a bunch!
[14:16] <ScottK> Did homerun too.
[14:17] <Riddell> what's new in homerun?
[14:17] <Riddell> oh the bugfix version
[14:17] <ScottK> Yeah, for SRU.
[14:18] <ScottK> I'll accept libkscreen/kscreen once you get it tested.
[14:18] <shadeslayer> Riddell: http://paste.kde.org/739886/
[14:18] <Riddell> actually there was a bug in the packaging (not a new one) which shadeslayer is fixing
[14:19] <Riddell> shadeslayer: ${shlibs:Depends}
[14:19] <ScottK> Should I reject then?
[14:19] <ScottK> (and which one)
[14:21] <Riddell> ScottK: reject both please
[14:21] <ScottK> done
[14:22] <shadeslayer> indeed ^^
[14:22] <shadeslayer> ScottK: thanks
[14:22] <ScottK> no problem
[14:23] <Riddell> shadeslayer: --with=pkgkde-symbolshelper
[14:24] <Riddell> ScottK: oh also if you can look at the hedgewars SRU from debfx that would make agateau very happy :)
[14:26] <ScottK> Riddell: Done
[14:27] <shadeslayer> Kevin Ottens managed to kill Mir and Ubuntu with one KDE Class last night xD
[14:27] <shadeslayer> KAction it was IIRC
[14:27] <Riddell> but he took 7 years to do so
[14:27] <shadeslayer> true ^^
[14:28] <BluesKaj> is mir in use on ubuntu saucy yet ?
[14:29] <Riddell> BluesKaj: no we're talking nonsence
[14:30] <BluesKaj> mir is nonsense , i thought ubuntu was serious about it ?
[14:30] <debfx> there are also virtualbox uploads sitting in p- and q-proposed for way too long ... just saying ;)
[14:31] <shadeslayer> BluesKaj: you're missing some vital context :P
[14:33] <ScottK> debfx: Is any of the commenting in 1081307 a regression from what's in the release already?
[14:33] <BluesKaj> shadeslayer, I was merely asking a quesy=tion about mir , and it's not in the Kevin Ottens context, if that's what you mean
[14:33] <BluesKaj> aerr question
[14:34] <shadeslayer> ah yes, Ubuntu is pretty serious about Mir
[14:35] <debfx> ScottK: yes, it's a regression because the kernel modules don't work with the lts-backport stack
[14:35] <ScottK> debfx: Right, but is it worse if I release the SRU?
[14:42] <debfx> ScottK: so everyone says it works for them except for one person. he hasn't used the -release version with the original kernel so I don't know if it would be a regression for him.
[14:44] <ScottK> OK.  Thanks.  I'll release htem.
[14:44] <ScottK> them
[14:45] <debfx> thanks
[14:46] <Riddell> yofel: if we do another mumble call next week do you have a mumble server to do it on?
[15:20] <Quintasan> Riddell: I think we lack a important feture in wireless network management - access points priority, I don't know if it's network manager that is missing the feature or kde backend but that imo requires investigation
[15:22] <Riddell> Quintasan: what does it mean?
[15:22] <Riddell> if it sees more than one wifi hub it recognises it knows which to try first?
[15:22] <Quintasan> Yeah
[15:22] <Quintasan> I'm at my university and I'm in range of my associations network and in general university network
[15:23] <Quintasan> the latter is unencrypted and it connects to that one automagically
[15:23] <Riddell> it'll be something for the plasma widget to sort out I'd think
[15:23] <Riddell> lamarque is the dude to talk to
[15:24] <Quintasan> I see
[15:24] <Quintasan> Riddell: I'll ask him
[15:33] <Quintasan> Riddell: Can you copy over my laptop ssh key to ftpmaster?
[15:37] <kubotu> ::qt-bugs:: [1177823] qdbus needs dependency ubuntu-sdk to work @ https://bugs.launchpad.net/bugs/1177823 (by Patola)
[15:40] <Riddell> Quintasan: url?
[15:40] <Quintasan> Riddell: https://launchpad.net/~quintasan/+sshkeys
[15:49] <Riddell> Quintasan: done
[15:49] <Quintasan> Thanks
[15:50] <smartboyhw> Sleeping time, bye Kubuntu people
[15:53] <markey> what's the status of KDE 4.10.3 backport?
[15:54] <Riddell> still lots to do http://kyofel.dyndns.org/kubuntu/build_status_4.10.3_raring.html
[15:54] <markey> we have unconfirmed reports about Amarok crashing on exit with 4.10.3. I'd like to verify that
[15:55] <markey> ok
[16:06] <Riddell> ScottK: new package update in bug 1177333
[16:06] <Riddell> ScottK: confirmed by a guy who was having the nvidia crash issue (on kde bug report)
[16:06] <ScottK> Riddell: OK.  Thanks.
[16:06] <ScottK> Can't look at it now, but will later.
[16:38] <Riddell> http://starsky.19inch.net/~jr/tmp/screenshot.png
[16:40] <Riddell> Phonon: http://starsky.19inch.net/~jr/tmp/screenshot.png
[16:40] <Riddell> Phonon: oy!
[16:40] <Riddell> Phonon: you smell!
[16:41] <Riddell> Phonon: this one! http://starsky.19inch.net/~jr/tmp/screenshot.png
[16:41] <Riddell> Phonon: oy!
[16:41] <Riddell> Phonon: http://starsky.19inch.net/~jr/tmp/screenshot.png
[16:59] <Phonon> ScottK: ^ council action requested!
[16:59] <Phonon> <- hurt
[17:06] <ScottK> Phonon: Figure out what's up with Bug #918688  and your SRU in precise and then we'll talk.  Is that really verification failed?
[17:16] <Phonon> ScottK: not failed the user had a different version installed than what was proposed
[17:17] <Phonon> feel free to add a comma somewhere
[17:50] <apol> shadeslayer, Riddell: can we get kdevelop 4.5? http://userbase.kde.org/KDevelop/Install4.5
[17:50] <apol> :D
[17:56] <shadeslayer> apol: ack
[17:57] <apol> :D
[17:59] <Riddell> is bug 1175273
[17:59] <yofel> Riddell: the mumble server we used last time should still be running
[17:59] <Riddell> yofel: groovy
[18:00]  * yofel will try to get to 4.10.3 again later, AFTER he does the SRU for the plasma init script
[18:01] <Riddell> oh I was going to say kdevelop needs merged with debian but they're even more behind
[18:50] <Phonon> jtechidna: ping
[18:50] <jtechidna> Phonon: pong
[18:51] <Phonon> JontheEchidna: got time for an idea for updates?
[18:51] <JontheEchidna> Phonon: yup
[18:52] <Phonon> JontheEchidna: so, essentially we'd like to have non-security updates phased... e.g. only offered once a week
[18:53] <Phonon> and in particular so that the day of the week would be random by day of install or something like that
[18:53] <Phonon> so that updates do not always hit all users but a subset and after <14 days all
[18:53] <Phonon> well, <=8 I suppose ^^
[18:53] <JontheEchidna> yeah
[18:54] <Phonon> point being that a) right now they are too annoying and b) by offering them to people at different times we have an additional safety net in case an update goes wrong
[18:54] <Phonon> JontheEchidna: will you make that happen? ;)
[18:55] <Phonon> also I like the new updater UI, albeit I am not sure I approve of the menu in the lower left
[18:55] <sreich> why not have it default to auto install?
[18:55] <sreich> e.g. windows does that
[18:55] <Phonon> that requires larger discussion
[18:55] <Phonon> also causes massive bikeshed
[18:55] <Phonon> so meh :P
[18:55] <sreich> oh boy
[18:55] <sreich> gotta love committees ;p
[18:57] <JontheEchidna> Phonon: currently automatic update checking is controlled by /etc/cron.daily/update-notifier-common
[18:57] <Phonon> JontheEchidna: ah, and we've been thinking about defering updates to poweroff/reboot (or at least ones that involve kdelibs).... so that we don't get silly this-kio-slave-is-kaput warnings due to runtime lib cchanges and whatnot
[18:57] <JontheEchidna> er, no, wrong file :P
[18:57] <Phonon> s/reboot/poweron
[18:58] <Phonon> JontheEchidna: oh and for the phased updates.... we'd still query at a regular interval
[18:59] <Phonon> it's just that internally muon should not notify about updates unless the marker-day has passed
[18:59] <JontheEchidna> hmm
[19:00] <Phonon> so say the day is monday and an update becomes available on saturday you'd get it offered on monday along with all packages from sunday, friday, thursday, wednesday, tuesday and monday of the previous week
[19:00] <JontheEchidna> this would all have to be implemented in the kded module I suppose
[19:00] <Phonon> so I guess you'd need an internal cache of the form "package version dateitbecomesoffered"
[19:00] <JontheEchidna> and we'd need a way of deciding/recording which day to offer updates
[19:01] <JontheEchidna> then once it's that day again, offer everything upgradable as updates
[19:01] <Phonon> right
[19:02] <Phonon> so IMO simply recording the date it should be offered would be best, so they are basically on embargo until the recordDate >= currentDate
[19:03] <JontheEchidna> I'm wondering how it's better than the current option to only check for updates daily/every two days/weekly/every two weeks we currently have
[19:13] <ahoneybun> Phonon: so like a weekly email filled with the post that happened that week?
[19:14] <Phonon> JontheEchidna: you want security ASAP
[19:14] <Phonon> ahoneybun: yeah
[19:14] <JontheEchidna> Phonon: oh, right
[19:14] <ahoneybun> Phonon: sounds cool like how the email list does things
[19:14] <ahoneybun> a digest
[19:16] <JontheEchidna> Phonon: do you have any ideas on how to implement this without a week-long QTimer? (I'd imagine that'd wake up the CPU)
[19:51] <Phonon> JontheEchidna: check at startup or something
[19:51] <Phonon> and check once a day for those mad people who don't ever logout
[20:07] <Quintasan> argh
[20:14] <Quintasan> Riddell: Care to take a look at mah merge? Not feeling comfortable since I haven't done that in a long time
[20:15] <Riddell> Quintasan: who what where?
[20:16] <Quintasan> Riddell: http://paste.ubuntu.com/5645801/
[20:18] <Riddell> Quintasan: this is a diff of debian against your merged package?
[20:19] <Quintasan> yeah, I have sent a link ubuntu against merged as well but my laptop quassel must have ate it
[20:19] <Riddell> Quintasan: you need a remaining changes list in the changelog to say why there's the patch and why the plasma-widget-kdeobservatory package and why kdeplasma-addons depends are different
[20:19] <Quintasan> hmm
[20:20]  * Quintasan looks
[20:20] <Quintasan> I think the depends are just in other order
[20:20]  * Quintasan triple checks
[20:21] <Riddell> Quintasan: is trhere no ubuntu changelog from before 4.8.80?
[20:22] <yofel> that's the diff no? we last merged for 4.8
[20:23] <Quintasan> what yofel, I just checked it
[20:23] <Riddell> the diff is against debian so it should have all the old ubuntu changelog entries in it
[20:24] <yofel> oh, right
[20:24] <Riddell> Quintasan: is boost versioned in build-deps
[20:26] <Quintasan> christ I just got lost in the changelog
[20:26] <Quintasan> Riddell: It is, I'll get back to deps when I'm done with the damn changelog
[20:31] <ScottK> Phonon: OK.  That fix still needs verification then.
[20:36] <Quintasan> Wouldn't it be easier to start with Ubuntu changelog and copy the Debian entries, not the other way around Riddell?
[20:36]  * Quintasan just copied most of Ubuntu changelog
[20:39] <yofel> Quintasan: erm, there's something called 'merge-changelog'
[20:39] <Quintasan> ...
[20:39] <Quintasan> I just thought about tabbing yofel
[20:40] <Quintasan> Found it almost at the same second you pinged :P
[20:40] <yofel> heh
[20:40] <Quintasan> my god it works
[20:40] <Quintasan> We need to document the merging process yofel
[20:41] <Quintasan> AND MENTION THE DAMN TOOLS
[20:41]  * Quintasan cries at the merges he did in the past by hand
[20:41] <yofel> isn't there some motu wiki page?
[20:41] <yofel> or does that only talk bzr these days?
[20:41] <shadeslayer> heh
[20:41] <shadeslayer> merge-changelog was the holy grail of merging packages
[20:44] <Quintasan> !info libboost1.51-dev saucy
[20:44] <Quintasan> hurr
[20:45] <Riddell> 1.53 in saucy
[20:45] <Quintasan> Riddell: Thanks, why aren't we using libboost-dev?
[20:45] <shadeslayer> Quintasan: getting X is pointless
[20:45] <shadeslayer> ( on Tablets )
[20:45] <shadeslayer> we should move towards Wayland
[20:45] <shadeslayer> let's move towards wayland
[20:45] <Quintasan> wait
[20:45] <Quintasan> how is that relevant to libboost-dev
[20:45] <Quintasan> :P
[20:46] <shadeslayer> its not
[20:46] <Quintasan> don't tell me
[20:46] <Riddell> Quintasan: ubuntu has a policy of versioning boost depends so we don't get any surprises when boost version changes
[20:46] <Quintasan> well, we could keep the metapackage there and have it point at the newest one
[20:46] <Quintasan> but I'm not going to make a fuss about that
[20:46] <Riddell> debian does that
[20:47] <Riddell> but then the boost version changes and so you might get changed behavious without knkowing it
[20:47] <Quintasan> That said, the deps in the debian control a in a different order, no point changing that, we'd just get useless delta there
[20:49] <Riddell> follow debian
[20:49] <Riddell> unless there's a reason not to
[20:55] <Quintasan> Riddell: plasma-widgets-addons suggests plasma-widget-lancelot instead of recommends, do we keep the change or make it Recommends as Debian does?
[20:56] <Riddell> look at the changelog to see why it was made?
[20:56] <Riddell> we have plasma-widgets-addons on the CD
[20:56] <Riddell> so probably it was changed to suggests to not bring in lancelot which a recommends would do
[20:56] <Riddell> so yes change it
[20:57] <Quintasan> That makes sense though the changelog doesnt mention that, I'll add it
[20:58] <Quintasan> !info libscim-dev raring
[20:58] <Quintasan> hmm
[20:58] <Quintasan> we use ibus so getting rid of that as well
[21:07] <ScottK> Riddell, shadeslayer, afiestas_: libkscreen and kscreen accepted for raring.
[21:08] <Quintasan> Not sure what it does buy yay for new ksomething package!
[21:08] <Riddell> yay!
[21:08] <Riddell> Quintasan: s/new/fixed/
[21:08] <Riddell> it'l still need someone to test it in -proposed
[21:09] <shadeslayer> ^^
[21:09] <shadeslayer> someone with an nVidia card
[21:09] <Quintasan> That sounds like me
[21:10] <Quintasan> What's the bug?
[21:10] <yofel> nvidia with nvidia or nouveau?
[21:11] <shadeslayer> binary blob afaik
[21:11] <shadeslayer> look at the boog
[21:11] <shadeslayer> 1177333
[21:12] <Riddell> bug
[21:12] <Riddell> bug 1177333
[21:13] <Quintasan> ah an external monitor you say
[21:13] <shadeslayer> yus
[21:13] <Quintasan> lemme look for the dvi->vga switch
[21:15] <yofel> ok, nvidia-313 from the traces
[21:18] <Quintasan> Riddell: How many people we can send to Akademy?
[21:20]  * Quintasan test builds kdeplasma-addons
[21:27] <Quintasan> I'm afraid I don't have the dvi->vga connector
[21:27] <Quintasan> if noone tests it, I'll get some tomorrow
[21:53] <markey> eh, so Ubuntu are gonna roll their own package format?
[21:56] <Riddell> markey: um what?
[21:57] <Phonon> no
[21:57]  * Riddell worries that canonical has announced anothetr crazy plan
[21:57] <keithzg> markey: Only for the Ubuntu SDK apps; they're somewhat sandboxed and all, the underlying install process seems more like how one would install something on an apache server (plunk down in a folder). http://www.h-online.com/open/news/item/Ubuntu-SDK-apps-to-get-own-package-format-1859655.html
[21:58] <ScottK> That one actually makes sense for what they're trying to do.
[21:59] <keithzg> "That proof of concept actually uses .deb as the container format, but without using many of its features..."
[21:59] <markey> I see
[22:00] <keithzg> So, yeah. It actually does seem to make sense, and they aren't (at least yet) needlessly reinventing the wheel for it.
[22:00] <markey> http://news.slashdot.org/story/13/05/08/2038243/ubuntu-developing-its-own-package-format-installer
[22:04] <Riddell> best get JontheEchidna on the case for muon support!
[22:05] <keithzg> Yeah, sensationalist writing as always. Slashdot, never change! ;) https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/037074.html has the salient details and the start of the discussion.
[22:05] <Phonon> Riddell: I am not sure that will make sense that much
[22:05] <Phonon> SDK apps will look alien as ubuntu components have nothing to do with qt controls (i.e. desktop components)
[22:07] <Riddell> it's yet another qml toolkit no?  because there aren't enough of those
[22:07] <ScottK> One thing on the TODO is to get them to move their qtcreator plugin to a separate package.
[22:10] <keithzg> Riddel: Yup, it's different from the Plasma one, the (now defunct) MeeGo  one, the Harmattan one, the Jolla one, the Blackberry one . . .
[22:11]  * keithzg figures the the downside of QML being so easy to work with it that it makes it too tempting for entities to roll their own component sets
[22:13] <Riddell> one interesting questions is if ubiquity gets posted to ubuntu sdk would we use that frontend in kubuntu?
[22:42]  * Riddell posts http://blogs.kde.org/2013/05/08/mataro-sessions-ii-breakouts


[18:06] <yano> W8LT (the Amateur Radio Club at OSU) is hosting license exams coming up in March, but they need a minimum of 5 folks to show up. If you are interested in getting licensed (for free!) contact Deep, https://u.osu.edu/w8lt/officers/
[18:06] <yano> the date is flexible; they are coordinating which date works better for folks on their Discord


[00:33] <sistpoty> lamont, Laney: I've just given back haskell-src-exts on armel. (build appeared to have been terminated). Hope there's not a good reason to terminate the build
[00:35] <lamont> sistpoty: all the pegatron buildds are gone - I was waiting for the queue to flush before doing a mass armel giveback
[00:36] <sistpoty> lamont: ah, ok :)... just hoped that I wouldn't cause a problem like eglibc for sparc ;)
[00:36] <sistpoty> *glibc* even
[00:38] <Laney> sistpoty: I don't think it will work — check the Debian status
[00:39] <Laney> same for pandoc
[00:39] <lamont> sistpoty: glib2.0
[00:40] <sistpoty> or that :)
[00:41] <lamont> mass armel giveback done
[00:42] <lamont> well, running
[00:42] <lamont> meh.  1033 builds givenback
[00:43] <sistpoty> Laney: hm? don't see anything particular?
[00:43] <sistpoty> lamont: thanks a lot!
[00:44] <Laney> sistpoty: you don't see all of the ftbfsen?
[00:44] <Laney> particularly a timeout on armel
[00:45] <sistpoty> Laney: oh, didn't look at build status, only at bugs
[00:46] <sistpoty> lamont: is the estimation of ten days on https://launchpad.net/builders/ more or less correct?
[00:47] <sistpoty> lamont: that would mean we're very close to the border (or even after it) where we need to close the archives for publishing afaict
[00:51] <lamont> well, lots of them should ftbfs quickly, no?
[00:51] <lamont> estimation is kinda waggy, but if folks are fixing things, we may want to keep a list of what to bump up
[00:53] <ScottK> lamont: Your mass giveback should all score at 0, right?
[00:53] <ScottK> If so, it won't interfere with any uploads.
[00:53] <lamont> either zero or they get rescored - I can't remember which
[00:54] <Laney> i'd appreciate the haskell stuff being rescored
[00:54] <lamont> they're all 0 now, but wouldn't hurt to check back later. IIRC, the job that would rescore them isn't running these days
[00:55] <ScottK> Ah.
[00:55] <ScottK> That's why rebuilds haven't been jumping back up.
[00:55] <lamont> something like that
[00:56]  * lamont is a bit fuzzy on the details
[00:58] <wgrant> lamont: you're correct. queue-builder is no longer running, so retries will stick at 0 until someone pokes them manually.
[00:58] <persia> Is it a problem that they are zero?  most of my requested rebuilds have been running (albeit at low priority)
[01:01] <wgrant> It probably isn't much of a problem, no. Even ia64 is almost OK now.
[01:01] <ScottK> I don't think it's a problem, it's just a change.
[01:09] <lamont> wgrant: if it did its sql queries a bit more granularly, we might let it run more
[01:10] <wgrant> lamont: The only useful thing it does, though is... nothing?
[01:10] <wgrant> 1) Bumps score by a few points based on time in the queue. Useless.
[01:10] <wgrant> 2) Rescores retries. Worse than useless.
[01:10] <lamont> wgrant: well, it rescores builds so non-buildd-admins can get their builds bumped back up after they retry them... so all in all, I'm not sure I care to do that
[01:10] <lamont> yeah - 2) is a big -555 from me
[01:11] <wgrant> 3) Locks thousands of buildqueue rows for aaaages and breaks the world.
[01:11] <persia> Just out of curiosity, why the mass-giveback?
[01:12] <lamont> persia: because I stabbed all of haskell after we got ghc6 to build
[01:13] <lamont> installing ghc6-doc on a pegatron was a great way to generate an infinite loop outside of the timeouts
[01:13] <persia> Ah.  This makes sense.
[01:13] <lamont> so rather than find the 100ish packages affected, I just went all 5-blades on the problem
[01:14] <persia> Makes sense, although I'm expecting a good ~200 of those to ftbfs as they just failed yesterday from a not-quite-so-massive-mass-giveback :)
[01:15] <lamont> heh. yeah
[01:15] <persia> I'm also a bit surprised at the number: we only had ~150 showing on the FTBFS page.  From where come the other ~800?  Is it worth a similar mass-giveback of missing binaries for other architectures?
[01:15] <Laney> I thought haskell was almost done
[01:15]  * persia too
[01:18]  * Laney is eyeing agda with suspicion
[01:18] <wgrant> I'm not sure that buildd-mass-retry.py excludes superseded builds.
[01:19] <wgrant> So the numbers may be artificially high.
[01:19] <persia> By 800?
[01:20] <persia> But anyway, if the point is to throw stuff at the wall and see if it sticks because the builders are bored, it makes sense to me to do other architectures as well.
[01:21] <persia> (although maybe not ia64, as that likely needs considerable build-dep order unwiding to make sense)
[01:22] <sistpoty> persia: the idea for haskell is to throw things at the wall to get the next bits of packages back in a buildable state (since the dependency graph is quite complex)
[01:22] <Laney> Is that how it was done?
[01:22] <persia> sistpoty: I thought that's why we had http://orangesquash.org.uk/~laney/haskell-installability/armel.png
[01:22] <Laney> I thought we had just been giving them back individually
[01:22] <Laney> that's what I've been doing anyway
[01:23]  * persia specifically excluded haskell from the not-quite-so-massive-mass-giveback beacause of the understanding that they were being done in order
[01:23] <sistpoty> persia: yep, but there are some false positivis
[01:23] <wgrant> lamont, persia: Yeah, buildd-mass-retry.py gives back even superseded builds, which explains the vast number.
[01:23] <Laney> packages which have never built will show up as installable on that graph indeed
[01:24] <wgrant> When buildd-manager goes to dispatch most of them, it will notice and throw them away.
[01:24] <persia> wgrant: So the queue should actually process fairly quickly then?
[01:24] <sistpoty> Laney: up to a certain point, I did, yes. then things became complex since a few buildds failed to install a -doc package (segfaulted there), probably depending on the kernel version
[01:24] <Laney> sistpoty: I saw that, but I'm not sure why it would happen... ghc6-doc isn't anything special is it?
[01:25] <Laney> is it some haddock problem?
[01:25] <persia> It seemed to segfault the old buildds though.
[01:25] <Laney> or just subarch skew
[01:25] <wgrant> persia: Indeed.
[01:25] <persia> I think it was bad silicon.  The old buildds were a collection of experimental boards.
[01:25] <sistpoty> Laney: no idea, just that it worked in a later rebuild
[01:25] <Laney> fair
[01:25] <persia> The new buildds are semi-production development boards from what I understand.
[01:26] <Laney> you should me-too 527245
[01:26] <Laney> would have helped us here ;)
[01:27] <wgrant> Yes, but that's not really easy.
[01:27] <persia> Needs coding thogh, and wgrant seems to be faily busy doing other incredibly useful stuff :)
[01:27] <Laney> I never said it was
[01:28] <wgrant> OK, then "Yes, but that's not really easy, and it's probably not going to be scheduled in the next decade or three."
[01:28] <persia> heh.
[01:29] <persia> Anyway, it only takes a couple hours to run thorough all the failed builds and retry the ones that fail for that reason after testing installability.
[01:29] <persia> Probably less if I could be bothered to script it.
[01:29] <lamont> Laney: I want to say unimplented instr trap or some such
[01:29] <lamont> frankly didn't pay much attention to it
[01:30] <Laney> seems like those machines were on the way out anyway
[01:31] <persia> lamont: On another porting note: did you get a chance to try doko's fpc debs?
[01:33] <lamont> not yet, will do
[01:36] <wgrant> lamont: You used buildd-mass-retry.py for this, right?
[01:37] <lamont> yep
[01:37]  * wgrant fixes it.
[01:37] <lamont> oh, yay
[01:37] <lamont> fix == ??
[01:38] <wgrant> lamont: It retries every failed build, even those that are long-superseded.
[01:38] <lamont> oh, thanks
[01:38] <wgrant> So the build queue looks huge, but in reality most of those builds will never hit a builder.
[01:55] <lamont> persia: for future bootstrap requests, note that the standard is to build debs using $whatever, then use those debs to build a chroot to statisfy build-deps, and let LP do its thing with that - so there's always a double-build
[01:56] <persia> lamont: Right.  Unfortunately, LP doesn't have an edit feature, so I can't ever change that request, but I'll fail to mention it again when we get the next new architecture.
[01:57] <lamont> heh
[01:57] <lamont> no worries
[01:58] <lamont> armel build running
[02:00] <persia> Cool, thanks.
[02:00] <persia> With luck, we'll have fpc before the set of stuff that build-depends on it attempts rebuild again :)
[02:01] <ScottK> Speaking of boot strapping...
[02:01] <ScottK> lamont: Any thoughts about dealing with eigenbase-farrago and eigenbase-resgen?
[02:02] <ScottK> At least it's arch all, so it only needs doing once.
[02:02] <lamont> dunno
[02:03] <lamont> fire something at rt.ubuntu.com?
[02:04] <lamont> most notably, wiht instructions that work
[02:05] <ScottK> Nevermind then.  Whining on IRC is about the most caring I can muster.
[02:06] <lamont> heh
[02:06] <lamont> well, throw your whine at rt.u.c and we'll make that the testcase for my docs, then
[02:07] <ScottK> OK.
[02:08] <lamont> I'll throw in the extra instr that might be needed.  and yeah, bootstrapping is something that at least needs an RT request
[02:10] <ScottK> lamont: RT 10582
[02:10] <lamont> ta
[02:10] <lamont> thanks, even
[04:15] <slangasek> ArneGoetje: ttf-kacst-one has a conflict with the version of ttf-kacst we have in the archive; this will make DVDs unbuildable
[06:13] <ArneGoetje> slangasek: ok, will update ttf-kacst
[07:08] <slangasek> ArneGoetje: thanks (btw, ttf-kacst-one also had a Recommends: ttf-kacst, which I've gotten rid of)
[07:12] <Keybuk> the idea of recommends on fonts amuses me
[07:12] <Keybuk> that's like ttf-arial recommends ttf-times-new-roman just because they're usually used together
[07:13] <slangasek> "users who like these wingdings also enjoyed..."
[07:17] <Keybuk> heh
[07:17] <micahg> thanks for dojo slangasek
[07:17] <Keybuk> ttf-ms-comic-sans Recommends euthanasia
[07:18] <slangasek> micahg: thanks to ScottK - I just pushed the button :)
[07:28] <slangasek> mdke: hi, do you have an ETA for final uploads of ubuntu-docs and gnome-user-docs for 10.04?
[07:49] <tjaalton> slangasek: am i pushing too far, or should we get the final round of changes from debian xserver & input drivers? :) (xorg.conf.d moved to /usr/share/X11, and allows admins to have stuff in /etc/X11/xorg.conf.d)
[07:50] <tjaalton> slangasek: the xserver is also an rc for 1.7.7, though we already had most of the relevant bugfixes as separate patches
[07:53] <ArneGoetje> slangasek: https://code.edge.launchpad.net/~arnegoetje/ubuntu/lucid/ttf-kacst/ttf-kacst-lucid/+merge/23625 and https://code.edge.launchpad.net/~arnegoetje/ubuntu/lucid/ttf-kacst-one/ttf-kacst-one-lucid/+merge/23624
[08:22] <hunger> Anyone else getting somany "Do not show this message again" buttons in the connect/disconnect notifications that the network connected to is no longer visible since the left side of the notice is pushed off screen?
[08:23] <hunger> This is in lucid.
[08:39] <peteris> mdke, here?
[09:39] <mdke> peteris: hi
[09:40] <mdke> peteris: yesterday at about 14:30
[09:43] <peteris> allright, mixed up days :)
[09:43] <peteris> nevermind
[09:44] <mdke> peteris: you can send me a po file if it's important
[09:45] <peteris> well, it's more like 5 ot 6 po files :)
[09:45] <peteris> and they are in LP
[09:47] <peteris> mdke, nevermind then, I'm more interested if I could get them in the future 10.04.1 release
[09:48] <mdke> peteris: we'll certainly do an update this time
[09:49] <peteris> mdke, you mean on .1 release?
[09:49] <baptistemm> hello
[09:51] <mdke> peteris: yes, before that
[09:52] <peteris> cool
[09:59] <peteris> mdke, .1 will be propably in the end of Juny, right?
[10:05] <slangasek> ArneGoetje: you can't delete a file from the upstream source in a package: dpkg-source: warning: ignoring deletion of file KacstOne.ttf
[10:07] <slangasek> tjaalton: it's pretty late, but I would consider the xorg.conf.d change as time permits if you upload it
[10:09] <mdke> slangasek: today is the aim
[10:10] <slangasek> mdke: ok, cool
[10:58] <joaopinto> slangasek, we have found the issue with that dell upgrade, about 48 h later :P
[10:59] <joaopinto> "none /proc/bus/usb usbfs devgid=127,devmode=664 0 0" on /etc/fstab caused an error on mountall which somehow leads to upstart hanging
[11:02] <slangasek> ah, that bug
[11:03] <tjaalton> slangasek: yep, the server has Breaks and bumps serverminver to minimize any damage
[11:03] <slangasek> joaopinto: well, that should be assigned to the mountall package, then; I thought there was an open bug report about it, but I don't see it now
[11:03] <joaopinto> well, it will affect all users which have followed https://help.ubuntu.com/community/VirtualBox/USB
[11:04] <joaopinto> ok, will do
[11:05] <slangasek> er, well, that documentation should be fixed then, because /proc/bus/usb doesn't work in 10.04, period
[11:07] <joaopinto> slangasek, right, but having a system hanging without any clue after an upgrade can't be blamed to that doc
[11:08] <joaopinto> :P
[11:12] <slangasek> yes, that part is a mountall bug
[11:14] <joaopinto> at least now I know how to step by step uptart tasks :)
[11:18] <joaopinto> I have updated bug 565109 description
[11:18] <joaopinto> hum, cache ?
[11:18] <joaopinto> ubottu, refresh
[11:18] <joaopinto> lol
[11:27] <tormod> joaopinto, will you paste those step-by-step instructions to a wiki page, please?
[11:27] <joaopinto> tormod, yes. I am just thinking that it migh worth a different page, that page we have describes the boot process, while this new one would be troubleshoot oriented
[11:28] <joaopinto> a single page would probably get too long
[11:28] <tormod> sure, make a new page
[11:29] <tormod> maybe it eventually should go to the upstream upstart wiki
[11:30] <tormod> but having such instructions somewhere in any form would be a huge improvement
[11:40] <joaopinto> hum, is there a good reason for the recovery option to start mountall ?
[11:45] <joaopinto> it's chain of events is likely to bring problems from which you want to recover from
[11:48] <slangasek> NCommander, ccheney: OOo FTBFs on armel with a debian/rules bug
[11:48] <slangasek> dh_gencontrol -popenoffice.org-pdfimport -- \
[11:48] <slangasek>                 -v1.0+OOo`echo 1:3.2.0-7ubuntu1 | cut -d: -f2`
[11:48] <slangasek> dpkg-gencontrol: error: current host architecture 'armel' does not appear in pac
[11:48] <slangasek> kage's architecture list (i386 m68k mips mipsel powerpc s390 alpha amd64 hppa ia
[11:48] <slangasek> 64 ppc64 s390x sparc)
[12:13] <slangasek> ccheney: the OOo source package doesn't seem to be in sync with the bzr branch
[12:20] <slangasek> ccheney, NCommander: I've uploaded what I believe should be a correct fix for the OOo FTBFS - no conceivable way for me to build-test it, but it looks like the new armel buildds can fail to build OOo in < 2 days now...
[12:29] <sladen> mvo: https://bugs.launchpad.net/bugs/516727  appears still to be an upgrade breaker, even with the update-manager tweaks
[12:54] <wgrant> Odd. My Lucid laptop has been thrashing sometimes lately (no swap), and I just watched it OOM kill several things with well over 2GiB of the 4GiB of RAM apparently used as disk cache.
[12:55] <wgrant> drop_caches does not reduce that volume :(
[12:58] <james_w> wgrant: ogra is having similar sounding issues in bug 563879
[12:59] <wgrant> Hmm.
[12:59] <wgrant> wgrant@magrathea:~/launchpad/lp-branches/bug-565739-dont-retry-superseded-builds$ cat /proc/dri/0/gem_objects | grep object\ bytes
[12:59] <wgrant> That cannot be normal.
[12:59] <wgrant> -1296973824 object bytes
[13:00] <wgrant> It also looks like almost 3GB when interpreted unsigned.
[13:00] <james_w> certainly sounds suspicious
[13:11] <tormod> wgrant, sarvatt also saw this gem_object wrapping negative
[13:12] <hyperair> wgrant: that sounds like an ancient i915 bug.
[13:12] <hyperair> i used to see that.
[13:12] <tormod> and vish in bug 563400 has more > 1gb gem (on ATI)
[13:13] <hyperair> wgrant: try using a newer kernel and see if that happens
[13:13] <hyperair> wgrant: also, restarting X should clear this gem_object madness
[13:14] <tormod> hmm ogra is also using chromium, like vish was
[13:15] <wgrant> hyperair: It has cleared it, yes.
[13:15] <wgrant> I had a similar thing around the GEM switch.
[13:15] <wgrant> But not significantly since.
[13:16] <wgrant> I don't use Chromium much, but I did use it at one point during that session.
[13:16] <hyperair> wgrant: so did i. and ever since the bug was fixed upstream, i've used a custom kernel, and have never had this problem again
[13:16] <hyperair> wgrant: i found that it needed somewhere around one X restart a day, during the time of that problem
[13:17] <hyperair> wgrant: we're shipping an old DRM stack aren't we?
[13:17] <wgrant> hyperair: I had to restart X multiple times a day.
[13:17] <wgrant> But it hasn't been that bad since -- maybe once a week?
[13:17] <tormod> hyperair, we're shipping a .33.2 drm stack
[13:18] <hyperair> tormod: weird, i could have sworn .33 had it all fixed..
[13:18] <wgrant> (this is a GM45, btw)
[13:18] <hyperair> and mine a 965GM
[13:18] <hyperair> regression perhaps?
[13:18] <hyperair> wgrant: there's an option in driconf about buffer object reuse
[13:18] <hyperair> perhaps that is related?
[13:19] <wgrant> I guess I should get something to monitor the GEM memory usage and scream if it jumps suddenly.
[13:19] <wgrant> Although I guess it's more likely to be a cumulative problem.
[13:20] <hyperair> wgrant: from my experiences during that time, it never jumped suddenly.
[13:20] <hyperair> something like a terminal open with watch cat /proc/dri/0/gem_objects would do
[13:21] <wgrant> That is exactly what I've been doing, yeah.
[13:27] <tormod> the gem objects are allocated all the time, that is normal, but it seems they are not all deallocated
[13:27] <wgrant> Right.
[13:33] <tormod> every time I open a youtube fan in firefox and close it again, firefox has grown 2MB, gem count as well. after closing firefox, I got only 1MB back there
[13:38] <tormod> for t in `seq 1 10`; do firefox ; grep "object bytes" /sys/kernel/debug/dri/0/gem_objects; done # and press ctrl-Q's
[13:42] <tormod> I can use e.g. eog /usr/share/backgrounds/ instead of firefox
[13:45] <joaopinto> slangasek, I am still playing with the mountall issue, it seems to be related to bug 553290
[13:45] <wgrant> tormod: So it looks like a general thing -- just Flash is really good at it?
[13:46] <joaopinto> ops, wait, maybe not, this is a side effect of starting the mountall manually, I am hitting this bug
[13:46] <tormod> wgrant, yes even "xterm" does the job
[13:46] <tormod> and X does not grow
[13:46] <joaopinto> I get both a failed mount, and skipping mount
[13:46] <joaopinto> looping
[13:47] <wgrant> tormod: Hmm, indeed. That grew the GEM object size by 100MB, and it has not decreased.
[13:47] <wgrant> At least we can easily reproduce it now...
[13:48] <wgrant> This really reminds me of the early days.
[13:48] <wgrant> But I cannot remember exactly when it started happening again.
[13:49] <tormod> the early days when we had flies amid the vacuum tubes?
[13:50] <wgrant> tormod: Heh, not going *quite* that far back.
[13:55] <tormod> you can also track it here: awk '/name/{ i++; s+= $4 } END{print i " " s}' /sys/kernel/debug/dri/0/gem_names
[13:57] <wgrant> Which are we treating as the One True Bug?
[13:58] <tormod> none I think , they are all blaming different things. the "-ati" bug even got "fixed" by an ati release, then reopened
[13:59] <wgrant> Yeah, I saw that...
[13:59] <wgrant> Anyway, I'm sort of glad that I'm not alone and/or crazy.
[15:08] <vish> yay ,I'm not alone.. :p
[15:09] <vish> wgrant: so the bug is actually in which package?  Bug 563400 is not -ati?
[15:15] <juliank> Why don't I have the permission to access  bug 538253?
[15:18] <azeem> juliank: could be an security issue, some of them are private AFAIK
[15:18] <vish> juliank: seems no one other than the reporter are subscribed
[15:19] <vish> or maybe what azeem said ..
[15:20] <juliank> azeem, vish - "There was a changelog entry:     - make sure to record the maintainer script that requested the  reboot in /var/run/reboot-required.pkgs (LP: #538253)" , and now I don't know the reason for it.
[15:20] <juliank> that's bad.
[15:23] <tormod> wgrant, vish, I thought I would make a master bug 565981, although I do not know if this gem count really pinpoints the issue
[15:24] <vish> wfm :)
[15:36] <strange> is this the place to discuss bugs?
[15:37] <tormod> strange, in most cases not, try #ubuntu or (#ubuntu+1 for lucid)
[15:37] <strange> i've tried #ubuntu thats a no go heh
[15:38] <SwedeMike> strange: if you have registered a bug on launchpad, going to #ubuntu-bugs might help.
[15:39] <strange> ok thank you
[16:18] <joaopinto> slangasek, isn't bug 543251 a duplicate from bug 507881 ?
[17:08] <ArneGoetje> slangasek: I have new language-packs ready... do you want them?
[17:22] <nhandler> ScottK: Bug #564070 has a debdiff
[17:22] <joaopinto> mountall/plymouth is seriously broken :(
[17:29] <Keybuk> joaopinto: WFM
[17:29] <joaopinto> Keybuk, it means I have been playing with it the last couple of hours and is not reliable :P
[17:31] <joaopinto> my last experiment was with some invalid entry on /etc/fstab, wrong filesystem type, missing mount poing, .. tested several reboots, and it just hang on the splash screen
[17:31] <joaopinto> on my last reboot it did show the failure prompt (as expected)
[17:32] <Keybuk> joaopinto: it's worked for me reliably every time
[17:32] <joaopinto> Keybuk, being reliable for you that dot make it reliable in general :)
[17:32] <Keybuk> being unreliable for you doesn't make it unreliable in general
[17:32] <Keybuk> joaopinto: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
[17:33] <joaopinto> Keybuk, I am not alone, anyway this comes from debugging the virtualbox proc usb issue
[17:33] <joaopinto> which is affecting >20 people :P
[17:33] <Keybuk> I'm sorry, but my INBOX disagrees with you
[17:34] <persia> So, let's not argue about this.
[17:34] <Keybuk> the only know triaged bug with mountall is with NFS root filesystems
[17:34] <persia> joaopinto: Please file detailed bugs.
[17:34] <joaopinto> Keybuk, it's hard for your INBOX to get mails from unskilled people which can't boot a system ;)
[17:34] <joaopinto> persia, I am just commenting, the bugs are filled, I am not complaining, I am just expressing myself
[17:34] <persia> Keybuk: Please acknowledge that mountall is very fast, but not necessarily careful at protecting users from shooting themselves in the foot with the right configuration.
[17:34] <Keybuk> joaopinto: do you have --debug output from a boot?
[17:35] <Keybuk> persia: I do not acknowledge that, I spent a very long time making mountall *careful*
[17:36] <joaopinto> Keybuk, I tried --debug, I got the debug on the console after hitting "ESC", which got me in text mode, but /var/log/boot.log was empty
[17:36] <Keybuk> joaopinto: bug #507881 ?
[17:36] <joaopinto> Keybuk, bug 507881 is reproducible on a virtualbox system
[17:36] <joaopinto> yup, that was I have spent more time with
[17:37] <Airells> hi , i have created simple app using qtcreator ( gui app ) what is the simplest way to create .deb now ? dh-make ?
[17:37] <Keybuk> I just commented on that asking for more information
[17:37] <joaopinto> then I decided to play with random errors on fstab, with random results
[17:37]  * Keybuk doesn't have virtualbox
[17:38] <joaopinto> Keybuk, I am reinstalling my vbox with a daily cd, I played too much with my /etc/init :P
[17:38] <persia> Airells: Depending on your taste, either that, or manual generation of the 4 packaging files: the folks in #ubuntu-packaging would be glad to help you through it.
[17:38] <Airells> pecisk thx
[17:38] <Airells> persia thx
[17:39] <joaopinto> Keybuk, but I have tried  "/something 	/somewhere somefs defaults 0 0" on my real hw :P
[17:41] <Keybuk> hmm
[17:41] <Keybuk> when it hangs, where does it hang?
[17:41] <joaopinto> Keybuk, wouldn't be safer for the recovery mode to not trigger mountall ?
[17:41] <joaopinto> Keybuk, mountall
[17:42] <Keybuk> not really, cause then you wouldn't get any mounted filesystems ;)
[17:42] <Keybuk> no, I mean where in the boot process?
[17:42] <Keybuk> what do you see on screen?
[17:42] <joaopinto> Keybuk, at that time you do have the root filesystem, mounted from the jernel, that's "recovery" ;)
[17:42] <joaopinto> ah, splash screen
[17:42] <joaopinto> always moving
[17:42] <Keybuk> so you do see the splash screen?
[17:42] <joaopinto> yes
[17:42] <joaopinto> btw, ATI fglrx
[17:42] <Keybuk> that's kooky then
[17:46] <joaopinto> Keybuk, recovery would be safer without mountall, because as you know it triggers several services, making optional (the personc could issue the start for it) would make it usable on more cases
[17:47] <joaopinto> the mountall could even be an option on the recovery menu
[17:47] <Keybuk> joaopinto: we're kinda getting rid of the "current" recovery mode
[17:48] <Keybuk> since mountall does a large part of it already
[17:48] <Keybuk> e.g. when filesystems fail, mountall lets you run fsck -y, or skip them, etc.
[17:48]  * persia is impressed by the detailed set of special-casing in mountall, and clearly ought check fresher code before making accusations based on hearsay.
[17:48] <Keybuk> persia: that's why I get frustrated at people; mountall is about a thousand times *better* than the crappy shell scripts we had before
[17:49] <Keybuk> sure, there might be bugs, but it's not a crap piece of code - it's a very carefully planned and written piece of code :p
[17:49] <persia> Indeed.  I always agreed it was better.  I just didn't think it was perfect yet.
[17:49] <Keybuk> well, no code is ever perfect
[17:49] <Keybuk> the only perfect code is the code you've removed
[17:49] <joaopinto> Keybuk, so there will be another option to boot with minimal services ? as I see it recovery is not mainly for fs recovery, it has a large use for services related recovery
[17:49] <persia> heh
[17:49] <Keybuk> joaopinto: I think we'll have something like
[17:49] <Keybuk> Start apache [y/n/d/?]
[17:50] <Keybuk> Received starting apache event, Start tomcat? [y/n/d/?]
[17:50] <Keybuk> et.c
[17:50] <joaopinto> ah, that would be great
[17:50] <joaopinto> brb, installing the vbox, will try to get that log
[17:52] <Keybuk> joaopinto: http://launchpadlibrarian.net/44707171/2010-04-18%2009.46.53.jpg
[17:52] <Keybuk> that's what you're supposed to see
[17:53] <ion> My plymouth doesn’t show the shirt. :-(
[17:53] <Keybuk> ion: you have to buy that separately
[17:55] <nigelb> Keybuk, :)
[17:57] <Keybuk> Processed 265456 of 577332 files (12h 45m 58s remaining).
[17:57] <Keybuk> whew....
[18:00] <ScottK> nhandler: I've got no keys for several hours, so please subscribe ubuntu-sponsors and I'll look at it when I get back to my keys if no one else does.
[18:01] <ion> keybuk: What’s that?
[18:01] <Keybuk> ion: importing my e-mail into notmuch
[18:02] <Keybuk> then going to run some experiments as to just how fast it is
[18:02] <ion> Ah
[18:02] <Keybuk> and if it's as awesomely fast as I hope, stick webkit on the front and write a GUI
[18:05] <Keybuk> I did some experiments on Friday
[18:06] <Keybuk> it suggested "all unread emails from Launchpad on bugs that I'm assigned to, and include the rest of the threads" would be of the order of a quarter of a second to run
[18:09] <joaopinto> Keybuk, pristine install on a vbox after adding the proc usb line: http://www.ubuntu-pics.de/bild/52848/screenshot_003_3Ouok9.png
[18:10] <Keybuk> ah
[18:10] <joaopinto> Keybuk, and just to be clear, I am testing on a virtualbox environment, but the original reportees where using real systems
[18:10] <Keybuk> now that's more like what I'd expect
[18:10] <Keybuk> when you said you saw the splash screen, that confused me
[18:10] <joaopinto> Keybuk, that is another case, the invalid entry
[18:11] <joaopinto> one bug at a time :)
[18:11] <Keybuk> can you give an example of "invalid entry" ?
[18:11] <joaopinto> let me try it on virtualbox now
[18:11] <Keybuk> also what kind of invalid entry are you putting in?
[18:11] <joaopinto>  /something 	/somewhere somefs defaults 0 0
[18:12] <Keybuk> hmm
[18:12] <joaopinto> assume it to be a major typo ;)
[18:12] <Keybuk> and that one you see a blank splash screen?
[18:12] <Keybuk> with little animated dots?
[18:12] <joaopinto> on that I see the blash screen with the animated dots
[18:12] <Keybuk> right
[18:12] <Keybuk> now
[18:12] <Keybuk> can you do this:
[18:12] <Keybuk> echo FRAMEBUFFER=y >> /etc/initramfs-tools/conf.d/splash
[18:12] <Keybuk> update-initramfs -u
[18:12] <Keybuk> (as root obv.)
[18:13] <Keybuk> then try both the usbfs and somefs cases
[18:23] <joaopinto> Keybuk, nothing changed for the usbfs case
[18:25] <Keybuk> joaopinto: you don't see any splash screen?!
[18:26] <joaopinto> usbfs case, no , still hanging on the initial text mode
[18:26] <dupondje> http://paste.ubuntu.com/417152/ => what is this ? :s
[18:30] <joaopinto> Keybuk, both usbfs and random entry on /etc/fstab result in the text mode screen without any output
[18:30] <joaopinto> the splash vs no splash are related to VM/Real system
[18:31] <Keybuk> but there should be no initial text mode if you set that FRAMEBUFFER=y
[18:35] <joaopinto> Keybuk, ops, my mistake, addng the framebuffer now
[18:35] <Keybuk> ;)
[18:37] <joaopinto> Keybuk, it would be nice to have an option to provide a different tasks config location, like, --initdir=/etc/init.custom
[18:37] <joaopinto> it would be a simple way to use different profiles
[18:37] <Keybuk> well, different profiles there's a proposal for
[18:37] <Keybuk> but that's not a bad idea for testing
[18:38] <joaopinto> I had a bad time moving all the confs out of the regular tree and moving them back for testing :\
[18:39] <Keybuk> yeh
[18:39] <Keybuk> can you file a wishlist bug on that http://launchpad.net/upstart
[18:39] <joaopinto> Keybuk, I get the splsh and the error prompt now
[18:39] <joaopinto> splash
[18:39] <Keybuk> do you get it for both usbfs and somefs?
[18:41] <joaopinto> yes
[18:41] <Keybuk> sweet
[18:41] <Keybuk> then I know what causes both of these
[18:41] <Keybuk> they're technically different bugs
[18:44] <joaopinto> great :)
[18:44] <Keybuk> the somefs one is simply a race
[18:44] <Keybuk> mountall sends the messages, but plymouth isn't running
[18:44] <Keybuk> so they never get there
[18:44] <Keybuk> and when plymouth starts, it doesn't resend
[18:45] <Keybuk> but the usbfs one is more tricky
[18:45] <joaopinto> ok, that explains while I got a random prompt once booting from my real system
[18:45] <Keybuk> because usbfs is a nodev filesystem, it holds up the "virtual-filesystems" event
[18:45] <Keybuk> which is what causes drivers to be loaded
[18:45] <joaopinto> I checked the code, TAG_VIRTUAL, the wait rule applies :)
[18:45] <Keybuk> which means if it's holding up the boot, then the graphics drivers never get loaded
[18:45] <Keybuk> so plymouth is never shown
[18:46] <joaopinto> can't an exception be added, like there is one for fuse ?
[18:46] <joaopinto> I mean, for the usbfs case, assuming it can be ignored
[18:46] <Keybuk> well, it'd be an exception for a filesystem that we don't recognise anymore
[18:46] <Keybuk> that might be a workaround
[18:46] <Keybuk> also the FRAMEBUFFER=y thing
[18:46] <Keybuk> I'll talk to slangasek when he's up
[18:46] <Keybuk> since this becomes an RM decision at this point in the release
[18:47] <joaopinto> someone else was suggesting to strip usbfs's on the upgrade process, that's an option
[18:48] <joaopinto> people adding usbfs to a new system will most likely understand that caused the hang
[18:48] <joaopinto> or maybe not :)
[18:48] <Keybuk> right
[18:48] <Keybuk> though other mistakes can cause this too :-/
[18:51] <joaopinto> the main issue for "end users" is that there is no message to understand the cause
[18:51] <Keybuk> sure
[18:51] <Keybuk> but that's the bug
[18:51] <Keybuk> it's not that there's no message
[18:51] <Keybuk> the bug is that the message isn't getting on the screen ;-)
[18:55] <joaopinto> it's a chicken and egg problem
[19:13] <Damascene> hello, there is a problem with ogv in ubuntu recordmydesktop at least
[19:13] <Damascene> http://www.google.pl/support/forum/p/youtube/thread?tid=7b9148c46c6b6f90&hl=en&safe=active
[19:18] <persia> Damascene: Are you sure that's a bug in Ubuntu?  Looks like a bug in YouTube to me.
[19:18] <Damascene> you can try it your self persia
[19:19] <Damascene> ffmpeg -i video.ogv video.avi
[19:19] <Damascene> see if it works
[19:20] <persia> Well, if it doesn't, file a bug.
[19:21] <Damascene> I tried it doesn't you should try now
[19:21] <Damascene> I need confirmation
[19:21] <Damascene> maybe it's in recordmydesktop
[19:28] <Damascene> persia, any luck?
[19:29] <tjaalton> slangasek: ok, here you go (didn't upload straight to the archive) https://launchpad.net/~tjaalton/+archive/test/+packages
[19:29] <persia> No.  I don't have a source video, and I'm working on something else.  The best way to get the confirmation you want is to file a bug, as I said.
[19:30] <Damascene> np. I just though you are trying to reproduce
[19:41] <popey> Damascene: i can help you reproduce this
[19:41] <Damascene> thanks
[19:42] <popey> looks like a bug in ffmpeg or gstreamer to me
[19:43] <Damascene> and youtube is using them?
[19:43] <popey> Damascene: i just recorded a video with gtk-recordmydesktop and it plays fine in mplayer
[19:43] <Damascene> yeah it plays fine in totem to
[19:43] <popey> Damascene: i then used ffmpeg to convert to avi as you just suggested, and tried playing that in mplayer and it looked bad
[19:43] <Damascene> *too
[19:43] <Damascene> same here
[19:44] <popey> right, so my guess is ffmpeg or gstreamer or some libavcodec bit, not gtk-recordmydesktop
[19:45] <Damascene> how to make sure?
[19:45] <popey> well the fact that the video which gtk-recordmydesktop plays fine, and only corrupts after ffmpeg touches it is a clue
[19:45] <popey> I'd file a bug in ffmpeg if I were you
[19:47] <Damascene> and youtube is using ffmpeg?
[19:49] <popey> i dont know
[19:54] <popey> Damascene: I tend to upload to blip.tv and have them send the video to youtube and that works okay
[19:55] <Damascene> by the way do you know any open source video hosting?
[19:55] <popey> blip.tv hosts ogv
[19:55] <Damascene> or only technical stuff
[19:55] <popey> http://ubuntuscreencasts.blip.tv <- those videos are ogv which I uploaded to blip.tv
[20:03] <Damascene> was that your sound?
[20:04] <popey> was what my sound?
[20:05] <YokoZar> Did human-theme disappear off the CD?
[20:06] <Damascene> yes
[20:07] <Damascene> popey,
[20:07] <popey> Damascene: can you please explain, your short sentences are hard to parse
[20:08] <Damascene> I'm just asking if that is your sound in the video
[20:08] <popey> which video? :) there are lots
[20:08] <popey> I'm the one talking in the releases one
[20:10] <Damascene> that was really good
[20:10] <popey> thanks. i didnt make the video, i just did the audio
[20:13] <popey> YokoZar: just booted a live cd in testdrive and yes, human is not there
[20:13] <Damascene> that was the thing I'm talking about
[20:14] <YokoZar> popey: That's bad, it was one of our best themes (honestly I'm still using it due to window buttons)
[20:14]  * popey quite likes radiance
[20:15] <popey> ar
[20:15] <popey> no, the other one
[20:15] <popey> :)
[20:15] <popey> I think they're named the wrong way round "radiance" makes me think dark for some reason.
[20:28] <spy6> hi there
[20:29] <spy6> how is the procedure to sync a package from unstabe to lucid?
[20:29] <spy6> (cause https://bugs.launchpad.net/ubuntu/+source/ipplan/+bug/565781)
[20:30] <persia> !sync
[20:30] <spy6> persia: i did read this
[20:31] <persia> OK.  What part is confusing?
[20:31] <spy6> but its not very usefull, cause luvid is in freeze
[20:31] <spy6> lucid
[20:31] <spy6> there is no "resync from new debian version" documented
[20:32] <persia> Oh, just get a freeze exception, which tends to be easy for stuff that's completely broken.
[20:32] <spy6> in case of freeze
[20:32] <persia> !ffe
[20:32] <persia> Mind you, if there's lots of *other* changes, it may need a cherrypick rather than a sync.
[20:32] <spy6> persia: there just minor changes beside the fix
[20:33] <persia> Well, get input fom the release team.  Sometimes they want a sync, and sometimes they want cherrypick.
[20:34] <spy6> persia: sorry, i don't have a clue about ubtunu stuff, i'm just the debian maintainer
[20:35] <persia> spy6: OK.  So, we have two options: I'm happy to explain how to do this, or I can do it for you.  Which would you prefer?
[20:35] <spy6> persia: dunno, i'm open for new stuff ... but the proble is just, lucid is not far ;)
[20:36] <persia> OK.  So the way we usually get input from the release team is to file a bug with "FFE" in the title (or edit a bug title), and subscribe "ubuntu-release".
[20:37] <persia> The release team with ack it, reject it, or ask for more input (usually within 24 hours).
[20:37] <persia> If you get an ACK, then subscribe ubuntu-sponsors, and someone will push it to the archive admins to get it synced.
[20:37] <spy6> okay ... so i add heading "FFE" into the title?
[20:37] <persia> Yep
[20:38] <persia> (and if you get stuck, or you think the process is stuck, come back here, and we can fix it)
[20:38] <spy6> hmm ... what about the sponsor list? just looking if someone is pushing it?
[20:42] <persia> So first you want to subscribe "ubuntu-release" to get feedback from the release team.
[20:42] <persia> Once you have approval, then subscribe "ubuntu-sponsors" to ask someone to upload.
[20:42] <persia> (both using the "Subscribe someone else" button)
[20:45] <spy6> persia: which button? I'm on the mailman interface of lists.u.c
[20:45] <persia> spy6: At https://bugs.launchpad.net/ubuntu/+source/ipplan/+bug/565781
[20:46] <persia> You want to subscribe the team to the bug in launchpad.  Whether you want to subscribe to the team mailing list is entirely unrelated :)
[20:46] <spy6> ah ... i contacts add to the bugreport
[20:47] <spy6> i though i should subscribe to a mailinglist ;)
[20:47] <persia> Sorry for the confusion.  You may also subscribe the the maillinglist if you like, but that's up to you and unrelated to getting approval.
[20:47] <spy6> damn, i just have to revert from the subscription ;)
[20:48] <spy6> okay ... i got it
[20:48] <spy6> persia: many thanks
[20:49] <persia> spy6: Looks right from here.  Come ask again if you don7t get feedback in the bug in a reasonable time.
[20:50] <spy6> great :)
[20:53]  * _silentAssassin is away: I'm busy
[20:55] <persia> !away > _silentAssassin
[20:56]  * _silentAssassin is away: sleeping
[21:08] <Damascene> hi again. I used the ffmpeg from svn with x264 and the problem have gone
[21:08] <Damascene> popey,
[21:11] <matumba> Damascene, could this be related to bug 305286 ? if so, let them know, because I can confirm that the patch mentioned in the report doesn't fix it (ffplay fails to play the ogv)
[21:55] <Keybuk> Processed 281161 of 577332 files (15h 37m 5s remaining).
[21:55] <Keybuk> that remaining time is going *up*
[21:55] <ion> Yet another piece of software that doesn’t bother to violate causality.
[22:01] <slangasek> joaopinto: 507881> ah, that's the one; wonder how I failed to see that in the list
[22:02] <slangasek> ArneGoetje: what's in the new langpacks?  The deadline isn't until next week, and a full langpack upload right now wouldn't give them time to build before we need to start ISO mastering
[22:02] <slangasek> (for RC)
[22:07] <slangasek> Keybuk: if /proc/bus/usb is already supposed to be handled with the generic "An error occurred" message, that's partially bug #563621 in plymouth
[22:08] <Keybuk> slangasek: no it's worse than tha tone
[22:08] <Keybuk> /proc/bus/usb ends up being tagged virtual
[22:08] <Keybuk> since it's a kernel filesystem
[22:08] <slangasek> Keybuk: should misc filesystems listed in /etc/fstab that aren't part of mountall's known list *ever* hold up virtual-filesystems?
[22:09] <Keybuk> slangasek: yes, if listed as "nodev" in /proc/filesystems
[22:09] <slangasek> tjaalton: hum, please upload straight to the archive instead, that's actually much more efficient at this stage of the release
[22:11] <slangasek> Keybuk: what's the rationale for that?  Future-proofing mountall against new kernel filesystems that it doesn't know about yet?
[22:11] <Keybuk> slangasek: anything nodev is a virtual filesystem
[22:13] <slangasek> true, but tautological as far as the question of whether we want to block on it before emitting the signal :)
[22:16] <tjaalton> slangasek: ok, on the way. -joystick would need to be synced if accepted, and debfx is working on virtualbox-ose (vboxmouse)
[22:20] <slangasek> Keybuk: anyway, I'll accept a mountall change to blacklist usbfs specifically; it just seems to me that the more elegant solution is to treat nodev filesystems locally specified by the admin as something other than 'virtual-filesystems', and let them be handled by the normal error handler
[22:21] <tjaalton> slangasek: btw fyi; there's finally support for AES/3DES/RC4 for rpcsec_gss coming up for .35, 22 commits applied without any problem on .32 ;) (needs three patches for nfs-utils as well)
[22:22] <slangasek> tjaalton: that's going to have to be considered as an SRU
[22:22] <tjaalton> slangasek: yeah I'm hoping for it
[22:22] <tjaalton> will test it tomorrow
[22:23] <tjaalton> but according to steved it has been tested with .32/.33/.34 using cthon
[22:23] <tjaalton> so it should be ok
[22:24] <tjaalton> my problems with pam_winbind were due to getting the ticket with RC4 on top, and kinit would then replace it with an nfs compatible one..
[22:26] <tjaalton> slangasek: would you like me to propose it on the kernel list?
[22:27] <slangasek> tjaalton: um... sure :)
[22:27] <slangasek> I'm not on the kernel team, so whatever method you and they agree on is fine with me :)
[22:27] <tjaalton> ok will do :)
[22:30] <persia> tjaalton: Be aware there's still some .31 trees backing lucid packages (linux-rt, linux-fsl-imx51)
[22:30] <tjaalton> persia: I doubt that the code has changed much, it has had DES hardcoded for a loong time
[22:30] <persia> (yes, we're breaking new ground, with *3* different upstream versions of the kernel in lucid)
[22:31] <persia> OK.  You just mentioned .32/.33/.34 and as far as I know, lucid has .31/.32/.33
[22:32] <tjaalton> persia: actually, here's the patch: http://users.tkk.fi/~tjaalton/foo/auth-gss-update.diff
[22:32] <persia> (-rt/-fsl-imx51, everything else, -ti-omap)
[22:33]  * persia has no idea about other changes in the area: just wants to make sure that any sensible patch with behaviour on which we want to rely works on all the different kernel trees we ship)
[22:33] <tjaalton> yeah well I can't see a reason why it wouldn't work with .31 as well, though it certainly doesn't hurt to test..
[22:33] <tjaalton> so -rt is .31?
[22:33] <persia> Yeah, -rt and -fsl-imx51
[22:33] <tjaalton> I doubt the other flavors run nfs&krb5 :)
[22:34] <tjaalton> handhelds or such
[22:34] <persia> Actually, NFS is *very* common for -fsl-imx51 and -ti-omap as most devices don't ship with significant onboard storage.
[22:34] <ajmitch> stranger things have happened
[22:34] <persia> Dunno about -rt.
[22:34] <tjaalton> well, DES is still there
[22:35] <tjaalton> and if people have been using it, they've had to hardcode the configs too
[22:35] <persia> (but -ti-omap is *closer* to .35, so less likely to have backporting issues)
[22:35] <tjaalton> anyway, -rt is probably something that has to be tested
[22:36] <tjaalton> since i can imagine it being used on such environments
[22:37] <tjaalton> ok, 1 hunk failed on top of .31.13
[22:37] <tjaalton> out of 22
[22:40] <tjaalton> likely due to 14ace024b1e missing
[22:41] <tjaalton> yep
[23:20] <tlp> is anyone else dramatically affected by bug #131094 and perhaps #343371 in Lucid? Seems to be happening more than it used to, but I could be wrong.
[23:21] <tlp> when my HDD light is solid, I can't really do anything. Sometimes I can switch over to a tty and login so I can kill whatever it is that's doing it, but many times I'll just power the box off.
[23:27] <spy6> hmmmm
[23:28] <persia> Yes?
[23:28] <spy6> persia: "sync acked"  means, i don't need  to subscribt ubuntu-sponsors?
[23:29] <persia> Right.  A sponsor (ajmitch) already got to it, acked it, and passed to ubuntu-archive.  Now you're just waiting for an archive-admin to publish the sync.  Given that it's monday, I'd expect that sometime in the 9-12 UTC range.
[23:30] <spy6> persia: ah okay ... that should be fine for lucid i guess :)
[23:30] <spy6> thanks
[23:30] <persia> For the purposes of taxonomy "archive-admin" in Ubuntu is roughly analogous to "ftp-master" in Debian.
[23:31] <spy6> i thought so
[23:32] <slangasek> Keybuk: re: bug #565185, bug #563878 - my first reaction was also to treat it as invalid, but on second thought, I don't think the design team was ever designing for 640x480 - I'll bet they're assuming a minimum res of 1024x768.  Maybe we should consult them about shrinking those graphics down by a factor of 1.6 or so, so that VGA16fb is more consistent with the experience they've actually designed?  (But not for final release, and proba
[23:32] <slangasek> ... candidate for SRU)
[23:33] <persia> slangasek: I'm sure 1024x600 is a closer approximation to expected minimum, although there have been N bug reports about stuff not working at 800x480.  I don't think anyone is seriously targeting 640x480.
[23:33] <slangasek> persia: right - but of course 640x480 is what the VGA fb gives you
[23:34] <slangasek> the trouble is, none of our positioning code assumes 640x480 either, so just resizing the images is going to look weird
[23:34] <persia> Yep.  There's been some interesting discussions in #ubuntu-installer about the side effect of various scalings at various resolutions regarding the install process.
[23:34] <slangasek> hmm; actually, our positioning code *might* all use the image sizes as the point of reference, and might just work
[23:35] <slangasek> sorry, might Just Work
[23:36] <joaopinto_> it works fine for me with the (ugly) ATI fglrx resolution
[23:36] <persia> Most stuff seems to scale reasonably down to medium resolutions, but 640x480 gets a bit tight.
[23:36] <persia> Anyway, anything that depends on number of pixels for apparent size is inherently broken.
[23:37] <persia> There exists no relationship between screen size and pixel count, even aside from the vesafb issues.
[23:37] <slangasek> as it happens, I had already tweaked the positioning code in the ubuntu-logo to eat up some of the space below the logo if we didn't have room to display all our text, based on feedback in prior bugs
[23:37] <slangasek> so we should actually *fit* on 640x480
[23:37] <slangasek> it's just not pretty
[23:38] <persia> I think that's fine.  We can't get pretty until we can get em-aware renderers into pre-boot in a sensible way.
[23:38] <persia> And even then it's tricky (go ahead: just try to make things look sensible on my 0.75" 800x600 display)
[23:38] <slangasek> you know we use pango for the text rendering, right? :)
[23:38] <persia> slangasek: Doesn't help with images though.
[23:39] <slangasek> well, yes
[23:39] <persia> Plus pango uses dpi as input trying to reach target size, rather than using dpi as input to reach sensible aspect.
[23:40] <slangasek> but we don't want to be scaling images anyway, they're not going to look crisp if we do that
[23:41] <persia> Right.  We need to render crisp images in realtime on the target hardware.
[23:41] <slangasek> heh
[23:41] <persia> But even that won't look crisp when we have framebuffer issues, because the display resolution won't match the native resolution.
[23:41] <persia> (at least for non-raster devices)
[23:42] <persia> Well, there's always the alternative of generating a pre-rendered image for every resolution at every size, but that gets tedious in a hurry.


[14:16] <lazyPower> rick_h_: did the MongoDB problems spawn from the MongoDB charm?
[14:17] <rick_h_> lazyPower: no
[14:18] <kwmonroe> hey rick_h_, thanks for fixing issue 107 (ingestion of promulgated bigdata-charmers charms)!
[14:19] <kwmonroe> rick_h_: now that i've buttered you up, a question:  do promulgated bundles need to have the charm revno explicitly set, as in "charm: blah-<revno>", in bundle.yaml?  or will the lack of -<revno> pull the latest?
[14:20] <lazyPower> kwmonroe: bundle spec wants revisions, but i'll let rick confirm that one ;) i know where you're headed with this and i know what you're going to get as an answer
[14:21] <rick_h_> kwmonroe: otp atm will look in a few sorry
[14:21] <kwmonroe> np


[08:04] <Chipaca> mo'in!
[08:09] <niemeyer> Morning Chipaca, greetings all
[08:13] <Chipaca> laptop is once again stuck at 800MHz, I'm going to have to take it apart and unplug the battery again :-|
[08:13] <Chipaca> probably on the weekend
[08:42] <Chipaca> so, to support dispatch being a script that calls us, while still expecting us to actually *handle* the dispatch, we need to drop looking at argv to know whether we're dispatch and just look at the env var
[08:43] <Chipaca> to me that means we should set an env var, or clear an env var, to catch us if we try to exec ourselves again (e.g. if somebody's copied charm.py instead of symlinking it)
[08:43] <Chipaca> this does not seem too bad to me
[08:44] <niemeyer> Chipaca: We can't drop the former approach for compatibility, but yeah, we need to make it configurable so that the call site for dispatch can use the env
[08:44] <Chipaca> niemeyer: 'the former approach', you mean looking at argv when we're _not_ dispatch?
[08:44] <Chipaca> that seems fine
[08:44] <niemeyer> Chipaca: Yeah, what we have atm
[08:46] <Chipaca> niemeyer: on a completely separate track, i'm waiting to hear back but it's likely the 'ops' package on pypi is not considered 'abandoned'. If that's the case, what's our fallback?
[08:54] <niemeyer> Chipaca: We can register something related and still keep the Python module name
[08:55] <niemeyer> Chipaca: We should circle back to see how to press further on obsolescence of the name, though
[08:55] <niemeyer> Chipaca: It's certainly abandoned for long
[08:56] <Chipaca> niemeyer: pypi has a definition of abandoned that is not just 'has it seen a release'
[08:56] <Chipaca> working on it, in any case
[08:56] <niemeyer> Chipaca: Sure, but that seems like a valid case of that for all metrics I can imagine
[09:27] <mup_> Issue operator#240 opened: Shared StoredState between kubernetes workload pods <Created by davigar15> <https://github.com/canonical/operator/issues/240>
[09:27] <jam>  niemeyer, Chipaca : maybe they use the metric "has it been installed lately" and most of us have accidentally installed it recently :)
[09:33] <Chipaca> that is one of the things they look at, yes
[09:35] <davigar15> Chipaca: Dmitrii-Sh and I have found this bug: https://github.com/canonical/operator/issues/240
[09:36]  * Chipaca looks
[09:37] <Chipaca> youch
[09:39] <Chipaca> davigar15: out of ignorance, what creates the symlink from agents/<unit>/charm to agents/<app>/charm ?
[09:39] <Chipaca> is that juju itself?
[09:39] <Chipaca> niemeyer, jam, ^^
[09:40] <jam> Chipaca, most likely Juju, sounds like on K8s every unit shares the charm dir, which we didn't expect
[09:41] <Chipaca> jam: isn't it fairly common to use the charm dir to store stuff, like keys and the like?
[09:42] <jam> Chipaca, so in other discussions I've had, you *shouldn't* use the charm_dir, we've discussed trying to make it read-only in Juju, but I do think it gets uses
[09:42] <jam> used
[09:43] <Chipaca> jam: so we're doing something we know we shouldn't?
[09:44] <jam> Chipaca, I don't think we've expressly discussed it, but some things like "why does the state sometimes end up in the application pod" is because we put stuff in the charm dir, which Juju *also* manages with things like charm upgrades.
[09:45] <jam> Chipaca, I don't think from Juju's end we've clearly stated to charms "here's the directory you should use for your runtime files" which means they use $PWD which is charm_dir
[09:45] <Chipaca> jam: yeah, i was about to ask, how _can_ a charm grab a directory for its own use?
[09:46] <jam> Chipaca, ultimately the charm is the root authority on the machine it is setting up. so it is mostly that we should have a well defined recommendation
[09:46] <jam> it gets slightly hairier if you install 2 apps to the same machine, who 'wins'. And on K8s there is only 1 operator which is responsible for all charm units.
[09:50] <mup_> Issue operator#241 opened: _TestingModelBackend incorrectly raises KeyError on missing relation <Created by gnuoy> <https://github.com/canonical/operator/issues/241>
[09:52] <mup_> PR operator#242 opened: Stop test harness relation_ids raising KeyError <Created by gnuoy> <https://github.com/canonical/operator/pull/242>
[10:02] <jam> anyway, not really here, just passing by, heading back to other activities
[10:02] <jam> Chipaca, #241 should be fixed by #196, IIRC
[10:02] <mup_> Issue #241: _TestingModelBackend incorrectly raises KeyError on missing relation <Created by gnuoy> <https://github.com/canonical/operator/issues/241>
[10:02] <mup_> PR #196: Factor out the Harness changes for test_model.py <Created by jameinel> <https://github.com/canonical/operator/pull/196>
[10:19] <Chipaca> niemeyer: could you re-review #196 ? i think jam addressed your points
[10:19] <mup_> PR #196: Factor out the Harness changes for test_model.py <Created by jameinel> <https://github.com/canonical/operator/pull/196>
[10:23] <Chipaca> davigar15: is that bug blockig your work?
[10:25] <davigar15> Chipaca: No, I have a workaround for it :-)
[10:25] <Chipaca> davigar15: ok
[10:25] <Chipaca> then i'm going to take a bit of time out to see why my battery is draining despite being plugged in (and my cpu stuck at 800mhz)
[10:25]  * Chipaca bbiab
[10:26] <davigar15> Basically I needed to update the state of the unit with the data retrieved from the relation_data, and then emit an event. Since it's auto-updated :P I just emit always the event in the relation_changed
[10:59] <davigar15> Chipaca: Is there a way to install python deps in the charm (similar to wheelhouse.txt)
[10:59] <davigar15> ?
[11:08] <niemeyer> davigar15: There will be.. right now this process is a bit manual. We have one pattern described in the README in the repository
[11:08] <niemeyer> davigar15: We'll have a full building process and associated publication communication with the store
[11:10] <davigar15> niemeyer: But that procedure is for adding deps from git repositories, right?
[11:15] <mup_> PR operator#242 closed: Stop test harness relation_ids raising KeyError <Created by gnuoy> <Closed by gnuoy> <https://github.com/canonical/operator/pull/242>
[11:15] <niemeyer> davigar15: Yes, but the lib directory may have any content on it, and it's added to sys.path
[11:15] <niemeyer> davigar15: Again, it's a bit manual.. we're working on the build tool
[11:17] <facubatista> Muy buenos días a todos!
[11:38] <niemeyer> facubatista: Hey hey, good Friday
[11:39] <facubatista> hola niemeyer, thanks!
[11:54] <Chipaca> brb, rebooting once again
[12:21] <Chipaca> facubatista: 👋!
[12:25] <Chipaca> it's a bummer that 'juju ssh' doesn't populate JUJU_ things :-/
[12:25] <niemeyer> Chipaca: It can't.. it doesn't have an agent behind it
[12:25] <niemeyer> Chipaca: That is, it's not in a hook context
[12:26] <niemeyer> Chipaca: That's what debug-hook / debug-code are for, and those do set it.. it's also done via ssh
[12:28] <Chipaca> niemeyer: debug-hook with no hooks, does that mean all, or none?
[12:29] <niemeyer> Chipaca: all
[12:30] <niemeyer> Chipaca: none wouldn't make much sense (debug nothing?)
[12:31] <facubatista> juju noop
[12:33]  * Chipaca has a lot of fun pronouncing 'noop' as /n(j)uːp/
[12:47] <Chipaca> I'd like to propose a breaking change: make the 'short' form observe look for _on_foo instead of of on_foo
[12:47] <Chipaca> (or, nuke the short form)
[13:04] <niemeyer> Chipaca: I vote for the latter, but we need a good way to notify people of the coming change
[13:05] <niemeyer> Chipaca: I'd also vote to do that at the same time that we promise API stability
[13:05] <niemeyer> Chipaca: We've done too many small breaking changes recently. They were good, but I think the time is approaching where we cannot afford to break any code anymore
[13:06] <Chipaca> niemeyer: I'd like to start having releases, too :)
[13:10] <niemeyer> Chipaca: Uhhh.. that's too advanced :P
[13:19]  * Chipaca giggles at 'juju run --operator'
[13:19] <mthaddon> davigar15: https://github.com/canonical/operator/issues/156 fwiw
[13:21] <Chipaca> mthaddon: BTW, what're you doing that makes it better to have a function do that instead of doing it at the package level?
[13:22] <mthaddon> Chipaca: sorry, not sure I understand the question - how do you mean?
[13:23] <niemeyer> I think stub and mthaddon understand that this is an ugly hack, but maybe we should add a note to the issue as well pointing that out
[13:23] <niemeyer> If you want to do something like that, do it on the install event, not at package level
[13:23] <Chipaca> mthaddon: I mean, https://git.launchpad.net/charm-k8s-wordpress/tree/src/wordpress.py#n14
[13:24] <Chipaca> it means every single function starts with requests = import_requests()
[13:24] <mthaddon> Chipaca: ah, it was just that we were needing to do that in a few places so we broke it out into a functionn
[13:25] <mthaddon> Chipaca: yeah, we could have just done this at the package level too - either way felt less than ideal though
[13:25] <Chipaca> oh, agreed it's ugly, but doing it in a function is ugly _and_ awkward :-D
[13:25]  * Chipaca knows it's not like you have a nice option, here
[13:26] <niemeyer> I've added a note
[13:26] <niemeyer> Chipaca: There's a nice option in fact
[13:26] <niemeyer> Chipaca: There's an event called "install", which happens to be a good place to have "apt install"
[13:27] <Chipaca> niemeyer: did you see my request that you re-review #196?
[13:27] <mup_> PR #196: Factor out the Harness changes for test_model.py <Created by jameinel> <https://github.com/canonical/operator/pull/196>
[13:27] <niemeyer> Chipaca: I did.. I have not done it because jam is off and facundo is not. Have been working on something else instead, as we'll discuss in 3 minutes
[13:28] <Chipaca> niemeyer: "do it on install" does not fix having to make the name available outside of _on_install though
[13:28] <mthaddon> niemeyer: it also needs to be in a charm upgrade too, otherwise you might never call it again though I think?
[13:28] <Chipaca> at which point the approach in https://git.launchpad.net/charm-k8s-wordpress/tree/src/wordpress.py#n14 seems to be better
[13:30] <niemeyer> Chipaca: If the import and name is used inside functions, that's not a problem
[13:31] <niemeyer> Chipaca: WIll have a look after the standup
[13:47] <Chipaca> mthaddon: WRT reviewing that charm, can you create an issue in canonical/operator for it? including links to the code :)
[13:47] <mthaddon> sounds good, will do - thx
[13:51] <Chipaca> mthaddon: we're trying to get a process for this set up, i'll write it up sometime once we agree
[13:52] <mup_> Issue operator#243 opened: Review of wordpress kubernetes charm <Created by mthaddon> <https://github.com/canonical/operator/issues/243>
[13:52] <mthaddon> thx, no hurry from our side, but any feedback appreciated
[14:15] <niemeyer> mthaddon: Are you available for a call just now?
[14:15] <mthaddon> niemeyer: yep
[14:15] <niemeyer> mthaddon: https://meet.google.com/fqw-mdqc-dsf
[14:50] <mthaddon> niemeyer: can you take a look at https://docs.google.com/document/d/1D-DA3vJRRaauNc2bAJqLTKtAMTTP6tdj5HmOz-rasJI/ and let me know if I've captured it?
[14:51] <Chipaca> facubatista: did you see my message about #233?
[14:51] <mup_> PR #233: Execute the registered methods to events under PDB if proper envvar is set <Created by facundobatista> <https://github.com/canonical/operator/pull/233>
[14:57] <facubatista> Chipaca, I didn't, but now I saw it
[15:31] <facubatista> Chipaca, niemeyer, proposed now
[15:32]  * facubatista -> lunch
[15:33] <Chipaca> facubatista: nice
[16:02] <mup_> PR operator#244 opened: Draft of the ops library support <Created by niemeyer> <https://github.com/canonical/operator/pull/244>
[16:05] <Chipaca> niemeyer: nice!
[16:05] <Chipaca> what a lovely note to wrap a week with :-)
[16:05] <niemeyer> Chipaca: Take it on! :)
[16:05] <Chipaca> those two PRs I mean
[16:06] <niemeyer> Chipaca: This still doesn't support the top-level 'opslib', but that's a nice future PR on top of the first merge
[16:06] <niemeyer> Chipaca: I did fix it to not import anything before it's actually used
[16:06] <Chipaca> niemeyer: i noticed
[16:06] <Chipaca> that's good
[16:06] <niemeyer> Chipaca: With the nice side effect that now import errors are reported normally
[16:07] <Chipaca> niemeyer: by 'take it on!' you mean I should grab the PR, make any changes I think it needs, and then drive it as if it were mine?
[16:08] <Chipaca> niemeyer: or just review as normal and then do follow-ups?
[16:08] <Chipaca> don't want to do the former if you mean the latter, and viceversa
[16:13] <niemeyer> Chipaca: Yeah, please feel free to just take ownership
[16:13] <Chipaca> ok, will do
[16:13] <niemeyer> Chipaca: I don't want to sit on this further and delay it
[16:13] <niemeyer> Chipaca: Thank you!
[16:14] <niemeyer> mthaddon: Doc looks great, thanks!
[16:14] <mthaddon> niemeyer: cool, thx for the suggestions - will incorporate those soon
[16:17] <mthaddon> niemeyer: that last bullet point for benefits is really nice (being able to break compatibility without breaking old code)
[16:20] <niemeyer> mthaddon: Yeah, we really need something that allows people to collaborate fast without clashing with or breaking each other
[16:20] <niemeyer> mthaddon: This looks painless enough I think
[16:22] <mthaddon> I'll try and find time to write up the charm developer workflow side of things next week as well, just so it's clear (to me at least) how that part works, but for now I'm EOW o/
[16:23] <Chipaca> mthaddon: have a good one
[16:23] <Chipaca> i'm going to go see if my knee is up for a run
[16:23] <mthaddon> Chipaca: I'd check with both knees before you start :)
[16:23] <Chipaca> then, i'm going to break gustavo's work :-p
[16:23] <Chipaca> mthaddon: the one on the right votes conservative, it can do one
[16:24] <niemeyer> Or fix it, with tests! :)
[16:24] <niemeyer> Have fun folks
[17:04]  * facubatista is back
[19:10] <facubatista> I have a silly mistake in my branch, so I got an error on install, it goes to "error state", if it's broken, why the install is retried?
[19:10] <facubatista> unit-bdv-4: 16:05:44 DEBUG unit.bdv/4.install AttributeError: module 'os' has no attribute 'chcwd'
[19:10] <facubatista> unit-bdv-4: 16:05:45 ERROR juju.worker.uniter.operation hook "install" (via explicit, bespoke hook script) failed: exit status 1
[19:10] <facubatista> unit-bdv-4: 16:05:45 INFO juju.worker.uniter awaiting error resolution for "install" hook
[19:10] <facubatista> unit-bdv-4: 16:05:50 INFO juju.worker.uniter awaiting error resolution for "install" hook
[19:10] <facubatista> unit-bdv-4: 16:05:51 INFO unit.bdv/4.juju-log Installing blog...
[19:10] <facubatista> failed: exit status 1 <--
[19:10] <facubatista> failed: exit status 1 <-- perfect!
[19:11] <facubatista> juju.worker.uniter awaiting error resolution for "install" hook <-- perfect, will fix, let me get a mate
[19:11] <facubatista> unit.bdv/4.juju-log Installing blog... <-- wait, why it started again??
[20:45] <Chipaca> facubatista: yep, hooks that fail get retried by the juju
[20:47] <facubatista> Chipaca, and I'm failing to update the code between retrials; and it doesn't let me to do a deploy again (it's says it's already deployed)
[20:48] <facubatista> so the try/error cycle involves removing the app and deploying from scratch
[20:48] <facubatista> so much lost time
[20:49] <Chipaca> facubatista: what happens if you ssh in and just cowboy the new charm in place?
[20:49] <niemeyer> You can ask to not repeat the hook
[20:49] <niemeyer> At resolve time
[20:49] <Chipaca> niemeyer: what's "resolve time"
[20:50] <facubatista> niemeyer, I'm not running "resolve"
[20:50] <niemeyer> So how do you tell the unit to keep going? I must be out of context and if so sorry for that
[20:51] <facubatista> niemeyer, I'm not telling it to continue, it retries by itself
[20:51] <facubatista> I'd want to tell it "ok, please refresh the code and retry that install"
[20:52] <niemeyer> facubatista: There must be something broken then, or again I don't understand what's happening.. when a hook returns a non zero exit, juju puts it in an error state
[20:55] <facubatista> niemeyer, it goes to error, yes, it even says "awaiting error resolution", but then retries out of the blue
[20:55] <niemeyer> Okay, I'm probably outdated then
[20:56] <niemeyer> This would not happen in the original implementation
[21:17]  * facubatista eods
[21:17] <facubatista> and eows!
[21:17] <facubatista> see you all on Monday, have a nice weekend
[21:18] <niemeyer> Have a good weekend
[21:23]  * Chipaca EOWs also
[21:23] <Chipaca> see y'all monday


[00:24] <jose> hey guys, how am I supposed to merge two branchs that are in an MP?
[00:24] <jose> I see no button
[00:35] <wgrant> jose: You need to merge with bzr on your local machine (to resolve conflicts, for example)
[00:36] <jose> wgrant: any idea on how should I?
[00:36]  * jose is a bit lost, bzr merge doesn't do anything
[00:37] <wgrant> jose: Inside the target branch, run 'bzr merge lp:~path/to/branch/to/merge'
[00:44] <jose> thanks!
[00:46] <jose> wgrant: huh, still, 'nothing to do' shows up
[00:46] <jose> I'm trying to merge https://code.launchpad.net/~jose/kubuntu-website/feature-tour-update/+merge/199881
[00:46] <wgrant> jose: which MP is this?
[00:46] <jose> ^
[00:49] <wgrant> jose: Are you sure you're merging the right way?
[00:49] <jose> erm, huh?
[00:50] <wgrant> In the branch you're merging *into*, run 'bzr merge lp:~path/to/branch/to/merge/FROM'
[00:50] <jose> oooooh
[00:50] <wgrant> It sounds like you're running it in the opposite direction
[00:50] <jose> yeah, I was doing exactly that :P
[04:01] <JZA> hi I got an issue trying to login into launchpad from the command line
[04:01] <JZA> I do, bzr branch lp:<project> and get the following
[04:01] <JZA> Permission denied (publickey).
[04:02] <JZA> I already put my public key which is my default key, but in case is not the default, is there a flag I can put to assign the key I am using?
[04:05] <JZA> I already put my key up
[04:22] <wgrant> JZA: What's your Launchpad username?
[04:22] <JZA> jzarecta
[04:22] <JZA> I paste my ssh pub on my profile
[04:22] <JZA> however I am unsure which passphrase is it asking me now
[04:23] <wgrant> What does 'ssh -v<EMAIL_ADDRESS>say?
[04:24] <JZA> ok it does  authenticate me
[04:24] <JZA> debug1: Authentication succeeded (publickey).
[04:24] <wgrant> OK, so it sounds like bzr doesn't know your Launchpad username
[04:24] <wgrant> What does '
[04:24] <wgrant> 'bzr lp-login' say?
[04:25] <JZA> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/%2Bbranch/openobject-doc/".
[04:25] <JZA> I see an issue on the URL
[04:25] <JZA> could that be the problem?
[04:25] <JZA> it says my nick, jzarecta
[04:26] <wgrant> What output does 'ssh<EMAIL_ADDRESS>give?
[04:26] <wgrant> Without -v
[04:35] <JZA> No shells on this server.
[04:36] <wgrant> JZA: Right, so that's working fine. What about 'bzr ping bzr+ssh://bazaar.launchpad.net/'?
[04:37] <JZA> bzr: ERROR: unknown command "ping"
[04:38] <wgrant> JZA: Does 'bzr branch lp:openobject-doc' still gives the "Permission denied (publickey)" error?
[04:39] <JZA> no, just gives bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/%2Bbranch/openobject-doc/".
[04:39] <wgrant> JZA: OK, so you did something to fix the problem.
[04:40] <wgrant> JZA: Perhaps you did something to your ssh-agent
[04:40] <JZA> I said, I added the custom key to my .ssh/config
[04:40] <JZA> so it goes to the one I uploaded
[04:40] <wgrant> The new error is because lp:openobject-doc doesn't name a branch.
[04:40] <JZA> but still not working :(
[04:40] <wgrant> What were you attempting to retrieve?
[04:40] <wgrant> The URL you specified doesn't exist.
[04:42] <JZA> yeah according to the documentation, tis is the branch I need to pull
[04:42] <JZA> https://doc.openerp.com/contribute/09_documentation_translation.html/
[04:42] <JZA> guess the project name has changed.
[04:42] <wgrant> The project still exists at https://code.staging.launchpad.net/openobject-doc, but it has no trunk branch set.
[04:42] <JZA> https://code.launchpad.net/openobject-doc
[04:43] <JZA> I see
[04:43] <wgrant> Er, without .staging, oops
[04:43] <wgrant> Your URL is correct
[04:43] <wgrant> You can see the 7.0, 6.1 etc. branches listed there.
[04:43] <wgrant> But no lp:openobject-doc
[04:45] <JZA> I see, I am poking around, I left a question, hopefully someone wil reply with the correct instructions.
[04:46] <JZA> at least I can say is not a lp or key issue.
[04:47] <wgrant> Yeah, it's just out of date docs, it seems.
[14:26] <AnAnt> Hello, is there something wrong with uploads to PPA ?
[14:27] <pmjdebruijn> are you getting an error?
[14:27] <AnAnt> hmm, sorry
[14:27] <AnAnt> I think I am mistaked
[14:28] <AnAnt> mistaken
[17:49] <Ge0rG> heydiho. I am using launchpad for translating my oss project (yaxim), and I needed to make a search&replace over the whole strings set. I downloaded a tarball, replaced the strings, and re-uploaded the tarball. But now, I need to manually assign each .po file from the tarball the right language in https://translations.launchpad.net/yaxim/master/+imports
[17:49] <Ge0rG> is there a way to get that automatically?
[17:51] <Ge0rG> would it work better if I strip yaxim- from the .po file names?
[17:52] <Ge0rG> no, it won't :(
[17:54] <Ge0rG> is there any way to automate the translation import queue?
[18:12] <Ge0rG> anyone from the translations team?
[18:26] <Ge0rG> ok, now I clicked through all 19 of them.
[21:01] <SamB> hmm, http://bazaar.launchpad.net/~vcs-imports/emacs/trunk/files is not working for me ...