[00:59] <Riddell> JontheEchidna: so bug 387364 is actually fixed?
[00:59] <JontheEchidna> Riddell: needs SRU apparently
[01:00] <JontheEchidna> but it should be good in karmic
[01:46] <JontheEchidna> more nice feedback on the feedback page :)
[02:09] <yuriy> oh boy i don't check my email for 2 days and you guys go crazy with planning
[02:11] <JontheEchidna> lol
[02:11] <JontheEchidna> feel free to join in; it's not too late to suggest anything :)
[02:18] <yuriy> i have a feeling i don't have much to contribute here, I think I would be the "KDE puritan" in this discussion
[02:19] <JontheEchidna> Default software is just one part
[02:19] <yuriy> yeah haven't gotten to the actual plan yet, reading the thread first
[02:19] <yuriy> slashdot style ;)
[02:19] <JontheEchidna> hehe
[02:27] <txwikinger> feedback page?
[02:35] <JontheEchidna> txwikinger: https://wiki.kubuntu.org/KarmicKoala/RC/Kubuntu/Feedback
[02:36] <yuriy> new i'm a pc/i'm a mac commercial is hilarious
[02:36] <txwikinger> cool thanks JontheEchidna
[02:37] <jjesse> the one with the pc being a news anchor?
[02:37] <yuriy> the one about windows 7, with the PC going "the new version of my operating system is out, and it doesnt have any of the problems the last version had! trust me!"
[02:39] <JontheEchidna> http://www.apple.com/getamac/ads/
[02:39] <JontheEchidna> very ballsy
[02:40] <JontheEchidna> mplayer plugin only gives audio though :(
[02:40] <JontheEchidna> ah, better: http://www.youtube.com/watch?v=mISTuG4LLeA
[03:21]  * JontheEchidna will fix bug 458695 tomorrow
[03:59] <freeflying> ScottK: http://www.flickr.com/photos/freeflying/sets/72157622515083587/
[03:59] <freeflying> ScottK: kubuntu-netbook on ARM
[04:14] <ScottK> freeflying: Thank you very much.  Very nice.
[04:22] <yuriy> JontheEchidna: I wrote up a (somewhat onesided) page on the bug reporting point: https://wiki.kubuntu.org/Kubuntu/Bugs/Apport/Discussion
[04:22] <yuriy> ...and didn't save my last changes *headdesk*
[04:22] <freeflying> ScottK: my pleasure
[04:24] <yuriy> there, better
[04:27] <ScottK> I know that thanks to the apport stuff I was able to give Sput my first good quassel backtrace ever this week.
[04:53] <shtylman> does the manual partitioning work in the installer?
[04:53] <shtylman> it didn't quite work for me in virtualbox...but that could be other setup crap
[05:14] <ScottK> I think I found stikonas KPackcageKit problem.
[05:15] <ScottK> No syslog running.
[05:49] <markey> hmm, no Chromium nightly updates lately
[05:49] <markey> anyone know why?
[05:51] <ScottK> markey: Chromium stuff is done by the Ubuntu Mozilla Team.  You might ask in #ubuntu-mozillateam (IIRC).
[05:54] <markey> ok thanks
[06:00] <markey> 06:59 < micahg> markey: daily is broke :)
[06:00] <markey> 06:59 < micahg> wanna fix it?
[06:00] <markey> so we know that
[06:13] <markey> anyone got a ppa for the latest Choqok?
[06:51] <ScottK> Packagekit upload pending for stikonas' complaint.  The answer to why we were going to release with a totally broken package kit is it was only totally broken if your syslog isn't running and no one had reported a bug.
[09:38] <apachelogger> JontheEchidna: that systemsettings-in-own-category from rc feedback package is foobar
[09:38] <apachelogger> the cat would only show up if there was an entry other than systemsettings
[09:39] <apachelogger> which I hunted down earlier in the cycle... unless, of course, someone rebroke it :P
[10:27] <apachelogger> http://picasaweb.google.com/cschlaeger/JapanLinuxSymposium#5395358413061926434
[10:27] <apachelogger> :D
[11:17] <agateau> ScottK: ping
[11:28] <agateau> ScottK: unping, have to go (sent you an email instead)
[12:06] <ScottK> debfx: Uploaded the revised patch.  It seems good here too.  Thanks.
[12:10] <Riddell> agateau: so what do we have to upload for knetworkmanager?
[12:12] <ScottK> Riddell: I just uploaded a new -workspace that ditches the untranslated string on the brightness OSD.
[12:12] <Riddell> thanks ScottK, that was next on my todo :)
[12:21] <ScottK> Riddell: Now since you didn't upload it, you can put your release team hat on and accept it ....
[12:31] <Riddell> ScottK: oh I see what you're hinting at, you want me to accept it
[12:33] <Riddell> accepted!
[12:42] <agateau> Riddell: latest package from my PPA?
[12:55] <Riddell> agateau: it changes a string but it seems like that string isn't in the upstream translations anyway
[12:55] <Riddell> good thing we have launchpad else it would never have a chance to be translated :)
[12:56] <debfx> ScottK: ok great, i'll submit the patch to the kde reviewboard
[13:00] <Riddell> agateau: that string has been translated in launchpad, would be be possible to do a s/hex// in the code rather than change the string?
[13:01] <agateau> Riddell: you mean editing the string after it has been translated?
[13:01] <Riddell> agateau: right
[13:01] <Riddell> it's not pretty but I think it's better than having the string in english?
[13:01] <agateau> Riddell: can do, but let's hope nobody went smart and named it otherwise
[13:01] <agateau> Riddell: I agree
[13:03] <agateau> Riddell: will give a try, expect update in the afternoon
[13:05] <Riddell> agateau: actually how about string = "ASCII/" + i18n(original_string)
[13:05] <Riddell> that's probably more reliable
[13:05] <agateau> Riddell: it depends on translators not reordering the string
[13:06] <Riddell> agateau: has anyone tested the wired icon change?  has wstephenson seen it?
[13:07] <agateau> Riddell: I tested it, not sure I posted it to wstephenson
[13:09] <agateau> Riddell: Looking at the .po files, replacing "Hex" won't work
[13:09] <agateau> and prepending ASCII/ does not sound good for all languages
[13:09] <agateau> because in some case the "hex" part is after the "key" part
[13:09] <Riddell> agateau: how about s,hex,ASCII/hex, ?
[13:10] <steveire> What is apport-kde?
[13:10] <Riddell> steveire: crash reporter
[13:11] <agateau> Riddell: probably a bit nicer, but still not perfect
[13:11] <steveire> I'm getting autospawning dialogs telling me it wants my password.
[13:11] <Riddell> steveire: you have a crash in /var/crash which belongs to root then
[13:11] <agateau> Riddell: lt for example translate "Hex Key" to "Šešioliktainis raktas"
[13:12] <steveire> I dismissed all of the dialogs. Oh well.
[13:12] <steveire> I'll let it do its thing next time
[13:12] <agateau> Riddell: how can I browse LP translations for knm?
[13:12] <Riddell> dpm: ?
[13:14] <Riddell> agateau: https://translations.edge.launchpad.net/ubuntu/karmic/+source/plasma-widget-networkmanagement/+pots/libknetworkmanager
[13:15] <agateau> Riddell: thanks
[13:16] <dpm> yeah, thanks Riddell, you were quicker. agateau, it's usually https://translations.launchpad.net/ubuntu/karmic/+source/<sourcepackage>, which should take you to all available translation templates for a given package
[13:16] <Riddell> agateau: we could also change the string only if it isn't translated  if orig_string == i18n(orig_string): sting = "new text"
[13:16] <Riddell> dpm: the tricky part there is inserting karmic into the URL at the right but, it's annoying how the translations tab doesn't light up unless you do that
[13:18] <agateau> Riddell: yes, but then users either get "translated and outdated" or "untranslated but accurate"
[13:18] <agateau> :/
[13:18] <Riddell> right, there's no perfect answer
[13:19] <agateau> what about adding ascii/ to translations ourself?
[13:25] <Riddell> agateau: how do you mean?
[13:26] <agateau> Riddell: I mean: settle on "Key" or "ASCII/Hex Key" for the english version,
[13:27] <agateau> Riddell: generate new POs
[13:27] <agateau> Riddell: and update them ourselves
[13:28] <Riddell> agateau: I don't speak 50 languages, I've no idea how to translate that!
[13:29] <agateau> Riddell: if you look at the language list in LP and in the po/ dir, there are less than 50 languages,
[13:29] <agateau> Riddell: and looking at the po files, it's quite easy to see where one could add ASCII/
[13:29] <Riddell> dpm: is that sane/possible ^ ?
[13:30]  * agateau doubt it's sane, but would love it to be possible
[13:31] <agateau> Riddell: is it possible to release an updated version with up to date translations after release date (as an sru)?
[13:32] <Riddell> yes translations get regular SRUs
[13:32] <agateau> Riddell: so maybe it's the sanest thing to do
[13:33] <agateau> Leave the string untranslated but accurate for release, and do an SRU
[13:33] <agateau> Bonus point if we can get some translations updated by native speakers before release
[13:34] <agateau> Riddell: on LP there are only 6 languages which are quite complete
[13:36] <agateau> I can fix fr, we would need help for brazilian, chineese, spanish, swedish and ukrainian
[13:36] <agateau> (and chinese is already missing 108 strings, so it would not really matter :/)
[13:37] <JontheEchidna> the translations deadline for LP was yesterday I believe. You'd have to manually edit the lang-packs once they're uploaded
[13:37] <agateau> Riddell: do we also ship translations from src po/ dir?
[13:37] <agateau> JontheEchidna: mmm, doesn't sound good
[13:37] <Quintasan> hiho
[13:38] <JontheEchidna> actually I don't know if you can change existing translations since they're binary. In the past we've only been able to add new translations manually iirc
[13:39] <agateau> JontheEchidna: this can be considered an addition as well
[13:39] <agateau> JontheEchidna: since we changed the original string
[13:39] <JontheEchidna> I mean, the addition of a totally new .mo file
[13:39] <agateau> JontheEchidna: oh ok
[13:40] <JontheEchidna> Riddell: is bug 458779 the one that was discussed on #kde-devel the other day?
[13:41]  * ryanakca points out that he only has one Developer of the week so far, can someone else please reply to the ML thread?
[13:42] <ryanakca> agateau: If you need help with fr and tell me how to help with it this weekend, I can do so as well.
[13:42] <agateau> ryanakca: I am french :)
[13:43] <agateau> thanks anyway :)
[13:43] <ryanakca> agateau: I know. But, if the volume of translations left can be split halfway, it'll go that much faster.
[13:43] <agateau> ryanakca: oh ok, in this case, it's just one string
[13:43] <ryanakca> Ah, haha :)
[13:44] <agateau> ryanakca: but it's the one which tells you you can enter an ascii or hex wep key
[13:44] <agateau> ryanakca: instead of only an hex key
[13:46] <a|wen-dtu> agateau: i'm able to understand swedish pretty well, so just ping me for that (or danish/norwegian)
[13:47] <agateau> a|wen-dtu: thanks, we still have to decide if we want to go this way
[13:48] <a|wen-dtu> of course :)
[13:55] <agateau> Riddell: just downloaded LP translations
[13:56] <Quintasan> hurr, /me can't do even simple pycode
[13:56] <agateau> Riddell: a grep reveals this string is only translated for es, fr, pt_BR, sv and uk
[13:57] <Riddell> agateau: translations from src po/ dir get imported into launchpad, language packs get made by exporting from launchpad, language packs will get updated from launchpad after release
[13:58] <Riddell> agateau: so we can probably change the string update those manually in launchpad which will see them appear in the next language pack update
[13:58] <ScottK> stikonas: I found your packagekit problem.  For some reason you don't have syslog running/reachable and that's why it crash.  That's also why it didn't crash for everyone.
[13:58]  * JontheEchidna prepares new kcm-gtk release to fix translation loading
[13:58] <ScottK> stikonas: I also did a packagekit fix and have uploaded it, so this may be fixed by release time.
[13:59] <agateau> Riddell: just to be sure I get it, we ship the untranslated string, and users will get it translated with next language pack update
[14:01] <Riddell> agateau: yes
[14:01] <agateau> Riddell: so nothing to do right now. I like this plan :)
[14:02] <Riddell> JontheEchidna: I commented on bug 458779, it's not the same crash as yesterday but he does have the bad poppler so maybe it's caused by the same issue
[14:02] <Riddell> JontheEchidna: did you look into userconfig translations?
[14:02] <JontheEchidna> Riddell: there is some info floating around on the ML
[14:03] <JontheEchidna> any translations would have to come after release at this point
[14:03] <Quintasan> JontheEchidna: where can I find documentation for PyKDE4? The site says nothing and python-kde4-doc contains only examples
[14:04] <Riddell> Quintasan: what do you want?  techbase.kde.org has some examples
[14:04] <Riddell> and a tutorial
[14:04] <JontheEchidna> Quintasan: just use the C++ docs, and try to pythonize them in your mind
[14:04] <JontheEchidna> then just fiddle with things until they work :D
[14:04] <Riddell> there are also pythonised docs on api.kde.org
[14:10] <ScottK> Riddell: jjesse is involved in kubuntu-docs too.  He may know.
[14:10] <jjesse> what was the question?
[14:12] <ScottK> jjesse: Pasted to a PM
[14:12] <ScottK> That was from #ubuntu-devel
[14:19] <Riddell> jjesse: so if you know how to build kubuntu-docs with translations I'm sure dpm would love to learn :)
[14:20] <dpm> haha
[14:20] <dpm> https://wiki.ubuntu.com/DocumentationTeam/Translation
[14:20] <jjesse> Riddell i was chatting w/ ScottK and i don't know how to build the docs at all, nixternal has always done that, mdke on #ubuntu-doc builds the ubuntu doc and would be able to help
[14:21] <Riddell> I used to do it but not for many a year
[14:24] <dpm> Riddell, can you access this location for requesting kubuntu translation exports? -> https://translations.edge.launchpad.net/ubuntu/karmic/+source/kubuntu-docs/+export (no need to do it, I've already requested an export)
[14:25] <Riddell> dpm: yes
[14:29] <Quintasan> look like I won't get anywhere with porting printer-applet to KNotification, Looks like I'm still a total beginner :O
[14:30] <JontheEchidna> Quintasan: oh, I don't think it has bindings yet
[14:30] <JontheEchidna> it should in 4.4 though
[14:30] <Quintasan> JontheEchidna: well, someone else will have to do it since I'm already overwhelmed by pycode
[14:30] <Quintasan> :S
[14:30] <JontheEchidna> lol
[14:31] <Quintasan> well I should stick with learning C++ and Qt for now
[14:31] <Riddell> update-notifier-kde uses KNotification
[14:31] <ScottK> I know the printer thing is a bit largish and not the most beautiful thing, but it works and works well here.  Please don't break it.
[14:31] <JontheEchidna> oh, KNotification, not KNotificationItem
[14:32] <Riddell> but not KNotificationItem, I don't know if that has bindings
[14:32] <JontheEchidna> Quintasan: sry, got confused
[14:32] <JontheEchidna> KNotificationItem will have bindings in 4.4 from what I hear
[14:32] <JontheEchidna> KNotification should have bindings
[14:32] <Riddell> infact printer-applet uses KNotification
[14:33] <JontheEchidna> oh, cool
[14:33] <Riddell> update-notifier-kde wants it's KNotification's changed to be persistent rather than using systray icons
[14:33] <Riddell> and printer-applet wants KNotificationItem
[14:33] <Quintasan> JontheEchidna: I read KNotfication in ML :P It's KNotificationItem
[14:34] <JontheEchidna> oops
[14:34] <Riddell> the naming is pretty confusing
[14:35] <Quintasan> procastrination is sure a scary thing
[14:36] <agateau> Riddell: yes, unfortunately, they didn't want to change it, even after it was pointed out that it was confusing :/
[14:47] <dpm> Riddell, adiroiban might be interested in helping out with kubuntu-docs
[14:47] <jjesse> have him ping me and nixternal on #ubuntu-docs sometime
[14:50] <Riddell> jjesse: best do it here, we need this toot sweet
[14:51] <Riddell> adiroiban: do you know how to get translated docs into kubuntu-docs?
[14:53] <JontheEchidna> Riddell: could you sponsor bug 458695 please?
[14:53] <Riddell> ok
[14:53] <JontheEchidna> thanks
[14:53] <JontheEchidna> The release changes the kcm's plugin name to match the translation domain
[14:54] <JontheEchidna> and also has translations exported from launchpad for the benefits of those not using launchpad (doesn't effect us, in other words)
[15:00] <Riddell> a crapton of translations no less, although these days I'd expect computer people to use metric craptonnes :)
[15:02] <ScottK> Probably still some legacy use of the nautical crapton to be considered though.
[15:03] <JontheEchidna> lol
[15:05] <stikonas> ScottK: thanks for fix
[15:06] <ScottK> stikonas: No problem.  Please note for the future though that "Why are you releasing a kpackagekit that's totally broken" wasn't very accurate or a pleasant way to find out about the problem.
[15:06] <stikonas> Sorry for that
[15:07] <ScottK> OK.  Please just take the lesson learned for next time.
[15:07] <ScottK> You also my want to figure out why your syslog is broken if you didn't do it on purpose.
[15:08] <stikonas> It seems that I have no syslog installed at all which is strange
[15:08] <stikonas> is this syslog-ng package?
[15:08] <ScottK> No, rsyslog
[15:08] <dpm> Riddell, adiroiban, in the meantime I'll give it a shot. For the record, I've received the link to the translations export -> http://launchpadlibrarian.net/34250048/launchpad-export.tar.gz
[15:09] <ScottK> There are many different ones, but that's the one that's default in Karmic.
[15:09] <ScottK> stikonas: You might want to investigate your logs to try and figure out where your syslog went.
[15:10] <ScottK> In particular, I'd suggest the upgrade logs assuming you upgraded to Karmic from a previous release.
[15:10] <stikonas> I've was upgrading from Alpha 5 or 6
[15:10] <stikonas> it was a clean install
[15:11] <stikonas> yes, it was removed on 15/09/2009 due to some dependency problems
[15:14] <stikonas> shouldn't then kubuntu-desktop depend on rsyslogd but not recommend it (now kubuntu-desktop->depends on anacron->recommends rsyslogd)
[15:14] <Riddell> packagekit should
[15:15] <Riddell> stikonas: do file a bug, glatzor the packagekit maintainer isn't around
[15:16] <ScottK> Riddell: I did fix packagekit to at least not crash if it's missing.  The upload is pending acceptance for Karmic.
[15:17] <stikonas> so, should I file a bug against packagekit, or not?
[15:18] <ScottK> Riddell: I tend to think syslog is something that should be provided by the system and not something individual packages that log should depend on (makes switching syslogs harder)
[15:19] <ScottK> stikonas: Can you pastebin the log that shows it getting removed?
[15:19] <stikonas> ScottK: my log is Lithuanian
[15:20] <ScottK> stikonas: How about if you pastebin it and I'll ask you what specific words mean if I need to know (a lot I can guess from context(
[15:20] <stikonas> ScottK: from /var/log/apt/term.log.1.gz ?
[15:21] <stikonas> or is there a better log
[15:21] <ScottK> stikonas: Yes.  That's good
[15:24] <stikonas> ScottK: I've attached the whole log here: http://people.pwf.cam.ac.uk/as932/files/term.log.1
[15:25] <ScottK> Thanks
[15:27] <adiroiban> back
[15:27] <ScottK> stikonas: What is "Šalinamas"?
[15:27] <adiroiban> Riddell: yep, I can build the translated xml files for kubuntu docs
[15:28] <stikonas> ScottK: Removing
[15:28] <ScottK> Thanks
[15:29] <adiroiban> I knew that nixternal was handling them, and I told him he can contact me in case he need help
[15:29] <adiroiban> i am subscribed to ubuntu-docs and happy to help with the translation port of u/k/xubuntu-docs if needed
[15:29] <ScottK> Šalinamas ubuntu-minimal is not a good thing.
[15:30] <stikonas> ScottK: I've reinstalled it
[15:30] <stikonas> ScottK: thanks
[15:31] <dpm> adiroiban, I've already started^^, but if you want to continue, please go ahead, you can reuse the link of the exported translations above
[15:32] <adiroiban> ok. but who should upload the kubuntu-docs package ?
[15:33] <dpm> adiroiban, Riddell said he could do it
[15:33] <adiroiban> same question for xubuntu ?
[15:33] <adiroiban> ok
[15:33] <dpm> adiroiban, it's only about Kubuntu for now
[15:34] <dpm> exporting translations, building a new package with them included and uploading it
[15:34] <adiroiban> then I will let you handle the kubuntu docs
[15:34] <adiroiban> and I can help with xubuntu docs
[15:35] <adiroiban> btw. for kubuntu docs I don't know if the Rosetta templates were updated
[15:35] <Quintasan> *"12155" <-- c++ wtf
[15:35] <adiroiban> I remember last time some of them were missing and some were obsolete
[15:36] <dpm> I'll only incorporate those in the package, then. I've noticed in the export that there are some obsolete ones, yes :(
[15:36] <ScottK> Meh.  He left
[15:38] <adiroiban> maybe we should have an IRC meeting and talk about the current state of kubuntu-docs
[15:39] <adiroiban> for me it is not clear how kubuntu and xubuntu docs are handled
[15:39] <adiroiban> and if we have a person taking care of them
[15:39] <adiroiban> like updating and fixing errors
[15:41] <ScottK> adiroiban: Probably we should focus on the translations for today though since that's tied to the release.
[15:41] <ScottK> adiroiban: nixternal and jjesse do work on maintaining kubuntu-docs
[15:41] <adiroiban> ok
[15:42] <adiroiban> but do we have the updated templates in Rosetta?
[15:43] <ScottK> No idea
[15:43] <adiroiban> for example kubuntu-docs basic-concepts was last updated 2009-04-17 19:31:16
[15:44] <adiroiban> maybe this is not a problem, since it should not be updated
[15:47] <dpm> adiroiban, I think we should then update the templates in the package, manually upload them, let LP do the necessary merging (and perhaps disable the obsolete ones), once finished export translations and only then rebuild and upload the package
[15:49] <adiroiban> yep. ubuntu-docs can be manualy updated
[15:49] <adiroiban> but they will not be translated
[15:49] <dpm> ??
[15:49] <adiroiban> we will not have translations for the new/modifed strings
[15:50] <dpm> adiroiban, kubuntu-docs, you mean
[15:50] <adiroiban> yes
[15:50] <dpm> well, it depends if the templates have changed or not
[15:50] <adiroiban> dpm: have you talked with nixternal or jjesse ?
[15:51] <adiroiban> maybe they can give us some hints about what was changed
[15:51] <adiroiban> or do you know which packages should be updated
[15:51] <adiroiban> and which are obsolete?
[15:52] <dpm> adiroiban, nixternal is away, and jjesse was here earlier, I'll ask at ubuntu-doc. The obsolete templates I assume will be those for which there is a template in the export, but not in the package. And re: which templates to update, probably best to regenerate all of those in the package
[15:53] <adiroiban> ok
[15:53] <dpm> brb
[15:53] <adiroiban> I will be away for the next 1 or 2 hours. We can continue then. Meanwhile, if you can update the rosetta templates
[15:54] <adiroiban> I can then do an export and generate the translated xml files
[16:05] <dpm> adiroiban, ok
[17:12] <dpm> adiroiban, Riddell, kubuntu-docs packaging might require more work than just adding the translations. By building the package, if I'm not mistaken, translations don't seem to be used
[17:12] <dpm> the translated html files don't seem to be built, I mean
[17:12] <adiroiban> dpm: you don't need the html
[17:12] <adiroiban> only the xml
[17:13] <adiroiban> yelp automaticaly generates the HTML files
[17:13] <dpm> adiroiban, well, nothing localised gets built. And Kubuntu doen't use yelp
[17:13] <adiroiban> I'm generating the HTML files only for debuging purpose
[17:13] <adiroiban> dpm: :) good point
[17:14] <dpm> adiroiban, :-)
[17:14] <adiroiban> i talked with jjesse on #ubuntu-doc and he told me everything is OK with kubuntu-docs
[17:15] <dpm> adiroiban, I saw it, I'm there as well. The comment, though, doesn't look to me as if anyone has looked at the translations at all
[17:17] <adiroiban> we should look at the jaunty or hardy package and see how kubuntu-docs are used in the system
[17:18] <dantti> Riddell: ping
[17:20] <Riddell> hi dantti
[17:20] <dantti> Riddell: was you that added in kpackagekit the catalog name?
[17:23] <Riddell> dantti: yes
[17:23] <dantti> Riddell: may i ask why?
[17:23] <Riddell> dantti: because it wasn't loading the catalogue
[17:24] <dantti> Riddell: here it loads without a problem KAboutData should do it, no need to do it manually
[17:24] <dantti> Riddell: maybe a kaboutdata bug?
[17:24] <Riddell> dantti: when loading as a kcontrol module kaboutdata doesn't get used
[17:26] <dantti> Riddell: hmm true, but it's used by system settings to tell the application name, maybe it's a bug,,, dunno..
[17:28] <Riddell> K_EXPORT_PLUGIN(KPackageKitFactory("kcm_kpk_update"))  possibly that is what gets used as the default catalogue name for kcontrol module?
[17:30] <dantti> Riddell: hmm good question, but maybe yes.. the problem is that at the end they will end up in just one app
[17:30] <dantti> so maybe there is no way without it..
[17:30] <dantti> i need to release <IP_ADDRESS> but somehow startup got so slow..
[17:36] <adiroiban> dpm: kubuntu-docs are displayes using konqueror ?
[17:37] <JontheEchidna> adiroiban: they're viewed from khelpcenter
[17:37] <Riddell> adiroiban: khelpcenter
[17:38] <adiroiban> thanks
[17:39] <markey> Riddell: tsdgeos... just don't take him too seriously
[17:39] <markey> noone does
[17:39] <adiroiban> and khelpcenter is using xml or html files?
[17:39] <markey> well except himself
[17:40] <markey> there is that
[17:40] <JontheEchidna> adiroiban: html files
[17:45] <Riddell> markey: ach it's not unreasonable that he gets grumpy, we forked kpdf for a while which was a headache for him, plus other issues that are his domain
[17:47] <dpm> adiroiban, I'm uploading the package with the exported translations integrated to http://people.canonical.com/~dpm/kubuntu-docs/kubuntu-docs-9.10.3/docs/ if you want to have a look and save some time (the LP export messes up the po files' paths and names), it's going to take a while until it's finished
[17:47] <dpm> but now I must go
[17:48] <adiroiban> ok
[17:48] <adiroiban> I'm still looking how kubuntu-docs i18n is implemented
[17:48]  * ScottK notes he will be TIL for packagekit now.  Didn't think of that before I fixed the crash.
[17:56] <adiroiban> what packages provides the kubuntu-docs translations ?
[17:57] <adiroiban> for ubuntu the xml files are uploaded with ubuntu-docs source package, but they are shiped in the language packs
[17:57] <Riddell> adiroiban: kubuntu-docs does
[17:58] <jjesse> did someone talk to mdke on #ubuntu-docs about how this owuld, he udnerstands both kubuntu-docs and ubuntu-docs packages
[17:58] <adiroiban> ok. so kubuntu-docs should also include /usr/share/doc/kde/HTML/es/
[17:58] <adiroiban> and other translations
[17:58] <Riddell> adiroiban: see http://packages.ubuntu.com/jaunty/all/kubuntu-docs/filelist
[17:58] <Riddell> yes
[17:59] <Riddell> jjesse: he's been idle
[17:59] <jjesse> hrmm ok
[17:59] <jjesse> sorry that i don't know about the packaging
[18:00] <Riddell> nobody does, it's all a mystery
[18:00] <adiroiban> Riddell: so kubuntu-docs html files were not moved in language packs?
[18:00] <Riddell> adiroiban: not that I know of
[18:00] <adiroiban> ok
[18:00] <adiroiban> then I will look at kubuntu-docs source package and I will try to create a package containing the translated html files
[18:15] <adiroiban> jjesse: can we take a look at kubuntu-docs templates enables in Launchpad ?
[18:16] <adiroiban> as they are not identical with the one from shipped-docs
[18:16] <jjesse> adiroiban ummm i'm sure you could i just don't know.... to be honest i juts write the docs and don't understand what happens next
[18:16] <adiroiban> that's ok
[18:17] <adiroiban> but for example we have systemdocs
[18:17] <jjesse> i feel bad that i can't have
[18:17] <adiroiban> is this file still used?
[18:17] <jjesse> help
[18:17] <adiroiban> or, let me ask in another way
[18:18] <adiroiban> the file "libs/shipped-docs" from kubuntu-docs source files
[18:18] <adiroiban> is listing the correct templates used in Kubuntu docs ?
[18:21] <adiroiban> jjesse: it's ok if you don't know.  How are kubuntu-docs files updated ? (for example, in case you found a spelling error)
[18:22] <jjesse> sorry a bit swamped at work so a bit delayed
[18:22] <jjesse> so all of the files for karmics docs are in lp:kubuntu-docs
[18:22] <jjesse> so i branch lp:kubuntu-docs, make changes to the .xml files (docbook format) and commit to the branch
[18:22] <adiroiban> ok
[18:23] <adiroiban> and what about kubuntu-docs source package?
[18:23] <jjesse> only members of the Ubuntu Documenation Committers team can commit to the main branches (ie lp:ubuntu-docs, etc)
[18:23] <Quintasan> Riddell: are we shipping soprano-backend-sesame with default install?
[18:23] <adiroiban> do you manualy copy them?
[18:23] <jjesse> as far as i know nixternal builds those, but he's on his bike for the next month
[18:23] <adiroiban> so you don't know how he builds them ?
[18:25] <jjesse> no i don't, i left him a voice mail and sent him a txt message in case he has his phone on him while biking
[18:25] <Riddell> Quintasan: no, it's non-free and depends on java
[18:25] <Riddell> Quintasan: but if you open the nepomuk kcontrol module it'll suggest you install it
[18:25] <adiroiban> I just want to know how you build the kubuntu-package, and see where should I put the script that is doing the translations
[18:25] <Quintasan> doesnt work for me :/ still uses redland, I have sesame set in nepomukrc but it complains the file doesnt exist while it is there
[18:26] <adiroiban> jjesse: no problem, we can solve this problem
[18:26] <jjesse> yeah  i understand your questions just dont know how he does it
[18:28] <Riddell> dpm-afk, ArneGoetje, (yuriy): there are two .pot file generated during build of userconfig, desktop_userconfig.pot and userconfig.pot, launchpad doesn't seem to know about them, any idea where they've gone?
[18:29] <neversfelde> debfx: the problem with the brightness on my ideapad occurs after waking up from suspend. So probably related to the powerdevil changes ScottK mentioned and not to your patch.
[18:30] <ScottK> Well I haven't narrowed that one down yet.
[18:32] <adiroiban> Riddell: are you building the package with strip-translation enabled?
[18:33] <adiroiban> https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation#Verifying%20translation%20uploads
[18:37] <Riddell> adiroiban: which, userconfig?  that produces http://paste.ubuntu.com/299924/ which looks fine
[18:38] <adiroiban> Riddell: yes, they are ok for the import of POT files
[18:38] <adiroiban> but the upstream translations (if any) are not there
[18:39] <adiroiban> and it is best to have each POT file in it's own folder
[18:39] <Quintasan> Riddell: it propably won't even work, at least with sun's jre installed
[18:39] <adiroiban> like po/domainX/domainX.POT
[18:39] <adiroiban> and po/domainY/domainY.POT
[18:40] <Riddell> adiroiban: there's no upstream, we are upstream.  all KDE apps put .pot files into the po/ directory
[18:41] <adiroiban> and where are the PO file stored?
[18:41] <Riddell> adiroiban: well the hope is in launchpad, but it's failing there
[18:42] <adiroiban> Riddell: this is ok for Ubuntu packages
[18:42] <adiroiban> but if for example openSuse is using that package ?
[18:42] <adiroiban> they will not use Launchpad
[18:42] <adiroiban> so the po files should be provided in the source package
[18:43] <ScottK> adiroiban: We should probably focus on the Karmic release critical bits of the problem today though.
[18:43] <Riddell> no, only we're using it and we're expecting launchpad to handle the translations, hopefully yuriy will put it into KDE at some point soon
[18:43] <adiroiban> I agree. we should look into Karmic problems
[18:45] <adiroiban> Riddell: last upload of userconfig was on Fri, 04 Sep 2009 12:28:35 +0200
[18:45] <adiroiban> https://edge.launchpad.net/ubuntu/karmic/+source/userconfig
[18:45] <adiroiban> this is the source package?
[18:46] <adiroiban> is this the source package?
[18:46] <Riddell> adiroiban: yes
[18:46] <adiroiban> maybe you should upload it again
[18:46] <adiroiban> and trace the problem
[18:46] <Riddell> and pray that launchpad does it right this time :)
[18:47] <Riddell> it does need uploaded though, it's not loading the right catalogue even if they did exist
[18:47] <adiroiban> I don't know if Rosetta is keeping the logs from Sept
[18:47] <JontheEchidna> Don't we generate the .pots using kubuntu.mk from pkg-kde-tools?
[18:47] <adiroiban> please upload it again I will look into the import queue
[18:47] <JontheEchidna> oh, right, they are being generated, nvm
[18:48] <adiroiban> if nothing happens we can ask for some help from Danilo
[18:48] <Riddell> adiroiban: ok, I'll need to fix the loading first, shouldn't be too long
[18:49] <adiroiban> and for the other problem. Maybe we can have a short chat durring UDS to talk about Kubuntu translations and how they are handled in Rosetta ... I know we had one last time
[18:55] <ScottK> adiroiban: I think our discussion is about if for UDS, not how.
[18:57] <adiroiban> sorry, I don't understand your statement
[19:02] <ScottK> adiroiban: There's a large contingent of Kubuntu devs that would rather just use upstream translations and skip Rosetta entirely.
[19:16] <debfx> there are some dependency problems with konqueror plugins: konqueror-plugin-searchbar depends on konqueror-plugins depends on konq-plugins recommends konq-plugins-l10n conflicts with konqueror-plugins
[19:16] <debfx> I guess konqueror-plugin-searchbar should directly depend on konq-plugins
[19:17] <Riddell> debfx: mm, those packages are a bit of a rename mess
[19:17] <debfx> and kubuntu-desktop still recommends konqueror-plugin-searchbar
[19:17] <JontheEchidna> oh, I know what's wrong. That huge conflict list isn't necessary, only the replaces list
[19:17] <Riddell> debfx: that seems a sensible solution, fancy doing a debdiff?
[19:17] <Riddell> or a bzr branch, I think it's in bzr
[19:18] <JontheEchidna> ah, the huge conflicts list was already taken care of
[19:18] <JontheEchidna> the transitional packages weren't updated to depend on the latest name
[19:20] <JontheEchidna> so all of the transitional packages need changing, not just -searchbar
[19:20] <Riddell> debfx: right, the seeds never got changed, but I don't want to do that this late
[19:21] <debfx> hm still konqueror-plugins wouldn't be installable without ignoring "recommends konq-plugins-l10n"
[19:22] <JontheEchidna> that should be removed
[19:27] <debfx> an easy fix would be to make the conflict with konqueror-plugins versioned like the others
[19:28] <Riddell> yuriy, adiroiban: userconfig translation fixes committed to bzr and uploaded to ubuntu
[19:28] <debfx> JontheEchidna: what should be removed?
[19:29] <JontheEchidna> debfx: konqueror-plugins should no longer recommend the -l10n package, it's just a transitional package anyways
[19:29] <adiroiban> ok.
[19:29]  * Riddell goes sliding over water
[19:29] <JontheEchidna> have fun
[19:30] <debfx> JontheEchidna: it doesn't
[19:31] <JontheEchidna> I believe I am confusing myself now...
[19:31] <debfx> JontheEchidna: it depends on konq-plugins which recommends konq-plugins-i10n
[19:31] <JontheEchidna> ah, yes
[19:33] <JontheEchidna> I don't think there's a problem as long as the other transitional-invdividual-plugin packages don't depend on konqueror-plugins
[19:33] <JontheEchidna> but rather depend on konq-plugins
[19:34]  * JontheEchidna really wishes debian could make up their mind on the names
[19:40] <debfx> JontheEchidna: this should fix it http://paste.ubuntu.com/299962/ (konq-plugins-i10n)
[19:40] <debfx> so it only conflicts with the jaunty package
[19:42] <JontheEchidna> that would fix that issue, yes
[19:44] <JontheEchidna> a cleanup of the other stuff should probably wait until 10.04, to not risk messing other things up
[19:50] <EagleScreen> ey
[19:50] <EagleScreen> Firefox open/save dialog are KDE in OpenSuse, why dont you do the same for Kubuntu?
[19:53] <EagleScreen> I think the package mozilla-xulrunner191-kde4 is the package provide it
[19:53] <debfx> EagleScreen: I set up a PPA that contains experimental firefox packages with the kde patch: https://edge.launchpad.net/~debfx/+archive/firefox-kde
[19:54] <EagleScreen> interesting PPA
[19:54] <EagleScreen> what is kmozillahelper?
[19:55] <debfx> it's the helper application that handles the kde integration
[19:57] <debfx> opensuse calls the package mozilla-xulrunner191-kde4
[19:59] <yuriy> Riddell: oh great! thanks, sorry i didn't get to that
[20:13] <debfx> JontheEchidna: submitted a merge request: https://code.launchpad.net/~debfx/konq-plugins/ubuntu/+merge/13864
[20:13] <debfx> ah ok :)
[20:13] <JontheEchidna> now to figure out how to actually merge it...
[20:15] <JontheEchidna> I guess I just apply the patch and mark the merge as done
[20:18] <JontheEchidna> debfx: merged, thanks
[20:21] <debfx> JontheEchidna: I guess bzr merge lp:~debfx/konq-plugins/ubuntu ?
[20:26] <JontheEchidna> anyways, your patch is now in bzr. We just need somebody to sponsor
[20:30] <debfx> Riddell: could you sponsor konq-plugins, changes are already in bzr?
[20:37] <firephoto_> i did a clean install with an alternate cd. amd64. it leaves grub showing the list of boot options. is this normal for an alternate install?
[20:40] <Riddell> debfx: can do
[20:40] <Riddell> firephoto_: it is if you have multiple boot options
[20:43] <firephoto_> actually it must be the alternate installer. saw the same thing on a gnome test install from a week ago.
[20:44] <firephoto_> it was a single disk, full part install.
[20:51] <ScottK> debfx: Do you understand how all the pieces of display management fit together?  I'm having no luck figuring out a problem I've got.
[21:14] <txwikinger> wow.. kamic upgrade is going in the speed of 1000kB/s
[21:18] <Ramblurr> after upgrading to karmic, i can't build any apps that dep on phonon
[21:19] <Ramblurr> apparently qt 4.5.3 has borked the phonon headers
[21:19] <Ramblurr> what's the easiest way to downgrade?
[21:19] <Ramblurr> (qt that is)
[21:22] <Riddell> Ramblurr: karmic has qt 4.5.2
[21:22] <Ramblurr> o_0
[21:22] <Ramblurr> i ended up with 4.5.3 somehow
[21:23] <Riddell> it has a funny version no 4.5.3really4.5.2 because we reverted the version
[21:24] <Riddell> but yes phonon does change header location with every version, you just have to work around it with your compile by making sure the include location is in the compile line /usr/include/qt4/phonon/
[21:26] <ScottK> Riddell: That may explain the armel kdebase-runtime failure today.  I'm troubleshooting with NCommander right now
[21:26] <NCommander> ScottK, want to bet your x86 might have a similar failure now
[21:26] <ScottK> Could be.
[21:26] <NCommander> ScottK, BTW, you going to be at UDS Dallas?
[21:26] <ScottK> Planning on it
[21:28] <Ramblurr> Riddell: i'm missing the file "phononnamespace.h", and it isn't in /usr/include/qt4/phonon/
[21:31] <ScottK> NCommander: test build started
[21:33] <ScottK> Ramblurr: Do you have libqt4-phonon-dev installed?
[21:33] <Ramblurr> yes
[21:36] <ScottK> Ramblurr: What architecture are you on?
[21:37] <Ramblurr> i686
[21:40] <ScottK> Ramblurr: It's in the .deb
[21:41] <Ramblurr> hum
[21:41] <Ramblurr> reinstalling it
[21:43] <Ramblurr> heh
[21:43] <Ramblurr> that did it
[21:43] <Ramblurr> a bunch of headers are back
[21:53] <ScottK> Riddell: Right now our kdebase-runtime on armel is expecting /usr/lib/qt4/plugins/soprano/soprano_redlandbackend.so, but we are shipping /usr/lib/soprano/libsoprano_redlandbackend.so.  Any thoughts on how that might happen?
[21:55] <Riddell> Ramblurr: it's in both /usr/include/qt4/phonon/phononnamespace.h and /usr/include/qt4/phonon/phononnamespace.h
[21:56] <ScottK> Riddell: I think he's fixed by reinstalling it
[21:57] <ScottK> Out for a while
[22:29] <ScottK> NCommander: Any more thought on what to try?
[22:40] <sourcemaker> I am using luks fs... can I install the rc?
[22:41] <sourcemaker> in the bug report is has been declared as fixed...
[22:41] <sourcemaker> but I do not know... if the patch has been integrated to the rc alternative cd...
[22:42] <ScottK> sourcemaker: What bug report?  I'll check.
[22:42] <sourcemaker> https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/428435
[22:45] <ScottK> sourcemaker: That fix is not on the RC image.  It was done after.
[22:46] <sourcemaker> ScottK: ok thanks.... can I do the upgrade via alternative install und update the lastest patches... ?
[22:47] <sourcemaker> updates via internet
[22:47] <ScottK> I'm not familiar with luks fs.  If you have an existing Jaunty install, you can sudo do-release-upgrade -d with no CD at all.
[22:47] <sourcemaker> ScottK: ok
[22:51] <NCommander> ScottK, not offhand
[23:10] <adiroiban> here is the status/error report for kubuntu-docs http://l10n.ubuntu.tla.ro/kubuntu-docs-karmic/
[23:23] <Riddell> adiroiban: userconfig should be in now if you are able to look at the mangled translations for that
[23:23] <adiroiban> Riddell: I have reported a bug
[23:24] <Riddell> adiroiban: where?
[23:24] <adiroiban> Bug 459428
[23:24] <adiroiban> it  should be in langpack-o-matic
[23:24] <adiroiban> but I have also link it to userconfig and ubuntu-translations
[23:25] <Riddell> adiroiban: I guess just ignore languages with errors for kubuntu-docs for now, notify the translators and do those in a SRU?
[23:26] <adiroiban> yep. But I can not build the kubuntu-docs package on my system
[23:26] <Riddell> why not?
[23:26] <adiroiban> problem salve
[23:26] <adiroiban> solved
[23:26] <adiroiban> it was using platform
[23:26] <adiroiban> all
[23:26] <adiroiban> instead of any
[23:26] <Riddell> that was quick
[23:26] <adiroiban> also the debian/rules part that should install the translated files was commented
[23:27]  * txwikinger goes to me jcastro now
[23:27] <adiroiban> in debian/control
[23:27] <Riddell> txwikinger: give him a tickle from me
[23:27]  * ScottK hands txwikinger a "et"
[23:27] <adiroiban> i have changed the Architecture to any
[23:27] <adiroiban> is this ok?
[23:28] <txwikinger> Riddell:  will do
[23:28] <adiroiban> or it should be All?
[23:28] <ScottK> adiroiban: Docs should be all.
[23:28] <txwikinger> thanks ScottK ;)
[23:28] <adiroiban> then I will get this error: dpkg-genchanges: arch-specific upload - not including arch-independent packages
[23:29] <ScottK> You're on amd64?
[23:29] <adiroiban> http://pastebin.ubuntu.com/300107/
[23:29] <adiroiban> nope
[23:29] <adiroiban> 32bit
[23:29] <ScottK> Weird.
[23:30] <ScottK> Dunno
[23:35] <adiroiban> what is the diference between all and any ?
[23:36] <ScottK> A package is arch all if one binary can be used by all architectures.
[23:37] <ScottK> A package is arch any if it can by built for any architecture, but needs to be compiled for each one.
[23:37] <adiroiban> thanks!
[23:37] <ScottK> No problem


