[01:43] <leleobhz> someone here know a document about tarball.mk on cdbs?
[01:50] <emgent> hi persia, can you open tasks in Bug #240549 ?
[01:50] <emgent> Thanks
[01:52] <persia> emgent: Yes, but it's *always* better to ask generally, rather tha poking a specific person :)
[01:54] <persia> emgent: There's no nominations to approve?  What needs doing?  Which releases are affected?  Please nominate some stuff, and ask someone to approve.
[01:54] <emgent> heheh ok persia sorry :P
[01:54] <emgent> persia: i cant nominate it.
[01:54] <emgent> ok done
[01:55] <emgent> launchpad timeout first.. now work fine
[01:56] <persia> emgent: Great.  Now check rmadison, and ask for approval in the right channel :)
[01:56]  * persia isn't core-dev
[01:56] <emgent> saw first to write debdiff
[01:57] <emgent> uok sorry, and thanks :)
[03:44] <leleobhz> running build_scripts
[03:44] <leleobhz> creating /tmp/buildd/twitteiro-1.1/build/scripts-2.5
[03:44] <leleobhz> error: Is a directory
[03:44] <leleobhz> make: *** [python-build-stamp-2.5] Error 1
[03:44] <leleobhz> someone can help me why this is happening?
[04:07] <genii> Hello. Can anyone recommend to me some good resource for: packaging from a foreign (non Debian) source,    and: working with a previous version of (ubuntu) sources in order to update it.
[04:10] <persia> genii: What are you trying to do?  Update an existing package from a new upstream source?
[04:11] <genii> persia: I think that is what it amounts to. Specifically the pdfedit is at 0.3.2 currently for Hardy, want to package 0.4.1
[04:12] <persia> genii: OK.  What's the current version in Debian?
[04:12] <genii> unstable?
[04:12]  * persia points at packages.qa.debian.org as an easy way to dig up this sort of information
[04:12] <genii> Ah, thanks
[04:12] <persia> Unstable typically, but if your preferred version is in experimental, that can also be interesting.
[04:13] <ScottK> Like the Chinese curse.
[04:13] <genii> Latest in either case in 0.4.1-1
[04:13] <genii> *is
[04:13] <persia> ScottK: Yes, well :)
[04:14] <persia> genii: Great.  Next check the current version in Ubuntu (https://launchpad.net/ubuntu/+source/pdfedit)
[04:14] <genii> Can it be then backported?
[04:14] <ScottK> !backports | genii
[04:15] <persia> genii: You've jumped ahead :)  Yes, the next step is a backport: https://help.ubuntu.com/community/UbuntuBackports
[04:16] <persia> genii: I hope you found that easier than trying to package it from scratch...
[04:18] <genii> persia: 0.4.1 has not yet seemed to have made it from 8.10 to 8.04 yet through backports.
[04:18] <persia> genii: Is there an open request yet?
[04:19] <genii> persia: A user in #kubuntu was recommended to make one, unsure if it was done.
[04:21] <genii> persia: If the scenario was only to have 0.4.1 in Hardy for myself, it would not be a large issue. The sources compile without incident. But then I embarked on a strange journey when trying to find how to package it for Launchpad.
[04:21] <persia> genii: Have you looked at launchpad.net/hardy-backports/+bugs ?
[04:22] <genii> I will look now.
[04:22] <persia> genii: Understood.  The idea is to reduce duplication of work, so everyone can share.
[04:22] <persia> The difficulty is that there is a somewhat complex process involved to make sure that work isn't duplicated.
[04:23] <persia> At the conclusion of your journey, you should expect that everyone who wants the updated version will be able to use it, as a result of your research.
[04:25] <genii> persia: Looks like they made a request (with no reply as of yet) https://bugs.launchpad.net/hardy-backports/+bug/240427
[04:26] <persia> genii: OK.  I believe the next step is for someone to build the intrepid pdfedit on hardy, and report on their success.  You'll need to use pbuilder or prevu for the build.
[04:27] <persia> ScottK: Would it be acceptable to use sbuild or cowbuilder for a test build?  If so, could the process page be updated?
[04:28] <persia> genii: Given your previous effort to update the package, are you up for the test build?
[04:28] <ScottK> persia: Yes.  The page is written primarily for non-developers, so the more accessible tools are emphasized.
[04:28] <persia> ScottK: OK.  It just says "No other build methods will be accepted" in bold print, meaning I'm not likely to backport anything :)
[04:29] <genii> persia: I might need to defer today, this is 14 hours now on the computer
[04:29] <persia> genii: OK.  To answer your original question, the easiest thing for you to do is to download the intrepid source and compile for hardy.
[04:29]  * ScottK looks at the page.
[04:30] <ScottK> persia: I'm pretty sure that was meant to exclude checkinstall and friends.
[04:30] <genii> persia: OK. With the pbuilder?
[04:30] <persia> If you follow the backports process, and update the bug when you do so, anyone else interested in the updated pdfedit will be able to use the backport (after enough testers have confirmed it).
[04:30] <persia> ScottK: I also.  I'm just being (perhaps surprisingly) pedantic.
[04:30] <ScottK> Sure.
[04:30] <persia> genii: pbuilder would work (as would tomorrow if you want a break).
[04:30] <ScottK> I'm the last one to be critical of pedantry.
[04:31] <genii> persia: I'll try tomorrow when I log in from work in about 10 hours
[04:31]  * persia considers the value of lp.net/~ubuntu-pendants
[04:31] <genii> persia: Should I come back here at that time?
[04:31] <persia> genii: Thanks.  Good luck with it.
[04:32] <persia> genii: Come back if you have questions (or just idle to see answers to other people's questions).  There's no requirement to be on IRC while you build or test pdfedit.
[04:32] <nxvl> why are we talking about pedancy?
[04:33]  * genii sips coffee and looks for his Advils
[04:33] <persia> nxvl: pedantry :)
[04:33] <nxvl> oh yes
[04:33] <nxvl> just a typo
[04:33] <nxvl> i'm SO tired
[04:33] <bimberi> nxvl: Capital 'W' :P
[04:33] <nxvl> bimberi: huh?
[04:34] <persia> nxvl: more pedantry ;)
[04:34] <bimberi> in Why.  Sorry, back to lurking and learning for me.
[04:34] <genii> persia: OK, thanks for the tips.You'll see me tomorrow :)
[04:35] <persia> genii: Probably not, as I hope to be asleep then, but someone else will be here.
[04:35] <genii> Heh :)
[04:35] <ScottK> persia: Fixed.
[04:35] <genii> Later, gentle-people
[04:35]  * ScottK goes back to ordering groceries.
[04:35] <persia> ScottK: Thanks.  Now if only I wanted to edit a PDF today...
[04:58] <Hobbsee> ScottK: proposal++
[05:26] <wgrant> ScottK: I think it's going to be a bit hard to bootstrap your new decision making process.
[05:27] <persia> wgrant: How do you mean?  (specifically, where is it likely to fail)
[05:28] <wgrant> persia: Well, we've got to make a decision on a new way to make decisions, which will be hard enough that it can't be made at a meeting.
[05:30] <persia> wgrant: Ah, right.  I was thinking that it might be a sensible pilot of the new process to use the new process to decide if the new process should be used (mind you, I'm not sure the new process as written will be the new process, but haven't yet organised my objections)
[05:40] <TheMuso> persia: I think one needs to be awake to be able to make sense of what you just said. I did, but there are that many occurrances of "new process" that it could make people's head spin. :p
[05:41] <wgrant> Pfft, only 5.
[05:41] <wgrant> And at least they do all refer to the same thing.
[05:41] <wgrant> Except one.
[05:42] <persia> Right.  Next time I'll use "foo" :)
[05:42] <TheMuso> lol
[06:42] <dholbach> good morning
[07:02] <geser> good morning
[08:09] <\sh> TheMuso: bug #239719 that's a totally new upstream version, or did I miss something from the debdiff?
[08:14] <TheMuso> \sh: I didn't check the version number, as I was more concerned at first with the changelog and what was changed before checking the version, so once I find something, I don't usually progress further with reading the diff.
[08:14] <\sh> TheMuso: I'll talk to siegfried about it...
[08:15] <TheMuso> \sh: Ok.
[08:50] <DktrKranz> ScottK: I just prepared a draftt based on what we discussed yesterday: https://wiki.ubuntu.com/StableReleaseUpdates/Draft
[08:51] <AnAnt> Hello, how can I create a diff between 2 diff files ?
[08:52] <persia> AnAnt: Interdiff is the program for that.  Note that it can be confused by certain classes of patches.
[08:53] <persia> DktrKranz: From my reading of the meeting log, it appeared that one criticism of the current policy was that it was established by MOTU SRU.  While the draft looks reasonably clear to me, please be sure to arrange that it gets appropriate validation this time so that we don't have to question it again (and can instead discuss possible specific changes).
[08:54] <AnAnt> thanks
[08:56] <persia> DktrKranz: Also, it's likely worth reviewing the specific language to make sure the filtered include at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification still works.
[08:57] <DktrKranz> oh... really
[08:59] <persia> Well, I presume so.  Best to have testers and developers looking at the same thing.
[09:04] <dholbach> how about a universe sponsoring 5-a-day? we have a lot of good stuff waiting for upload! https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-universe-sponsors
[09:04]  * dholbach processed a bunch of them today
[09:05] <persia> Why 5?
[09:05] <dholbach> do 10 if you like :)
[09:05] <Koon> 10-a-day-and-night ?
[09:05] <dholbach> Koon: :-)
[09:05]  * persia prefers to look at clearing the queue, but admits it's currently a bit of a mess.
[09:06] <DktrKranz> do-as-much-as-you-can-a-day-but-please-more-than-five
[09:07] <DktrKranz> persia: PerformingSRUVerification adjusted, thanks for noticing it
[09:08] <persia> DktrKranz: Erm.  Might not want to adjust the page until the draft is applied.
[09:08] <DktrKranz> persia: it takes directly from StableReleaseUpdates, not from /Draft.
[09:08] <persia> Ah.  That's perfect then :)  Ignore the last.
[09:08] <persia> (and it appears like it will work with /Draft cleanly as well)
[09:10] <DktrKranz> I didn't check, but I guess so, since I took tokens present in both pages
[09:10] <persia> DktrKranz: I had guessed you had checked, as it works so cleanly.  Lucky accident then :)
[09:11] <DktrKranz> yes!
[09:11] <DktrKranz> oh, this is cool: http://edos.debian.net/weather/
[09:13] <persia> DktrKranz: How hard would it be to port?  Might be interesting as a means to attract attention to some of the porting architectures.
[09:14] <DktrKranz> persia: it should be based on edos-debcheck, I think it doesn't require much work. I'll try to look if it's on Debian QA SVN already
[09:49] <Doris> lo, i've been suggested this room for my question. when running dpkg-buildpackage on a project i get "dpkg-shlibdeps: failure: no dependency information found for" - anyone know where this is fixed ? i have a depends line in my debian/control file.
[09:51] <RAOF> Doris: Sounds like you're depending on a broken library; the library package should be shipping a .shlibs file, which tells dpkg-shlibdeps what the dependencies should be.
[09:56] <DktrKranz> persia: debian weather is not online, we asked zack if he could publish it somewhere, he'll do soon. So we can look at it :)
[09:57] <persia> DktrKranz: Cool.  I'm thinking it might be also interesting for the SRU crowd: watch the weather improve.  Might also be a good metric for our release-readiness as we get to that part of the cycle.
[09:58] <DktrKranz> especially for lpia, since it is now an official port (if I'm not wrong)
[09:59] <persia> I think lpia is in the same class as everything else on ports.ubuntu.com.
[09:59] <DktrKranz> launchpad.net/ubuntu/intrepid states it's official
[09:59] <persia> Of course, we can't quite compete with Debian (I expect the sysadmins would revolt if we tried to add that many m68k buildds)
[10:01] <persia> DktrKranz: Interesting.  Last I looked there was a lot of hackery involved in lpia.  Getting that clean this cycle will be a bit of work.
[10:01] <Doris> raof, the one it depends on is one of mine too, so that's fixable. thanks. :) i take it this shlibs file normally lives in the debian dir too ?
[10:01] <directhex> what *IS* lpia?
[10:01] <wgrant> i386 with even more added specialness.
[10:01] <DktrKranz> persia: we lack real hardware to test, even if we have PPAs for test builds... but that's not enough :/
[10:01] <persia> directhex: Low Power Intel Architecture.  It's things like the A110 and Atom.  The IA is essentially IA-32, but there's a couple minor differences.
[10:01] <RAOF> Doris: The debian library packaging guide should give specifics.  dh_makeshlibs is probably what you want to look at.
[10:02] <persia> Also, the toolchain is a little different, and optimised for a different usecase.
[10:02] <wgrant> persia: Ah, so LPIA builds should be used on Atom?
[10:02] <Doris> kk thanks :)
[10:02] <directhex> persia, i was under the impression atom was a "normal" i386
[10:02] <persia> DktrKranz: At least you can buy it now.  I have an A110 laptopishthingy
[10:02] <persia> directhex: It's backwards compatible.
[10:02] <directhex> persia, why give one low-power x86 its own arch, but not another?
[10:03]  * DktrKranz should upgrade his hardware at some point... having a 9-year-old PC as primary box is not so cool
[10:03] <persia> wgrant: For best performance, for some use cases.  One might argue that one ought use amd64 on the Intel desktop series in the same way.
[10:03] <persia> directhex: How do you mean?
[10:03] <wgrant> persia: Does Atom do EMT64?
[10:03] <wgrant> I recall is lacked either vmx or emt64.
[10:03] <persia> wgrant: Nope.
[10:04] <persia> Right.
[10:04] <persia> It's also hardlocked for a maximum of 1GB RAM.
[10:04] <wgrant> Ow.
[10:04] <persia> The A110 shares those shortcomings, but still only gets me 3-hour battery life.
[10:04] <wgrant> Hopefully the post-945 Atom chipset will improve on that...
[10:05] <persia> The poulsbo stuff?  Maybe.
[10:06] <persia> .
[10:06] <directhex> persia, i'm failing to find a reference for how lpia differs from x86
[10:07] <directhex> persia, if we're talking minor compiler flag details whilst it'll still run i386 executables (+ vice versa) then what's special about lpia compared to other needs-special-love x86, like via's CMOV-free C3 chips?
[10:07]  * wgrant is hoping to replace his home router/servery thing with something Diamondville-based at some point.
[10:10] <persia> directhex: I don't have a good answer to that question.  I do know that someone in #ubuntu-mobile was talking about trying to run lpia on a Geode earlier today (but haven't heard results).
[10:11] <wgrant> Geodes are remarkably slow :(
[10:11] <directhex> wgrant, really? you REALLY think it's remarkable? i'd say it's depressingly expected, personally
[10:12] <persia> wgrant: Well, depends on your definition.  I've some slower processors around running linux if you want to have a comparison...
[10:13] <wgrant> persia: ARMs, or some old x86?
[10:13] <persia> wgrant: low-clock ARMs.  Somewhere I have an old 486DX/50 tablet, but I've not tried to load Ubuntu on it.
[10:15] <wgrant> The oldest thing I've run Linux on is our 486DX/50 laptop, and that was about 8 years ago.
[10:16] <directhex> i ran redhat on a cyrix dx2/66 once. the experience made me swear off linux for about 5 years
[10:16] <wgrant> Actually, I might have installed something on our Cyrix 40MHz desktop before that, but I forget...
[10:18] <persia> wgrant: Well, if you want to talk about history, I'll be able to trot out some ancient examples.
[10:18] <persia> Bes current is the H340, which I believe is a 50MHz ARM
[10:19] <persia> s/Bes/Slowest/
[10:19] <directhex> linux on mp3 players isn't a good thing
[10:20] <persia> directhex: Why not?  How is it different than linux anywhere else?
[10:20] <persia> Admittedly, 320x240 isn't much space, and input is limited, but...
[10:20] <directhex> persia, my player shipped with a terrible linux-based firmware. rockbox was a vast improvement
[10:21] <persia> directhex: Isn't rockbox linux?
[10:21] <directhex> and the h3xx series have a <=140mhz coldfire chip. never running at that speed though
[10:21] <directhex> persia, absolutely not. it's their own kernel
[10:21] <persia> Aha!
[10:22]  * persia is multiply enlightened, and clearly ought uninstall linux from that machine.
[10:23] <directhex> persia, http://www.rockbox.org/twiki/bin/view/Main/RockboxKernel
[10:34] <lionel> hi sylvaing :)
[10:34] <sylvaing> hi
[10:35] <sylvaing> lionel, ;-)
[10:43] <Riddell> slomo_: you need to attach the debdiff to bug 239317
[10:44] <slomo_> Riddell: done
[10:46] <Riddell> now poke motu-sru :)
[11:30] <Riddell> superm1: coreavc, a codec package without a codec?
[11:34] <Riddell> superm1: "On Debian & Ubuntu systems, a complete copy of the LGPL v2 can be found under /usr/share/common-licenses/GPL-2"  bad copy and paste?
[11:36] <Riddell> superm1: is there anything from upstream which indicates the source is GPL?
[11:38] <Riddell> superm1: are the patches for mplayer and xine used?  if not how does this package get used?
[12:12] <directhex> Riddell, is it a debconf-powered package, like quake2-data or msttcorefonts?
[12:12] <Riddell> directhex: doesn't seem to be
[12:28] <Laney> I'm getting a FTBFS when attempting to build the vegastrike package from sid. Builds fine on sid/hardy pbuilders but not in an intrepid one. Error: http://pastebin.ubuntu.com/20831/
[12:29] <directhex> pythontastic
[12:29] <Laney> Quite
[12:48] <Laney> Any insights appreciated ;)
[12:49] <directhex> don't look at me, i handle monoish things
[12:55] <ScottK> Laney: I guess I'd be looking at any Ubuntu differences in boost to see if anything looked like a likely culprit.
[12:56] <Laney> ScottK: I've looked at boost, and the same version is in Intrepid and Hardy.
[12:56] <Laney> (builds fine in Hardy)
[12:56] <ScottK> Oh.
[12:56]  * ScottK dunno then.
[12:56]  * ScottK would guess somehow the new compiler flags are screwing with you, but has no idea how.
[12:57] <geser> Laney: have you compared the version of boost-python (or how the package is called) in intrepid and sid?
[12:59] <Laney> geser: sid has -11 and intrepid has -4ubuntu3. But good idea, I'll check the BST
[12:59] <Laney> BTS
[13:02] <RAOF> Laney: I'm getting the same FTBFS with Miro, but I'm yet to really investimigate.
[13:02] <geser> Laney: you might try if using the boost packages from Debian unstable inside your pbuilder helps (if they're installable), so you might know if you need to get boost merged first
[13:04] <Laney> RAOF: I'll let you know if I find anything out
[13:04] <Laney> geser: Will do, thanks
[13:29] <luisbg> ahhhh
[13:30] <luisbg> oops, wrong window
[13:34] <Laney> RAOF: Debian bug #468061 looks promising. Building boost ATM to test.
[13:37] <norsetto> heya heya
[13:37] <persia> Hurrah!  norsetto's here.  Everything will now be done in the next six hours :)
[13:38] <gaspa> persia: are you still awake?
[13:38] <gaspa> :D
[13:38] <norsetto> persia: can I share your drink? Seems powerful
[13:38] <persia> gaspa: Yes.  I've a late meeting tonight.  Tuesdays and Thursdays are the days I'm most likely to be around late.
[13:39]  * gaspa write down this sentence..
[13:39] <gaspa> persia: about nbs. you said that packages.u.c isn't reliable for that. What should i use instead, in your opinion?
[13:41] <norsetto> gaspa: http://people.ubuntu.com/~ubuntu-archive/NBS/
[13:42] <persia> gaspa: The rmadison interface is fairly reliable.  If you can't get that to work, you could ask LP, but there's no good API.
[13:42] <gaspa> norsetto: yes, that's ok.... but i need sourcename, and some other infos.
[13:42] <gaspa> persia: ok, i'll take a look
[13:42] <persia> gaspa: You could also pull a packages file, but you'd need to pull for each architecture, which makes it a bit messy.
[13:42] <gaspa> i see.
[13:43] <persia> gaspa: Hmm.  Looking again, it seems that rmadison doesn't support ports.ubuntu.com.  If you could figure out how what is required, it'd be nifty (although only as an optional switch)
[13:46] <geser> what about the output of "apt-cache madison <pkg>"? it also lists the source package name (if one has a deb-src line)
[13:49] <gaspa> geser: I don't want to depend totally on local sources.list. apt-cache could be a first approach to speed up the process. but i need also a static place(like packages.u.c, but more updated) where get infos.
[13:50] <gaspa> for example, now, i do a local request to get sourcename, and if there isn't in apt-cache output, i fall back to packages.u.c
[13:52] <geser> gaspa: what about wget the Sources.gz from archive.u.c and use grep-dctrl on it? or do you want additional dependencies for the script neither?
[13:53] <gaspa> geser: not now... yes, it could be fine archive.u.c...
[13:54] <gaspa> at least i could try and see if it's not too slow.
[13:55] <geser> gaspa: as a.u.c is only updated hourly, you could refetch the Sources.gz only if they're missing or older than one hour
[13:57] <gaspa> well... the nbs get refreshed every 6 hours, so a more fine timing is pretty unusefull.
[14:04] <gaspa> geser, persia: just for curiosity, why 6 hours?
[14:05] <persia> gaspa: That's the cron configuration for the script that generates them.
[14:06] <norsetto> gaspa: whats your idea for the nbs?
[14:07] <gaspa> norsetto: using a inverse approach, looking the package that depends on them... 'cause they're the ones that  should be fixed.
[14:07] <gaspa> norsetto: http://iogaspa.altervista.org/nbs/reversenbs.xml
[14:09] <gaspa> persia: ok, i meant if there was a _particular_ reason... but don't mind. :) just curiosity
[14:10] <persia> gaspa: Well, it used to be when we bothered the maintainer, so it went into daily cron.  Then someone in Australia pointed out that running it at the beginning of the European workday wasn't ideal for their workflow, so it moved to 6 hours.
[14:10] <gaspa> :D
[14:10] <persia> If there are enough people chasing it quickly enough to justify more frequency, it could be arranged to be as often as hourly, but currently there isn't much value gained.
[14:11] <gaspa> i agree.
[14:15] <gaspa> norsetto: given your question, now i want feedback from you.
[14:16]  * norsetto gives feedback to gaspa
[14:17]  * gaspa gives thanks to norsetto
[14:21] <Laney> RAOF and geser: Updating to the sid version of boost fixed the FTBFS. Thanks for your help.
[14:21] <Laney> (I wonder if it's worth me doing the merge)
[14:22] <geser> Laney: IMHO it doesn't make much sense to sync vegastrike now if it's know it will FTBFS until boost gets merged
[14:22] <amikrop> If you package your Python application as a .deb package with debhelper, then you don't need a setup.py, right?
[14:23] <amikrop> I mean, packaging with debhelper makes setup.py (and distutils) obsolete?
[14:24] <geser> amikrop: not really, debhelper only helps you with common task during package building but it doesn't make distutils obsolete
[14:25] <amikrop> geser: How setup.py (distutils) could be combined with debhelper?
[14:25] <ScottK> amikrop: In your build rule call python setup.py build
[14:25] <geser> isn't calling setup.py the equivalent of make install for a C program?
[14:26] <ScottK> amikrop: In your install rule call python setup.py intall (and then there's an option to tell it where to install).
[14:26] <ScottK> geser: Pretty much.
[14:26] <persia> geser: Well, "setup.py build" is "make all", and "setup.py install" is "make install".
[14:26]  * persia notes that make does more than C
[14:26] <amikrop> ScottK, geser: Aha. Right.
[14:26] <geser> amikrop: if you don't need something special, package a python using distutils with cdbs should be quite easy
[14:27] <amikrop> I see.
[14:27] <ScottK> amikrop: If you want to use debhelper, stepic is a reasonable example.
[14:27] <amikrop> ScottK: What is "stepic"?
[14:28] <Laney> geser: I meant the boost merge
[14:28] <ScottK> amikrop: It's a python package that uses debhelper and distutils.  https://launchpad.net/ubuntu/+source/stepic
[14:29] <amikrop> ScottK: Cool, thanks.
[14:31] <amikrop> ScottK: Actually, how I get the whole dir (with debian/ inside)?
[14:32] <ScottK> apt-get source stepic or dget https://launchpad.net/ubuntu/hardy/+source/stepic/0.3-1/+files/stepic_0.3-1.dsc 0 I'd recommend the later if you don't have intrepid sources in your sources.list
[14:35] <amikrop> ScottK: Actually, if I apply the .diff to .orig.tar.gz will I have the result?
[14:36] <ScottK> If you have the source package and you want to unpack it, the best way to do it is dpkg-source -x filename.dsc
[14:36] <cyberix> What is the compat file for?
[14:37] <ScottK> I should have said dget -x above. That would have unpacked it too.
[14:37] <persia> cyberix: It specifies the lowest major version of debhelper with which the package is compatible
[14:37] <ScottK> cyberix: It says what Debian packaging compatibility level the package supports.  It's roughly equivalent to the major version number of debhelper needed to build the package.
[14:37] <nxvl> dholbach: i show your video on Friday before starting :D it was kewl
[14:38] <cyberix> So why isn't build-dep enough?
[14:38] <amikrop> ScottK: OK, thanks.
[14:39] <ScottK> cyberix: Because using debhelper isn't actually required.  Almost everyone does, but there are other ways to do it.
[14:40] <persia> cyberix: Also because you might build-dep on debhelper 6 for some specific feature, but still have your debian/rules in debhelper 4 format (assuming you are sufficiently lazy, or just doing a quick patch to a package)
[14:41] <POX_> .oO( ScottK is already in T&S )
[14:41] <ScottK> POX_: I have also had to work on Manoj's packages, so I know debhelper isn't a requirement.
[14:42] <POX_> :)
[14:48] <Kopfgeldjaeger> http://launchpadlibrarian.net/15377022/buildlog_ubuntu-intrepid-i386.multisync0.90_0.92.0~svn355-1_FAILEDTOBUILD.txt.gz  <-- looks like a Dependency problem, right? The package builds fine in my pbuilder so I guess it was a temporary problem
[14:49] <persia> Kopfgeldjaeger: Maybe.  Is your pbuilder up-to-date?
[14:49] <Kopfgeldjaeger> ok, in fact it doesn't work in my pbuilder
[14:49] <Kopfgeldjaeger> It worked before my pbuilder update... so there's a problem with an update
[14:53] <norsetto> POX_: thanks for uploading pyelemental again
[14:54] <POX_> norsetto: I've changed debian/copyright a little bit before uploading
[14:54] <norsetto> POX_: ok, I didn't see that
[15:10] <cyberix> I have no idea, if my package would work with debhelper earlier than 5
[15:15] <bddebian> Heya gang
[15:20] <geser> Hi bddebian
[15:21] <bddebian> Heya geser
[15:24] <norsetto> geser: Sie moechten Ihre Zeit fuer Ihr Vermoegen anwenden?
[15:24] <norsetto> geser: (no idea what that means)
[15:25]  * norsetto now also receives spam in german and russian
[15:26]  * jpds doesn't know the last two words in that sentence
[15:26] <apachelogger> actually that sentence is pretty wrong
[15:26] <Hobbsee> norsetto: they want to use your time for your fortune.
[15:26] <apachelogger> grammarwise
[15:27] <Hobbsee> apparently.
[15:27] <Hobbsee> apachelogger: that's what i thought, too.
[15:27] <norsetto> he, not only german spam, but also wrong german spam:-)
[15:27] <sebner> rofl
[15:28] <sebner> norsetto: show the wrong german spam :P
[15:28] <norsetto> well, I spare you all the rest of the email
[15:29] <sebner> norsetto: forwand it to me =)
[15:29] <apachelogger> hm
[15:29] <apachelogger> thinking about it
[15:29] <norsetto> sebner: you gonna get it anyhow, its spamming a whole bunch of ubuntu.com addresses
[15:29] <apachelogger> I think sebner is a mail address aggregator for spamm0rs :P
[15:30]  * sebner hides. they discovered his secret. He is the spamking and uses his adress/contacts to spam the whole world xD
[15:31] <cyberix> norsetto: I just fixed the issues in mi2svg
[15:31] <norsetto> cyberix: good, thanks
[15:32] <superm1> Riddell, its a codec wrapper
[15:32] <superm1> Riddell, like how wine is a windows binary loader
[15:32] <superm1> Riddell, the upstream website indicates it's GPL
[15:32] <superm1> Riddell, but its not in their .orig.tar.gz
[15:32] <superm1> it's on code.google.com
[15:32] <superm1> i filed a bug with them to include the GPL with orig.tar.gz
[15:33] <superm1> which should be documented in the debian/rules part that pulls it
[15:34] <cyberix> norsetto: no problem, please point out any further problems
[15:34] <superm1> Riddell, and that -dev package is intended to be built against.  after this gets pulled in i'll get patches set up appropriately for the other packages that can use it
[15:49] <directhex> superm1, you planning on patching myth et al with coreavc support then?
[15:49] <superm1> directhex, well i'm going to provide two libmyth-0.21's
[15:49] <superm1> one with coreavc support
[15:49] <superm1> one w/o
[15:49] <superm1> since upstream hasn't made it conditional to include it yet
[15:51] <superm1> the build process for doing it like this is a little annoying now
[15:51] <superm1> but i guess stuarta will have it as an option for 0.22
[16:14] <lukehasnoname_> join #freebsd
[16:14] <lukehasnoname_> er
[16:52] <Ekushey> i tried to upload a fonts package to my PPA, and i got the following message: Rejected: Unable to find distroseries: unstable
[16:53] <sebner> Ekushey: use intrepid instead of unstable in your changelog
[16:54] <wasabi> Trying to use dpkg triggers. Figured out that I need a packages .triggers file. However, where do I put the action for the trigger?
[16:54] <wasabi> in the postinst or preinst?
[16:56] <Ekushey> sebner, so i'll just have to replace unstable to intrepid and rebuild the package? is that all?
[16:56] <sebner> Ekushey: yep
[16:57] <Ekushey> thanks sebner
[16:58] <sebner> np
[17:27] <genii> Hello. I was here yesterday, getting some insight into the backport process. In this case pdfedit current version in 8.10 back to 8.04. It was suggested to compile the Intrepid sources with pbuilder and test. I have the sources but am not certain what arguments to pass to pbuilder at this point.
[17:32]  * genii puts on a pot of coffee
[17:33] <Laney> genii: You can build the intrepid version using prevu: https://wiki.ubuntu.com/Prevu
[17:34] <genii> Laney: For Hardy?
[17:34] <Laney> genii: Yeah
[17:34]  * genii reads the wiki
[17:44] <cody-somerville> How does prevu differ from using pbuilder?
[17:46] <genii> Hm. Prevu is giving me "/home/user.pbuilderrc does not exist"  ... will this cause any issue?
[17:46] <ScottK> genii: No.
[17:46] <genii> ScottK: OK
[17:46] <ScottK> cody-somerville: prevu is a simplified wrapper around pbuilder for non-developers to test backports.
[17:47] <ScottK> genii: That just means the default config in /etc gets used.
[17:50] <sebner> !prevu =)
[17:50] <sebner> !prevu
[17:50] <sebner> ha
[17:50] <genii> If I have already a deb-src for Intrepid in my sources will it get confused?
[17:52] <ScottK> It shouldn't.
[17:53] <genii> OK
[17:55] <\sh> moins ScottK
[17:56] <ScottK> heya \sh.
[18:10] <wasabi> So how in the world do I accomplish this:  binary packageA in a source package containing 10 packages needs to be triggered when any of the other binary packages change.
[18:10] <wasabi> I've created debian/triggers, and set it to activate foo-update
[18:10] <wasabi> and debian/packagea.triggers, and insured it was set to interest foo-update
[18:11] <wasabi> And implemented code in packagea.postinst that detects if $1 is triggered, and does work.
[18:11] <wasabi> The code in packagea is never executed, as far as I can tell, and nothing even tries to make it be.
[18:12] <wasabi> And even if I slap it around enouhg, it does evenentually run the triggers.... but BEFORE some dependcies have been set up
[18:14] <Ekushey> when i try to apt-get install a package that i built, i get the "WARNING: The following packages cannot be authenticated!" message. how do i remove it?
[18:16] <directhex> Ekushey, have a signed repository, e.g. don't try to access your PPA directly
[18:17] <Ekushey> directhex, i'm very new to this, this is the first package that i uploaded to my PPA
[18:18] <Ekushey> downloading anything from PPA will give this warning?
[18:18] <directhex> Ekushey, PPA archives aren't signed. you need to mirror them elsewhere (and sign them in the process) to avoid the problem
[18:20] <Ekushey> ok, thanks... i need to study more about it
[18:49] <Ekushey> is there a way i can delete the amd64 build of a package from my PPA?
[18:50] <directhex> i don't think so. you can delete the entire source package & all binaries, though
[18:54] <Ekushey> directhex, so what i can do is change "Architecture: any" to "Architecture: i368" on the control file, rebuild and reupload to PPA?
[18:56] <directhex> yeah, that'd work. why're you hatin' on amd64 though? do real people really use i386 in this day & age?
[18:57] <Ekushey> directhex, this is the actual problem: https://launchpad.net/~ubuntu-bd/+archive/+builds?build_text=&build_state=failed
[18:58] <Ekushey> amd64 and lpia build failed, only i386 build worked
[18:58] <directhex> why is a font architecturey? O_o
[18:58] <directhex> surely ttf files are arch independent?
[18:59] <Ekushey> should be :)
[19:00] <directhex> "any" and "all" aren't the same thing
[19:00] <laga> shouldn't it say "Architecture: all" so it's arch-independent?
[19:00] <laga> yeah
[19:00] <directhex> "all" means a single _all.deb
[19:00] <directhex> "any" means a _i386.deb, _amd64.deb, _arm.deb and so on
[19:00] <Ekushey> oh... so that is the mistake that i did
[19:01] <Ekushey> i'm rebuilding it then
[19:01] <Ekushey> should i delete the current package from my ppa, or will it update itself when i reupload
[19:02]  * Ekushey is a 1-day old packager ;)
[19:02] <ScottK> Increment the revision number and upload again will take care of it.
[19:03] <Ekushey> ScottK, i add it on the changelog?
[19:04] <ScottK> Yes.  Add a new debian/changelog entry with a higher revision number.
[19:04] <ScottK> Use dch -i to get the initial template for the entry.
[19:09] <Ekushey> ScottK, the version number was 0.1-1, the new one is 0.1-1ubuntu1. is that OK?
[19:10] <ScottK> Ekushey: I'd suggest 0.1-1ubuntu1~ppa1
[19:10] <ScottK> That way you can increment as needed (the ppaX part) without affecting 'real' revision numbers.
[19:11] <Ekushey> alright, thanks!
[19:12] <directhex> i'd suggest something alphabetically earlier than "ppa"
[19:13] <directhex> if you're building packages against hardy, then you want something alphabetically earlier than "hardy", to ensure official backport packages will supercede your ppa (e.g. an official backport of foopackage 0.3-2ubuntu1 to hardy will be numbered 0.3-2ubuntu1~hardy1)
[19:15] <Ekushey> directhex, so what should i put?
[19:15] <Ekushey> is there any wikipage explaining the versioning issues?
[19:15]  * ScottK agrees with directhex actually.
[19:16] <ScottK> I actually use Xubuntu1~release1~ppa1
[19:16] <ScottK> Not a simple one.
[19:18] <Ekushey> so i should make it like 0.1-1ubuntu1~hardy1~ppa1?
[19:19] <ScottK> Yes.  That's better than my initial suggestion.
[19:20] <mario_limonciell> well it really depends on when you intend the package to be in use i think
[19:21] <Ekushey> alright, reuploading :)
[19:21] <mario_limonciell> there are cases that you wouldn't want the backport to supercede your PPA
[19:21] <mario_limonciell> say if you were putting in a patch that wouldn't ever show up in a backport necessarily
[19:21] <YokoZar> Hooray, Wine 1.0 in intrepid now
[19:21] <YokoZar> Now...what's the process for getting it into hardy backports?
[19:22] <mario_limonciell> YokoZar, are you the person regularly working on getting wine in Ubuntu?
[19:22] <mario_limonciell> if so, i've got a question for you
[19:22] <YokoZar> mario_limonciell: Yes I am
[19:23] <mario_limonciell> YokoZar, coreavc is leveraging some code from wine from the looks of it.  I'm not sure how old the code is, but it currently fails on amd64.  I was wondering if you glanced over the build log if the failures look similar to old wine failures on amd64 to you.  If so, then I can try to update the code in there and resubmit it upstream to the coreavc project
[19:23] <mario_limonciell> http://launchpadlibrarian.net/15342144/buildlog_ubuntu-hardy-amd64.coreavc_0.1~svn63-0ubuntu1~ppa1_FAILEDTOBUILD.txt.gz
[19:26] <mario_limonciell> YokoZar, regarding your question though, files a bug against the hardy-backports project on launchpad
[19:27] <YokoZar> mario_limonciell: Yeah I just found that part on the wiki :)
[19:27]  * YokoZar looks at build log
[19:30] <YokoZar> mario_limonciell: I'm a bit curious as to what kind of code it is.  Wine only builds experimentally in 64-bit mode; the amd64 package is built by compiling in 32 bit mode and linking with 32 bit libraries (mostly in ia32-libs)
[19:30] <mario_limonciell> YokoZar, oh, i had thought that wine had started to build in 64 bit mode stably since it was showing up on amd64.  That answers the question
[19:30] <mario_limonciell> i'll have to add in a similar workaround for this then for now
[19:31] <mario_limonciell> YokoZar, if you are curious to look over the code, its sitting in intrepid NEW right now or on the ~mythbuntu PPA
[19:34] <sistpoty> hi folks
[19:35] <geser> Hi sistpoty
[19:35] <sistpoty> hi geser
[19:36]  * lukehasnoname hi
[19:37] <bddebian> Heya sistpoty
[19:37] <sistpoty> hi bddebian
[19:43] <norsetto> hi sistpoty
[19:43] <sistpoty> hi norsetto
[19:43] <sistpoty> norsetto: doko merged atlas yesterday \o/
[19:44] <norsetto> sistpoty: \o/ alleluja!
[19:48] <norsetto> sistpoty: argh, still fails on i386
[19:48] <sistpoty> :(
[19:48] <cyberix> norsetto: Did you check my changes?
[19:48] <norsetto> cyberix: no
[19:49] <cyberix> norsetto: Should I encourage sistpoty to look at it or do you still want to complain :-D
[19:49] <cyberix> Well revu day comming tomorrow
[19:49] <cyberix> I could also ask some third guy, if you are getting tired with the package :-)
[19:49] <norsetto> cyberix: is there anything left to complain about!?
[19:50] <cyberix> Well I think fixed everything you brought up so far
[20:14] <medo> hello
[20:15] <medo> I used apt-get into chroot in intrepid and I got exit with error code one.
[20:15] <medo> does that mean my setting for the chroot is wrong
[20:15] <medo> I have followed the steps exactly as in the wiki
[20:15] <geser> medo: what kind of error?
[20:16] <medo> syntax error
[20:16] <medo> in file statoverride
[20:17] <medo> I couldn't file this file anywhere
[20:17] <medo> ??
[20:17] <cyberix> How do you package software that expects to find all it's files in the same directory?
[20:17] <medo> this is the exact output I get "dpkg: syntax error: unknown group `Debian-exim' in statoverride file"
[20:18] <geser> cyberix: would a wrapper work, which cd into the correct dir and calls then the real binary?
[20:18] <cyberix> I suppose it is not hard to make it work
[20:18] <cyberix> I'm just wondering how this fits in with rest of the system
[20:20] <medo> geser: I'm using to install apt-utils so I can use apt-get -install after that
[20:20] <medo> I'm not sure if this would help though
[20:21] <pochu> any lists.tauware.de admin around?
[20:22] <Laney> geser: Do you have any objection to me merging gtkglarea and/or guidedog?
[20:24] <geser> Laney: no, as I don't have time to do merges myself, all my open merges are free to take (but a notification would be nice to know that someone is working on it)
[20:24] <Laney> geser: Ah, that's good to know. I always put a comment on DaD anyway so you'll know if I pick one up.
[20:24] <lukehasnoname> Will Gnome 2.24 make it into Intrepid? It's due out mid Sept.
[20:25] <geser> lukehasnoname: yes, at least it was so in the past that the current gnome version made it into the soon to be released Ubuntu version
[20:26] <geser> lukehasnoname: interpid has already the first gnome 2.23 devel packages
[20:27] <medo> geser: thanks a lot I figured it out. I misconfigured the file
[20:40] <pochu> sistpoty: do you have admin access to mailman on tauware.de? I have issues unsubscribing from a list
[20:42] <norsetto> cyberix: there is something funky with your translations
[20:43] <pochu> hey norsetto, how are you?
[20:44] <norsetto> Hola pochu!
[20:45] <pochu> sistpoty: I'm leaving for dinner, if you are an admin, could you see if there's still any 'pochu@' or 'pochu27@' address subscribed? I unsubscribed @ubuntu address but keep receiving mail... TIA!
[20:47] <sistpoty> pochu: sorry, don't have access to the list... siretart ^^?
[20:47] <sistpoty> pochu: (or you could ask on #ubuntuwire)
[20:48] <Mez> anyone know any good debconf tutorials
[21:19] <pochu> sistpoty: ok, thanks, I'll ask there
[21:33] <mathiaz> Mez: try http://www.fifi.org/doc/debconf-doc/tutorial.html
[21:33] <Mez> mathiaz, thanks - thats the one I found
[21:35] <siretart> pochu: the mailman on tauware will be shut down soon
[21:45] <pochu> siretart: and that list moved to ubuntuwire?
[21:45] <pochu> siretart: if so, will you keep the subscribers list?
[21:49] <siretart> pochu: yes, I copied the complete config over to ubuntuwire
[21:49] <siretart> including subscriptopns
[21:51] <pochu> siretart: ok, I'll keep an eye on it to see if I still have some issues. Thanks for your help
[22:02] <norsetto> good night all
[22:02] <jpds> g'night nor...
[22:02] <LinuxMonkey> night nand
[22:02] <LinuxMonkey> bah
[22:02] <jpds> hehe
[22:02] <LinuxMonkey> he left before i could tab it
[22:02]  * jpds hugs LinuxMonkey 
[22:02] <LinuxMonkey> thanks ill need it
[22:03] <LinuxMonkey> im ready to pull some hairs
[22:03] <jpds> LinuxMonkey: I don't recommend that. You might need them later..
[22:04] <LinuxMonkey> true. trying to understand packages, how to fix my chroot to have my pgp keys and more.lol
[22:05] <ScottK> LinuxMonkey: Why do you need keys in your chroot?
[22:06] <LinuxMonkey> dunno im trying to follow the outdated guides in the wiki
[22:07] <Falken> Hi ! France is out of the Euro2008. Too bad :( Meanwhile, I have my first package (ever) waiting for reviews ... Can I do something to make things go faster ?
[22:08] <ScottK> LinuxMonkey: What wiki?
[22:08] <ScottK> Falken: You're more likely to get satisfaction if you give us a link to the package on REVU.
[22:10] <Falken> of course. http://revu.ubuntuwire.com/details.py?package=flabber
[22:10] <LinuxMonkey> ScottK its probably just me... probably didnt setup intrepid correctly.lol
[22:11] <LinuxMonkey> ScottK: Could not find a signing program (pgp or gpg)!
[22:11] <ScottK> LinuxMonkey: There's no need to sign inside a chroot.
[22:12] <ScottK> You should build (and sign) your source packages and then build them in a clean environment using pbuilder, sbuild, or similar.
[22:13] <LinuxMonkey> well im lost then, the guides are out of date, ill have to wait and see then, cause i really want learn this
[22:14] <sistpoty> ember: around? (I'm just looking at bug #237348)
[22:14] <ScottK> LinuxMonkey: What guide are you following?
[22:14] <LinuxMonkey> ScottK: https://wiki.ubuntu.com/PackagingGuide/Complete
[22:15] <YokoZar> Does anyone have a Gutsy and Feisty machine around to do a real quick test for me?
[22:16] <ScottK> YokoZar: Does it need to have X on it?
[22:16] <ScottK> LinuxMonkey: I don't see on that wiki where it says to sign stuff inside a chroot.
[22:16] <YokoZar> ScottK: Just want to see if the Wine package is installable, I imagine you dont
[22:17] <YokoZar> ScottK: https://edge.launchpad.net/~ubuntu-wine/+archive
[22:17] <ajmitch> YokoZar: making 1.0 available for us mortals?
[22:17] <YokoZar> I made a small change to debian/rules that I'm not certain the build daemon would barf on (ie it might be depending on a version later than what's available in gutsy)
[22:17] <ScottK> YokoZar: I'd just do that in a chroot then if I were you (pbuilder login).
[22:17] <YokoZar> ScottK: Yeah I didn't set up pbuilder yet, heh
[22:18] <YokoZar> I just use the ppa to build now
[22:18] <YokoZar> This is the last gutsy/older package for me at the moment
[22:18] <sistpoty> ajmitch: you just want it to play WoW, don't you? :P
[22:19] <LinuxMonkey> lol i allready play wow on here.lol
[22:19] <ajmitch> sistpoty: of course
[22:19] <sistpoty> heh
[22:19] <YokoZar> ajmitch: by the way, if you'd like to make 1.0 available to more mortals: https://bugs.edge.launchpad.net/hardy-backports/+bug/240755
[22:20] <LinuxMonkey> ScottK: ok well i guess im lost and probably followed that guide all wrong.lol
[22:20] <RainCT> If I want to backport a package that needs the cmake version from Intrepid, can I request a backport for both?
[22:20] <ajmitch> YokoZar: however I'm not in any backports team :)
[22:21] <YokoZar> ajmitch: still needs a confirm/triage (ie, build and test it)
[22:21] <ScottK> RainCT: You can request it, but what affect would that have on other packages?
[22:21] <RainCT> ScottK: that's why I ask :)
[22:21] <YokoZar> RainCT: cmake is a build tool used by other packages right?
[22:21] <YokoZar> It's unlikely it'd be backported in that case
[22:22] <ScottK> RainCT: I'd suggest teaching the package to work with the older cmake.
[22:22] <ajmitch> though cmake may be backwards compatible, backporting it may actually be safe
[22:22] <Laney> Is SHELL=/bin/bash allowed in a rules file?
[22:22] <ajmitch> unlike tools like automake with its 20 different versions
[22:22] <ScottK> That's probably require more testing than RainCT wants to do to confirm though.
[22:23] <sistpoty> Laney: yes... debian/rules is a makefile and SHELL=something that's the shell to be called from make to something
[22:23] <RainCT> well, I'll ask upstream (who asked me for the backport, although I don't know them :P) if they are happy with having it in a PPA (or if they want to get it working with cmake from hardy)
[22:23] <sistpoty> s/that's/sets/
[22:23] <jpds> RainCT: I suggest building the whole of KDE4, just to make sure it's safe to backport
[22:23] <RainCT> thanks guys :)
[22:23] <Laney> sistpoty: Right, thanks. I just didn't know if it had to remain as dash or anything
[22:24] <sistpoty> Laney: no, you don't as bash is in essential (if you'd use a custom shell not in (build)-essential, it'd need to be in build-depends though)
[22:24] <Laney> Got it :)
[22:25] <sistpoty> Laney: you might get extra points to eleminate bashism in debian/rules though (but if unsure, shell=/bin/bash seems like the most defensive solution though)
[22:26] <Laney> sistpoty: Nah, I'll not bother. I'm looking into whether do do a sync or merge, and leaving it as bash lets me do a sync so it's best to keep it as is.
[22:28] <ScottK> Laney: Switching to dash is a Debian release goal, so if you can resolve the bashism, it'd be a useful patch for Debian too.
[22:29] <ScottK> Without knowing how hard it is, I'd suggest fixing it to use dash and then filing a bug/patch with Debian.
[22:30] <Laney> ScottK: Someone already sent a fixed (to use dash) rules file to a bug on the BTS as there was an error with the bash version, but he chose to just fix the bug and keep it on bash. So there is a patch already.
[22:34] <sistpoty> ScottK: there's no bashism, if SHELL=/bin/bash ;)
[22:34] <ScottK> sistpoty: That just makes the bashism work.
[22:34] <sistpoty> or rather its completely allowed to use a bashism then
[22:34] <sistpoty> heh
[22:34] <ScottK> Sure, but it's still not idea.
[22:34] <ScottK> idea/ideal
[22:35] <sistpoty> hm... not too sure. for debian alone, it's not much of a big deal. as upstream who deals with building on other unices (like *bsd) as well, there is (as bash != bash there :()
[22:36] <Laney> Is this enough of a deal to stop me requesting a sync?
[22:36] <Laney> (Given that the maintainer is aware)
[22:36] <sistpoty> Laney: imo no, but you could still write a patch and forward it to DBTS ;)
[22:37] <Laney> sistpoty: It already exists, as I said above!
[22:37] <Laney> I'd give you a link but the bts isn't responding for me atm
[22:37] <sistpoty> Laney: heh, then just request a sync
[22:38] <Laney> sistpoty: Good, I will
[22:38] <Laney> Thanks :)
[22:38] <sistpoty> np
[22:40] <Laney> So while I wait for that to testbuild, can someone shed some light on why bug #181225 was invalidated? It seems sensible to me.
[22:40] <bobbo> can someone post their output of "sudo apt-get build-dep audacious" quickly?
[22:42] <Laney> bobbo: On Hardy?
[22:43] <bobbo> Laney: yeah
[22:43] <i4x> hugs 4 every1!!
[22:43] <Laney> bobbo: See notice!
[22:43] <sistpoty> Laney: seems to be some fallout of the Kmos debate back then... you might want to check if it's still valid or not
[22:44] <Laney> sistpoty: It is
[22:44] <sistpoty> Laney: then go and set it back to a sane state ;)
[22:44] <Laney> Righto
[22:58] <ScottK> \sh: I hope you're OK with the latest claws-mail upload.
[23:06] <bdmurray> I'm curious if something is packagable.  I'm uncertain about the firmware parts involved.
[23:07] <bdmurray> It's the R5u870 driver.
[23:08] <ScottK> Do you have a link to the relevant license text?
[23:08] <ScottK> bdmurray: ^^^
[23:10] <bdmurray> ScottK: the tarball is linked to at http://wiki.mediati.org/Installation
[23:14] <sistpoty> bdmurray: ugh, the firmware seems to be extracted right out of the windows driver, so I doubt it's easily redistributable
[23:14] <sistpoty> bdmurray: at least not via GPL as advertised in COPYING
[23:14] <bdmurray> sistpoty: Okay, that is what I had thought but wasn't certain.
[23:15] <ScottK> sistpoty: Copied or reverse engineered?
[23:18] <bdmurray> It looks like it might be possible to reverse engineer it
[23:19] <bdmurray> Oh, maybe not.
[23:20] <sistpoty> ScottK, bdmurray: according to recode-fw.scm extracted from the windows driver
[23:20] <sistpoty> (nontheless, even if reverse engenieered, it would lack the source code for gpl-2)
[23:23] <sistpoty> bdmurray: however it might be possible if the firmware could be shipped separately (or downloaded by maintainer scripts) from the driver
[23:24] <ScottK> However I'd be reluctant to do that with something that claimed to be GPL, but wasn't on the face of it.
[23:25] <bdmurray> There is a launchpad bug report, if we could get to it ;-), about this particular driver and packaging it.
[23:26]  * ScottK suggests invalid as an appropriate status.
[23:28] <bdmurray> Maybe "Won't Fix" because of the current way it stands?
[23:28] <sistpoty> ScottK: well, the driver itself looks fine (at least each file has gpl headers). The only problem I see is that the firmware would need to get downloaded and extracted from the windows driver on package install (or by a package in multiverse, depending on the license of the windows driver)
[23:39]  * sistpoty goes to bed... gn8 everyone