[00:24] <cjwatson> Daviey: accepted mythexport.  you may have to close a bunch of bugs manually as I just noticed John used the wrong format in the changelog.  I don't want to make him go around again just for that.
[00:26] <nhandler> Didn't someone make a script that lets you pass it a list of bug numbers and it takes care of closing them?
[00:26] <Daviey> cjwatson: Doh.. not having a good day here.  Thanks for that.
[00:27] <cjwatson> nhandler: I did a one-off when the auto-closing system was broken
[00:28] <cjwatson> http://paste.ubuntu.com/506066/ - but NOT SUITABLE for running as-is, it doesn't take bug numbers on the command line but fishes them out of the publication records
[00:28] <cjwatson> it's probably not worth it for a handful of bugs
[00:37] <Daviey> done
[00:38]  * Daviey lets John know
[02:04] <ScottK> ^^^ appears to be the one that robbiew already said no to in an FFe.
[02:05] <ScottK> I don't see any new bugs, or approvals, so rejecting.
[02:42] <jdstrand> cjwatson: oh, I forgot to mention the tasks. I installed all tasks. it's a server install, not a UEC install, with all tasks selected
[02:43] <jdstrand> cjwatson: I'm going to try it now
[02:52] <ScottK> Arrrgh!!!
[02:52] <ScottK> I swear I clicked reject, but it's in.  https://launchpad.net/ubuntu/+source/ubuntu-font-family-sources/0.69+ufl-0ubuntu1
[02:53] <ScottK> Unless someone else accepted it ....
[02:53] <ScottK> Urgh.
[02:53]  * ScottK goes to bed.
[03:06] <jdstrand> cjwatson: well, it worked this time. I'll try a few more times in the morning. I think for now forget about it unless I can reproduce
[10:17] <cjwatson> casper> commented on bug
[10:18] <dpm> hi everyone, I realise it's getting late, but I prefer asking in any case:
[10:18] <dpm> While testing the final maverick language packs, I've noticed that the gnome-language-selector translations are missing (bug 654548). Would it be possible to do a new upload of language-selector including an export of LP translations and bypassing pkgbinarymangler's translation-stripping part? It would be a workaround, but this way we'd have a translated language-selector without the need of new language packs.
[10:18] <ubot4> Launchpad bug 654548 in ubuntu-translations "Language selector translation is missing from the final Maverick language packs (affects: 2) (heat: 12)" [High,Triaged] https://launchpad.net/bugs/654548
[10:19] <doko> cjwatson: re-uploaded ffmpeg yesterday. did see that packages like libmesh do fail to build with the current ffmpeg version in maverick. so there is a chance that the packages which we did remove may come back in time for maverick
[10:20] <doko> about opensync: there are already a few plugins built with the new opensync version, so not sure about the best way ...
[10:20] <doko> for audacious, I'd like to remove the plugins which fail to build unless I hear back from bdrung
[10:32] <cjwatson> doko: I was hoping to get a straight answer from siretart on whether it was OK, but he seems to still be labouring under the misapprehension that we're actually using powerpc
[10:32] <cjwatson> so I've just accepted it
[10:32] <doko> ok, thanks
[10:33] <cjwatson> dpm: language-selector is already blacklisted in pkgbinarymangler, so it ought to include its own translations and this is not a workaround
[10:33] <cjwatson> dpm: since language-selector is part of the toolchain that installs language packs ...
[10:33] <cjwatson> it already seems to include quite a few translations
[10:34] <mgunes> cjwatson: is the premature downloading of pre-published images before release a problem in the final release process the same way it is in milestones? If so, I'm inclined to post a notice on the forums until release telling people to check the release blog and/or ubuntu-announce for definitive news, since it seems to be a growing problem recently.
[10:34] <dpm> cjwatson, ah, weird, I don't have any translations in /usr/share/locale for language-selector, either, but let me re-check...
[10:34] <cjwatson> mgunes: yes
[10:34] <cjwatson> mgunes: it inhibits our ability to get things out to mirrors
[10:35] <Laney> can someone make sure the removals ~ubuntu-archive are subscribed to are done before the really final freeze?
[10:36] <mgunes> cjwatson: thanks, will proceed
[10:36] <dpm> cjwatson, it seems that the latest version of language-selector has translations in the source code, but it does not install them
[10:36] <seb128> it does, I just did a local build
[10:37] <dpm> seb128, so do you think the blacklisting perhaps is not working and they got stripped?
[10:37] <seb128> $ dpkg -c language-selector-common_0.6.5_all.deb  | grep language-selector.mo  | wc -l
[10:37] <seb128> 92
[10:37] <seb128> on a local build
[10:37] <seb128> let me check launchpad build logs
[10:39] <dpm> thanks
[10:39] <seb128> skaet, hey
[10:39] <seb128> in London?
[10:39] <skaet> hey seb,
[10:39] <skaet> yup,  just arrived in the office.  :)
[10:40] <seb128> is it your first time in the office?
[10:40] <seb128> dpm, cjwatson: http://launchpadlibrarian.net/56391059/buildlog_ubuntu-maverick-i386.language-selector_0.6.5_FULLYBUILT.txt.gz
[10:40] <skaet> seb128, yup, first time.
[10:41] <seb128> "pkgstriptranslations: language-selector-common does not contain translations, skipping
[10:41] <seb128> pkgstriptranslations: tarball already exists
[10:41] <seb128> "
[10:41] <cjwatson> looks suspiciously like it's stripping translations doesn't it
[10:42] <cjwatson> wait, language-selector was unblacklisted?
[10:42] <cjwatson> bug 570240
[10:42] <ubot4> Launchpad bug 570240 in pkgbinarymangler (Ubuntu) "Wrong language-selector package blacklisted (affects: 1) (heat: 23)" [Low,Fix released] https://launchpad.net/bugs/570240
[10:42] <cjwatson> I'm not sure I follow the reasoning for dropping it from the blacklist, TBH
[10:43] <pitti> hello
[10:43] <cjwatson> but, dpm, you were involved in that bug ...
[10:43] <seb128> pitti, hey
[10:43] <seb128> we are discussing language-selector
[10:43] <seb128> should translations be stripped or not?
[10:43] <seb128> right now they are stripped but not in langpacks
[10:43] <cjwatson> original question:
[10:43] <cjwatson> 10:18 <dpm> While testing the final maverick language packs, I've noticed that the gnome-language-selector translations are missing (bug 654548). Would it be possible to do a new upload of language-selector
[10:43] <ubot4> Launchpad bug 654548 in ubuntu-translations "Language selector translation is missing from the final Maverick language packs (affects: 2) (heat: 12)" [High,Triaged] https://launchpad.net/bugs/654548
[10:43] <cjwatson>             including an export of LP translations and bypassing pkgbinarymangler's translation-stripping part? It would be a workaround, but this way we'd have a translated language-selector without the need
[10:43] <cjwatson>             of new language packs.
[10:44] <cjwatson> I was surprised by language-selector having been dropped from the blacklist; I confess that bug 570240 doesn't make huge amounts of sense to me but maybe I need more coffee
[10:44] <ubot4> Launchpad bug 570240 in pkgbinarymangler (Ubuntu) "Wrong language-selector package blacklisted (affects: 1) (heat: 23)" [Low,Fix released] https://launchpad.net/bugs/570240
[10:44] <pitti> hm, why are they missing in the first place..
[10:44] <seb128> that would be one of the questions for you
[10:44] <seb128> I'm not sure how langpacks are built or where to check for logs
[10:44] <pitti> but yes, I wouldn't mind a reupload of language-selector with translations included
[10:44] <dpm> cjwatson, good catch, I didn't even remember that bug.
[10:44] <pitti> seb128: I can do that
[10:45] <seb128> pitti, thanks
[10:45] <pitti> I need about 15 more minutes to finish my current g-s-d patch, then I can have a look at this
[10:45] <cjwatson> changing language on the live CD I agree is a dodgy unlikely-to-work edge case; but including translations in l-s applies also to the installed system
[10:45] <seb128> ok
[10:45] <cjwatson> so I think the correct fix is to blacklist l-s, but this time do it properly
[10:45] <dpm> pitti, I've requested an export, let me check if I've already got the link and I'll paste it here
[10:46] <seb128>  Installed-Size: 2320
[10:46] <cjwatson> what's Size?
[10:46] <seb128> against
[10:46] <seb128> Installed-Size: 456
[10:46] <seb128> language-selector-common
[10:46] <cjwatson> and which binary package is that?
[10:46] <cjwatson> ok
[10:46] <seb128> once translations are shipped
[10:46] <seb128> the deb is 277k
[10:46] <cjwatson> against Size: 58036
[10:46] <cjwatson> 200K increase in compressed size doesn't seem too bad
[10:47] <seb128> right
[10:47] <seb128> so let's do an upload without stripping translations?
[10:47] <cjwatson> shall I upload pkgbinarymangler then?
[10:48] <cjwatson> or do we just want to override it in language-selector?
[10:48] <seb128> I was going to just override in language-selector
[10:49] <dpm> seb128, yeah, +1 on that. I don't quite understand what's happened here (why the latest langpacks don't contain the translations even if it's in fact not blacklisted), but we can try to figure out after release.
[10:50] <cjwatson> they are there, they're just in the KDE language packs
[10:50] <cjwatson> $ dpkg -c /home/lp_archive/ubuntu/pool/main/l/language-pack-kde-de-base/language-pack-kde-de-base_10.10+20100930_all.deb | grep language-selector
[10:50] <cjwatson> -rw-r--r-- root/root     12969 2010-10-01 18:14 ./usr/share/locale-langpack/de/LC_MESSAGES/language-selector.mo
[10:50] <seb128> urg
[10:50] <cjwatson> bad heuristics somewhere I assume
[10:51] <dpm> ah
[10:51] <cjwatson> presumably because there's a language-selector-qt but the GTK version is just language-selector
[10:52] <cjwatson> I suspect http://paste.ubuntu.com/506372/ would fix it, but if we're re-blacklisting anyway then who cares
[10:54] <pitti> done with my previous patch, /me reads backlog
[10:56] <pitti> dpm: so the rationale for unblacklisting language-selector from stripping seemed and seems reasonable to me; has this changed?
[10:57] <pitti> Copying af/language-selector into package ../maverick/sources-base/language-pack-kde-af-base
[10:57] <pitti> (from the log)
[10:57] <pitti> cjwatson: right
[10:58] <pitti> cjwatson: classificatio override committed, thanks
[10:58] <pitti> I think we should only blacklist it once for this maverick upload
[10:58] <pitti> but in general keep it stripped
[10:58] <seb128> pitti, should we just "export NO_PKG_MANGLE=1" in the l-s rules?
[10:58] <dpm> pitti, the rationale hasn't changed, as far as I'm aware, although I'm getting a bit lost with all the blacklisting
[10:58] <pitti> the next langpack update will fix that then
[10:58] <cjwatson> pitti: the rationale in the bug report for unblacklisting language-selector only considered the live CD case
[10:59] <pitti> seb128: yes
[10:59] <cjwatson> pitti: it didn't, as far as I can tell, consider the case of an installed system where the desired language just isn't installed yet
[10:59] <ScottK> FYI, I'll be off IRC for the next 13 - 15 hours, so don't wait on me for anything ....
[11:00] <pitti> cjwatson: I thought the rationale was that you'd at least see it in a language you can understand -- after all, it's your desktop language
[11:01] <cjwatson> that's not the rationale given in bug 570240
[11:01] <ubot4> Launchpad bug 570240 in pkgbinarymangler (Ubuntu) "Wrong language-selector package blacklisted (affects: 1) (heat: 23)" [Low,Fix released] https://launchpad.net/bugs/570240
[11:01] <cjwatson> and there are several situations where the desktop language might be English for one reason or another - not on CD and no network access during installation, for instance
[11:02] <cjwatson> in which case the OS installer would have been localised, but now you're dropped into a desktop you don't understand, so I think some guidance in language-selector would not be inappropriate
[11:02] <cjwatson> I thought it was a simple rule - anything needed to install language packs should be blacklisted.  no?
[11:03] <pitti> I don't think we ever spelt it out clearly, but it makes sense for the corner case above
[11:05] <seb128> cjwatson, could you review the g-s-d upload pitti just did once it hit the queue?
[11:05] <seb128> it's the fix for bug #640807
[11:05] <ubot4> Launchpad bug 640807 in gnome-settings-daemon (Ubuntu Maverick) (and 2 other projects) "automatic xrandr module misconfigures monitors (affects: 13) (dups: 3) (heat: 54)" [High,Fix committed] https://launchpad.net/bugs/640807
[11:05] <pitti> will still take some 15 minutes until the debdiff appears, though
[11:06] <seb128> it's basically going back to the behaviour we had before GNOME 2.32
[11:06] <pitti> the change was introduced very late (after FF), in 31.91
[11:11] <cjwatson> seb128,pitti: looks reasonable to me.  the only concern I have is future migration.  will we make sure to migrate gconf configuration for this locally-introduced key, even if upstream uses a different name in future?
[11:12] <seb128> cjwatson, we will switch to gsettings next cycle
[11:12] <pitti> cjwatson: that's indeed a concern; however, fortunately they will migrate to gsettings soon anyway
[11:12] <seb128> so upstream will not go for a gconf key
[11:12] <pitti> cjwatson: so if they change the name, we'd only need to change the key name in the migration code
[11:12] <seb128> and gconf -> to gsettings is dropping one line in a file
[11:12] <dpm> cjwatson, pitti, seb128: thanks a lot for looking into the l-s translations issue
[11:12] <seb128> so migration will be easy
[11:12] <pitti> right
[11:13] <cjwatson> hm, ok
[11:14] <seb128> brb
[11:18] <pitti> dpm: so, want me to wait on your export, so that I can update the translations in the package?
[11:20] <dpm> pitti, whatever suits you best. I've just got the export link: http://launchpadlibrarian.net/57123174/launchpad-export.tar.gz If you could include those translations, that would be great. If those are too big a change at this point, just including the existing translations in the package would be a big improvement already
[11:21] <pitti> dpm: I don't see why we shouldn't include them; the current po files in the package weren't tested any more (i. e. not at all) than the ones in the langpacsk
[11:21] <pitti> i. e. the launchpad ones were at least tested in KDE
[11:21] <pitti> or from folks with the KDE langpacks installed
[11:22] <dpm> pitti, +1. They were also tested by ubuntu folks, as the transition to the kde langpack seemed to happen recently (I just noticed it when I reported the bug, before it was translated in Ubuntu)
[11:23] <dpm> or at least that was my impression
[11:25] <pitti> ok, works fine in German; I installed pkgbinarymangler, and -common has the po files now; both the menu entry and the app itself are in German now
[11:25] <dpm> cool
[11:30] <pitti> uploaded
[11:58] <doko> cjwatson: we really need a list of sources which are not yet build in a distribution ...
[11:59] <doko> built even
[12:01] <doko> just found eigenbase-resgen and mondrian
[12:02] <wgrant> doko: You mean things that haven't been rebuilt in maverick, or something else?
[12:03] <ttx> ScottK: looking...
[12:03] <cjwatson> doko: http://people.canonical.com/~ubuntu-archive/testing/maverick_outdate_all.txt
[12:03] <cjwatson> oh, that's only out of date, not never built at all
[12:03] <cjwatson> feel free to extend lp:ubuntu-archive-reporting :-)
[12:04] <doko> heh
[12:04] <cjwatson> actually it's lp:~maxb/+junk/ubuntu-archive-reporting isn't it ...
[12:04] <maxb> heh
[12:04] <maxb> shall we move that?
[12:04] <cjwatson> as you like ...
[12:04] <cjwatson> we have a minor branch deployed anyway
[12:04] <cjwatson> (path, arch, suite changes)
[12:05] <doko> maxb: do you volunteer to extend it?
[12:05] <maxb> uh, possibly :-)  I might need to remind myself how feasible what you suggest is in the current code first
[12:06] <ttx> ScottK: looks reasonable to me.
[12:13] <ttx> ScottK: though we could (should) filter out the non-security changes, they seem quite harmless.
[12:13] <Riddell> ttx: ScottK is away today
[12:16] <ttx> Riddell: ok -- I was just answering a question he had about bug 636482
[12:16] <ubot4> Launchpad bug 636482 in python-django (Debian) (and 1 other project) "Update python-django to 1.2.3 version to fix an XSS vulnerability (affects: 2) (dups: 1) (heat: 26)" [Unknown,Unknown] https://launchpad.net/bugs/636482
[12:57] <bdrung> doko: sorry, i don't have time to work on these. a quick look showed that we are using old versions or the upstream changes don't improve the build failure
[12:57] <cjwatson> could somebody please review lupin?
[12:57] <doko> looking
[13:08] <cjwatson> doko: thanks
[13:14] <doko> bdrung: ok, then I'll remove audacious-dumb and audacious-dumb and disable the plugins for imms, upse and xmp
[13:14] <doko> cjwatson: ^^^ ?
[13:15] <cjwatson> seems like the best option at this point to get rid of the last NBS other than opensync
[13:15] <doko> what do you think about opensync?
[13:16] <cjwatson> I commented on that yesterday
[13:16] <cjwatson> 16:55 <cjwatson> I'm worried about the results but don't see what else we can do really
[13:16] <cjwatson> 16:55 <cjwatson> I do think we should restore it in an SRU if at all possible
[13:16] <cjwatson> 16:57 <cjwatson> the bug needs some better discussion of the problem and why this is the only option - people are going to find it while wondering what happened to opensync
[13:16] <cjwatson> for the audacious stuff - please only remove binaries
[13:16] <cjwatson> no need to remove sources if there are no build-deps involved in NBS
[13:16] <doko> yes
[13:17] <doko> updated the opensync bug report today:
[13:17] <doko> the alternative would be to downgrade to opensync to (< 0.30), and then rebuild/downgrade the following packages too:
[13:17] <doko> osynctool
[13:17] <doko> libopensync-plugin-syncml
[13:17] <doko> libopensync-plugin-file
[13:17] <doko> libopensync-plugin-evolution2
[13:17] <doko> libopensync-plugin-xmlformat
[13:17] <doko> libopensync-plugin-vformat
[13:18] <Riddell> does anything use opensync?  it's dead upstream as far as I know
[13:18] <cjwatson> I guess if that can be done without involving an epoch (and hence breaking merges forever), it would be preferable
[13:18] <cjwatson> Riddell: "dead upstream" doesn't seem compatible with "new upstream versions uploaded quite recently to Debian experimental"?
[13:19] <doko> azeem will join us here in 15min ...
[13:34] <doko> please review upse and xmp
[13:36] <mvo> about this apt upload, it does fix the test case in the changelog (postfix failing to instal if exim is already installed). I did exsessive tests on it and created lp:~mvo/+junk/apt-resolver-regression-tests  to ensure it does nothing bad (plus inspected the code of course), so it should be fine. if you prefer it as a SRU that is fine for me as well
[13:38] <lamont> mvo: what was the issue?  (as in should postfix do something differently?)
[13:39] <ttx> Riddell, cjwatson: do we have a tentative schedule for the final ISO generation yet ?
[13:39] <ttx> (I mean, the first candidates for final)
[13:39] <mvo> lamont: postfix is fine, apt is having a issue in maverick
[13:40] <mvo> lamont: its just a convinient test-case
[13:40] <lamont> ah, ok
[13:41]  * lamont unstresses
[13:42] <mvo> lamont: no worries (and yeah, release week is fun, isn't it?)
[13:44] <lamont> heh
[13:44] <lamont> you keep using that word....
[13:53] <cjwatson> ttx: not before tomorrow
[13:53] <ttx> cjwatson: ok, thanks !
[13:54] <doko> hi azeem_
[13:54] <doko> what do you suggest for the opensync mess?
[13:59] <azeem_> gah, network is really slow here
[14:05] <azeem_> doko: ok, so the file and evolution plugins are the ones which should get reverted I guess, and the syncml one dropped
[14:06] <doko> azeem_: and opensync reverted too? which version number should be used?
[14:07] <doko> epoch, or fake version
[14:08] <cjwatson> please not an epoch
[14:08] <cjwatson> unless Debian uses one too I suppose
[14:09] <azeem_> my preference would be uploading 0.22-4squeeze1 to t-p-u after coordination with the Debian release team, and then merge a fake version to maverick from there
[14:09] <azeem_> if that is possible
[14:10] <cjwatson> we're not likely to have time to wait for t-p-u
[14:10] <cjwatson> the absolute hard deadline for unseeded packages in universe/multiverse is tomorrow noon UTC
[14:10] <cjwatson> actually no
[14:11] <cjwatson> sorry, noon UTC on Oct 9
[14:11] <cjwatson> so I suppose we can wait a day or two for t-p-u review
[14:13] <azeem_> packages against testing are at http://people.debian.org/~mbanck/opensync-squeeze
[14:13] <azeem_> I didn't have much time last night to test them as well though, will do now after checking what else is missing
[14:35] <doko> wgrant: no, packages which are not built at all (and are not built because the build dependencies are missing). these show not up on ubuntuwire.com/ftbfs
[14:39] <micahg> could a member of the release team please look at bug 650601?
[14:39] <ubot4> Launchpad bug 650601 in libfxscintilla (Ubuntu) "[FFe] Please update libfxscintilla to 2.11.0 (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/650601
[14:57] <cjwatson> doko: seems to be a lot of cruft in the debdiff of upse from what's in the archive - is it necessary?
[14:58] <doko> looking ...
[15:00] <azeem_> cjwatson, doko: ok, I asked for tester feedback on opensync-users and debian-user
[15:01] <doko> cjwatson: re-uploaded with the same version number
[15:01] <doko> azeem_: thanks
[15:04] <jdstrand> cjwatson: I'm not keen on cosmic rays. I've tested 4 more installs without incident
[15:05] <jdstrand> so I'm forgetting about it now too
[15:11] <doko> rejected my first upse upload
[15:13] <cjwatson> jdstrand: duly forgotten
[15:32] <Daviey> jdstrand: I tried to reproduce it last night in KVM... and couldn't
[16:01] <Daviey> Hi... been looking at Bug #600174 ... The axis2c code seems really buggy (valgrind), and now the FTBFS seems to have happened because of tool chain changes.  Disabling the test suite produces binary packages... Looking for advice from the RT with what to do.
[16:01] <ubot4> Launchpad bug 600174 in axis2c (Ubuntu Maverick) (and 1 other project) "axis2c fails to build from source on maverick/i386 (affects: 3) (dups: 1) (heat: 22)" [High,Confirmed] https://launchpad.net/bugs/600174
[16:02] <Daviey> there is an i386 package currently in maverick.... which is good...
[16:02] <Daviey> .. but if a security update is needed... it's going to need work
[16:02] <Daviey> (or disabling the test suite)
[16:03] <Daviey> Should we just leave it in FTBFS for now?
[16:07] <doko> Daviey: does it build with gcc-4.5? it's in main too, so could be an alternative. didn't check myself
[16:10] <Daviey> doko: Ah.. good point
[16:10] <doko> Daviey: also trying with -O0/-O1
[16:11] <Daviey> doko: I will try that... but i really wanted to establish if it's worth my time working on it at the moment... rebuilding so close to release scares the crap out of me :)
[16:11] <doko> Daviey: well, target it for maverick-updates and work later on it?
[16:12] <Daviey> doko: Yeah... that takes the pressure off slightly :)
[16:14] <cjwatson> hm, dmraid installations not so happy, grub installed to wrong place
[16:14] <cjwatson> and there's only been a bug open about this for six months or so ...
[16:15] <cjwatson> buggeration.
[16:19] <\sh> ScottK: ping
[16:22] <\sh> ScottK: for universe and bugfix releases (native package which results in a new version) do we need to file a FFe or just follow "Feature Freeze for bugfix only updates" ?
[16:22] <doko> ScottK is offline for a some hours
[16:22] <doko> cjwatson: please could you review the reuploaded upse?
[16:23] <Laney> \sh: no special freeze ATM AFAIK
[16:23] <doko> heh, he didn't like it
[16:26] <\sh> Laney: k..thx
[17:00] <azeem_> doko: I guess the google-calendar plugin needs to be dropped as well, as per LP#244877
[17:01] <doko> azeem_: could you document this in bug #654613 ?
[17:01] <ubot4> Launchpad bug 654613 in multisync0.90 (Ubuntu) (and 10 other projects) "remove packages needing opensync (<< 0.30) in maverick (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/654613
[17:07] <mvo> the aptdaemon upload I just did is not a OMG-this-needs-to-be-in-NOW upload, we can also do it as a SRU on the first day. it collected a bunch of dupes, this is why I uploaded it
[17:07] <mvo> (now)
[17:08] <azeem_> doko: gah, it's still<EMAIL_ADDRESS>[17:08] <azeem_> I've no idea (i) how I came up with that patch (ii) why I thought that patch/upload fixed it
[17:08] <azeem_> but applying it to /usr/share/pyshared/Ft/Xml/XPath/ParsedAxisSpecifier.py fixes it
[18:09] <cjwatson> doko: your binutils-avr upload also removed bug-lpm.c and bug-lpm.o.  was that intentional?
[18:10] <doko> yes
[18:10] <cjwatson> ok
[18:11] <doko> maybe I should have left it there to keep the diff minimal
[18:11] <cjwatson> *shrug* accepted anyway
[18:16] <doko> cjwatson: enblend-enfuse is the last one for today. and I assume that there's enough buildd power to build gcc-snapshot
[18:18] <cjwatson> I'm not entirely sure about that assumption
[18:18] <cjwatson> is it vital we have a new snapshot?
[18:18] <doko> no
[18:18] <doko> fixes the build failure on powerpc
[18:19] <cjwatson> oh, hm, didn't realise it was failing
[18:20] <cjwatson> it takes over two days on armel
[18:20] <cjwatson> I guess it has to be now or not at all ...
[18:21] <cjwatson> could somebody review initramfs-tools?
[18:24] <doko> done
[18:25] <cjwatson> thanks!
[18:25] <cjwatson> oh, urghurgh, queuebot fell over
[18:30] <cjwatson> no longer running on my home machine, so should have a better chance of staying up
[18:30] <doko> interesting, removed the auacious-dev b-d, now ftbfs with missing zlib header ...
[18:31] <cjwatson> hm, spewing lots of stderr, but I guess I can ignore that for now
[18:33] <doko> the enblend-enfuse upload fixes the ftbfs on armel, didn't mention it in the changelog
[18:46] <doko> I don't why we need armel->avr and armel->z80 cross toolchains ...
[20:47] <micahg> I still have 2 FFe bugs that need to be looked at for universe (bug 631221 and bug 650601)
[20:47] <ubot4> Launchpad bug 631221 in calendarserver (Ubuntu Maverick) (and 1 other project) "FFe: Sync calendarserver 2.4.dfsg-2 (universe) from Debian unstable (main) (affects: 10) (dups: 2) (heat: 181)" [Wishlist,Fix released] https://launchpad.net/bugs/631221
[20:47] <ubot4> Launchpad bug 650601 in libfxscintilla (Ubuntu) "[FFe] Please update libfxscintilla to 2.11.0 (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/650601
[20:47] <micahg> oops
[20:47] <micahg> sorry, that first one is wrong, should be bug 651514
[20:47] <ubot4> Launchpad bug 651514 in tortoisehg (Ubuntu) "FFe: Sync tortoisehg 1.1.1-1 (universe) from Debian unstable (main) (affects: 5) (dups: 2) (heat: 34)" [Medium,New] https://launchpad.net/bugs/651514
[21:09] <ogra> someone of the release team please let the x-loader-omap4 package through, it add the missing support for the final omap4 hardware revision, it was tested heavily by ubuntu and TI engineers on that HW
[21:16] <ogra> skaet, i need an official ok for that package i guess
[21:16] <ogra> (the one above my last line)
[21:40] <cjwatson> ogra: done
[21:44] <ogra> cjwatson, thanks a lot
[21:47] <cjwatson> micahg: tortoisehg granted (and sync-helper running), will read through libfxscintilla later
[21:49] <micahg> cjwatson: awesome thanks
[23:08] <cjwatson> micahg: libfxscintilla approved
[23:08] <cjwatson> I'd appreciate somebody looking over grub-installer and debian-installer, if anyone has a moment
[23:09] <micahg> cjwatson: k, I'll finish the update tonight and find someone to upload, thanks
[23:11] <cjwatson> Riddell: I don't hugely care since it's just a debug message, but this chunk http://paste.ubuntu.com/506842/ in the pulseaudio diff looks wrong - the else will bind to the inner if, not the outer one
[23:11] <cjwatson> Riddell: at the very least it's wrongly indented.  might want to let Colin Guthrie know
[23:12] <cjwatson> Riddell: is there a bug associated with this pulseaudio upload, or a mailing list reason or something?
[23:12] <Riddell> mm, that's why I always use curly brackets with if statements
[23:13] <Riddell> cjwatson: http://permalink.gmane.org/gmane.comp.audio.pulseaudio.scm/2725 is the main reference I was given
[23:13] <Riddell> I was hoping crimsun would give me his opinion but he's been silent
[23:13] <Riddell> I can file a bug and get Colin Guthrie to explain his reasoning if you want
[23:14] <cjwatson> well, they all look reasonable enough from the patch descriptions, I'm just wondering about the tradeoff for putting it into maverick at this late point vs. an SRU
[23:14] <cjwatson> I don't know enough about pulseaudio to evaluate how serious any of those things are
[23:14] <cjwatson> happy to accept if they are serious
[23:15] <Riddell> I don't think it matters much either way
[23:20] <cjwatson> Riddell: well, if you can manage to track down crimsun by tomorrow morning, or otherwise find an explanation of seriousness, I'm happy to let it in
[23:20] <cjwatson> pulseaudio just makes me nervous :)
[23:25] <cjwatson> done with reviewing for tonight, early start tomorrow to get to London


