[00:15] <LaserJock> ScottK: woot, going for DM
[00:37] <zul> LaserJock: dungeon master? :)
[00:37] <LaserJock> heh, something like that
[01:17] <emgent> Chuck ?
[01:18] <zul> shitty gary gygax has passwed away
[02:12] <Hobbsee> effie_jayx: poke
[02:15] <bddebian> Heya gang
[02:20] <crimsun_> bddebian: 'lo!
[02:20] <bddebian> Heya crimsun_
[02:21] <RAOF> Heya crimsun_, bddebian.
[02:22] <bddebian> Hi RAOF
[02:23] <LaserJock> hi bddebian, crimsun_ , RAOF
[02:23] <bddebian> Heh, heya LaserJock
[02:23] <TheMuso> Hey folks.
[02:23] <TheMuso> (Easier to do. :p)
[02:24] <bddebian> Hi TheMuso... :-)
[02:24] <crimsun_> 'lo RAOF, LaserJock, TheMuso
[02:57] <effie_jayx> Hobbsee, yep???
[03:13] <crimsun> TheMuso: I may need you to upload soonish (or post-Alpha 6 - up to you guys now)
[03:13] <crimsun> err, sorry, alsa-driver being the source.
[03:14] <TheMuso> crimsun: Probably post alpha 6 is the best bet atm, but sure I can take care of it.
[03:15] <crimsun> TheMuso: thanks.  Given post-Alpha 6, then, I'll ping you.
[03:15] <TheMuso> crimsun: Sure.
[04:00] <D-Unit> is there a link on the ubuntu wiki that says how to make a .deb? i checked ubuntuforums and found a guide but its not like easy to follow...i dont like guides that always lead u to clicking other links, i like it all in 1 page
[04:00] <TheMuso> D-Unit: I suggest you search the wiki for the packaging guide, and go to http://wiki.ubuntu.com/MOTU to be linked to further information.
[04:05] <Hobbsee> effie_jayx: can you fix libapache2-mod-python please?  at least in gutsy, it appears to depend on 2 versions of python.
[04:08] <D-Unit> TheMuso, https://wiki.ubuntu.com/PackagingGuide ?
[04:08] <TheMuso> D-Unit: I'd say thats the one.
[04:08] <D-Unit> k, thx
[04:57] <LaserJock> oh man, it's awesome when Debian fixes things :-)
[04:57] <LaserJock> I thought my fitting program was gonna be toast
[05:07]  * cody-somerville is actually pretty impressed with his interactions with debian.
[05:07] <cody-somerville> I had heard all this bad stuff
[05:08] <RAOF> I think the deal is that "Debian" as a whole is not a valid unit of social interaction.
[05:08] <Hobbsee> that' strue
[05:08] <Hobbsee> some are nice, some aren't.
[05:09] <RAOF> You can have excellent dealings with individual maintainers, but if you try to interact with "Debian" (by, for example, attempting to become NM), it's icky.
[05:09] <TheMuso> All DDs I've worked with have been great.
[05:09] <cody-somerville> It seems Debian is so big that cliques form
[05:17]  * bddebian refrains from comment
[06:01] <slangasek> cody-somerville: how dare you say that Debian is cliquish, I'm not sitting with you at lunch anymore
[06:01] <cody-somerville> slangasek, hehe :D
[06:01]  * cody-somerville makes a note to sit by slangasek at the UDS.
[06:04] <LaserJock> it's amazing what Debian talks about on it's mailing lists
[06:04] <LaserJock> they really like to hash stuff around
[06:04] <LaserJock> (not that we don't at all)
[06:05] <LaserJock> reading debian-devel and debian-project can be really interesting
[06:05] <slangasek> the mailing lists are important for staying on top of where things are going... but they're definitely not where the work happens. :)
[06:06] <LaserJock> btw, I sent in my application for DM yesterday :-)
[06:06] <LaserJock> and ScottK sent his in today
[06:07] <slangasek> I noticed that, cheers to the both of you
[06:07] <LaserJock> hopefully I won't get booted out in the first week ;-)
[06:11] <cody-somerville> :D
[06:12] <LaserJock> I hope DM will be a real good initiative for Debian
[06:13] <LaserJock> I know it's been a motivator for me
[06:15] <nixternal> oi oi
[06:15] <TheMuso> LaserJock: dm? Is this the same as NM?
[06:16] <StevenK> DM is not the same as NM
[06:16] <LaserJock> TheMuso: no, it's different
[06:16] <TheMuso> Right
[06:17] <LaserJock> Debian Maintainer is for people who don't want to be full Debian Developers yet
[06:17] <TheMuso> Ah.
[06:17] <LaserJock> they are limited to packages they are a Maintainer or Uploader for
[06:17] <StevenK> http://wiki.debian.org/Maintainers
[08:27] <emgent> morning people
[09:52] <\sh> damn..why people assign randomly bugs, just because there is one who uploaded...grmpf
[10:07] <RAOF> \sh: Because they don't understand the process.  And want to make you look bad :)
[10:08] <\sh> RAOF: I blame sbuild ,-)
[10:08] <RAOF> \sh: Yeah, wierd bug.
[10:08] <\sh> because wine works with pbuilder / manual build
[10:11] <soren> Which bug are we talking about?
[10:12] <RAOF> soren: The bug where wine segfaults on everything if built in sbuild/buildd, and doesn't when built in pbuilder.
[10:12] <soren> Sounds like fun. Compared build logs?
[10:13] <RAOF> You'd want to ask \sh that :)
[10:13] <\sh> soren: wine crashing
[10:14] <\sh> soren: I compared everything...there is no change...I also removed dh_strip to get rid of some problems with it...
[10:15] <\sh> soren: funny though: using a snapshot chroot, which is also used for sbuild, and do a manual build...wine works...using sbuild directly -> package binaries -> crash
[10:17] <\sh> soren: so I think something strange happens when building the package...and there is a difference between sbuild and pbuilder
[10:19] <soren> A guy posted to the bug with his ./configure output.
[10:19] <\sh> but I'm at the end with my knowledge, or as you say in german "ich bin am ende mit meinem latein"
[10:19] <soren> It's different from the build logs from launchpad.
[10:20] <soren> checking for -lXi... not found
[10:20] <\sh> soren: yes...because he doesn't do the magic we did
[10:20] <soren> checking for -lXinerama... not found
[10:20] <soren> On Launchpad.
[10:20] <\sh> soren: this is already resolved
[10:20] <\sh> soren: a temp problem...(which is not the cause of the crash)
[10:21] <soren> Did you compare the full build logs?
[10:22] <\sh> soren: yepp....I can reproduce this on any compile host I have...the build logs are the same and even the compile output of the manual build compared to the sbuild log (minus the package building process)
[10:24] <\sh> and if someone has time and wants to help...it'll be appreciated :) I'm lost for now
[10:25] <soren> Do you happen to have the build logs handy from pbuilder where it works?
[10:26] <\sh> soren: my sbuild logs are still available..pbuilder i have to recreate one...
[10:26]  * \sh is just building another one...I have to md5sum check the binaries from the package with the ones I build manually
[10:27] <\sh> soren: I'll publish them when I have the pbuilder logfile..
[10:28] <albert23> \sh: in the bug report you wrote wine does *not* work when built in pbuilder, and it doesn't work for me either. I have a fix to make the pbuilder working again.
[10:29] <\sh> albert23: somehow my last pbuilder try worked...sbuild didn't
[10:29] <\sh> albert23: what did you change?
[10:30] <soren> \sh: sbuild is not really interesting. Launchpad has those, and it's the case where it doesn't work. I want to compare to the case where it *does* work.
[10:30] <albert23> \sh: problem is the standard  LDFLAGS to default value: -Wl,-Bsymbolic-functions set by dpkg-buildpackage
[10:30] <\sh> soren: yepp..you'll get the pbuilder output :)
[10:31] <albert23> \sh: if I reset LDFLAGS and make sure not to strip, it works again
[10:33] <soren> Wine is like a half hour build or thereabouts, no?
[10:33] <albert23> \sh: this is my debdiff: http://pastebin.ubuntu.com/5308/
[10:33] <albert23> \sh: it makes dh_strip and dbgsym creation work again as well
[10:34] <soren> It claims to also fix the segfault? Is that accurate?
[10:34] <albert23> soren: yes it is
[10:34] <albert23> \sh: see also http://www.winehq.org/pipermail/wine-bugs/2007-July/062505.html
[10:37] <\sh> hmm...give me a shot...
[10:38] <effie_jayx> Hobbsee,  ping
[10:38] <albert23> \sh: note the Unexport FLAGS set by dpkg-buildpackage was not needed and is commented out in debian/rules
[10:40] <\sh> albert23: yepp..could you push your change towards the bug report? (bug #191575)
[10:40] <ubotu> Launchpad bug 191575 in wine "wine segfaults on winecfg" [High,Confirmed] https://launchpad.net/bugs/191575
[10:41] <albert23> \sh: yes I will, after first cleaning up the unneeded change
[10:41] <\sh> albert23: much better, if you could checkout the wine debian/dir from ubuntu-wine project
[10:41] <\sh> s/project/team/
[10:41] <\sh> albert23: https://code.edge.launchpad.net/~ubuntu-wine/wine/ubuntu-debian-dir :)
[10:43] <albert23> \sh: sorry, I have not used bazaar before....
[10:52] <\sh> albert23: ok..I#ll do it then when it works :)
[10:52] <\sh> but first lunch...bbl
[11:19] <Hobbsee> effie_jayx: pong
[11:19] <Hobbsee> \sh:
[11:19] <Hobbsee> \sh: because they expect you to fix it if they assign it to you.  duh.
[11:31] <jussi01> If i change the /etc/pbuilderrc file distribution to hardy from gutsy, then run sudo pbuilder update --override-config, that will update my pbuilder to hardy successfully?'
[11:32] <soren> Probably not.
[11:32] <soren> AFAIR distributino is only really used at creation time.
[11:32] <jussi01> soren: ok, whats the correct way to upgrade pbuilder then?
[11:33] <jussi01> delete the base, change the distribution and run pbuilder create again?
[11:33] <soren> You need to either create a new pbuilder from scratch (which I recommend) or change the source.list in your current pbuilder and then run the command you mentioned.
[11:33]  * soren needs food, so goes to lunch
[11:33] <jussi01> ok
[11:33] <jussi01> thanks
[11:54] <emgent> jdstrand, heya :)
[11:54] <jdstrand> hi emgent!
[12:05] <\sh> albert23: you are the hero
[12:06] <albert23> \sh: :-)
[12:07] <\sh> albert23: would you like to give me your realname?
[12:07] <albert23> \sh: it's in the debdiff
[12:11] <stani> Is there anyone later today who can help me uploading Phatch & SPE?
[12:12] <emgent> jdstrand, i have some debdiff for your todolist :P
[12:12] <jdstrand> great!
[12:23] <stani> sorry, wrong channel
[12:35] <tbf> could someone remove the existing gnome-lirc-properties_0.2.2-0ubuntu1.dsc package, please? it is broken.
[12:36] <tbf> hmm... or should dcut do the job?
[12:49] <slytherin> Does anyone know if LZMA is default compression for packages now?
[12:49] <jmehdi> hi, I'd like to know if I could upload a new package on revu even if it is "feature freeze"
[12:53] <jdong> slytherin: no and yes
[12:53] <Hobbsee> jmehdi: you can.  likely no one will look at it
[12:53] <jdong> slytherin: no for most, yes on some large packages
[12:54] <slytherin> jdong: large packages like OOo?
[12:54] <jdong> slytherin: the compression and decompression costs of LZMA are usually several orders of magnitude away from that of gzip/bzip2 so it's not globally enabled
[12:54] <jdong> slytherin: and yes OOo is one of the LZMA'ed packages
[12:54] <slytherin> cool
[12:54] <jdong> indeed
[12:55] <jdong> the other cool thing is that it brings "lzma" into main and installed by default
[12:55] <jdong> which for modern PC's is a great alternative to gzip
[12:57] <zul> meh....dislike doing ffe
[12:59] <jdong> "Bug Fix." I swear. ;-)
[13:01] <zul> sure...:)
[13:05] <emgent>  bug #198731
[13:05] <ubotu> Launchpad bug 198731 in lighttpd "[CVE-2008-1111] Failure to Handle Exceptional Conditions " [Undecided,Confirmed] https://launchpad.net/bugs/198731
[13:14] <Iulian> Hello
[13:15] <mok0> I read in the policy that the distributions field in changelog can be a space separated list of distributions. Does that actually work with the build system?
[13:20] <azeem> mok0: that part is from the old Debian ages, I don't think Ubuntu is using it
[13:21] <mok0> azeem: ok. Seems smart though. Although I don
[13:21] <mok0> t think the distribution information belongs in changelog
[13:21] <azeem> "distribution" as in "hardy", "hardy-backports" etc.
[13:21] <mok0> azeem: yes
[13:21] <azeem> why wouldn't it belong into changelog?
[13:22] <mok0> azeem: because it's a silly to have to create a new changelog entry just because you are compiling a package under a new distribution
[13:22] <azeem> that doesn't follow
[13:22] <mok0> azeem: no?
[13:23] <azeem> you can override the distribution in the .changes file
[13:23] <mok0> azeem: how do you do that?
[13:23] <azeem> vi foo.changes
[13:23] <mok0> :-)
[13:23] <mok0> azeem: because it's a silly to have to create a new change file entries just because you are compiling a package under a new distribution :-)
[13:23] <azeem> well, it's what the Ubuntu autobuilders do with synced Debian packages I guess
[13:24] <mok0> azeem: I think the logical association is that a distribution is a set of packages. A package does not necessarily have anything to do with a distributgion
[13:25] <mok0> In fact, a package can be part of many distributions.
[13:25] <azeem> a source package mabye
[13:25] <azeem> maybe*
[13:25] <mok0> Therefore, it doesn't make sense to define the distribution in changelog
[13:25] <azeem> binary packages tend to get rebuilt for the respective distribution
[13:25] <mok0> azeem: the changelog documents the source package
[13:26] <mok0> azeem: exactly: from the same source
[13:26] <azeem> mok0: well, what's your use case?
[13:26] <azeem> upload the same source to hardy and dapper-backports?
[13:26] <mok0> azeem: I have a bunch of packages that need to be compiled unchanged for hardy
[13:26] <azeem> upload the same source to unstable and hardy?
[13:26] <azeem> mok0: unchanged fro what?
[13:26] <azeem> from*
[13:26] <mok0> azeem: unchanged from gutsy
[13:27] <mok0> azeem: I need to process them all manually to correct the distribution in debian/changelog
[13:27] <azeem> why would you upload package to gutsy at this point?
[13:27]  * slytherin wonders why the heck OOo fails to build on powerpc
[13:27] <mok0> azeem: we run gutsy on almost all machines
[13:28] <\sh> WINE WORKS AGAIN YEEHAA
[13:28] <effie_jayx> does it make sense for apache to have two pyton versions in the depens line?
[13:29] <azeem> mok0: and where are you uploading to?
[13:29] <mok0> azeem: a local repo
[13:29] <azeem> so autobuild the package for gutsy from there
[13:30] <mok0> azeem: autobuild?
[13:30] <azeem> buld the hardy source package for gutsy
[13:31] <azeem> I don't see why you would have to change debian/changelog in this case
[13:31] <mok0> azeem: you mean, just override the distribution?
[13:31] <azeem> yes
[13:31] <azeem> doesn't pbuilder (or whatever you're using) have an option for that?
[13:31] <azeem> sbuild has
[13:32] <mok0> azeem: I haven't seen one for pbuilder... I'm not (yet) using sbuild, although I plan to
[13:33] <mok0> azeem: In fact, I'd like to have a complete building environment, like that in the PPA
[13:33] <mok0> azeem: because I need to build for several distributions and 2 archs
[13:50] <RainCT> tbf: a bit late, but dcut doesn't work on REVU
[13:51] <tbf> RainCT: so some demigod has to cleanup it seems?
[13:51] <tbf> ah! revu's demigod did! :-D
[13:54] <mok0> Hmm. Major upset in openoffice in today's hardy upgrade
[13:54] <soren> Yeah. Excellent excuse to yank the sucker out. I like it.
[13:55] <mok0> soren: Harsh words on an otherwise innocent Wednesday...
[13:57] <\sh> what's wrong with our beloved office app? ,-)
[14:01] <slytherin> apart from that it is blazing fast. :-P
[14:03] <soren> \sh: I'm assuming that's a rhetorical question.. :)
[14:04] <\sh> soren: kind of ;)
[14:05] <soren> Good.
[14:05] <soren> :)
[14:13] <mok0> Trying to figure out what cdbs' tarball.mk is good for. Anyone knows?
[14:16] <azeem> it's for orig.tar.gz's which contain other (possibly multiple) tarballs
[14:48] <hellboy195> \sh: congratulation :)
[14:48] <\sh> hellboy195: no give your congrats to albert23 :)
[14:49] <hellboy195> \sh: true but you also put a lot of work and time into it ;)
[14:57] <\sh> hellboy195: that's one of the duties...:)
[14:58] <emgent> heya
[14:58] <\sh> hellboy195: the only rant i have, the bug was known to wine bugzilla..but was set to closed/invalid
[14:59] <albert23> \sh: I liked the explanation: Don't mess with linker flags unless you understand exactly what they do. Now what would the dpkg developer think of that?
[15:00] <hellboy195> \sh: grrr
[15:01] <\sh> albert23: regarding the wine bugreport...it's wines fault...or better not wines fault, but it's an exception I would liked to know earlier...and it's not any other ones fault of a misbehaving wine...I think wine needs a status like mplayer, which is pushing their own LDFLAGS too
[15:02] <\sh> s/their/its/
[15:10] <\sh> albert23: the fun part about this bug is, that the bugreport was set to closed/invalid, but actually it's not invalid neither should it be closed...
[15:11] <albert23> \sh: yeah, at least they could have given a bit more explanation.
[15:14] <\sh> albert23: so for the next time, I need to refine my searches to include invalids/closed bugs too ,-)
[15:15] <albert23> \sh: Maybe. Actually, first I found the fix. Only when I tried to validate the fix I found that bug report
[15:16] <\sh> albert23: well, after 2 weeks trying to search what was the cause, you don't see the obvious...
[15:16] <\sh> 4 weeks actually
[15:17] <albert23> \sh: it's just that I was caught by those standard flag settings before that made me try this
[15:19] <\sh> albert23: which source was it? :)
[15:20] <albert23> \sh: that was gcal. First it build fine, suddenly it was FTBFS
[15:20] <bddebian> Heya gang
[15:26] <\sh> albert23: but it was CFLAGS in gcals case ... but yes...
[15:39] <emgent> jdstrand, another debdiff for your todolist :P
[15:39] <emgent> bug #198731
[15:39] <ubotu> Launchpad bug 198731 in lighttpd "[CVE-2008-1111] Failure to Handle Exceptional Conditions " [Medium,Fix released] https://launchpad.net/bugs/198731
[15:39] <emgent> hardy fixed by \sh, gutsy, feisty, edgy, dapper ready and tested.
[15:41] <ScottK> \sh: It this a good wine to backport and did you see the note I left for you about kdeguidance wineconfig?
[15:42] <jdstrand> emgent: ok.  thanks!
[15:42] <\sh> ScottK: you can try :) and no..I didn't get the note
[15:43] <ScottK> \sh: Would you please look at the wine related debdiff in Bug #151982 and tell if you think we should do that?  I'm preparing a kdeguidance upload over the next few days.
[15:43] <ubotu> Launchpad bug 151982 in kde-guidance "Wineconfig doesn't detect Wine" [Medium,In progress] https://launchpad.net/bugs/151982
[15:47] <\sh> ScottK: regarding /usr/local/lib* I think it has to follow the very same rules as /usr/lib*...but I would even drop the /usr/local/lib* check complety
[15:47] <\sh> ScottK: and yes, the patch is fine :)
[15:48] <ScottK> \sh: Thanks.
[15:48] <ScottK> The local bit's in there from upstream, so I'll probably leave it.
[15:48] <ScottK> User install stuff in /usr/local it's their problem.
[15:49] <\sh> ScottK: so go ahead :)
[15:50] <ScottK> Main's frozen until the last alpha is released.  Unless someone kvetches about the version I have in my PPA, I'll upload it after the freeze is off.
[15:51] <\sh> ScottK: yepp...
[15:53] <\sh> crimsun: are you working on a fix for libflashsupport?
[16:17] <mdomsch> ScottK, did superm1 get you what you needed yesterday re: kde-guidance?
[16:17] <ScottK> mdomsch: No, but it's a few days yet, so as long as I get it from one of you soonish.
[16:20] <superm1> mdomsch, sorry i got disconnected yesterday when you mentioned my name w/o a log.  what was needed?
[16:20] <mdomsch> I had a bug at one point against kde-guidance, needing new MonitorsDB file from upstream
[16:21] <mdomsch> the copy in the kde-guidance upstream tarball is by definition out of date
[16:21] <superm1> you said that you have some of those guys using hwdatadb on the same page, i'm guessing kde-guidance isn't?
[16:22] <mdomsch> https://bugs.launchpad.net/ubuntu/+source/kde-guidance/+bug/157321
[16:22] <ubotu> Launchpad bug 157321 in kde-guidance "28 new Dell monitors for MonitorsDB file" [High,Fix released]
[16:22] <ScottK> So the question would be are there more?
[16:22] <superm1> everything is marked fix released on that bug?
[16:23] <mdomsch> says 'fix released', but there are plenty more...
[16:23] <mdomsch> in fact, exactly 29
[16:23] <mdomsch> 28 more
[16:23] <ScottK> superm1: I'm uploading a new kde-guidance after the freeze is over, so I'd like to get that wrapped up into it.
[16:24] <superm1> ScottK, should just be a matter of grabbing the latest MonitorsDB on that git tree i'd expect
[16:24] <superm1> and dropping it in place
[16:24] <mdomsch> ScottK, http://git.fedorahosted.org/git/hwdata.git?p=hwdata.git;a=blob_plain;f=MonitorsDB;hb=HEAD
[16:25] <mdomsch> is the new upstream for that file
[16:25] <mdomsch> superm1, right
[16:25] <ScottK> OK.  I can do that.
[16:26] <superm1> mdomsch, ScottK realistically i think it'd be a better idea to stop shipping different MonitorsDB files in different packages, but rather symlink to a "single" MonitorsDB and keep that in sync (add it as a dependency to all the others)
[16:26] <superm1> it's probably too late to do that for this cycle, but its something we should look at doing for Intrepid
[16:27] <ScottK> superm1: I agree.
[16:27] <ScottK> Both with doing and it's to late for this cycle.
[16:27] <mdomsch> superm1, I agree too
[16:27] <mdomsch> the hwdata package in hardy is up-to-date right now with the hwdata git tree
[16:27] <superm1> ScottK, so if you want to have a small BoF at UDS this time around, all that can get organized there
[16:28] <mdomsch> that's where I would expect to see the file live, and kde-guidance get a dep on hwdata
[16:28] <superm1> i can write a spec for it
[16:28] <ScottK> superm1: Please do.  We need to totally revisist displayconfig for Kubuntu for Intrepid in any case.
[16:28] <superm1> alrighty :)
[16:29] <mdomsch> huh, hwdata shouldn't be quite up-to-date, let me rerun my script
[16:30] <ScottK> mdomsch: It'll be a bit before I get to it.
[16:31] <mdomsch> hwdata is in main btw, as is kde-guidance, so no cross problems there
[16:32] <ScottK> mdomsch: Could you also please add this monitor while you're adding so I don't have to maintain it as an Kubuntu unique difference: Bug #192899
[16:32] <ubotu> Launchpad bug 192899 in kde-guidance "New monitor Viewsonic VA702B in MonitorsDB" [Low,In progress] https://launchpad.net/bugs/192899
[16:32] <mdomsch> ScottK, sure, one sec
[16:36] <mdomsch> ScottK, pushed upstream
[16:36] <ScottK> Great.
[16:38] <mdomsch> ScottK, if you're going to have a bunch of those, we can get you commit rights on the upstream repo
[16:38] <ScottK> mdomsch: I probably won't.  I only hit that one because I'm preparing an kdeguidance upload and was trying to cherrypick through the other open bugs and get the easy ones.
[18:06] <ScottK> DarkSun88: Around?
[19:05] <mathiaz> ScottK: for libdb transition, which package should be used in the build-dep: libdb4.6-dev or libdb-dev ?
[19:06] <zul> libdb4.6
[19:06] <ScottK> mathiaz: I'd use libdb4.6-dev so you aren't suprised
[19:06] <mathiaz> Are grepping for transactions in the source code is enough ?
[19:06] <zul> mathiaz: im working on cyrus-imap its a bit more complicated
[19:06] <mathiaz> or is it transaction ?
[19:07] <ScottK> zul: What I told them to do was grep for the word transaction in the package and leave it alone if they found it.
[19:07] <mathiaz> ScottK: ok - thanks.
[19:07] <zul> ScottK: ah ok
[19:08] <ScottK> Trying to get less experienced folks to knock out some of the easy ones.
[19:08] <mathiaz> ScottK: and by them you mean ?
[19:08] <ScottK> mathiaz: You and others when we discussed it in the server team meetings
[19:08] <mathiaz> ScottK: ok.
[19:09] <mathiaz> ScottK: if transactions are used, what are the issues ? migration ? API breaks ?
[19:09] <ScottK> You have to migrate the data to a new structure.
[19:09] <ScottK> mathiaz: Look at pitti's liddb4.6 transition patch in cyrus-sasl2 for an example.
[19:10] <mathiaz> ScottK: ok. So existing datas have to be migrated. However the source code doesn't need to be updated ?
[19:11] <ScottK> As I understand it, yes.
[19:11] <mathiaz> ScottK: ok. Thanks :)
[19:12] <zul> mathiaz: however some the api has changed as well like smtpguard
[19:12] <zul> and cryus-imap as well
[19:13] <mathiaz> zul: when do you catch that error ? when building the package ?
[19:13] <zul> correct
[19:23] <\sh> re
[19:39] <rulus> persia: FYI, the new gnuvd is in Hardy now :)
[19:49]  * \sh hates wireshark ,-)=
[19:51] <hellboy195> \sh: uhh updating wine right now. *Love ya* :D
[19:52] <\sh> hellboy195: beer at linuxtag is appreciated ;)
[19:52] <hellboy195> \sh: I would do it if I'd be there :\
[19:53] <\sh> hellboy195: you need to come :)
[19:53] <hellboy195> \sh: no time, no money :(
[19:53]  * ScottK hands \sh https://wiki.ubuntu.com/UbuntuDevelopment#Removals
[19:53] <ScottK> ;-)
[19:54] <\sh> ScottK: lol yeah...it would be better if we could just inject new upstream versions for wireshark...that would stop my headaches ;)
[19:54] <\sh> cherrypicking patches is boring ;)
[19:54] <\sh> and bug #
[19:55] <\sh> bug #172283 is really a long list...downto dapper;)
[19:56] <ScottK> Personally I have a very strong policy of never running wireshark on a machine that's not well hidden behind an external firewall.  I assume it's got security trouble.
[19:56] <ScottK> If I have to do stuff on the internet I use tcpdump.
[19:57] <\sh> ScottK: I wonder really who the guys are finding out all those issues...I think they don't have a real life(tm)
[19:57] <ScottK> It's a popular package.  They do say that with enough eyes all bugs are shallow.
[19:58] <\sh> ScottK: yes, but presenting a malicious mp3 is really art
[19:58] <ScottK> Yes, but the world if full of artists.
[19:59] <\sh> -ERIGHT:)
[19:59] <ScottK> Last night I went with my wife to see a seamstress about making a dress for her (my brother is getting married next month).  While we were there she was trying to go to the web site of a dress pattern maker and apparently get a typo.
[20:00] <ScottK> She ended up with a pop-up recommending she download some 'security' software.
[20:00] <ScottK> Fortunately she thought before clicking to accept the install and asked me (knowing I know a bit about computers)
[20:00] <ScottK> Dunno what would have happened if I hadn't been there.
[20:01] <\sh> ScottK: I hope she bought you a nice old bottle of <insert your fav drink here>
[20:01] <ScottK> Well she and my wife are still haggling the price of making the dress.  I'm hopin it factors in there.
[20:02] <\sh> hehe
[20:21] <\sh> bah....one CVE but already fixed with an old one...what the heck are they doing
[21:06] <emgent> good night people
[21:10]  * Fujitsu incinerates scipy.
[21:10] <ScottK> Yeah!
[21:11] <Fujitsu> I think I've finally got it building on all archs.
[21:11] <Fujitsu> It doesn't like it on any arch if LDFLAGS is set at all, but works with FFLAGS set everywhere except amd64.
[21:27] <DktrKranz> ScottK, do native packages require a FFe if they ship only bugfixes?
[21:27] <ScottK> No.
[21:28] <DktrKranz> Thanks.
[21:39] <\sh> oh damn...
[21:40] <RAOF> \sh: So wine joy?
[21:40] <\sh> RAOF: much better...my second package I'm buggin in, wireshark
[21:49] <RAOF> \sh: Oooh, someone's fixed dh_strip for wine, too!
[21:50] <\sh> RAOF: na..the fix is -X ;)
[21:50] <\sh> RAOF: but that was already in my local debian/ dir
[21:50] <RAOF> Oh.  Well, it's still 1/3 the size of before :)
[21:53] <\sh> RAOF: well, it should have the size of gutsy again (with some bytes more)
[23:14] <mathiaz> zul: can you have a look at bug 182571 and include it in the samba merge ?
[23:14] <ubotu> Launchpad bug 182571 in samba "smb.conf(5): Poor backspace escaping" [Wishlist,Confirmed] https://launchpad.net/bugs/182571
[23:17] <slangasek> yuck, what's it take to fix the tools being used to generate the manpages?
[23:42] <ScottK> jdong: Ignoring the Main/Universe split for backports is definitely there again.  Please complain.
[23:47] <jdong> ScottK: bug filed
[23:47] <ScottK> Great.
[23:47] <jdong> now we... wait :D
[23:48] <phoenix24> Any tool/program to wrap a text file in 80-col format ?
[23:49] <ScottK> kate?
[23:54] <geser> par?
[23:57] <ScottK> vim?