[00:15]  * invaleed is away (Please give me hug)
=== invaleed is now known as in[v]aleed
[00:16] <Hobbsee> in[v]aleed: please turn that off.
[02:53] <rjune__> are there instructions on building a Jaunty chroot?
[02:54] <stdin> rjune__: install a intrepid chroot and upgrade it to jaunty
[02:54] <rjune__> where can I find instructions on building an intrepid chroot?
[02:54] <nellery> rjune__: https://wiki.ubuntu.com/PbuilderHowto
[02:54] <Elbrus> stdin: why not: install a jaunty chroot?
[02:54] <rjune__> nellery: thanks
[02:56] <stdin> Elbrus: because I use debootstrap, and it doesn't have jaunty yet
[02:58] <Elbrus> stdin: I think just make a softlink in /usr/share/debootstrap/scripts from jaunty -> gutsy
[02:58] <Hobbsee> stdin: it knows about jaunty - or at least, the backported version does
[02:58] <stdin> that would probably work, yeah
[02:59] <stdin> Hobbsee: ah, so it does
[02:59] <rjune__> a large percentage of folks here are from canonical, yes?
[03:00] <stdin> probably a small percentage
[03:00] <stdin> tiny, in fact
[03:08] <ScottK> The backported debchroot does know jaunty for Hardy and Intrepid.
[03:08] <ScottK> Backported debchange does too.
=== jussio1 is now known as jussi01
[04:38] <jdong> RFC: I just told bug 275375 to submit deluge-team's PPA packaging to REVU
[04:38] <ubottu> Launchpad bug 275375 in deluge-torrent "Please upgrade to deluge-torrent 1.0.6" [Wishlist,Triaged] https://launchpad.net/bugs/275375
[04:39] <jdong> 1.x.x is a complete rewrite compared to our existing 0.5.x and they redid all the packaging too
[04:39] <jdong> given that there is NOTHING in common between this and what we have in our repos other than the name of the software, I think it's appropriate to treat it as if it were brand-new
[04:39] <jdong> any thoughts? disagreements?
[04:40] <Hobbsee> jdong: hmm....fair call, to an extent, but REVU is still quite slow
[04:40] <jdong> aye; I'd be happy to take the first look at the packaging but I just wanted to get the thing onto a QA platform
[04:41] <Hobbsee> (the problem would be if it never quite got thru REVU, and we released with the old version)
[04:41] <Hobbsee> apart from taht, i'd say REVU is a fair place to put it
[04:41] <jdong> yeah, we need to take care to look at it once it appears on REVU
[04:42] <Hobbsee> just put a note of the above on the submission, so people don't try and push towards debdiffs / interdiffs / whatever diffs we're using this week ;)
=== nhandler_ is now known as nhandler
[04:49] <jdong> "Please backport the Jaunty version of Banshee to Intrepid. A few other
[04:49] <jdong> dependencies are needed as well.
[04:49] <jdong> "
[04:49] <jdong> I love the way the 2nd sentence was so nondescriptively and helpfully worded :)
[04:51] <StevenK> "No."
[04:53] <jdong> well at least he said Please, right? :)
[04:54] <Hobbsee> therefore, it should be "No.  Thank you"
[04:54]  * jdong peeks in the Banshee Team PPA
[04:55] <jdong> HOLY SMOKING CRAP: https://edge.launchpad.net/~banshee-team/+archive
[04:55] <jdong> that's not just a "few" dependencies that's half the mono/cli stack!
[04:58] <Hobbsee> trivial, for a crack person.
[04:58] <Hobbsee> !jdong
[04:58] <ubottu> <Hobbsee> jdong: yes, but you're FULL OF CRACK!
[04:58] <Hobbsee> mind you,  it must *really* be full of lots of crack, if jdong says it is :P
[05:01] <jdong> :)
[05:53] <Elbrus> anybody mind updating my (debian) package winff so that it can fully use ffmpeg in ubuntu (bug 304249) (debdiff available in the bug report and only changes in debian dir)
[05:53] <ubottu> Launchpad bug 304249 in winff "[jaunty] Presets are not compatible with the ffmpeg version " [Undecided,Confirmed] https://launchpad.net/bugs/304249
=== thekorn_ is now known as thekorn
[08:06] <eMerzh> if some motu want to celebrate his revu day by reviewing my package : http://revu.ubuntuwire.com/details.py?package=sqliteman thanks!
[08:08]  * RAOF bites
[08:11] <iulian> :)
[08:34] <directhex> jdong, mono is disallowed for backporting, so you can just give a simple "no" :p
[08:36] <directhex> jdong, of course, you can no longer trivially backport CLI apps from jaunty, what with the mono 2.0 transition.....
=== wgrant_ is now known as wgrant
[09:22] <RAOF> Man, copyright sucks.
[09:23] <directhex> RAOF, whyso?
[09:23] <RAOF> Allow me to elaborate: /checking/ the copyright of packages sucks.
[09:44] <RAOF> eMerzh: The mechanical parts look good.  As almost always is the case, there still appears to be some copyright fun waiting for you :/.
[09:45] <eMerzh> Thanks a lot for your review RAOF! .... so i'll dive into the copyrights things :)
[09:48] <RAOF> I'm not sure whether it matters that your Copyright credits are overbroad, but I would be listing the actual holders of the copyright for each of the files, rather than saying the set of all people who claim copyright in one or more files has copyright over *
[09:49] <RAOF> eMerzh: Actually, I'd also suggest mentioning in README.Source that the shipped copy of qtscintilla isn't actually used in the build.  That's something that's nice to know from the get-go :)
[09:50] <eMerzh> RAOF: ok, ...but about readme.source, a motu told me that it was unecessary... so i' remove it...
[09:52] <RAOF> eMerzh: That would have been before you added the patches; Policy 3.8.0 says that you should have a README.Source if dpkg-source -x doesn't result in the extraction of the sources as-built.
[09:52] <RAOF> And since you already need one for that, it'd be nice to add something about the qtscintilla :)
[09:53] <slytherin> eMerzh: RAOF: Please refer to https://wiki.ubuntu.com/README.sourceHowTo
[09:56] <RAOF> slytherin: By "point to", what does that page mean?
[09:56] <RAOF> slytherin: filesystem link?  Have a README.Source that just says "see /usr/share/whatever"?
[09:56] <slytherin> RAOF: I am not sure, probably mention it in README.Debian. :-D
[09:57] <slytherin> RAOF: Or as you pointed in README.source. Some thing similar to what is done for common licenses.
[09:57] <RAOF> Right.
[10:00] <eMerzh> slytherin: so for my package, did i restore my previous README.source with a mention to the dpatch/README.source.gz ?
[10:01] <eMerzh> slytherin: should i restore ...
[10:01] <slytherin> eMerzh: Yes, just a mention, not complete text.
[10:02] <eMerzh> slytherin:  like this, http://bazaar.launchpad.net/~emerzh/%2Bjunk/sqliteman/annotate/11?file_id=readme.source-20081119183320-4q86ddc5u42k2iqo-1 is it ok?
[10:04] <slytherin> eMerzh: Change the text in first line to - "This package uses dpatch in order to apply patches to the upstream source. Patches are stored in debian/patches and their filenames usually end in .dpatch"
=== not_rly is now known as orly_owl
=== _jason is now known as jrib
[11:32] <_Groo_> hi2/all
[11:32] <_Groo_> is this the right place for kubuntu devel also?
[11:33] <mok0> _Groo_: ... did you try #kubuntu-devel :-)
[11:34] <_Groo_> mok0: did now :)
[11:34] <_Groo_> thanks
=== asac_ is now known as asac
=== in[v]aleed is now known as invaleed
=== fta_ is now known as fta
=== thunderstruck is now known as gnomefreak
[14:22] <RainCT> heya
[14:23] <handschuh> RainCT: yo!
[14:24] <JontheEchidna> mok0: oh, by the way. Tagging for KDE 4.2 beta2 is taking place on the seventh, so next week we're going to be packaging it if you would like to help.
[14:25] <mok0> JontheEchidna: I'll make a note...
[14:25] <mok0> JontheEchidna: Will it be in #kubuntu-devel
=== thunderstruck is now known as gnomefreak
[14:35] <Tetracomm> Hello.
[14:35] <RainCT> hi
[14:35] <Tetracomm> I got a tarball and want to know what the dependencies for the program are, how do I check?
[14:36] <directhex> Tetracomm, checking configure.in or configure.ac is a good step
[14:41] <Tetracomm> Horribly long file.
[14:41] <Tetracomm> :S
=== RainCT changed the topic of #ubuntu-motu to: Masters of the Universe - https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Jaunty: OPEN. | Grab a merge: http://dad.dunnewind.net http://merges.ubuntu.com | http://qa.ubuntuwire.com/uehs | It's REVU Day, go review :)
[14:43] <RainCT> Tetracomm: yeah, there are funnier things than finding out dependencies :)
[14:44] <Tetracomm> I need help.
[14:47]  * RainCT reviews scim-wijesekera
[14:51] <RainCT> really stupid question (blame CDBS *g*.. and exams which kill my brain! :)), but shouldn't   "./configure --prefix=/usr" (in debian/rules)   point to $(CURDIR)/debian/<pkgname>/usr/ ?
[14:51] <directhex> nope!
[14:52] <directhex> ./configure --prefix=/usr
[14:52] <RainCT> directhex: ohh, I'm getting stupid then XD
[14:52] <directhex> make DESTDIR=$(CURDIR)/debian/tmp install
[14:52] <RainCT> ah okay
[14:53] <RainCT> directhex: thx
[14:55] <Tetracomm> Can anyone else help me to find the dependencies of a program in a tarball?
[14:55] <RainCT> Tetracomm: have you checked if there's a README or INSTALL file listing them?
[15:03] <Tetracomm> Yes.
[15:03] <hyperair> when does a package get a -dev, and when doesn't it? i noticed that geany has headers within it. howcome that isn't split into a geany-dev package or something?
[15:07] <JontheEchidna> hyperair: generally when another package needs the development headers to build
[15:08] <JontheEchidna> if no software requires the headers to build they are either just thrown in with the rest of the package (in the case of small packages) or into debian/not-installed
[15:09] <hyperair> JontheEchidna: debian/not-installed? is that a file?
[15:09] <JontheEchidna> yup
[15:09] <hyperair> interesting. i never knew there was such a file. i thought that if there's an install file, everything left out of install won't be installed?
[15:10] <JontheEchidna> right, but having a not-installed makes it easier to keep track of what is purposefully left out
[15:10] <hyperair> i see. yeah
[15:10] <JontheEchidna> because new files can be introduced with new releases of software
[15:10] <JontheEchidna> yeah
[15:10] <hyperair> yeah i didn't think of that
[15:10] <hyperair> thanks =0
[15:10] <hyperair> =)*
[15:10] <JontheEchidna> :)
[15:49] <rjune> where does pbuilder create it's build environment?
[15:51] <JontheEchidna> rjune: /var/cache/pbuilder/build
[15:52] <rjune> thank you
[15:53] <JontheEchidna> yw
=== Richie is now known as WelshDragon
[16:03] <rjune> every call of pbuilder generates a clean build environment?
[16:05] <JontheEchidna> yes
[16:05] <JontheEchidna> each has a different folder in the build dir
[16:05] <rjune> that could get big
[16:05] <JontheEchidna> they get deleted after the build is done
[16:06] <rjune> I'm on an intrepid box currently, I was told just install pbuilder then update the chroot.
[16:07] <rjune> https://wiki.ubuntu.com/PbuilderHowto?highlight=(pbuilder)#Installing Pbuilder on Warty, Hoary or Breezy <-- that's the relevant bit to build jaunty from intrepid, yes?
[16:09] <JontheEchidna> I use the instructions here: https://wiki.ubuntu.com/PackagingGuide/Complete#The%20Personal%20Builder:%20pbuilder
[16:11] <ScottK-laptop> For a Jaunty pbuilder, you'll need some packages from intrepid-backports
[16:11] <ScottK-laptop> That or make an intrepid one and upgrade it.
[16:12] <rjune> ScottK-laptop: so pbuilder update? or pbuilder upgrade?
[16:13] <rjune> I have a pbuilder environ on intrepid already
[16:13] <ScottK-laptop> rjune: Then you can use pbuilder login --saver-after-login and then upgrade while you're logged in.
[16:21] <DRebellion> Hey guys, can anybody take a look at Cifer (a tool for analysing and cracking classical ciphers) in revu? http://revu.ubuntuwire.com/details.py?package=cifer
[16:22] <directhex> can it do 4-rotor enigma code?
[16:24] <DRebellion> directhex, -.-
[16:25] <DRebellion> no, we didn't get into the wwii machine stuff
[16:25] <directhex> a classic if ever there was one!
[16:25] <directhex> hackable by the british though :/
[16:26] <DRebellion> hmm... i think it can do only pen and paper cifers..
[16:26] <DRebellion> but then, all 'classical' ciphers are pen and paper
[16:41] <ScottK-laptop> DRebellion: One quick comment: Don't include the debian dir in your orig.tar.gz.
[16:42] <DRebellion> ScottK-laptop, sorry =/
[16:42] <DRebellion> i did have a bad feeling about releasing it in our source tarball
[16:43] <DRebellion> ScottK-laptop, would it be wise to release an upstream 1.0.2 and remove the directory?
[16:48] <bmm> I'm looking for comments or the first advocate on: http://revu.ubuntuwire.com/details.py?package=metalink Thanks in advance.
[16:49] <rjune> to upgrade to jaunty, simply update the sources file for apt, then do update/upgrade, right?
[16:49] <directhex> and pray
[16:49] <rjune> LOL
[16:51] <pochu> rjune: better use update-manager
[16:51] <laga> hey rjune
[17:23] <bddebian> Damnit, I know I've done it before.  How do I pass DEB_BUILD_OPTIONS to pbuilder?
[17:30] <ScottK> DRebellion: Yes.
[17:30] <DRebellion> ScottK, already underway ; )
[17:30] <ScottK> rjune: Better don't upgrade.
[17:37] <DRebellion> How can I determine which version of debhelper i should depend on? Is there some magical tool that will check my source package for the features it uses?
[17:41] <quadrispro> RainCT, I've read you messages some day ago...
[17:42] <stdin> DRebellion: should be the same version as in debian/compat
[17:43] <stdin> so if debian/compat contains 6, then you build-dep on debhelper (>= 6)
[17:43] <DRebellion> stdin, yes, but how do i know what version to put in debian/compat? I'm trying to get away with the lowest version possible.
[17:46] <stdin> I say to try 5 first
[17:46] <DRebellion> stdin, ok, then keep working up? gotcha.
[17:47] <ScottK-laptop> DRebellion: It's a question of what version of debhelper your package needs.
[17:47] <DRebellion> ScottK-laptop, i'm not sure how to determine this though?
[17:47] <DRebellion> in any other way than trying each out, that is.
[17:48] <ScottK-laptop> One way is looking the the changelog for debhelper and figuring out of you're using any features from a particular release.
[17:49] <ScottK-laptop> DRebellion: 5 is fine for your package.
[17:49] <DRebellion> ScottK-laptop, ok, thanks
[17:49] <ScottK-laptop> Make sure the versioned depends on debhelper in debian/control matches
[17:49]  * invaleed is away (Please give me hug)
=== invaleed is now known as in[v]aleed
[17:49] <ScottK-laptop> !away | in[v]aleed
[17:49] <ubottu> in[v]aleed: You should avoid noisy away messages in a busy channel like #ubuntu, or other Ubuntu channels; it causes excessive scrolling which is unfair to new users. Use the command "/away <reason>" to set your client away silently.  See also «/msg ubottu Guidelines»
[17:50]  * jdong notes that's his 2nd warning in 12 hours
[17:50] <ScottK-laptop> Yep
[17:54] <fabrice_sp> Hi. Somebody willing to review again  DVDStyler? it's at http://revu.ubuntuwire.com/details.py?package=dvdstyler. Thanks!
[18:03]  * StevenK waves to ScottK-laptop, in a timezone that is a lot closer to his.
[18:04]  * ScottK-laptop waves back.
[18:32] <DRebellion> Ok, Cifer (a tool for analysing and cracking classical ciphers) is now at 1.0.2. Any reviews would be much appreciated: http://revu.ubuntuwire.com/details.py?package=cifer .
[18:33] <laga> DRebellion: :(
[18:35] <DRebellion> laga, =/
[18:38] <directhex> laga, :x
[18:51] <StevenK> bddebian: lool is at Fosscamp
[19:06] <bddebian> StevenK: Ahh
[19:08] <edster> hey I've found that rwhod on hardy / intrepid segfaults when specifying an interface ... (ie rwhod -i eth2).  Would this be the right place to find someone willing to look into this?
[19:14] <rww> edster: did you file a bug report?
[19:15] <edster> rww: naw, I didn't.  Where do I go to do that?
[19:15] <rww> !bugs | edster
[19:15] <ubottu> edster: If you find a bug in Ubuntu or any of its derivatives, please file a bug report at: http://bugs.launchpad.net/ubuntu  -  Bugs in/wishes for the bots can be filed at http://launchpad.net/ubuntu-bots
[19:15] <edster> thanks.  :)
[19:18] <edster> ah looks like it's been updated in debian .. but not yet merged..  https://bugs.launchpad.net/ubuntu/+source/netkit-rwho/+bug/261396
[19:18] <ubottu> Ubuntu bug 261396 in netkit-rwho "rwhod segfaults upon startup when specifying interface to use" [Undecided,New]
[19:21] <directhex> debian is newer? that's unpossible!
[19:22] <guille_> hi all
[19:22] <guille_> do you know which is the absolute path of the file printed when a user logs via ssh?
[19:22] <guille_> s/logs/logs in
[19:23] <rww> guille_: /etc/motd
[19:23] <guille_> rww: thank you
[19:23] <rww> guille_: btw, that should probably have been directed to #ubuntu, rather than here ;)
[19:24] <guille_> oh, sorry
=== munckfish is now known as _munckfish
=== _munckfish is now known as munckyMagik
=== munckyMagik is now known as munckfish
=== fabrice_sp_ is now known as fabrice_sp
[22:13] <scotlfs> ok guys so how do I begin packaging? I am on the motu wiki and have read some of the stuff, but I mean how do I coordinate with the team about what I am doing etc etc....
[22:15] <pochu> scotlfs: I suggest you start with merges from Debian and bug fixes. To coordinate, for merges you should mail the last Ubuntu uploader to check with him if he has started doing the work, and if he's fine with you taken it
[22:15] <scotlfs> actually I have a package I want to volunteer to maintain for ubuntu, as far as I know (I could be wrong), no one is maintaining it yet, thus my volunteering....
[22:30] <pochu> scotlfs: cool, then you want to upload it to REVU
[22:30] <directhex> scotlfs, which package?
[22:31] <scotlfs> the Creative FXi driver
[22:32] <directhex> X-Fi?
[22:32] <scotlfs> I have one for my system, so its no extra skin off my back...I never maintained debs before but I developed rpm and maintained SRPMS for the LFS psuedo distro, so it shouldn't be too hard
[22:32] <scotlfs> yes  Xfi
[22:33] <DRebellion> Before I head off: if anybody is looking for something to revu i would be really grateful if they took a look at cifer, a tool for cracking classical cryptographic ciphers. http://revu.ubuntuwire.com/details.py?package=cifer . Thanks in advance.
[22:33] <scotlfs> developed rpm for the system, I don't mean I developed RPM proper
[22:33] <directhex> scotlfs, good luck. i've heard not a single good word about the wuality of the x-fi source
[22:35] <scotlfs> You are right, it sucks....but it works....
[22:35] <scotlfs> but I can improve it with time
[22:35] <scotlfs> or we can
[22:35] <scotlfs> or whomever else is interested
[22:36] <scotlfs> so I don't really know whether that falls under audio or under kernel as far as MOTU projects
[22:37] <directhex> scotlfs, you want to build a dkms package
[22:37] <directhex> scotlfs, look at... lirc-modules-source or kvm-source or kqemu-source
[22:38] <scotlfs> Its also been a while since i played iwth C on unix, the last few years I have been doing C# in a windows environment....quite different
[22:39] <scotlfs> c# is more like Visual Basic than C
[22:39] <directhex> let's assume i'm familiar with c#
[22:48] <scotlfs> hehe
[22:48] <scotlfs> ok then
[22:49] <scotlfs> so then who do I need to coordinate with for this?
[22:50] <directhex> scotlfs, is there an existing package? is the current source built & included as part of the ubuntu kernel?
[23:01] <scotlfs> I don't believe there is an existing package, however I don't know whether there is. I can say there isn't one available to clients...
[23:26] <kees> mok0: your quiltifying of makeztxt is not okay... you didn't break things into logical patches, you just separated them by filename.  also, we're not supposed to add patch systems to Debian packages that don't have them -- makes later merges more difficult.
[23:27] <directhex> unless it's pkg-cli-* or pkg-mono, in which case patch systems are encouraged, nay, mandatory
[23:35] <kees> mok0: specifically "please don't change helper tools": https://lists.ubuntu.com/archives/ubuntu-devel/2008-November/026903.html
[23:37] <mok0> kees: Not sure I understand
[23:37] <mok0> ah
[23:37] <kees> mok0: well, mostly, just adding quilt for a Debian package makes it hard to re-merge
[23:38] <directhex> unless it's pkg-cli-* or pkg-mono, where quilt is one of our approved patch systems
[23:38] <kees> mok0: and specifically, breaking the diff.gz into quilt by filename doesn't make sense because changes need to be separated logically
[23:38] <mok0> kees, not if the patches are used by the DD
[23:38] <kees> mok0: well, true.  but e.g. in the case of 03-ztxt_process.c.patch, there are 2 logical changes there
[23:39] <mok0> kees: let me look
[23:39] <StevenK> It does make it harder to re-merge.
[23:39] <kees> one is a FTBFS fix, the other is a crasher fix.
[23:39] <StevenK> You have the patches in debian/patches, then MoM merges them, and you have the patched source too.
[23:39] <StevenK> Fail.
[23:39] <kees> also the makeztxt.c and makeztxt.1 changes (for correct argument handling) should be considered 1 logical change and not be spread between two files
[23:39] <kees> StevenK: ah, good point
[23:40] <StevenK> kees: And then the patches are different ...
[23:40] <mok0> kees: makeztxt.1 really ought to go in debian/
[23:40] <StevenK> It's a painful, painful mess.
[23:40] <kees> mok0: yeah, it _all_ should go the debian.  :)
[23:40] <mok0> StevenK, kees should I redo it?
[23:40] <mok0> ... or just forward patches?
[23:41] <kees> mok0: if you re-organized the patches, it'd certainly be better -- all the fixes are already forwarded to debian (see bdmurray's notations)
[23:41] <StevenK> mok0: If the DD doesn't accept a patch that implements a patch system, ask *why*
[23:41] <mok0> StevenK: hm, I see
[23:42] <kees> StevenK: the maintainer isn't actually a DD and hasn't uploaded anything else
[23:42] <kees> StevenK: I emailed them yesterday asking if they wanted to share maintainership
[23:42] <mok0> Hopefully we soon go to the quilt src pkg format
[23:42] <StevenK> Ew
[23:42] <StevenK> Dun wanna play that game
[23:42]  * StevenK hates quilt, and wants it to die
[23:43] <mok0> It's not really quilt specific
[23:43] <directhex> everyone has their favourites
[23:43] <kees> StevenK: reAlly?  quilt sure is nicer than other stuff
[23:43] <directhex> i mean, some people in here think cdbs is usable!
[23:43] <StevenK> kees: I hate quilt, I have a mild dislike of CDBS, and prefer dpatch
[23:43] <mok0> heh, /me loves both cdbs AND quilt
[23:44] <kees> StevenK: I want to see you and slangasek discuss patch systems.  I'll bring popcorn.
[23:44] <StevenK> We have ...
[23:44] <kees> and I missed it! dang.
[23:44] <StevenK> kees: File a session at UDS?
[23:44] <kees> I see benefits in both quilt and dpatch.
[23:44]  * StevenK smirks
[23:44] <kees> StevenK: hah, I've got enough to do.  :)
[23:44]  * directhex uses dh, but generally has only a "cdbs is smelly" policy
[23:45] <StevenK> kees: Are you in SF yet?
[23:45] <kees> StevenK: nopers, sunday night
[23:45]  * StevenK nods
[23:45] <kees> directhex: heh
[23:45] <mok0> quilt is very convenient when you're creating lots of fixes
[23:45] <kees> quilt is nice for rebasing.  dpatch is nice for adding new patches
[23:45] <directhex> we used to be a dpatch-only shop, but our latest contributor has sold us on quilt as an option
[23:45] <slangasek> "discuss" patch systems?  is kees suggesting I should pack extra gear?
[23:46] <kees> haha
[23:46] <directhex> slangasek, crowbars go through the baggage check, right?
[23:46] <StevenK> Only if I can get someone to bring me my Clue
[23:46] <kees> just wrap it in tinfoil so the TSA doesn't see it.
[23:47] <StevenK> "What's this large heavy metal object?" 'A developer education tool.'
=== dmb is now known as Guest24294
[23:49] <mok0> kees, you have a suggestion on how I should deal with this?
[23:49] <mok0> kees: makeztxt I mean
[23:54] <kees> mok0: personally, I would revert the quilt changes.
[23:54] <kees> mok0: but if you want to keep quilt, I'd re-arrange the patches to be logically separated, not per-file separated
[23:55] <mok0> kees: and bump the version?
[23:55] <mok0> kees: release
[23:55] <mok0> ubuntu2
[23:56]  * kees nods