[09:26] <progre55> hi guys. when running an instance, I get these exceptions (http://pastie.org/1160744) on the node logs, and the instance instantly terminates. Any suggestions please?
[10:44] <progre55> anybody? after I restarted my nc, it's not discovered by the cc anymore.. in the cc logs I get this "could not be invoked (check NC host, port, and credentials)"
[10:44] <progre55> and also this "netInitTunnels(): in MANAGED-NOVLAN mode, priv interface 'eth0' must be a bridge, tunneling disabled"
[10:44] <progre55> any suggestions, please?
[13:22] <duxbuz> hello.... waht is ubuntu cloud
[13:44] <smoser> progre55, do your node controllers have hvm support ?
[13:44] <smoser> you can check by 'kvm-ok' on them
[13:57] <progre55> smoser: hey man =) thanks for the reply, I've been able to fix it already..
[13:57] <progre55> but honestly, no idea how
[13:57] <progre55> it got fixed on its own somehow =)
[13:57] <smoser> hm.m.
[13:58] <progre55> I was restarting it several times, deattaching and re-attaching the node, etc
[13:58] <progre55> but now I have another problem =)
[13:58] <progre55> I'm running an instance, and it's getting a public IP <IP_ADDRESS>
[13:59] <progre55> but actually, my local IP range in the office is 172.16.xx.xx
[13:59] <progre55> so I dont have access to the instance from anywhere, and the instance doesnt have connection to the internet =)
[14:00] <progre55> I can only ssh into it from the eucalyptus server machine
[14:01] <progre55> I'm guessing it's because I had VNET_PUBLICIPS="<IP_ADDRESS>-<IP_ADDRESS>" in the conf
[14:02] <progre55> but now I've changed it to 172.16.xx.xx-... and even restarted the cc machine after it, but the instances are still assigned <IP_ADDRESS>
[14:02] <progre55> smoser: any suggestions, please?
[14:03] <smoser> hmm..
[14:03] <smoser> well, the instances get their address via dhcp
[14:03] <smoser> so if you have a dhcp server on that network, it can be a race
[14:04] <smoser> and you instance might not even have the ip address that euca says it has.
[14:04] <progre55> oh.. and how do I check the actual IP address?
[14:04] <smoser> i'm not sure
[14:05] <progre55> and the dhcp on the network would not assign 192.168, cause the invalid IP range in the network starts with 172.16
[14:51] <progre55> how do you download an EMI from a command line?
[14:51] <progre55> cause I had downloaded it from the web-UI, and now it says it's "Installed", but I had "disabled" it from the Images tab
[14:52] <progre55> and it's not there anymore
[16:06] <progre55> my instances are running and everything is okay, but they do not have internet connection, and cannot be reached from outside the cc machine..
[16:49] <TeTeT> progre55: you can grab an EMI from http://uec-images.ubuntu.com/ and then use uec-publish-tarball to upload it
[16:51] <progre55> TeTeT: yep, I've done that already =) thanks
[21:18] <veenenen> random bug
[21:18] <veenenen> http://paste.ubuntu.com/494924/
[21:18] <veenenen> when I launch an auto scaling group on ec2, the second one I launch goes down after 10 minutes
[21:19] <veenenen> and it's complete unreponsive
[21:19] <veenenen> the only indication the server gives is generating 2 ssh server keys
[21:31] <veenenen> oh yeah, and this is uec 32bit maverick running on ec2
[21:33] <smoser> veenenen, https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/567334
[21:33] <smoser> if you reboot it might come back up
[21:35] <smoser> s/might/likely will/
[21:37] <veenenen> the instance is actually available at first
[21:38] <veenenen> but after 30 minutes the load drops to 0 suddenly
[21:39] <veenenen> i know I said 10 minutes before, but I just got around to checking the graph and it was actually 30 minutes. Well, 31 minutes to be exact.
[21:39] <smoser> well, its the same bug. those messages are not good.
[21:39] <veenenen> ok
[21:40] <smoser> i'd say it started after about 32 minutes of being up
[21:40] <smoser> to be more precise
[21:40] <smoser> 1920.220071 seconds
[21:41] <veenenen> haha, sorry.
[21:42] <veenenen> i just got back from a meeting to this
[21:52] <smoser> veenenen, what image were you booting ?
[21:52] <veenenen> the same one from yesterday
[21:52] <smoser> i'm being asked if you have console=hvc0. on /proc/cmdline.
[21:52] <smoser> so you probably dont
[21:53] <veenenen> how would I check that?
[21:53] <smoser> cat /proc/cmdline
[21:53] <smoser> but you wont have it
[21:53] <veenenen> ok, yeah
[21:54] <smoser> (you should add that if you want to maintain this image, add it in /boot/grub/menu.lst
[21:57] <veenenen> just add that anywhere?
[22:03] <smoser> ## additional options to use with the default boot option, but not with the
[22:03] <smoser> ## alternatives
[22:03] <smoser> ## e.g. defoptions=vga=791 resume=/dev/hda5
[22:03] <smoser> # defoptions=console=hvc0
[22:03] <smoser> yours probably has empty 'defoptions'
[22:03] <smoser> add that, then run 'sudo update-grub-legacy-ec2'
[22:08] <smoser> veenenen, ^
[22:11] <veenenen> is cloud-init uncommenting that line?
[22:12] <veenenen> Sorry if this is rudimentary. I haven't worked much with grub directly.


[14:37] <akgraner_> hey y'all...
[14:39] <akgraner_> I should be back online this afternoon...
[14:39] <akgraner_> talk chat more laters  - gotta go get this knee looked...
[22:10] <MrChrisDruif> I don't know if any admins are around on this channel, but UBT Wiki FG meeting just started. Anyone who wants to join #ubuntu-meeting is welcome


[05:33] <stub> Is the update-manager indicator on wily supposed to be informing people abount Xenial now?
[06:25] <pitti> Good morning
[06:26] <pitti> hallyn: indeed, that seems fairly new; can you please file one (debian or LP, doesn't matter) with how you got there, so that we can write a test case?
[06:37] <infinity> stub: Yes.
[06:38] <infinity> stub: wily upgrades were enabled pretty much right after release, it's only LTS->LTS upgrades where we delay until the point release.
[06:38] <stub> ok, that was my confusion. I thought all recommended upgrades were delated until point release.
[06:39] <stub> I like that word.   Slacker.
[07:00] <infinity> (unless this was your mom's machine)
[07:03] <ginggs> morning! would someone help me understand why bliss is not migrating please? if i am reading update_output correctly, then polymake is involved somehow.
[07:05] <infinity> ginggs: That output is telling you that upgrading bliss will make polymake uninstallable.
[07:07] <infinity> ginggs: Because polymake needs a rebuild for the libbliss1d->libbliss2 soname bump.
[07:08] <ginggs> infinity: aha thanks!
[07:08] <infinity> ginggs: Do you have upload rights for the rebuild, or shall I lob it at the archive for you?
[07:09] <ginggs> infinity: no need to worry, i can do it
[07:09] <infinity> ginggs: Enjoy.
[07:09] <infinity> (dch -R)
[07:09] <ginggs> infinity: for future reference, how did you get from 'will make polymake uninstallable' to 'needs a rebuild'?
[07:10] <infinity> ginggs: I checked if any package names changed.  Saw the sover bump.  Checked rdepends of libbliss1d, which happens to just be libbliss* and polymake, extrapolated.
[07:11] <ginggs> infinity: ok, manually then
[07:11] <infinity> ginggs: One could also try installing in a chroot while explicitly excluding all the old packages (apt-get install polymake libbliss1d- libbliss1d-dbg-) and watch it whine, if it's to complex to understand at first glance.
[07:12] <infinity> The second one is a better option if you see no immediate connection between your upload and the breakage britney is telling you about.
[07:13] <infinity> Cause be an interim dep needs fixing, or a dependency is versioned in a way that breaks things, etc.
[09:25] <jamespage> mwhudson, hey still awake? do you know if we're planning to adopt the shared linking stuff in go in any way just yet?
[09:26] <jamespage> mwhudson, openstack has its first go based work it wants to include and they are struggling with approach so wanted to chime in with what we've done in Ubuntu for LXD and Juju...
[10:14] <Skuggen> slangasek: Did you have time to review some sedition for making MySQL upgrades more robust?
[10:15] <Skuggen> slangasek: https://github.com/ltangvald/mysql-5.7/commit/f57b068c956d0792bb35cec72fee8d66b0f513c7
[14:11] <xnox> marga, W: http://dl.google.com/linux/chrome/deb/dists/stable/Release.gpg: Signature by key 4CCA1EAF950CEE4AB83976DCA040830F7FAC5991 uses weak digest algorithm (SHA1) ....
[14:12] <xnox> =)
[14:14] <juliank> xnox: that's in progress already AFAICT (the file already has a 4096R signature as well last time I checked)
[14:15] <juliank> pub   rsa4096/0x7721F63BD38B4796 2016-04-12 [SC]
[14:15] <juliank> It's now just a matter of the packages shipping a new key
[14:15] <xnox> juliank, right. but the bug is not in the key, but in the parameters passed to gpg as to which digest algo to use =)
[14:15] <juliank> xnox: No, no.
[14:16] <xnox> hm?!
[14:16]  * xnox thought it's about gpg --digest-algo SHA256
[14:16] <juliank> You get the warning from a DSA1 key
[14:16] <juliank> s/key/signature/
[14:16] <juliank> that uses SHA1
[14:16] <xnox> *sigh*
[14:17] <juliank> xnox: On the other hand, the RSA signature seems to use SHA1 as well
[14:17] <juliank> (But that's not the cause of the error yet)
[14:19] <juliank> So while you are practically right in the end, this surprisingly does not follow from the error
[14:19] <juliank> :)
[14:19]  * juliank had to run gpgv manually to check
[14:20] <juliank> xnox: If you want to track state, https://bugs.chromium.org/p/chromium/issues/detail?id=596074
[14:21] <juliank> There's also the fancy https://bugs.chromium.org/p/chromium/issues/detail?id=440870 where we ask to install into trusted.gpg.d instead of using apt-key...
[14:23] <seb128> juliank, hey, looking at bug #1562733 ... is APT::Update::Post-Invoke supposed to work in case of "E:" like "E: Some index files failed to download. They have been ignored, or old ones used instead."?
[14:23] <juliank> seb128: I forgot to update this. It currently doesn't.
[14:23] <juliank> We'd have to swap some lines around
[14:23] <seb128> k, so not a solution to the appstream issue :-/
[14:24] <juliank> seb128: I think it should start working soon, we talked about this yesterday in #debian-apt
[14:24] <seb128> juliank, is that swap something you consider doing/a fix or would it be a behaviour change you don't want for some reason?
[14:26] <juliank> seb128: DonKult had some concerns because it was always like this; but I don't think the current state makes sense. What we want to do is make -Success run if not all sources failed. But it's slightly unclear yet how much work that is.
[14:27] <seb128> juliank, would that be SRU material for 16.04?
[14:27] <juliank> seb128: I'd hope so. 1.2.11 in yakkety is also SRU material, BTW.
[14:28] <seb128> I guess it just requires somebody taking on doing the SRU then
[14:28] <seb128> juliank, thanks!
[14:30] <juliank> seb128: I can continue 1.2 releases for some time upstream (until 1.3 hits unstable), and they could be SRUed, as that's a sort-of-stable-series-intended-for-xenial
[14:31] <seb128> juliank, that sounds good ... then I guess it would be up to mvo or infinity to handle xenial SRUs? or do you plan to handle those as well?
[14:32] <juliank> Well, I don't have any upload permissions...
[14:33] <juliank> Which means it does not really matter that much, it's just a question of who writes the SRU bug
[14:33] <juliank> because if I do, someone has to sponsor-ACK it
[14:34] <seb128> right
[15:05] <pitti> slangasek, cyphermox: FYI, I did some research about packages integrating with resolvconf, and I think it's simpler better to do the DNS resolution part first/separately; I adjusted https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-local-resolver accordingly
[15:05] <pitti> i. e. this will continue to use resolvconf for the time being, and just replace dnsmasq on the desktop and introduce it on the server
[15:06] <pitti> if we want to move from resolvconf to resolved for managing resolv.conf, that's doable, but rather independent, and should then become a separate BP; but this is much more work, and there is not much visible benefit
[15:14] <rbasak> flexiondotorg: just to be clear, those packages are things you consider part of MATE, and should be included in part of any MATE packageset, right? As opposed to any special only-you upload thing.
[15:14] <pitti> slangasek: I set it to "review" and proposed for yakkety (I can't accept any more); this is now all actually tested, too :)
[15:16] <caribou> xnox: With LP: #1564475 you raised crashkernel to 196M, then LP: #1570775 talks to add cio_ignore output to the kexec kernel
[15:16] <caribou> xnox: what is the final decision on this one ? use cio_ignore + 128M or cio_ignore with 196M ?
[15:16] <flexiondotorg> rbasak, Yes, those packages are part of the MATE package set.
[15:17] <caribou> xnox: I'm preparing a version of kdump-tools that will set the value different if it sees an LPAR but I need to know if this is still relevant
[15:17] <rbasak> flexiondotorg: OK. Just checking I didn't understand something. Thank you :)
[15:17] <flexiondotorg> rbasak, No probs. Thanks.
[15:18] <rbasak> Uh, misunderstand something I meant :)
[15:35] <nacc> anyone else having wiki.ubuntu.com problems? https://wiki.ubuntu.com/NishanthAravamudan/YourDeveloperApplication says (while logged in) that "Immutable Page" for myself...
[15:37] <pitti> nacc: log out and back in, SSO sometimes gets confused
[15:38] <nacc> pitti: tried that 2x now, will try again
[15:38] <nacc> pitti: ack that
[15:38] <pitti> it's not immuatable for me, but the page is rendered tiiiiiiny!
[15:38] <nacc> pitti: that's probably what is going on, if i had to guess, though
[15:38] <nacc> pitti: weird :)
[15:39] <pitti> nacc: I tried logging out and back in, and it's now hanging after SSO auth
[15:40] <pitti> so, definitively something up here
[15:40] <nacc> pitti: yeah, login takes a long time for me, but i wonder if it's the spam prevention stuff
[15:42] <pitti> nacc: finished, can edit again, hmm
[15:43] <nacc> pitti: still immutable for me :/
[15:45] <nacc> pitti: heh, restarted chrome and now i get a 500 from the login :)
[15:46] <nacc> pitti: second attempt, got logged in again, but immutable still
[16:52] <seb128> bdmurray, hey, do you think you could look at https://bugs.launchpad.net/ubuntu/+source/apturl/+bug/1566201 ? it's the most reported e.u.c issue on the weekly summary
[16:53] <seb128> bdmurray, and any idea why https://errors.ubuntu.com/problem/25cc76910cc3cfeaf1369ca3f208f5c3710046d3 fails to get a stacktrace?
[16:53] <seb128> or https://errors.ubuntu.com/problem/d4cb05c46d65d26239b285df4c0162e393f4972a
[16:53] <Michal_amateur> Hello, can somebody help me? I have game, I have backgroud image size 150x150 and I want multiple this picture to size for example 2000x2000.
[16:55] <lathiat> Hi Michal_amateur, the channel for support is #ubuntu you should try there
[16:56] <Michal_amateur> I see thanks, I will try
[16:57] <bdmurray> seb128: both of those nm-applet crashes which failed to retrace have some "?? ()" in StacktraceTop in the first 4 parts.  I'll try and force a retrace of them though.
[17:00] <seb128> bdmurray, do they have symbols after the ??
[17:00] <seb128> or just those?
[17:02] <bdmurray> seb128: http://pastebin.ubuntu.com/16321012/
[19:58] <Umeaboy> Hi!
[19:58] <Umeaboy> Any plans of getting an update for the package repo?
[20:00] <sarnold> Umeaboy: can you rephrase your question?
[20:05] <Umeaboy> May I please get an update of the repo package into 15.10?
[20:14] <nacc> Umeaboy: existing release's versions need to follow the SRU policy at https://wiki.ubuntu.com/StableReleaseUpdates; usually new releses don't qualify in and of themselves
[20:45] <Umeaboy> nacc: Right, but can't the upgrade notice at least be hidden by default?
[20:45] <nacc> Umeaboy: what "upgrade notice"?
[20:46] <Umeaboy> When you run repo init you see a message that there is a newer repo and that an update is suggested to install.
[20:50] <nacc> Umeaboy: that's presumably something in the repo source itself? it's unmodified from Debian, so my guess is this is just how the packaged `repo` behaves
[20:51] <nacc> Umeaboy: if you want, file a bug, I guess
[20:51] <Umeaboy> OK.
[20:51] <Umeaboy> I'll do that.
[20:51] <Umeaboy> Thanks.
[20:51] <Umeaboy> Have to go......take care!
[21:03] <mwhudson> jamespage: yeah, should start using go shared libs in y
[21:24] <hallyn> pitti: for that deb-systemd-helper error, I filed bug 1579922
[21:24] <hallyn> (may well be my fault, but if so then  Ineed gentle prodding and corretion :)
[21:24] <hallyn> thx
[22:23] <TJ-> is there any unmentioned dependency of dput that would cause it to stall whilst uploading to a PPA? According to iftop only about 871 bytes are sent - dput is showing "lubuntu-artwork_0.62.dsc: " and nothing else happens and the TCP connection eventually is dropped but dput continues sitting there until Ctrl+C
[22:43] <sladen> TJ-: can you try 'strace'ing it?
[22:43] <sladen> TJ-: you're probably found a parsing bug
[22:45] <TJ-> sladen: I'm using python -m trace ... and it appears to be getting stuck at the sftp client
[22:47] <sladen> TJ-: wireshark might be the next top
[22:48] <sladen> TJ-: or ssh -v  and see how much setup is managed
[23:17] <TJ-> solved it - somehow the id_rsa* from 15.10 had been replaced by a fresh generated key on the 16.04 PC; all the other keys (i have 1 key per service/server used) were the same. After doing that there was a "sign_and_send_pubkey: signing failed: agent refused operation" error, which required "ssh-add" to let the agent know about the keys
[23:18] <sarnold> it might still be worth a bug report, good error messages are always nice :)
[23:18] <TJ-> spoke too soon. It uploaded the .dsc then failed next with "lubuntu-artwork_0.62.tar.xz: Connection to ppa.launchpad.net closed by remote host."
[23:20] <TJ-> this time it's continuing, showing a steady 1Mb/sec for the tar.xz file
[23:21] <TJ-> I think that problem was the entire ISP connection dropping - just noticed the IRC client reconnected with IPv4 instead of IPv6
[23:22] <TJ-> I've never known an LTS with so many issues as 16.04. I seem to spend most of my days tracking them down
[23:23] <sladen> TJ-: please can you turn them into bug reports.  This immediately starts to help other people Googling with the same error messages, and in the medium term allows a starting point for getting them fixed
[23:24] <TJ-> OK, got it again "lubuntu-artwork_0.62.tar.xz: Connection to ppa.launchpad.net closed by remote host." ... but iftop shows a steady 1Mb/sec upload still going on
[23:24] <TJ-> sladen: they are all bug repports
[23:24] <sladen> TJ-: excellent
[23:24] <TJ-> sladen: along with patches in most cases
[23:24] <sladen> TJ-: doubleplusgood!
[23:24] <TJ-> But it would be nice if someone learned what 'regression tests' means :)
[23:26] <cjwatson> some of us have 25000 of them ;-)
[23:26] <sarnold> you could add dep-8 tests for the things you found so they'd show up on http://ci.ubuntu.com/ if they break in the future :)
[23:27] <cjwatson> (upload problems to ppa.launchpad.net sound like connectivity issues, honestly - I agree with trying wireshark, you'll probably find some evidence in there)
[23:27] <sarnold> hmm maybe not that, that looks ancien.t
[23:27] <TJ-> this is nice "Successfully uploaded packages." ... despite the connection closed message... now to see if I get an Accepted email!
[23:28] <TJ-> cjwatson: Yes, you're the guy I want! a bug in grub2 I had to chase with a client today actually. do you recall if you were responsible for the patches/sleep_shift.patch (adds Shift keys to GRUB_TERM_ESC in sleep --interruptable) ?
[23:29] <TJ-> because on 16.04 Shifts no longer work, and the alternative Esc is causing issues because it is also the key that accesses the firmware's setup
[23:30] <TJ-> cjwatson: I shall be filing a bug report on it shortly, now I've got the plymouth-theme-lubuntu-logo bug-fix uploaded, but wondered if sleep was one of yours?
[23:30] <cjwatson> TJ-: I wrote that patch eons ago and it's known that it doesn't work on UEFI
[23:30] <cjwatson> TJ-: but it's not my responsibility any more, you want cyphermox
[23:30] <cjwatson> (well, not in Ubuntu anyway)
[23:31] <TJ-> cjwatson: right, so there's a bug report... I couldn't find one earlier but maybe I didn't search well enough
[23:31] <cjwatson> I don't know if there's a bug report but I knew about the issues when I wrote the patch
[23:31] <cjwatson> UEFI doesn't (or at least didn't at the time) permit checking the status of keyboard modifiers with zero delay
[23:32] <cjwatson> and I was instructed to make it zero delay
[23:32] <cjwatson> so meh
[23:32] <TJ-> ahhh bug 1028126
[23:32] <TJ-> cjwatson: thank-you :) I'll do some work on it then, see if I can come up with a fix
[23:33] <cjwatson> I have a vague recollection that I might have tried to add a delay only on UEFI, but I don't remember if that's true or if so where
[23:33] <cjwatson> certainly dig through the current spec version and see if you can work out a way to do zero-delay modifier checks
[23:33] <TJ-> cjwatson: I'm working on cryptodisk patches to add keyfile support, and detached headers, which are going upstream, but not dabbled in the GRUB term code so far, still find it easy to get lost in the modules and abstraction at times
[23:34] <TJ-> cjwatson: did you understand that to be a problem with UEFI itself, or GRUB's use of UEFI ?
[23:34] <cjwatson> UEFI itself
[23:35] <cjwatson> I haven't read the relevant bits of the spec for a while but at the time it was not possible to implement the getkeystatus method in grub-core/term/efi/console.c (as opposed to e.g. grub-core/term/i386/pc/console.c)
[23:35] <TJ-> the "zero delay" being for the HIDDEN option of GRUB2?
[23:35] <cjwatson> sounds right
[23:36] <TJ-> ahhhh... OK, I think I can tackle it now... I wasted a few hours today searching fruitless in the source-code for the shift modifier... only to realise I was in the upstream repo, not the Ubuntu patched one!
[23:37] <cjwatson> https://anonscm.debian.org/git/pkg-grub/grub.git will be close enough
[23:38] <cjwatson> debian/patches/quick_boot.patch is the bit that relies on getkeystatus
[23:38] <cjwatson> and that also has an attempted fallback
[23:38] <TJ-> thank-you, that's really helpful.
[23:39] <cjwatson> the Escape bit is in grub-core/commands/sleep.c:grub_check_keyboard
[23:39] <cjwatson> so if that were made to check some other reasonable key as well as GRUB_TERM_ESC it would probably be a reasonable workaround for your client
[23:40] <cjwatson> backspace or something
[23:40] <TJ-> is the delay required for something in GRUB to settle... in other words, maybe "priming the pump" as soon as grub starts might help
[23:41] <TJ-> Yes, that's one thing he asked, but trying to avoid having to maintain patches that won't ever make it into upstream or Debian/Ubuntu. He ships a *lot* of laptops with Ubuntu pre-installed
[23:45] <ogra_> slangasek: i think your last livecd-rootfs change is missing bits in live-build/auto/build
[23:47] <cjwatson> TJ-: no "settling".  the reason a delay was needed when I last checked the UEFI spec is that it could only detect transitions in modifier keys, not the current state
[23:47] <cjwatson> TJ-: so that only works if there's enough time for a user to press a key in the relevant window
[23:48] <cjwatson> TJ-: I haven't been involved upstream in a while, but I think adding some other reasonable alternative key to interrupt the sleep command could go upstream
[23:48] <cjwatson> TJ-: it wouldn't really conflict with much else
[23:49] <slangasek> ogra_: what bits?
[23:50] <TJ-> OK, thanks for the background, it is making a lot of sense now
[23:50] <cjwatson> np
[23:50] <TJ-> that's a real foobar on the side of UEFI if it doesn't treat the modifiers as they were always intended
[23:51] <ogra_> slangasek: there are other mentions of "ubuntu-core:system-image"
[23:51] <cjwatson> eh, things are always fairly raw at the level of the firmware
[23:51] <cjwatson> pretty much by definition
[23:51] <slangasek> ogra_: yes; the ones I dropped were the only ones that were nested conditionals
[23:51] <cjwatson> and I think you're reaching with "always intended".  modifiers were intended to modify other keys, originally; testing their state in isolation is a bit of an extension really
[23:51] <cjwatson> obviously it would be nice if we could
[23:52] <ogra_> slangasek: ah, so the $PROJECT:$SUBPROJECT construct still exists ? fine then ... ignore me :)
[23:53] <TJ-> cjwatson: but the original IBM PC/AT hardware defined it at the I/O register level, so the bit flags represent the current state, not a transition
[23:53] <slangasek> ogra_: it does still exist for the moment, yes... we can eventually simplify but that's a bit more of a refactor, since there are other projects with support for builds that key on SUBPROJECT=system-image
[23:53] <slangasek> (whether they should or not is another question)
[23:53] <cjwatson> TJ-: I think it may be possible now though; looking at the current-ish spec, the EFI_KEY_STATE_EXPOSED flag to EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL.ReadKeyStrokeEx looks relevant
[23:54] <ogra_> yeah, stuff for the athens sprint i guess :)
[23:54] <ogra_> as long as stuff still builds allll is fine i guess
[23:54] <ogra_> -ll
[23:54] <TJ-> cjwatson: stop already, it's not your problem :p
[23:55] <TJ-> cjwatson: but thanks for saving me a few hours already :D
[23:55] <ogra_> (though it is yakkkety anyway .... nothing we currently focus on)
[23:55] <cjwatson> TJ-: looks like this may have been added in UEFI 2.4, which postdated my original work.  I'll leave figuring out whether it actually works to you


