[00:06] <SpamapS> jdstrand: for the dh_apparmor bugs .. to make packages easier to no-change backport, can one | debhelper (<< 9.20120115ubuntu3) ?
[00:08] <infinity> SpamapS: Don't see why not.
[00:09] <ScottK> Just don't try it in Debian.
[00:10] <SpamapS> ScottK: in Debian I'm thinking the packaging needs some revisiting so we can get in sync w/ Ubuntu.
[00:10] <SpamapS> Hrm.. gcc-4.5 wasn't in lucid .. I wonder if I should just punt the no-change idea.
[00:10] <ScottK> OK.  I don't know your specifics, but alternate build-depends aren't supported on Debian.
[00:13] <jdstrand> SpamapS: I don't see any problems with that. makes syncing with Debian harder as mentioned
[00:13] <SpamapS> jdstrand: yeah I just found 3 other things that make it hard to build w/o changes on lucid.. not really worried about any of the others so I'm dropping the idea. ;)
[00:14] <jdstrand> heh
[00:40] <Laney> iulian: I don't know. I've tried a few patches but it's just fail after fail, and the builds take about 10 hours.
[00:42] <bdmurray> slangasek: what do you think about bug 226780? should it be won't fix or fixed?
[00:47] <slangasek> bdmurray: I think it should be fixed
[00:48] <bdmurray> slangasek: okay, the fix should really be in apt-key though not the cronjob like in the patch. correct?
[00:49] <slangasek> bdmurray: ah, hadn't looked at the patch... yes, I think apt-key itself should respect the setting
[00:49] <slangasek> bdmurray: apt-key is a shell script that already calls apt-config for lots of settings, it should pick the proxy out as well
[00:55] <lcc> I'm getting occasional kernel panics with 12.04. I've never had any kernel panics with 11.10.
[00:57] <SpamapS> lcc: you may want to join #ubuntu+1 , as that is frequented by quite a few beta testers
[00:57] <SpamapS> lcc: while this channel is just for discussion fo development itself
[00:57] <lcc> oh ok
[02:16] <smoser> slangasek, you around ?
[02:16] <smoser> you able to take a quick sniff of bug 948461
[03:02] <lerop> anyone willing to write me a fully selinux script for 11.10 it can be python if thats easier and be willing to do it for $25
[03:02] <lerop> as selinux as can be
[03:08] <ScottK> Heh.
[03:08] <ScottK> For $25 I'd type #!/usr/bin/python.
[03:09] <StevenK> zsh: no such file or directory: /usr/bin/python.
[03:09] <StevenK> :-P
[03:09]  * ScottK didn't say it'd do anything.
[03:10] <StevenK> You also didn't say where you'd type it
[03:10] <ScottK> That too.
[03:10] <ScottK> But what to you expect for $25.
[03:11] <ScottK> (even US or Canadian, he may have meant Australian)
[03:11] <lerop> i can type that with my pinky toe
[03:12] <elky> My pinkie toe can send you an artistic interpretation of a selinux script for $25. I take non-refundable payment in advance.
[03:18] <Gaming4JC> I don't suppose any nice developer could get this moving along? :)
[03:18] <Gaming4JC> https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/821100/
[03:18] <Gaming4JC> I really need ia32libs with libGL on natty for a project I'm working on
[03:18] <Gaming4JC> and sadly it doesn't exist :/
[03:38] <slangasek> smoser: I'm entirely failing to understand the thesis statement of this bug
[03:39] <slangasek> smoser: the claim is that *apt* is saving the files to the wrong filenames after downloading them?  I have a hard time believing that's been happening since hardy and someone's just noticed it now
[03:40] <smoser> i have your same thoughts.
[03:40] <smoser> you do understand the thesis statement.
[03:40] <slangasek> hmm
[03:40] <smoser> http://paste.ubuntu.com/872478/
[03:40] <smoser> that kind of shows the failure.
[03:41] <smoser> (and i just updated the bug with a comment)
[03:41] <smoser> note, in that pastebin at the end, i download the libpolkit-agent-1-0_0.104-1_amd64.deb via wget
[03:41] <smoser> and md5sum it
[03:41] <smoser> in the wget output, the md5sum matches that of the 'apt-get' download of libxcb-util0_0.3.8-2_amd64.deb
[03:42] <smoser> slangasek, so i'm trying to reproduce with more traditional mirrors.
[03:42] <smoser> but believing that S3 is serving incorrect file content, is only moderately more difficult than to believe that apt is $*#@ing up itself.
[03:42] <smoser> as both are involved in huge amounts of gets per day
[03:43]  * slangasek nods
[03:43] <slangasek> so wget returns the correct file where apt-get returns the wrong one/
[03:43] <lifeless> one thing that can look the same
[03:43] <lifeless> is truncated content
[03:44] <lifeless> if you have a non-TE stream and no content-length header, HTTP cannot tell the difference between internet fail and EOF
[03:44] <slangasek> lifeless: this doesn't appear to be a case of truncation; the objects are just plain swapped on the filesystem after download
[03:45] <slangasek> clean md5sum... belonging to the wrong file
[03:45] <lifeless> kk
[03:45] <lifeless> was just putting it out there :)
[03:46] <slangasek> smoser: is it reproducible with a single package download (e.g., apt-get install thing-with-no-depends)?  or does it only go wrong when downloading multiple files with the same http process?
[03:47] <smoser> lifeless, its not truncated content.
[03:47] <smoser> dpkg -I shows info on the deb downloaded
[03:47] <smoser> slangasek, i'm going to test now, just runnig wget in a loop
[03:47] <smoser> on that file that had bad content
[03:47] <smoser> and wget ... checksum ... wget ...
[03:47] <smoser> see if i can take apt out completely
[03:55] <slangasek> smoser: see if it's reproducible with Acquire::http::Pipeline-Depth=0
[03:55] <slangasek> (cf. apt.conf(5))
[03:56] <smoser> slangasek, k. let me test this wget in a loop for a while first.
[03:59] <psusi> lifeless, huh?  connection failure will result in a connection reset, not a clean close...
[04:00] <lifeless> psusi: and yes wget curl etc all have displayed this in the past
[04:01] <psusi> lifeless, you mean they return a zero exit status when they get a connection reset instead of eof?
[04:01] <psusi> I could have sworn that wget was smart enough to detect that and try to reconnect and resume the download...
[04:08] <lifeless> psusi: it may be nowadays, my HTTP mental model is a melange of 16 years encounters ;)
[04:12] <smoser> slangasek, so.. some info.
[04:12] <smoser>  http://paste.ubuntu.com/872513/
[04:12] <smoser> doesn't seem to fail. (just repeated wget).
[04:13] <smoser>  http://paste.ubuntu.com/872514/
[04:13] <smoser> doesnt seem to fail (it has your Pipeline-Depth)
[04:13] <smoser> but a simple removing of that Pipeline-Depth seems to give failure.
[04:30] <lifeless> http pipelining ? Terrible idea :(. (poorly supported, and a microoptimisation that encourages serious security issues and bugs)
[04:30] <lifeless> channels are much better, which spdy and AFAICT all the other HTTP 2.x candidates offer
[04:30] <smoser> and apparently default behavior in apt
[04:30] <smoser> :)
[04:30] <lifeless> smoser: I argued against this on debian-devel.
[04:30] <smoser> lifeless, then i blame you
[04:30] <lifeless> Apparently upstream cache developers don't know enough.
[04:30] <smoser> for not winning that argument
[04:30] <smoser> :)
[04:32] <smoser> http://kb.cloudopt.com/index.php/Known_Problem:_HTTP_Pipelining_Fails_with_BucketExplorer
[04:33] <smoser> well this royally sucks.
[04:34] <lifeless> http://old.nabble.com/APT-do-not-work-with-Squid-as-a-proxy-because-of-pipelining-default-td28579596.html
[04:44] <smoser> lifeless, thanks.
[04:44] <smoser> i'm headed to bed, but anyones thoughts (slangasek) on what we could do about this issue would be greatly apprecited.
[04:45] <smoser> ie, we want to put these S3 mirrrors in place , and this would block that.
[04:45] <smoser> and this default seems present back to hardy
[05:29] <TheMuso> Is it just me, or is firefox segfaulting on startup after latest updates?
[05:47] <pitti> Good morning
[06:27] <scientes> what does the ubuntu live-cd installer use to make a new partition label?
[06:28] <SpamapS> probably gparted, but I'm just guessing
[06:28] <scientes> you mean parted
[06:28] <scientes> which gparted is a front-end to
[06:29] <scientes> cause if you have a iso9660 live cd on the sd card, and then try partitioning it, grub-install fails cause it still detects the iso9660 file system even though there is a msdos partition table
[06:29] <scientes> so i am about to write the patch that zeros out the rest of the header in the msdos partition lable
[06:30] <scientes> if it detects a iso9660 image already there
[06:30] <scientes> instead of just writing the bare minimum
[06:30] <scientes> there is a small gap that grub is using that i guss isn't zeroed
[07:27] <ritz> Is it possible to locally build a package for oneiric from bzr branch on precise, using buildeb plugin ?
[07:28] <micahg> ritz: with sbuild or pbuilder, sure
[07:28]  * ritz checks sbuild 
[08:06] <dholbach> good morning
[08:37] <rickspencer3> hey pitti, close to a beer this morning!
[08:38] <pitti> not sure what's wrong with the meta-kde packages
[08:39] <micahg> pitti: kde4libs was uploaded w/out the rest of the stack
[08:40] <micahg> oh, rather, meta-kde was uploaded without the rest of the stack save kde4libs :)
[08:43] <rickspencer3> pitti, micahg well, it looks like the rest of the archives, including armhf are in good shape now for multiple days in a row
[08:43] <rickspencer3> this has to be a good thing for developers
[08:43] <pitti> yes, indeed
[08:43] <rickspencer3> :)
[09:42] <seb128> slangasek, hey
[09:42] <seb128> slangasek, did you get anywhere with that gconf upgrade bug?
[09:42] <seb128> it's flooding my bug emails box :p
[09:46] <tjaalton> i synced a package with syncpackage, but it's not processed yet unlike the other upload I just did
[09:46] <tjaalton> is the process different there?
[09:52] <pitti> tjaalton: it's source NEW, and thus in https://launchpad.net/ubuntu/precise/+queue?queue_state=0
[09:53] <tjaalton> pitti: oh right, it got split from arduino..
[09:53] <tjaalton> @pilot in
[09:55]  * dholbach hugs tjaalton and sconklin
[09:58] <sladen> who synced 'tzdata' ~3 hours ago?
[09:58] <micahg> sladen: pitti did, why?
[09:58] <sladen> pitti: it appears to be resetting the timezone on package install
[09:59] <pitti> reset how?
[09:59] <pitti> works fine here
[09:59] <pitti> $ cat /etc/timezone
[09:59] <pitti> Europe/Berlin
[09:59] <sladen> $ cat /etc/timezone
[09:59] <sladen> Africa/Bamako
[09:59] <sladen> filed as bug #948809
[10:00] <sladen> whether that's because Europe/London is sometimes the same as UTC
[10:01] <pitti> slangasek: could you please add the output of "grep -A3 '^Name:.*tzdata' /var/cache/debconf/config.dat" ?
[10:01] <pitti> argh, sladen ^
[10:01] <pitti> slangasek: please ignore me
[10:03] <micahg> tjaalton: seamonkey-browser is now a transitional package, can you fix your upload to enhance seamonkey?
[10:03] <sladen> pitti: added.  The two interesting Value: lines are "Berlin" and "UTC"
[10:03] <tjaalton> micahg: sure
[10:03] <pitti> there's no packaging change in latest tzdata, so it must be a bug that's lurking for ages already
[10:04] <sladen> yikes. it's changed it in indicator-timedate too
[10:04] <pitti> slangasek: no "london" at all, hmm
[10:04] <pitti> sladen: I take it you don't know what /etc/timezone said before the upgrade
[10:05] <sladen> pitti: would have been 'Europe/London'
[10:05] <sladen> pitti: would it be worth patching the package in the short term to at least dump the previous value, before the logic takes place
[10:06] <pitti> we could, but here we are pretty sure about the previous value
[10:12] <micahg> tjaalton: thanks
[10:14] <tjaalton> anyone opposed to the change proposed here https://code.launchpad.net/~blkperl/ubuntu/precise/plymouth/fix_blank_screen/+merge/95817
[10:14] <tjaalton> it's true that on servers you get a blank screen on startup
[10:16] <tjaalton> tested that it works
[10:20] <tjaalton> huh, not a single plymouth upload in precise
[10:20] <tjaalton> guess it's stable then ;)
[10:20] <seb128> tjaalton, you know how it goes: "you upload it, you maintain it"
[10:21] <seb128> tjaalton, nobody wants to maintain it ;-)
[10:21] <RAOF> Broken on hybrid graphics in some circumstances, sadly.
[10:21] <tjaalton> seb128: yeah, I'll just ack the change then :)
[10:49] <tjaalton> uh, cryptsetup is 1,5y old
[10:50] <tjaalton> last merge in november 2010
[11:30] <dupondje> tjaalton: indeed, thats why I prepared a merge for it
[11:30] <dupondje> :)
[11:31] <Daviey> infinity: Are you going to be looking at bug 759545?
[11:35] <Daviey> cjwatson: noticed biosdevname bugs starting to appear, bug 948559 and bug 948546, for example
[11:37] <jodh> Any French speakers interested in taking a look at bug 948884? rickspencer3 ? ;)
[11:37] <tjaalton> dupondje: yeah, acked, hopefully accepted too..
[11:37] <dupondje> lets hope so :)
[11:37] <dupondje> there is also TRIM support in the new version
[11:41] <cjwatson> Daviey: thanks
[11:46] <roignac_> hi all! I'm trying to propose a merge for lp:~ubuntu-desktop/nautilus/debian
[11:46] <roignac_> but lp keeps switching me to lp:nautilus
[11:46] <roignac_> is there any way to avoid this redirect?
[11:47] <roignac_> Or should I abandon all hope and send patches instead of branches?
[11:47] <dupondje> tjaalton: who could push it ? :)
[11:47] <seb128> roignac_, hey, how do you propose the merge? did you branch of lp:~ubuntu-desktop/nautilus/debian ?
[11:48] <seb128> roignac_, it should use the parent branch...
[11:48] <tjaalton> dupondje: someone of the release team needs to ack it
[11:49] <roignac_> seb128: I branched lp:~ubuntu-desktop/nautilus/ubuntu
[11:49] <seb128> roignac_, on https://code.launchpad.net/~roignac/ubuntu/precise/nautilus/bug_32542_save_search_as_button/+register-merge
[11:49] <seb128> roignac_, select other and type ~ubuntu-desktop/nautilus/ubuntu
[11:49] <seb128> that should work?
[11:50] <roignac_> seb128: target branch is specified as lp:ubuntu/nautilus =/
[11:50] <seb128> roignac_, right, but you can pick "other" and type ~ubuntu-desktop/nautilus/ubuntu no?
[11:51] <roignac_> seb128: i tried this, but LP keeps redirecting to lp:nautilus
[11:51] <seb128> roignac_, ask on #launchpad I guess
[11:51] <roignac_> ok, thanks
[12:00] <roignac_> seb128: thanks, #launchpad guys did help
[12:00] <seb128> roignac_, what was the issue?
[12:01] <roignac_> Though they also wondered why does ~ubuntu-desktop uses lp:~ubuntu-desktop/nautilus, but not lp:~ubuntu-desktop/ubuntu/nautilus branches for packaging
[12:01] <dupondje> cjwatson: could you check https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/776264 for me ? :)
[12:01] <roignac_> seb128: I've created a branch in /ubuntu (following the tutorial), but the destination branch was in /nautilus
[12:02] <seb128> seems like a launchpad bug
[12:02] <seb128> it shouldn't stop on namespace and let you overwrite the destination
[12:04] <roignac_> nope, this is a little problem with packaging branch. If a newbie like me strictly follows tutorial at Bugs/HowToFix one will branch lp:ubuntu/nautilus
[12:05] <roignac_> sorry, will branch ~ubuntu-desktop branch and will push it to lp:~username/ubuntu/nautilus
[12:05] <cjwatson> dupondje: I'd rather not, I don't know cryptsetup at all well
[12:05] <dupondje> ok no problem
[12:05] <roignac_> seb128: so he won't be able to merge with lp:~ubuntu/nautilus
[12:06] <roignac_> sorry for spam, everybody
[12:06] <seb128> roignac_, sorry that the workflow is not consistent
[12:06] <seb128> roignac_, we don't use the udd way for desktop for several reasons
[12:06] <seb128> roignac_, that's part of the issue
[12:07] <roignac_> I see, so attaching patches is easier and much safer
[12:14] <dupondje> maby we should add 'last time merged (days ago)' to the MoM? Cause I guess some more packages are really out-of-date
[12:15] <cjwatson> https://bugs.launchpad.net/merge-o-matic/+bug/881487
[12:15] <dupondje> hehe :D
[12:25] <cjwatson> Daviey: OK, fixed both of those now
[12:31] <Daviey> cjwatson: Oh, i wasn't prodding you to fix them!  Just a FYI
[12:46] <ritz> gtk+3.0 build fails from source on precise, with ./.libs/libgtk-3.so: undefined reference to `ubuntu_menu_proxy_insert'
[12:46] <ritz> https://pastebin.canonical.com/61799/
[12:46] <ritz> what am I missing here ?
[12:51] <seb128> ritz, no it doesn't
[12:52] <ritz> seb128, hmmm, the is a bzr branch  lp:ubuntu/gtk+3.0, over which I ran configure with the stated option
[12:52] <seb128> ritz, what version did you try to build and how?
[12:52] <seb128> ritz, did you apply the patches in debian/patches?
[12:53] <ritz> I did nothing, just branch and ran configure
[12:53] <seb128> ritz, those are packaging branches, they are made to build packages not to be built like a trunk
[12:54] <seb128> i.e debian/rules has usually the correct recipies to build
[12:54] <seb128> which include i.e applying the distro patches
[12:54] <infinity> Daviey: Yes.  I think I'll look harder at it today.
[12:54] <ritz> interesting, was not aware of this
[12:54] <seb128> ritz, well you can of course build it like a trunk, you just need to figure what the packaging is doing and you are not, could be that forgot to apply patches or forgot ldflags or build options
[12:56] <ritz> cool, thanks
[12:59] <sconklin> @pilot out
[13:00] <ritz> seb128,  where does ubuntu store "trunk" , or ubuntu requires patches for most packages ( like gtk/indicator) ?
[13:00] <seb128> ritz, define trunk
[13:00] <seb128> ritz, the packacing is usually upstream trunk with build rules and distro patches
[13:00] <seb128> well upstream "trunk" -> "tarballs"
[13:01] <ritz> hmmm, fair enough
[13:01] <ritz> so, debian/rules will enable the ubuntu specific build/patches
[13:06] <ritz> seb128, Thanks, build fine now
[13:06] <ritz> me--
[13:06] <infinity> ritz: Yes.  In general, something like "debuild -b" will give you what you want.
[13:09] <Daviey> infinity: thanks!
[13:09] <ritz> hmm, interesting.
[13:10] <ritz> infinity, thanks :)
[13:41] <Q-FUNK> would anyone happen to know where the keyring password for ubuntu-dev-tools e.g. synpackage is stored? I would need to change it.
[13:47] <infinity> Q-FUNK: https://launchpad.net/people/+me/+oauth-tokens
[13:47] <infinity> Q-FUNK: And revoke?
[13:49] <Q-FUNK> infinity: I meant that password that is asked in the shell whenever I run 'syncpackage'
[13:49] <infinity> Oh.  I don't think I've ever been asked for a password...
[13:51] <Q-FUNK> not the access rights granted to applications to play with LP on my behalf :)
[13:52] <infinity> It doesn't need any other passwords... Except possibly GPG passphrases for --no-lp use.
[13:52] <pitti> Riddell: do you know what changed yesterday to cause http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html ?
[13:53] <ScottK> pitti: Without looking, I'll guess we started uploading KDE 4.8.1.
[13:53] <Q-FUNK> infinity: here, it asks for a password
[13:53] <infinity> Sure looks that way.
[13:53] <geser> Q-FUNK: if you're running GNOME then it's in your gnome keyring (similar if you use KDE)
[13:53] <ScottK> pitti: That's it.  It should get sorted today.
[13:54] <Q-FUNK> geser: stored under which key name?
[13:54] <pitti> ScottK: thahnks
[13:55] <pitti> ScottK: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt now has a large armada of stuff that wants to go to universe; are these really all obsolete, or is that just temporary?
[13:56] <infinity> pitti: Probably worth completely ignoring archive reports about anything vaguely KDE-related until the transition's done.  It's always bumpy. :/
[13:56] <pitti> ack
[13:56] <ScottK> pitti: I'd be very surprised if it's not temporary.
[13:57] <geser> Q-FUNK: good question, never had to look it up yet how in detail python-launchpadlib stores the password; perhaps ask in #launchpad
[14:04] <tjaalton> are cross-architecture depends/recommends allowed yet?
[14:16] <infinity> tjaalton: Only if it's never going to happen on a buildd.
[14:17] <dupondje> pitti: about cryptsetup merge, how you want to test it exactly? root disk completely encrypted with LUKS or ?
[14:17] <infinity> tjaalton: See, eg: ia32-libs (on amd64), which depends on ia32-libs-multiarch (which only exists on i386)
[14:17] <pitti> dupondje: yes, something like that; the alternate install supports this schema
[14:17] <dupondje> so just a precise daily install and then upgrade
[14:17] <dupondje> i'll fix :D
[14:18] <pitti> dupondje: usually it's raw disk <- cryptsetup partion <- LVM <- root/home etc.; and then a separate /boot
[14:18] <infinity> tjaalton: Buildds, however, are intentionally not multiarch-aware, to keep the architectures self-contained, so no pulling of such tricks on anything that might be a build-dep of.. Anything.
[14:18] <ScottK> stgraber: What would be an example of a social membership that the DMB would process?
[14:18] <pitti> dupondje: thanks, much appreciated!
[14:19] <tjaalton> infinity: right, this is for !buildd
[14:20] <infinity> tjaalton: Then yeah, it can be done, and we've been doing it since oneiric (see the above example)
[14:20] <infinity> tjaalton: flashplugin-nonfree works similarly.
[14:20] <stgraber> ScottK: an existing coredev who isn't a direct member of MOTU and who's been spending a lot of time helping people in #ubuntu-motu or helped with universe QA or similar activities and who wants to be a MOTU has they feel they're part of that effort (vs just wanting the upload rights that they already have anyway)
[14:20] <tjaalton> infinity: right, of course. just double-checking :)
[14:21] <ScottK> stgraber: OK.  That makes complete sense.  It wasn't so clear from the wiki entry.  You might add an example ...
[14:21] <ScottK> Thanks.
[14:22] <infinity> tjaalton: There are upgrade concerns to watch for.  flashplugin-nonfree and ia32-libs both introduced new-named packages to make sure that upgrades did sane things.
[14:22] <infinity> tjaalton: (As in, if you just drop the amd64 version of a package, and expect apt to magically upgrade it to i386, that might end badly for you)
[14:23] <infinity> tjaalton: In those cases, we kept the old package names in place, but made them transitional packages that depended on a new i386-only package.
[14:23] <tjaalton> infinity: hmm actually I'm thinking if it was possible for a package to declare a relationship like "Depends: foo:i386 [amd64]", but now I realize how that'd not be that useful on debian :)
[14:24] <infinity> tjaalton: That's not doable, no.
[14:24] <infinity> tjaalton: The tricks we pull are based on transitive dependency backfill, I guess is a good way to put it.  As in, we make sure the package only exists on one arch in the first place.
[14:24] <infinity> And then depend on it.
[14:25] <infinity> "Depends: foo:arch" isn't allowed.
[14:25] <infinity> (Though people pulling dirty tricks like we have might be proof that we should revisit adding foo:arch deps)
[14:25] <tjaalton> :)
[14:39] <jamespage> please could someone poke the package importer to update the rabbitmq-server branch - its a bit out of date..
[14:57] <ogra_> infinity, what did you do last time to make alsa-lib build on x86 ? it failed again with the same cryptic error
[14:57] <ogra_> ...
[14:57] <ogra_> checking whether we are cross compiling... configure: error: in `/build/buildd/alsa-lib-1.0.25/bibuild':
[14:57] <ogra_> configure: error: cannot run C compiled programs.
[14:57] <ogra_> ...
[15:02] <infinity> ogra_: Build it on palmer.  I'll do it.
[15:02] <ogra_> thx
[15:03] <infinity> Err, roseapple.
[15:03] <infinity> Whatever.
[15:03] <ogra_> any idea what causes it ?
[15:03] <infinity> It's running amd64 code. :/
[15:03] <ogra_> ouch, k
[15:03] <infinity> It needs merging to fix that.
[15:03] <infinity> Some day.
[15:05] <infinity> Alright, I have to head out for a bit.
[15:05] <infinity> alsa-lib building.
[15:05] <smoser> hi, i have a question about debconf usage that i'd like to get some input on.
[15:05] <smoser> cloud-init has a couple debconf things that can be seeded, and a configuration format that supports config.d type behavior.
[15:06] <smoser> i'm considering allowing a debconf preseed value of "local-config" or something that would then largely just get dropped into cloud.cfg.d/99-local
[15:06] <smoser> the reason for this is that cloud-init preseeding is likely to be done by a machine.
[15:07] <smoser> so more friendly menus or such are not necessary, but i'd like to open up a very generic window to doing this without having the pre-seeder need a late_command script or something to populate that.
[15:11] <dupondje> pitti: I installed a precise system, upgraded cryptsetup. Now I rebooted and it works fine, but I get some delay @ booting, the error: error: no video mode activated
[15:11] <dupondje> but thats unrelated I guess ?
[15:11] <pitti> doesn't sound cryptsetup-ish
[15:11] <pitti> dupondje: did you get this with the previous cryptsetup, too?
[15:12] <jcastro> cyphermox: hey so the reason I said "12.10" for the BT audio mail is I don't know enough about it to know if it was a ood idea for 12.04
[15:12] <jcastro> cyphermox: is it really that simple a fix though? I mean, there's a wireless device and audio involved, I was expecting mountains needing to be moved, etc.
[15:13] <cyphermox> jcastro: no, it's a simple two-line patch to enable this in bluez
[15:13] <jcastro> cyphermox: and the sound indicator has GUI support for this and all that?
[15:13] <cyphermox> there's still going to be the need for manual setup to reroute the streams to the right output device though
[15:14] <cyphermox> right, no it doesn't ;)
[15:14] <jcastro> oh ok, so we can at least suck less off the bat, that's good!
[15:14] <smoser> cjwatson, do you have thoughts on my debconf idea above ? or slangasek ?
[15:14] <smoser> (sorry for asking by name)
[15:15] <cyphermox> jcastro: right, this makes us suck less from the start
[15:15] <dupondje> hmz pitti Mar  7 16:09:09 ubuntu kernel: [   15.858831] init: udev-fallback-graphics main process (773) terminated with status 1
[15:15] <tjaalton> slangasek: I pushed a commit to plymouth and noticed it had two commits staged since september. mind checking if they should get in precise, and check the new one too :)
[15:16] <pitti> dupondje: is this with the current cryptsetup, or only with the updated one? if the latter, this needs to be investigated
[15:17] <dupondje> lets see if downgrade fixes it
[15:21] <dupondje> pitti: downgraded again, same issue.
[15:21] <pitti> dupondje: ok, thanks; so that confirms it's not due to that
[15:22] <cjwatson> smoser: not sure I really know cloud-init well enough to be able to comment usefully, TBH
[15:23] <smoser> well, generally, cjwatson i'm asking if it would be appropriate to have a debconf question like "local-config"
[15:23] <smoser> which woudl contain config-blob for the $GENERIC_PACKAGE
[15:23] <smoser> or if that is bad form for some reason or another
[15:24] <cjwatson> I have no idea, you'll find all sorts of examples in the archive probably :-)
[15:24] <smoser> (i assume i'm going to possibly need to be smart with new line hanling or something in the value of the string)
[15:24] <cjwatson> I don't see why late_command scripts are somehow evil though
[15:24] <cjwatson> it is explicitly not a design goal of debconf to let you configure every last possible scenario
[15:24] <cjwatson> but, if you want your package to have its own more targeted equivalent of late_command, *shrug*
[15:25] <cjwatson> just think about how it's going to handle upgrades
[15:26] <smoser> cjwatson, thank you for the feedback.
[15:27] <smoser> Daviey, ^
[15:27] <slangasek> seb128: no, no progress on gconf yet :/
[15:27] <smoser> my thought process there is, that rather than generally allowing configuration of one bit of cloud-init (for bug 924375), i'll just open up a big blob
[15:34] <Daviey> smoser: Yeah, late command of, "echo "http://foo/bar" > /etc/cloud-init.d/next-server , is pretty cheap
[15:34] <Daviey> cjwatson: debconf low, and default value should handle upgrades fine, no?
[15:35] <smoser> Daviey, right, but i see value in not requiring late_command (at least i think i do )
[15:35] <cjwatson> Daviey: it sounds like it shouldn't even be asked at all
[15:36] <cjwatson> you don't actually need to db_input things ...
[15:36] <smoser> i'm good with not even asked at all if thats possible.
[15:36] <smoser> good enough for me.
[15:36] <smoser> is there a defined escaping mechanism for debconf values ?
[15:36] <mhall119> mvo: ping (you know why)
[15:37] <smoser> (ie, to deal with '\n' or other potentially problematic things)
[15:37] <mvo> mhall119: *cough* I do! and no excuses from me this time let me look at the branch
[15:38] <cjwatson> debconf-escape(1)
[15:38] <Daviey> cjwatson: right, but i was thinking smoser might want people to be able to enter a value
[15:38] <cjwatson> I don't think that's generally the right answer for "giant blob" type things
[15:38] <cjwatson> preseed/late_command doesn't get asked
[15:39] <cjwatson> can't remember whether it would be a good idea to set the 'escape' capability in this circumstance; possibly not, but try either way :)
[15:39] <Daviey> Yes, so it really depends if smoser thinks users will want that question asked... if late_command on a debconf question is suitable
[15:39] <smoser> i dont think users would want the question asked.
[15:39] <smoser> i'm inserting it for machines.
[15:39] <Daviey> smoser: ok, then late_command is almost free :)
[15:40] <smoser> machine's whose only real interface is preseed
[15:40] <smoser> the issue with late_command is that it doesn't stack terribly easy
[15:40] <smoser> without some general infrastructure in place.
[15:41] <smoser> ie, if 3 things want to add late_command, something has to join them on ';' or something.
[15:41] <cjwatson> I don't have a problem as such with an extra specialised unasked question for this; this is totally up to packages
[15:41] <smoser> thanks, cjwatson .
[16:24] <dupondje> cjwatson: some question about grub2. Getting "error: no video mode activated", could this be caused because it tries to read fonts from /usr/share/grub/ ?
[16:24] <tjaalton> doko: icedtea-netx-common is marked arch: all, but it builds a desktop file with the path to javaws with an arch dependent path. should the binary package be made arch: any, or the desktop file moved?
[16:26] <doko> tjaalton, best to move to icedtea-netx, I'll do this for the final 1.2 packages. thanks
[16:26] <tjaalton> doko: ok, cool
[16:27] <tjaalton> also, looks like installing the package isn't enough to make the links load the app by default, instead firefox will try to "open" it which just results in an empty tab..
[16:27] <tjaalton> .jnlp links I mean
[16:30] <tjaalton> this all to get my kid to do her homework ;)
[16:30] <blackbug> Hello, I have a question regarding the screenshot application in ubuntu. Which is the default application invoked with printscreen key?
[16:31] <tjaalton> blackbug: gnome-screenshot
[16:31] <cjwatson> dupondje: yeah, known problem when using cryptsetup, will be fixed with 2.00
[16:32] <cjwatson> dupondje: best ignored for now :)
[16:32] <dupondje> 2.00 will get into precise?
[16:32] <blackbug> tjaalton: thanks, where i can find src code for it?
[16:33] <tjaalton> blackbug: apt-get source gnome-screenshot
[16:33] <dupondje> pitti: the error I got is grub2 related (tries to open files on /usr/share which is still crypted). Will you upload cryptsetup? or want me to comment the bug?
[16:33] <tjaalton> or bzr branch lp:ubuntu/gnome-screenshot
[16:33] <tjaalton> ah, that doesn't work
[16:33] <blackbug> tjaalton: thanks i needed bazaar branch.
[16:35] <ScottK> apt-get source gnome-screenshot should work too
[16:35] <blackbug> yes, "bzr branch lp:ubuntu/gnome-screenshot" isnt working..
[16:36] <tjaalton> @pilot out
[16:38] <cjwatson> dupondje: no
[16:39] <cjwatson> dupondje: waaaaaaaaaaaay too many changes
[16:39] <blackbug> a naive question: i have just started exploring ubuntu apps source code, in case I make some changes, how should i test it? should i compile/build whole code on my machine and replace install new binaries.. or any other test enviornment method or way
[16:39] <dupondje> cjwatson: héhéh :) no workaround that can be made for that issue? cause now there is some delay ... :)
[16:42] <cjwatson> dupondje: no, sorry
[16:42] <cjwatson> dupondje: at least not one I consider safe for precise
[16:42] <cjwatson> I'd rather have stable-and-slow than unknown-and-fast
[16:42] <cjwatson> at least for non-default scenarios like cryptsetup
[16:44] <dupondje> cjwatson: ok no big issue indeed :)
[17:18]  * seb128 closes another set of duplicates of bug #948294 and look at slangasek
[17:18] <slangasek> yes
[17:19] <seb128> slangasek, I think bug #948457 and bug #948296 are yours as well
[17:19] <seb128> slangasek, could be the same underlining issue
[17:19] <slangasek> if they're new symptoms, I guess so
[17:20] <seb128> slangasek, yes, all started with 3ubuntu1 and all happen "while upgrading"
[17:21] <bdmurray> seb128: is there a bug about icon text wrapping on periods like in bug 942539?
[17:22] <seb128> bdmurray, I don't think so, I'm not convinced it's a bug
[17:23] <seb128> bdmurray, you need to wrap somewhere, dot are usually end of words or sentences
[17:23] <seb128> bdmurray, though indeed in that case it's unfortunate
[17:23] <blackbug> Hello, repeating my question, in case anyone has any idea about it. "a naive question: i have just started exploring ubuntu apps source code, in case I make some changes, how should i test it? should i compile/build whole code on my machine and replace install new binaries.. or any other test enviornment method or way"
[17:25] <mvo> mhall119: I gave the MP a +1, while I'm the original edit-patch author, I don't actually have commit access to devscripts so that is all I can do for now
[17:26] <mhall119> mvo: thanks, do you know who can approve it?
[17:27] <slangasek> seb128: I certainly think wrapping after a period with no space after it is a bug; it violates all the standard word-wrapping rules for English.
[17:27] <roaksoax> pitti: ping?
[17:30] <roaksoax> pitti: Hi! I'm looking to create a user/pass and a db for postgresql, from .postinst file. Is there any recommended way to do so?
[17:31] <mvo> mhall119: I think its https://launchpad.net/~devscripts-dev - so bdrung
[17:32] <mhall119> mvo: thanks, I've already pinged bdrung about my submission to debian too
[17:33] <mvo> thanks
[17:33] <mhall119> bdrung: ^^ Please ping me if you need anything else for than MP
[17:33] <bdrung> mhall119: the edit-patch fix?
[17:33] <mhall119> bdrung: yes
[17:35] <bdrung> mhall119: i can look into it tomorrow. feel free to ping me again.
[17:35] <seb128> slangasek, right, though it's not a word, it's numbers and dot only, like if you had 123.456.789.123 not sure if rules dictate that to not be wrapped
[17:36] <PaoloRotolo> Hi all!
[17:36] <seb128> slangasek, but I don't know enough about unicode rules to say
[17:37] <slangasek> seb128: er, Unicode certainly can't dictate the rules here, they may vary by language
[17:37] <slangasek> for *English*, splitting on the dot is wrong :)
[17:37] <seb128> slangasek, well, gtk upstream apparently follow http://www.unicode.org/reports/tr14/
[17:37] <seb128> "Unicode Line Breaking Algorithm"
[17:37] <mhall119> bdrung: will do, thanks
[17:38] <slangasek> phooey
[17:38] <seb128> slangasek, so unicode can't dictate but they do :p
[17:38] <seb128> slangasek, though gedit seems to wrap 12.04 correctly so it might well be a nautilus bug indeed
[17:39] <smoser> @pilot in
[17:41] <seb128> slangasek, bdmurray: yeah, seems a nautilus icon grid bug, when renaming the text entry wraps it correctly
[17:42] <slangasek> seb128: the unicode standard lists . as an "Infix Numeric Separator" that should only break between numbers if accompanied by a space
[17:42] <seb128> slangasek, right, nautilus bug
[17:43] <seb128> I somewhat doubt it's important enough on the nautilus list for having anyone upstream to care about it
[17:43] <seb128> it's unfortunate it's showing on the liveCD though :-(
[17:44] <brendand> i don't think it's anything to do with the full stop
[17:44] <brendand> if you put, e.g. - then it still breaks at the dash
[17:45] <brendand> hmm, but not with anything else
[17:50] <brendand> seb128 - workaround is to stick a unicode 000D (CR) character in there. will that fly?
[17:50] <bdmurray> brendand: that idea was discussed in the bug
[17:52] <seb128> brendand, if that works sure
[17:53] <brendand> stgraber has a good point about the translation implications though
[17:59] <blackbug> I have posted a bug 949116 which is related to mounting of internal/external harddisk and usb drives in 12.04. Also, nautilius
[18:05] <smoser> kenvandine, ping
[18:11] <cnd> is there any issue with always building static libraries with -fPIC?
[18:11] <cnd> I'm trying to figure out a resolution for https://bugs.launchpad.net/ubuntu/+source/gtest/+bug/949244
[18:12] <cnd> I'm thinking of just adding "--with-pic" to the configure flags when building the package
[18:16] <kenvandine> smoser, pong
[18:16] <smoser> kenvandine, http://pad.lv/762167
[18:17] <smoser> i'm patch piloting, and that looks sane to me, but seb had asked you to look at it.
[18:17] <smoser> i'll build and upload if you think its sane.
[18:18] <smoser> the only question i had is if gtk2-engines-pixbuf should have a versioned depends of some sort (since gtk-engines-murrine does, but i have no other reason than that)
[18:18] <kenvandine> smoser, the version probably isn't really important anymore
[18:19] <kenvandine> looks fine to me, go for it!
[18:19] <kenvandine> smoser, thanks
[18:19] <smoser> thanks.
[18:32] <slangasek> cnd: convention is to build a .a and a _pic.a, but that's not a hard rule; we sometimes build .a with -fPIC when it's not logical to ever support a non-PIC lib
[18:33] <cnd> slangasek, when would we want to support a non-PIC lib?
[18:33] <slangasek> cnd: the only reason anyone cares about non-PIC .a is because i386 is register-poor, and PIC eats registers
[18:34] <cnd> this is for gtest, which wouldn't be used outside of test runs
[18:34] <cnd> slangasek, I assume the only problem with i386 being register poor is that stuff will run slower?
[18:34] <cnd> if so, I think that's ok for tests
[18:34] <blackbug> hello, i am trying to compile an apps code, but getting the following error.."configure: error: Package requirements (glib-2.0 >= 2.31.0
[18:34] <blackbug>                   gtk+-3.0 >= 3.0.0
[18:34] <blackbug>                   libcanberra-gtk3) were not met:
[18:34] <blackbug> No package 'gtk+-3.0' found
[18:34] <blackbug> No package 'libcanberra-gtk3' found
[18:34] <blackbug> Consider adjusting the PKG_CONFIG_PATH environment variable if you
[18:34] <blackbug> installed software in a non-standard prefix.
[18:34] <blackbug> "  i am using 12.04 gnome.
[18:34] <slangasek> cnd: much, much slower, yes - but yeah, for gtest it's probably ok
[18:36] <cnd> ok
[18:36] <cnd> slangasek, thanks!
[18:38] <arges> if I want to see the output of g_debug in gnome-settings-daemon is there  a package with the debug output enabled? or do I need to build my own package? thanks
[18:40] <ScottK> arges: Yes.  No.  See https://wiki.ubuntu.com/DebuggingProgramCrash
[18:40] <arges> ScottK, thanks
[19:05] <iulian> Laney: Errm, it should've worked! :-(
[19:05]  * iulian sighs.
[19:26] <blackbug> i want to debug a core file. but the application is not giving the core file inspite of displaying segmentation fault and dumping core file msg. i already checked ulimit which is set to unlimited. any other clues?
[19:30] <mhall119> stgraber: jelmer: james_w: seb128: can you guys please read over http://people.ubuntu.com/~mhall119/blog/patching.html and let me know if you think it's okay?  I tested it out with geany and all the commands worked fine there.
[19:33] <james_w> mhall119, looks ok
[19:33] <james_w> mhall119, for the reverting, "bzr revert" might be easiest, but if there are extra revisions, then I would suggest "bzr merge . -r 32..31" as it saves a command and will handle renames and things better
[19:35] <mhall119> james_w: what command does it save?
[19:36] <james_w> bzr patch
[19:37] <mhall119> james_w: doing it with merge makes bzr fail, somethign to do with geany having applied quilt patches on the branch
[19:37] <james_w> ah, hmm
[19:37] <seb128> mhall119, it's over my bzr knowledge, if james_w is happy with it I'm sure it's good
[19:38] <mhall119> james_w: here's the fun output from trying to do it via merge: http://paste.ubuntu.com/873490/
[19:38] <mhall119> I did realize I forgot to have them update the changelog with dch -i, I'm adding that step now
[19:39] <mhall119> seb128: ^^ I assume that should be done, right?
[19:39] <dobey> is there no way to say "if x is installed, then y must be installed" when x is a recommends, and it doesn't itself rquire y, but the package's usage of x does require both?
[19:41] <dobey> i guess not
[19:43] <ajmitch> only way I can think of offhand is depending/recommending a metapackage that depends on both x & Y, but that isn't nice at all
[19:43] <slangasek> yeah, there's really no way to do conditional package relationships
[19:48] <broder> ah, damn. i screwed up the udd branch for bluez because i didn't see that cyphermox had already uploaded 4.98-2ubuntu3 (he apparently beat me by 6 minutes). what can i do to reset the state of the udd branch?
[19:48] <cyphermox> dah, sorry broder
[19:48]  * broder shrugs
[19:49] <broder> i'll merge and re-upload - it's no big deal
[19:49] <broder> just not sure how to fix the branch, since i already pushed my (now inaccurate) tag
[19:53] <mhall119> james_w: refresh, I added step 4 (dch -i)
[19:55] <slangasek> broder: if you want the importer to not fall over later down the line, I guess it's best to just leave the tag wrong.
[19:56] <slangasek> (there are no great choices here, given the importer's persistent refusal to accept bzr tag --delete as a possibility)
[19:57] <broder> :(
[20:05] <cnd> slangasek, I attempted to file a debian bug report using reportbug, but I think it failed to send the email at the end
[20:05] <cnd> do you know how to be sure and/or how to send it manually?
[20:05] <cnd> I have ssmtp set up
[20:06] <cnd> actually, it's msmtp
[20:06] <cnd> don't know if that makes a difference
[20:09] <slangasek> cnd: with those MTAs I'm not sure how to check, but to send it manually, you just have to send the message to submit@bugs.debian.org with the body of the message intact
[20:11] <stgraber> cnd: ssmtp logs in syslog usually (though it's very limited logging and won't give you a way to access your mail as it doesn't do spooling)
[20:11] <cnd> ok
[20:14] <cnd> slangasek, I assume the turn around time for filing a bug report and receiving a reply back should be less than 15 mins?
[20:16] <broder> slangasek: the importer did actually just move my branch aside and recreated it with the correct histor
[20:16] <cnd> slangasek, looks like it got filed, thanks!
[20:16] <slangasek> broder: oh, wunderbar :)
[20:16] <slangasek> cnd: < 15 mins - no guarantees ;)
[20:16] <broder> slangasek: https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/bluez/precise-201203072011/+merge/96445
[20:16] <broder> (which i'm going to reject, because i've already handled the merge)
[20:20] <seb128> slangasek,
[20:20] <seb128> bzr: ERROR: An error (1) occurred running quilt: Patch 05_readd_gconf_engine_key_is_writable.patch does not exist
[20:21] <seb128> slangasek, seems you forgot to bzr add that patch to the vcs?
[20:21] <slangasek> oh what
[20:21] <seb128> slangasek, I'm fixing it
[20:21] <slangasek> seb128: no, I've got it here
[20:21] <slangasek> bzr add debian && bzr push, already done
[20:22] <seb128> slangasek, hum, bzr pull didn't pull it for me?!
[20:22] <slangasek> no, I *just* pushed it
[20:22] <seb128> oh ok
[20:22] <seb128> slangasek, thanks
[20:22] <slangasek> sure
[20:22] <slangasek> and sorry
[20:22] <seb128> no worry
[20:22] <slangasek> note that if you guys were using the UDD branch, this wouldn't have happened ;)
[20:22] <seb128> slangasek, I'm doing a test build for another issue, just ran into it
[20:22] <slangasek> (since I did a UDD merge first and then copied over to the ~ubuntu-desktop branch ;)
[20:23] <seb128> slangasek, right, we would just have to deal with 5x issues with outdated import, quilt problems and other issues
[20:23] <slangasek> ah, trollfail
[20:23]  * slangasek crawls back into his cave
[20:23] <stgraber> ;)
[20:23] <seb128> slangasek, I'm happy to trade that sort of issue to not use UDD any day ;-)
[20:23] <seb128> lol
[20:23] <seb128> rather
[20:24] <seb128> :-(
[20:24] <seb128> using UDD would be great, it would mean it's working decently enough
[21:23] <mhall119> james_w: are you happy with that blog?
[21:23] <mhall119> stgraber: have you had a chance to look at it?
[21:24] <james_w> mhall119, looks ok, though I haven't tested obviously
[21:25] <mhall119> sure, I didn't expect you too, just wanted to make sure there aren't any glaring errors in the process
[21:25] <mhall119> the end result is a new file in debian/patches/, a new line in debian/patches/series, and a new entry in debian/changelog
[21:26] <mhall119> no changes being made to the source itself
[21:26] <stgraber> mhall119: haven't yet, busy pushing some changes to wubi, will have a look in a minute (pretty much done pushing all I have)
[21:26] <mhall119> stgraber: thanks
[21:28] <stgraber> mhall119: you seem to be missing a "mkdir debian/patches"?
[21:29] <slangasek> mkdir -p debian/patches, so it works whether or not the directory is already there? :)
[21:29] <mhall119> I guess I shouldn't assume they have a debian/patches in the branch, huh
[21:29] <stgraber> though just creaating debian/patches will only work with 3.0 (quilt) packages, for older packaging you'd need to create it + add a build-dep on quilt and add to debian/rules
[21:30] <mhall119> stgraber: how bad would it be if somebody submits a patch file to an older package without that dependency?
[21:31] <stgraber> if whoever doesn't review carefully, the package will build but the patch won't be applied
[21:32] <stgraber> *if whoever does the review doesn't look carefully
[21:33] <broder> does it actually make sense for people who don't have a packaging background to be rewriting their patches? there are still lots of things that could go wrong - .pc conflicts, packages using dpatch (god forbid and not really that likely)
[21:33] <broder> and most importantly this doesn't address the desktop team's weird separate branches
[21:34] <broder> (i think i may have argued in the past that we needed to be telling people how to do this, and if so i apologize  because i think i was wrong to do so)
[21:44] <mhall119> stgraber: how would somebody tell if it's an old or new package?
[21:51] <stgraber> mhall119: debian/source/format
[21:51] <stgraber> mhall119: if it's not "3.0 (quilt)" it won't work with your instructions
[21:51] <jalcine> Anyone know where I can find doku?
[21:53] <smoser> @pilot-out
[21:53] <udevbot> Error: "pilot-out" is not a valid command.
[21:53] <smoser> @pilot out
[21:55] <mhall119> stgraber: do you think quilt 3 will be a minority of majority of packages?
[22:00] <broder> mhall119: zack keeps some stats on adoption in debian: http://upsilon.cc/~zack/stuff/dpkg-v3/ - looks like about 60% of packages in the debian archive are 3.0 (quilt)
[22:00] <mhall119> better odds than Vegas
[22:01] <mhall119> I'll just have them check their debian/source/format before following along
[22:01] <mhall119> what should I tell people who's packages aren't using quilt 3?
[22:01] <ScottK> 3.0 (quilt) just makes my head hurt.
[22:01] <ScottK> mhall119: Nothing.  It's optional.
[22:01] <stgraber> mhall119: http://raphaelhertzog.com/files/2011/12/formats-patches.png
[22:02] <broder> mhall119: anyway, i'm still trying to figure out whether it's actually important that your contributors rephrase their patches with quilt and a changelog, or whether there are other problems with the quicklists and keywords rounds that we should be focusing on instead
[22:03] <broder> i tend to argue that we should be willing to take patches that aren't quiltified as long as everything else is in order, and there's enough information for a contributor to fill in the changelog/dep-3 info
[22:04] <mhall119> broder: it won't hurt if I teach people to make quilt patches when their source package will use it though, will it?
[22:04] <broder> sure, it'd certainly make me happier if i was sponsoring them
[22:05] <broder> but your current instructions make me less happy because the resulting commit doesn't have the patch applied with the .pc changes in the branch
[22:05] <broder> because i've had bad luck trying to merge branches that don't apply patches
[22:05] <mhall119> broder: so the patches *should* be applied?
[22:06] <mhall119> if so, I can just remove the step that reverts that
[22:06] <broder> this is sort of a sticky point in the udd/3.0 (quilt) processes
[22:06] <broder> but right now the branches track patches applied
[22:06] <broder> but they should be applied by quilt, which generates a .pc directory with a bunch of metadata
[22:06] <broder> and that *also* needs to be in the commit
[22:07] <broder> so what i would want to see would be (a) unapply the patches (b) run quilt push -a (c) bzr add everything (including the .pc file)
[22:07] <mhall119> broder: unapply all applied patches, then apply them all?
[22:08] <stgraber> mhall119: what I gave you yesterday actually generated a .pc with the patch applied
[22:08] <broder> unapply the patches that the contributor made, because those would be the ones not currently "owned" by quilt
[22:08] <mhall119> broder: and then quilt push <new patch>?
[22:09] <broder> yeah, or just quilt push -a
[22:09] <mhall119> ok, that's easy enough to add
[22:12] <slangasek> tjaalton: fwiw, I'm still meditating on this latest plymouth change; although I worked with William at the Ubuntu Global Jam over the weekend to prepare this change, I'm a little concerned about the possibility that a raw chvt here could racily break desktop systems
[22:12] <slangasek> tjaalton: by having the chvt called underneath lightdm
[22:13] <ScottK> broder: This would be so much easier if 3.0 (quilt) didn't apply patches by default.
[22:13] <ScottK> It would even make sense to me then.
[22:17] <broder> ScottK: i go back and forth on which i prefer. there are some compelling pros to applying patches when you unpack, but the bad interaction with any sort of vcs is definitely unfortunate
[22:17] <ScottK> Independent of VCS issues, applying patches on unpack seems fundamentlaly wrong to me.
[22:18] <ScottK> It's like a layer violation between the upstream and distro layers of the package.
[22:22] <broder> but it also helps reduce confusion about what the package is going to build for people who walk up to it without packaging background
[22:24] <mhall119> broder: added quilt push -a instructions to http://people.ubuntu.com/~mhall119/blog/patching.html
[22:24] <mhall119> in step 3
[22:26] <broder> yeah, looks good. you may also need to bzr add .pc to pick up the extra crap files there
[22:28] <ScottK> IME nothing regarding quilt avoids confusion for people who are new to it.
[22:28] <broder> hmm, compelling point
[22:34] <mhall119> broder: I have a bunch of .pc/*.patch/.timestamp files now that bzr isn't aware of
[22:34] <mhall119> should all of those be added?
[22:34] <broder> mhall119: yep
[22:34] <broder> otherwise you're only adding half of quilt's state
[22:35] <mhall119> why do I have these files for patches that were previously there though?
[22:35] <jelmer> hi mhall119
[22:35] <mhall119> hey jelmer
[22:36] <jelmer> mhall119: did you still need feedback on http://people.ubuntu.com/~mhall119/blog/patching.html ?
[22:36] <jelmer> mhall119: ".dekstop" seems to be consistently misspelled, is that intentional ? :)
[22:36] <mhall119> jelmer: yes please
[22:36] <mhall119> doh! no
[22:37] <jelmer> mhall119: Cool, I'll have a look now.. might be an hour or as my battery is about to die
[22:38] <mhall119> jelmer: ok, I wasn't planning on having it post until tomorrow morning anywa
[22:38] <broder> mhall119: sorry, irc flaked. the .pc files are how quilt tracks which patches have been applied
[22:38] <broder> if you apply patches but don't include the .pc files that quilt creates, it's worse than not applying the patches at all
[22:39] <mhall119> broder: in that case, I think the geany branch is a mess
[22:40] <broder> mhall119: no, because the patch isn't applied
[22:40] <broder> from my perspective as a sponsor of a udd changes, the best possible world is patches applied with .pc files, then new patch was not applied
[22:40] <broder> patch applied to the osurce tree but without the .pc files is the worst possible setup
[22:40] <jelmer> mhall119: it's a bit confusing that you're mixing both the upstream change and the packaging change in the same branch
[22:41] <mhall119> broder: on a clean bzr branch of ubuntu:geany
[22:41] <mhall119> quilt top says that all patches are applied
[22:41] <mhall119> but I don't see any of those .timestamp files in .pc/
[22:41] <jelmer> mhall119: I can understand why, but it also makes the use of bzr diff and dep3-patch slightly awkward
[22:42] <jelmer> I wonder if we need some better tools for this particular case
[22:42] <broder> mhall119: grabbing the branch and looking
[22:42] <mhall119> jelmer: I was originally leaving the source the same as upstream, but was told that I should apply the patch before committing
[22:42] <jelmer> (or pehrpas just need to improve dep3-patch to handle this case better)
[22:43] <broder> jelmer: since udd tracks 3.0 (quilt) branches with patches applied, you want to apply your new patch as well
[22:43] <broder> otherwise you have a branch with patches partially applied
[22:43]  * mhall119 is so confused right now
[22:44] <jelmer> broder: that does make sense, but I think the use of dep3-patch for that case is a bit awkward at the moment
[22:44] <broder> mhall119: oh, ugh. i bet this is caused by changes in quilt
[22:44] <jelmer> mhall119: sorry :-?
[22:44] <jelmer> I mean :-/
[22:44] <broder> mhall119: if you pop all the patches then push them back on, you get .timestamp files
[22:44] <mhall119> broder: yes, that appears to be what's happening
[22:45] <broder> (also .pc/.quilt_patches and .pc/.quilt_series)
[22:45] <broder> that sucks
[22:45] <mhall119> so would it be okay for a submission to suddenly add these .timestamp files?
[22:45] <jelmer> wait.. changes in the quilt format?
[22:45] <broder> jelmer: bzr branch ubuntu:geany && cd geany && quilt pop -a && quilt push -a && bzr status
[22:45] <broder> http://paste.ubuntu.com/873736/
[22:46] <broder> the udd importer would be running on lucid, right? so there's plenty of room for changes to quilt
[22:46] <mhall119> ok, I'm going to leave this post unscheduled for now, and take my son to karate, I'll be back later and see what you guys have decided on ;)
[22:46] <broder> mhall119: for the record, i no longer have any idea what the best option is :(
[22:46] <mhall119> broder: welcome to the club
[22:47] <jelmer> broder: I think that's another argument for not actually storing the applied quilt patches in the udd branches
[22:47] <jelmer> broder: but rather have them applied at checkout time by bzr
[22:48] <broder> jelmer: that would require us to throw away all of the udd history we have and restart from scratch, right? is that even an option?
[22:48] <jelmer> broder: it would be possible to not apply quilt patches for newly imported versions I guess
[22:49] <jelmer> I'm not sur, needs some more thought I guess
[22:49] <jelmer> *sure
[23:20] <seb128> slangasek, hey
[23:20] <seb128> slangasek, I just saw your comment on that lightdm uninstall bug
[23:21] <seb128> slangasek, I was just wondering, what's the standard thing to do for people trying to uninstall a service while it's running?
[23:21] <slangasek> seb128: the service should certainly be stopped
[23:21] <seb128> slangasek, I think we still have a bug about one of the maintainer script trying to delete to lightdm user on uninstall which fails if you uninstall it from your user session while lightdm is still running
[23:21] <slangasek> and then the package removal should continue
[23:22] <seb128> slangasek, that would log all users out with a dm...
[23:22] <seb128> isn't that bad taste?
[23:22] <slangasek> well, I suppose if they're running *under* the dm, you could bail
[23:22] <slangasek> but in this case, I know it was being uninstalled from the commandline
[23:22] <slangasek> and it still failed :)
[23:22] <seb128> "bail" like break the script?
[23:22] <seb128> slangasek, right, it just made me think about the other case
[23:22] <seb128> or "bail" like success but fail to clean the lightdm user behind?
[23:23] <slangasek> "bail" like break the script
[23:23] <seb128> ok
[23:23] <seb128> so those bugs a "Invalid" then
[23:23] <seb128> i.e "don't do that, don't try to purge a dm you are running and logged with in a session"
[23:24]  * slangasek nods
[23:24] <seb128> slangasek, thanks
[23:24] <slangasek> sure :)
[23:24] <seb128> it happens frequently enough that the bug has half a dozen dups