[01:53] <BenC> infinity: upload processing
[02:02] <infinity> BenC: adare and ross on manual, then.
[02:03] <infinity> (and accepting)
[02:03] <infinity> BenC: Needs a matching -meta too...
[02:05] <infinity> BenC: Ahh, there it is.
[03:45] <ScottK> jbicha: Please don't mark bugs fix released when the fix is in a PPA.  Fix released for an Ubuntu bug is for when the package is in Ubuntu.
[03:45] <ScottK> (re 1163062)
[03:47] <jbicha> ScottK: ok, should I mark it invalid? it only affects packages in the ppa
[03:47] <ScottK> jbicha: Yes.
[03:47] <ScottK> I wouldn't bother changing this one.
[03:51] <ScottK> jbicha: For Kubuntu PPAs we created a /kubuntu-ppa project and direct people to file bugs against PPA packages there.
[03:51] <ScottK> It wasn't clear in the case of that bug it only affected the PPA.
[04:16] <vibhav> good morning
[06:33] <doko> infinity, could you leave a comment on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701422
[06:36] <dholbach> good morning
[06:40] <infinity> doko: I'm not sure I have an opinion there.  I'm certainly not going to deviate from upstream, but vorlon's welcome to file a bug at sourceware.org
[06:41] <doko> slangasek, ^^^
[06:50] <infinity> slangasek: Looking at commit 7e66ee5142deda977163d0a858c3d2883cae3f07 and comparing manpages, I'm inclined to agree that including setfsuid and setfsgid in the list of set*id WUR changes there was probably a mistake.
[06:51] <infinity> slangasek: If you ask nicely, maybe I'll throw a patch upstream to revert that part of the commit and see if I get any arguments.
[06:52] <bkerensa> <(o.o) >
[06:52] <slangasek> infinity: "ask nicely" is code for "buy you a beer", right?
[06:53] <infinity> slangasek: Could be.
[06:54] <infinity> Bah, I was going to look and see if reality matched the manpage, but it's a straight syscall, there's no way for glibc to know that anyway.
[07:09] <doko> $ file !$
[07:09] <doko> file /usr/include/linux/stddef.h
[07:09] <doko> /usr/include/linux/stddef.h: very short file (no magic)
[07:10] <doko> infinity, apw,: empty file. do you know why?
[07:10] <dholbach> @pilot in
[07:12] <infinity> doko: Maybe the one define it used to have isn't necessary anymore?
[07:13] <doko> infinity, there is *no* define
[07:14] <doko> well, at least I would expect a comment
[07:14] <infinity> Hrm.  The kernel source has "#include <linux/compiler.h>" in that file.
[07:15] <infinity> Weird.
[07:16] <dholbach> Riddell, do you know if somebody is looking into bug 1131636?
[07:17] <dholbach> I'm asking because there's a workaround in bug 1155327 (which is in the sponsoring queue) and I'm not 100% sure what the best solution for now might be
[07:19] <doko> jamespage, could you have a look at the tomcat7 build failure?
[07:20] <doko> hmm, could retry with the updated openjdk too
[07:20] <infinity> doko: So, I'd guess the reason it's empty is because the one in the kernel is a single line including linux/compiler.h, which also doesn't exist in the userspace headers.
[07:21] <infinity> doko: But Andy may have better ideas about WTF oddity is going on there.  The UAPI mangling stuff could still have some bugs.
[07:52] <dholbach> hey mvo!
[07:52] <dholbach> mvo, I have an apt question :-D
[07:52] <mvo> hey dholbach
[07:52] <mvo> dholbach: sure, fire!
[07:53] <dholbach> mvo, it seems apt/dpkg is stuck over here unpacking a kernel package for some time now - how do I debug it?
[07:53] <mvo> dholbach: what does ps afx show?
[07:53] <mvo> dholbach: hm, its unpacking you say? then its a dpkg bug ;)
[07:54] <dholbach> mvo, http://paste.ubuntu.com/5669752/
[07:54] <ogra_> dholbach, hmm, i saw plenty of reports about that on G+ the last days
[07:54] <rbasak> infinity: ping
[07:54] <mvo> dholbach: and no terminal prompt/gtk debconf prompt anywhere?
[07:55] <dholbach> mvo, no
[07:55] <ogra_> seems to have started around wed. or thu. last week
[07:55] <mvo> dholbach: can you do a strace -p 19619 ?
[07:56] <dholbach> mvo,
[07:56] <dholbach> Process 19619 attached - interrupt to quit
[07:56] <dholbach> read(3,
[07:56] <mvo> dholbach: yeah, I suspected this, so it looks like aptdaemon did not give you a terminal/gtk debconf prompt :/
[07:57] <dholbach> mvo, so it's an aptdaemon problem?
[07:57] <doko> mvo: https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4410918
[07:58] <doko> can you reproduce this? hangs in the testsuite on i386
[08:04] <doko> didrocks, don't see pitti or seb128 here. could you organize a bug fixing party for the gtk/gir/gnome ftbfs in main (and maybe in universe)?
[08:05] <doko> didrocks, don't see pitti or seb128 here. could you organize a bug fixing party for the gtk/gir/gnome ftbfs in main (and maybe in universe)?
[08:05] <doko> seb128, ^^^
[08:05] <didrocks> doko: see, better to invoke the right people :)
[08:05] <seb128> doko, hey, just back from 4 days w.e, will have to figure out what's the workload for the next week(s) first, but I can see try to squash a few
[08:05] <seb128> doko, do you have a list?
[08:06] <doko> seb128, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130329-raring.html
[08:06] <seb128> thanks
[08:06] <doko> I think you know the package names better than I do
[08:07]  * ogra_ wonders what esound still does in main
[08:07] <dholbach> mvo, shall I kill the process and file a bug on aptdaemon about it?
[08:08] <mvo> dholbach: yes please
[08:09] <dholbach> thanks mvo
[08:09] <mvo> doko: probably the same bug that dholbach just experienced
[08:13] <dholbach> mvo, bug 1163163
[08:13] <dholbach> doko, ^
[08:16] <dholbach> Mirv, for https://code.launchpad.net/~timo-jyrinki/ubuntu/raring/ubuntu-touch-meta/fix_lp1163125/+merge/156464 would you mind adding a changelog entry?
[08:16] <dholbach> Mirv, apart from that I'm happy to sponsor it
[08:17] <Mirv> dholbach: there is one already?
[08:17] <Mirv> oh, changelog, not commit message
[08:17] <dholbach> hum
[08:17] <Mirv> ok, just a second
[08:17] <dholbach> perfect
[08:18] <Mirv> dholbach: pushed changelog change
[08:18] <dholbach> on it
[08:19] <Mirv> hmm, version bump probably still as native package?
[08:19] <Mirv> pushed that as well..
[08:20] <dholbach> thanks
[08:21] <dholbach> Mirv, uploaded
[08:22] <Mirv> thanks!
[08:26] <cjwatson> dholbach: https://code.launchpad.net/~timo-jyrinki/ubuntu/raring/ubuntu-touch-meta/fix_lp1163125/+merge/156464 - still time to abort that upload?
[08:28] <Mirv> ah, one more layer of autogeneration
[08:31] <dholbach> cjwatson, oops sorry - I'm happy to upload a newer version of it with a fix in the seeds file
[08:32] <cjwatson> dholbach: perhaps you could just sync up the seed branch I pointed to
[08:32] <cjwatson> that should be enough now, but we shouldn't make this kind of manual change in future
[08:33] <dholbach> yes, agreed - I haven't touched seed related bits in a very long time and I wasn't sure where this change needed to be made
[08:34] <dholbach> cjwatson, it's still in the unapproved queue of raring - so it could be rejected there if you like, but I can also just go and update the seeds
[08:34] <cjwatson> might as well just do the latter now
[08:34] <dholbach> ok
[08:34] <Mirv> proposed https://code.launchpad.net/~timo-jyrinki/ubuntu-seeds/ubuntu-touch.raring.fixlp1163125/+merge/156487 as well
[08:34] <cjwatson> I just want to avoid the two data sources getting out of sync, so that when somebody later comes along and tries to do things the right way they don't get confused at it randomly reverting changes
[08:35] <cjwatson> yep, that's correct, I'll merge it, thanks
[08:35] <dholbach> thanks Mirv, cjwatson
[08:38] <ogra_> cjwatson, hmm, could we set up meta MPs in a way that ubuntu-release, ubuntu-core-dev or ubuntu-cdimage gets the notifications  ?
[08:39]  * ogra_ would have liked to be notified for that one ... seems the only automatic subscriber for it is ubuntu-branches ... which is rather pointless
[08:40] <xnox> ogra_: just subscribe relavant team(s) to the lp:ubuntu/meta-foo branches.
[08:40] <ogra_> xnox, i know i can do that ... but before i blindly subscribe a team i rather get some feedback ;)
[08:42]  * ogra_ subscribed himself now
[08:42] <ogra_> though i dont think that gives me MP notifications ... and i dont want to be the only reviewer
[08:47] <cjwatson> ogra_: I'm not quite sure how it works TBH - those branches are magic in various ways
[08:49] <ogra_> heh
[09:05] <wgrant> ogra_: You'll get MP notifications if you configure your subscription to give you them.
[09:05] <wgrant> By default it doesn't, I don't think, but it asks you.
[09:07] <ogra_> wgrant, thx, i'll make sure thats set
[09:29] <doko> Laney, could you take of goocanvas for the next cycle? I see you are involved in the Debian issue
[09:36] <seb128> doko, he's off this week
[09:45] <doko> Riddell, ScottK: could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4442123 ? it looks like a wrongly set bin dir
[09:53] <Riddell> hmm, maybe some clashing with qt 5
[09:58] <ev> cjwatson: for what it's worth, bdmurray went ahead and implemented the mapping from bugs to crash signatures on https://errors.ubuntu.com: https://rt.admin.canonical.com/Ticket/Display.html?id=60462
[09:58] <ev> if memory serves, I believe you asked for this a while back
[09:59] <ev> trying to get it landed today
[09:59] <cjwatson> is that a bidirectional mapping?  I think I was looking for crash signatures to bugs
[09:59] <cjwatson> (the particular case I wanted it has been handled, but I'm sure I'll need that again at some point)
[10:00] <ev> err yes, the bidirectional stuff
[10:01] <ev> I think :)
[10:01]  * ev digs
[10:04] <ev> cjwatson: ah, we don't have that precisely, but its just because the API doesn't expose it. It's an easy fix that I'll make today.
[10:04] <cjwatson> OK, cool, thanks
[10:26] <doko> xnox woke up, db uploads starting ...
[10:27] <xnox> doko: you are funny. I notice a lot of gir ftbfs as well that can be fixed similar to https://launchpadlibrarian.net/135708494/ubiquity_2.14.0_2.14.1.diff.gz
[10:27] <xnox> doko: also what's up with all the underlinking? something changed in the linker/gcc?
[10:30] <doko> xnox, yep, did ping seb128 about the gtk/gir stuff
[10:30] <seb128> doko, xnox: seems like you guys are on desktop stuffs so I will wait before doing some so we don't conflict
[10:31] <doko> the underlinking was a bug, recently fixed in binutils
[10:31] <doko> seb128, no we stay away =)
[10:31] <seb128> doko, ok ;-)
[10:34] <rbasak> What does the "Set" column mean in the FTBFS reports????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
[10:34] <rbasak> Aargh. Sorry, stuck key.
[10:39] <rbasak> doko: can I help with some of these FTBFSes? What's already being worked on?
[10:40]  * rbasak is on +1 maintenance this month, but infinity is presumably asleep right now
[10:40] <doko> rbasak, see the recent uploads, I'll stop myself for today with this stuff. xnox did do the db packages
[10:41] <rbasak> doko: where to look? https://launchpad.net/ubuntu/raring/+queue?queue_state=3 or somewhere else?
[10:42] <doko> rbasak, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130329-raring.html
[10:42] <rbasak> doko: I mean for recent uploads
[10:42] <doko> ahh
[10:43] <doko> https://lists.ubuntu.com/archives/raring-changes/2013-April/thread.html
[10:43] <rbasak> OK - thanks!
[10:43]  * rbasak looks at sqlite3
[10:45] <wgrant> rbasak: The Set column indicates whether the source is in any packageset.
[10:45] <rbasak> wgrant: ones that are directly listed, or anything seeded?
[10:46] <rbasak> Oh
[10:46] <rbasak> Upload set.
[10:46] <rbasak> Gotcha
[10:47] <doko> rbasak, sqlite3 is done =)
[10:47] <wgrant> Packagesets tend to be based on the transitive closures of the seeds, right.
[10:48] <rbasak> doko: so it is. I'll look more carefully, thanks.
[11:04] <GunnarHj> cjwatson: Hi Colin, can you please take a look at bug 1163142? seb128 think you may be the right person to spot the problem.
[11:05] <seb128> cjwatson, I ran into a similar issue the other day, it seemed like dpkg/debconf being stucked on a read (from strace)
[11:05] <cjwatson> GunnarHj: is it reproducible locally?
[11:06] <cjwatson> seb128: in the same language-selector stack?
[11:06] <GunnarHj> cjwatson: I could easily reproduce it.
[11:06] <seb128> cjwatson, no, normal upgrade using update-manager for me
[11:06] <seb128> cjwatson, we have/had issues with the new unity-dash "spamming" gvfsd-http and hiting ulimit on open fds
[11:06] <cjwatson> seb128: yeah, if it was a different stack that's sort of like "I ran into a compiler error yesterday too" :-)
[11:06] <seb128> so I wonder if that could break debconf
[11:07] <cjwatson> much more likely that something is mishandling fds
[11:07] <cjwatson> in the layers above debconf
[11:07] <cjwatson> it's easy enough to do if e.g. you forget to mark the right things close-on-exec
[11:07] <cjwatson> GunnarHj: can you give me step-by-step instructions?
[11:08] <GunnarHj> cjwatson: Just try to install any language using language-selector. That's it.
[11:11] <seb128> cjwatson, right, I just wanted to point the dash eating all the available fds issue as a data point in case it's useful, but seems like that one could be a different bug
[11:12] <dholbach> @pilot out
[11:31] <cjwatson> GunnarHj: Got it.  I'll see what I can do
[11:31] <GunnarHj> cjwatson: Great, thanks!
[11:39] <didrocks> cjwatson: is it normal that natty is still on http://archive.ubuntu.com/ubuntu/dists/?
[11:41] <cjwatson> I think so, yes.  There's generally a delay on removing that due to various stragglers
[11:41] <didrocks> ah ok, thanks :)
[12:03] <melodie> hello
[12:05] <melodie> I am seeking help with casper and post install scripts for a little project, and I am not sure what the problem is to get to the goal. I would like the post-install script to put 2 launchers on the desktop : after install, whatever language it will be.
[12:06] <melodie> I have got it in the Live remix, thanks to a script in the casper-bottom directory, and from there I don't know how to achieve the rest ?
[12:07] <melodie> I have looked also the chan list to see if there is another chan where I could ask, and I didn't see any other more relevant
[12:10] <cjwatson> seb128: good news, this has nothing to do with unity; bad news, argh twisty pile of code
[12:11] <cjwatson> melodie: have a look at the ubiquity-hooks/ directory in the casper source
[12:11] <seb128> cjwatson, thanks for investigating it!
[12:11] <cjwatson> It doesn't have a *specific* example for desktop launchers, but scripts there are run by ubiquity post-install in much the same way that casper-bottom hooks are
[12:12] <melodie> hi cjwatson, among else there is one question I wondered: would the following bug be causing the desktop launchers from the live not be copied to the desktop ? https://bugs.launchpad.net/ubuntu/+source/xdg-user-dirs-gtk/+bug/1163043
[12:12] <melodie> i show you the script too:
[12:13] <melodie> http://paste.ubuntu.com/5670225/
[12:13] <cjwatson> sorry I don't know and can't look right now
[12:14] <melodie> no problem
[12:14] <cjwatson> the whole business of translated directory names is an incredibly stupid design guaranteed to lead to problems, of course
[12:14] <melodie> is there another chan somewhere else for that sort of question ? anyhow I can stay connected
[12:14] <melodie> oh so...
[12:14] <cjwatson> iron rule should be to translate for display but not in the underlying identifier
[12:15] <cjwatson> sadly some people failed to understand this ...
[12:16] <seb128> cjwatson, when you do that you run into issues where your filebrowser/fileselector doesn't match your translated UIs (or if you use an app using a toolkit which doesn't do the translation for you)
[12:17] <seb128> but yeah, each solutions have their issues
[12:17] <melodie> hi seb128
[12:17] <seb128> it's not a problem easy to solve as long as you give users direct access to the fs and don't have one toolkit
[12:17] <seb128> would be easier if we had one API and a file picker ;-)
[12:17] <seb128> melodie, hey
[12:18] <melodie> I saw you have triaged this bug I filled. thank you. :)
[12:18] <seb128> yw
[12:18] <cjwatson> seb128: the problem with the xdg solution is that it moves all the bugs away from xdg and into everyone else's scripts
[12:18] <cjwatson> classic example of externalising costs
[12:19] <cjwatson> which of course looks OK if you aren't on the receiving end :)
[12:20] <seb128> well, Desktop is sort of a special case and trickier
[12:20] <cjwatson> ah, here we go, the aptdaemon bug isn't quite as hard as I thought
[12:20] <cjwatson> missing flush
[12:20] <seb128> but for things like Music it does make sense to be able to define the directory to be whatever you want and to have the name translated
[12:21] <GunnarHj> melodie: Hi Mélodie!
[12:21] <seb128> cjwatson, \o/ on finding the aptdaemon bug ;-)
[12:21] <melodie> seb128 do you have an idea if it is possible to get these 2 poor launchers from the Live to the installed version ? this is the script which is used, maybe could be improved or completed or ? http://paste.ubuntu.com/5670225/
[12:21] <melodie> hi GunnarHj :)
[12:23] <seb128> melodie, can't you just add those files to /etc/skel ?
[12:23] <seb128> hum, I guess that's where the translated "Desktop" directory makes things harder...
[12:24] <melodie> seb128 perhaps not as long as casper creates the directories where it is supposed to go ?
[12:24] <melodie> yes, it is what makes it harder...
[12:24] <seb128> you don't use nautilus right?
[12:24] <seb128> nautilus a gsettings key for those special icons
[12:24] <melodie> I use pcmanfm, and could use as well thunar  or spacefm
[12:24] <seb128> which would make your job easier than having to .desktop files
[12:24] <seb128> to copy*
[12:25] <GunnarHj> melodie: I'm not sure about your suggestion with bold text in the Language Support UI. I do agree it would be motivated - you were not the first to have problem with the drag-and-drop thing - but I don't think we use bold text in other UIs, so it would be a style break.
[12:25] <melodie> GunnarHj then some color maybe ?
[12:26] <GunnarHj> :)
[12:26] <GunnarHj> melodie: Even worse, I'd say.
[12:27] <melodie> I have to check the bug report page to find another idea then
[12:27] <seb128> melodie, sorry, I'm not sure what's the best way to do that, out of shipping a small script that create those on first login
[12:27] <melodie> that would suit the need I'd say
[12:28] <melodie> I don't know how to do that, so if you would I will be very happy to get help at some point
[12:29] <GunnarHj> melodie: In the release after 13.04 we will switch to another UI completely. I'd suggest that we are patient in the meantime.
[12:29] <seb128> melodie, basically add a .desktop in /etc/xdg/autostart that call your script/command and make that script/command write a key/file somewhere to say its job is done and exit when the file exist
[12:29] <seb128> melodie, so it runs once and then do nothing from then on
[12:30] <melodie> nice! and that could also reproduce the process for each new user created: right ?
[12:30] <seb128> yes, those autostarts are run by the user and you should write the key/file in the user dir
[12:31] <melodie> thanks. I'll ask someone to do it that way and will test it right after
[12:33] <melodie> GunnarHj I agree when it comes to patience, there is no other way. Just if I can fetch an idea you could use, I'll give it a try. :)
[12:33] <doko> apw, ogasawara: I was looking at the tcpcopy ftbfs, looks like ip_queue.h isn't included in linux-libc-dev. it is in Debian. why not in Ubuntu?
[12:35] <GunnarHj> melodie: Thanks. :) (Still thinking about your idea - can't help it's tempting to make an exception.)
[12:36] <melodie> I am installing a new language in my version now, to remember how it looks like exactly
[12:37] <GunnarHj> melodie: Hmm... right now is probably a bad time to install a language. You'll probably see what I mean. :(
[12:37] <melodie> I got a dbus error but I neglected it
[12:37] <melodie> and that worked
[12:38] <melodie> I am adding an additional package so that it stops reminding me it is missing...
[12:38] <melodie> there is no option to dismiss it definitely, so...
[12:38] <GunnarHj> melodie: Did you succeed in installing a language on an updated Raring?
[12:38] <melodie> my work box is based on Precise
[12:39] <melodie> ^^
[12:39] <GunnarHj> melodie: Aha, that explains it. ;-)
[12:39] <melodie> when this little project will be fully finished then it will be time to move forward. :)
[12:39] <GunnarHj> Ok.
[12:40] <melodie> the program asked me to install gimp-help-fr for some time now : just thinking if an option to dismiss definitely could be nice to have
[12:40] <melodie> ok
[12:40] <melodie> GunnarHj I might have an idea you could use:
[12:40] <GunnarHj> melodie: Why do you think that would be important?
[12:42] <melodie> GunnarHj let's say it is a wish : the wish to be always free to do things how we want them. If I want to install language packs, but not all of them, because let's say, I don't need gimp help, well, why does this program insist forever ? :)
[12:42] <melodie> about drag and drop, here is the idea:
[12:42] <melodie> just adding 'HowTo:' on a line before the rest
[12:43] <melodie> in french 'Mode d'Emploi:'
[12:43] <melodie> and so on...
[12:43] <GunnarHj> melodie: Well, the simple answer would be that in Ubuntu languages are available on an all-or-nothing basis.
[12:44] <melodie> some of the packages do take quite some space, and it can be nice to be able to choose (it might make it more complicated to deal upstream, on your side, but for people with old boxes, low disk space, or just users who prefer to go minimal, it's nice)
[12:45] <GunnarHj> melodie: About the "HowTo" idea: There is a "Help" button at the bottom of the window.
[12:45] <melodie> GunnarHj this is right however it takes to install yelp... whereas the suggest I submit takes a few caracters to add
[12:46] <melodie> let me see how much adding yelp there brings in with depends...
[12:46] <melodie> it will bring in 27.2 Mo.
[12:47] <melodie> I check in the build directory of the project too...
[12:47] <GunnarHj> melodie: Actually the language support used to be more like you would like it. It was simplified a while ago, and changing it back would be non-trivial.
[12:47] <melodie> I get that
[12:48] <GunnarHj> melodie: Why are you so worried about disk space? Is that really an issue for you?
[12:49] <cjwatson> Language availability in Ubuntu is much less all-or-nothing than it used to be; I would argue that the point of check-language-support and friends was precisely to make it not all-or-nothing.
[12:50] <GunnarHj> cjwatson: Yeah, in the sense that you only install the languages you need, you are right, of course.
[12:51] <cjwatson> That wasn't what I meant.  It's much more fine-grained in terms of per-application packages than it used to be.
[12:52] <cjwatson> In that the only supported interface used to be that of installing language-support-LL, which installed all the support packages available for a given language; now you get to select support packages according to which applications you have installed, and it's clearly within the power of the management tools to be more picky than that if they want to.
[12:52] <cjwatson> Just a matter of how to handle the preferences.
[12:52] <GunnarHj> cjwatson: But a few cycles ago you could check which parts of the language support you wanted to install. That possibility is no longer there.
[12:53] <cjwatson> Right.  But that's a change in language-selector which you seemed to be trying to present as intrinsic to Ubuntu's language support availability.
[12:53] <cjwatson> It's not - it's purely a question of the UI.
[12:54] <GunnarHj> Hmm.. Have to think about that. ;-)
[12:54] <cjwatson> At least, there's nothing in the support package layout to prevent that.
[12:55] <GunnarHj> cjwatson: No, I agree it was a UI change. Still affecting the users' options in practice.
[12:58] <melodie> GunnarHj I didn't answer your question yet : it is interesting to spare disk space whenever possible. It is also often a difficult choice to do when building a project : keep this for the sake of the comfort of the user ? Or let the final user get it by himself ? what if he doesn't even fancy it can exist ? this is why I pay systematic attention to those details.
[13:01] <GunnarHj> melodie: A new UI will need to be written for language support handling when we switch to a new UI for the rest of language/locales settings. Maybe something to consider then.
[13:05] <melodie> GunnarHj this is very nice
[13:05] <melodie> if you can keep the idea aside...
[13:05] <melodie> :)
[13:13] <GunnarHj> melodie: Will try. :)
[13:14] <melodie> GunnarHj thanks. :)
[13:19] <xnox> wgrant: is it possible to "manually" superseed packages in test-rebuild results? e.g. with my pending tcltk-defaults uploads pidgin & ace are fixed from FTBFS.
[13:22] <cjwatson> xnox: It's simpler to retry those packages in the rebuild test
[13:22] <xnox> cjwatson: ah, awesome.
[13:25] <wgrant> xnox: Yeah, what cjwatson said.
[13:27] <mvo> cjwatson: thanks for your aptdaemon fix, shall I upload or are you on it already?
[13:27] <cjwatson> mvo: already uploaded
[13:28] <mvo> ta
[13:28] <cjwatson> Since I was pretty certain of it
[13:29] <davmor2> mvo: how do
[13:30] <mvo> cjwatson: yeah, totally
[13:31] <mvo> davmor2: good, thanks! and you?
[13:31] <davmor2> mvo: good, busy but that is good too :)
[13:44] <doko> xnox, did you give up with the Tcl/Tk multiarch thing?
[13:46] <xnox> doko: I didn't give up, just put in place compat shell script that can be sourced -> calls dpkg-architectures and chain sources the correct one.
[13:46] <xnox> doko: I'm not planning on spending my time fixing universe, when I can do it once and fix it for $most packages.
[13:47] <seb128> xnox, is that for tclConfig.sh changing path?
[13:47] <xnox> seb128: yes.
[13:47] <seb128> xnox, how is your fix working? does it mean I don't need to fix pidgin? ;-)
[13:48] <xnox> seb128: no need to fix pidgin. Pidgin will works out-of-the-box with fix in-place. (tested locally as one of the guinea pig packages)
[13:48] <doko> seb128, glib2.0 did fail again in raring on armhf
[13:48] <seb128> doko, it's weird, the same version built fine in debian and raring last week
[13:48] <doko> TEST: gdbus-close-pending... (pid=27574)
[13:48] <doko>   /gdbus/close-pending:
[13:48] <doko> (/build/buildd/glib2.0-2.36.0/debian/build/deb/gio/tests/.libs/lt-gdbus-close-pending:27574): GLib-CRITICAL **: g_main_context_wakeup: assertion `g_atomic_int_get (&context->ref_count) > 0' failed
[13:48] <doko> FAIL
[13:48] <doko> GTester: last random seed: R02S9237789288b283d4b059cc2abb315517
[13:49] <doko> /bin/bash: line 1: 19034 Terminated              G_DEBUG=gc-friendly MALLOC_CHECK_=2 MALLOC_PERTURB_=$((${RANDOM:-256} % 256)) dbus-launch ../../glib/gtester --verbose io-stream memory-input-stream memory-output-stream readwrite g-file g-file-info converter-stream data-input-stream data-output-stream g-icon buffered-input-stream buffered-output-stream sleepy-stream filter-streams volumemonitor simple-async-result srvtarget contex
[13:49] <doko> ts gsettings gschema-compile async-close-output-stream gdbus-addresses network-address gdbus-message socket pollable tls-certificate tls-interaction cancellable vfs network-monitor fileattributematcher resources proxy-test simple-proxy inet-address permission task credentials actions gdbus-connection gdbus-connection-loss gdbus-connection-slow gdbus-names gdbus-proxy gdbus-proxy-threads gdbus-proxy-well-known-name gdbus-introspec
[13:49] <doko> tion gdbus-threading gdbus-export gdbus-error gdbus-bz627724 gmenumodel gdbus-close-pending gdbus-connection-flush gdbus-peer gdbus-exit-on-close gdbus-non-socket gdbus-peer-object-manager appinfo contenttype mimeapps file live-g-file desktop-app-info unix-fd unix-streams gapplication basic-application gdbus-test-codegen gdbus-auth
[13:49] <doko> make[7]: *** [test-nonrecursive] Error 143
[13:49] <doko> make[7]: Target `check-local' not remade because of errors.
[13:49] <doko> make[7]: Leaving directory `/build/buildd/glib2.0-2.36.0/debian/build/deb/gio/tests'
[13:49] <doko> make[6]: *** [check-am] Error 2
[13:49] <doko> make[6]: Leaving directory `/build/buildd/glib2.0-2.36.0/debian/build/deb/gio/tests'
[13:49] <doko> make[5]: *** [check-recursive] Error 1
[13:49] <doko> make[5]: Leaving directory `/build/buildd/glib2.0-2.36.0/debian/build/deb/gio/tests'
[13:49] <doko> make[4]: *** [check] Error 2
[13:49] <doko> make[4]: Le
[13:49]  * seb128 hands a pastebin to doko
[13:50]  * doko hands seb128 https://launchpadlibrarian.net/135923939/buildlog_ubuntu-raring-armhf.glib2.0_2.36.0-1ubuntu1_FAILEDTOBUILD.txt.gz
[13:50] <seb128> doko, thanks
[14:02] <seb128> doko, what builds are used there? is that a normal/real builders or is that a qemu/virtual one?
[14:02] <tkamppeter> Anyone can help me with a problem caused by moving a conffile from one binary package to another? Bug 1162164
[14:02] <doko> seb128, normal, as for every test rebuild
[14:02] <desrt> how many CPUs are being emulated?
[14:03] <desrt> in the builder....
[14:05] <desrt> ie: is it emulating SMP or no?
[14:06] <seb128> desrt, doko is saying that's a normal builder and not a virtual one
[14:06] <seb128> doko, it's weird that we never hit that issue on the normal archive uploads
[14:07] <desrt> is it possible that the normal archive builders were single-core and this builder is multi-core?
[14:07] <desrt> the testcase is testing concurrency issues and the critical is on an atomic update of a refcount.... if that doesn't scream 'threading bug' i don't know what does
[14:08] <doko> afaik, all of these are configured for parallel=2 (or 3), just print DEB_BUILD_OPTIONS
[14:08] <desrt> doko: the build options are not interesting.  it's the hardware that is.
[14:08] <desrt> the testcases are run serially....
[14:08] <doko> desrt, well, then disable parallel tests
[14:08] <desrt> but they have threads
[14:09] <desrt> which is kinda the point... we want to test that our threading is working properly
[14:09] <xnox> tkamppeter: the best you can do is "Replaces: cups (<< 1.6.2-1ubuntu3)" in the "cups-daemon" package. There is no sane way to "unown" and "reclaim ownership" on a conffile and thus move it to a new binary package.
[14:10] <xnox> tkamppeter: where the version is the first one of package cups that does _not_ have /etc/init/cups.conf
[14:11] <desrt> does anyone know how many cores this builder has?
[14:11] <doko> desrt, these are all pandas, so two
[14:12] <desrt> and the other builders on which the build worked?  also two?
 desrt, these are all pandas, so two
[14:12] <xnox> desrt: we have procenv package that a build time does a lot system detection and prints a lot of interesting info. See https://launchpadlibrarian.net/126054733/buildlog_ubuntu-raring-armhf.procenv_0.19-1_BUILDING.txt.gz
[14:13] <desrt> seb128: we should have this in all our builds :)
[14:13] <cjwatson> xnox: are you certain that aleya and mothallah are identical hardware?  (I'm not)
[14:13] <seb128> desrt, did you find the bug?
[14:14] <desrt> seb128: no.  i don't even have an idea for the basis of the bug.
[14:14] <xnox> cjwatson: let me check what other builds of procenv we have in the history...
[14:14] <cjwatson> I checked, don't see one on mothallah.  it's probably quicker to ask webops.
[14:15] <seb128> doko, is there any way to throw a debug version of the package to the builder if we get one?
[14:15] <doko> seb128, upload to a non-virtualized ppa and make it build on armhf only?
[14:17] <ogra_> seb128, want access to the canonical-arm-dev PPA ?
[14:18] <seb128> ogra_, that could be handy but I don't have a strong need for it either, your call
[14:18] <ogra_> well, for doing testbuilds it might help
[14:19] <ogra_> it is real hardware ...
[14:19] <seb128> ogra_, can you get me added?
[14:20] <ogra_> seb128, done
[14:21] <seb128> ogra_, thanks
[14:36] <bdmurray> jodh: is there a ppa with a fix for bug 1163103?
[14:39] <jodh> bdmurray: not atm. It wasn't clear from the bug, but if that message is the only issue, ignore it - it's harmless.
[14:39] <bdmurray> jodh: oh, so it should still work then?
[14:40] <jodh> bdmurray: I certainly hope so :)
[14:40] <jodh> bdmurray: the problem is that the nih calls we're making assume the daemon is running as root. and it isn't :)
[14:45] <xnox> jodh: should be using XDG_RUNTIME_DIR for pid files as a user =)
[14:46] <bdmurray> jodh: and where is it logging?
[14:46] <jodh> xnox: the bridge now does, but NIH isn't xdg-aware yet alas :)
[14:49] <tkamppeter> xnox, thank you very much, strange is the message "trying to overwrite '/etc/init/cups.conf', which is also in package cups 1.6.2-1ubuntu3" as I have checked on my box and cups 1.6.2-1ubuntu3 does not contain /etc/init/cups.conf.
[14:50] <jodh> bdmurray: as of now, syslog (erroneously). The issue is fixed in upstream such that it'll log to stdout and thus end up in ~/.cache/upstart/upstart-file-bridge.log.
[14:50] <xnox> tkamppeter: correct, it doesn't exist on fresh installs. One must upgrade from the time when it did. =) I recently had to deal with a broken conffile dating back to hardy times =))))
[14:52] <tkamppeter> xnox, I have also checked http://packages.ubuntu.com/search?suite=raring&arch=any&searchon=contents&keywords=%2Fetc%2Finit%2Fcups.conf and only cups-daemon provides /etc/init/cups.conf, independent of the architecture.
[14:53] <doko> zul: are these server uploads (rc2) needed for the beta?
[14:53] <zul> doko:  when is the beta out again?
[14:53] <xnox> tkamppeter: sure, but in quantal it was in the cups package. So anyone upgrading from quantal or before, and had that conffile for example modified, it will be there causing upgrade conflict.
[14:54] <doko> zul: Thursday?
[14:54] <tkamppeter> xnox, and cups-daemon contains "Replaces: cups (<< 1.6.1-1~)".
[14:54] <xnox> tkamppeter: yeah, noticed.
[14:54] <zul> doko:  yeah i think they would be nice to have
[14:54] <doko> zul: could you note in the MIR issue, why cinder/nova need python-babel?
[14:56] <zul> doko:  i reopened the MIR that was previously opened but babel causes this bug when its not installed https://bugs.launchpad.net/ubuntu/+source/cinder/+bug/1126378
[14:57] <xnox> tkamppeter: hmmm... it looks like it could be a bug in apt-clone restore (used to upgrade using the desktop cd, as shown in the bug report)
[14:57] <doko> zul: could you add this info in 941913?
[14:57] <zul> doko:  ack
[14:58] <zul> doko:  done
[15:00] <tkamppeter> xnox, should I reassign this bug to apt-clone
[15:03] <xnox> tkamppeter: not sure, needs testing.
[15:03] <xnox> (reproducer)
[15:03] <xnox> tkamppeter: potentially cups may have to move the conffile out of the way....
[15:07] <tkamppeter> xnox, the conffile is /etc/init/cups.conf before and after, how should CUPS move it? Let pre-inst of cups-daemon rename it and post-inst of cups-daemon move it back overwriting the new cups.conf of cups-daemon?
[15:09] <xnox> tkamppeter: you should use rm_conffile on /etc/init/cups.conf in the cups package just like there are for the rest of conffiles.
[15:09] <xnox> tkamppeter: that way it will be removed and it will be "resurrected" afresh with no baggage by cups-daemon.
[15:09] <xnox> tkamppeter: also see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672945
[15:10] <slangasek> "support moving a conffile between packages" - that's called "Replaces:"?
[15:14] <xnox> slangasek: not really, as the conffile stays allocated to the previous package and even with replaces dpkg does not unpack the new one. See tkamppeter's raised issue in bug  https://launchpad.net/bugs/1162164
[15:15] <doko> slangasek, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4438112 ? you seem to know the maintainer
[15:16] <xnox> slangasek: or is the problem here, that we have a too strictly versioned Replaces?
[15:18] <BenC> cjwatson: Is there a way to make the ISO installer initrd check for install media on non-removable disks as well (e.g. hd partition)?
[15:18] <doko> afaik, we can't migrate config files between packages
[15:18] <BenC> I ask because virtio-blk doesn't show up as removable even when media=cdrom on qemu
[15:18] <ogra_> unless "Replaces" suddenly started secretly using dpkg-maintscript-helper
[15:21] <blitzkrieg3> would someone please sponsor bug 861171?
[15:49] <tkamppeter> xnox, but if I use rm_conffile in cups, does this happen before cups-daemon installes cups.conf? Or can it happen I end up without cups.conf at all?
[15:52] <stgraber> cjwatson: DMB meeting minutes in the ubuntu-devel-announce moderation queue for when you have a minute
[15:53] <cjwatson> stgraber: done
[15:53] <xnox> tkamppeter: cups' preinst will move cups.conf out of the way, cups-daemon postinst will put cups.conf in place. If dpkg still barks at you (it shouldn't as far as I remember), then cups-daemon will need a Pre-Depends: cups (at least the first version that did not have cups.conf)
[15:53] <stgraber> cjwatson: thanks
[15:54] <xnox> tkamppeter: there will be a window of no cups.conf on disk and depending on the options to dh_installinit it may be stopped as well while the upgrades are in progress.
[15:57] <slangasek> xnox: the conffile is still attached to the previous package, but is *also* attached to the new package and a subsequent upgrade of the old package fixes up the dpkg database; and regardless of which package it's associated with in the database, TTBOMK the user-visible *behavior* is what we want/expect
[15:57] <slangasek> doko: "know the maintainer" - you mean I touched it last? :)
[15:58] <slangasek> tkamppeter, xnox: I strongly disagree that rm_conffile is warranted here - reparenting of conffiles via Replaces: has been working for years
[15:58] <slangasek> and if it's not working now, we should figure out why and address it
[15:59] <doko> nm, seb did fix it
[15:59] <xnox> tkamppeter: in that case the version number should be higher in the "Replaces" field. It should be same or lower than current cups source package. All the way until next lts.
[15:59] <slangasek> doko: that "nm" is to me?
[16:00] <slangasek> xnox: it should only need to declare Replaces: on the last version of cups that shipped the conffile
[16:00] <xnox> slangasek: in the linked error log, the unpack of packageB claims that conffile is still present in packageA off the versionNew.
[16:00] <xnox> s/off/of/
[16:01] <slangasek> xnox: I haven't seen this link
[16:01] <slangasek> link me? :)
 slangasek: not really, as the conffile stays allocated to the previous package and even with replaces dpkg does not unpack the new one. See tkamppeter's raised issue in bug  https://launchpad.net/bugs/1162164
[16:02] <xnox> slangasek: I did at 16:14 Oxfordshire time ^^^^
[16:02] <xnox> =)
[16:03] <slangasek> xnox: ah, k :)
[16:14] <infinity> rbasak: What was that contentless ping about?
[16:14] <rbasak> infinity: sorry. +1 maintenance. It's April.
[16:14] <infinity> It sure is.
[16:14] <infinity> In a meeting right now, sec.
[16:14] <tkamppeter> xnox, so you mean that any version of cups-daemon N should have Replaces: cups (<< N)?
[16:14] <rbasak> np
[16:15] <xnox> tkamppeter: (<= N)
[16:15] <tkamppeter> xnox, so cupsa-daemon should also replace cups of the same source package version?
[16:16] <tkamppeter> xnox, cups needs cups-daemon.
[16:16] <xnox> tkamppeter: yeah or less.
[16:16] <xnox> *sigh*
[16:17] <xnox> tkamppeter: either get a real solution from slangasek =) or use rm_conffile as my original idea is. Since afaik there is no sane way to "move" a conffile from one package to the other.
[16:18] <tkamppeter> xnox, so should I assign the bug to slanagasek (and perhaps also add a dpkg task)?
[16:19] <tkamppeter> s/slanagasek/slangasek/
[16:19] <xnox> =)))) we should get a simple reproducer of it in a chroot first.
[16:19] <xnox> cause that's the first thing that will slangasek ask for before punting it into "incomplete" state =)
[16:21] <doko> chasing this bus error building libx11 docs on i386 ... can't reproduce it in a script :-/
[16:23] <slangasek> xnox, tkamppeter: right, because I just tested in a quantal chroot with dpkg --auto-deconfigure -i /path/to/cups-daemon.deb, and I don't see this error at all
[16:23] <slangasek> xnox, tkamppeter: if anything, this looks like a possible corrupted dpkg db on the affected system - I strongly counsel against elaborate maintainer script hacks if we only have one report and it's not reproducible
[16:24] <xnox> right, I shall quickly install quantal and then use raring cd to upgrade, as this is how the bug report is filed.
[16:25]  * xnox loves that utah command can just do this for me in the background (download & do a default quantal install)
[16:25] <tkamppeter> xnox, slangasek, I am still waiting for answers of the reporter what he exactly did. I did a fresh installation of Raring for i386 on a 7 year old laptop this weekend and it worked perfectly.
[16:25] <slangasek> indeed
[16:26] <melodie> is it xdg-users-dirs-gtk which creates the default directories in the accounts of new created users at first login ?
[16:33] <dobey> melodie: probably. i think that's what asks if the user wants them moved, when a different locale is selected and the user logs in
[16:34] <melodie> dobey what about this issue ? https://bugs.launchpad.net/ubuntu/+source/xdg-user-dirs-gtk/+bug/1163043
[16:34] <melodie> hi dobey btw... :)
[16:35] <melodie> I'll be back in one hour or so, need to go out now.
[16:35] <melodie> I'll be back and stay connected
[16:35] <dobey> hi. i don't know about that bug. i guess it's a bug though. seems it does that for multiple directories, not just 'Desktop'
[16:37] <melodie> dobey no, only Desktop (at least when switching from English to French)
[16:37] <melodie> dobey you could look at the screenshots I pointed to and you will see that
[16:44] <dobey> oh, i didn't realize "documents" was the french version as well. anyway, seb already marked the bug as low priority 7 hours ago, not sure why you need to ask about it in here
[16:46] <infinity> rbasak: So, if you're looking for things to tackle, the FTBFS list (prioritizing on current failures in the archive, and when those are done and/or too hard, moving on to doko's rebuild test) would be a great place to go.
[16:46] <dobey> if he thought it was filed in the wrong place, he would have moved it
[16:46] <infinity> rbasak: And feel free to just toss up debdiff on some web space or other and aim me at the lot for review/sponsorship/etc.
[16:46] <doko> infinity, the current ftbfs list is empty ;-P
[16:47] <infinity> doko: You have a weird definition of empty.
[16:47] <ogra_> doko, what did you do ? break the backend ?
[16:47] <melodie> dobey just because I wonder if this is related with the other question I asked just before:
 is it xdg-users-dirs-gtk which creates the default directories in the accounts of new created users at first login ?
[16:47] <doko> infinity, well, main
[16:47] <infinity> doko: +1 maint isn't just main.
[16:47] <rbasak> infinity: I tried going through doko's rebuild test this morning, but couldn't see any easy way of not duplicating work of people who are way ahead (doko, xnox).
[16:47] <infinity> Though, very few of those universe failures are likely to be fixable before release.
[16:48] <melodie> dobey someone will help me with a script and asked what script creates the new directories for each new user : this is why I am asking here where the knowledge is :)
[16:48] <xnox> infinity: rbasak: I did upload a compat tcltk which should resolve a fair amount of FTBFS.
[16:48] <infinity> rbasak: Helping Laney unsnag his ghc transition pain before release might be nice too.
[16:49] <rbasak> I'm happy to take some packages to fix if I know I won't get trumped
[16:49] <rbasak> (and I'll be on IRC)
[16:49] <xnox> rbasak: you could be untangling ghc transition, there is an active BigIndian bug blocking a fair chunk of stuff. cjwatson has started poking it, but maybe you'd also be able to fix it.
[16:49] <rbasak> What's the bug?
[16:49] <infinity> rbasak: Which could be in the form of fixing a bug or three, or identifying leaf nodes or small branches we can prune from broken arches to smooth things.
[16:50] <xnox> although it looks like cjwatson was doing test-build with the fix already for that =/
[16:50] <rbasak> xnox: see what I mean? :)
[16:50] <cjwatson> Yeah, I'm working on haskell-cipher-aes/powerpc
[16:50] <infinity> cjwatson: Oh, did you need leviathan back for that? :P
[16:50] <rbasak> Right now my biggest personal blocker is that I feel that I'll waste effort
[16:50] <cjwatson> infinity: Maybe, if I fail to zen it with PPAs
[16:51] <infinity> cjwatson: I'll just turn it on, and you can let me know if you didn't need it.
[16:51] <xnox> rbasak: this is a good list to work off: http://qa.ubuntuwire.com/ftbfs/
[16:51] <infinity> I need to test BenC's latest kernel anyway.
[16:51] <xnox> but it's mostly universe atm.
[16:51] <ogra_> rbasak, there is a whole universe full of armhf FTBFS and you have the fast hw ;)
[16:54] <cjwatson> rbasak: I started late last month, so I'm letting myself run late too.  I'll probably be out of your way in a few days.
[16:54] <cjwatson> rbasak: But, well, just ask
[16:55] <cjwatson> rbasak: haskell-* probably has a horrible learning curve.  You might be better off looking at other things in general ...
[16:55] <cjwatson> Unless it's something you already happen to be familiar with
[16:55] <doko> rbasak, maybe leave a message in +1-maint what you're working on
[16:57] <cjwatson> infinity: Yeah, I think I will need to work through this on leviathan; I'm not quite enough of a savant to be able to guess it, apparently :P
[16:58] <cjwatson> Though I'm pretty sure I'm in the right area.
[16:58] <Whoopie> debfx: Thanks for the virtualbox update. Works great now under raring and precise.
[16:59] <infinity> cjwatson: Alright, let me upgrade and reboot into the new kernel before you get busy with chroots you don't want me eating.
[16:59] <infinity> cjwatson: Or am I too late? :)
[17:01] <cjwatson> infinity: No, go ahead
[17:04] <ahasenack> guys, just wondering, I'm having crashes every 5min or so in X, and I'm reporting them. I'm on Quantal. Is something widespread going on, or is it just me?
[17:04] <ahasenack> no nvidia, just plain intel
[17:04] <xnox> tkamppeter: slangasek: did ubiquity based upgrade off quantal and despite scary messages it did complete fine without cups errors.
[17:05] <slangasek> xnox: does the log show cups-daemon being unpacked before cups?
[17:05] <slangasek> (if not, it's not a complete rule-out)
[17:06] <xnox> slangasek: cups-daemon is unpacked before cups.
[17:06] <slangasek> ok
[17:07] <slangasek> so, whatever was happening in that bug report, it doesn't give much evidence that dpkg is broken :)
[17:09] <infinity> cjwatson: Okay, all upgraded.
[17:10] <mitya57> ahasenack: do you have a bug number?
[17:10] <cjwatson> awesomesocks
[17:10] <ahasenack> mitya57: apport didn't give me one
[17:11] <ahasenack> mitya57: I don't know where it's uploading this stuff to, but I have probably dozens already
[17:11] <ahasenack> 5 just today
[17:22] <xvzf> hi there, what is an "upstream d-i repository"?
[17:23] <cjwatson> xvzf: d-i is the debian-installer project.  What's the context for your question?
[17:25] <xvzf> cjwatson: Hi Colin, I'm Gergely, and we exchanged e-mail about the kickseed project.  It is now clear.
[17:25] <mitya57> ahasenack: ah, it goes to errors.ubuntu.com then
[17:26]  * mitya57 doesn't have access there, so somebody else should look
[17:28] <cjwatson> xvzf: OK.  http://anonscm.debian.org/gitweb/?p=d-i/kickseed.git specifically
[17:29] <slangasek> ev: do we have cross-retracers in launchpad now, or only for errors?
[17:33] <ahasenack> mitya57: it could be https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1159536 ranked at number 6 currently
[17:34]  * xnox realises I should have been off to volleyball 30 minutes ago....
[17:35] <ahasenack> I don't understand why it's marked "fix released", the comment that changed that says "TLB invalidate bug."
[17:39] <mitya57> ahasenack: try asking on #ubuntu-x please
[17:39] <ahasenack> mitya57: ok, thanks
[17:40] <Sarvatt> ahasenack: the upstream intel developer did that, you're hitting https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1140716/ which is a regression in the last 2 quantal and precise kernel updates that just got narrowed down tho the stable update that broke it
[17:40] <ahasenack> Sarvatt: ah, good to know, thanks for the pointer
[17:41] <mitya57> can anybody please mark https://code.launchpad.net/~lqs/ubuntu/precise/uwsgi/fix-for-1131314/+merge/152324 as WIP?
[17:52] <xvzf> join #fedora
[17:53]  * xvzf misses a slash...
[17:56] <asac> anyone heard that recent linux stable kernel update in precise might have caused problems for iwlwifi users? I rebootted today and I cannot connect to my wifi anymore :/
[17:57] <asac> err .. .actually i am on quantal :)
[17:58] <asac> mac80211: fix FT roaming
[17:58] <asac> mac80211: synchronize scan off/on-channel and PS states
[17:59] <asac> thats all i found that could be relevant
[17:59] <asac> iwlegacy: fix IBSS cleanup
[18:01] <asac> ok will observe a bit more :)
[18:03] <infinity> asac: You might want #ubuntu-kernel
[18:40] <bdmurray> mterry: based off the volume of reports on errors about bug 1056545 I think it is worth fixing in Q
[18:42] <mterry> bdmurray, sure, OK
[19:04] <ev> slangasek: Looking at ~ubuntu-archive on osageorange, it looks like apport is running the right revno for that and there are logs for armhf, but pitti could say for certain
[19:04] <slangasek> ev: ok.  it was actually powerpc I was interested in in this case, maybe armhf is set up but powerpc not?
[19:05] <seb128> slangasek, we don't have ppc retracers afaik
[19:05] <slangasek> seb128: ok, but we have cross-retracer capabilities
[19:06] <seb128> slangasek, the number of users didn't make it worth the maintenance cost
[19:06] <slangasek> so why aren't we using the cross-retracing for powerpc :)
[19:06] <seb128> because nobody allocated the time/resources to set it up/maintain it? ;-)
[19:07] <seb128> though that's probably a lower cost since pitti reworked the system to not use chroots with a full system to update daily and keep working
[19:12] <ev> slangasek, seb128: for what it's worth, we don't appear to have ever received core files for powerpc on daisy.ubuntu.com. Just amd64, i386, armhf, and armel.
[19:14] <slangasek> ev: fair enough.  Bug #1162692 for an example of a bug missing retracing.
[19:17] <ev> hm, strange that we didn't get that on daisy
[19:18] <ev> whoopsie successfully builds on ppc, but I wonder if it successfully runs :)
[19:45] <slangasek> ev: so what happens if I just add a 'powerpc' stanza on osageorange?
[19:48] <slangasek> arges: bug #1157678, "SRUed to other series" - are you actually seeing this issue anywhere outside of raring?  This is definitely a new problem in raring for me
[19:48] <arges> slangasek: i should have added 'IF it affects other series' I've only seen it on raring as well.
[19:48] <slangasek> ok
[20:01] <slangasek> ev: apparently the answer is "a whole lot of nothing" because we don't have powerpc on ddebs.u.c
[20:01] <mterry> bdmurray, uploaded quantal version of sessioninstaller too
[20:03] <bdmurray> mterry: thanks, I'll approve it soon
[20:25] <saiarcot895> hi
[20:26] <saiarcot895> could someone sponsor the merges in LP Bug 1077624 (https://bugs.launchpad.net/ubuntu/+source/flightgear/+bug/1077624) for me?
[20:30] <TheLordOfTime> wasn't raring frozen?
[20:32] <saiarcot895> it is, but I thought that once beta was released, the status goes back to Feature Freeze
[20:32] <saiarcot895> do I have to wait till the beta is released?
[20:47] <TheLordOfTime> i'm not sure, but I have a question about the freeze that was announced just over two hours ago.
[20:47] <jtaylor> the freeze only affects seeded packages
[20:47] <TheLordOfTime> but it's not important :P
[20:59] <infinity> saiarcot895: You don't have to wait for the beta to be released, no.
[20:59] <infinity> TheLordOfTime: What's your question?
[21:00] <TheLordOfTime> infinity, nevermind, i found the answer myself :P
[21:01] <infinity> Fair enough.  Then I can go have lunch instead.
[21:13] <saiarcot895> ok
[22:15] <melodie> good night
[22:36] <bdmurray> xnox: bug 1159023 should really be about those three separate packages right?
[22:45] <bdmurray> okay, I sorted that out myself
[22:46] <xnox> bdmurray: yeap. Just open a task for each one. I think desktop-* something has a checker to run against them.
[22:46] <xnox> bdmurray: ok =)
[22:47] <sarnold> thanks bdmurray :)
[22:47] <xnox> I fixed gmpc recently.
[22:48] <bdmurray> xnox: yes, I discovered that in my research