[07:50] <didrocks> hi mvo :)
[07:50] <mvo> hi didrocks
[09:03] <crevette> hello
[09:04] <didrocks> lut crevette
[09:05] <crevette> salut didrocks
[10:23] <didrocks> hi seb128 & huats
[10:24] <huats> hey seb128
[10:24] <didrocks> seb128: python-gnome and python-gnome-desktop are ready (bug #327938 and bug #327933)
[10:34] <seb128> lut didrocks huats
[10:34] <seb128> didrocks: ok thanks
[10:35] <didrocks> seb128: you're welcome :)
[11:16] <geser> could someone please look (or even better sponsor) bug 317344 as this blocks the transition of tomboy and f-spot to the new gnome-sharp2 package names?
[11:18] <huats> pochu: do you remember why you enabled the test-suite on gnome-keyring in debian ?
[11:24] <pochu> huats: because test suites are good
[11:24] <huats> pochu: sure but any other reason ?
[11:25] <seb128> you guys are speaking about gnome-keyring?
[11:25] <huats> because in the latest release, it fails to build if you enable them (because it sets -Werrors)
[11:25] <huats> seb128: yep
[11:25] <pochu> huats: in what arches?
[11:25] <seb128> well, that's building the test tools to neither install or run those
[11:25] <huats> seb128: I was asking pochu if there was any reason why he enable the test-suite
[11:26] <pochu> huats: and since what release?
[11:26] <seb128> so what is the interest?
[11:26] <seb128> you don't run those during the build
[11:26] <pochu> seb128: isn't it a test suite?
[11:26] <seb128> and you don't install those
[11:26] <seb128> right, but you need to run make run if you want to run it
[11:26] <seb128> and you don't do it
[11:26] <pochu> oh
[11:26] <seb128> and you don't ship the tools either
[11:26] <seb128> so I fail to see the interest
[11:26] <pochu> you're right then
[11:27] <tjaalton> seb128: I've got a request for gnome-menus; what about moving <DefaultMergeDirs/> to the end of {applications,settings}.menu, so that people can override the values by adding files in *-merged/
[11:27] <pochu> clearly what I wanted to do was to run the test suite... but I failed it seems ;)
[11:27] <huats> pochu: it was added (the set -Werrors) between the  the <IP_ADDRESS> dans the 2.25.5 I think
[11:27] <seb128> tjaalton: who made that request?
[11:27] <tjaalton> seb128: me :)
[11:27] <pochu> huats: ah ok
[11:27] <seb128> tjaalton: I've an air of dejavu
[11:27] <pochu> huats: so feel free to disable it... it seems my change was pointless :(
[11:28] <huats> pochu: and it fails on the architectures that are not present on ppa :) (otherwise we could test them more easily)
[11:28] <huats> pochu: already did :)
[11:28] <seb128> tjaalton: let me find the bug for you
[11:28] <tjaalton> seb128: ok, so for instance now I can't have a file in merged/ which would remove all KDE entries from the menus (we have to install both desktops)
[11:28] <tjaalton> thanks
[11:28] <seb128> tjaalton: http://bugzilla.gnome.org/show_bug.cgi?id=557443
[11:28] <tjaalton> sigh
[11:29] <pochu> huats: btw, do you have your check-symbols script handy? I'd like to have a look at it :)
[11:29] <huats> sure :)
[11:29] <huats> I will send it to you this afternoon ok ?
[11:29] <seb128> tjaalton: edit the .menu or ship a custom one if you want to do that
[11:29] <tjaalton> seb128: that's exactly what I'm trying to avoid :)
[11:30] <seb128> tjaalton: read the bugs for details and talk to vuntz and try to convince him if you still disagree
[11:30] <tjaalton> seb128: now I just include the file with the excludes, and it works just fine
[11:30] <tjaalton> but I had to add the include to the file
[11:31] <tjaalton> MergeFile that is
[11:31] <tjaalton> anyway, will read
[11:36] <pochu> huats: sure, thanks!
[11:36] <tjaalton> seb128: so the spec sucks :)
[12:08] <andreasn> mpt, ping
[12:15] <asac> seb128: bug 272010 -> please look at totem debdiff and tell me if you want me to push that or do something else on that package for you ;)
[12:21] <asac> anyone here has sun java5/6 plugin installed and can give me a dpkg -L on that?
[12:23] <gnomefreak> asac: http://pastebin.mozilla.org/621196
[12:23] <gnomefreak> its -l not -L
[12:24] <asac> gnomefreak: but i need -L ;)
[12:24] <gnomefreak> but dpkg doesnt like -L
[12:25] <syldeb35> asac: http://pastebin.mozilla.org/621198
[12:26] <asac> syldeb35: hmm ... there is no .so ... where are the alternative links ending?
[12:26] <asac> how is that file called?
[12:28] <didrocks> I have to bind to evince in gnome-python-desktop update: http://paste.ubuntu.com/116783/ but there is no evince-dev or some similar package and it builds successfully without it. Does this mean I have only to add it as a dependency of the binary package?
[12:32] <geser> didrocks: did you checked the build log if it detects evince or not? I guess it checks for evince but as it doesn't find the needed headers it skips it.
[12:33] <didrocks> geser: let me check (and I don't find any package with header for evince, appart from the two libraries that I added libevdocument-dev and libevview-dev)
[12:38] <syldeb35> asac : perhaps this one :dpkg -L sun-java6-bin -->http://pastebin.mozilla.org/621203
[12:38] <syldeb35> the alternative links end to /usr/lib/jvm/java-6-sun/jre/plugin/i386/ns7/libjavaplugin_oji.so
[12:39] <asac> yeah thanks
[12:39] <asac> syldeb35: is that the same filename for sun-java5-bin?
[12:43] <syldeb35> not sur because sun-java5-plugin not installed but I have /usr/lib/jvm/java-1.5.0-sun-<IP_ADDRESS>/jre/plugin/i386/ns7/libjavaplugin_oji.so
[12:43] <seb128> didrocks: there is libevdocument and libevview which are evince libraries
[12:43] <syldeb35> and /usr/lib/jvm/java-1.5.0-sun-<IP_ADDRESS>/jre/plugin/i386/ns7/libjavaplugin_oji.so
[12:44] <didrocks> seb128: yes, (cf my last sentence :)). I will just try to check the build log first
[12:44] <seb128> asac: the debdiff looks alright please upload
[12:45] <seb128> didrocks: those are the libraries supposed to be used, they did make libraries for a reason
[12:45] <didrocks> seb128: so, gnome-python-desktop will not really depends on evince, but only on those two libraries
[12:45] <seb128> right
[12:45] <asac> seb128: done. thanks
[12:45] <seb128> they made those libs especially for that
[12:45] <seb128> asac: did you push the changes to bzr?
[12:45] <didrocks> seb128: oh right (do you follow a ML to keep up to date with those informations?)
[12:46] <seb128> didrocks: not really, I do read the changes description on the ftp list
[12:46] <asac> seb128: am i part of -desktop?
[12:46] <seb128> ie the NEWS for new tarballs
[12:46] <seb128> asac: dunno, if you are not we can fix that easily ;-)
[12:48] <didrocks> seb128: it's just written "New Evince bindings", not that those 2 lib gives these bindings, but yeah, it's implicite :)
[12:48] <asac> seb128: trying to push ;)
[12:48] <asac> seb128: i think i have no permissions. can you add me?
[12:48] <seb128> asac: sure, one sec
[12:48] <seb128> didrocks: that might have been detailled on a planet.gnome.org blog
[12:49] <seb128> didrocks: and the mention of the split was on the evince side, ie they wrote about new libs allowing embeders
[12:49] <didrocks> seb128: ok. What's strange is that I have no "no evince binding found" in the build log when I don't add them.
[12:50] <didrocks> too late ;)
[12:50] <asac> now seb is gone :)
[12:50] <didrocks> he will be back soon, as usually ^^
[12:51] <asac> yeah. me feels itchy to push the branch and move on ;)
[12:51] <didrocks> asac: :)
[12:51] <didrocks> seb128: ok. What's strange is that I have no "no evince binding found" in the build log when I don't add them.
[12:51] <seb128> asac: added
[12:52]  * asac runs bzr push
[12:52] <seb128> didrocks: maybe the configure is not verbose, are the binding built and in the deb?
[12:52] <asac> ok Pushed up revision 9.
[12:52] <seb128> asac: danke
[12:52] <didrocks> seb128: let me add the b-d first to compare the build log :)
[12:52] <seb128> asac: welcome to ubuntu-desktop too btw ;-)
[12:55] <seb128> doing an another bootchart, brb
[12:55]  * asac feels thrilled
[12:55] <asac> and a warm feeling of new power ;)
[13:04] <didrocks> seb128: yes, it works. It activate a whole bunch of bindings now
[13:04] <seb128> see ;-)
[13:04] <didrocks> seb128: let me push the new branch version
[13:04] <didrocks> (and tag it again)
[13:05] <seb128> you are using tagging now?
[13:05] <didrocks> seb128: yes, since evince update :)
[13:05] <didrocks> I dunno if it's useful, but well
[13:06] <Tm_T> hi asac
[13:14] <didrocks> seb128: it's ok now
[13:24] <seb128> pitti: what command can be called to trigger suspend nowadays?
[13:43] <soren> pm-suspend?
[13:43] <soren> That's what I use.
[14:21] <seb128> mvo_: how busy are you today? ;-)
[14:23] <mvo_> seb128: medium, why? need some sponsoring love?
[14:23] <seb128> mvo_: no, there is a new gnome-control-center version available, I'm looking at it but in case some your patches need to be updated ;-)
[14:24] <mvo_> seb128: hm, I see. if there is trouble please ping me, I will have a look
[14:24] <seb128> mvo_: ok thanks, the proxy thing doesn't apply I'm looking at it
[14:25] <seb128> did I already say how much I dislike glade changes? ;-)
[14:28] <mvo_> you did (and I agree)
[14:28] <geser> mvo_: if you have some time for sponsoring, could you please look and sponsor bug 317344?
[14:29] <mvo_> geser: sure, let me have a look
[14:29] <seb128> mvo_: ok that was an easy one you are off the hook for now ;-)
[14:30] <mvo_> *puffff*
[14:30]  * mvo_ makes a sign of relief :)
[14:30] <seb128> ;-)
[14:30] <seb128> trying gsd update, brb
[14:33] <crevette> wow my karma doubled in the last 2 weeks
[14:33] <crevette> I started low :)
[14:36] <mvo> geser: I have to admit that I don't know that much about c#, is ok that its still "libgnomedesktop2.20-cil" (even though this is now updated to 2.24?
[14:38] <geser> mvo: me neither, I hope that the Debian maintainers know what they do (slomo did the upload to experimental)
[14:38] <mvo> geser: aha, if he did it, then its probably allright :)
[14:39] <crevette> should I ping someone to have universe packaged sponsored? I did 2 bug reports for new versions with universe sponsors subscribed, but I don't news about them
[14:39] <seb128> tseliot: are you there?
[14:39] <mvo> oho, someone else on the hook now ;)
[14:39] <seb128> crevette: no, there is just a lot of items, look on http://daniel.holba.ch/sponsoring/
[14:39] <tseliot> seb128: sure
[14:39] <seb128> mvo: see it's not only you ;-)
[14:40] <seb128> tseliot: you gave me patch updates for some of the g-c-c changes yesterday, did you actually change something to those?
[14:40] <seb128> tseliot: ie 109_screen_resolution_extra.patch applies correctly to 2.25.90
[14:41] <tseliot> seb128: yes, I did changes to them
[14:41] <seb128> same for 110_screen_resolution_package.patch
[14:41] <tseliot> seb128: I think I gave you the right patches, let me check them again
[14:42] <seb128> tseliot: could you summarize the changes so I know why I should use your versions and what to write in the changelog ;-)
[14:42] <seb128> http://albertomilone.com/ubuntu/gnome/jaunty/gcc-patches/110_screen_resolution_package.patch
[14:42] <seb128> http://albertomilone.com/ubuntu/gnome/jaunty/gcc-patches/109_screen_resolution_extra.patch
[14:42] <seb128> http://albertomilone.com/ubuntu/gnome/jaunty/gcc-patches/25_window_manager_settings.patch
[14:43] <seb128> the previous version of those still apply correctly
[14:43] <seb128> I'm not sure what you changed
[14:43] <tseliot> seb128: there were only some small conflicts. The real changes took place in the patches for gnome-desktop
[14:44] <tseliot> seb128: therefore if the old patches compile, simply leave them as they are
[14:44] <seb128> ok
[14:44] <seb128> right the 80_aspect_in_dropdown.patch needed to be updated
[14:44] <seb128> thanks
[14:45] <tseliot> that was relevant to what I do so I thought it would be useful to update it
[14:45] <seb128> indeed that was useful thanks for that one ;-)
[14:45] <tseliot> ;)
[15:24] <lool> seb128: BTW I know now what really made me unhappy about bug-buddy and gnome-dbg
[15:24] <lool> seb128: Something on my system pulled bug-buddy at some point
[15:24] <lool> which pulled gnome-dbg
[15:24] <lool> gnome-dbg and bug-buddy have some circular dependency (one recommends one depends) and wont ever get out of your system
[15:25] <lool> Downgrading the recommends make this loop go away, which is good for my sanity
[15:25] <seb128> ;-)
[15:25] <seb128> I use neither bug-buggy or gnome-dbg so I was not really bothered but I understand your issue ;-)
[15:26] <lool> I guess I could as well drop the bug-buddy depends from gnome-dbg
[15:27] <crevette> what is gnome-dbg ?
[15:27] <lool> a meta package pulling all the *-dbg on Debian
[15:28] <crevette> ah okay, I thought it was kind of debug wrapper scripts that could appears when a crash happens, and offer you to debug it, like in windows :)
[15:28] <seb128> didrocks: is gnome-python-desktop ready to be reviewed?
[15:28] <lool> crevette: Sure, and it would also hand you a patch?   :-)
[15:29] <crevette> lool, we could propose to run nemiver instead of bug-buddy :)
[15:29] <crevette> only for real mens
[15:30] <crevette> lool, I hope you bought the wonderful GNOME tee-shirt at FOSDEM?
[15:31] <maxb> I have Alt+F6 configured to "Run a terminal" as per default, and in compiz it works. In metacity, instead it causes a thick black border to highlight the active window - what is this hilight for, and why is it intercepting the configured keybinding?
[15:32] <lool> crevette: I did
[15:32] <crevette> lool, \./
[15:32] <crevette> are they nice? I choose them, I ordered the print, but I don't know what they look like :)
[15:33] <crevette> s/what/how/
[15:33] <walters> maxb: see /apps/metacity/global_keybindings - by default that's switch_group which switches windows inside a "group" (application, sort of)
[15:34] <maxb> hmm
[15:34] <maxb> I guess I need to file a bug about the UI and actual behaviour disagreeing
[15:34] <asac> seb128: what do you think about bug 217551 ... nm just opens gtk_menu_popup with activate_time
[15:34] <lool> crevette: They are simple and nice
[15:34] <lool> I like the color a lot better than last year's
[15:35] <crevette> don't you like the green ?
[15:35] <crevette> :)
[15:35] <seb128> asac: needs debugging?
[15:35] <crevette> the burgundy looked like cool on the paper
[15:35] <crevette> so I chose that :)
[15:35] <seb128> asac: any reason you don't try to authentificate while the menu is open?
[15:37] <maxb> Where are the keybindings that gnome-keybinding-properties edits stored?
[15:37] <asac> seb128: hmm ... dont think i understand what you mean. from what i understood the keyring dialog is triggered and then all input isnt processed anymore
[15:38] <seb128> asac: to me it seems that the keyring callback get called while the menu is open which creates a keyboard grabbing issue
[15:38] <seb128> asac: usually you open a menu, click on an item, that calls the keyring callback and the menu is closed before you get the dialog
[15:39] <asac> seb128: how does keyring grab keyboard?
[15:40] <asac> gdk_keyboard_grab ;)
[15:41] <seb128> asac: yes
[15:43] <seb128> asac: http://bugzilla.gnome.org/show_bug.cgi?id=554782
[15:43] <seb128> asac: that bug suggests it has been fixed in nm-applet svn some months ago, do you still get the issue on jaunty?
[15:45] <asac> seb128: keyring does no error handling for "grab_keyboard"
[15:46] <seb128> asac: http://svn.gnome.org/viewvc/network-manager-applet?view=revision&revision=1062 ?
[15:47] <asac> seb128: Not fixed in intrepid, not fixed in jaunty. C'mon guys, this is REALLY irritating bug.
[15:47] <asac> seb128: i think it fixed the issue partially
[15:48] <asac> if you reopen the menu before keyring pops up it might reproduce still
[15:48] <seb128> asac: I agree it's an irritating bug
[15:48] <seb128> I'm not sure what the right fix is though
[15:48] <seb128> keyboard grabbing should fail in this case no?
[15:49] <seb128> brb
[15:49] <seb128> trying compiz update
[15:49] <asac> hmm
[15:51]  * seb128 looks to mvo
[15:51] <seb128> mvo: can I get a wm running? danke!
[15:52] <seb128> /usr/bin/compiz.real (core) - Error: Plugin 'core' has ABI version '20090207', expected ABI version '20080828'.
[15:52] <seb128> /usr/bin/compiz.real (ccp) - Error: InitObject failed
[15:52] <seb128> /usr/bin/compiz.real (core) - Error: Couldn't activate plugin 'ccp'
[15:52] <seb128> mvo: you broke my jaunty ;-)
[15:52] <maxb> seb128: Have you got the recent compiz-fusion-plugins-{main,extra} updates? They seemed to take a while to reach the mirrors
[15:53] <maxb> Though clearly there aren't strict enough dependencies
[15:53] <mvo> seb128: did you upgrade everything? hrm hrm
[15:53] <seb128> maxb: that's alright, I know what is broken and why, I'm just teasing mvo because he didn't use breaks correctly ;-)
[15:53] <mvo> but yeah, some dependency strictness is missing
[15:54] <seb128> mvo: no, I did upgrade compiz-gnome
[15:54]  * mvo sighs
[15:54] <mvo> seb128: ha! so you did it on purpose ;) ?
[15:54] <seb128> which triggered compiz-core and compiz-plugins to be upgraded
[15:54] <seb128> mvo: yes, just to show if you did use breaks correctly this time ;-)
[15:54] <seb128> show -> see
[15:55]  * mvo hides under a rock
[15:57] <maxb> The new compiz has also broken a few keyboard shortcuts (bug 328111)
[15:57] <mvo> oh, thanks maxb
[15:57] <mvo> maxb: could you please check if you have the "gnomecompat" plugin enable (it should be default)
[15:57] <maxb> Sure!.. How? :-)
[15:59] <seb128> mvo: bug #327793 has some users which have issues
[15:59] <seb128> mvo: but that seems to be partial upgrades
[15:59] <seb128> restarting session again
[16:00] <mvo> seb128: the broken title bar should be fixed
[16:01] <seb128> mvo: ok, I get 6 workspaces on one line rather than 8 on 2 lines now
[16:01] <seb128> but compiz is running
[16:03] <mvo> seb128: hrm, bad
[16:03] <seb128> let me do an another session restart to make sure that's not transitionnal
[16:05] <seb128> mvo: hum and the gnome-panel taskbar lists all the dialog open, not only the ones on the current workspace as it should
[16:14] <davmor2> bryce: you around yet?
[16:14] <didrocks> seb128: thanks for the sponsoring (when you have some time, there is still gnome-python one)
[16:15] <seb128> didrocks: did you subscribe the sponsor team? it's not listed on
[16:15] <seb128> http://people.ubuntu.com/~dholbach/sponsoring/index.html
[16:16] <didrocks> seb128: yeah, apparently: bug #327933
[16:16] <seb128> it's in the not correctly parsed list, weird
[16:16] <didrocks> I will report a bug to dholbach :)
[16:18] <mvo> seb128: oh, lets talk about it after my meeting
[16:18] <seb128> mvo: it doesn't do it for everything, I'm trying to see what is going on exactly
[16:25] <seb128> mvo: are you running you shiny new compiz version? ;-)
[16:26] <mvo> seb128: no, don't tell me you run this unstable gnome ;) - kidding, yes I do on my workstation
[16:26] <bryce> davmor2: yep
[16:27] <mvo> maxb: please open "ccsm" (from e.g. a terminal) and check it should be in the top row
[16:27] <seb128> mvo: can you try to open evolution on any workspace and see if it's listed on all workspaces?
[16:27] <seb128> mvo: or gnome-screenshot
[16:28] <seb128> mvo: listed in the gnome-panel tasks, not in alt-tab
[16:28] <mvo> seb128: for me it seems to be only in the main one, maybe its viewport<->workspace ocnfusion again :( ?
[16:28] <mvo> and I run a very fresh profile, reseted it the other day
[16:28] <mvo> (the compiz profile)
[16:29] <seb128> I run a recent profile too
[16:29] <seb128> I selected normal in the capplet to restart compiz after the partial broken upgrade
[16:29] <davmor2> bryce: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-nv/+bug/309482 I've added the nv stuff.  Is there an easy way to force vesa use though for the vesa info everytime it reboots it's using nv again
[16:30] <mvo> seb128: lets debug after the meeting/tomorrow, I may need the dump of your profiel settings
[16:32] <seb128> mvo: ok, let me know when you want to debug this
[16:36] <asac> mvo: in the past i saw packages in /var/cache/apt/archives in apt-cache show PACKAGENAME ... thats not the case in jaunty anymore?
[16:36] <asac> s/packages/package-versions/
[16:39] <bryce> heya mvo
[16:40] <bryce> mvo: btw we can drop the blacklisting of Intel Eaglelake from compiz now.
[16:40] <bryce> mvo, (LP: #261080)
[16:41] <bluesmoke> bug 261080
[16:54] <mvo> bryce: done
[16:55] <mvo> asac: hm, what execalty did you see in the past? I have not changed anything here
[16:55] <mvo> asac: I will be away for some minutes, lets talk after
[16:56] <asac> mvo: i think i saw all versions in the cache ... now i see: version in archive + version installed
[16:56] <asac> but no version that is in cache but not installed nor in archive
[16:58] <mvo> asac: I don't think this ever worked, might be conincidence (archive==version-in-cache)
[16:58] <asac> mvo: well. i am quite sure it worked. i used it frequently
[16:59]  * asac confused
[16:59] <asac> of course i believe you ;)
[16:59] <mvo> asac: hm, I can review the bzr logs, but I have currently no idea
[16:59] <asac> you are the man (TM)
[16:59] <mvo> asac: might be really strange side effect or something
[16:59]  * mvo really runs now
[16:59] <mvo> bbl
[17:06] <bryce> mvo: excellent, thanks!
[18:07] <highvoltage> anyone else have a problem in Jaunty where "Launching File Browser" just opens up in a loop in the window list and slows down the machine to a crawl?
[18:24] <dobey> highvoltage: i've seen that happen in intrepid before. could be an extension you have installed, causing problems
[18:25] <highvoltage> dobey: I think it started happening when I installed the netbook-launcher, but it happens even in a safe-mode gnome-session
[18:25] <highvoltage> (when the netbook-launcher isn't started)
[18:25] <dobey> highvoltage: when it happened to me, it was a python-based nautilus extension i was playing with, causing nautilus to "crash" and the session kept restarting it
[18:30] <maxb> mvo: ccsm showed the gnomecompat plugin not selected. ticking it restored Alt+F1 and Alt+F2, but not Alt+F6. However, there's a further problem with handling these as a compiz plugin - it means the settings in gnome-keybinding-properties are not respected
[18:30]  * maxb goes to say the same in the bug
[19:00] <crevette> wow a lot of -dbg pulled in the lastest update
[19:04] <maxb> Yeah, I think that isn't sane
[19:04] <maxb> bug-buddy is the source of the Recommends that pulls it all, AFAIK
[19:05] <pochu> well, you shouldn't need bug-buddy in Ubuntu ;)
[19:06] <maxb> But I didn't install it manually
[19:06] <maxb> It may be that update-manager needs to consider removing bug-buddy rather than pulling in all that lot
[19:34] <benc> do I need to install or configure a firewall on ubuntu desktop?
[19:36] <BugMaN> benc: read this -> https://help.ubuntu.com/8.10/keeping-safe/C/firewall.html
[19:37] <benc> thanks. is it recommended or unnecesary?
[19:38] <BugMaN> benc: not necessary like in a windows environment
[19:39] <benc> BugMaN: I'm developing  web applications so I guess I should setup a firewall. thanks
[19:40] <BugMaN> benc: ok in this case is better to install a firewall
[19:40] <benc> thanks
[20:26] <mvo> maxb: thanks for this update, I check it out (tomorrow)
[20:29] <asac> since today my window decorations are white :/
[20:29] <asac> maybe uxa
[20:29] <asac> let me test
[20:32] <asac> hmm ... that wasnt the problem
[20:47] <bryce> asac: is this with the new 6.10.99 -ati?
[20:48] <asac> bryce: no thats on my thinkpad with i965
[20:48] <asac> i am currently upgrading in the hope that its gone :)
[20:49] <bryce> ok
[20:49] <bryce> duh right, uxa == intel
[20:49] <asac> bryce: http://people.ubuntu.com/~asac/tmp/screen_white.png
[20:50] <asac> but its not accellmethod
[20:50] <bryce> weird.  compiz maybe?
[20:52] <bryce> compiz (1:0.7.9+git20090211-0ubuntu1) was uploaded yesterday, that'd be my first guess
[20:53] <bryce> if you still have earlier compiz debs in your /var/cache/apt/archives/ maybe try reverting?
[20:53] <asac> bryce: ok. it was a temporary issue as it seems
[20:54] <asac> last update made it go away \o/
[20:54] <asac> how colorful a desktop can be ... impressive ;)
[20:54] <asac> for a moment i thought it was an experient from dx team ;)
[20:55] <asac> experiment
[20:58] <bryce> hehe
[22:34] <Amaranth> asac, bryce: Downgrade metacity, not compiz
[22:34] <Amaranth> libmetacity-private changed
[22:34] <Amaranth> The fix should be in compiz git at this point, gotta check on that
[22:35] <Amaranth> Problem was we were creating an RGBA colormap the "old-fashioned" way since when that code was written the way libmetacity wants it done didn't exist
[22:35] <asac> Amaranth: for me its fixed already
[22:35] <Amaranth> ah, mvo is quick :)
[22:38] <Amaranth> yay a git snapshot even
[22:38] <Amaranth> that means wall viewport changing should look a lot cooler
[22:51] <bryce> sweetness.  dual head at 3840 x 1200, and compiz is working (and nice performance).
[22:51] <maxb> asac's grey titlebar issue should be fixed with latest compiz and metacity in the archive
[22:52] <bryce> on RV535/X1650
[22:52] <bryce> I'm stunned, I've not had both dual-head and compiz like this before.  very nice
[22:53]  * bryce wobbles windows across two monitors
[22:53] <dobey> bryce: i wonder how well it works at 4096x1152 :)
[22:55] <bryce> hmm, only issue so far is when I first enabled compiz, it moved all my gnome-terminal windows to 0x0
[23:16] <bryce> Amaranth: hey, have you played with the cube and dual-head displays?
[23:16] <Amaranth> bryce: not in a _long_ time
[23:17] <bryce> basically it seems to give me two cubes, one for each screen
[23:17] <bryce> with each screen being an adjacent face on the cube
[23:17] <bryce> which... works... but doesn't feel right
[23:17]  * bryce shrugs


