[00:08] <ScottK> That seems to happen to me about every 10th startup.
[00:09] <lamont> [pid  8787] +++ killed by SIGSEGV (core dumped) +++
[00:09] <lamont> so... I'm gonna go with something a shade more drastic
[00:09] <ScottK> That'll do it.
[00:09] <ScottK> Cutting torch?
[00:11] <lamont> [ 2123.191192] soffice.bin[8681]: segfault at 238 ip 00007fe5d314bdca sp 00007fffe2cc9338 error 4 in libvclplug_genlo.so[7fe5d30e7000+8a000]
[00:11] <lamont> amusingly, 4 pids, 4 segvs
[00:14] <RAOF> lamont: Do you have two monitors?
[00:18] <RAOF> lamont: If you do, you're looking at bug #916357
[00:18] <RAOF> (ie: libreoffice crashes early in startup if you've got two displays enabled)
[00:29] <lamont> RAOF: interesting
[00:29] <lamont> and yes
[00:35] <poolie> zul, can you tell me anything about replacement of keystone with keystone-light in precise?
[00:44] <lamont> I'd also be interested in knowing what I did to make unity (3d) panel not show up when I login that way... I was going to give 3d a try again and see if video could keep up with it now
[00:45] <RAOF> Log in what way?  With two monitors enabled?
[00:45] <lamont> hrm... I wonder if that's it
[00:45] <lamont> 2d works just fine, panel on far left like it wants to be
[00:46] <RAOF> You mean the launcher?
[00:46] <RAOF> Works fine for me :)
[00:51] <lamont> yeah, launcher.  'tever
[00:51] <lamont> and given that it doesn't work on my laptop either, I suspect that I removed some package that it cares greatly about
[00:51] <lamont> or something
[00:51] <lamont> but that was 6 months ago
[00:52] <RAOF> Possibly?  It should depend on everything that's absolutely necesary for, though.
[01:07] <lamont> it's possible that I stabbed it in a config file as well
[02:01] <freeflyi1g> its ok to do it this afternoon
[02:55] <poolie> is there a policy about installation of ubuntu packages not being interactive by default?
[02:56] <psusi> the only kind of interactive they can be is having debconf questions
[02:56] <poolie> right, but there should be no debconf questions at the default level?
[02:58] <psusi> well, don't go asking questions that aren't required at the low priority
[02:59] <poolie> right
[02:59] <psusi> if it must have an answer to install, then use high priority to force it to be asked... but if it's more of an optional thing you can do with sensible defaults, use low priority to prevent it from being asked on normal installs
[02:59] <poolie> the specific thing is that bug 930444 complains (amongst other things) keystone asks a question
[02:59] <poolie> for which it could probably reasonably guess a default
[03:00] <poolie> i'm trying to work out if that is bad by definition, or just undesirable
[03:00] <psusi> afaik it's undesirable to have non low priority questions that aren't really required
[03:02] <poolie> i think so too, i just wondered if that was written down
[03:08] <lifeless> poolie: the installer experience needs TB ack to change IIRC
[03:09] <lifeless> poolie: packages not installed by default on desktop or server or cloud could ask more but its desirable not to ask questions unless really needed
[03:09] <poolie> i agree
[03:09] <poolie> i wondered if the TB had ever stated this
[03:09] <poolie> not a big deal, just wondered
[03:09] <poolie> https://bugs.launchpad.net/ubuntu/+source/keystone/+bug/931236
[03:16] <bkerensa> slangasek: Were having a loco meeting and I brought up you talking at our global jam
[03:16] <slangasek> bkerensa: which channel's that on?
[03:17] <slangasek> oh, I've fallen off the loco channel, haven't I
[03:17] <slangasek> silly proxy crashes
[03:18] <bkerensa> slangasek: I figured you had too many channels and needed a break :) I do that sometimes
[05:21] <pitti> Good morning
[05:22] <ajmitch> morning pitti
[05:23] <pitti> hey ajmitch
[05:55] <micahg> pitti: would it be possible to deNEW amarok (breaking dist-upgrades) and libindicate (preventing a bunch of other rdeps from building)
[05:56] <pitti> sure, I'll do some poking at NEW
[05:56] <micahg> thanks
[06:57] <malkauns> wtf my xorg is at 100% :( :(
[07:17] <alkisg> How can I lock down gsettings? The "lockdown" paragraph from http://live.gnome.org/dconf/SystemAdministrators doesn't seem to apply to precise, e.g.:
[07:17] <alkisg> $ dconf update
[07:17] <alkisg> fatal: Error opening directory '/etc/dconf/db': No such file or directory
[07:46] <dholbach> good morning
[10:00] <apw> pitti, then that probabally accounts for it, just more off it, therefore i have noticed
[10:00] <apw> heh and you getting fingered for the uploads is funny
[10:21] <bkerensa> dholbach: If a package has "Standards-Version: 3.8.2
[10:21] <bkerensa> " it should be bumped up?
[10:22] <dholbach> bkerensa, if it's a package which exists in debian it does not make sense to just update the string - it's a diff we would have to carry on our own
[10:22] <dholbach> in that case just leave it to the maintainer to update it
[10:22] <bkerensa> ok
[10:25] <dholbach> if it's an ubuntu package and you want to update the standards version make sure you have a look at what changed from that version of debian policy to what's current and make adjustments to the package if necessary - then you can go and update it if you like
[10:26] <cjwatson> there's an upgrading checklist in Debian policy
[10:27] <cjwatson> the point isn't to have the string current at all costs, it's to act as a reminder for what version of policy the package has been checked up to
[10:27] <bkerensa> I see
[10:28] <cjwatson> and yes, I agree with dholbach, don't in general update it as an Ubuntu delta
[10:28] <bkerensa> I was mostly looking for some small work to do before bed and I saw a package that had a outdated standards version and had never heard about the policy
[10:28] <bkerensa> :)
[10:28] <seb128> thanks to whoever helped to get webkit built during the w.e and sorry it was so bumpy and that I screwed up the .symbols stuff on friday evening
[10:28] <dholbach> bkerensa, /usr/share/doc/debian-policy/upgrading-checklist.* might be interesting then :)
[10:29] <bkerensa> dholbach: Does harvest take awhile to update? I have noticed that it lists quite a bit of potential work that already has fixes released and is not really potential :)
[10:29] <dholbach> bkerensa, it should be updated every 30m
[10:29] <bkerensa> :D
[10:30] <bkerensa> dholbach: Hmm well I have been checking it for a few days now and I see plenty of Bugs that have been fixed months ago
[10:31] <bkerensa> :)
[10:31] <bkerensa> https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/905260 <-- for example is listed under banshee on harvest and was fixed quite awhile ago
[10:31] <bkerensa> :D
[10:31] <dholbach> bkerensa, can you please file a bug on harvest with a few examples which are listed?
[10:31] <bkerensa> surely
[10:31] <cjwatson> that's fix committed not fix released ...
[10:31] <dholbach> it can be a bug in harvest or in one of its data providers
[10:31] <cjwatson> although one might argue that's not a particularly interesting opportunity in some contexts
[10:32] <bkerensa> :D
[10:32] <dholbach> hum, if apport does not open the firefox window correctly, how can I report the bug?
[10:32] <dholbach> "firefox is already running blah blah blah..."
[10:33]  * dholbach just had X crash a couple of moments ago
[10:36] <bkerensa> https://bugs.launchpad.net/harvest/+bug/931343
[11:38] <ricotz> YokoZar, hello :), no wine 1.4~rc2-0ubuntu1~ppa1 for lucid in the ppa?
[11:55] <MacSlow> mvo, ping
[12:02] <ScottK> pitti or Riddell: sip4 just hit binary New on i386 only due to a new arch:all package.  It'd be nice to get it let out soon so we don't have archive skew problems.
[12:16] <ScottK> python-qt4 will hit binary New as well, but for all archs, so it's less urgent.
[12:16] <mvo> MacSlow: welcome back
[12:17] <MacSlow> mvo, thx
[12:18] <pitti> ScottK: NEWed
[12:24] <pitti> Sweetshark: do you happen to know about the current status on libo on armhf?
[12:25] <Sweetshark> pitti: no progress there, unless it magically solved itself without a patch
[12:25] <Sweetshark> pitti: bug 900636
[12:25] <ogra_> pitti, linaro is supposed to be working on it
[12:26] <ogra_> (no idea who, or whats the status, ask rsalveti)
[12:26] <pitti> ah, thanks for the pointer
[13:36] <herton> pitti, hi, there were some issues in the copying of the lucid kernel to -proposed (https://bugs.launchpad.net/kernel-sru-workflow/+bug/921562/comments/5). I did some new checking, so some issues probably happened before but only now the stable bot is checking them.
[13:55] <pitti> herton: ah, nice work on these checks! will clean up now
[14:07] <pitti> herton: fixed; does your bot query archive.u.c., or launchpad directly?
[14:11] <pitti> hallyn: you uploaded two diffferent qemu-kvm versions to lucid-proposed, rejecting both; please merge and reupload
[14:26] <pitti> jdstrand: do you want to re-evaluate bug 673925 with the current version?
[14:26] <pitti> jdstrand: or were you already involved enough with the fix to say "ok now"?
[14:27] <pitti> ScottK: new python-qt4 pulls in pyopengl; do we really want this in main?
[14:28] <pitti> ScottK: also, pyopengl uses python-support
[14:35] <herton> pitti, thanks. It queries archive.u.c just for the latest version in -proposed, but uses launchpad api to check the components
[14:37] <pitti> herton: ah, then you might already be able to run it again with the updated results
[14:38] <herton> pitti, ack, will take a look here
[14:44] <pitti> ScottK: oh, nevermind; python-qt4-gl wants to go back to universe
[14:50] <herton> pitti, some new things came up now on the component check for the lucid -proposed: http://pastebin.ubuntu.com/840458/
[14:50] <pitti> herton: -preempt is not supposed to be in main
[14:50] <pitti> need to run out for some errands, bbl
[14:50] <pitti> I'll check the others later
[14:51] <herton> pitti, right, just referring to the new matches on the pastebin I posted
[14:51] <herton> ok
[14:51] <herton> pitti, this -preempt is a issue with an old copy of the bot running, I reported to brad (bjf) already, just ignore it for now
[14:58] <yofel> mterry: hi, do you have time to look at these MIR's? 930384 and 930112. They're required for gtk3 support in kubuntu.
[14:59] <mterry> yofel, k, I'll either look at them or assign them with a day or two
[14:59] <yofel> thanks
[15:28] <jdstrand> pitti: wrt 673925> I spent quite a bit of time iterating with upstream on the fix in 925657, so yes I think it is fine. I commented in the bug
[15:35] <pitti> jdstrand: great, thanks!
[15:44] <pitti> herton: I promoted the non-preempt stuff from your pastebin
[15:48] <herton> pitti, nice, thanks. Launchpad still doesn't report the changes yet, will wait some minutes and check again.
[15:48] <seb128> how do I tell bzr bd-do (debian dir only vcs) to no fail because a patch doesn't apply ... I want to use it to refresh patches which is the whole point of using that command
[15:49] <theozaurus> Hi, I'm attempting to package up Passenger with Ruby 1.9.3 on Lucid using packages taken from Precise and dotdeb. I've got stuck though in that when I upload to PPA and it attempts to build it cannot find the rake command. Running it locally is fine and it has the correct build dependencies to get Rake, however when running dh_clean it just gives me "Command not found" on the PPA build server. How can I better debug the situation?
[15:51] <cjwatson> check your Build-Depends
[15:51] <cjwatson> no doubt locally you just already have that package installed
[15:53] <theozaurus> cjwatson: I'll have another look!
[15:53]  * cjwatson looks at the failed build logs
[15:54] <cjwatson> No sign of rake in your Build-Depends; that'll be the problem
[15:55] <cjwatson> also I think I'd recommend calling rake simply as rake, not as '/usr/bin/rake1.9.3'
[15:55] <cjwatson> "Remove rake as a dependency, this is included in Ruby 1.9.3
[15:56] <cjwatson> " - it's still a separate binary package
[15:58] <theozaurus> cjwatson: In my Ruby build it packages it
[15:59] <theozaurus> cjwatson: I've switched it to rake1.9.1 which seems to be working. I think the issue is that it creates symnlinks to rake1.9.3 which Make doesn't pick up. Could that be possible?
[15:59] <theozaurus> cjwatson: That was very fast work in finding the repo!
[16:00] <cjwatson> theozaurus: perhaps you need a ruby-defaults upload in your PPA if you want the unversioned symlinks to be present
[16:00] <cjwatson> theozaurus: Google is occasionally my friend :-)
[16:01] <theozaurus> Ah i'll have a look at the ruby-defaults package. As you may have guessed debian packaging is very new to me so just trying to feel my way through.
[16:03] <cjwatson> hm, the business of rake shipping /usr/bin/rake (as a real file, not a symlink!) and ruby1.9.1 shipping /usr/bin/rake1.9.1 even in the primary Ubuntu archive is kind of odd
[16:03] <cjwatson> so having ruby-defaults do that would introduce an awkward file conflict
[16:03] <pitti> cnd: are you aware of the non-applying patch in xserver-xorg-input-evdev? are you working on it ATM, or need help:?
[16:03] <cjwatson> I wonder what the motivation behind that was
[16:04] <cnd> pitti, no, I'm not aware
[16:04] <cnd> which patch?
[16:04] <pitti> cnd: see https://launchpadlibrarian.net/92570339/buildlog_ubuntu-precise-i386.xserver-xorg-input-evdev_1%3A2.6.99.901%2Bgit20120126-0ubuntu1_FAILEDTOBUILD.txt.gz
[16:05] <cnd> hmm... why didn't I get an email about the build failure?
[16:05] <cjwatson> theozaurus: maybe you are better off calling it as rake1.9.1 for now; if you want rake1.9.3, you need a Build-Depends on ruby1.9.3 which contains it (in your PPA)
[16:06] <cjwatson> theozaurus: the builders start off with basically a blank slate - a very minimal system which is only able to build minimal C packages - and only install what they're told to install
[16:08] <cnd> pitti, I'm fixing it right now
[16:08] <cnd> thanks!
[16:13] <pitti> cnd: thank you!
[16:14] <cnd> pitti, I should have received an email about the build failure, right?
[16:14] <pitti> yes
[16:16] <cnd> hmm...
[16:16] <cnd> pitti, any ideas why I didn't?
[16:17] <pitti> cnd: not off-hand; usually both the uploader and the changed-by: addresses get the mail
[16:18] <cnd> ok
[16:25] <micahg> cnd: no build failure mails on syncs from Debian made with syncpackage ATM
[16:25] <cnd> micahg, this wasn't a sync though...
[16:26] <micahg> ah
[16:32] <bonks> when are new versions of subversion added to apt? just curious because v1.7.* has been out for a while but apt only has 1.6.17
[16:33] <micahg> bonks: when they're added to the archive for that particular release
[16:34] <bonks> micahg: do you guys have eta's?
[16:35] <micahg> I don't know what it's planned for precise, feature freeze is in 3 days
[16:35] <cjwatson> subversion's mostly maintained by Debian
[16:35] <micahg> s/what/that/
[16:35] <cjwatson> the packaging, I mean
[16:35] <cjwatson> we'd generally not update before they do
[16:35] <herton> pitti, I fixed the checks for -preempt on the script which checks components, there are still 2 mismatches now: http://pastebin.ubuntu.com/840578/
[16:35] <cjwatson> and yeah, I expect too late for precise now
[16:36] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656966 is a Debian bug of sorts for the upgrade
[16:36] <bonks> cjwatson: thanks
[16:36] <cjwatson> ah, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621692 is clearer
[16:37] <herton> pitti, as I understand, linux-versatile should be in main as well, since the linux image and other versatile meta packages are also in main
[16:37] <herton> the other is one preempt case I got now checking properly the -preempt packages
[16:37] <pitti> herton: linux-image-versatile is, linux-versatile isn't
[16:38] <pitti> herton: but linux-versatile was in universe in lucid final, too
[16:38] <cjwatson> I wouldn't be opposed to getting subversion 1.7 merged in if the Debian maintainer got it uploaded, but it's a bit complex to duplicate the work
[16:39] <bonks> cjwatson: understood
[16:39] <herton> pitti, any reason linux-versatile shouldn't be moved to main? Seems an error it being on universe
[16:40] <pitti> herton: mostly for consistency; it wasn't in final
[16:50] <herton> pitti, ok, I'm ignoring the linux-versatile then on the script, just linux-headers-lbm-2.6.32-38-preempt then must be moved to universe
[16:50] <pitti> herton: ack, done
[16:50] <pitti> good night everyone!
[16:51] <herton> pitti, thanks, I think everything is sorted now
[17:00] <cjwatson> Sweetshark: hmm, does there exist a usefully current branch for the LO packaging?
[17:07] <Sweetshark> cjwatson: a git branch on http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=summary
[17:08] <cjwatson> gotcha, thanks
[17:09] <cjwatson> Sweetshark: if I just send a patch for the Debian branch are you likely to merge it before precise?
[17:09] <cjwatson> I'm working through everything on http://lintian.ubuntuwire.org/tags/preinst-uses-dpkg-maintscript-helper-without-predepends.html but don't want to upload LO frivolously
[17:10] <Sweetshark> cjwatson: yes, I am rebasing on debian-experimental-3.5 regularly.
[17:10] <cjwatson> cool.
[17:36] <hallyn> is apt-get autoremove supposed to be smart?  should it never remove packages which were manually installed?
[17:37] <hallyn> (cause boy did it mess up on saturday on my lucid server)
[17:39] <Ampelbein> It is supposed to only remove packages that were automatically installed and are neither Depends or Recommends of another package.
[18:33] <SpamapS> Hm, the new bzr package merging stuff seems to work quitew ell
[18:34] <hallyn> Ampelbein: wonder if landscape messed with the db or something
[18:47] <SpamapS> slangasek: ping? I need your opinion on a merge conflict in cyrus-sasl2..
[18:48] <SpamapS> slangasek: http://paste.ubuntu.com/840754/
[18:48] <SpamapS> slangasek: seems like the wildcard is safe enough here.
[18:51] <ScottK> pitti: Thanks.
[18:52] <infinity> SpamapS: I see nothing wrong with the wildcard.
[18:52] <infinity> SpamapS: Just makes it easier to rev the packaging.
[18:53] <SpamapS> infinity: agreed, ok, that makes me feel better about it.
[18:53] <infinity> SpamapS: (I'd probably back it up even further, in case the major changes, to be honest, since that's the sort of thing people are prone to forget about)
[18:53] <infinity> But meh. :)
[18:53] <SpamapS> can't fix the world.
[18:53] <infinity> I try.
[18:53] <infinity> Then I get tired and nap.
[18:54]  * SpamapS hears a guitar strumming in the background and wonders if we're about to hear infinity's rendition of What's Going On
[18:54] <infinity> I'll spare you.
[19:07] <slangasek> SpamapS: wildcard looks safe to me
[19:09] <randomuser> i know this is inappropriate here, the other channels seem to address mostly cut-and-paste issues; I'm looking for a reason why a default NM controlled interface would spam DHCP requests
[19:10] <SpamapS> slangasek: thanks
[19:10] <SpamapS> so now I need to figure out how this works when I do a package merge and some, but not all, patches were applied. do I do a debcommit w/ all 'unapplied', then another one subsequently, with patches applied?
[19:17] <slangasek> SpamapS: I would apply all the patches before committing, personally
[19:17] <SpamapS> slangasek: tried that.. failed miserably
[19:18] <slangasek> how do you mean?
[19:18] <SpamapS> slangasek: .pc is "gone" now.. so I'd be adding it again..
[19:18] <slangasek> why is .pc gone?
[19:18] <SpamapS> slangasek: because the merge came from a place where the patches were unapplied
[19:18] <SpamapS> so .pc is marked as removed in the merge
[19:18] <slangasek> did the maintainer change the source format?
[19:18] <slangasek> and switch back to v1?
[19:19] <SpamapS> slangasek: definitely not.. but the merge appears to remove .pc/*
[19:19]  * slangasek scratches his head
[19:19] <slangasek> barry: ^^ do you know what's going on with this package merge?
[19:20] <SpamapS> you can see it very easily if you merge lp:debian/cyrus-sasl2 into lp:ubuntu/cyrus-sasl2
[19:20]  * barry reads scrollback
[19:20] <SpamapS> http://paste.ubuntu.com/840797/
[19:20] <SpamapS> (that is after resolving the 2 conflicts)
[19:21] <slangasek> I expect the patches to be unapplied as part of the merge because of the new bzr-bd quilt handling, but not to try to remove .pc
[19:21] <barry> SpamapS, slangasek: i'll bet it's bug 929164
[19:22] <barry> SpamapS: if you can confirm, and possibly hold off on uploading a new version, we can get the bzr guys to help us diagnose the problem
[19:22] <slangasek> barry, SpamapS: I just checked, and .pc is present in the source branch
[19:22] <slangasek> so I think this is related to bzr-bd quilt
[19:22] <SpamapS> barry: yes I had that problem too.. worked around it by doing 'debcommit'
[19:23] <barry> really.  that's interesting
[19:23] <SpamapS> but of course, that committed unapplied patches
[19:23] <barry> yep
[19:23] <slangasek> SpamapS: why does 'quilt push -a' not work?
[19:24] <psusi> cjwatson: was it /boot/efi or /boot/grub/efi where the efi system partition needs to be mounted?
[19:24] <barry> SpamapS: probably, the conflicts prevented the patches from getting applied at the end of the merge
[19:24] <SpamapS> slangasek: it only applies a few of the patches.
[19:25] <SpamapS> slangasek: I didn't investigate further why that is
[19:25] <slangasek> SpamapS: is debian/patches/series bustificated?
[19:25] <barry> SpamapS: so the package is cyrus-sasl2?
[19:25] <SpamapS> yes
[19:25] <slangasek> I would expect 'quilt push -a' to be the right thing to do after the merge, to get it back to the state UDD wants
[19:25]  * barry tries it locally
[19:25] <SpamapS> err
[19:25] <SpamapS> barry: yes its cyrus-sasl2
[19:25] <SpamapS> slangasek: not sure, looking now
[19:26] <SpamapS> slangasek: except then you'd like, re-modify all the files, and add new untracked files into .pc ..
[19:26] <slangasek> perhaps?  maybe bzr manages to pick them up in .pc automatically?
[19:26] <slangasek> but 'bzr add' in any case
[19:28] <barry> SpamapS: so to resolve the conflicts i just took the debian version
[19:30] <SpamapS> I'm going to try setting the quilt-commit-policy to 'applied' and see if that resolves it
[19:31] <barry> SpamapS: so, i've confirmed that when bug 929164 is hit, all you need to do is `bzr rm` (no arguments) to be able to build the source package (no debcommit required, but probably has the same underlying effect on the package)
[19:32] <barry> SpamapS: but this causes failures: quilt push -a && bzr commit -m'quilt push -a'
[19:34] <SpamapS> where exactly can I set this 'quilt-commit-policy' ?
[19:34] <SpamapS> There's no docs for it..
[19:34]  * SpamapS should perhaps ask jelmer
[19:34] <SpamapS> jelmer: here?
[19:34] <barry> SpamapS: yeah, i did find them, but i forget where
[19:34] <barry> you add them to debian/bzr-builddeb.conf which is an ini file iirc
[19:35] <jelmer> SpamapS: hi
[19:35] <SpamapS> jelmer: I'm trying to figure out how to set the quilt-commit-policy = applied
[19:35] <barry> hi jelmer!  more data on bug 929164
[19:37] <SpamapS> seems to me that the policy should be inferred from debian/source/format , shouldn't it?
[19:38] <jelmer> SpamapS: what are you trying to do exactly?
[19:38] <jelmer> SpamapS: quilt-commit-policy by default is disabled
[19:39] <SpamapS> jelmer: I want patches applied to a branch when I commit
[19:40] <jelmer> SpamapS: ah, ok - in that case you want 'echo [BUILDDEB]\nquilt-commit-policy = applied\n' > debian/bzr-builddeb.conf
[19:40] <SpamapS> jelmer: mostly for the greater purpose of testing why merging lp:debian/cyrus-sasl2 into lp:ubuntu/cyrus-sasl2 ends up deleting the entire .pc directory
[19:41] <jelmer> SpamapS: that would probably be because the smart quilt merging kicks in - it unapplies patches during the merge
[19:42] <barry> SpamapS here's where jelmer describes configuration: http://article.gmane.org/gmane.linux.ubuntu.devel/34747
[19:43] <barry> jelmer: and when there's conflicts the patches don't get applied because the process stops, which makes sense
[19:43] <dupondje> Somebody here around with some gdebi/apt knowledge? Got a weird issue with a package, depends are mysql-client-5.1 | mysql-client, but get the following error on install (gdebi: http://paste.ubuntu.com/840803/ or apt http://paste.ubuntu.com/840800/ )
[19:44] <jelmer> SpamapS, barry: also http://bazaar.launchpad.net/~bzr-builddeb-hackers/bzr-builddeb/trunk/view/head:/doc/user_manual/configuration.rst
[19:45] <barry> jelmer: thanks, i'll add a link to that from the packaging guide
[19:46] <SpamapS> ok so the unapply is fine, but how do I magically then tell the smart quilte merging to re-apply ?
[19:48] <SpamapS> if I quilt push -a myself.. I have to then bzr add ..
[19:49]  * SpamapS is so confused
[19:50] <lifeless> SpamapS: orly :P
[19:51] <SpamapS> Ok, so doing   bzr merge deb ubuntu, then resolving the conflicts, then doing 'bzr rm', then 'quilt push -a', then 'bzr add', then debcommit .. that worked
[19:53] <jelmer> SpamapS: so, the issue seems to be that if there are conflicts during the patch applying we leave the tree as is
[19:54] <barry> jelmer: could `bzr resolve` when there are no more conflicts clean everything up?
[19:54] <SpamapS> to be clear, there were no conflicts during the _quilt_ patching, only during the bzr merge process
[19:54] <barry> SpamapS: after that last debcommit though, can you still `bzr bd -S` ?
[19:55] <SpamapS> barry: yes!
[19:55] <barry> SpamapS: cool.  failed for me, but let me try again with your recipe
[19:55] <SpamapS> barry: both before and after the debcommit actually
[19:55] <jelmer> barry: yeah, I guess we could have that apply the quilt patches. It might be a bit odd though
[19:56] <SpamapS> jelmer: I'd be in support of that.. since that is the point at which the manual merge is over.
[19:56] <SpamapS> Even if it just reminded me to quilt push -a / bzr add .. :)
[19:56] <jelmer> SpamapS: ok, that's certainly possible
[19:57]  * jelmer pastes a bit of IRC conversation in the bug
[19:59] <barry> SpamapS, jelmer confirmed that SpamapS's recipe works.  which makes sense since that's probably exactly what happens if there are no merge conflicts
[20:08] <cjwatson> psusi: /boot/efi
[20:12] <psusi> cjwatson: fixed up the installation-guide again... left in the section about some systems needing /boot, but still got rid of all of the nitty gritty and largely obsolete details about CHS and LBA, and added a section for GPT
[20:17] <cjwatson> ok
[20:21] <dupondje> Somebody here around with some gdebi/apt knowledge? Got a weird issue with a package, depends are mysql-client-5.1 | mysql-client, but get the following error on install (gdebi: http://paste.ubuntu.com/840803/ or apt http://paste.ubuntu.com/840800/ )
[20:21] <dupondje> anyone ? :)
[20:24] <BenC> dupondje: it's not an issue…you don't have either of those packages installed
[20:24] <dupondje> BenC: shouldn't gdebi fetch the missing depend ?
[20:25] <BenC> dupondje: your original pastebin showed you using dpkg -i
[20:25] <dupondje> http://paste.ubuntu.com/840803/
[20:26] <BenC> dupondje: that's still dpkg output
[20:26] <BenC> dupondje: why not just do "sudo apt-get install mysql-client"
[20:27] <dupondje> jtaylor made the output btw
[20:27] <dupondje> not having a precise system here
[20:28] <BenC> dupondje: this is likely a better question for #ubuntu, either way
[20:28] <dupondje> see https://bugs.launchpad.net/ubuntu/+source/automysqlbackup/+bug/931123
[20:29] <Ampelbein> The "real" question is: Is it a bug in the package to list a non-existend depends first. As in "mysql-client-5.1 | mysql-client", where the former is not available in Ubuntu.
[20:30] <BenC> It's not a bug at all for that to happen
[20:30] <BenC> The whole reason for "foo | bar" syntax is for that very reason
[20:30] <BenC> Well, for similar reasons, but that is one of them
[20:32] <Ampelbein> See, that's what I thought. But there are developers around who won't sync such a package, because "I like stuff gdebi installable".
[20:33] <dupondje> It looked just fine to me also indeed ...
[20:33] <broder> Ampelbein: then fix gdebi
[20:33] <BenC> Yeah, because apt will likely install it just fine
[20:33] <Ampelbein> broder: I don't even use gdebi.
[20:34] <broder> err, in spite of the highlight, that was directed at the abstract "you" :)
[20:34] <SpamapS> Hm, is a versioned build-depends that will prevent building cyrus-sasl2 against an old buggy version of heimdal enough to keep a delta from Debian?
[20:35] <BenC> arguably, in this case, I would think that the "mysql-client-5.1" portion of that depend is pretty pointless
[20:35] <BenC> since it and all mysql-client-x.y packages should provide mysql-client anyway
[20:35] <SpamapS> BenC: agreed
[20:35] <SpamapS> in this particular case, just depend on mysql-client
[20:35] <dupondje> thats maby true
[20:36] <dupondje> but is it a reason to make a delta with debian ?
[20:36] <dupondje> as its not really wrong ...
[20:36] <BenC> dupondje: it is actually not needed, so wrong in a very real sense
[20:38] <BenC> So I would say delta with Debian and provide the feedback that it's superfluous to depend on mysql-client-5.1 specifically when mysql-client is perfectly fine by itself
[20:38] <Laney> it's actually a real package too, so yeah
[20:39] <BenC> The OR syntax was meant for things like "exim4 | mail-transport-agent" where you have competing packages to satisfy the same dependency but one is preferred…this is not such a case
[20:41] <broder> uh, that may be a design goal, but is it actually documented that it *must* be used that way?
[20:41] <superm1> BenC: noticed you did a mythtv upload to precise a few weeks ago just now.  can you please ping someone in #ubuntu-mythtv (daviey or myself or tgm4883) to merge changes like that so that they don't get missed on uploads that happen from the VCS?
[20:41] <dupondje> ok its clear :) going to bugreport in debian
[20:41] <dupondje> thanks!
[20:42] <BenC> broder: mucking up the dependency resolution process needlessly is against any design goal, IMO :)
[20:42] <BenC> superm1: Yeah, sorry…will do next time
[20:42] <superm1> thanks
[20:43] <superm1> we've got many more uploads planned for precise so i've merged it and it will just come up on one of those at some point
[20:51] <SpamapS> barry: so, after all that merging, it turns out that the package can be synced. I figure you guys have the two branches locally that can reproduce the problem.. so once I hear back from you I will sync the package.
[20:51] <SpamapS> Hey is merge-o-matic broken?
[20:52] <barry> SpamapS: i'll let jelmer answer about that.  in my original bug report i had lots of problems getting back to a state where the bug showed up.  but i think we now have enough information for jelmer to do awesome things
[20:52] <SpamapS> I uploaded wget on Friday.. still shows needing a merge
[20:53] <Ampelbein> SpamapS: Seems last updated: 10-Feb-2012 04:10
[20:55] <SpamapS> barry: should be easy if we just push the branches to +junk and put the links in the bug
[20:55] <barry> SpamapS: good idea!  will you do that or do you want me to do it?
[20:55] <SpamapS> barry: already doing it :)
[20:55] <barry> :)
[21:03] <SpamapS> barry: ok, comment posted. syncing
[21:04] <barry> SpamapS: thanks
[21:40] <Riddell> TheMuso: what did you find out KDE frontend to orca?
[21:40] <Riddell> about..