[00:07] <micahg> RAOF: chrisccoulson fixed gjs on i386
[00:07] <RAOF> micahg: Yay!
[00:07] <RAOF> armel is still out of luck?
[00:08] <micahg> RAOF: he's going to look at it
[00:32] <YokoZar> ScottK: Just made another Wine upload.  One change is that the package wine (for old 1.0 stable wine) needs to be resurrected: its source should still be on the server, but its binary packages were being replaced by dummy packages in wine1.2 beta package.
[00:33] <YokoZar> ScottK: easiest way to do this is just minor version bump wine and wine-gecko, which I'll do later after wine1.2 is built
[00:34] <YokoZar> ScottK: after that I can fix that package you linked earlier (it needs to build off old stable wine due to changes in winelib)
[00:36]  * YokoZar is off to drive home
[01:38] <ScottK> TheMuso: There are audacious, audacious-plugins, wine-1.2, and nautilus-image-converter uploads in the queue.  All these are in the ubuntustudio package set.  Which, if any, of these do you want in for RC?
[01:39] <TheMuso> ScottK: Audacious changes are all that seem relevant out of that list.
[01:39] <TheMuso> However I would be interested to know what the fixes are for nautilus-image converter as well.
[01:39] <ScottK> TheMuso: Do you want to respin for it or should I hold it?
[01:39] <TheMuso> ScottK: hold
[01:39] <ScottK> OK
[01:40] <ScottK> http://launchpadlibrarian.net/44860525/nautilus-image-converter_0.3.0-2ubuntu2_source.changes
[01:41] <ScottK> I'm not sure how much we care about icon renaming at this point (the audacious changes).
[01:56] <TheMuso> right
[01:56] <TheMuso> not very much I'd say
[01:57] <TheMuso> but for the final release, those translations are probably worth it. I always have thought that the more translations the better.
[01:59] <ScottK> I'd appreciate a review by ubuntustudio of the audacious/audacious-plugins uploads before Thursday to let me know if you want them in the final release or stick with what we have.
[03:18]  * imbrandon returns
[03:23] <ScottK> YokoZar: Wine is part of the ubuntustudio package set so I can't accept it until after RC freeze is over unless they want to respin their ISO for it.
[03:30] <imbrandon> so what happens to a debian package when its between "incomming" and the archive in debian ... :(
[03:31] <imbrandon> my upload was accepted ~9 hours ago but still not in the archive :(
[03:36] <persia> YokoZar: Oh, also, what do you think about adding wine1.2 to P-a-s?  I'm not sure it will ever be useful for sparc/armel, and I'm unconfident that anyone has powerpc windows binaries to test.  I have no idea about ia64.
[03:37] <persia> imbrandon: Check other mirrors: you might be hitting mirror skew.  Once it's out of incoming, it should be somewhere (although maybe not yet pushed to mirrors (remember ftp.debian.org is a mirror))
[04:00] <imbrandon> persia: ahh yes, i've been checking http.us.archiv.debian.org , probably should check others
[04:00] <imbrandon> you know what the canoncial one is ?
[04:01] <imbrandon> ( not company, e.g. the "real" one the mirrors sync from )
[04:01] <persia> There (intentionally) isn't one for "canonical".  For "Canonical", it's hidden in launchpad, and I don't think it has an external URI.
[04:01] <imbrandon> hum
[04:03] <persia> My understanding of the reasoning is that if there *was* an official master, it would be overloaded.
[04:04] <persia> And I believe this is based on historical precedent, where it *did* get overloaded.
[04:04] <persia> So everything happens on mirrors now.
[04:04] <imbrandon> true, i wonder where DAK installs it to first though, its gotta mirror to somewhere
[04:04] <persia> I believe DAK installs to ftp-master, which gets mirrored.  I believe that ftp-master isn't accessible except to mirrors.  I may be mistaken.
[04:05] <imbrandon> i wouldent be so worried if i wasent in a time crunch, i wanna sync before launch
[04:05] <imbrandon> lol
[04:05] <imbrandon> persia: ahh that sounds right
[04:06] <persia> imbrandon: Check ftp.debian.org: it's likely to be the most up-to-date mirror (although it's probably not the highest-performance mirror)
[04:06] <imbrandon> nope :(
[04:06] <persia> imbrandon: And check *inside* the pool.  The way that debian gets mirrored means that the pool updates before the metainformation.
[04:06] <imbrandon> not on incoming.d.o or http://ftp.debian.org/debian/pool/main/a/apt-mirror/
[04:07] <persia> and no email?
[04:07] <persia> Very odd.
[04:07] <imbrandon> i got the email
[04:07] <persia> Maybe DktrKranz or bddebian can give guidance on how it really works then.
[04:07] <imbrandon> apt-mirror_0.4.7-1_i386.changes uploaded successfully to localhost
[04:07] <imbrandon> along with the files: apt-mirror_0.4.7-1.dsc apt-mirror_0.4.7.orig.tar.gz apt-mirror_0.4.7-1.debian.tar.gz apt-mirror_0.4.7-1_all.deb
[04:07] <imbrandon> etc etc etc
[04:08] <imbrandon> whatever machine is ries.debian.org
[04:08] <imbrandon> ( thats where the email came from )
[04:08] <imbrandon> Your Debian queue daemon (running on host ries.debian.org)
[04:09] <imbrandon> ahhh
[04:10] <imbrandon> ries.debian.org == ftp-master.debian.org
[04:10] <imbrandon> sooo its probably mirror lag, but damn, thats alot of lag
[04:15] <persia> ries is not actually ries, but another host running the ries filesystem, but that's trivia :)
[04:15] <imbrandon> ahh
[04:15] <imbrandon> not sure exactly what that means but okies
[04:16] <imbrandon> oh well i'll give it a few more hours before i start considering someone more drastic like a fake-sync
[04:16] <imbrandon> lol
[04:16] <imbrandon> s/someone/something
[04:17] <imbrandon> persia: do you know what mirror LP will atempt to grab it from for a sync ?
[04:18] <imbrandon> guess thats the one i should really be worried about
[04:21] <persia> I believe it's the mirror inside LP.
[04:21] <persia> But I suspect that a skilled archive-admin could pull from anywhere.
[04:22] <imbrandon> k
[04:22] <imbrandon> i just dont wanna *not* get it in because of a mirror problem ;)
[04:22] <imbrandon> its already late as is
[04:25] <persia> You could just upload it, with -0ubuntu1 :)
[04:25]  * imbrandon chuckles at the thought of a mirror problem with apt-mirror
[04:25] <persia> Assuming you've the appropriate FFes, etc.
[04:26] <imbrandon> persia: yea, i considered that, but i think i will give it a few more hours just to see if it shows up
[04:26] <imbrandon> yea its a bugfix only release, FFe's and such a re g2g
[04:26] <imbrandon> are*
[04:26] <persia> So yeah.  When you get too itchy, upload.  Until then, wait.
[04:26] <imbrandon> yup
[04:28] <imbrandon> this release did see the first upstream packaging for fedora,opensuse and win32 though ;)
[04:28] <imbrandon> was kinda happy about that
[04:28] <persia> Nice.
[04:29] <persia> So, tell me, what does apt-mirror give me that would improve on my debmirror experience?
[04:29]  * persia uses ubumirror for ubuntu, and plans to migrate to lmirror, but still hasn't found a completely satisfactory solution for debian
[04:30] <imbrandon> honestly i have never used debmirror so i would not probably be the best to tell on that one, but TheMuso did switch ( among others ) for reasons unknown to me exactly
[04:30] <persia> OK.  So, why use apt-mirror then?
[04:30] <imbrandon> i know apt-mirror can do partial mirrors well of just one arch, or arch+source or like 2arches + source etc
[04:31] <imbrandon> i *think* i was told thats hard with debmirror
[04:31] <imbrandon> and multi releases
[04:32] <TheMuso> apt-mirror uses a similar config file format similar to sources.list for one.
[04:32] <imbrandon> i really should check out debmirror , hehe , to know what i'm up against, its more of an alternative to say rsync where you may not want the whole archive
[04:32] <persia> It's possible, but it requires fairly complex calls to debmirror
[04:32] <TheMuso> It also has multi-threaded downloading if you want that.
[04:32] <imbrandon> yea and the config is very similar to sources.list
[04:33] <TheMuso> doesn't mirror installer-$arch/i18n/dist-upgrader stuff though. Not hard to patch in though if one wanted that.
[04:33] <persia> e.g. /usr/bin/debmirror -a amd64,armel,i386,powerpc -s main,main/debian-installer --method rsync -h ftp.jaist.ac.jp -r :pub/Linux/Debian/ -d sid -d squeeze /data/http/debian --pdiff=none
[04:33] <imbrandon> TheMuso: i actualy added that stuff in examples for 0.4.7 in the postmirror script
[04:33] <TheMuso> imbrandon: ah ok
[04:34] <TheMuso> I used to use debmirror, but the mirror.list config file format won me over, pure and simple.
[04:34] <imbrandon> persia: the same thing in apt-mirror would be like ....
[04:34] <TheMuso> Easy to extend if I wanted to
[04:35] <imbrandon> deb-amd64 ftp.jaist.ac.jp/debian main main/debian-installer
[04:35] <imbrandon> in the mirror.list
[04:36] <imbrandon> and lines for the other arches
[04:36] <TheMuso> One downside to apt-mirror is no rsync.
[04:36] <persia> Oh, that would be less ideal.
[04:36] <imbrandon> yea, i tried to overcome that a bit with postmirror.sh , but i really wanna add something new ( but still keep it simple ) for 0.5.0
[04:38] <imbrandon> hold on persia lemme past an example mirror.list ( and yea its not for everyone, but i have had nothing but good reviews of it )
[04:38] <imbrandon> paste*
[04:38] <imbrandon> ( in pastebin )
[04:39] <persia> imbrandon: I'll definitely give it a try when I have a chance.  I'm not entirely satisfied with debmirror.
[04:39] <TheMuso> Because apt-mirror doesn't support rsync, I'd say I probably may have a few stale files in my tree from stopped downloads that have been superseeded.
[04:40] <TheMuso> So a way to clean out stale files would be useful.
[04:40] <imbrandon> also the other good thing is the limited deps, it only depends on perl and wget thus is very portable
[04:40] <TheMuso> unless the clean stuff in mirror.list does that...
[04:40] <imbrandon> the clean should take care of that TheMuso
[04:40] <imbrandon> with md5 checks and such
[04:40] <persia> Oh, stale cleanup is imporant to me.  I (try) to mirror sid, and that can have a *lot* of churn.
[04:40] <persia> Oh, good.
[04:41] <TheMuso> imbrandon: ah ok then I should be fine then.
[04:41] <imbrandon> yea it has its own clean that can autoclean after each mirror or be run manualy
[04:41] <imbrandon> or both
[04:42] <imbrandon> persia: http://pastebin.ca/1869004
[04:42] <imbrandon> thats the "default" config for debian
[04:43] <imbrandon> forget the double line numbers, it was a paste mistake
[04:43] <persia> And can it reuse an existing mirror set as a base?  I'd rather not spend a day reinitialising my mirror :)
[04:43] <imbrandon> yes as long as your base path is seup correctly
[04:43] <imbrandon> setup*
[04:44] <TheMuso> Yeah, I migrated my mirror from debmirror tp apt-mirror with little issue./
[04:44] <TheMuso> s/little/no/
[04:44]  * persia will definitely try this in the near future
[04:45] <imbrandon> like persoanly i use /storage/apt-mirror for a base path, so i can rsync and move the rsync to /storage/apt-mirror/var/mirror/archive.ubuntu.com/ubuntu and be fine
[04:45] <imbrandon> it will even clean the stuff from rsync that it dosent need anymore
[04:45] <imbrandon> brb soda refill time
[04:47] <imbrandon> persia: worst case i can see is tell apt-mirror to use your existing mirror as its source for the initial mirroring, then switch to the "official" mirror your grabbing from , then rm the old
[04:47] <imbrandon> not ideal but would work in a worst case thing
[04:47] <imbrandon> to save a huge download
[04:47] <TheMuso> I probably won't switch from apt-mirror unless there is something that can significantly improve on what apt-mirror has to offer, and since I mirror everything, this shouldn't be a problem post archive re-org.
[04:48] <persia> Oh, good idea.  I can play with apt-mirror against my current mirror to get a feel for it.
[04:48] <persia> TheMuso: Once lmirror support is added to the archives, I'll share my experience.  Won't help for Debian mirrors short-term, but ought significantly reduce overhead of mirroring Ubuntu.
[04:49] <imbrandon> yea playing with it against ppa's is good for testing too , as ppa's tend to be smaller and can get a feel for things
[04:49] <imbrandon> when i bug squish i use my ppa as a "test bed"
[04:49] <TheMuso> persia: sounds good.
[04:49] <imbrandon> lmirror ?
[04:49] <TheMuso> And when I say everything, I mean everything for amd64, i386, source, and powerpc.
[04:50] <imbrandon> yea i only mirror i386, source, and powerpc, no amd64
[04:50] <imbrandon> i have the room now, i should probably start, i just dident have the room on my raid when i started mmirroring
[04:50] <nhandler> TheMuso: How much space does that take?
[04:51] <imbrandon> nhandler: each arch is about 30gig give or take a little ( for ubuntu )
[04:51] <nhandler> imbrandon: Is that source+binary? Or just the binary packages?
[04:51] <imbrandon> just binary
[04:52] <imbrandon> last time i looked source+i386 was like 55gig
[04:52] <imbrandon> but that was months ago, might be a bit diff now
[04:53] <imbrandon> rember also the first arch you mirror will be a bit larger than others too because of the arch_all packages
[04:54] <imbrandon> ( not a huge diffrence though )
[04:57] <TheMuso> powerpc is 96G for main, restricted, universe, multiverse.
[04:57] <imbrandon> wow
[04:57] <persia> imbrandon: lp.net/lmirror
[04:57] <TheMuso> amd64+i386+source combined is 224G for all the components mentioned above.
[04:57]  * imbrandon looks
[04:58] <TheMuso> This excludes instlaler-$arch, i18n, and dist-upgrader dirs in dists
[04:58] <lifeless> TheMuso: lmirror
[04:58] <imbrandon> you know, canoncial should buy lp.net like sourceforge bought sf.net
[04:58] <imbrandon> :)
[04:58]  * TheMuso checks out lmirror.
[04:59] <lifeless> TheMuso: jpds will be testing it out in the dc in the nearish future
[04:59] <TheMuso> cool
[04:59]  * persia get annoyed at LVM
[05:00] <TheMuso> lifeless: sounds like something that official mirros will use
[05:00] <imbrandon> lifeless: is it a new protocol or will it work against say ftp://
[05:00] <lifeless> imbrandon: it can read from ftp
[05:00] <lifeless> TheMuso: yes, and how is a personal mirror different to an official one?
[05:01] <lifeless> TheMuso: [other than not wanting the general internet to pull from it]
[05:01] <TheMuso> lifeless: true that.
[05:01] <imbrandon> lifeless: not all arches ?
[05:01] <imbrandon> hehe
[05:01] <imbrandon> no but i see what ya mean, its really handy
[05:01] <lifeless> imbrandon: not all mirrors mirror all arches anyhow; filtering is definitely needed, though actually I want us to advertise per-arch lmirror sets
[05:02] <imbrandon> that would be awesom, if you need outside testers i can def drum some up , lol
[05:02] <imbrandon> i end up knowing alot of apt-mirror users LOL, steal my userbase hahahaha
[05:03] <lifeless> imbrandon: definitely, once we have a test mirror
[05:04] <imbrandon> lifeless: is this a canonical project or is it a community one , or mor importantly ( to me ) is it floss
[05:04] <imbrandon> more*
[05:04] <lifeless> me, gpl
[05:04] <imbrandon> awesom
[05:04] <lifeless> as in, personal time, gpld
[05:05] <imbrandon> sweet, yea if you need any help lemme know, i'm not a great python guru but i can test and give ya use cases and drum of some of our users that might be more suited to lmirror vs apt-mirror
[05:06] <imbrandon> plus i have a new 5tb array to fill with something other than porn ( shhh )
[05:07] <lifeless> herh
[05:08] <lifeless> *heh*
[05:12] <TheMuso> lol
[05:20] <persia> lifeless: Actually, one way in which a personal mirror differs from an actual one is that personal mirrors are unsuitable for push-mirroring from official mirrors.
[05:20] <imbrandon> bzr launchpad-login imbrandon
[05:20] <imbrandon> err
[05:21] <lifeless> persia: why?
[05:22] <imbrandon> persia: and on that note sometimes need to be ratelimited on their downloads ( eg apt-mirror config can say only download @ 10kb/s per thread )
[05:23] <persia> lifeless: Erm, resource allocation?  firewall configurations?  I could probably come up with some other things, but they, like the ones I mention, could be argued away.
[05:26] <lifeless> so, some official mirrors will want rate limiting; and push-mirroring - I want to end up with comet support which will neatly avoid nearly all firewalls
[05:30] <gastons> is dpkg-buildpackage a wrapper for dpkg --build ?
[05:53] <imbrandon> nhandler: the blog post about my email is up, formatting is a little wonky on the planet, but you can click through to read it better if wanted
[06:25] <lifeless> gastons: amongst other bits, yes
[06:27] <gastons> ok thks
[06:48] <Ciemon> Morning all, bug 343430 seems to be quite simple, although I'm not having any success.
[06:49] <Ciemon> To test a debian/rules change, do I just download the source, change the rules, then pbuild? Or do I debuild prior to debuild?
[06:50] <Ciemon> heh, that should be debuild prior to pbuilder?
[06:50] <Ciemon> I realise you're all up against it at the moment, so if the answer isn't simple, don't worry about it :)
[07:00] <RAOF> Ciemon: Download the source, change the rules, then do one of (a) build a source package (debuild -S) & pbuilder it, or (b) build a binary package (debuild)
[07:01] <Ciemon> Thanks RAOF
[07:51] <DktrKranz> imbrandon: flow of packages in Debian work this way. When you upload a package, a software called queued moves it to a queque called "unchecked" on ftp-master.debian.org (actually it's ries). It happens every five minutes, and you get "successfully uploaded to blabla" (usually "localhost") mail.
[07:57] <DktrKranz> imbrandon: unchecked scan happens every 15 minutes (unless dinstall is running, actually at 0152,0752,1352,1952 UTC), and you get "foo_ver.arch.changes ACCEPTED" mail.
[08:00] <DktrKranz> imbrandon: during dinstall, package moves to pool, and some black magic starts to sync ftp-master with the mirrors about 1h after dinstall is started (and this takes a while). You should be able to get packages ~3h after dinstall is started.
[08:00] <DktrKranz> persia: FYI too --^
[08:07] <imbrandon> DktrKranz: what if you never get the second mail
[08:07] <imbrandon> btw thanks for the clairification
[08:08] <imbrandon> i got the "successfull upload to localhost" email ~12 hours ago almost exactly, but nothing since then
[08:09] <imbrandon> not a ACCEPT or REJECT
[08:09] <DktrKranz> imbrandon: could you please tell me name of the .changes file, so I look where it is now?
[08:10] <imbrandon> sure one sec
[08:10] <imbrandon> apt-mirror_0.4.7-1_i386.changes
[08:13] <YokoZar> persia: Don't like it, as there 1) is an arm port underway, 2) are already parts of the package usable on all architectures (eg fonts), and 3) multiarch will make things nice again soon
[08:15] <imbrandon> multiarch a reality ? i thought that was a myth in the deb world ;) /me ducks
[08:15] <DktrKranz> imbrandon: Reject Reasons:
[08:15] <DktrKranz> found unknown status token 'SIG_SUBPACKET' from gpgv with args '['24', '1', '29', 'hkp://pool.sks-keyservers.net']' in apt-mirror_0.4.7-1_i386.changes.
[08:15] <imbrandon> DktrKranz: ugh , ok thanks for looking
[08:16] <imbrandon> DktrKranz: could i bother you for a sponsor upload LOL, no worries if not i'll have jbouse fix it in the morning
[08:16] <DktrKranz> sure
[08:16]  * DktrKranz checks if he has key here
[08:16] <imbrandon> awesome, its in collab-maint, i'll get you the url
[08:17] <imbrandon> all checked in and tagged etc
[08:17] <DktrKranz> I have key, updating chroot
[08:19] <imbrandon> DktrKranz:  ok cool. its at git clone git://git.debian.org/collab-maint/apt-mirror.git
[08:19] <DktrKranz> oki
[08:19] <imbrandon> master branch should be the same as what was uploaded, but its also tagged
[08:21] <DktrKranz> I could eventually fetch rejected upload and resign :)
[08:22] <imbrandon> heheh
[08:23] <imbrandon> what ever is easier on you
[08:26] <dholbach> good morning
[08:26] <imbrandon> moins dholbach
[08:27] <dholbach> hey imbrandon
[08:47] <DktrKranz> imbrandon: mind checking if everything's OK before uploading? http://people.debian.org/~dktrkranz/apt-mirror/
[08:56] <imbrandon> DktrKranz: sure one sec, sorry went afk for a moment
[08:56] <DktrKranz> np
[08:57] <imbrandon> DktrKranz: yup, looks good
[08:57] <DktrKranz> uploading then
[08:57] <imbrandon> DktrKranz: btw thanks again for taking the time to look for it and also sponsor this upload ;)
[08:59] <DktrKranz> imbrandon: done. given that dinstall is started 10 minutes ago, expect the ACCEPTED mail to come in ~2.5 hours from now :)
[08:59] <imbrandon> DktrKranz: great, thanks ;)
[09:01] <DktrKranz> I'll check myself too, as I get it as well.
[09:01] <imbrandon> DktrKranz: hum it sent an email about the changes file already being present
[09:02] <imbrandon> k
[09:03] <imbrandon> DktrKranz: i'm sure you got the same mail though
[09:03] <DktrKranz> mh, no
[09:03] <imbrandon> ohh ok, one sec
[09:03] <DktrKranz> if it's queued, only Maintainer gets it
[09:04] <imbrandon> http://pastebin.ca/1869240
[09:05] <DktrKranz> yeahyeah, seen it on queued output.
[09:06] <imbrandon> the old upload have to be rm'd first or something
[09:07] <imbrandon> sorry this turned into a pita ;)
[09:08] <DktrKranz> np, if everything turns bad, we'll upload a -2 ;)
[09:08] <imbrandon> :)
[09:11] <imbrandon> heh got an email about the amd64 one now
[09:11] <imbrandon> same thing, someone else came first
[09:11] <DktrKranz> yup, I tried that way too
[09:11] <imbrandon> ;)
[09:11] <DktrKranz> soo, uploading a -2 will fix
[09:12] <DktrKranz> as I'm not confident enough to remove broken uploads already managed by dak :)
[09:12] <imbrandon> yup yup, go ahead and just add a superfuralus changelog entry if you want
[09:13] <imbrandon> or just change the version of -1 to -2 and skip -1 , whatever your more comfortable with
[09:15] <DktrKranz> I'll turn it -2
[09:16] <imbrandon> k
[09:18] <DktrKranz> ok, let's see now
[09:20] <DktrKranz> Apr 20 08:19:31 processing /apt-mirror_0.4.7-2_i386.changes
[09:20] <DktrKranz> Apr 20 08:19:31 /apt-mirror_0.4.7-2_i386.changes is already present on target host:
[09:20] <DktrKranz> Apr 20 08:19:31 Job apt-mirror_0.4.7-2_i386.changes removed.
[09:20] <DktrKranz> what?
[09:20] <imbrandon> wth
[09:20] <imbrandon> erm
[09:21] <imbrandon> definately strange
[09:21] <imbrandon> its all greek to me, i mean i know what its saying but not why
[09:23] <DktrKranz> definitely, I'll look after dinstall to see wth is happening
[09:24] <imbrandon> k
[09:24] <imbrandon> so like ~3 hours ?
[09:27] <DktrKranz> yup
[09:29] <imbrandon> kk
[09:59] <jetienne> q. where can i find the prerm script of an installed .deb ? i got one which is buggy, and so i can no more remove it
[09:59] <carstenh> ls /var/lib/dpkg/info/packagename.*
[10:00] <jetienne> carstenh: thanks
[10:46] <imbrandon> gnight all
[11:06] <geser> persia: as you have done all previous xserver-xorg-video-displaylink uploads: should I upload a FTBFS directly or give you a branch to merge/debdiff/just the quilt patch?
[11:06] <persia> geser: Please just upload.
[11:07] <persia> I don't understand.  I did my testbuilding always on amd64 :(
[11:08] <persia> Oh, chroot safety checking.
[11:08] <geser> persia: unless you do the same check like the buildds on pointer conversion, it will succeed
[11:09] <persia> Yeah.  I need to integrate that into my sbuild config.
[12:02] <Ciemon> Laney: could you give me a shout if you have 5 mins spare, I'd like you to confirm some findings on bug 343430
[12:04] <Ciemon> -
[12:05] <persia> I think that's a side effect of debian policy, and the easiest solution is to add a patch redirecting the menu item to /usr/share/doc/gpredict/copyright
[12:05] <persia> Unfortunate, as it means more patching of the code than is desired, but I think upstream did the right thing, and the packaging was correct, and it would be buggy to ship both copyright and COPYING.
[12:05] <Ciemon> hi persia, so the rules comes from Debian
[12:06] <persia> At least we share some portions of it, yes.
[12:06] <Ciemon> OK, well, the COPYING file comes with the source
[12:06] <persia> Right.
[12:06] <Ciemon> which is essentially a version of the GPL
[12:06] <persia> Ah, yeah, debian/rules is entirely from debian: the only ubuntu-specific patch is some .desktop file edits.
[12:07] <persia> Seems to be GPLv2.
[12:07] <Ciemon> ok.. so is there a copy of the debian policy that I can read to understand why the licence has been removed?
[12:08] <persia> Sure, I'll dig it up.
[12:08] <Ciemon> excellent
[12:08] <persia> Quick version is "to save space", because GPLv2 is shipped as /usr/share/common-licenses/GPL-2
[12:08] <persia> So we ought be patching the source to have Help...License show that file.
[12:08] <carstenh> reporting a bug in the debian bts would help
[12:09] <persia> Indeed.
[12:09] <Ciemon> I'm talking with the author, so I'll do it that way
[12:09] <persia> Ciemon: Upstream behaviour probably shouldn't change.  This belongs as a distribution patch because the bug is a side effect of distribution policy.
[12:10] <persia> I believe the upstream behaviour to be correct.
[12:10] <carstenh> fix seems to be replacing the path in the source code / configure / what ever with /usr/share/common-licenses/GPL-2
[12:10] <Ciemon> yeah, easily done.
[12:10] <persia> RIght, but *as a distribution patch*  There's no guarantee that file exists on a non-debian-derived system.
[12:11] <Ciemon> Right, thanks for taking time to explain.. it's all new.
[12:12] <carstenh> Ciemon: if you report this bug including a patch against debian this might raise the chances to get this fixed in debian and thus avoid work in ubuntu after syncing with debian next time
[12:13] <Ciemon> Will do, and I'll commment on the bug in launchpad.. which could effectively close it
[12:15]  * persia wishes pages at www.debian.org would load faster already
[12:15] <persia> carstenh: Well, given the nature of the issue, we'd probably want to do the work in Debian anyway.
[12:15] <carstenh> persia: try www.debian.tld
[12:16] <carstenh> persia: yes, but that does not imply that you really report it against debian
[12:16] <persia> We tend to.
[12:17] <persia> Either as a bug report, or by working with the Debian maintainers to apply a patch from an LP report.
[12:17] <carstenh> there are both, good and bad examples
[12:17] <persia> Unfortunately, yes.
[12:20] <persia> Ciemon: So, policy 12.5 indicates to reference the /usr/share/common-licenses/ files rather than include the entire license in debian/copyright.
[12:21] <persia> I can't find the bit that says not to ship upstream COPYING, but it's standard practice to not include it (as this information is always in copyright anyway)
[12:21] <persia> policy is available with apt-get install debian-policy, or mirrored in several places (I use http://www.debian.org/doc/debian-policy/ but it's very slow for me right now)
[12:22] <carstenh> persia: you can't find anything that is not there
[12:23] <persia> carstenh: OK.  So where is the bit that says we don't ship COPYING?  Is/was it in the maintainers guide?  Is it just a semi-oral practice guideline?
[12:23] <carstenh> when there is additional information like copyright holders it's perfectly ok to include the file
[12:23]  * persia always lists *all* the copyright holders in debian/copyright
[12:24] <persia> I'm sure I've been told to do this at some point, but I very much don't remember where or when.
[12:24] <carstenh> persia: but do don't patch source code to cat /usr/share/doc/packagename/copyright
[12:24] <persia> carstenh: No, the idea is to patch it to use /usr/share/common-licenses/GPL-2
[12:24] <persia> (which happens to be the same contents as COPYING)
[12:24] <persia> If it's not the same content, then that's not the solution, but I believe it to be the same.
[12:25] <carstenh> persia: yes. but given COPYING would contain copyright information and the help button would display this file there would be a regression if you would simply change the path
[12:26] <carstenh> if this is not the case common sense says /usr/share/common-licenses/GPL-2 is preferable
[12:26]  * persia runs diff to check
[12:29] <persia> http://paste.ubuntu.com/419181/ suggests to me that it ought be patched in debian to use the common-licenses file.
[12:30] <persia> And all Debian derivatives (including Ubnutu) would then have this issue resolved, without needing to significantly increase the installed-size of the application.
[12:31] <carstenh> persia: i didn't answer your question from 13:23:06. everything except debian policy is a recommendation (e.g. the debian developers reference) and might be ignored if you know what you are doing. this part of the policy (12.5) is worded as a suggestion, so it simply means: "do whatever you like if it's reasonable"
[12:31] <persia> Well, yeah, but still :)
[12:31]  * persia comments on the bug
[12:32] <carstenh> old fsf adresses are a lintian warning and debian tends to patch them anyway
[12:33] <carstenh> oh, this is not an old adress, just different whitespaces :)
[12:34] <persia> And an extra comma.
[12:34] <persia> (or a missing comma: I forget)
[12:34] <persia> Still, nothing worth shipping an extra file.
[12:41] <Ciemon> thanks for the comment persia, hopefully I'll get to write my first patch with this package
[12:42] <persia> Ciemon: Good luck.  Ask if you have questions.  As carstenh said, the right way to solve this is to report the bug to the BTS and post the patch there.
[12:43] <persia> (because this is also a bug in Debian)
[15:35] <warsocket> Hi, anyone fancy's to help me  get a gambas program properly packaged,  I kinda have probembs building a source package and getting a change file
[15:35] <warsocket> *which i can upload to REVU
[15:38] <maxb> warsocket: It's best if you can ask specific questions - people may have time to answer those when they don't have time to get involved in an extended discussion
[15:41] <persia> And many people prefer to answer specific questions even when they do have time for an extended discussion.
[15:42] <warsocket> ok
[15:43] <warsocket> Where can I get a good resource on creating source packages, google only gives me the how o I compile source packages answers
[15:45] <maxb> https://wiki.ubuntu.com/PackagingGuide/Complete can be a bit daunting because it is so large, but is a good thing to read
[15:46] <warsocket> Ok will re-read that one, tnx
[18:30] <c_korn> can dh_make be configuered not to create a orig.tar.gz file when specifying a orig.tar.bz2 with the -f option ?
[18:40] <persia> c_korn: The easy way around that is not touse dh_make :)
[18:42] <c_korn> persia: yeah, I thought you would say that :)
[18:52] <hyperair> the proper way is to fix dh_make
[18:54] <blueyed> is xulrunner-1.9.1 going to stay during lucid?
[18:54] <micahg> blueyed: no
[18:55] <micahg> blueyed: that's why I put the comment in the miro bug
[18:55] <blueyed> ah, hi :) - talking with willkg => #miro-hackers?
[18:55] <blueyed> have not read/catched up.
[18:55] <blueyed> when will it get removed?
[18:55] <micahg> blueyed: soon
[18:56] <micahg> blueyed: as soon as we verify all rdepends are gone
[18:56] <micahg> blueyed: do you want me to hop in miro-hackers?
[18:57] <blueyed> micahg: no. it's clear now.
[18:57] <blueyed> (mre)
[18:57] <blueyed> +o
[18:59] <persia> hyperair: Does "RM: I don't like it?" count as a fix?
[19:02] <hyperair> persia: it can, if you're convincing enough ;-)
[19:04] <persia> The problem is that dh_make is actually useful when teaching people why packaging works the way it does.
[19:04] <persia> I just don't believe it to be useful to actually package stuff (and believe relying on it to package stuff builds poor habits).
[19:05] <hyperair> persia: i like having a debian/control template done up for me actually =\
[19:05] <hyperair> but i think we've been through this argument before =)
[19:05] <persia> I guess.  What bothers me is that it7s always wrong.
[19:05] <Laney> I just copy from another package
[19:05] <persia> And wrong in subtle ways that test the packagers understanding of policy.
[19:06] <persia> Like I said, useful if you're teaching someone and want to test them.  Less useful if you're packaging.
[19:07] <persia> But it seems to be maintained, which makes it harder to remove.
[19:11] <hyperair> we should improve lintian to detect all of dh_make's flaws =p
[19:13] <hyperair> is anyone getting a launchpad that just has a red "Loading" rectangle at the top left corner?
[19:34] <blueyed> micahg: can you create a upstream xulrunner bug for bug 537050, please?
[19:38] <micahg> blueyed: I'll look into it
[19:39] <blueyed> micahg: great. http://bugzilla.pculture.org/show_bug.cgi?id=13169 has testcases - I'm not sure which one is better though.
[19:39] <micahg> blueyed: I'll take a look at that a little later
[19:43] <psusi> jdong: did you never get that defrag script you wrote packed and into the archives?
[19:46] <jdong> psusi: no, I didn't
[19:47] <psusi> doh
[19:48] <psusi> jdong: hopefully tonight I should have e2defrag working with extents... had a good go at it last night but still having a little trouble handling it when there are more than the 4 extents that can fit in the inode and the tree depth grows to 1
[19:49] <jdong> cool
[19:49] <psusi> all other ext4 features are working well so that will be the last thing to do I think before it should be ready to try and upload
[19:50] <joaopinto> hi, anyone familiar with the virtualbox package ?
[19:50] <psusi> I guess now I need to look into becoming a motu
[19:50] <joaopinto> is the "Install guest additions" expect to work ?
[19:56] <highvoltage> slangasek: /join #ubuntu-release
[19:56] <highvoltage> (oops)
[19:58] <\sh> joaopinto, it worked at my place with downloading the iso of the guest tools
[19:58] <joaopinto> strange, it warned about the download, but then nothing was installed/mounted
[19:58] <joaopinto> butI found that there is a package with the addons
[19:59] <joaopinto> a guest package
[19:59] <\sh> joaopinto, hmmm..i tested it on lucid 64bit
[19:59] <joaopinto> \sh, same here
[19:59] <joaopinto> it gave the "about to download warning"
[19:59] <joaopinto> oh wait, it is mounted after a reboot on the vm
[20:00] <\sh> joaopinto, yeah..and after download it was mounted in the gues os (win 7 testing) and I could install it without a hassle
[20:00] <joaopinto> \sh, thanks, it worked after restart the vm, but this is a lucid guest also
[20:00] <\sh> oh well I outed myself ;)
[20:00] <\sh> joaopinto, will test it tomorrow afternoon with some linux guests i think
[20:01] <joaopinto> anyway I decided to go with the guest package from the repository :)
[21:15] <micahg> blueyed: I have to see if the bug is in xulrunner or python-gtkmozembed
[21:26] <blueyed> micahg: have you gotten the test case(s)?
[21:26] <micahg> blueyed: not yet
[21:28] <blueyed> micahg: would help apparently. I've tested them both, but I think the one first posted is the way to go (the one just failing, without error on console) - but you want to test both maybe, if the first one does not work out.
[21:29] <micahg> blueyed: does the patch take care of us for lucid though or do we need to figure this out before release?
[21:29] <blueyed> micahg: we have a patch for lucid, and I've uploaded it already.
[21:30] <blueyed> but apparently it's a xulrunner bug.
[21:30] <micahg> blueyed: yes, I saw, just asking if that does it for miro
[21:30] <micahg> or if it's only a partial fix
[21:30] <blueyed> would be nice to get it fixed for lucid.
[21:30] <blueyed> partial fix, for now.
[21:30] <blueyed> it might break when fixing xulrunner, maybe.
[21:31] <micahg> blueyed: we'll get xulrunner updates as they're released, so we can get this fixed upstream later, I"m just wondering if it solves the issues entirely for Miro
[21:31] <blueyed> it's likely to influence other dependent apps, too.
[21:31] <blueyed> yes, it solves this particular issue.
[21:32] <micahg> blueyed: k, I'll try to keep an eye out for other apps that might show that errro
[21:33] <blueyed> xulrunner-1.9.1 gets deleted already?
[21:34] <micahg> blueyed: yeah, it should, I didn't see anything about binding to a certain xul in the patch
[21:37] <psusi> then links at http://ubuntuforums.org/showthread.php?t=169551 for joining MOTU seem to be wrong... they lead to pages documenting how to become a core developer, not a motu
[22:19] <ScottK> Since virtually no developers have anything to do with Ubuntu forums, it's not suprising that would be one more topic they are misinformed about (although I didn't look at the specifics of the case)
[22:20] <warsocket> I got a question about packaging,  how should i set $DESTDIR or should dh_make set it?
[22:21] <warsocket> it fials here in the makefile: cp gsmartdimmer-0.0.1.gambas $(DESTDIR)/usr/bin
[22:21] <warsocket> *it tries to copy to /usr/bin
[22:22] <maxb> It is the responsibility of debian/rules to pass the proper DESTDIR to make
[22:22] <warsocket> I just made that file with dh_make
[22:23] <warsocket> wich generated the debain deirectory for me
[22:24] <warsocket> so what directory should i set it to so debuild can make a binary package out of it?
[22:26] <warsocket> this line is in the debian/rules file under install:  but I guess it does not work ?
[22:26] <warsocket> $(MAKE) DESTDIR=$(CURDIR)/debian/gsmartdimmer install
[22:26] <maxb> That looks correct to me
[22:27] <warsocket> cp gsmartdimmer-0.0.1.gambas $(DESTDIR)/usr/bin
[22:27] <warsocket> but that gives an error
[22:27] <warsocket> because i cant write to /usr/bin
[22:27] <warsocket> just as if $DESTDIR is empty
[22:27] <warsocket> but it should be set
[22:28] <warsocket> *confused*
[22:31] <warsocket> *i checked with a echo in the makefile
[22:31] <warsocket> $(DESTDIR) is empty
[22:34] <dutchie> 21
[22:34] <dutchie> :(
[22:44] <warsocket> For anyone wondering im one step further, the rror was that install: was the top rule of my makefile
[23:29] <carstenh> persia: we broke topgit ... maybe cherrypicking from upstream instead of applying patches by hand would be less error prone
[23:31] <carstenh> persia: problem is that "dosomemagic" became "dosomemagic during copy and pasting
[23:40] <carstenh> persia: bug 566852 (hello bot)