[02:04] <savvas> debian native packages in revu should have a version such as 0.1.2ubuntu1 right?
[02:05] <lidaobing> debian native packages should not in revu
[02:06] <lidaobing> you can subscribe it to ubuntu-universe-sponsor directly
[02:06] <lifeless> lidaobing: it would be unusual, but I don't see why it doesn't need a review
[02:06] <lidaobing> with the status confirmed and no one assigned.
[02:06] <lifeless> lidaobing: debian native != unmodified from debian
[02:06] <lidaobing> lifeless, sorry, i mis-understanding it
[02:07] <lidaobing> lifeless, i thought it as a synrequest
[02:07] <lifeless> savvas: I don't think there is a sensible version number, but that would make sense to me
[02:07] <lifeless> lidaobing: I know; its ok :)
[02:08] <savvas> I meant the debian native versioning, sorry for misleading hehe
[02:09] <lifeless> savvas: you didn't ;)
[02:10] <savvas> I also wonder if I should recommend to a friend of mine, http://revu.ubuntuwire.com/p/pdfshuffler to go to Debian directly
[02:10] <savvas> there's an ITP bug open but the person didn't reply or make any progress as far as I know
[02:16] <savvas> oh and one more thing, do you think I should ask him to remove the debian/ folder from the original source, to stop being debian native? seems more appropriate
[02:26] <lifeless> savvas: that has nothing to do with being debian native
[02:26] <lifeless> failing to have an orig tarball and using a native version number do that
[02:27] <lifeless> if its not something that is intrinsic to debian, it shouldn't be a native package
[02:27] <lifeless> just put -1 in the changelog
[02:27] <ode> hi
[02:27] <lifeless> and give it a package_version.orig.tar.gz
[02:28] <ode> what do i put as the version number in the name of the tarball when what I am packaging just comes as a script with no version numbers, just a release history with dates?
[02:29] <savvas> lifeless: ok thanks, I'll talk with him later :)
[02:29] <ode> i.e. foo_20071208.orig.tar.gz
[02:30] <lifeless> looks fine
[02:30] <lifeless> nothing stops a date being a version number
[02:31] <imbrandon> just rember that you will need an epoc if they switch to "normal" version numbers in the future
[02:31] <lifeless> or you could do 0~2007...
[02:31] <imbrandon> true, that would be my choice "just in case"
[02:32] <ode> k0p, thanks
[02:32] <imbrandon> btw, hiya lifeless :)
[02:33] <ode> another thing?
[02:34] <ode> i can log into revu but see no link where I can upload packages
[02:34] <ode> I have my gpg key uploaded to launchpad
[02:34] <imbrandon> ode: you dont upload via the web interface, you use dput ( like the archive and ppa's )
[02:35] <savvas> ode: https://wiki.ubuntu.com/MOTU/Packages/REVU
[02:36] <ode> thanks
[02:37]  * imbrandon ran across a "python for dummies" book on his shelf he has never read
[02:37] <imbrandon> heck , i dont even rember buying it
[02:38] <ode> the videos from this years pycon are now on bliptv
[03:05] <artfwo> james_w: I am not sure that I understood your comment to my REVU upload - scantailor
[03:06] <artfwo> there is a stock README.Source about using simple-patch-sys
[03:06] <artfwo> *is there?
[03:06] <artfwo> I can't seems to find one bundled in cdbs
[03:09] <pace_t_zulu> can someone point me to some documentation regarding install time package detection with dpkg/apt?
[03:35] <jmarsden> artfwo: See https://wiki.ubuntu.com/README.sourceHowTo (it's not official, but maybe better than nothing?)
[03:36] <artfwo> jmarsden: yes, that is exactly what I was looking for, thanks!
[03:36] <jmarsden> No problem.
[03:58] <qiyong> dpkg-checkbuilddeps: error: syntax error in debian/control at line 16: first block lacks a source field
[04:04] <ScottK> Does the first line of your debian/control file start: Source:
[04:04] <ScottK> with a source package name after that ...
[04:23] <qiyong> ScottK: ?
[04:23] <ScottK> qiyong: Can you pastebing your debian/control file?
[04:24] <qiyong> Package: fvmm
[04:24] <qiyong> ScottK: ^
[04:24] <ScottK> From the Ubuntu archives?
[04:24] <qiyong> !pastebin
[04:24] <qiyong> ScottK: local pkg
[04:25] <ScottK> OK.  If you pastebin the debian/control I can probably tell you what's causing that error
[04:25] <qiyong> ScottK: can i /msg you?
[04:25] <ScottK> OK
[06:03] <tonyyarusso> Is there a guide anywhere for breaking a package up into sub-packages?  There's one that has a three-part setup (graphical client, cli server, cli robot), and I'd like to be able to install the server/robot portions without the graphical dependencies.
[06:04] <LucidFox> tonyyarusso> Add more packages to debian/control. In debian/rules, install first to debian/tmp, then use dh_install and debian/[packagename].install files to move the files to debian/[packagename] directories.
[06:04] <LucidFox> Or if using CDBS, this would already be done for you.
[06:05] <LucidFox> Look at any existing source package with multiple binary packages for an example.
[06:06] <tonyyarusso> Do you have a particularly good example to recommend?
[06:07] <tonyyarusso> (Preferably a relatively simple one too)
[06:08] <LucidFox> debhelper or CDBS?
[06:11] <tonyyarusso> debhelper
[06:15] <hyperair> look at geanygdb which just entered karmic.
[06:15] <hyperair> that uses debhelper
[06:15] <hyperair> or man dh
[06:16] <hyperair> no wait, geanygdb is a single binary package
[06:16] <hyperair> hmmm
[06:28] <lifeless> tonyyarusso: its pretty stock; you add packages to control [and install/doc/dirs files to match], thats it usually.
[06:33] <LucidFox> tonyyarusso> You could look at avidemux for debhelper << 7, or gtkpod for debhelper 7
[06:34] <LucidFox> avidemux was a single package up to version 2.3 - since 2.4, it's split into avidemux, avidemux-common, avidemux-cli, avidemux-gtk and avidemux-qt
[06:35] <LucidFox> wait, no avidemux-gtk
[06:38] <LucidFox> Gosh, Launchpad really is the new Facebook. https://edge.launchpad.net/~ubuntu-photographers
[06:39] <tonyyarusso> LucidFox: -cyclists too
[06:40] <qiyong> what is the debian/files format?
[06:46] <LucidFox> qiyong> It's generated by the build tools, so you don't have to worry about it :)
[06:46] <LucidFox> http://www.debian.org/doc/debian-policy/ch-source.html#s-debianfiles
[06:54] <dholbach> good morning
[06:54]  * LucidFox waves at dholbach
[06:55] <dholbach> hiya LucidFox!
[07:29] <LucidFox> Damnit, quassel, stop crashing on hiding buffers.
[07:44] <ScottK> That's apparently a tough one for them as the backtraces they've gotten on it don't point to any code in Quassel.
[07:54] <LucidFox> I wonder if it would make sense to maintain a version of Quassel with pure Qt, built without kdelibs
[07:54] <LucidFox> that's just asking for packaging trouble, though
[07:56] <LucidFox> <A
[07:56] <LucidFox> And would it make sense to merge it from Debian?
[07:58] <ScottK> Since I used it with KDE, I'd think not.  I've vaguely considered trying to build both KDE and Qt versions from the same source package.
[07:59] <ScottK> If you figure out how to do that sanely (I haven't really looked into it), I'm open to it.
[07:59] <LucidFox> I did that with kde4-style-qtcurve by doing a double build, but it had only one binary package.
[08:01] <ScottK> You'd end up throwing away the 2nd quasselcore build as it would be the same either way.
[08:03]  * LucidFox nods
[08:03] <LucidFox> So it would add quassel-nokde and quassel-client-nokde to the existing quassel, quassel-client, quassel-core and quassel-data
[08:08] <ScottK> I'd call them -qt4, but yes.
[08:18] <imbrandon> gnight all
[08:21]  * nixternal hugs dholbach 
[08:22]  * dholbach hugs nixternal back
[08:32] <directhex> good moaning
[08:48] <LucidFox> ScottK> That's going to be some unwieldy debian/rules. http://paste.ubuntu.com/169357/
[09:00] <directhex> LucidFox, you call that unwieldy? o_o
[09:04] <LucidFox> directhex> Compared to the current CDBS-based debian/rules, ye
[09:07] <directhex> try http://svn.debian.org/viewsvn/pkg-cli-apps/packages/ikvm/trunk/debian/rules?revision=4424&view=markup for an extra-special rules which i claim all appropriate blame for
[09:19] <LucidFox> directhex> heh, even dh 7 wouldn't shorten it that much
[09:19] <directhex> LucidFox, there's so much voodoo in it i don't know what adding dh7 medieval black magic would do - probably nothing healthy
[09:19] <LucidFox> hahaha
[09:21] <directhex> LucidFox, that was weeks and weeks of work though, including round-trip discussions with upstream
[09:21] <LucidFox> Wow.
[09:21] <directhex> and even HE recommends people just use the binaries, because building is a pig
[09:22] <directhex> he helped me pin down how to create my own bootstrap binaries, which i need to provably do for them to be bootstrap binaries (and not just generic evil bundled closed-source things). the trick is grabbing half-build objects from halfway through the build process
[09:41] <LucidFox> directhex> Why doesn't upstream just create a sane build system?
[09:42] <directhex> LucidFox, i think he finds it easier to split out the "external" parts (modified openjdk and classpath sources) from his own stuff
[10:01] <directhex> is the info on http://retro.apebox.org/keysign.pdf combined with my passport sufficient for keysignage at UDS?
[10:06] <dholbach> popey: when you remove spam - do you just "remove wiki page" or do you have permissions to "remove spam"?
[10:06] <popey> depends how it was spammed
[10:06] <dholbach> I meant the regular 2768246kjl24nhzl42ljh426hj spam :)
[10:06] <popey> there have been a lot of pages recently created called MoinMoin/SomeRandomName, the spammers attach text files to those pages
[10:06] <dholbach> or is there another form of regular spam?
[10:07] <popey> some is just links on pages, some is in attachments
[10:07] <evanrmurphy> Hey, I apologize if this is off-topic, but it's a quick question: Do I need special permission to create a personal wiki on wiki.ubuntu.com? I've read that it's a step in the Ubuntu membership process.
[10:07] <dholbach> evanrmurphy: no, just go for it :)
[10:07] <popey> evanrmurphy: no just go ahead and create a page at http://wiki.ubuntu.com/YourName
[10:08] <evanrmurphy> dholbach, popey: Thanks!
[10:08] <popey> dholbach: did I understand your question correctly?
[10:08] <dholbach> popey: yes, thanks :)
[10:08] <popey> https://wiki.ubuntu.com/HelpOnInstalling/ZicuaDihulav is an example
[10:08] <dholbach> just looking at cash-advance-loans :)
[10:08] <popey> you can spot them a mile away, if you go to https://wiki.ubuntu.com/RecentChanges and search for txt
[10:09] <popey> they kinda stand out
[10:09] <evanrmurphy> dholbach: Yes you understood perfectly. P.S. your tutorials and packaging sessions on Ubuntu development are excellent.
[10:09] <dholbach> evanrmurphy: thanks  a lot for the flowers :)
[10:10] <popey> :)
[10:10] <evanrmurphy> dholbach: Scratch that first sentence, I misread popey's "dholbach: did I understand your question correctly?". Enjoy the flowers. :)
[10:11] <popey> dholbach: have you noticed that the person _just_ spammed the wiki
[10:11] <popey> note the user ~David, doesnt exist
[10:12] <dholbach> popey: agy just told me that a fix for that will hopefully be rolled out today
[10:12] <popey> nice
[10:12] <popey> thanks
[10:26] <LucidFox> ScottK> Why is quassel built with nostrip?
[10:34] <directhex> dholbach, so how would a new MOTU go about getting an @ubuntu.com address he can stick on the end of his GPG key?
[10:35] <dholbach> directhex: https://wiki.ubuntu.com/Membership has a link to it
[10:35] <dholbach> https://wiki.ubuntu.com/UbuntuEmail
[10:36] <directhex> ooh, automagic AND functional!
[10:40] <LucidFox> directhex> Ooh, an interview already.
[10:40]  * LucidFox reads
[10:41] <directhex> LucidFox, prepared it weeks ago, back when the evil ubuntu conspiracy had already decided i was going to be a MOTU ;)
[10:41] <LucidFox> Haha
[10:41] <LucidFox> "Age: 25, if Evolution’s calendaring is to be believed."
[10:41] <dholbach> LucidFox: I'm sure directhex practised giving interviews in front of his mirror months ago
[10:42] <LucidFox> ^_^
[10:44] <directhex> dholbach, in a manner almost identical to http://xkcd.com/578/ as it happens
[10:52] <artfwo> james_w, nixternal, thanks for reviewing and advocating scantailor!
[10:53] <artfwo> now if anyone could take some time to review http://revu.ubuntuwire.com/p/supercollider that would be much appreciated :)
[10:54] <LucidFox> Every time I use dput, I'm worried of automatically typing "ubuntu" instead of "revu" or "ppa"
[10:54] <directhex> oh, remind me to kill my default target
[10:58] <LucidFox> How does the Behind MOTU process work?
[10:58] <james_w> artfwo: no problem, it was a good job
[10:58] <james_w> LucidFox: dholbach mails each new MOTU with a questionaire
[10:58] <LucidFox> oh
[10:59] <james_w> LucidFox, directhex: see the end of https://wiki.ubuntu.com/DeveloperGuide/Uploading
[11:00] <LucidFox> Thanks
[11:02] <\sh> moins
[11:04] <\sh> thekorn: ScottK : Thx (just readnig your queries :))
[12:26] <LucidFox> Why are my packages still being signed with the old key :S
[12:27] <LucidFox> Where do I choose which key debuild uses?
[12:27] <james_w> ~/.devscripts.cf
[12:27] <james_w> or something like that
[12:27] <james_w> DEBSIGN_KEYID in there
[12:27] <james_w> if not specified then it's matched by GPG
[12:30] <LucidFox> thanks, it worked
[12:30] <pkern> ogra: A new Gobby with undo hit Karmic (source package gobby-infinote, binary gobby-infinote/gobby-0.5); test server available on gobby.0x539.de.
[12:30] <ogra> cute !
[12:32] <pkern> ogra: Not protocol-compatible to the old, sadly, and not entirely finished, but you can try it out.  (It works, it was pretty stable, but it is not yet feature-complete for 0.5 and there could still be slight protocol changes.)
[12:36] <hyperair> LucidFox: you could always delete your old key.
[12:36] <hyperair> and back it up somewhere
[12:37] <LucidFox> Nah, I'll leave it until the expiry date
[12:37] <hyperair> expiry eh..
[12:37] <hyperair> my keys have no expiry
[12:43] <kmdm> Hi guys, if someone's got a little time can they check I'm not going completely mad? ;) It seems libdkim-dev is missing from hardy/universe yet the package source is set to build that package, and if I build it myself I do get the libdkim-dev built along with libdkim0...
[12:46]  * Hobbsee looks
[12:47] <Hobbsee> that's weird
[12:47] <kmdm> Hobbsee: Yeah, I think I found the .deb in the right place but it was just absent from Packages(.gz) iirc
[12:48] <Hobbsee> cprov: any idea why that's not there?
[12:52] <kmdm> Just digging around some more... the package history seems to show it being superseded by dkim-milter 2.0.2.dfsg-1ubuntu1, but then that version was deleted...
[13:03] <LucidFox> Looking through the Planet Ubuntu /heads directory, it kind of bugs me that some people apparently intentionally chose the *worst* photos they could find :)
[13:06] <soren> LucidFox: Hey, some people don't even use photos! *nudge* *nudge* :)
[13:06] <LucidFox> soren> Heh.
[13:06] <LucidFox> I have a reason not to. *wink*
[13:07] <soren> Secret agent, eh? Fair enough.
[13:23] <directhex> my chikkin.png > a photo
[13:39] <james_w> ajmitch: should treecc be removed from Ubuntu too?
[13:40] <directhex> which treecc? aren't there two?
[13:40] <james_w> precisely
[13:40] <directhex> rename one "bushcc". it's the only way.
[13:55] <LucidFox> I'm tempted to start a quote database for Ubuntu channels
[13:57] <directhex> LucidFox, make a fortunes file, for inclusion in email signatures!
[14:07] <Ampelbein> james_w: hi. you commented on bug 373512 that it needs to be a fake-sync. can you point me to some documentation on this?
[14:07] <james_w> Ampelbein: you need a motu to do that for you
[14:08] <james_w> I subscribed the sponsors again, someone should act on it
[14:08] <Ampelbein> james_w: ok, thanks.
[14:08] <james_w> or someone here could do it for you now, it doesn't take long at all
[14:09] <directhex> i could do it. what am i doing? are there likely to be pirates?
[14:10] <james_w> .orig differ in debian and ubuntu, but we want to sync
[14:10] <james_w> so grab the debian package, and the ubuntu tarball
[14:10] <james_w> check the tarballs don't differ in contents
[14:11] <james_w> then upload a build1 based on the debian package, but built against the ubuntu changelog
[14:11] <james_w> if that makes sense
[14:11] <directhex> do i need to build1 it? i thought fakesyncs usually kept the debian versioning
[14:11] <james_w> actually it's ubuntu1 isn't it?
[14:11] <james_w> we don't want the autosync to fall over it I guess
[14:12] <directhex> ubuntu1 would be just a merge, not a fakesync?
[14:16] <LucidFox> I thought fakesyncs were ubuntu1
[14:17] <AnAnt> Hello, is onkarshinde here ?
[14:18] <AnAnt> slytherin
[14:18] <LucidFox> AnAnt> He's slytherin here, so no
[14:18] <mok0> If the package already has a ubuntu* version, you bump it, otherwise add build1
[14:18] <LucidFox> judging by the user list
[14:18] <LucidFox> mok0> Isn't this for rebuilds?
[14:18] <mok0> yes
[14:18] <mok0> isn't that the issue?
[14:19] <AnAnt> are quilt-based source packages supported yet ?
[14:21] <AnAnt> if a package that I maintain was using quilt patch system, but all patches got removed (since they were applied upstream), do I have to remove quilt from Build-Deps ?
[14:21] <dholbach> nixternal: thanks for uploading django-openid-auth :)
[14:21] <james_w> wth? http://packages.qa.debian.org/b/bash-completion-lib.html
[14:21] <LucidFox> Any more opinions on the gtkpod-aac issue?
[14:22] <AnAnt> james_w: ?
[14:22] <james_w> just a really odd package
[14:23] <AnAnt> oh
[14:23] <james_w> forking an old version of a package in order to take it somewhere that the new maintainers of the package want to go anyway
[14:23] <LucidFox> hehe
[14:27] <mok0> Gawd, sourceforge is slow
[14:34] <AnAnt> james_w: depends on bash3
[14:35] <AnAnt> erm, nevermind
[14:35] <AnAnt> the new version is 4 not 3
[14:37] <kklimonda> james_w: would you mind pushing bug 373845 again? Sorry for my mistake, I've built this package so many times that I forgot to actually build the updated one. This time I've tested it. ;)
[14:38] <james_w> kklimonda: quilt has been synced now?
[14:38] <kklimonda> james_w: yes
[14:39] <james_w> ok
[14:39] <kklimonda> I've just built it on karmic pbuilder.
[14:39] <james_w> I don't have time now I'm afraid
[14:39] <kklimonda> sure
[14:39] <kklimonda> It isn't that important - I just wanted to remind you. :)
[14:39] <james_w> np
[14:39] <james_w> put a note in the bug report
[14:40] <james_w> then other people would consider it
[14:40] <james_w> and it will mail me
[15:11] <bddebian> Heya gang
[15:14] <artfwo> I'd like to ask any Vim experts how would I handle a bug like bug 310213
[15:16] <artfwo> I have a package, which includes README.Debian with explanations about vim-addon-manager, but since it's useless without vim-addon-manager will it really hurt, to Depend on vim-manager instead of recommending it?
[15:19] <james_w> artfwo: I think the current situation is fine, but you could explain that if they don't have the vim-addon-manager command they should install that package
[15:19] <artfwo> I am thinking of that as well, will an OK-only debconf dialog be sufficient?
[15:20] <james_w> for what?
[15:20] <artfwo> for explaining this to the user
[15:20] <james_w> nope
[15:20] <artfwo> README.Debian then?
[15:20] <james_w> that's fine
[15:21] <james_w> using debconf for this isn't a good idea
[15:21] <artfwo> that's what I have already done
[15:21] <james_w> most people won't see it
[15:21] <james_w> for those that will see it it will stop the installation, just to tell them something they might already know
[15:22] <artfwo> but I've just have a discussion with an upstream author, who wants a hard dependency on vim-addon-manager at least, because his system does not install recommended as dependencies
[15:22] <LucidFox> siretart> Now there's my concern. If libmp4v2 isn't even in recommends (and ScottK says that it shouldn't be), then with the death of proper gtkpod-aac there will be no obvious way for multiverse users to actually get gtkpod with m4a support.
[15:23] <artfwo> james_w: doing a hard dependency will break the vim policy, and I don't want that as well
[15:23] <LucidFox> Since "apt-get install gtkpod-aac" will not install libmp4v2.
[15:23] <siretart> LucidFox: I think we can safely assume that multiverse users have 'ubuntu-restricted-extras' installed
[15:23] <siretart> LucidFox: or kubuntu-restricted-extras
[15:23]  * LucidFox doesn't...
[15:24] <siretart> well, that is the documented and advertised method to get "that multimedia stuff" working
[15:24] <LucidFox> even so, it doesn't depend on libmp4v2
[15:24] <siretart> well, change it then :-)
[15:27] <LucidFox> It's a highly specific library, and the recommends for ubuntu-restricted-extras are all generic
[15:27] <LucidFox> why are they recommends rather than depends in the first place, by the way?
[15:27] <siretart> "they"?
[15:27] <LucidFox> ubuntu-restricted-extras has no depends, only recommends
[15:27] <LucidFox> Recommends: gstreamer0.10-plugins-ugly, gstreamer0.10-plugins-ugly-multiverse, ttf-mscorefonts-installer, adobe-flashplugin | flashplugin-nonfree, unrar, gstreamer0.10-plugins-bad, gstreamer0.10-plugins-bad-multiverse, gstreamer0.10-ffmpeg, libavcodec-unstripped-52, gstreamer0.10-pitfdll
[15:28] <siretart> not sure, ask mvo. I assume thats common practice with meta-packages these days
[15:29] <maxb> I assume it's so you can opt out of individual ones without having to remove the overall metapackage
[15:29] <LucidFox> ah
[15:30] <siretart> I rather think it has to do with being able to install package that conflict with one or more packages from the list without resulting in having to deinstall the other packages
[15:31] <siretart> coffee.now
[15:33] <LucidFox> And why "adobe-flashplugin | flashplugin-nonfree"? adobe-flashplugin isn't in the archive, and flashplugin-nonfree is transitional to flashplugin-installer
[15:34] <LucidFox> is it for some kind of backward compatibility?
[15:34] <Hobbsee> LucidFox: a-f is in partner
[15:35] <LucidFox> ah
[15:35] <Hobbsee> iirc
[15:35] <LucidFox> but flashplugin-nonfree can be changed to flashplugin-installer?
[15:35] <Hobbsee> looks like it
[15:39] <dholbach> directhex: http://behindmotu.wordpress.com/2009/05/11/jo-shields-directhex/#comment-624
[15:47] <LucidFox> Since I'm going to modify ubuntu-restricted-extras, can I add all ffmpeg unstripped libraries as suggested in bug #373963?
[15:48] <LucidFox> right now all [kx]?ubuntu-restricted-extras have libavcodec-unstripped-52, but not the other libraries
[15:50] <Hobbsee> LucidFox: yes, please fix it as you see fit
[16:06] <siretart> LucidFox: yes please. I'm surprised that this hasn't happened yet.
[16:06] <LucidFox> siretart> uploaded
[16:06] <siretart> thanks
[16:06] <LucidFox> added libmp4v2-0 to ubuntu-* and xubuntu-* too
[16:07] <siretart> did you add just libavcodec-unstripped-52 or also the other ones?
[16:08] <LucidFox> libavcodec-unstripped-52 was there already, I added the other ones
[16:12] <siretart> arg, sorry, I misread
[16:13] <siretart> the others are actually not necessary. until now nobody has raised any concerns about libavformat, so I don't strip that library (but in theory I could implement that)
[16:13] <siretart> for the other ones, I cannot imagine serious concerns, so the unstripped variant has functionally identically libraries
[16:14] <siretart> we do built them for convenience of the users: avformat depends on avcodec, and that on in turn pulls in postproc, avutil and avfilter
[16:15] <siretart> but anyway, it doesn't matter much
[16:21] <LucidFox> Apparently quite a few people have doubts about notify-osd...
[16:29] <kklimonda> does update-manager support upgrade from 7.10 to 8.04? 7.10 was moved to old-releases.u.c and I don't know if the update-manager that was shipped with it handles such a situation..
[16:30] <directhex> 7.10->8.04 ought to be fine
[16:32] <kklimonda> what was the version of update-manager in 7.10?
[16:32] <kklimonda> (i'm actually going to check out if it supports this upgrade as this question is popping over and over again)
[16:35] <kklimonda> directhex: doesn't look like u-m from gutsy supports it.. at least grepping source for "old-releases" returns nothing..
[16:42] <Gast_680_> http://www.schwimmbadspiel.de/?refId=99828434
[16:42] <Gast_680_> http://www.schwimmbadspiel.de/?refId=99828434
[16:42] <Gast_680_> http://www.schwimmbadspiel.de/?refId=99828434
[16:42] <Gast_680_> http://www.schwimmbadspiel.de/?refId=99828434
[16:42] <Gast_680_> http://www.schwimmbadspiel.de/?refId=99828434
[16:42] <Gast_680_> http://www.schwimmbadspiel.de/?refId=99828434
[16:42] <Gast_680_> http://www.schwimmbadspiel.de/?refId=99828434
[16:42] <Gast_680_> http://www.schwimmbadspiel.de/?refId=99828434
[16:42] <Gast_680_> http://www.schwimmbadspiel.de/?refId=99828434
[16:42] <Gast_680_> http://www.schwimmbadspiel.de/?refId=99828434
[16:42] <Gast_680_> http://www.schwimmbadspiel.de/?refId=99828434
[16:42] <Gast_680_> http://www.schwimmbadspiel.de/?refId=99828434
[16:42] <Gast_680_> http://www.schwimmbadspiel.de/?refId=99828434
[16:42] <Gast_680_> http://www.schwimmbadspiel.de/?refId=99828434
[16:42] <Gast_680_> http://www.schwimmbadspiel.de/?refId=99828434
[16:44] <ikonia> super spam
[16:52] <kklimonda> what is option 'X-Ubuntu-Gettext-Domain' in .desktop files used for?
[16:57] <Amaranth> kklimonda: For packages in main we strip the translations out of the .desktop files and gnome-menus has a patch to load a translation from the .mo file
[16:57] <Amaranth> kklimonda: it uses that key to figure out where to get the translation
[16:58] <kklimonda> Amaranth: it doesn't apply to packages from universe?
[16:58] <Amaranth> kklimonda: it won't strip the translation but it'll still prefer the .mo file version if that key is set
[16:59] <kklimonda> i see.. thanks :)
[17:17] <nixternal> dholbach: no problem on django-openid upload :)
[17:24] <dholbach> :-)
[17:33] <kklimonda> hmm.. there isn't anything like requestmerge tool - can you point me to some "perfect" merge request so I can copy it? :)
[17:34] <LucidFox> kklimonda> "Please merge packagename version from Debian unstable ({main|contrib|...})"
[17:35] <LucidFox> Add debian/changelog entries since the last Ubuntu version, attach your debdiff, and subscribe u-m-s or u-u-s
[17:35] <ScottK> kklimonda: If you look at the requestsync output and change sync/merge and attach a debdiff from the Debian version you should be good.
[17:36] <kklimonda> ok, thanks :)
[17:38] <kklimonda> should I create debdiff from both previous ubuntu release and debian release?
[17:39] <ScottK> kklimonda: Just the Debian one.  Some people do the previous Ubuntu one, but I have no idea why.
[17:39] <kklimonda> ScottK: it is mentioned on merge wiki page
[17:39] <ScottK> OK.  Then that's a good reason to include it.
[17:40] <ScottK> Honestly I've never looked at one when I was sponsoring.
[17:40] <ScottK> I've diffed the debian dirs, but the upstream changes really aren't generally of interest.
[17:41] <huats> DktrKranz: are you around ?
[17:43] <kklimonda> ScottK: that's why I'm asking - it sounds overzealous to me especially when a debdiff is over 12 megabytes ;)
[17:44] <ScottK> I'd leave it out and explain why.
[17:48] <LucidFox> ScottK> Jonathan Thomas says in bug #374802 that quassel packages can be stripped now - is this correct?
[17:48] <LucidFox> I specifically added force nostrip to the new debian/rules because it was in the old one
[17:49] <ScottK> LucidFox: I think so.  We generally use CDBS for KDE packages because of special rules for KDE in kde4.mk.
[17:49] <ScottK> I'm kind of reluctant to abandon that.
[17:49] <LucidFox> Ah
[17:49] <LucidFox> A double build would be much more difficult to do with CDBS, though, if not outright impossible
[17:50]  * JontheEchidna seems to remember seeing another KDE package that did a double build...
[17:50] <JontheEchidna> kdiff3 I think
[17:51] <JontheEchidna> Yeah, it does a double build with CDBS, albeit not with kde4.mk
[17:51] <LucidFox> o_O
[17:51]  * LucidFox downloads
[17:52] <JontheEchidna> (this is new in the latest version in karmic synced from unstable, mind)
[17:52] <JontheEchidna> s/synced/merged
[17:54] <ScottK> JontheEchidna: What's the one we're switching to in Karmic?
[17:54] <ScottK> LucidFox: There's a newer helper in pkg-kde-tools that we'll want for Karmic in any case.
[17:54] <LucidFox> Specifically for double builds?
[17:54] <LucidFox> ah, wait
[17:55] <LucidFox> replacing kde4.mk
[17:55] <JontheEchidna> /usr/share/pkg-kde-tools/qt-kde-team/1/debian-qt-kde.mk is the drop-in replacement for kde4.mk
[17:55] <kklimonda> bug 375000 - how does it look? Damn, nice bug number ;)
[17:55] <JontheEchidna> actually, that needs pkg-kde-tools as a build-depend
[17:55] <LucidFox> It just includes kde4.mk, actually
[17:56] <ScottK>  The one in Karmic doesn't do that
[17:56] <LucidFox> ah
[17:56] <JontheEchidna> It probably did that for sync purposes in Jaunty
[17:56] <JontheEchidna> and come to think of it, it would make backporting easier too
[17:57] <ScottK> JontheEchidna: That's exactly why i did it (sync/backporting).  You do need to make sure you don't use any of the symbol file magic in Jaunty though as we don't support that.
[17:58] <JontheEchidna> Yeah, though I was pleasently surprised when strigi from Unstable built fine in Karmic :)
[17:58] <JontheEchidna> symbol files and all
[17:58] <kklimonda> Hmm.. Why is transmission's maintaner set to Ubuntu Core Developers when package is in universe?
[17:59] <ScottK> IIRC it used to be in Main.
[17:59] <ScottK> There's no automatic process for changing that when packages move between components.
[17:59] <kklimonda> should i change maintainer to MOTU or leave it be?
[18:00] <ScottK> I'd change it.
[18:00] <LucidFox> Upon looking at the karmic debian-qt-kde.mk, none of that seems relevant to quassel.
[18:01] <ScottK> Could be.  No guarantee it would remain that way in the future.
[18:02] <ScottK> I'd prefer to stick with it, but if it's not possible, then I think it's not essential.
[18:05] <awe> cjwatson: looks like someone beat to me the punch for the aap sync bug; so moving on to console-common, it also looks like it's just a sync; do you mind if i go ahead report the bug?
[18:06] <awe> s/go ahead report/go ahead and report/
[18:08] <cjwatson> awe: no, I believe that Debian only just merged my keymap.sh patch
[18:08] <cjwatson> awe: check that el.po is either not empty any more or has been removed
[18:09] <cjwatson> awe: (see 0.7.80ubuntu1 changelog)
[18:09] <cjwatson> awe: I have zero interest in console-common any more since we no longer use it by default :)
[18:10] <awe> cjwatson: OK
[18:10] <awe> I'll get the hang of this one of these days.  Sigh...
[18:13] <vmelo> hi there
[18:14] <awe> cjwatson: how come the old ubuntu patch file doesn't show that the empty po file was removed?  I just see the changelog entry that say it was...
[18:15] <vmelo> I'd like to know why I can make a deb with debuild, but not with pbuilder... the dependencies are not recognized by pbuilder
[18:16] <bdrung_> if a package is in Dependency wait status, when will it tried again to build?
[18:17] <bdrung_> https://launchpad.net/ubuntu/+source/mpg123/1.7.2-3ubuntu1/+build/985773
[18:17] <LucidFox> https://edge.launchpad.net/ubuntu/+source/treecc What the heck?
[18:17] <LucidFox> http://packages.qa.debian.org/t/treecc.html
[18:18] <james_w> heh
[18:18] <james_w> nice
[18:18] <awe> cjwatson: also it looks like el.po is no longer empty in the new debian version, so looks like a sync request is correct
[18:21] <geser> bdrung_: usually it happens automatically, but this case is somehow special
[18:21] <LucidFox> james_w, so what's the deal with two treecc's?
[18:22] <james_w> name clash
[18:22] <bdrung_> geser: why is it special?
[18:22] <james_w> the higher version one was removed in Debian, and then the lower one uploaded I assume
[18:22] <james_w> then it was synced despite having a lower version, that bit I'm not clear on
[18:22] <cjwatson> ScottK: I usually like to see the diff from the previous Ubuntu version because that way it's easier to see whether there are any regressions introduced as part of the merge process (i.e. previous Ubuntu change dropped by mistake)
[18:23] <cjwatson> awe: as far as diff is concerned there isn't a whole lot of difference between an empty file and a missing one; that's the sort of thing diff can easily leave out
[18:23] <LucidFox> and then it was removed from Debian *again*
[18:23] <cjwatson> awe: if it's there now, great
[18:23] <geser> bdrung_: because libltdl3-dev (on what it waits) is provided by libltdl-dev but because it failed to install at that time LP believes it has to wait on it
[18:23] <cjwatson> ScottK: (admittedly, I'd produce this myself rather than expecting to see it from the merger)
[18:24] <awe> cjwatson: ok, thanks for your help.  I'll go ahead and file the sync bug then.
[18:24] <geser> bdrung_: but as it doesn't reappear it will wait for it forever
[18:28] <geser> bdrung_: I've given it back (after checking in my pbuilder that it builds)
[18:28] <bdrung_> geser: so changing b-d from libltdl3-dev to libltdl-dev would be the solution?
[18:29] <geser> yes, it would but as the buildds manage to resolve libltdl3-dev to libltdl-dev now a give-back is sufficient
[18:30] <bdrung_> ok
[18:30] <bdrung_> geser: thanks for your help
[18:37] <fabrice_sp__> james_w, about bug #373873: Debian maintainer is telling me that this flag is of no use anymore for powerpc. It seems that it comes from breezy, but I don't see any bug report explaining that compilation option. Do you have any info?
[18:37] <james_w> afraid not
[18:37] <james_w> I just looked at the diffs
[18:38] <fabrice_sp__> at breezy time, it was already launchpad for bug report?
[18:40] <fabrice_sp__> anyway, if it's compiling with powerpc (and working, as it seems no bugs has been reported in Debian) should'nt we try to sync? Or is it too risky?
[18:40] <james_w> no, we could try
[18:41] <james_w> I'd prefer it if there was someone with knowledge of powerpc/that flag that could speak to it
[18:43] <fabrice_sp__> Anyone (NCommander?) with powerpc at hand?
[18:49] <cjwatson> fabrice_sp: not really; we migrated to Launchpad for bugs in January 2006 - https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-January/000054.html
[18:49] <cjwatson> fabrice_sp: some of MOTU was using Launchpad for bugs before that, though
[18:49] <fabrice_sp> thanks cjwatson
[18:49] <fabrice_sp> And what exists before? (just looking for the root cause of a change in a pacakge, done for Breezy)
[18:50] <cjwatson> Bugzilla
[18:50] <cjwatson> fabrice_sp: you can use http://bugs.launchpad.net/bugs/bugtrackers/ubuntu-bugzilla/<bug number> to look up an old Bugzilla bug number
[18:50] <cjwatson> it'll redirect you to the imported bug in Launchpad
[18:51] <cody-somerville> What env variable do you have to set to enable debhelper debugging?
[18:51] <cody-somerville> or is DH_VERBOSE=1 what I want?
[18:54] <james_w> "export" that at the top of debian/rules
[18:54] <james_w> you might be able to do it from outside, I'm not sure
[18:55] <cody-somerville> awesome, thanks
[18:56] <LucidFox> ScottK> Reading the notify-osd comments, you seem to be rather pissed about it
[18:56]  * LucidFox hopes this doesn't sound like flamebait
[18:57] <maxb> I think there are quite a few people who are rather pissed about notify-osd :-)
[18:57] <maxb> Myself included
[18:58] <cjwatson> cody-somerville: you can run individual debhelper commands with DH_VERBOSE=1, which may be helpful
[18:59] <cjwatson> (if the package doesn't use debian/compat, then beware that you need to use the appropriate DH_COMPAT from debian/rules too)
[19:02]  * cody-somerville nods.
[19:03] <RainCT> mok0: you're m-o-m merge proposal reverts my UI changes :P
[19:03] <cody-somerville> I'm trying to find out why files aren't getting installed into the different binary packages anymore. I see that everything gets setup correctly in debian/tmp/. Its almost like dh_install -a --sourcedir=debian/tmp does nothing at all.
[19:04] <cody-somerville> "dh_install -a -N$(PIKE)-core --sourcedir=debian/tmp $(DH_EXCLUDE)"
[19:34] <pace_t_zulu> hi guys... i am trying to create a debdiff to provide to patch launchpad bug #301007
[19:34] <pace_t_zulu> i am following this guide: https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
[19:35] <pace_t_zulu> I have modified the source... i ran 'dch -i' to update the changelog
[19:35] <pace_t_zulu> the current version of the package is ubuntu3 ... i have been unable to create the ubuntu4.dsc from which the debdiff will be created
[19:35] <pace_t_zulu> can someone help me with this?
[19:38] <geser> which error do you get?
[19:39] <james_w> ;
[19:39] <james_w> pace_t_zulu: did you run "debuild -S -us -uc"?
[19:39] <pace_t_zulu> james_w: yeah it fails because of dependencies...
[19:40] <pace_t_zulu> james_w: can i build with pdebuilder to generate ubuntu4.dsc ?
[19:40] <james_w> with --use-pdebuild-internal I think
[19:41] <Ampelbein> pace_t_zulu: you must not have all dependencies installed to build the source. can you pastebin the output of debuild?
[19:41] <geser> and you don't need all build-depends installed to build a source package, mostly the commons ones are enough (debhelper, cddbs)
[19:41] <pace_t_zulu> Ampelbein: yes i am aware that i'm missing dependencies... that's why i'd like to use pdebuilder
[19:42] <Ampelbein> pace_t_zulu: you got me wrong, sorry. english is not my first language. there is no need to have all dependencies installed.
[19:42] <geser> if you want to work on packages regularly it useful to have them installed
[19:42] <Ampelbein> at least for source-building
[19:43] <pace_t_zulu> Ampelbein: i am installing the build dependencies now... but for the future i'd like to be able to generate the subsequent .dsc file with pbuilder... sorry i referred to it as pdebuilder before
[19:43] <pace_t_zulu> james_w: what were you saying about --use-pdebuild-internal?
[19:43] <Ampelbein> pace_t_zulu: can you pastebin the error you get with 'debuild -S -sd'?
[19:43] <james_w> it's an argument
[19:44] <james_w> read the manpage and work out how to use it
[19:44] <Ampelbein> pace_t_zulu: or you can use pdebuild as a command to automatically build the source package and afterwards the binary in pbuilder.
[19:44] <pace_t_zulu> james_w: argument to which command? pdebuild? or pbuilder?
[19:45] <james_w> pace_t_zulu: pdebuild, that's what you asked me about
[19:45] <pace_t_zulu> Ampelbein: working on getting the error... it is in the same buffer as the current aptitude install of the build dependencies
[19:46] <pace_t_zulu> james_w: apologies, i realize that i am not doing things correctly here
[19:46] <james_w> np
[19:48] <pace_t_zulu> Ampelbein: http://paste.ubuntu.com/169884/
[19:48] <pace_t_zulu> Ampelbein: i recognize the problem is the lack of build dependencies
[19:49] <cody-somerville> james_w, I did as you suggested and I get lots of extra output except from dh_install
[19:49] <pace_t_zulu> Ampelbein: i was hoping this could be addressed using pbuilder
[19:49] <cody-somerville> james_w, dh_install -a -Npike7.8-core --sourcedir=debian/tmp -XSsleay -XMird -XMsql -Xmsql -XPDF -XFfmpeg -XOracle -Xoracle -Xsybase -XGnome -XGTK -XGDK -XDVB -XJava -XTTF
[19:49] <cody-somerville> james_w, Does anything look wrong with that to you?
[19:49] <james_w> a lot of -X
[19:50] <cody-somerville> It was working before
[19:50] <james_w> they're not matching everything in debian/tmp are they?
[19:50] <james_w> what did you change? :-)
[19:51] <james_w> pace_t_zulu: pbuilder works on source packages
[19:51] <james_w> pace_t_zulu: you are having trouble building a source package, therefore you can't build one to give to pbuilder
[19:52] <james_w> pace_t_zulu: however, pdebuild has a mode where it does more inside the chroot than normal
[19:52] <pace_t_zulu> james_w: so i would need to use pdebuild ?
[19:52] <cody-somerville> james_w, http://pastebin.ubuntu.com/169885/
[19:52] <pace_t_zulu> james_w: thank you for your help
[19:52] <cody-somerville> james_w, the call to tree is for debugging.
[19:52] <geser> pace_t_zulu: if you want to avoid installing the build-dependencies you can build the new source package by hand (but check afterwards if it only contains your changes)
[19:52] <james_w> pace_t_zulu: using that, along with the right options, you may be able to get it to build you a source package inside the chroot
[19:52] <geser> pace_t_zulu: dpkg-source -b sourcepkg-dir
[19:53] <james_w> pace_t_zulu: however, I've never used that mode, and have no idea whether it even works, let alone all the steps that may be needed. All I know is that it starts with "pdebuild --use-pdebuild-internal", so I suggest that you start there.
[19:53] <pace_t_zulu> james_w: i think you're solution with 'pdebuild --use-pdebuild-internal' will solve my issue
[19:54] <pace_t_zulu> james_w, Ampelbein and geser: thank you for your help and patience with me
[19:55] <james_w> cody-somerville: nothing jumps out at me.
[19:55] <james_w> cody-somerville: tree confirms all of the files are in debian/tmp?
[19:56] <cody-somerville> yup
[19:57] <james_w> I assume that at least some of your packages are arch-dependent? :-)
[19:57] <james_w> also, can you pastebin the log of the DH_VERBOSE run?
[19:58] <james_w> and one of the package.install files that you expect to be acted on by these commands
[20:13] <savvas> nixternal: here? would you care to upload a new fixed version for gnote? there were some inconsistencies with the license we fixed (included gfdl and a text file with it) :)
[20:24] <cjwatson> pace_t_zulu: you could also use debuild's -d option to ignore build-dependencies for the purpose of building the source package
[20:25] <cjwatson> pace_t_zulu: that ought to be rather simpler than involving pbuilder
[20:26] <pace_t_zulu> cjwatson: thank you... i am uploading the debdiff as we speak
[20:26] <pace_t_zulu> cjwatson: who should i contact to get this patch pushed through?
[20:26] <cjwatson> no idea, I didn't read the whole conversation, just saw the question about debuild
[20:27] <cjwatson> wiki.ubuntu.com/UbuntuDevelopment has docs about sponsorship
[20:28] <cjwatson> awe: bug 375068: one would not conventionally file a merge bug until one has something to merge
[20:28] <cjwatson> awe: I thought you said it could be a straightforward sync, in which case why does the bug say it's a merge?
[20:29] <cjwatson> awe: we normally use "merge" to mean that there still needs to be an Ubuntu change to the source package afterwards, and "sync" to mean a verbatim copy from Debian
[20:29] <awe> cjwatson: cause i was wrong...
[20:29] <awe> there are two /po dirs
[20:29] <awe> it turns out that the zero length el.po was still in the debian upstream version
[20:30] <cjwatson> right, in that case my original comment stands, usually you file a merge bug only once you have a debdiff to sponsor
[20:30] <cjwatson> of course might as well just keep going now you've filed it, but for the next time
[20:30] <awe> hmmm, then the wiki needs to be updated.  it says:
[20:30] <awe> If you are not the previous uploaders, before you work on the merge, file a bug in Launchpad against the source-package product
[20:31] <awe> anyways, i was just about to add the debdiff
[20:33] <kmdm> Quick Q... If a binary package is missing from the repository (but the source package builds it fine) should I just file a bug for a no source change re-upload or something? (package in question is hardy/universe: libdkim-dev)
[20:33] <geser> awe: it's in the wiki to avoid double work
[20:33] <cjwatson> awe: oh, in this case, you'd talked to the previous uploader and I'd said I was happy for you to work on it, so no need for that step
[20:34] <cjwatson> since, as geser says, the point of that step is to avoid me working on it
[20:34] <cjwatson> (as previous uploader)
[20:34] <geser> kmdm: libdkim-dev | 1:1.0.19-3 | http://archive.ubuntu.com jaunty/universe Packages
[20:34] <geser> kmdm: it's there
[20:34] <cjwatson> kmdm: if it weren't there, the question you would need to ask is "why is it magically missing, and why would a rebuild magically bring it back?"
[20:35] <awe> cjwatson: ok, but i still need to file a bug in order to add the debdiffs right?  if so, next time i'll make sure i have the debdiffs ready and add them right away
[20:35] <cjwatson> awe: yes
[20:35] <awe> ok, thanks
[20:35] <cjwatson> awe: it just struck me as odd while reading mail that's all :)
[20:35] <geser> kmdm: overlooked that hardy
[20:35] <awe> np
[20:36] <kmdm> cjwatson: Because it was superseded by dkim-milter which Martin Pitt then subsequently deleted... as shown at https://launchpad.net/ubuntu/hardy/i386/libdkim-dev :)
[20:36] <kmdm> geser: I said hardy ;)
[20:36] <cjwatson> that's a good answer
[20:37] <cjwatson> however, simply resurrecting it from the version in hardy is no good, because that would cause versions to go backwards
[20:37] <cjwatson> I assume this is why the version in intrepid and beyond has an epoch
[20:37] <kmdm> The binary package is still there though, from the same source package :S It would have just been handy to have the -dev package in the repos too...
[20:37] <kmdm> err, I mean, libdkim0
[20:38] <cjwatson> one could consider a stable release update to resurrect it, but SRUs need a pretty good reason
[20:38] <cjwatson> http://wiki.ubuntu.com/StableReleaseUpdate
[20:38] <cjwatson> the SRU would have to add the epoch but have a lower version number than intrepid
[20:38] <geser> "* Add an epoch to reclaim binary packages "stolen" by dkim-milter."
[20:39] <cjwatson> if it's just for one-time use, you can probably fish out the libdkim-dev package from LP
[20:39] <cjwatson> I agree this is a messy inconsistency
[20:40] <kmdm> Aye, I was trying to build a custom exim4 package but pbuilder couldn't pull in libdkim-dev... and that's how I came across this :)
[20:51] <kmdm> If no-one else is, I'll prepare a debdiff and stick it in launchpad so at least it's there for consideration and findable by others if they encounter the same thing... :)
[20:53] <savvas> in order to upload a new version of gnote in "new" queue, do I upload it to revu again? there's a license fix
[20:53] <savvas> (again)
[21:18] <kmdm> If I've logged a bug which needs to be considered for SRU but also needs sponsorship do I subscribe motu-sru, u-u-s or indeed both?
[21:19] <hyperair> motu-sru
[21:19] <hyperair> !sru
[21:19] <hyperair> follow the steps in that link ^
[21:19] <kmdm> hyperair: Yeah, I was reading the procedure there and motu-sru was step 3, but step 4 said to upload to -proposed and I can't do that, hence the query :)
[21:20] <hyperair> motu-sru gives the ack, and only after that can someone sponsor you and upload it
[21:21] <kmdm> Aha, thanks :)
[21:21] <hyperair> =)
[21:50] <LordKow> i dont understand why this MoM report is citing conflicts between the current ubuntu and new debian version in the package source directory. don't you always want to use the new source since it is a version upgrade?
[21:50] <kklimonda> LordKow: MoM is stupid ;)
[21:51] <LordKow> k :)
[21:51] <kklimonda> LordKow: i guess it's a safety check for those ugly packages that don't use any patch system ;)
[21:52] <LordKow> yea well it's kind of a violation of debian policy to directly change the source
[22:26] <funkyHat> Why is drupal5 being packaged for Jaunty?
[22:27] <funkyHat> Or am I missing something?
[23:21] <directhex> The following packages have unmet dependencies:
[23:21] <directhex>   apache2-threaded-dev: Depends: apache2.2-common (= 2.2.11-2ubuntu2) but it is not going to be installed
[23:21] <directhex> boo
[23:21] <maxb> amd64, perchance?
[23:21] <ajmitch> directhex: you broke stuff?
[23:22] <directhex> maxb, lpia and armel
[23:22] <directhex> ajmitch, i didnt touch nuffink, mister
[23:23]  * maxb curses that there is no ports rmadison
[23:26] <funkyHat> Why is drupal5 being packaged for Karmic? I meant to say -.-
[23:35] <directhex> for giggles
[23:35] <directhex> like this: "tee hee!"
[23:36] <binarymutant> if I wanted to package a plugin for pidgin should I try to get it into purple-plugin-pack (or whatever it's called) ?
[23:36] <ajmitch> directhex: so can I interpret that as an Official MOTU Response now?
[23:37] <directhex> ajmitch, yes. so sayeth ubuntu: "lulz"
[23:38]  * ajmitch quotes out of context
[23:45] <cjwatson> LordKow: it is NOT a violation of Debian policy to directly change the source.
[23:45] <cjwatson> LordKow: (I'm one of the Debian policy editors)
[23:46] <cjwatson> it is perfectly standard, even if many developers choose to use patch systems
[23:46] <binarymutant> cjwatson, ? really?
[23:46] <cjwatson> really.
[23:47] <binarymutant> doesnt that mess with the checksum?
[23:47] <cjwatson> no? which checksum in particular are you thinking of?
[23:47] <azeem> directly changing the orig
[23:47] <azeem> (I guess)
[23:48] <cjwatson> (azeem knows this, but) changing the source "directly", i.e. without using a patch system, in the unpacked source package does not result in the .orig.tar.gz changing - the changes go into the .diff.gz