[16:06] <batteronizer> Hi
[16:06] <batteronizer> I've made an Ubuntu lens
[16:07] <batteronizer> but on quickly submitubuntu, I get this: ERROR: No submitubuntu command found in template unity-lens.
[16:07] <batteronizer> what am I doing wrong here?


[10:14] <ogra_> lilstevie, around ?
[10:48] <brendand> hey, does the hard-float image work on the pandaboard?
[10:53] <ogra_> sure
[10:54] <brendand> does it make any difference?
[10:54] <ogra_> it fells faster, i didnt measure anything myself
[10:54] <ogra_> so thats a totally subjective impression
[10:54] <brendand> yeah, that might be an interesting experiment
[12:21] <lilstevie> ogra_: kinda, redecorating bedroom
[13:30] <lilstevie> ogra_: if you are about I am here now :)
[13:31] <ogra_> lilstevie, i was wondering if you have anything newer for the transformer than 2.6.36
[13:31]  * ogra_ is just playing with an ubuntu installed transformer and the kernel seems to have some issues
[13:31] <ogra_> though the config is a bit odd anyway
[13:32] <lilstevie> the config is a bit off yeah, been working on some things though
[13:32] <lilstevie> I will have something newer soon
[13:33] <ogra_> but you are on the same source ?
[13:33] <ogra_> k
[13:35] <lilstevie> well I am working on bringing it over to mainline
[13:36] <lilstevie> there is the 2.6.38 CrOS kernel if you are using u-boot though
[13:38] <ogra_> not sure they use u-boot on this device
[13:38] <ogra_> its not mine, i just got it to look at some performance issues
[13:38] <lilstevie> ah,
[13:39] <lilstevie> yeah probably stock bootloader then
[13:39] <ogra_> (and noticed a bunch of udev errors on boot)
[13:39] <lilstevie> hm
[13:39] <ogra_> looks like it doesnt have dnotify enabled and other minor things
[13:39] <lilstevie> can you grab the config from /proc/config.gz and see what the generation date is?
[13:43] <ogra_> # Linux kernel version: <IP_ADDRESS>
[13:43] <ogra_> # Tue Jan  3 09:26:31 2012
[13:43] <ogra_> but i think they recompiled the kernel already
[13:46] <lilstevie> wow
[13:46] <lilstevie> jan 3
[13:46] <lilstevie> :p
[13:46] <lilstevie> thats not my kernel
[13:46] <lilstevie> :p
[13:47] <lilstevie> but it is built off the latest probably
[13:47] <lilstevie> there are some odd things missing from the config, I am aware of that, and I have been adding them as I have been made aware of them
[13:47] <brendand> ogra_ - any chance the hf images might not work on older pandaboards?
[13:47] <lilstevie> although, can't say I have seen any udev errors
[13:47] <ogra_> define older
[13:47] <brendand> i have an A1 and it isn't going anywhere
[13:48] <ogra_> we tested onm EA1 which is even older
[13:48] <ogra_> *on
[13:48] <brendand> okay
[13:48] <infinity> Define "not going anywhere"?
[13:49] <brendand> maybe it's just the latest image then
[13:49] <infinity> Usually that's a bad SD, or a a badly-seated card.
[13:49] <brendand> hmm
[13:49] <GrueMaster> brendand: I have run it on every HW revision board I have (EA1-A3 & 4460).
[13:49] <brendand> well, the light pattern seems a bit weird. not what i usually see
[13:49] <GrueMaster> And I have today's daily image running now on 4460.
[13:50] <GrueMaster> Precise kernel doesn't blink the led's like maverick-oneiric kernels did.
[13:51] <brendand> when i switch my monitor to the dvi input, it just switches back again. that usually means nothing being output on the dvi
[13:52] <GrueMaster> brendand: That is a different issue (and one I haven't tested).
[13:53] <GrueMaster> Try the HDMI port.
[13:53] <brendand> jeez
[13:54] <brendand> all of a sudden it's the HDMI port that needs to be used. great
[13:54] <GrueMaster> Erm, that has always been the case.
[13:54] <GrueMaster> At least that is how I have tested since Maverick.
[13:56] <brendand> oh well, no worries
[14:05] <kerute> hello
[14:07] <kerute> lilstevie_: sorry to bother you, if i want to try the 2.6.38 in OLiFe, what should I do ? i tried to flash using the 'update cros kernel' or by replacing the 2.6.36 with tne .38 but i either end up in initramfs shell telling me there is no mmcblk0p8 or stuck on 'asus' boot screen
[14:08] <lilstevie> kerute: at this point, solve the reason why it wont read asus/nvidias bastardized gpt implimentation
[14:09] <lilstevie> or use u-boot
[14:09] <kerute> ok so u-boot i have to compile it from your repo (u-boot-tegra) and flash it using OLiFe ?
[14:10] <lilstevie> yes
[14:10] <kerute> ok thanks a lot
[14:11] <kerute> for the first point i'm not sure i have enought knowledge :)
[15:08] <ppisati> would kexec be a nice addition to our kernels?
[15:09]  * infinity glances at #ubuntu-kernel
[15:11] <ppisati> well, if you want it i need a bug to be opened against our P kernels
[15:11] <ppisati> teh patchset is quite big, but it works
[15:11] <ppisati> so i won't backport it to O
[15:15] <infinity> ppisati: I didn't say I wanted it.
[15:16] <infinity> ppisati: Do the x86 Ubuntu kernels have kexec?
[15:16] <ppisati> yep
[15:16] <ppisati> it was broken on arm
[15:16] <ppisati> but a series of patches make it work on arm now
[15:16] <infinity> Ahh.  Well, I'm a fan of our ARM kernels mirroring the x86 ones.
[15:16] <ppisati> yep
[15:16] <infinity> Just as an element of least surprise.
[15:16] <ppisati> the problem is that all the stuff is in 3.3
[15:17] <ppisati> and the backport for omap-only is about...
[15:18] <ppisati> ~17 ptches ATM
[15:18] <ppisati> the entire patches with all the archs is about...
[15:18] <ppisati> 70 patches? more or less
[15:19] <ppisati> sorry, with all the arm chips
[15:19] <ppisati> and i want to apply it to master
[15:19] <ppisati> so i'll percolate down to all the topic branches
[15:19] <ppisati> it'll
[15:19] <ppisati> (can't type today...)
[15:28] <GrueMaster> iirc, kexec was attempted multiple times on arm.  seems to come up every cycle.  I think there is an old blueprint on it.
[15:30] <GrueMaster> ppisati: do a google search:  arm kexec site:launchpad.net
[15:30] <GrueMaster> lots of entries.
[15:39] <ppisati> GrueMaster: cool
[15:39] <ppisati> there's still an issue
[15:39] <ppisati> but it's workable
[15:40] <ppisati> aka nic is dead after kexec
[15:46] <GrueMaster> How is this considered "workable"?
[15:48] <ppisati> in the sense that it's an isolated fix
[15:48] <ppisati> some stuff is not initialised properly in smsc911x
[15:48] <ppisati> and when it boots from u-boot is ok
[15:48] <ppisati> else it craps out
[19:34] <calculus> I have ubuntu 11.10 on a pandaboard, did apt-get dist-upgrade, connected a tv to the hdmi port, and video works, but I am trying to get the audio to come out on the tv as well... any ideas?
[19:34] <calculus> is there something in alsamixer that needs to be turned on/unmuted?