[00:04] <debfx> I guess most debian-edu* packages should be removed as the debian-edu source package has already been removed from jaunty
[00:05] <lfaraone> ScottK: re bug 527978, should I just upload it as a 0ubuntu1? (will waiting for it to land in Debian miss the freeze?)
[00:11] <ScottK> lfaraone: At this point I'd get it uploaded to Ubuntu.
[00:12] <ScottK> debfx and ajmitch: It's not too late for removals, but we need bugs filed/subscribed to ubuntu-archive
[00:12] <ajmitch> ScottK: yep, that's what I was saying
[00:13] <ScottK> OK
[00:13]  * ajmitch is *still* patiently waiting for build-dependecies to download before testinbuilding this package
[00:13] <lfaraone> ScottK: done, https://code.edge.launchpad.net/~lfaraone/ubuntu/lucid/groundcontrol/gc1.6.5, attached to bug, will propose for merging shortly.
[00:13] <ScottK> OK.
[00:14]  * ScottK won't sponsor it so he can review it for the release team.
[00:24] <lfaraone> ScottK: I think nhandler offered to review it.
[00:26] <ScottK> OK.  Good.
[00:28] <debfx> ajmitch: could you ack bug #569959 ?
[00:28] <debfx> persia: thanks for sponsoring the ftbfs fixes
[00:29] <persia> debfx: Thanks for creating them.  Nice to have working software.
[00:30] <ajmitch> does anyone have objections to removing/blacklisting debian-edu-*? I can't really see how they're useful, but I could be wrong
[00:31] <persia> stgraber: Any thoughts on that?
[00:31]  * persia is of the "toss it: it's not helping" mindset, personally
[00:33] <debfx> I finally figured out why reverse-build-depends doesn't work for me: I thought it uses lucid by default, the help says the default is karmic but in fact it's maverick ^^
[00:33] <ScottK> debfx: Accepted your fixes.  Thanks.
[00:34]  * ScottK leans in favor of removals like debian-edu stuff
[00:35] <persia> debfx: It was lucid up until *very* recently, when it was switched to maverick for the next release.  Extra points for submitting a patch that changes the help to indicate "the current development release" or has the help dynamically be correct based on the source.
[00:35] <ajmitch> current development release can be fetched from LP with a few lines of python, if you're prepared to depend on launchpadlib
[00:36] <debfx> persia: already checked out the ubuntu-dev-tools branch :)
[00:36] <ajmitch> launchpad.distributions['ubuntu'].current_series.name is what you want
[00:37] <lfaraone> ScottK: what time does this have to be in the queue by?
[00:37] <debfx> ajmitch: that
[00:37] <ScottK> lfaraone: Sooner the better, but we have a day or two if needed.
[00:37] <debfx> ajmitch: that would make r-b-d require an internet connection
[00:38] <ajmitch> debfx: yes
[00:38] <debfx> and it's written in perl
[00:38] <ajmitch> or to store this somewhere
[00:38] <lfaraone> ajmitch: I thought I had them blacklisted last release...
[00:38] <lfaraone> ajmitch: (re edu)
[00:38] <ajmitch> lfaraone: debian-edu-* ?
[00:39] <lfaraone> ajmitch: yes.
[00:39] <persia> I think u-d-t already depends on launchpadlib for some other stuff, but be nice if it used anonymous credentials to avoid needing to register credentials for yet another tool.
[00:39] <ajmitch> such as doing launchpad = Launchpad.login("ubuntuwire rcbugs", "", "", EDGE_SERVICE_ROOT)
[00:40] <ScottK> Should it use edge though?
[00:40] <ajmitch> easy way to login anonymouly, though that code is written for karmic
[00:40] <ajmitch> probably not, but it's what I was used to using
[00:45] <lfaraone> I'm working on a utility to automate the updating of packaging to bzr/hg/git heads, and am planning on including it in u-d-t. I'm also intending to write a full testsuite for it, including sample repositories of each. (less than a couple KB, gzipped). Would this be accepted? (as if I didn't gzip the repos bzr would interpret them as nested git trees)
[00:48] <persia> lfaraone: I think there exist several utilities that do that: check foo-buildpackage as a start.
[00:49] <persia> The mr package may be even more interesting, as it's intended to work with arbitrary VCS.
[00:50] <lfaraone> persia: my goal is that you can do this regardless of what VCS you use yourself for your packaging, or even if you use none at all.
[00:50] <debfx> lfaraone, ajmitch: should I update the debian-edu bug to request the removal of debian-edu-*?
[00:50] <persia> lfaraone: So, add a "null" module to mr :)
[00:51] <persia> debfx: A new bug will be less confusing, but reference the old bug in the new bug.
[00:51] <lfaraone> persia: right now it pulls the upstream changelog from the upstream commits between now and the last release and formats it as a debian changelog.
[00:51] <lfaraone> persia: that's fine.
[00:51] <persia> lfaraone: Please *don't* do that.  There's a reason we ship the upsteam changelog separately from the debian changelog.
[00:52] <persia> You should ship both (as indicated by the various packaging guides, and supported by lintian), and you should put "New Upstream Version" when you upload a new upstream version, and only note critical changes that are especially interesting.
[00:52]  * ScottK has some binary New to do thanks to debfx.
[00:52] <lfaraone> persia: we're asssuming upstream lacks a changelog.
[00:52] <persia> lfaraone: That's either a bad assumption, or supports poor practices on the part of upstream.  Please don7t.
[00:52] <lfaraone> persia: so you're saying http://packages.debian.org/changelogs/pool/main/p/pianobar/pianobar_0+git20100420.3072c5a-1/changelog is terrible practice? (for an upstream which only has snapshots)
[00:52] <persia> Yes.
[00:54] <persia> 1) bad of upstream to only have snapshots, 2) bad of upstream to rely only on VCS logs for changelog, rather than describing things for end-users, 3) annoying verbosity in debian/changelog that is also available in an upstream changelog (even if the package source build requires scraping it out of the upstream VCS with git shortlog)
[00:55] <lfaraone> persia: According to DPM § 4.4, debian/changelog "includes modifications made in the Debian package compared to the upstream one as well as other changes and updates to the package."
[00:55] <lfaraone> persia: that excludes upstream changes?
[00:56] <ScottK> Generally it does.
[00:56] <ScottK> It's sometimes considered good to mention major changes in the package.
[00:57] <persia> lfaraone: The key bit is "compared to the upstream one"
[00:57] <ScottK> That's since apt-listchanges just shows the Debian changelog.
[00:57] <persia> lfaraone: But that comparison only makes sense when the upstream changelog is also made available.
[00:57] <ScottK> But it's just key bits, not the whole thing.
[00:58] <persia> The other thing about the pianobar changelog is that it has lots of frequent uploads, which indicates either that you're spending a lot of time pushing every patch, or that upstream is highly unstable and buggy.
[00:59] <lfaraone> persia: former, I've only had it crash on rare occasions. Which is why I wrote said script to automate this.
[00:59] <persia> But it really deoesn't help most users to get a new downoad every day or two.
[00:59] <lfaraone> I test the new upstream release for about a day, then put it up.
[00:59] <persia> Most users want to have things just work, and don't want updates.
[01:00] <lfaraone> persia: then they should track testing.
[01:00] <lfaraone> (no?)
[01:00] <persia> No.
[01:00] <persia> A maintainer should make the package as close to perfect as possible, and release it.  Then focus on someting else (maybe working to make upstream perfect, maybe another package, etc.)
[01:01] <lfaraone> persia: a good number of these uploads are either fixes, or new features.
[01:01] <persia> When there's a new upstream release that's well tested and offers significant advantages to users, that should again be prepared with effort to make it as perfect as possible.
[01:01] <debfx> persia: where should I file a package blacklist bug?
[01:02] <persia> debfx: In launchpad, against the package.  Typically it's just added as a note in the package remove request.
[01:02] <persia> In the rare case where we want to blacklist-but-not-remove, it gets it's own bug.
[01:03] <ScottK> lfaraone: The other thing with frequent uploads is that the Debian buildd network is overloaded and behind, so by uploading very frequently you delay the transition of other packages to Testing.
[01:03] <persia> lfaraone: Check with someone else, but it's very much not my style.  The complete lack of closing any bugs reported in Debian indicates that the selection of fixes and features appears more interseting to someone closely watching upstream than someone who7s just using it.
[01:03] <debfx> persia: it would be a request to blacklist and remove debian-edu-*
[01:03] <persia> Then again, I make a practice of packaging stuff where upstream is so stable as to appear dead to most folks, so perhaps I'm biased :)
[01:04] <persia> debfx: Right.  Generally if you request removal of stuff still in debian, the archive-admins will blacklist at the same time.  It doesn't especially hurt to note it in the bug, but it may not help.  Having an extra bug just makes the archive-admins have to process more bugs.
[01:04]  * micahg seems to gravitate to stuff that moves fast upstream
[01:05] <ScottK> Speaking of which, where's seamonkey?
[01:05] <micahg> in progress :-/
[01:05] <micahg> people found a few issues
[01:06] <persia> debfx: You hit a few gcc 4.4 bugs today: any idea why http://launchpadlibrarian.net/44677571/buildlog_ubuntu-lucid-armel.musescore_0.9.6~beta1+dfsg-0ubuntu1_FAILEDTOBUILD.txt.gz would be an arch-specific build failure?
[01:06] <persia> (I'm not asking for a fix, just curious if it is obvious to someone else)
[01:10] <debfx> persia: Typedef for double on all platforms except for those using CPUs with ARM architectures. On ARM-based platforms, qreal is a typedef for float for performance reasons.
[01:10] <debfx> instead of double it should return qreal
[01:10] <persia> Aha!  That directly contradicts the bit someone told me about not using floats in armel for performance reasons, but certainly explains the oddities :)
[01:14] <debfx> persia: not sure why it doesn't automatically typecast float to double
[01:14] <persia> Doesn't matter.  Not going to be fixed for lucid.
[01:15] <micahg> ScottK: shooting for morning
[01:15] <persia> When we find out what new toolchain features will be enabled on armel for maverick, we can ask about that sort of thing, although it may have to wait for a new ABI from Qt.
[01:15] <ScottK> micahg: What timezone?
[01:15] <micahg> ScottK: CDT
[01:15] <persia> UTC-5?
[01:15] <micahg> yes
[01:16] <ScottK> micahg: OK.  Make it early then.  I'm flying from -0400 to -0700 tomorrow and probably need to get it done before I'm in the air.
[01:16] <micahg> ScottK: what time is that?
[01:16] <ScottK> micahg: Around lunch time.
[01:17] <ScottK> I don't want to depend on airport wireless to get it done.
[01:17] <micahg> k, well,I might end up staying up to finish then
[01:17] <micahg> in which case morning in Europe
[01:18] <ScottK> OK.
[01:18] <micahg> ScottK: also what to do with bug
[01:18] <micahg> oops
[01:18] <micahg> bug 532232
[01:19]  * micahg seems to have a broken keypad
[01:25]  * ScottK looks
[01:27] <ScottK> micahg: Is it totally broken as is?
[01:27] <micahg> ScottK: lightning is, sunbird isn't AFAIK
[01:28] <micahg> ScottK: Thunderbird 3 requires lighning 1.0 beta 1
[01:28] <ScottK> But we're just talking about updating lightning, right?
[01:29] <persia> ajmitch: Still about?  bug #528957 would benefit from gilir's patch (I've tested it a fair bit, and so have some others).
[01:29] <micahg> ScottK: well, it's built out of the same source, and there's more to the story
[01:29] <ScottK> micahg: OK.
[01:29] <micahg> ScottK: upstream has discontinued development on sunbird and is only developing lightning, we were thinking to only build a new lightning and a stub sunbird
[01:30] <ScottK> OK.
[01:30] <ajmitch> persia: still about, just been having some ssh issues :)
[01:30] <ScottK> micahg: So does sunbird get removed?
[01:30] <micahg> ScottK: it's too late for the ideal thing which would be to rename the source, but yes, I think sunbird would get removed
[01:31] <persia> ajmitch: Sorry to hear that.  May you be blessed with high entropy input.
[01:31] <ajmitch> persia: just curious why you're pinging me about it?
[01:31] <ajmitch> ah, patch is against a main package
[01:33] <ajmitch> I'm guessing that libsdl1.2 isn't on the CDs & it's not too late to push an upload fir it
[01:34] <persia> The trick is to have it all compiled-like before the image rebuilds happen Monday UTC-7 :)
[01:34] <persia> OK.  Maybe SRU then.  Alas.
[01:34] <debfx> could someone please have a look and possibly ack bug #569959 ?
[01:35] <ajmitch> persia: it's the release team's call, I'll set it building here
[01:35]  * ajmitch would really like an SSD for the laptop about now
[01:36] <ajmitch> debfx: ACked
[01:36] <ajmitch> I checked & debian-edu is on the blacklist, just not the other packages
[01:37] <debfx> ajmitch: ok, thanks
[01:40] <ajmitch> persia: to be honest, it looks like something that'll probably be SRU material, given that it's just affecting something in universe at this stage
[01:40] <micahg> ScottK: does that plan sound ok for lightning?  I think we also need to update the locales or we lose all the translations
[01:40]  * persia wonders why debootstrap --variant=buildd is installing exim4 in Debian
[01:40] <persia> ajmitch: Fair enough.
[01:40]  * persia was just reviewing "unseeded bugs" opportunities to sponsor, and that appeared, except it needs a "core" sponsor.
[01:41] <ScottK> micahg: I'd like asac or someone to ack the sunbird removal, but generally, yes.
[01:41] <ajmitch> ScottK: able to comment on http://launchpadlibrarian.net/44484053/libsdl1.2_1.2.14-4ubuntu2.debdiff being SRU or fixing it now?
[01:41] <micahg> ScottK: k, he or chriscccoulson would be doing the uploads
[01:42] <ScottK> ajmitch: SRU.  It doesn't fit the RM's criteria for post-RC Main uploads.  You can upload to -proposed now.
[01:42] <ajmitch> ScottK: thanks
[01:42] <ScottK> No need to wait.
[01:43] <ScottK> It just won't get accepted until Thursday, modulo release team mistakes about accidentally accepting stuff in proposed (I did that once already)
[01:43]  * ajmitch will change version & target release for it
[01:43] <ScottK> Thanks.
[01:50] <persia> Anyone want to review the (large) changes in bug #565206?  I don't know enough about the software in question to have any idea if this would be a good thing.
[01:50]  * persia thinks it needs review *before* getting an FFe reevire
[01:51] <persia> s/reevire/review/
[01:55] <ScottK> persia: From reading the changelog, the deprecation warnings concern me.  It does sound like the package is pretty broken at the moment and so I think a bias towards accepting is generally appropriate.
[01:56] <ScottK> I can confirm that scidavis is not alone in having gotten bitten by some changes on Qt 4.6.
[02:14] <persia> ScottK: Thanks.
[02:15] <persia> Anyone up for testing it?  I'll enqueue it, but I'm not sure I'll hit it soon enough to do it justice and get it uploaded.
[02:20] <ajmitch> how testable is it?
[02:22] <persia> You'd want a dataset, and some ideas how to plot it nicely, at least.
[03:45] <ScottK> geser: If you get a chance, it looks like libepc is in need of one of your GTK deprecation fixes.
[06:11] <YokoZar> ScottK: got a wine1.0 package ready to upload, will followup with wine1.0-gecko, new wine1.2 and wine1.2-gecko that conflict properly, and then finally a new vst
[06:12] <ScottK> OK.
[06:48] <Rhonda> persia: That's on intention not in the series file - see the difference between the .in file and the one without - and the debian/branchcheck script. :)
[06:53] <YokoZar> ScottK: ok, all uploads except -vst done
[06:54] <ScottK> right.  YokoZar you know what time it is here, right?
[06:54] <YokoZar> ScottK: Feel free to do it in the morning ;)
[06:54] <ScottK> Which one needs to build before you can do vst?
[06:54] <YokoZar> wine1.0
[06:55] <ScottK> OK.  Let's see if I can manage to stay awake for that one.
[06:56] <YokoZar> It's best if they come in a group methinks, so feel free to go to bed and do it when you're fresh ;)  (IIRC, it's about 2am there?)
[07:02] <ScottK> It is.
[07:02] <ScottK> I have to be up in ~4 hours, so I'll only be so fresh ....
[07:09] <micahg> ScottK: progress on SM, I think the package works now, having one more person test, then working on integrating fixes back into branch
[07:16] <ScottK> Great.
[07:17] <ScottK> YokoZar: I let the two wine1.0 packages in.  They'll hit binary New after they build, it I'll get that in the morning.
[07:21] <dholbach> good morning
[07:41] <ajmitch> morning dholbach
[07:41] <dholbach> hey ajmitch
[07:44] <imbrandon> heya dholbach
[07:45] <dholbach> hey imbrandon :)
[07:50] <suji11> hi
[07:55] <suji11> my package IOK(Indic Onscreen Keyboard) is already in ubuntu repository, now i have to bring this to debian repository how to do that?
[07:55] <suji11> i follow this link https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers?action=show&redirect=ContributingToDebian and made changes in "how do i do" then what should i do? again should i send that package to revu.ubuntuwire.com?
[07:59] <DktrKranz> lfaraone: done
[08:03] <imbrandon> suji11, the equivalent would be mentors.debian.net
[08:04] <suji11> imbrandon: Thank you:)
[08:09] <suji11> can i remove a package from revu.ubuntuwire.com which is unknowingly sent by me ?
[08:16] <imbrandon> suji11, just archive it
[08:21] <carstenh> suji11: at the first sight your package looks quite good, but there are still a few things that could be improved: 1. lintian -I complains about hyphen-used-as-minus-sign and already did when you created the package 2. people maintaining packages in debian generally have a given name and a family name and use both in their packages 3. the description should be improved, I think the debian developers reference has something about how to ...
[08:21] <carstenh> ... write good descriptions
[08:25] <carstenh> suji11: http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-pkg-synopsis
[08:46] <geser> ScottK: libepc done
[10:20] <suji11> imbrandon: my package IOK is now in the version of 1.3.9 but i have to update it to 1.3.10 , how to do that?
[11:08] <ivoks> er...
[11:14] <ivoks> any archive admins here?
[11:25] <ScottK> ivoks: What's up.
[11:26] <ivoks> ScottK: bug 570096
[11:26] <ivoks> ScottK: abi is broken, hell is freezing :)
[11:26] <ScottK> Ah.  I can't do the actual sync for that.
[11:26]  * ScottK loooks
[11:27] <ivoks> we already have confirmations of problems it is causing :/
[11:29] <ScottK> OK.
[11:31] <ScottK> ivoks: See #ubuntu-devel.  That should take care of it.
[11:31] <ivoks> ScottK: good night :*
[11:43] <Ciemon> nigelbabu: ping?
[11:45] <Ciemon> Just looking through https://wiki.ubuntu.com/ReviewersTeam/GettingInvolved is it worth linking Workflow para 2 - " forward the bug and patch upstream" to https://wiki.ubuntu.com/Bugs/HowToTriage#Forwarding upstream ?
[11:45] <Ciemon> I had to search for it.. say yes and I'll make the change.
[11:47] <Laney> Be bold and do it!
[11:48] <Ciemon> :)
[11:48] <Ciemon> He can always rollit back I guess
[11:48] <Laney> erm
[11:49] <Laney> "If the change is significant enough to be fixed in Ubuntu, get the patch uploaded."
[11:49] <Laney> what of forwarding to Debian in that case?
[11:50] <Laney> hmm
[12:57] <imbrandon> Ciemon: yes, make the change, was likely an oversight
[12:57] <Rhonda> Is it possible to cowbuilder --create ubuntu chroots on a Debian system? What --mirror should one use for that?
[12:58] <imbrandon> Rhonda: yes, and the normal ones you would use for ubuntu updates
[12:58] <imbrandon> eg <cc>.archive.ubuntu.com
[12:58] <Rhonda> Thanks. Hmm, now cdebootstrap tells me E: Unknown suite $everything
[12:59] <Rhonda> So I think I would need to create some additional files. :)
[12:59] <carstenh> debootstrap ...
[12:59] <Rhonda> Hmm, but there is /usr/share/cdebootstrap/generic-ubuntu in the cdebootstrap package, makes me wonder …
[12:59] <carstenh> dpkg -L debootstrap | grep whatyouwant | wc -l sould print 1
[12:59] <imbrandon> Rhonda: yea, the debian wiki on it looks to cover the adding of suites
[13:00] <imbrandon> ubuntu suites, that is
[13:00] <Rhonda> Ah, /usr/share/cdebootstrap/suites :)
[13:00] <Rhonda> Oh, it only goes up to intrepid.
[13:02] <imbrandon> should be trivial to "backport" the needed packages from ubuntu lucid OR ( what i would recomend ) just add the needed suites manualy to the scripts
[13:02] <imbrandon> just make sure if you manualy do it you record your changes etc for updates
[13:03] <Rhonda> Ah, seems I need to have ubuntu-archive-keyring.gpg installed, too.
[13:03] <imbrandon> yes if you dont want the gpg errors ;)
[13:03] <imbrandon> Rhonda: are you doing this on unstable ?
[13:04] <Rhonda> imbrandon: lenny
[13:04] <imbrandon> Rhonda: ahh , you might look at the sid packages, they are likely to have newer scripts
[13:04] <imbrandon> but honestly thats all they are, scripts that are basicly copy/pasted from release to release with minimal to no changes
[13:05] <Rhonda> I am currently switching from cdebootstrap (lenny) to debootstrap (lenny-backports). That might be also pretty helpful. :)
[13:05] <imbrandon> ;)
[13:06] <imbrandon> if you run into a snag holler, its been a while since i have run debian proper but there are plenty of us arround that have and should be able to get ya threw it
[13:06] <carstenh> both, debootstrap and cdebootstrap-static from sid work on lenny
[13:06] <imbrandon> mostly on my dev machines i run ubuntu lts's with other ubuntu and debian chroots, so i do the opsite ;)
[13:07] <Rhonda> carstenh: Sure, but I like to keep my system as clean as possible. You know that I'm a perfectionist in my approaches. :)
[13:07] <imbrandon> heh, dev machine and clean ? hahahaha , i mean good luck .... just teasin
[13:07] <lfaraone> ScottK: DktrKranz uploaded gc 1.6.5 to unstable 5 hours ago. Should I convert that back to a sync request?
[13:08] <Rhonda> imbrandon: That's why one uses tools like cowbuilder in the first place - remember? :)
[13:09] <carstenh> Rhonda: you just need to redefine "clean", I use a private partial sid mirror as excuse to install such packages on stable
[13:09]  * Rhonda jumped at the sight of "1.6.5" and thought wesnoth.  %-/
[13:09] <imbrandon> Rhonda: if the needed suites arent in lenny-backports you can also use ~/.* files too to "amend" the scripts
[13:09] <imbrandon> its just a bit more involved in the setup
[13:09] <imbrandon> not much though
[13:09] <Rhonda> imbrandon: Sure, but with debootstrap from lenny-backports it at least started something, which is more than before. :)
[13:09] <imbrandon> :)
[13:10] <Rhonda> And I usually do a "cp -a squeeze sid" anyway because sid has issues with bootstrapping anyway, so that part isn't troubles here.
[13:10] <carstenh> persia: i uploaded topgit to debian today, including the patch that you uploaded to ubuntu. if you want to tag this in ubuntu somehow ...
[13:11] <imbrandon> Rhonda: yup, basicly the same concept
[13:12]  * imbrandon needs to read a couple of chapters in his shiney new git book today
[13:14] <imbrandon> i should probably have a debian proper vm , hum, maybe something else to put on my todo for this week
[13:15] <imbrandon> anyone else excited about pbuilder-cross :) hehe
[13:18] <lfaraone> imbrandon: I've always been able to get away with pbuilder-sid login, unless something requires dbus or anything odd like that.
[13:19] <imbrandon> lfaraone: yea mostly it does, but for X and corner cases it good to have one arround
[13:19] <imbrandon> dosnt take nothing but hdd space and thats easy to come by
[13:25] <hyperair> what's pbuilder-cross?
[13:29] <imbrandon> hyperair: new crossbuilder in expirimental with multistrap vs debootstrap
[13:30] <hyperair> imbrandon: er. in english, please?
[13:30] <hyperair> exactly how "cross" are we going?
[13:30] <imbrandon> eg pbuilder-cross arm some.dsc , on a x86 machine
[13:30] <hyperair> cross-arch?
[13:30] <hyperair> is it something like qemubuilder?
[13:30] <imbrandon> sorta
[13:30] <hyperair> interesting
[13:31] <hyperair> what does it use?
[13:31] <imbrandon> gcc's native cross compiling ability and multistrap
[13:36] <lfaraone> ScottK: now that gc1.6.5 is in debian, there's no reason to upload the 0ubuntu1 version, right?
[13:38] <ScottK> lfaraone: At this point a straight upload is easier.
[13:40] <lfaraone> ScottK: Huh. Are the archive admins busy handling last-minute removals, or am I missing something?
[13:40] <hyperair> imbrandon: what's multistrap?
[13:41] <ScottK> lfaraone: Generally they are all busy people.  Archive admin is not a full time job.  So I wouldn't assume there will be any availability to do it.
[13:41] <imbrandon> hyperair: like debootstrap but for bootstraping other arches easier than traditionaly with debootstrap + apt-cross
[13:41] <ScottK> lfaraone: If someone uploads -1 using requestsync, we get to ~ the same place.
[13:41] <ScottK> requestsync/syncpackage
[13:42] <hyperair> imbrandon: that's cool stuff. (and this is the first time i've heard of apt-cross)
[13:43] <Daviey> Does that mean essentially sponsoring an upload, from Debian?
[13:43] <imbrandon> iirc archive admin duties are only done like 4 out of 7 days a week and of those 4 days its "rotated" between the admins for whos "day" it is, that was the case last i looked into it more than a year ago
[13:43] <Laney> it's just directly uploading a sync instead of waiting for an AA to push the button
[13:43] <Daviey> ah
[13:43] <ScottK> Daviey: Yes.  Essentially you take the Debian package, run syncpackage over it to get a .changes that ~ looks like it came from Debian, and upload.
[13:44] <lfaraone> ScottK: okay. but you can't upload it, since you have to review it.
[13:44] <ScottK> This is true.
[13:44] <lfaraone> ScottK: do I need ubuntu-release approval before a motu would touch it?
[13:44] <ivoks> i got waiting for approval :)
[13:44] <ScottK> I suspect imbrandon will upload it.
[13:44] <imbrandon> i can upload
[13:44] <ScottK> lfaraone: No.  People should upload and wait for reviews in the queue.
[13:45] <lfaraone> imbrandon: thanks, that'd be awesome.
[13:45] <ivoks> could we prioritize this?
[13:45] <ivoks> for example, i'm waiting to get approval for cluster-agents
[13:45] <ivoks> cause i can not upload two other packages untill this one is built
[13:45] <imbrandon> ScottK / lfaraone : is the package in question ready for upload or are we talking here in a little bit ?
[13:46] <lfaraone> imbrandon: it is already in Debian.
[13:46] <Daviey> ivoks: Can you not build depend on a $VERSION?
[13:46] <lfaraone> imbrandon: http://ftp.de.debian.org/debian/pool/main/g/groundcontrol/groundcontrol_1.6.5-1.dsc
[13:46] <imbrandon> ivoks: i'm sorry i'm not familiar with what you have going
[13:46] <imbrandon> lfaraone: k, i'll grab it here in justa few moments and ping ya when its uploaded ( should be less than 30 min )
[13:48] <ivoks> Daviey: i could
[13:48] <Daviey> ivoks: If you do that, then you should be able to fire off your two uploads; and they should just get a Dep Wait.
[13:48] <nigelbabu> Ciemon: pong.  but I guess you're question is already answered :)
[13:48] <lfaraone> ScottK: what was the reason syncpackage was removed from u-d-t, by the way?
[13:49] <ScottK> lfaraone: Because historically we have discouraged use of things like this and adding it right before release without a lot of discussion didn't seem like a great idea.
[13:49] <ScottK> BTW, it wasn't removed, it's in the source, it just doesn't get included in the binary.
[13:50] <lfaraone> ScottK: ah. I'm confused: what's the harm in this if Archive Admins would just take the action based on the MOTU's request anyway?
[13:50] <ivoks> Daviey: but that's not correct
[13:50] <lfaraone> (I don't see why it's discouraged, that is)
[13:50] <Daviey> ivoks: How so?
[13:51] <ivoks> Daviey: cause new version of lucid's package B could work with karmic's package A
[13:51] <ScottK> lfaraone: There's more risk of error if the package is touched manually than done via the archive.
[13:51] <ivoks> Daviey: it's just that current lucid package A is broken
[13:51] <ScottK> ivoks: It's accepted, FYI.
[13:51] <ivoks> Daviey: so, making a hard dep on new version is wrong
[13:52] <ivoks> ScottK: thank you! :)
[13:52] <ivoks> ScottK: i'll have one more :/
[13:52] <ScottK> YokoZar: Don't forget to file a bug for removal of the wine source package (if you didn't already).
[13:52] <ScottK> OK
[13:52] <lfaraone> ScottK: okay. I just think that if we had a method for MOTUs to take the action directly, it would save the AAs a lot of work. Especially since from what I can tell the AAs aren't reviewing the request.
[13:53] <ScottK> lfaraone: The desired solution is a button in LP.
[13:53] <lfaraone> ScottK: yes, that would be ideal.
[13:53] <lfaraone> ScottK: so what we have now isn't for some oversight reason, just because we don't have the technical measures to work around this?
[13:53] <Daviey> ivoks: Hmm, i've done that multiple times.. Do you have a quote from Debian policy, or similar that states it shouldn't be done?
[13:54] <ivoks> Daviey: i said it isn't correct, not that there's a policy :)
[13:54] <ScottK> lfaraone: Someone needs to implement the button in LP is the only reason we don't have it.
[13:55] <Daviey> ivoks: Ahh!  It's a trick i've done a couple of times to ensure multiple packages get built in the correct order; therefore linking against the version i want it to.
[13:55] <lfaraone> ScottK: okay. is there a bug report for that? (I might want to look into implementing it in the copious free time I'll have after Lucid and Finals)
[13:55] <ScottK> Daviey: Artificially bumping version requirements is not a good idea.  I do it sometimes myself, but am careful to docment the fact that it's artificial and when it can go away.
[13:55] <ScottK> lfaraone: I'm sure there is.  It'll be against soyuz.
[13:56] <Daviey> ScottK: it's all in the changelog :)
[13:57] <imbrandon> ScottK: is syncpackage broken atm ?
[13:58] <ScottK> imbrandon: Not that I know of.
[13:58] <imbrandon> ScottK: hum ok
[13:59] <imbrandon> E: No credentials found for 'ubuntu-dev-tools', please see the manage-credentials manpage for help on how to create one for this consumer.
[14:00] <lfaraone> ScottK: not afaict, but bug 529933 seems similar. (and one that would need unblocking before we can add the button
[14:00] <ScottK> I'm almost certainly not the one to be discussing LP development with.
[14:00] <imbrandon> ScottK:  ~/.bin/syncpackage groundcontrol_1.6.5-1.dsc lucid
[14:00]  * ScottK has no idea about it.
[14:00] <imbrandon> then i get that
[14:00] <imbrandon> hum hum
[14:01] <ScottK> Weird.
[14:01] <imbrandon> and a big fat traceback
[14:01] <lfaraone> imbrandon: do you have your credentials stored?
[14:01] <lfaraone> imbrandon: does "requestsync --lp hello" work?
[14:01] <ScottK> imbrandon: I gather someone has "improved" the original version.
[14:02] <ScottK> lfaraone: Why on earth would someone make a script require authenticated access to LP to read information?
[14:02] <ScottK> Now I'm really glad I didn't include it.
[14:02] <imbrandon> lfaraone: no i dont , but why should i need it
[14:02] <lfaraone> ScottK: I've got no idea, but that's a problem for later :)
[14:02] <Daviey> ScottK: It was probably written before LP API had anon access.
[14:02] <lfaraone> imbrandon: try the original at http://people.canonical.com/~pitti/scripts/syncpackage I guess :)
[14:03] <ScottK> Daviey: We've had a script that worked for years.
[14:03] <lfaraone> (which does not seem to use the API)
[14:03] <Daviey> ScottK: But that answers why it requires authenticated access to purely read public info.
[14:03] <ScottK> imbrandon: Use this one http://people.canonical.com/~pitti/scripts/syncpackage
[14:03] <ScottK> Daviey: No.  That's how.  The why is someone is an idiot.
[14:04] <ScottK> That's the unimproved one
[14:05] <Daviey> seems somewhat harsh. ho hum.
[14:06] <Laney> Right, the LP API stuff in udt could be improved to use anon access as appropriate
[14:06] <imbrandon> ScottK: http://paste.ubuntu.com/422767/
[14:07] <imbrandon> from "unimproved"
[14:07] <Laney> . o O ( and maybe syncpackage could be made to fallback to the old apt-cache madison way )
[14:08] <ScottK> Ah.
[14:08] <imbrandon> where is it getting the '2.5' ?
[14:08] <ScottK> That's the a python thing
[14:09] <imbrandon> ugh ok so i need to force it to use 2.5 ? or ...
[14:09] <ScottK> This is the exact class of package that pitti's version didn't work with.
[14:09] <ScottK> I think mine will.
[14:09] <imbrandon> heh
[14:09] <imbrandon> k
[14:12] <ScottK> Checking and then I'll get you the fix
[14:14] <ScottK> imbrandon: http://paste.debian.net/70708/
[14:15] <ScottK> With that it works.
[14:15] <ScottK> Daviey: Actually I think it's not harsh at all.
[14:15] <ScottK> Daviey: If you consider that my LP ID is allowed to put new code into -updates for all Ubuntu users, you might then get an idea why I think it's lunacy to give any more code rights to use it than absolutely necessary.
[14:16] <Daviey> ScottK: The authors of the tools should have written in anon API access before it existed?
[14:16] <ScottK> Daviey: No.  They should have kept using rmadison until it did.
[14:16] <Daviey> or worse, screenscrape?
[14:16] <Daviey> ScottK: ok.
[14:16] <ScottK> As I said, we've had a script that worked reasonably well since before the LP API even existed.
[14:18] <Daviey> ScottK: Oh aye.
[14:21] <imbrandon> ScottK / lfaraone : uploaded
[14:22] <ScottK> Thanks.
[14:22] <ScottK> BTW, it took a long time to figure out changing only those two lines ....
[14:22] <imbrandon> ScottK: heh
[14:23] <imbrandon> hum manage-credentials seems a bit broken too atm
[14:23]  * imbrandon looks more
[14:26] <imbrandon> ugh, better things to do, but yea manage-credentials is complaining about not reading something from /tmp/
[14:29] <Rhonda> Ah! Wait! … erm. … how can I hand cowdancer the components that it should look at? It seems to only look at "main".
[14:30] <carstenh> pbuilder uses --components "main contrib non-free"
[14:30] <imbrandon> lfaraone: " - Fixes to fixes" hahahah seriously ?
[14:30] <Rhonda> Right, /me tries --components 'main universe' now.
[14:31] <carstenh> pbuilder update --overrite-config --components ...
[14:32] <lfaraone> imbrandon: I know, right? :)
[14:32] <Rhonda> carstenh: I can only update if there is something. the create failed. :)
[14:32] <Rhonda> And if that would be the case I'd just do sudo vim hardy/etc/apt/sources.list
[14:37] <ScottK> lfaraone and imbrandon: Accepted.
[14:37] <ScottK> Thanks.
[14:41] <lfaraone> ScottK: thanks again.
[14:48]  * Rhonda thinks she needs to set a few also affects for wesnoth-1.8 in the wesnoth bugs …
[14:52] <callum1> hi all, packaging newbie here have hit a problem when running debuild -S hopeing someone can help me :)
[14:56] <callum1> the error I am seeing can be seen here: http://ubuntu.pastebin.com/HJW3C2PM
[14:57] <imbrandon> ScottK / lfaraone : ty ty
[14:58]  * Rhonda hides behind persia, I fumbled with bug #109434
[15:00] <imbrandon> let me guess, someone dosent think it should
[15:01] <imbrandon> when will people realize its the debian way that if you have a service/server installed its "on", this isnt redhat from 1998 where everthing under the sun was installed but off by default ;)
[15:02] <joaopinto> callum1, the error is kind of obvious, you missed the "include" directive on that line
[15:02]  * imbrandon stops his rant untill he reads the bug
[15:02] <Rhonda> imbrandon: Many people didn't expect it for game servers indeed, yes.
[15:02] <Rhonda> I tried to argument in that direction but I guess you know pushy users.
[15:04] <Rhonda> Comment added about my findings.
[15:05] <imbrandon> Rhonda: yea a server is a server, reguardless if its a game server or not
[15:05] <Rhonda> How do I add a "also affects" for the wesnoth-1.8 (Ubuntu) package to bug #281784? I want to mark it for the wesnoth package as wontfix and for the wesnoth-1.8 package as fixed. :)
[15:05] <Rhonda> imbrandon: No need to convince me about that argument. :)
[15:06] <imbrandon> :)
[15:06] <imbrandon> i know, just touchy subject with me, since i lived though the nightmares of RH / SuSE installing postfix etc on desktop machines and then it was my job to support / secure them , ugh
[15:07] <imbrandon> not fun times
[15:07] <micahg> ScottK: I hope to finish Sm within the hour
[15:07] <micahg> *SM2
[15:08] <ScottK> micahg: OK.  You've possibly missed my window.  I've informed slangasek.
[15:10] <callum1> thanks joaopinto I can see the problem in the debian rules file as it uses includes that I do not have. This is my first attempt at packaging and the bug was simply to fix a typo in the description. I didn't want to change anything in the rules file unless this was necessary. Should I be altering this?
[15:11] <joaopinto> callum1, no you should not, but if you are building the package you need to install the build depends
[15:12] <slytherin> callum1: You should not alter rules file. Instead install the package that satisfies the includes.
[15:20] <Rhonda> \o/ - my cowbuilder chroots are there. :D
[15:27] <callum1> joaopinto / slytherin : thanks sorry for asking the obvious please bear with me. The includes are include /usr/share/cli-common/cli.make include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/rules/patchsys-quilt.mk include /usr/share/cdbs/1/class/makefile.mk. I am not sure how to get these dependancys fulfilled. :(
[15:30] <slytherin> callum1: try installing cli-common-dev package
[15:32]  * Laney perks up
[15:33] <Laney> we usually use dh for CLI packaging these days
[15:33] <callum1> slytherin: Thanks this worked :)
[15:35] <Laney> callum1: you know there is already a package for tomboy-blogposter, right?
[15:35] <Laney> or is that just what you're trying to build?
[15:36] <imbrandon> callum1: sudo apt-get build-dep tomboy-blogposter
[15:36] <callum1> Laney: yeah there is a bug in launchpad that there is a typo in the package description so just working my way through the packaging guide doc
[15:36] <Laney> oh, well it looks like you changed the version incorrectly
[15:36] <Laney> it should go to 0ubuntu2 not 1ubuntu1
[15:37] <Laney> and I see another problem in the rules file — CC=csc should be CC=mono-csc these days
[15:37] <callum1> Laney ok thanks for the heads up ill fix those
[15:39] <Laney> and then you should increase the minimum version on mono-devel to >= 2.4.3
[15:39] <Laney> and *then* you should come over to Debian and get the package in there :)
[15:44] <simar> could anyone tell me that can i have 64bit ubuntu????
[15:44] <lfaraone> simar: try asking in #ubuntu
[15:45] <simar> lfaraone:  i tried bt no one reples
[15:46] <Laney> this isn't the place to ask, sorry
[15:46] <lfaraone> simar: well, this is for Ubuntu packaging and development.
[15:46] <simar> ok  i cc
[15:46] <simar> than
[15:46] <micahg> ScottK: do I have time for a last local test build (40 min)?
[15:47] <ScottK> micahg: Go ahead.  If I can't get airport wifi, there are other release team members that can review.  It's better to get it right.
[15:47] <micahg> ScottK: ok, thanks
[15:48] <slytherin> simar: yes you can have.
[15:49] <slytherin> Does anyone know if packaging of XBMC was ever discussed on this channel?
[15:52] <lfaraone> slytherin: search google with "site:irclogs.ubuntu.com"
[15:53] <lfaraone> slytherin: answer, probably not: http://www.google.com/search?q=site:irclogs.ubuntu.com+"ubuntu-motu.txt"+xbmc
[15:55] <slytherin> lfaraone: They have a PPA. So I was wondering why haven't they considered packaging for official repositories.
[15:58] <_ruben> probably to keep release cycles seperate
[15:58] <lfaraone> slytherin: often upstream dislikes the headaches that come with "stable" maintinence.
[16:00] <slytherin> hmm
[16:01] <lfaraone> slytherin: feel free to maintain it, it's FOSS after all :)
[16:02] <slytherin> lfaraone: I haven't yet tried it. :-)
[17:27] <callum1> hi all first time packaging... just ran pbuilder which has thrown an error AuthenticationTypes.cs(44,41): error CS0433: The imported type `System.Web.HttpUtility' is defined multiple times I have only changed the desciption of the package so not sure why this has failed
[17:28] <carstenh> try building the unchanged package?
[17:29] <callum1> carstenh: yeah I just followed the packaging guide as this is my first attempt at making one
[17:30] <callum1> ah sorry no I changed the revision to 0ubuntu2 and im trying to build that .dsc
[17:30] <carstenh> this was more a suggestion than a question. you should try to build the unchanged package. if this fails you did not break the package with your changes ;)
[17:30] <callum1> :)
[17:31] <callum1> ok ill give that a try just now cheers
[17:31] <carstenh> :)
[17:31] <callum1> ls
[17:36] <callum1> carstenh: The original wont build either :(
[17:37] <callum1> ok this seems to be a known issue http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi guess I will leave this bug alone
[17:37] <callum1> :)
[17:38] <carstenh> good, so you did nothing wrong :)
[17:40] <callum1> Thanks for the advice that could have been a bit of a headache. I'll see if I can find something easy for a first attempt
[17:42] <andol> In regards to bug #562067, I assume it's to late to have the psimedia package rebuilt before relase?
[17:47] <geser> callum1: still looking for an easy to fix package?
[17:48] <callum1> geser yeah :)
[17:49] <geser> look at the FTBFS of osmo
[17:49] <geser> the "problem" is that it uses some deprecated GTK symbols and builds with -DGTK_DISABLE_DEPRECATED
[17:49] <geser> so the fix is to build without this define
[17:50] <callum1> great thanks ill have a look now
[18:03] <callum1> geser: I have managed to build this package without making any changes?
[18:03] <geser> hmm
[18:04] <carstenh> you should talk about the ubuntu releases you use ...
[18:04] <geser> callum1: did you try to build it in a lucid pbuilder?
[18:08] <callum1> geser: I am on karmic at the moment
[18:08] <callum1> take it this is a lucid issue?
[18:08] <geser> yes
[18:09] <callum1> got lucid and the dev tools on a latop at home I'll fix this tonight
[18:11] <geser> callum1: if you plan to help out on Ubuntu, you should have a pbuilder (or equivalent) for the development version as all uploads go there (you don't have to run the development version on your system for this)
[18:12] <callum1> geser: now you mention it that makes sense :)
[18:19] <Elbrus> When I built my package (winff) lintian said that my override for embedded-zlib was unused, so I removed it. Now it got rejected by the system because of that warning. What could be going on, difference between i386 and amd64?
[18:19] <Elbrus> sorry, was for #debian-mentors...
[18:22] <Laney> I thought you couldn't override that one
[18:42] <piju> hello
[19:10] <Elbrus> Laney: you can... see: http://ftp-master.debian.org/static/lintian.tags
[19:30] <imbrandon> anyone familiar with JS arround ? why does a=4;b=6;a+++b; return 10
[19:30] <imbrandon> e.g. the hows the +++ intrepreted
[19:31] <hyperair> in C it would be undefined afaik.
[19:31] <hyperair> i'm not sure about JS
[19:31] <hyperair> i just add the brackets.
[19:31] <hyperair> if it returns 10, then it's (a++) + b
[19:32] <hyperair> if it returns 11, then it's a + (++b)
[19:32] <hyperair> i say just go to whoever wrote the code and start throwing tomatoes at him/her until he/she understands not to give people headaches with ambiguous code.
[19:32] <micahg> hyperair: +1
[19:33] <imbrandon> lol exactly
[19:33] <imbrandon> and yea its returning 10
[19:33] <hyperair> of course, sebner would prefer rotten tomatoes ;-)
[19:33]  * sebner hurries into the cellar
[19:33] <hyperair> hehehehe
[19:34] <imbrandon> i guess i dont fully understand the a++ then , i understand the ++b increments it
[19:34]  * hyperair activates the portal in the cellar and tosses tomatoes at sebner through the portal
[19:34] <hyperair> imbrandon: a++ = return a and then increment.
[19:34] <imbrandon> oh wait a++ incrments it too it just returns the old val
[19:34] <hyperair> ++a = increment, then return a.
[19:34] <imbrandon> ahhh
[19:34] <imbrandon> right /duh
[19:34] <sebner> hyperair: I'm not quite sure how here deserves them (except you of course)
[19:34] <hyperair> yes, one is pre-decrement, one is post-decrement.
[19:35] <hyperair> sebner: who is here?
[19:35] <hyperair> i mean who is "here"?
[19:36] <sebner> hyperair: I mean who instead of how xD
[19:36] <hyperair> sebner: aah!
[19:36] <hyperair> that suddenly made a lot more sense!
[19:38] <hyperair> sebner: anyway i was talking about whoever wrote (a+++b). if you write anything like that i'll launch homing tomato missiles at you.
[19:38] <hyperair> =p
[19:38] <hyperair> well i'll just assume they have enough range to reach your physical location from here
[19:38] <sebner> hyperair: ah, (a++++b) WTH?????????????
[19:38] <hyperair> sebner: three pluses.
[19:39] <sebner> hyperair: 4 make more sense :P
[19:39] <sebner> hyperair: a++ ++b
[19:39] <hyperair> sebner: er no i don't think it does...
[19:39] <hyperair> sebner: you need something to join them.
[19:39] <sebner> hyperair: well then it's a+ + +b
[19:39] <sebner> hyperair: what's not valid?!
[19:39] <persia> a++++b should return an error: a+++++b is more useful
[19:39] <sebner> hyperair: you increment with ++
[19:39]  * sebner agrees with persia 
[19:40] <hyperair> persia: yeah, that's right. at least it's less ambiguous than a+++b
[19:40] <MTecknology> Is it possible to replacve udev on an ubuntu system?
[19:40] <sebner> MTecknology: I doubt it, it's a core technology
[19:40] <hyperair> sebner: a++ + b or a + ++b
[19:40] <hyperair> aptitude purge udev \o/
[19:41] <sebner> hyperair: ah, definately needs whitespaces
[19:41] <MTecknology> hyperair: :P..
[19:41] <hyperair> MTecknology: ;-)
[19:41] <MTecknology> hyperair: I actually want to remove initramfs-tools; I don't understand what it's purpose is..
[19:42] <hyperair> MTecknology: it's used for bootstrapping the ubuntu system.
[19:42] <MTecknology> hyperair: I don't have any initrd and from my understanding, that's where it fits into the boot process
[19:42] <hyperair> MTecknology: i suppose. you got rid of your initrds eh..
[19:43] <MTecknology> yup
[19:43]  * hyperair shrugs
[19:43] <hyperair> initrds are important for me at least
[19:43] <MTecknology> hyperair: but now I can't remove that package because a lot of other tools, (mostly udev) depend on it
[19:43] <hyperair> MTecknology: go poke the #ubuntu-kernel people. they'd probably know better =p
[19:44] <MTecknology> I understand the importance of initrd; I have some systems that wouldn't boot w/o it; just on this system I don't need it
[19:46]  * sebner is an end-user and happy that his system works, no idea what initrd is xD
[19:47]  * hyperair mumbles something about not knowing what GAC is and hides from sebner
[19:47]  * sebner fetches his rotten tomates!
[19:48] <persia> MTecknology: Not having initrd is supported for some configurations, but not recommended.  Not having udev isn't supported, but theoretically feasibly if you manage all your device nodes manually: that said, it may cause some other issues (e.g. with mountall) that would receive little sympathy.
[19:48] <persia> That said, this isn't the best place to ask questions: you might try #ubuntu-devel, but I suspect you'll get told to use an initrd and udev there as well.
[19:49] <MTecknology> persia: I figured udev can't be removed. It was more of a random question.
[19:50] <sebner> MTecknology: it seems you have to find your luck with gentoo/LFS :P
[19:50] <MTecknology> sebner: .... Gentoo really doesn't give you much freedom of choice..
[19:51] <MTecknology> sebner: wanna chat about that- join me in -offtopic :)
[19:52] <sebner> MTecknology: I'm sorry but I have to fetch some rotten tomatoes for hyperair, besides I'm only an end-user not interested in such technical stuff ^^
[19:52]  * hyperair deploys an anti-rotten-tomato shield
[19:53] <MTecknology> sebner: I used Gentoo for a while and will never go back 'via choice' - They just don't let you really choose how your system is - only gives you the initial feel that you have that much control. I'll stop it there ;)
[19:53] <sebner> heh
[19:54]  * sebner grabs the magic stick from persia and smashes the shield of hyperair!
[19:54]  * hyperair deploys another
[19:54] <persia> sebner: You know, of course, now that you have the magic stick, you have accepted several responsibilities, right?
[19:54] <persia> sebner: I'd recommend using it to push RCBugs today, since that was my plan.
[19:55]  * hyperair laughs at sebner
[19:55] <sebner> persia: I thought the magic stick is only to beat bad people :P
[19:55] <iulian> Haha.
[19:56] <persia> sebner: No.  The magic stick is used, with an appropriate fulcrum, to move the world.
[19:56] <persia> It can also be used to move other things.  I usually used it to move developers to chase autogenerated buglists.
[19:56]  * sebner used it only for evil things then xD
[19:57] <persia> Don't do that :p
[19:57] <sebner> persia: blame hyperair :P
[19:57] <hyperair> persia: that sounds really familiar. something like... slangasek's signature =p
[19:57] <hyperair> sebner: you've just admitted that beating me is evil. therefore, I must be a good person.
[19:58] <hyperair> sebner: that makes you the villain =D
[19:58] <ajmitch> what have I walked in on here?
[19:58] <sebner> hyperair: beating = evil but beating an evil person (you) is good :P
[19:58] <persia> ajmitch: early-morning rioters, it seems.
[19:58] <ajmitch> how worrying
[19:58]  * hyperair nominates sebner as the king of contradictions.
[19:59] <ajmitch> why aren't they fixing bugs?
[19:59] <sebner> persia: /evening here though
[19:59] <hyperair> it's early morning here. how did you guess?
[19:59] <hyperair> like 3AM
[19:59] <persia> sebner: Not in NZ
[19:59] <ajmitch> because we know what part of the world you're in?
[19:59] <sebner> ajmitch: persia knows :P
[20:00]  * hyperair isn't in NZ, though.
[20:01] <MTecknology> sebner: You want to review a package for me?
[20:01]  * ajmitch thinks it's far too early to be up & getting ready for work
[20:01] <sebner> MTecknology: what kind of package? I have time in ~1 hour
[20:01] <MTecknology> sebner: I have a question about packaging with multiple licenses too
[20:02] <sebner> MTecknology: general packaging questions are best asked /here
[20:02] <hyperair> ajmitch: you're right, it's still before bedtime =p
[20:02] <sebner> hyperair: sleep is for the weak! cit. ScottK
[20:02] <MTecknology> sebner: I was looking into packaging TrueCrypt more and also wanted your opinion on just rebranding the whole thing for multiverse
[20:02] <MTecknology> sebner: I'm just saying.. ya know... you have the magic stick now :P
[20:03]  * sebner takes a deep breath, runs slowly, faster faster FAAAAAASSTER! and throws is back at persia 
[20:03]  * sebner runs in a corner and hides
[20:03]  * iulian wanted to package truecrypt ages ago but gave up.
[20:04] <ajmitch> sebner: chicken
[20:04] <hyperair> hehehehehe
[20:04] <hyperair> iulian: you and everyone other MOTU who uses truecrypt
[20:04] <sebner> ajmitch: a fast chicken lives longer :P
[20:04] <ajmitch> truecrypt is one of those nice-to-have but hard to get right packages, I think
[20:04] <iulian> MTecknology: IIRC, there is a thread about it on debian-legal.
[20:04] <hyperair> we need one of those quotegrab bots here
[20:04] <hyperair> that was epic.
[20:05] <hyperair> "a fast chicken lives longer"
[20:05]  * ajmitch stabs requestsync & launchpad
[20:05] <hyperair> ajmitch: syncpackage
[20:05] <ajmitch> E: The versions in Debian and Ubuntu are the same already (0.9~beta2-3). Aborting.
[20:05] <ajmitch> lies!
[20:05] <Laney> you can override that can't you?
[20:05] <ajmitch> Laney: still frustrating
[20:05] <hyperair> i think you can't. because requestsync is always smarter than you are ;-)
[20:05] <Laney> -C
[20:06] <Laney> it's because LP's Debian import is slow :(
[20:06] <MTecknology> iulian: ya, I think the end result was something like it's just not possible to package it - either that or just not worth it
[20:06] <hyperair> the best part is that if you'er in a region of the world where accessing launchpad sucks badly, you have to wait something like 15minutes for requestsync to come back and tell you "oh hey i can't do it after all"
[20:06] <ajmitch> Laney: glacial, you mean
[20:06] <iulian> MTecknology: I honestly cannot remember the reason.
[20:06]  * iulian goes back to study now.
[20:06]  * hyperair remembers saying that he was giong back to study, and really does this time
[20:07] <ajmitch> hyperair: I found that it wanted to look up packages.debian.org via ipv6 first, and timed out on each ipv6 address...
[20:07] <MTecknology> iulian: their 'open/free' license isn't really free
[20:07] <ajmitch> the problem is in python, not requestsync though
[20:07] <hyperair> T_T i build up my resolve to get back to studying and someone pings me.
[20:07] <hyperair> ajmitch: yeah that suck.s
[20:07] <ajmitch> hyperair: you're not allowed to study
[20:07] <hyperair> sucks*
[20:07] <iulian> hyperair: Shh.  I'm really going if you stop highlighting me. :)
[20:07] <iulian> MTecknology: Indeed.
[20:07] <hyperair> iulian: i didn't!
[20:07] <iulian> That's true.
[20:08] <hyperair> and stop highlighting me, iulian ;-)
[20:08] <ajmitch> iulian: stop bugging hyperair! :)
[20:08] <hyperair> ajmitch: you too =p
[20:08]  * hyperair kills notify-osd and replaces it with a no-op shell script
[20:08] <MTecknology> If I have initramfs-tools installed, does it really do anything to the boot process or is it mostly there for use by initrd?
[20:08] <ajmitch> that's no fun
[20:08] <MTecknology> meh - ignore the question
[20:29] <lfaraone> imbrandon sponsored bug 301190 to {intrepid, karmic, jaunty}-proposed two days ago but I can't see the upload reflected on LP. Are they stuck in a queue somewhere?
[20:33] <imbrandon> lfaraone: likely untill after the release goes out, i got the waiting for approval emails
[20:33] <iulian> https://launchpad.net/ubuntu/intrepid/+queue?queue_state=1&queue_text=
[20:34] <imbrandon> Script panel is disabled
[20:34] <imbrandon> mt
[20:34] <imbrandon> ahh yea its in the queue
[20:34] <imbrandon> lfaraone: ^^
[20:48] <arand> The directory of the orig.tar.gz is required to follow a naming scheme right? (name+version less the debian/ubuntu bit).
[20:53] <persia> arand: Not at all.  It can be anything.
[20:54] <arand> persia: Ok... well I think I'll go with the norm either way..
[20:56] <arand> Since I don't think I've seen any packages that don't...
[20:56] <persia> arand: Best practice is to have it be however upstream did it.  If you're upstream, package-version is nice.
[20:56] <persia> dpkg will *always* unpack to package-version, regardless of the way the orig.tar.gz is constructed internally.
[20:58] <arand> persia: Ah, that is nice.
[21:18] <imbrandon> arand: yea if your not upstream dont repack the tar for that
[21:18] <imbrandon> please
[21:20] <arand> imbrandon: Ok, this is just some playing about for a PPA, but I'll keep it in mind.
[21:33] <imbrandon> arand: :) yup , no worries, just thought i would mention that repacking an upstream tar is a last resort and if you do you need to provide a way to recreate the exact same tar via get-orig-source in debian rules etc, generaly its a bad idea unless you need to do it for dfsg or something
[21:39] <LeLutin_> hello, I'm currently trying to make a .deb package for some project I'm coding. I was wondering how the "debian/watch" file worked, and if anyone know if I can use a URL from Github for tracking the automatically generated tarballs
[21:39] <Laney> look into something called githubredir
[21:42] <LeLutin_> Laney: great, thanks
[22:51] <imbrandon> ScottK: can you do archive removals ?
[23:14] <piju> how long it takes my pkg to appear on PPA after uploaded ?
[23:16] <persia> piju: We don't much do PPAs here (we focus on Ubuntu itself).  You might ask in #launchpad.
[23:17] <persia> imbrandon: Needs shell access: best to just get it on the subscribed list.
[23:51] <ubuntujenkins> I am part of the ubuntu-manual team and the packages in lucid don't have evrything we want (i personally don't know what). The team would like to set up a personal ppa with the stuff we need as we are getting people dispite our note on not installing the packages. basically I would like to build the packages with everything that is in the current texlive source. The readmes in the debian svn branch are usefull but I
[23:51] <ubuntujenkins>  can't work out what specifies what parts of the texlive source are pulled in.
[23:55] <persia> ubuntujenkins: I'm not sure I understand your question.  Firstly, I suggest you want to know what you want to change before you start changing it.  Secondly, we don't really support PPAs here.  Those aside, what are you trying to do, or what is your specific issue?
[23:56] <ubuntujenkins> persia: I would like to package all of the current source. the way the debian packages are set up is that they only package some of the source, but i can't work out where this is specified and was wondering if any one knows anything about it?