=== funkyHat is now known as funkyHat|off
=== superm1|away is now known as superm1
[05:35] <dholbach> good morning
[05:35] <crimsun> hullo
[05:36] <nxvl> dholbach: hi!
[05:36] <dholbach> hi crimsun, hi nxvl!
[05:36]  * dholbach hugs y'all
[05:38] <nxvl> dholbach: we don't have a MOTU/TODO with a list of bugs anymore, do we?
[05:39] <dholbach> nxvl:  https://wiki.ubuntu.com/MOTU/TODO/Bugs ?
[05:40] <nxvl> dholbach: yup, but we use to have a table in there with some bugs listed
[05:41] <dholbach> ahhhh right... the "Weekly Bugs"
[05:41] <dholbach> that was just 10 bitesize and 10 packaging bugs picked randomly
[05:41] <nxvl> yup
[05:41] <dholbach> I used to update it every week but there was not a lot of excitement about it
[05:42] <nxvl> exactly those
[05:42] <dholbach> and especially with harvest now it makes even less sense for me to update it every week
[05:42] <nxvl> :D
[05:42] <nxvl> just checking
[05:45] <nxvl> dholbach: btw, wouldn't it be nice to at least link harvest from ubuntuwire?
[05:46] <dholbach> nxvl: yeah, sure - I just don't have editing powers there :)
[05:46] <dholbach> the more links to harvest, the better
[05:47] <nxvl> :D
[05:47] <ajmitch> wgrant would be able to change ubuntuwire for you
[05:47]  * ajmitch doesn't have a checkout of the branch handy
=== persia_ is now known as persia
[06:01] <j-b> jdong: you are going to kill me
[06:19] <wgrant> dholbach, nxvl: It seems to already be on http://qa.ubuntuwire.com/. I don't recall who added it, but it has been there for ~1.5 months
[06:19] <dholbach> rock and roll
[06:19] <dholbach> thanks wgrant!
[06:19] <wgrant> np
[06:19]  * wgrant returns to work.
[06:21] <wgrant> It might want to be renamed on that page; please ask if you feel the same.
[06:22] <dholbach> maybe "Harvest - Aggregated package opportunities"?
[06:23] <wgrant> dholbach: Done.
[06:24] <dholbach> the unstoppable wgrant!
[06:24] <dholbach> gracias!
[06:24] <wgrant> Unstoppable except for damn uni work, sure.
[06:25] <crimsun> I miss uni work.
[06:28] <wgrant> crimsun: But you're crimsun.
[06:50] <j-b> siretart: ping
[06:50] <siretart> j-b: in 30 mins. on the way to work
[06:51] <j-b> siretart: just to tell you we are going to tag VLC 0.9.3 tomorrow or the following day
[06:51] <j-b> to fix bugs
[06:54] <iulian> Good morning.
[07:28] <siretart> j-b: now I'm back!
[07:29] <siretart> j-b: ah, do you have a link with a changelog mentioning the fixed bugs?
[07:34] <j-b> siretart: yes, I do
[07:35] <j-b> siretart: bigger is DTS-channel fix
[07:35] <j-b> http://git.videolan.org/?p=vlc.git;a=blob;f=NEWS;h=221e1dd6e80549c04762ade78ad38ae28c76f031;hb=0.9-bugfix
[07:36] <j-b> siretart: so, for linux port, it means a few crashes fixes, DTS 5.1 channel order, pausing subtitles and MMS behaviour regression fix
[07:37] <didrocks> dholbach: is there a way/futur implementation on harvest to only see a subset of packages for preferences to the team? norsetto's work, for instance, did a very good for the desktop team: http://www.webalice.it/norsetto/
[07:38] <dholbach> didrocks: team stuff is in progress, until then you can use URLs like http://daniel.holba.ch/harvest/handler.py?pkg=audacity,avahi,pulseaudio
[07:39] <dholbach> using the script in https://lists.ubuntu.com/archives/ubuntu-devel/2008-August/026027.html helps too :)
[07:39] <didrocks> dholbach: great, thanks :)
[07:39]  * didrocks hugs dholbach 
[07:40] <dholbach> de rien
=== superm1 is now known as superm1|away
[08:21] <el_ave> hi
[08:22] <el_ave> i'm trying to play with making packages in ubuntu using pbuilder
[08:22] <el_ave> but for some reason  dh_shlibdeps doesn't pick-up the deps
[08:26] <RAOF> I presume that you've actually got a ${shlibs:deps} in your package's Depends: field?
[08:27] <el_ave> yep
[08:28] <el_ave> here is part of logs
[08:28] <el_ave> dh_installdeb
[08:28] <el_ave> dh_shlibdeps
[08:28] <el_ave> dh_gencontrol
[08:28] <el_ave> dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
[08:29] <RAOF> Are there actually shared library dependencies involved?  That seems somewhat odd.
[08:30] <el_ave> i'm trying to modify an exisiting package, the initial package builds fine, the only things i
[08:30] <el_ave> have changed so far are the names of the package
[08:31] <RAOF> Does the unmodified package also exhibit that warning?
[08:32] <el_ave> nope, it seems to pick up the deps just fine
[08:32] <RAOF> Oh.  You changed the package name; did you also change the install files (if any)?
[08:33] <RAOF> I'd _guess_ that you're now building an empty package, and so there aren't any shlibdeps.
[08:34] <el_ave> i see
[08:36] <el_ave> it look like the code gets compiled, but i guess you mean the install scripts don't copy it to proper place for a package to be made?
[08:37] <directhex> .install files.
[08:38] <directhex> Projects/pkg-cli-apps/packages/smuxi/trunk/debian/smuxi-frontend.install
[08:38] <RAOF> Right.  The general flow of a multi-binary package build is "upstream build" -> "upstream install to $(CURDIR)/debian/tmp" -> "dh_install moves files from tmp to debian/$(PKGONE) debian/$(PKGTWO), etc"
[08:38] <RAOF> Then, run the rest of the build process on the contents of debian/$PKGONE, debian/$PKGTWO, etc.
[08:39] <RAOF> So, if the package you touched has a mypackage.install file, and you changed the name from mypackage to yourpackage, dh_install will no longer pick up mypackage.install, and won't move things into the right place.
[08:40] <el_ave> thank you! let me digg into it a little more :)
[08:40] <directhex> RAOF, was f-spot still hanging on exit, as far as you know?
[08:40] <RAOF> directhex: Not that I've noticed, but I don't fire up f-spot very often.
[08:40]  * directhex is going postal on mono bugs on lp
[08:41] <RAOF> Seems to quit cleanly.
[08:46] <directhex> hm, apparently problems persist on hardy
[08:46] <directhex> silly 1.2.6
=== dholbach_ is now known as dholbach
=== BugMaN1 is now known as BugMaN
=== Ng_ is now known as Ng
=== elmargol is now known as elmargol_
=== elmargol_ is now known as elmargol
[10:17] <james_w> does anyone have any tips about how to diagnose this? http://launchpadlibrarian.net/17859568/buildlog_ubuntu-intrepid-lpia.libcairo-ruby_1.5.1-1%2Blenny1_FAILEDTOBUILD.txt.gz
[10:18] <james_w> ruby1.9 won't install as rdoc1.9 isn't going to be installed
[10:29] <geser> james_w: get a lpia chroot and check why rdoc1.9 can't get intalled, you might need to do this recursively
[12:11] <slytherin> please keep a watch on bug #272866. Once it is done, you can proceed with moving aspectwerkz2 to universe. I believe you already have a bug logged for that.
[12:11] <ubottu> Launchpad bug 272866 in javassist "Please move package to universe" [Undecided,Confirmed] https://launchpad.net/bugs/272866
[12:20] <_ruben> is a Releases file mandatory in a local apt mirror? my dput/mini-dinstall generated local repo doesnt have it, and apt doesnt seem to see the packages in it :/
[12:22] <directhex> i use one.
=== Nafallo_ is now known as Nafallo
[12:23] <slytherin> _ruben: yes it is mandatory.
[12:23] <slytherin> james_w: ruby1.9 has failed to build on lpia
[12:23] <slytherin> james_w: https://edge.launchpad.net/ubuntu/intrepid/+source/ruby1.9/+builds
[12:24] <_ruben> slytherin: figured as much .. probably related to the "has no (source|binary) override entry" ?
[12:24] <_ruben> which rings a vague bell .. but dont recall the details :)
[12:27] <directhex> _ruben, want an ultra-simple release file?
[12:29] <directhex> _ruben, use 'apt-ftparchive release' - but you need some hand-crafted preamble before the output from that command
[12:30] <_ruben> directhex: i'd expect it to be created for me .. or that a false assumption? .. there no mention of it on https://wiki.ubuntu.com/PbuilderHowto#Building%20With%20Local%20Packages
[12:31] <directhex> _ruben, i'm afraid i've never used mini-dinstall
[12:32] <_ruben> any clues wrt the "has no (source|binary) override entry" ? .. it sounds familiar, probably ran into smth similar years ago when i did some packaging when we used debian
[12:48] <_ruben> aparently the Release file isnt really required for local usage .. i used the wrong the .changes file with dput (it only "uploaded" the source, not the binary)
=== warp10_ is now known as warp10
[13:14] <_ruben> great .. just got a request to provide a (virtual) server with php4 :/
[13:15] <slytherin> _ruben: You are not supposed to upload binary.
[13:15] <slytherin> _ruben: and if you say it is a mirror then why are you uploading packages manually?
[13:16] <_ruben> slytherin: its stuff im packaging for internal use .. and this "mirror" is on the build system .. to fullfill package dependencies between our own stuff
=== orly_owl_ is now known as orly_owl
=== LucidFox_ is now known as LucidFox
[13:51] <Laibsch> Hi there
[13:52] <Laibsch> I'm Debian maintainer for the gourmet package (I think that is the best way to contribute packages to ubuntu, I don't even run debian)
[13:53] <Laibsch> recently, because of an invalid bug report, somebody added a false dependency on python-metakit
[13:53] <Laibsch> This package does not even exist past gutsy
[13:53] <Laibsch> Can somebody please remove that dependency and upload a new package?
[13:54] <Laibsch> bug 269963 for details
[13:54] <ubottu> Launchpad bug 269963 in network-manager "[intrepid] network-manager should recommend or suggest dnsmasq" [Undecided,Confirmed] https://launchpad.net/bugs/269963
[13:54] <Laibsch> sorry, wrong number apparently
[13:54] <Laibsch> bug 269936
[13:54] <ubottu> Launchpad bug 269936 in gourmet "lacks dependency on metakit" [Low,In progress] https://launchpad.net/bugs/269936
=== luisbg_ is now known as luisbg
[13:59] <directhex> Laibsch, absolutely the best way to 'contribute to ubuntu' is by being the best debian packager you can - ubuntu should be shipping bug fixes etc your way, not the other way round (in most cases)
[14:00] <directhex> Laibsch, depending on a dead package is indeed broken
[14:01] <Laibsch> directhex: exactly
[14:01] <Laibsch> IF the dependency was indeed missing, I'd add it in a flash and be full of shame for forgetting it
[14:01] <Laibsch> But that just ain't true
[14:02] <directhex> let me try the debian package as-is
[14:03] <directhex> unfortunately there's no way to revert the package right now to what we call syncing (just using diff.gz unmodified from debian) as the version in ubuntu is 'newer'
[14:03] <directhex> right, fine, installed, works, where was the problem?
[14:03] <james_w> it can be uploaded with the change reverted though, that's no problem
[14:03] <directhex> yeah, like james_w said, we can do a ubuntu2 version
[14:03] <directhex> to replace the broken ubuntu1
[14:04] <directhex> james_w, whose approval do i need to get that into intrepid before release if i prep a debdiff?
[14:04] <james_w> directhex: no-one at the moment
[14:04] <james_w> directhex: you just need a sponsor
[14:04] <directhex> nobody sponsors me. they go & hide when i appear
[14:06] <james_w> if you prepare a diff and put a link here I'm sure someone will sponsor it
[14:06] <james_w> though using a bug at this point is probably a good idea with the freeze in effect
[14:06] <james_w> you can still ask on here though
[14:06] <directhex> Laibsch, just revert the python-metakit binary depends:, yes?
[14:07] <Laibsch> yes
[14:07] <Laibsch> The other change from that commit seems to be correct for ubuntu
[14:07] <Laibsch> although I wouldn't mind being listed as maintainer
[14:07] <james_w> directhex: yeah, I think so, might as well leave the maintainer field change
[14:07] <Laibsch> As I said, I use ubuntu myself as my main system
[14:08] <directhex> Laibsch, it's normal to set the Mainteiner: to the motu thing. yeah, i know i know.
[14:08] <james_w> Laibsch: that's cool, but it's easier to not have exceptions to that rule, as it would be a headache.
[14:08] <directhex> Successfully signed dsc and changes files
[14:09] <Laibsch> I'm familiar with how debian and sponsoring works
[14:09] <Laibsch> but I think the ubuntu process changed recently
[14:09] <Laibsch> or is it still tauware.de?
[14:09] <directhex> jms@osc-franzibald:/tmp$ diffstat gourmet_0.14.0-1ubuntu1-to-0.14.0-1ubuntu2.debdiff
[14:09] <directhex>  changelog |    6 ++++++
[14:09] <directhex>  control   |    2 +-
[14:09] <directhex>  2 files changed, 7 insertions(+), 1 deletion(-)
[14:15] <Lutin> am I missing something, or should "dpkg-buildpackage: set LDFLAGS to default value: -Wl,-Bsymbolic-functions" should be rather set to -Bsymbolic-functions ?
[14:18] <Lutin> as ld doesn't understand -Wl (assuming that LDFLAGS are to be passed to ld, that is)
[14:20] <dholbach> directhex: I just replied to bug 269936
[14:20] <ubottu> Launchpad bug 269936 in gourmet "Broken dependency on metakit" [Low,In progress] https://launchpad.net/bugs/269936
[14:21] <james_w> Lutin: LDFLAGS should go to cc I believe
[14:21] <directhex> dholbach, the app starts fine for me, without metakit
[14:22] <dholbach> directhex: there might still be an issue that the reporter is seeing
[14:22] <Lutin> james_w: well apparently, that's not how some autofoo/configure does it then (http://launchpadlibrarian.net/17423602/buildlog_ubuntu-intrepid-i386.steam_2.2.31-4.2_FAILEDTOBUILD.txt.gz for example)
[14:23] <dholbach> directhex: it's necessary we revert the addition of the depends, but we can't be sure that it fixes the issue
[14:24] <directhex> dholbach, it fixes that particular bug, which was just saying "this package should depend on that package" (it shouldn't). he has a separate bug about the app failing to start (for him), and i wonder how much of that comes from his mix of every ubuntu release ever in sources.list
[14:24] <dholbach> directhex: I'd prefer to find out before we simply close the bug, but still it's necessary to revert it
[14:24] <directhex> i'll revise the debdiff then
[14:25] <dholbach> directhex: apart from that, it should have been (LP: #<...>) (with the "#")
[14:25] <dholbach> directhex: thanks a lot
[14:25] <dholbach> I'm subscribed so I'll upload it in a bit
[14:25] <Lutin> james_w: and there at least a couple others in the FTBFS list, iirc. anyway, seems there are people out there using ld $(LDFLAGS), and I was wondering how to deal with it
[14:26] <dholbach> directhex: and the diffstat shouldn't be necessary - just the patch would be swell
[14:27] <directhex> dholbach, i try to be complete when requesting sponsorship. not that it's helped the plight of monodoc
[14:28] <dholbach> directhex: gracias
[14:28] <dholbach> slomo: do you think you have a bit of time to look at bug 256853 and see if it's OK?
[14:28] <ubottu> Launchpad bug 256853 in monodoc "[FFe][merge request] Please merge monodoc 1.9-2 from Debian Unstable" [Undecided,Confirmed] https://launchpad.net/bugs/256853
[14:28]  * dholbach has no clue about mono stuff at all
[14:35] <sistpoty|work> hi folks
[14:36] <Hobbsee> heya sistpoty|work!
[14:36] <sistpoty|work> hi Hobbsee
[14:37] <dholbach> directhex: uploaded - thanks a bunch
[14:37]  * directhex counts it as a favour, will come a'callin' in future ;)
[14:39] <dholbach> directhex: favour that I checked and uploaded the fix? no problem ;-)
[14:40] <directhex> yeah, because nothing is important to me like python recipe manager apps
[14:40]  * directhex tries it in ironpython \o/
[14:41] <Laibsch> it's actually a really nice thing to have
[14:41] <Laibsch> for those food lovers among us
[14:41] <directhex> aw, it'd need porting
[14:41] <Laibsch> ;-)
[14:41] <directhex> Laibsch, i can't work out how to make it work
[14:41] <jdong> directhex: to ironpython?
[14:41] <Laibsch> what is ironpython?
[14:41] <jdong> directhex: have you tried including all the site-packages? :D
[14:41] <Laibsch> Some python torture tool?
[14:41] <jdong> Laibsch: it's a .NET/CLR implementation of Python
[14:42] <directhex> jdong, what's the command-line voodoo?
[14:42] <jdong> directhex: what does the python app bork on?
[14:42] <directhex> jdong, you sound clued up. you can't sponsor stuff in main can you?
[14:42] <jdong> directhex: fortunately, no :)
[14:42] <directhex> ImportError: No module named os.path
[14:42] <Laibsch> directhex: Are you generically interested in getting it to work or are you just stating you can't understand its UI (which could see a lot of improvement, I agree)
[14:43] <directhex> Laibsch, i don't really understand how to get ingredients into it, to make a new recipe
[14:43] <Laibsch> We can chat privately if you are interested
[14:43] <jdong> directhex: ah, you can't import dot stuff in ironpython
[14:43] <jdong> directhex: i.e. importing os makes os.path accessible, but importing os.path itself seems to be illegal syntax
[14:43] <directhex> Laibsch, i doubt i have the energy. unless it has a special mode for mixing cocktails! \o/
[14:44] <jdong> directhex: actually... it works here
[14:44] <jdong> WTF?
[14:44] <jdong> directhex: /usr/lib/ironpython/Lib/site.py
[14:44] <jdong> have fun tweaking that to your python site-packages dir :)
[14:45] <directhex> jdong, i don't even *like* python! i just like there being multiple CLR languages to choose from
[14:45] <jdong> directhex: CLR is quite neat
[14:46] <jdong> I like python right now because it's a dynamic language that makes development simple
[14:47] <jdong> though C# is also getting very close to there with Miguel's dynamic C# shell work
[14:47] <jdong> can't wait for someone to hack that to the point that you can just run a .cs file with it
[14:47] <directhex> that'll obviously get packaged up once there's a released tarball, and after the Mono20Transition is complete debian-side
[14:50] <james_w> LucidFox: I'm not quite sure what the correct fix is. It may be possible to make it call gcc instead of ld.
[14:51] <LucidFox> correct fix for what?
[14:54] <james_w> bobbo: hey, you around?
[14:54] <james_w> LucidFox: http://launchpadlibrarian.net/17423602/buildlog_ubuntu-intrepid-i386.steam_2.2.31-4.2_FAILEDTOBUILD.txt.gz <- ld $(LDFLAGS) being called by the build
[14:56] <LucidFox> james_w> What does this have to do with me?
[14:56] <LucidFox> I don't even know what this package is
[14:56] <james_w> LucidFox: ah, sorry, I meant Lutin
[15:15] <geser> james_w: I usually export LDFLAGS similar to the default LDFLAGS but without the -Wl, in debian/rules
[15:16] <james_w> Lutin: ^
[15:17] <sistpoty|work> hi bddebian
[15:17] <Laibsch> james_w: Looks like you were right on the money, there is an old auto-closed bug in the sf.net tracker for gourmet that has the exact strange error message from the other bug report when somebody upgraded from <0.10 to 0.12.  That "you-ship-broken-software" guy hasn't update for three years at least.
[15:17] <geser> A bddebian!
[15:18] <bddebian> Hi folks
[15:18] <bddebian> Hi sistpoty|work, geser
[15:18] <james_w> Laibsch: the encoding error?
[15:18] <Laibsch> yes
[15:19] <Laibsch> which might be another bug
[15:19] <directhex> i wonder if he's even dist-upgraded after changing his sources.list
[15:19] <Laibsch> because the error about encoding problems is incorrect
[15:19] <Laibsch> directhex: he says he did
[15:19] <arvind_khadri> hi, for packaging do i need to follow the debian manual?
[15:19] <james_w> Laibsch: I can see the characters that it is probably complaining about, but I don't know why it doesn't complain for anyone else
[15:20] <Laibsch> james_w: because they are declared
=== lmr is now known as lmr[lunch]
[15:20] <Laibsch> or at least that is what I think why it works
[15:20] <directhex> arvind_khadri, yeah, pretty much, but there are more user-friendly guides on the ubuntu wiki
[15:21] <arvind_khadri> directhex, the things remain the same right ?? :)
[15:22] <directhex> arvind_khadri, yes, ish. there are some tiny differences to bear in mind if you're packaging software for ubuntu main
[15:22] <directhex> arvind_khadri, generally speaking though, the best way to get an app into ubuntu is by getting it into debian first
[15:23] <arvind_khadri> directhex, i want to create a .deb from a tarball  basically and as of now i want to make it work in ubuntu
[15:24] <directhex> arvind_khadri, a well-written source package will compile on either distro (usually) ;)
[15:24] <arvind_khadri> directhex, :) ok so shall i go ahead with the debian manual?
[15:24] <directhex> yes
[15:25] <arvind_khadri> directhex, thanks
[15:27] <arvind_khadri> directhex, the package has been written for fedora btw ...
[15:32] <arvind_khadri> directhex, can i convert it into a .deb?
[15:33] <directhex> arvind_khadri, don't. those conversions are very dangerous to users' systems
[15:34] <arvind_khadri> directhex, ok so if i want to make that particular package be made as a .deb what shall i do?
[15:34] <directhex> arvind_khadri, just follow the debian packaging guide. use the fedora specfile as a reference only for things like the ./configure flags and so on, but generate a clean debian/rules file
[15:35] <directhex> arvind_khadri, in theory, dh_make is a tool to make a skeleton package automatically - but verify the output!
[15:37] <arvind_khadri> directhex, hmm
[15:49] <slytherin> arvind_khadri: which package are you talking about?
[15:55] <bobbo> james_w: pong
[15:56] <james_w> hey bobbo
[15:56] <bobbo> hey :)
[15:56] <james_w> bobbo: did you see Colin's comments on the bzr bug?
[15:56] <bobbo> james_w: yeah, I have a freeze exception for 1.6.1?
[15:57] <james_w> bobbo: I haven't done one for main yet this cycle, so I'm not up to speed on the process, but you have an ACK from one RM at least
[15:58] <bobbo> james_w: cool, I'll look it up but i'm guessing either thats it or i'll only need one more (havent touched main for ages either)
[15:59] <james_w> bobbo: yeah, they were my thoughts too. Are you happy with going to 1.6.1?
[15:59] <bobbo> james_w: yeah it seems to make most sense at the moment as 1.7rc2 hasnt been released yet so it could be a while...
[16:00] <bobbo> and im guessing the longer the release cycle, the more stuff gets changed which means less chance of it getting accepted by -release
[16:00] <james_w> well once rc1 is out only a few things trickle in
[16:00] <james_w> I think 1.7 may be today or tomorrow
[16:00] <james_w> or is it 1.7rc2, I don't remember.
[16:01] <bobbo> james_w: ah didnt know that..i'll have a look and decide soonish but im still leaning towards doing 1.6.1 tbh
[16:01] <james_w> bobbo: I suggest we sync 1.6.1 from Debian after getting the exception, and then cherry pick those important fixes, what do you think?
[16:02] <bobbo> james_w: yeah, makes sense to me, I'll have a look at it in a bit (got some homework to do now). Thanks for your help!
[16:04] <Laibsch> coming back to gourmet, if I may.  The bug report is really a wishlist request to support importation from metakit based recipe collections
[16:04] <Laibsch> Given the fact that the last metakit version of gourmet is about three years old and the apparently sorry state of metakit in general, my motivation to support the switching over from metakit-based recipe collections borders on 0.
[16:05] <james_w> bobbo: great, thanks. Give me a shout if I can help with anything.
[16:05] <james_w> bobbo: and Thursday is Beta freeze, so getting it in before then would be a good idea I think
[16:06] <bobbo> james_w: ok, i'll try to get as much of it as possible done by tonight
[16:06] <Laibsch> Should I leave the bug report open or set it to wontfix.  I guess the one to fix packaging would be me and I don't feel like doing it -> wontfix in that sense.  I won't prevent anyone else from supplying a patch, of course, this is not a conscious choice not to fix things -> not quite wontfix
[16:06] <Laibsch> wontfix or leave open?
[16:07] <azeem> I'd think wontfix mostly applies if you think it's NOTABUG or something, but the submitter disagrees; or have otherwise technical reservations against fixing it
[16:08] <james_w> Laibsch: if Luis confirmed my suspicion I was going to suggest transforming the bug to be "fail more gracefully when metakit isn't available and the user has a metakit based database to import"
[16:08] <james_w> Laibsch: then there could be a second request to re-instate metakit in Ubuntu to allow these people to import.
[16:08] <Laibsch> Well, it seems importation can be done
[16:09] <Laibsch> I collected that information but apparently did not write it here
[16:09] <Laibsch> Let me pastebin it
[16:09] <Laibsch> http://rafb.net/p/YBfPnO87.html
[16:10] <Laibsch> We could fail more gracefully and that would be easy enough to do
[16:10] <Laibsch> Agreed
=== superm1|away is now known as superm1
[16:30] <Lutin> geser: sounds sane, thanks :) (re: LDFLAGS)
[17:19] <Riddell> Adri2000: ping
[17:20] <Riddell> bug 127496 you uploaded to hardy-proposed?  it needs a debdiff on the bug and approval by motu-sru
[17:20] <ubottu> Launchpad bug 127496 in ngircd "ngircd will not uninstall or update" [Medium,In progress] https://launchpad.net/bugs/127496
[17:23] <sistpoty|work> Riddell: just from a glance, maybe the sru is at bug #85266?
[17:23] <ubottu> Launchpad bug 85266 in ngircd "ngircd refuses to start automatically through sysv init" [Medium,In progress] https://launchpad.net/bugs/85266
[17:26] <Riddell> sistpoty|work: mm, seems to be yes, how confusing
[17:53]  * sistpoty|work decides to head home. cya
[18:41] <saivann> siretart : If you have time, can you review and upload debdiff in bug 269725 ?
[18:41] <ubottu> Launchpad bug 269725 in gnucash "gnucash: Obscuring windows after getting transactions with HBCI." [Unknown,Confirmed] https://launchpad.net/bugs/269725
[18:41] <jdong> https://bugs.edge.launchpad.net/ubuntu/+source/ffmpeg-debian/+bug/93849/comments/16
[18:41] <ubottu> Ubuntu bug 93849 in ffmpeg-debian "ffmpeg does not have AMR audio support" [Wishlist,Confirmed]
[18:41] <jdong> grumble.
[18:41] <jdong> now, how do we configure comment blocking in launchpad?
[18:42] <jdong> this is the only good use of the digg style thumbs-up thumbs-down voting
[18:46] <directhex> jdong, FIX MY BUG OR I'LL SWITCH TO YGGDRASIL LINUX INSTEAD!
[18:47] <jdong> directhex: more like fix my bug or I will write a pointless update and ping everyone on motumedia every week.
[18:50] <directhex> jdong, could be worse. i hear some relentless jackasses sit on IRC and insist 'merge my package or i'll spam you on irc'!
[18:50] <jdong> directhex: oh I've already stopped paying attention to IRC pings from unknown people
[18:51] <jdong> directhex: this is aggravating because I try to keep up on all my bugmail because I usually only subscribe to stuff I need to act upon
=== funkyHat|off is now known as funkyHat
[18:51] <directhex> jdong, i'm not spamming you, you're not a core-dev. not worth it ;)
[18:51] <jdong> and it certainly doesn't help that I have to open up that e-mail chain once every 3 days to see that he posted a survey or questionnaire about the bug.
=== warp10_ is now known as warp10
=== ivoks_ is now known as ivoks
[20:21] <Adri2000> Riddell: pong, yes sorry, I didn't make everything clear in the changelog. actually this .2 upload fixes a bug discovered during .1's testing in -proposed, so I just continued the sru process on the same bug. thanks for accepting the upload though
=== fabrice_sp_ is now known as fabrice_sp
[20:40] <fabrice_sp> Hi. Can someone review, and ack if correct, my debdiff for bug #272263? Thanks
[20:40] <ubottu> Launchpad bug 272263 in icedove-dispmua "icedove-dispmua: Package has a Depends on icedove (<= 2.0.0.99) which cannot be satisfied in Intrepid" [Undecided,Confirmed] https://launchpad.net/bugs/272263
=== fabrice_sp_ is now known as fabrice_sp
=== fabrice_sp_ is now known as fabrice_sp
[22:08]  * directhex is sad, his new work laptop is gonna be too new for intrepid
[22:26] <NCommander> soren, ping
=== cr3_ is now known as cr3
=== fta_ is now known as fta
=== superm1 is now known as superm1|away
=== cr3__ is now known as cr3