[00:04] <wookey> doko: well done
[00:07] <mspencer> Should questions related to the development of an app with a specification on wiki.ubuntu.com be asked here or on #ubuntu-app-devel?
[00:07] <mspencer> The app is Contributor Console, https://wiki.ubuntu.com/ContributorConsole
[00:09] <ScottK> mspencer: Not here.  Not sure if that's better or not.  Perhaps #ubuntu-desktop too.
[00:18] <bdrung> infinity: may i ask you to process gnustep-gui in around one or two hours once armhf and powerpc are built?
[00:20] <infinity> bdrung: I'm sure you can.  (Someone will get to it regardless)
[00:22] <bdrung> infinity: hä? gnustep-gui is/will stuck in binary NEW.
[00:30] <infinity> bdrung: yeah, I know.  We'll get to it.
[01:40] <cjwatson> roaksoax,Daviey: Where's the upstream bzr repository for maas-enlist?  It looks like it has a separate upstream existence and the upstream part of its version is "0.4+bzr36", but there's no lp:maas-enlist
[01:43] <roaksoax> cjwatson: lp:~maas-maintainers/maas/maas-enlist
[01:43] <cjwatson> Thanks
[02:18] <epikvision> Hello all.  I have a question. Why do some packages that exist in lp not appear in the Ubuntu Software Center?
[02:42] <jcastro_> someone needs to put the stuff from lp into ubuntu
[02:42] <jcastro_> it just doesn't automagically happen
[02:48] <infinity> jcastro_: I'm not sure if he meant "software in random PPAs and bzr branches" or "software in the Ubuntu archive (as shown on LP) that isn't indexed in SC"
[02:48] <infinity> epikvision: ^?
[02:49] <jcastro_> seems like he meant lp as a whole, which includes the things you just mentioned
[02:50] <epikvision> yeah, that's what I meant.
[02:50] <infinity> jcastro_: Given that software-center (intentionally) only indexes things with desktop files, I suspect it builds some confusion from people who, say, search for Apache and wonder why we don't "ship" it (when we clearly do).
[02:50] <jcastro_> I'm answering your question on askubuntu, which I assume you just posted because it's just similar
[02:50] <epikvision> I just did; thanks.
[02:52] <epikvision> jcastro_ I also included a comment to extend the question.
[03:30] <epikvision> jcastro_ so I guess having a packager in the app review board makes a powerful combination!  ^^
[03:34] <ScottK> It's a fundamental flaw in the system that non-developers are on the board at all.
[03:37] <jcastro_> even if the ARB was full of say, full MOTUs or Core Devs, they would still be doomed
[03:37] <ScottK> Well sure.
[03:38] <ajmitch> ScottK: there aren't any non-developers on the board, nor will there be going forward
[03:38] <ScottK> OK.  Good to hear.
[03:39] <ScottK> I guess I got confused by the new review policy.
[03:58] <achiang> for a UDD package, where a bzr checkout only gets the debian/ directory (network-manager-gnome in this case), how do i build a test package for upload? with a normal package, i'd do debuild -S -sa -I -i
[04:02] <infinity> achiang: Unpack the orig, export the debian directory into it, then debuild -S
[04:03] <cyphermox> achiang: bzr bd should do it
[04:04] <cyphermox> (or bzr bd -S)
[04:04] <cyphermox> backtracking though, what branch did you use?
[04:04] <achiang> infinity: what does "export" mean in this context? i was thinking: find .orig.tar.gz, .dsc, and .diff.gz files, dpkg-source -x, then rm -rf the debian directory, then cp -a the bzr branch's debian directory into it... i'm sure you're suggesting a less clunky method. :)
[04:05] <achiang> cyphermox: bzr+ssh://bazaar.launchpad.net/~network-manager/network-manager-applet/ubuntu.precise/
[04:05] <cyphermox> achiang: rock on :)
[04:06] <cyphermox> yeah, bzr bd is what you're looking for, and if you want to make things easy you'll want to download the orig tarball from launchpad
[04:07] <achiang> man... that is clunky
[04:08] <cyphermox> I admit it needs a bit of new love :)
[04:10] <RAOF> Full source branches work better, but suffer from slow branching.
[04:11] <ScottK> FSVO better.
[04:12] <ScottK> But then I use diff and patch to move stuff between what I plan to upload and bzr.
[04:13] <cyphermox> RAOF: really I should just do away with that old concept of get-orig-source in that package, which I inherited from when I started maintaining the package and was the way it was due to daily builds
[04:14] <cyphermox> and I already have a branch that fixes all this, I just had more important things to do than merging it :/
[05:29] <bkerensa> is someone doing phantom patch pilot? :) I just got a few MP's that got merged with no review
[05:29] <bkerensa> heh
[05:37] <pitti> Good morning
[05:37] <ScottK> bkerensa: patch pilot is a time for Canonical employees that's set aside for them to do sponsoring work.  Other people do it too.
[06:09] <pitti> apw, infinity: argh, I suck; can you please change "Restictions: needs-build" to "Restrictions: build-needed"? *brown paperbag*
[06:10] <pitti> I'll send a patch for binutils today
[06:13] <scientes> what non-free software makes the ubuntu-nexus7-installer claim "non-commercial" use?
[06:13] <scientes> cause the installer itsself is GPL 3
[06:14] <pitti> scientes: I suppose it's related to the bits of non-free drivers that it ships, such as the Tegra one
[06:15] <scientes> does it ship flash?
[06:15] <scientes> cause i know flash for arm GNU/Linux (glibc/x11) is non-commercial
[06:16] <scientes> if i install ubuntu will i still have android?
[06:16] <scientes> can i dual boot?
[06:19] <pitti> not with that image
[06:19] <scientes> "
[06:19] <scientes> There are currently no plans to support dual booting Ubuntu and Android."
[06:19] <pitti> but you can download and restore the original android image
[06:38] <infinity> pitti: Grr.
[06:38] <infinity> pitti: I even read the spec, but didn't notice that you'd given me the wrong syntax.
[06:39] <infinity> pitti: I won't fix it right away, but it'll make its way into the next glibc upload.
[06:40] <infinity> scientes: We don't wipe out the partition layout, so if you backup with something like nandroid, you can restore.
[06:41] <infinity> scientes: As for the non-commercial bits, pitti's right, it's drivers.  Though, the most restrictive one is some broadcom blob, not the nvidia one.
[06:41] <infinity> scientes: Not that I think it matters, other than covering our butts a bit, since it's clearly a tech preview sort of toy, not something you're going to put on 1000 tablets and deploy in the enterprise. :P
[06:51] <bkerensa> infinity: surely the drivers do not require Canonical/Ubuntu to demand no-commercial use?
[06:51] <bkerensa> these drivers are already used commercially on the Nexus 7 when running Android?
[06:53] <infinity> bkerensa: http://paste.ubuntu.com/1376568/
[06:53] <pitti> infinity: it's not urgent, next upload is fine; thanks!
[06:53] <infinity> bkerensa: That's the only license we have.  Clearly non-commercial, and only gives us the right to extend a non-commercial use grant to our users.
[06:54] <infinity> bkerensa: I would assume that Google has a different license.  Not all licenses are created equal. :P
[06:55] <bkerensa> infinity: huh
[06:55] <infinity> bkerensa: If you, of course, have obtained the same binaries under a different license, you can do whatever you're allowed to do, but that's the license we have, so.  *shrug*
[06:56] <infinity> (Well, the license is longer, obviously, but that was the relevant bit)
[06:56] <bkerensa> infinity: I wonder how that works for Canonical employees who are trying to improve the core of Ubuntu on the N7 since their use would be commercial in nature?
[06:56] <infinity> How is it commercial?
[06:56] <bkerensa> well if they are paid by a company to improve Ubuntu Core on the N7 device using those drivers the nature of their use is not personal
[06:58] <infinity> bkerensa: It's possible for commercial organisations to engage in non-commercial activities.
[06:59] <infinity> bkerensa: We're not selling (or monetizing in any way) Ubuntu on the N7, and certainly not that firmware.
[07:00] <bkerensa> infinity: The platform is monetized technically since the shopping lens ships with the image :)
[07:00] <bkerensa> although I double Canonical will see any revenue on the N7
[07:00] <bkerensa> ;p
[07:00] <bkerensa> I can barely access the dash at this point
[07:01] <infinity> Seems a great argument to file a bug to remove that lens in the N7 image. :P
[07:01] <bkerensa> infinity: not worth my time ;p
[07:01] <infinity> Nor mine.
[07:40] <dholbach> good morning
[07:49] <pitti> hey dholbach
[07:52] <pitti> infinity, doko: I attached a binutils debdiff to bug 1081500; let me know if you want me to upload this; note that this is appropriate for Debian as well
[08:09] <jamespage> is there any nice way to stop a prerm thats doing something wrong on package upgrade?  I need a way of preserving some data generated by a package but the prerm script in the version in the archive currently removes it
[08:19] <tkamppeter_> Anyone knows the date of UDS-S?
[08:21] <xnox> tkamppeter: tentative schedule here https://wiki.ubuntu.com/SReleaseSchedule the week that has may the 16th
[08:24] <xnox> jamespage: i think "old" prerm is the first one that runs =( http://wiki.debian.org/MaintainerScripts
[08:24] <jamespage> xnox, yeah - thats what I'm trying to avoid
[08:25] <xnox> jamespage: well, if you have a dependency, you can make that dependency preinst script rescue your data.
[08:26] <jamespage> xnox, ? not sure I understand
[08:26] <xnox> e.g. if packageA eats data on prerm and depends on packageB, I think packageB preinst can rescue your data, but I have not tested this.
[08:27] <xnox> since packageB new preinst will be run before packageA prerm, you might possibly need pre-depends.
[08:28] <xnox> cjwatson: what's the best way to work around a broken prerm for a package already in the archive? (currently prerm is causing data loss on upgrade)
[08:29] <jamespage> xnox, right - I see
[08:29]  * jamespage looks at the Depends
[08:29] <jamespage> hmm
[08:30] <xnox> jamespage: if that is not possible, you might want to introduce a new pre-depends package called "packageA-rescue-data", but that is very extreme.
[08:31] <xnox> jamespage: what's the package in question?
[08:31] <xnox> jamespage: and the upgrade path? dist-upgrade or -security/-updates?
[09:57] <cjwatson> jamespage,xnox: Old prerms that don't fail but that do something undesirable are tough to work around.  The only method I can think of is a preinst of something you Pre-Depend on, as xnox suggests.
[09:58] <xnox> cjwatson: ack, thanks.
[09:58] <cjwatson> (Well, actually, the postinst would do.)
[09:58] <jamespage> cjwatson, yeah - its working OK using that approach - thanks for the feedback
[10:04] <seb128> doko, https://launchpadlibrarian.net/123630730/buildlog_ubuntu-raring-amd64.unity_6.12.0-0ubuntu2_FAILEDTOBUILD.txt.gz
[10:04] <seb128> "-- Found Gettext: /usr/bin/msgmerge (found version "0.18.1")
[10:04] <seb128> CMake Error at CMakeLists.txt:106 (if):
[10:04] <seb128>   if given arguments:
[10:04] <seb128>     "STREQUAL" "TRUE"
[10:04] <seb128>   Unknown arguments specified"
[10:04] <seb128>  
[10:04] <seb128> doko, do you know if something changed in the toolchain around yesterday? the issue started recently in raring
[10:05] <seb128> that's a no change rebuild (well a control recommends added) compared to the previous version which was building
[10:06] <xnox> seb128: well cmake had a new upstream release uploaded on 2012-11-15
[10:06] <seb128> xnox, the issue started around yesterday
[10:07] <xnox> seb128: ack.
[10:07] <seb128> we have daily builds in a ppa, they didn't break around the 15 but more recently
[10:07] <xnox> i see.
[10:07] <xnox> seb128: can I have a link to the build record to grab the source package?
[10:08] <seb128> xnox, apt-get source unity in raring
[10:08] <xnox> ok.
[10:08] <seb128> https://launchpad.net/ubuntu/+source/unity/6.12.0-0ubuntu2
[10:10] <seb128> xnox, or in fact it could be cmake... let me try to downgrade it
[10:10] <didrocks> yeah, let's try that first
[10:11] <xnox> seb128: for some reason the GETTEXT_FOUND is not set.
[10:11] <xnox> seb128: yet the above find_package (Gettext REQUIRED) should have done so.
[10:11] <xnox> unless it's now ${Gettext_FOUND} which is very not CMake like capitalization.
[10:12] <seb128> yeah
[10:12] <seb128> downgrading cmake fixes it
[10:12] <xnox> seb128: so a change in FindGettext.
[10:13] <seb128> Riddell, ^
[10:13] <seb128> Riddell, you did the cmake update
[10:13] <didrocks> that's a weird variable
[10:13] <seb128> http://launchpadlibrarian.net/123100540/cmake_2.8.9-1ubuntu1_2.8.10.1-0ubuntu1.diff.gz
[10:13] <seb128> is the diff
[10:13] <didrocks> Gettext_FOUND as xnox said, is really not cmake-like
[10:13] <seb128> there is a diff in FindGettext
[10:14] <seb128> +set(GETTEXT_FOUND ${Gettext_FOUND})
[10:14] <seb128> indeed, weird
[10:17] <xnox> seb128: didrocks: file a bug against cmake package & (you or somebody else) should forward this upstream.
[10:17] <xnox> currently it looks insane.
[10:17] <xnox> in cmake.
[10:17] <infinity> set(GETTEXT_FOUND ${Gettext_FOUND}) should be setting the old variable.
[10:17] <infinity> But it could well just be failing to find it correctly.
[10:17] <xnox> but I don't see them setting Gettext_FOUND either.
[10:18] <infinity> Looks like a complete rewrite of the module.  :/
[10:18] <didrocks> xnox: they don't apparently…
[10:18] <didrocks> not sure if the dep thing is magic in some way…
[10:19] <seb128> http://www.cmake.org/Bug/bug_relationship_graph.php?bug_id=13691&graph=relation
[10:19] <seb128> didrocks, ^
[10:19] <didrocks> with the added target
[10:20] <didrocks> PARENT_SCOPE
[10:20] <didrocks> this is even more black magic :)
[10:21] <seb128> we should maybe revert the FindGettext.cmake diff to 2.8.9
[10:21] <seb128> until that's properly fixed upstream
[10:21] <seb128> ?
[10:21] <xnox> seb128: I agree.
[10:21] <xnox> cjwatson: was there a magic wiki page for reverts?
[10:21] <cjwatson> xnox: https://wiki.ubuntu.com/UbuntuDevelopment/RevertLog
[10:21] <seb128> xnox, revert the whole cmake?
[10:21] <xnox> seb128: also we need autopkgtest in cmake for a sample FindGettext ;-)
[10:21] <didrocks> +1 on revert
[10:21] <seb128> or just FindGettext.cmake?
[10:22] <cjwatson> Is the FindGettext change fairly isolated from everything else?
[10:22] <xnox> seb128: I am hoping that reverting FindGettext should be sufficient.
[10:22] <cjwatson> If so, probably simpler to just revert it alone
[10:22] <infinity> Nothing else references that module.
[10:22] <infinity> So, reverting it alone should be fine, assuming the old version works with the new CMake.
[10:22] <didrocks> yeah, it seems standalone
[10:22] <infinity> (Which is really should)
[10:26]  * xnox is doing the revert, and will document it.
[10:26] <pitti> OOI, didn't we use to have three powerpc builders?
[10:27] <xnox> pitti: didn't like I see discussion somewhere of one ppc box disappearing?!
[10:27] <pitti> thanks xnox, so it's known
[10:28] <cjwatson> pitti: It failed to come back from reboot on upgrade - there's a high-priority RT about it
[10:31] <xnox> seb128: didrocks: does this work? https://bazaar.launchpad.net/~pimvullers/maya/fix-1080713/revision/380
[10:33] <didrocks> xnox: with the current cmake, you mean?
[10:33] <xnox> didrocks: yes.
[10:33] <seb128> xnox, it seems to work yes
[10:33] <seb128> well applied to unity
[10:33] <xnox> see related issue: https://bugs.launchpad.net/maya/+bug/1080713
[10:36] <xnox> seb128: didrocks: does the "new" style also work with older CMakes?
[10:37] <didrocks> seb128: want me to test or do you have a pbuilder handy?
[10:38] <seb128> didrocks, xnox: I didn't test a full build but "cmake .." works fine with that change to CMakeLists.txt, using both old and new cmake
[10:38] <seb128> where it was breaking with the new cmake before
[10:38] <xnox> awesome.
[10:38] <seb128> so it seems to be fine for both
[10:39] <didrocks> seb128: ok, I'll try a full build and ensure we have translations
[10:39] <seb128> didrocks, I've started one on my raring machine with the new cmake
[10:39] <didrocks> seb128: do you test on quantal as well?
[10:40] <seb128> didrocks, I can pbuild on quantal yes
[10:40] <didrocks> seb128: ok, I'll let you handle this then :)
[10:41] <xnox> cjwatson: no reverts after all =)
[10:41] <didrocks> I think it broke quite some packages though
[10:42] <didrocks> when I added the initial support, I looked at the doc
[10:42] <didrocks> and that was what was published IIRC
[10:42] <infinity> if(FOO_FOUND) is the more common usage, by far.
[10:43] <infinity> Though maybe not for Gettext specifically, if some doc was suggesting the STREQUAL. :/
[10:43] <infinity> rgrep through a lintian lab anyone?
[10:44] <Laney> http://codesearch.debian.net/search?q=STREQUAL+%5C%22TRUE%5C%22
[10:44] <infinity> Laney: Those aren't all necessarily wrong, if they're actually comparing strings, as I understand it.
[10:45] <Laney> Quite. I'm not suggesting they are, but I couldn't think of a better string in ten seconds. There's not so many results there to look at anyway.
[10:45] <infinity> I don't see a single GETTEXT in there, though.
[10:46] <Laney> Depends if it's something unique to GETTEXT_FOUND
[10:47] <Laney> But yeah, it's possible other PS packages have used the same idiom.
[10:47] <infinity> I suspect the new and bizarre voodoo in play to make GETTEXT_FOUND get set... however it gets set... also swapped it from being a string to a bool or something.
[10:47] <infinity> *hand wavy*
[10:49] <seb128> xnox, Laney, infinity, xnox: I would still go with the "revert the cmake gettext change" until somebody who knows about gettext figure out why it broke and what should be done
[10:49] <seb128> we don't even know how many builds in the archive that breaks
[10:49] <didrocks> just unity in the PS stack
[10:49]  * didrocks grepped
[10:49] <seb128> ups, the second xnox was meant to be didrocks
[10:49] <infinity> seb128: It breaks zero things in Debian, apparently.
[10:50] <xnox> infinity: Debian does not have that version yet?
[10:50]  * xnox goes to check
[10:50] <infinity> seb128: And outside of Debian-derived packages, the PS stuff may well be the only cmake-using things we care about. :P
[10:50] <infinity> xnox: No, we just grepped the archive.
[10:50] <xnox> It did break Maya on gentoo =)
[10:50] <Laney> I'd keep it. We'll find out if stuff breaks, and if it does then we know where the problem comes from and how to fix it.
[10:50] <seb128> xnox, debian doesn't have that version no
[10:51] <xnox> For future reference this is bug 1080713
[10:51] <xnox> with a bug link to cmake bug tracker.
[10:51] <didrocks> (I didn't grep through webapps, but if I see it failing, I'll fix it)
[10:51] <xnox> And I commented in cmake's bug tracker that this change breaks previously working CMakeLists.
[10:52] <seb128> it still seems an incompatible change
[10:52] <seb128> is that wanted?
[10:52] <xnox> seb128: which may or may not be appropriate for a new upstream cmake release.
[10:52] <xnox> seb128: i'd like to wait on a response from cmake developers on this.
[10:53] <infinity> It's a correct change.  That *should* be a boolean.
[10:53] <Laney> Things doing wrong things and getting burned isn't something to get too upset about if almost nothing is affected, IMO.
[10:53] <infinity> Reverting won't buy us anything here, if the impact is minimal.
[10:53] <Laney> I codesearched for GETTEXT_FOUND and didn't see anything.
[10:53] <xnox> seb128: until then, I'd like to keep ubuntu cmake package task as won't fix, as there is a way to work around in a sane backwards compatible way.
[10:53] <infinity> (I've certainly broken more packages with glibc 2.16 than this will break)
[10:53] <xnox> =))))))
[10:54] <infinity> And, as stated, this affects zero source packages in Debian.
[10:54] <infinity> So, if it affects us in any meaningful way, we're pretty special.
[10:54] <infinity> It may well just be unity.
[10:54] <xnox> infinity: and maya software see the bug report.
[10:54] <xnox> infinity: which came up with the fix in the first place ;-)
[10:54] <infinity> xnox: We don't ship maya.
[10:54] <Laney> Not in archive → doesn't exist.
[10:54] <Laney> :P
[10:54] <infinity> xnox: But if upstream fixed their build system, go them.
[10:55] <xnox> Laney: infinity: /me clearly confused maya with mayavi2 sorry
[10:55] <Laney> Some software sets GETTEXT_FOUND to TRUE/FALSE and some 1/0. Don't know if that will be affected.
[10:55] <cjwatson> xnox: Do please document that we had a discussion anyway; one of the things we wanted to know was how often we decided against reverting
[10:56] <xnox> cjwatson: ack.
[10:56] <infinity> Laney: No, no.  Those are packages shipping their own FindGettext module.
[10:56] <infinity> Laney: Anything SETTING it can be safely ignored, you just want to find things testing it.
[10:57] <infinity> Laney: And where they're a pair in the same source package, obviously it's using its private copy, so again, a red herring.
[10:59] <infinity> I can't quite sort out why, every time I poke at cmake, it feels both elegant and awful at the same time.
[11:00] <Laney> How does autotools feel?
[11:01] <infinity> Sort of exactly the opposite.
[11:02] <brendand> is there something special about variables starting with double underscore in python?
[11:02] <infinity> CMake feels pretty and clean and such, but I end up banging my head repeatedly on flat surfaces when I can't sort out the crazy abstracted way to do X, Y, or Z.
[11:02] <infinity> autotools, for all its ugly, is easy to just hack a quick DWIM test.
[11:03] <brendand> something strange happening in pdb, where instance variables named like that are perfectly accesible by the running code, but pdb somehow sees them differently
[11:05] <infinity> "Private name mangling: When an identifier that textually occurs in a class definition begins with two or more underscore characters and does not end in two or more underscores, it is considered a private name of that class."
[11:05] <infinity> brendand: http://docs.python.org/2/reference/expressions.html#atom-identifiers
[11:08] <xnox> seb128: didrocks: cjwatson: documented https://wiki.ubuntu.com/UbuntuDevelopment/RevertLog
[11:08] <didrocks> thanks xnox, looks good :)
[11:09] <xnox> cjwatson: also made the outcome of the previous instance more clear, as a patch revert did happen in libgcrypt11, but not in cmake's case.
[11:10] <seb128> xnox, thanks
[11:10] <xnox> fixed grammar now as well =)
[11:10] <brendand> infinity, that makes sense, but when pdb is inside a method shouldn't it be running 'inside' that instance? i'm going to guess that that isn't how pdb works
[11:11] <cjwatson> My suggestion would be to avoid __var like the plague ...
[11:11] <bdrung> dholbach: what kind of hardware do it need for hangouts?
[11:12] <brendand> cjwatson, i will now
[11:13] <dholbach> bdrung, a webcam helps - if you want to try it out, we could have a test hangout
[11:13] <xnox> bdrung: i386 or amd64. The easiest with google chrome browser.
[11:14] <infinity> xnox: Works just as well in firefox.
[11:14] <dholbach> bdrung, https://tools.google.com/dlpage/hangoutplugin
[11:14] <xnox> infinity: hmm... for me cpu blowsup under firefox... but maybe it's just me.
[11:15] <infinity> xnox: I found it about equally crap in both the last time I cared to compare.
[11:15] <xnox> noted.
[11:15] <infinity> xnox: And discovered that an Atom N450 wasn't good enough. :P
[11:15] <infinity> (This may have improved since... Man, I hope it has)
[11:16] <infinity> When the first step to video chat/conference is "find the most powerful computer in your house and kidnap it for use as a very expensive microphone stand", something's wrong.
[11:16] <dholbach> infinity, a tiny little bit maybe, but it's still taxing
[11:16] <xnox> well. I have tried it on an arm netbook and google kept on pretending I am running 32bit x86 compatible processor.
[11:17] <infinity> dholbach: Methinks the people who do their Android hangout client need to go smack the people who do the x86 browser plugin.
[11:17] <infinity> dholbach: Given that it runs better on my phone than my laptop sometimes. :P
[11:18] <bdrung> dholbach: then i need a webcam
[11:18] <bdrung> xnox: chrome or is chromium enough?
[11:19] <xnox> bdrung: chrome seemed to have everything built in. chromium needs a plugin just like firefox does.
[11:19] <xnox> bdrung: webcam is needed if you want to broadcast your face =) just a mic works and then you will be broadcasting a static picture/avatar.
[11:20] <bdrung> okay, then i have to test if my headset still works
[11:22] <bdrung> last time, i tried, i had problems with recording. now i have a different sound card. so this problem may have solved itself.
[11:22] <infinity> Alright, on a scale of 1 to nap, I think I'm going to go 13.
[11:22] <bdrung> which value has nap? infinity?
[11:22] <bdrung> ;)
[12:03] <brendand> what's the most straightforward way to find the maximum resolution of a particular display (say VGA-0)?
[12:03] <bdrung> brendand: maybe parsing the output of xrandr
[12:04] <brendand> bdrung, that's what i was afraid of - it's a bit ugly
[12:07] <bdrung> then i can't help you
[12:08] <brendand> cat'ing in /sys/class/drm/card0* *would* be cleaner if it wasn't for proprietary drivers
[12:36] <ion> slangasek: skype and skype-bin:i386 from the partner repo seem not to be installable at the same time.
[12:37] <bizhanMona> HI does ubuntu 12.10 supports EFISTUB bootloader?thx
[13:05] <mlankhorst> how do I request a package to be removed from universe? xserver-xorg-input-penmount has been broken in quantal and precise, and nobody noticed
[13:06] <cjwatson> file a bug and subscribe ubuntu-archive; but it can't be removed from stable releases
[13:06] <mlankhorst> ok
[14:46] <alkisg> bdrung: hi, sorry for the ping, should we wait for an updated adblock-plus package from lp:mozillateam? The current version conflicts with thunderbird 17...
[14:50] <alkisg> (unrelated) btw, upgrading skype on precise is broken, the new "skype-bin" wants to uninstall the old "skype" package, not upgrade it...
[14:52] <xnox> alkisg: was the previous skype installed from skype.com or from the archive?
[14:52] <alkisg> xnox: from the archive (using software center)
[14:52] <alkisg> skype and skype-bin, versions: 4.0.0.8-0oneiric1
[14:53] <alkisg> (oneiric even though I'm using precise)
[14:53] <xnox> alkisg: is adblock-plus simply disabled in thunderbird, or it is preventing to upgrade to thunderbird?
[14:53] <alkisg> xnox: upgrading thunderbird prompts for removing the adblock package
[14:53] <alkisg> So update-manager says a "partial update is available"
[14:54] <xnox> *sigh*
[14:54] <alkisg> I purged skype and skype-bin. I tried installing skype, it says that it depends on skype-bin but that won't be installed
[14:55] <alkisg> I installed skype-bin only, seems to work...
[14:55] <xnox> alkisg: are you on amd64 or i386 architecture?
[14:55] <alkisg> i386
[14:55] <xnox> alkisg: thank you.
[14:55] <alkisg> Thank you too
[14:55] <xnox> alkisg: I will check & try to confirm both issues. Have you filed any bugs yet by any chance?
[14:56] <alkisg> xnox: no, for neither
[14:56] <xnox> alkisg: that's ok.
[14:56] <alkisg> Thanks a lot, tell me if I should file a bug
[14:56] <xnox> cjwatson: should we be running britney for security and updates pockets? ^^^^^
[14:57] <cjwatson> Arguably but not planning on setting it up any time soon
[14:57] <cjwatson> What's that got to do with it though?  skype's in partner, not security/updates
[14:58] <cjwatson> In any case, this change appears at least somewhat deliberate - looks like it's switched to a multiarch scheme?
[14:59] <xnox> cjwatson: ack. Let me correct myself: stuff that lands in a stable release post-release via reasonable & supported paths.
[14:59] <cjwatson> bug 1081860 FWIW
[14:59] <cjwatson> (probably wrong title now)
[14:59]  * cjwatson fixes
[14:59] <xnox> cjwatson: but switching to a multiarch scheme should not break upgrade on a i386 (non-multiarch) install.
[15:00] <cjwatson> no, that's true
[15:06] <geser> xnox: see bug #1082030 for the skype issue
[15:06] <cjwatson> Yeah, looks like a busted Breaks
[15:07] <cjwatson> xnox: I can go ahead and fix this if you like
[15:07] <cjwatson> since Steve is probably gorging on turkey or will be soon
[15:08] <cjwatson> And I think I remember how to upload to partner :)
[15:08] <xnox> cjwatson: yes please. as it's a r_egression in a stable releases.
[15:08]  * xnox was not punished with such privilege yet
[15:09] <cjwatson> Hmm, that's a point, I don't think I actually have upload access to partner
[15:09] <cjwatson> Unfamiliar feeling
[15:10] <xnox> well stgraber & mvo can.
[15:12] <stgraber> yeah, I "think" I'm in the magic team that has upload access to partner, never tried it though :)
[15:12] <cjwatson> You are.  It should just be an ordinary upload with Component: partner
[15:12] <seb128> xnox, the cmake fix from this morning didn't work
[15:12] <seb128> if (GETTEXT_FOUND) works with with 2.8.9 but not 2.8.10
[15:12] <seb128> xnox, just for info
[15:13] <xnox> seb128: buildlog?
[15:13] <seb128> xnox, https://launchpadlibrarian.net/123700184/buildlog_ubuntu-raring-i386.unity_6.12.0-0ubuntu4_FAILEDTOBUILD.txt.gz
[15:13] <stgraber> cjwatson: ok, want me to take care of this then?
[15:14] <seb128> xnox, but doing cmake .. the GETTEXT_FOUND line is not printed
[15:14] <seb128> xnox, it is when using 2.8.9
[15:14] <didrocks> xnox: yeah, it's printed
[15:14] <didrocks> not*
[15:15] <xnox> seb128: didrocks: I've asked you "does this work on both?" you say yes. Even to the fact of building it in quantal & raring. Now two uploads were done that FTBFS.
[15:15] <xnox> didrocks: do you not do a clean build in pbuilder/sbuild before uploading?
[15:15] <xnox> (with raring-proposed enabled)
[15:15] <seb128> xnox, I did pbuilder on quantal, my raring build failed on a gcc/include issue
[15:15] <cjwatson> stgraber: I've attached a patch to the bug, if you'd care to sponsor it?
[15:15] <didrocks> xnox: I trusted seb128 when he told me he built it ;)
[15:16] <seb128> xnox, so yeah, unfortunate chain of events
[15:16] <stgraber> cjwatson: sure
[15:16] <didrocks> yep, because of the other failure
[15:16] <xnox> now, we see what happened here, LOL =))))))
[15:16] <didrocks> let's try to fix it first
[15:16] <didrocks> xnox: well, not the end of the world, fixing it is more important
[15:16] <xnox> anyway. Yeah, I still was not convinced that even Gettext_FOUND was set or not.
[15:17]  * xnox goes to play with cmake quickly.
[15:17]  * xnox has reverted cmake to upload ready here, just in case.
[15:17] <seb128> xnox, seems it's not
[15:17] <seb128> if (Gettext_FOUND)
[15:17] <seb128>         message(STATUS GETTEXT_FOUND = ${GETTEXT_FOUND})
[15:17] <seb128> -> no message printed
[15:20] <_val_> Hi there. Is anyone working on vdsm for ubuntu? Just out of curiousity.
[15:25] <didrocks> ok, opensuse has a patch
[15:25] <slangasek> cjwatson: so what's the fix you're applying to skype?  I'm thinking we should just use ${binary:Version} going forward
[15:25] <didrocks> and it works
[15:25] <didrocks> but full of black magic
[15:25] <xnox> didrocks: link?
[15:25] <didrocks> http://www.mail-archive.com/opensuse-commit@opensuse.org/msg28785.html
[15:25] <didrocks> they remove the additional set
[15:25] <didrocks> something else already set it right it seems
[15:25] <didrocks> in cmake
[15:26] <xnox> 8-/
[15:27] <xnox> didrocks: that works.
[15:27] <didrocks> xnox: grepping in the cmake module dir only show that one
[15:27] <didrocks> yeah, I confirm
[15:28] <didrocks> even if we don't really know what set it
[15:28] <didrocks> I wouls propose uploading cmake with that patch
[15:28] <didrocks> and give back the unity build
[15:29] <xnox> ack.
[15:29] <xnox> autopkgtest for GETTEXT_FOUND?
[15:29]  * xnox so does not want to see this happening again, when cmake is fixed.
[15:29] <xnox> or "not fixed upstream, yet again"
[15:29] <didrocks> xnox: I'm adding that to my Friday TODO, would be a nice little hack on Friday afternoon :)
[15:30] <didrocks> works for you?
[15:30] <xnox> didrocks: sure. Well I remember people talking about a unity "needs-build" autopkgtest.
[15:30] <xnox> that way if _any_ of unity's reverse build-deps change we will notice the failure.
[15:30] <didrocks> xnox: hum? we won't have autopkgtest in unity
[15:30] <cjwatson> slangasek: patch in bug 1082030 - I felt that since it was broken I should just apply the minimally correct fix
[15:31] <slangasek> cjwatson: ok
[15:31] <didrocks> xnox: we have an "autopilot" step in the ppa before copying to distro
[15:31] <didrocks> xnox: but the unity integration tests need bare metal, which doesn't work with the current autopkgtest infra
[15:31] <xnox> didrocks: i know. It's not a full/real smoke tests, just an in-archive single test.
[15:31] <cjwatson> slangasek: if you fancy reviewing it in the queue, I'll copy it everywhere relevant once I can
[15:31] <didrocks> xnox: if you have doc on that, I'm interested ;)
[15:32] <cjwatson> didrocks: It'd still be enough to catch the bug and prevent it migrating from -proposed (once we finish that)
[15:32] <didrocks> not really up to date with that infra and the reverse-dep building, just hear about the theory
[15:32] <_val_> Hi there again.
[15:32] <xnox> didrocks: which simply does a test build. Such that when gcc/boost/cmake/etc change, it is noticed =)
[15:32] <didrocks> cjwatson: it's what jibel is currently (I mean, *today*) finishing right?
[15:32] <cjwatson> didrocks: well, it needs work on my side too
[15:32] <_val_> Hi there. Is anyone working on vdsm for ubuntu? Just out of curiousity.
[15:32] <didrocks> cjwatson: how does it work? the package just need one autopkgtest?
[15:32] <slangasek> cjwatson: trying, but seeming to have network issues getting to the queue
[15:32] <cjwatson> didrocks: basically: it's in your interest to provide autopkgtest metadata even if it's incomplete, because it allows you to enforce constraints on your dependencies
[15:33] <xnox> didrocks: yeah, in unity. that does nothing, but has "needs-build" requirement ;-)
[15:33] <cjwatson> it could do something if you had some subset of tests that were worth running
[15:33] <didrocks> wiki page would be appreciated :)
[15:33] <cjwatson> I realise you can't run them al
[15:33] <cjwatson> l
[15:33] <didrocks> cjwatson: all is autopilot, the rest is run during build :/
[15:33] <xnox> didrocks: that way, we would have noticed this breakage at the time cmake was uploaded.
[15:33] <cjwatson> didrocks: we haven't implemented it yet, so it's a little unreasonable to want user documentation :P
[15:33] <didrocks> but I can just ship a dummy test to trigger that
[15:33] <didrocks> cjwatson: heh, ok, so once here, I'll do it :)
[15:34]  * xnox will do merge proposal with that test against unity, but first let me upload this cmake thing.
[15:34] <didrocks> xnox: ah, you are doing it? so you win the autopkgtest I guess :p
[15:38] <xnox> didrocks: yes, yes.
[15:47] <AbsintheSyringe> when will kernel 3.6 get into quantal?
[15:51] <xnox> AbsintheSyringe: maybe ask in #ubuntu-kernel
[15:51] <AbsintheSyringe> xnox, will do, tnx
[17:44] <cjwatson> right, the busted skype dependencies are all fixed now
[19:00] <xnox> seb128: didrocks: fixed cmake is uploaded & unity builds retried (2 succeeded, 2 building). I am EOD.
[19:39] <seb128> xnox, thanks
[20:28] <bitshuffler> Good evening. Question regarding debian packaging: Is the package name & its version somehow available in a post install script? (reasoning is I would like to have a post install script I don't have to touch when e.g. the version increases which is required somewhere in the script) With .rpm it is easily available within the .spec but I'm kinda lost how that is done with .debs.
[20:30] <infinity> bitshuffler: The postinst isn't called with the current version as an argument, but since your source package knows its version, it's trivial to substitute it into your postinst at build time.
[20:31] <bitshuffler> infinity: are there some helpers for substitution or do I have to use e.g. sed?
[20:38] <infinity> bitshuffler: sed seems to be the most common go-to for this sort of thing.
[20:38] <infinity> bitshuffler: Though, I will say that most of the times I think I might need to know my version in a maintainer script, I think about it and realise I'm wrong.
[20:38] <infinity> bitshuffler: What's the actual problem and intended solution here?
[20:39] <bitshuffler> infinity: thanks for the pointer :) Coming from rpm packaging I sometimes wonder why .deb packaging is that uncomfy … ;D
[20:40] <bitshuffler> infinity: in that case I need multiple sun jdk versions installable in parallel (managed via update alternatives) so one can install a specific version or multiple (in case of jenkins)
[20:40] <bitshuffler> so I need the version to get the update-alternatives in post install working
[20:41] <infinity> But surely, that's not the package version, just the upstream version?
[20:41] <bitshuffler> best guess is some bash scripting by getting the version via ls
[20:41] <tumbleweed> and if they're co-installable, it's in the packgae name somewhere
[20:41] <bitshuffler> infinity: package names would differ for versions and all provide a common $jdk
[20:42] <bitshuffler> and is the package name somehow available in a post install script?
[20:42] <infinity> Yeah, it is.
[20:42] <bitshuffler> awesome, how?
[20:42] <tumbleweed> $0?
[20:43] <bitshuffler> heh, really?
[20:43] <bitshuffler> are there more arguments available or is there some doc on that somewhere?
[20:43] <infinity> $0 isn't actually the package name, to be fair. :P
[20:43] <bitshuffler> well what is it then?
[20:43] <infinity> $DPKG_MAINTSCRIPT_PACKAGE is, however.
[20:44]  * tumbleweed didn't know that
[20:44] <infinity> $0 is the name of the postinst script, which would be $package.postinst, but isn't guaranteed to be, as that's a dpkg-internal thing.
[20:44] <infinity> So, don't do that. :P
[20:48] <bitshuffler> infinity: do you have some link to docs re what variables are available and what their meaning is? I'm unable to find any info on that.
[20:48] <tumbleweed> bitshuffler: dpkg manpage
[20:48] <bitshuffler> tumbleweed: thanks :)
[20:49]  * bitshuffler goes and boots some .deb vm
[20:49] <tumbleweed> I see non-zero packages on my system using $0 to find the pcakage name, but fortunately most of them are only using it to display helpful error messages
[20:50] <infinity> tumbleweed: gcc is a classic offender here.  I should probably give a patch to doko.
[20:50] <infinity> tumbleweed: Most cases of $0 in maintainer scripts are false positives, as it's actually being used to reference the maintainer script, not the package.
[20:51] <tumbleweed> or it an awk's $0 or something
[20:51] <infinity> (ie: echo "$0: called with unknown arguments")
[20:51] <tumbleweed> yeah
[20:52] <infinity> DPKG_MAINTSCRIPT_PACKAGE was a reasonably recent addition, to be fair, but even before that, the only sane way to know a package name in a script was to subst it in during the build.
[20:52] <infinity> So, the cleverness I see in gcc and checkbox maintainer scripts should likely die. :P
[21:07] <bitshuffler> hm, didn't find anything how dbpkg would be helpful in my case. So the most 'sane' way would be to get $package_name & $version from control file during packaging and generate post install files from there, correct?
[21:09] <tumbleweed> you don't need the version, do you?
[21:10] <bitshuffler> I do. How would I otherwise specify the correct version/priority for update-alternatives in my post install script?
[21:11] <bitshuffler> what I want to achieve is to have one place I maintain that version and the rest gets it automagically somehow if needed
[21:11] <tumbleweed> only one version of a package can be installed at a time, so you need the version to be in the packgae name
[21:11] <bitshuffler> otherwise I'll just forget it somewhere sometimes and have a mess ...
[21:12] <tumbleweed> (the upstream version, that is, you certainly don't need the package version for an alternatives priority)
[21:12] <bitshuffler> tumbleweed: the package name differs as well. But all those provide a virtual package - e.g. 'jdk7' so I can easily the newest and get updates if I don't care about a specific one
[21:13] <bitshuffler> so I have like sun-jdk-1702-1.7.02 and sun-jdk-1703-1.7.03 and so on
[21:13] <bitshuffler> sounds kinda insane but the only viable solution I found yet ;D
[21:13] <tumbleweed> right, so just extract the upstream version from that
[21:14] <bitshuffler> that is the control file like suggested above or how do I get the package name during post install if I shouldn't rely on $0?
[21:15] <tumbleweed> as infinity said, $DPKG_MAINTSCRIPT_PACKAGE
[21:15] <infinity> DPKG_MAINTSCRIPT_PACKAGE
[21:15] <infinity> But there's nothing wrong with substing values in at build time either.
[21:16] <infinity> I have to say that, since I maintain a package that does that several hundred times per build. :P
[21:17] <bitshuffler> heh, I guess I was dense regarding $DBPKG_…, googled for it and read the scripts docs :D
[21:18] <bitshuffler> Thanks a lot for your help. Am happy to do as suggested just had hoped there would be a better way (like e.g. that script getting called with arguments or …)
[21:24] <infinity> bitshuffler: DPKG, not DBPKG
[21:25] <bitshuffler> infinity: yes, mistyped but read the right one
[22:18] <cjwatson> bitshuffler: environment variables are better for this anyway - they're named rather than positional, which is generally more conveniently extensible
[22:20] <bitshuffler> cjwatson: well, agreed, problem just is from where to get that env variable?
[22:21] <cjwatson> bitshuffler: um
[22:21] <cjwatson> bitshuffler: it's right there in your environment when the postinst is called
[22:23] <bitshuffler> cjwatson: awesome, what's the variables name and from where does it get set?
[22:24] <cjwatson> bitshuffler: the variable's name is DPKG_MAINTSCRIPT_PACKAGE, as per the above conversation.
[22:24] <cjwatson> bitshuffler: It's set by dpkg, the package manager.
[22:26] <bitshuffler> oh dear :D Sorry, I didn't try it yet, thought it contains just the package name
[22:27] <cjwatson> It does
[22:27] <bitshuffler> well, but I guess now the version as well ;D
[22:28] <cjwatson> No, you don't
[22:28] <cjwatson> You need the upstream version which you have embedded in the package name, ib the scheme you described
[22:28] <cjwatson> You do not need the package version
[22:28] <cjwatson> *in
[22:29] <bitshuffler> ah, now, yes, that is how I now planned to do it. Thanks again :)
[22:36] <infinity> bitshuffler: The only caveat in parsing DPKG_MAINTSCRIPT_PACKAGE is that, if your package is in any way multi-arched, under certain circumsances, DPKG_MAINTSCRIPT_PACKAGE might contain "package:arch", so you'll need to strip off ":.*" from the end of the string before playing with it.
[22:36] <bitshuffler> infinity: thanks :)
[22:38] <infinity> Something like "package=${DPKG_MAINTSCRIPT_PACKAGE%:*}" should do nicely.
[22:40] <doko> infinity, ?
[22:40] <doko> where is $0 used?
[22:41] <infinity> doko: gcc-defaults.
[22:41] <infinity> doko: pkg=`basename $0 .postinst`
[22:41] <infinity> doko: From gcc.postinst
[22:42] <infinity> doko: And g++
[22:43] <doko> $ svn log debian/gcc.postinst.in
[22:43] <doko> ------------------------------------------------------------------------
[22:43] <doko> r1591 | doko | 2006-10-07 15:17:50 +0200 (Sa, 07. Okt 2006) | 2 Zeilen
[22:43] <doko> - catchup commit 1.42 - 1.46
[22:43] <doko> ------------------------------------------------------------------------
[22:44] <doko> you didn't notice for at least six years ...
[22:44] <infinity> doko: Nope, I didn't grep until just now during this discussion. :)
[22:45] <infinity> doko: If that code is six years old, probably better to just remove it than fix it.  I'd assume the transition it's fixing is long over in oldstable.
[22:47] <doko> yes, can do this
[23:16] <doko> jdstrand, ping
[23:17] <doko> jdstrand, unping
[23:36] <bawf> I'm having trouble building gnome-system-monitor