[00:03] <LaserJock> it's been sitting here for like 20 minutes
[00:03] <LaserJock> I'm just gonna start over
[00:04] <selckin> alt-f something should give you a console, try killing something
[00:08] <LaserJock> ah hah
[00:08] <LaserJock> I had to kill debian-installer and start a new one up
[00:11] <LaserJock> now we're cookin'
[00:11] <DarkMageZ> jdong, any chance of backporting libgpod 0.6 to gutsy and building amarok against that? missing support for new ipods ッ
[00:14] <isaac> DarkMageZ: isn't that done already?
[00:14] <isaac> in the ipod-touch ppa?
[00:14] <DarkMageZ> oh. yay for ppa ッ
[00:15] <isaac> https://launchpad.net/~ipod-touch/+archive
[00:15] <isaac> there
[00:16] <DarkMageZ> tho realistically i think it should atleast be in backports so it's findable
[00:26] <pochu> persia: I will.
[00:29] <jdong> DarkMageZ: I believe I responded to one of those tickets reasoning that it cannot be done in a safe and not intrusive manner for -backports
[00:29] <jdong> for now I'd have to recommend the ipod-touch PPA too
[02:20]  * Hobbsee waves
[02:22] <persia> Hey Hobbsee
[02:23] <RAOF> Hey Hobbsee, persia.
[02:23] <RAOF> What was this abount: " persia)) RAOF: How familiar do you need?"
[02:24]  * persia misses ubuntulog
[02:24] <RAOF> persia: I looked in backscroll, but that didn't seem to help much :)
[02:24] <persia> My vague memory was that you had asked "Is someone familiar with foo", and someone more familiar also volunteered, and said something, but it may be a case if missed nick completion.
[02:25]  * LaserJock goes to read the FF exception wiki pages
[02:25] <RAOF> Actually, yes.  Now that I look at it.
[02:25] <RAOF> Again.
[02:25] <Hobbsee> oh yay, feature freeze should be done
[02:25] <LaserJock> I hate it when I don't make the deadlines :(
[02:26] <persia> Hobbsee: It's been frozen for a while.  About 3 hours late here, and maybe 5 on #ubuntu-devel, and possibly even more on ubuntu-devel-announce, but fairly solidly at this point.
[02:26] <LaserJock> one of the things I dislike about Ubuntu development, it's so fast there's always a deadline looming :-)
[02:26]  * minghua simply hates deadlines, whether he makes it or not.
[02:27] <persia> LaserJock: There's two ways to think about it: either the deadlines for getting things done, or the freeze times as windows to relax because you don't need to finish the feature for another 10 weeks or so.
[02:27] <LaserJock> persia: what are you feelings on getting a MOTU ack for NEW packages if it's just switching packaging?
[02:28] <Hobbsee> persia: i'm on VAC.
[02:28] <LaserJock> I'm afraid no one is gonna wanna look at these packages
[02:28]  * Hobbsee has been on VAC since the 13th
[02:28] <persia> LaserJock: How do you mean?  I'm happy to give a generalised answer, but need either more context, or a specific example from which to generalise.
[02:29] <LaserJock> ok, so I'm redoing the squeak packages from Multiverse
[02:29] <LaserJock> they all have different names so they need to go through NEW
[02:29] <LaserJock> but it's just different packaging, not different sources
[02:29] <LaserJock> do I need a MOTU review?
[02:29] <persia> LaserJock: Can you do it in such a way that it is binary NEW but not source NEW?
[02:30] <LaserJock> kinda
[02:30] <LaserJock> but that would defeat the purpose
[02:30] <LaserJock> I'm trying to sync up with "official" packages
[02:30] <LaserJock> but it's 5 new source packages :/
[02:30] <persia> Ah.  We have odd orig.tar.gz files, and you're fixing that, but to do so you need new source packages?
[02:31] <LaserJock> well, the problem originates because Debian doesn't have it
[02:31] <Hobbsee> i would have thought that source name changes shouldn't have to go thru again
[02:31] <Hobbsee> that being siad, running a diff thru the entire source wouldn't be hard
[02:31] <LaserJock> we originally got the packages from some Spansih distro back in like hoary/breezy
[02:32] <Hobbsee> or is it more than a name change?
[02:32] <Hobbsee> oh, the crack...the crack...
[02:32] <persia> I'm not convinced just changing a source package name needs MOTU ACK (although I think it needs FFe at this point), but getting another person to take a look might be a good idea, just in case there is some oddity in the upgrade or install path.
[02:32] <LaserJock> but there's actual a couple guys that maintain the official "unofficial" packages now
[02:32] <LaserJock> and our old packages were not the best
[02:32] <LaserJock> but they use a different naming scheme
[02:33] <LaserJock> well, the upgrade is totally screwed
[02:33] <LaserJock> I gotta figure out something
[02:33] <LaserJock> but I wanted to get something in the archive first
[02:34] <persia> LaserJock: I think that's the point of FeatureFreeze: at this point you have to figure it out before putting it in the archive.  Maybe playing with a PPA could help?
[02:34] <LaserJock> hmmpf
[02:34] <LaserJock> well, I guess since I missed the deadline I might as well spend a couple more weeks working on upgradability
[02:35] <LaserJock> I'm just so sick of these packages
[02:35] <persia> I suspect motu-release will be failrly lenient through Alpha 6 soft-freeze or so, but I'm just guessing.  I'm also assuming that the package shuffle will fix a number of real bugs.
[02:35] <LaserJock> yes
[02:36] <LaserJock> I'll kill of around 10 bugs
[02:36] <LaserJock> *off
[02:36] <LaserJock> and OLPC people want the packages
[02:36] <LaserJock> although I'm a little annoyed that OLPC is using this stuff since it's non-free
[02:36] <persia> There you have it then.  Just keep fighting it, and when you're done, ask for an FFe.  I did a bunch of exceptions for gutsy, and as long as they remained somewhat sane, never had an issue with approval.
[02:37] <LaserJock> there's nothing sane about squeak, but yeah
[02:37] <LaserJock> ;-)
[02:37] <Hobbsee> yay, insanity!
[02:37] <ScottK> Hobbsee: Since you're on VAC, I gather motu-release should get itself organized without waiting for you?
[02:37] <LaserJock> it took me several weeks to figure out the licensing
[02:37] <persia> Ah.  s/remained somewhat sane/fixed verifiable bugs/ then.  Thinking about it, the aolserver4 mess wasn't actually sane either.
[02:38] <LaserJock> In a single directory there was a LICENSE, COPYING, and COPYRIGHT file
[02:38] <Hobbsee> ScottK: i'm back on wednesday
[02:38] <LaserJock> and all 3 were different licenses
[02:38] <Hobbsee> ScottK: that being said, i'm mostly around now
[02:39]  * persia prefers upstreams who use better naming conventions when they have mixed-source licensing.
[02:39] <ScottK2> Hobbsee: Did you read my proposal to the MOTU ML on bugfix only upstream releases?
[02:39] <Hobbsee> ScottK2: i'm still sorting thru my *inbox*, let alone other mail.
[02:39] <LaserJock> squeak is an opposite case of java
[02:40] <LaserJock> the VM is GPL, but the language is non-free
[02:40] <LaserJock> or something like that
[02:40]  * Hobbsee is getting there...
[02:40] <persia> Huh?  How can a language be non-free?
[02:40] <ScottK2> Hobbsee: OK.  I think that's the only potential point of discussion.  I'd appreciate your feedback.
[02:40] <LaserJock> persia: well, not the language itself
[02:40] <LaserJock> I'm gonna confuse myself
[02:41] <LaserJock> but there's these images that you run on the VM
[02:41] <LaserJock> and those are non-free
[02:41] <persia> LaserJock: Sounds like far too many Games packages.
[02:42] <LaserJock> yeah, probably
[02:42] <LaserJock> thing is, I don't have a clue about what this stuff is even for, and I don't really care
[02:42] <LaserJock> makes packaging not as fun
[02:43] <persia> Typical model for Games is to have separate (often repacked) sources for the free and non-free bits, to encourage people to generate free content.  Yes, annoying.
[02:43] <ScottK2> Then why are you packaging it?
[02:43] <LaserJock> user demand
[02:43] <persia> ScottK: Also, repackaging: we already have squeak
[02:43] <ScottK2> LaserJock: Users you particularly care about?
[02:43] <LaserJock> and I once wrote a zenity script to start the bloody thing from the menu and I became the "maintainer"
[02:43] <LaserJock> ScottK2: I guess
[02:44] <ScottK2> Ah.  Touched it once and stuck with it forever.
[02:44] <LaserJock> a lot of edu people like it
[02:44] <LaserJock> yeah
[02:44] <persia> Is it that much better than gnu-smalltalk?
[02:44] <LaserJock> in fact that's something that I have to deal with for the upgrade path
[02:45] <LaserJock> I wrote the script to do sane things
[02:45] <LaserJock> sent it upstream
[02:45] <LaserJock> but now they have a different script
[02:45] <LaserJock> which works
[02:45] <LaserJock> but works totally differently
[02:45] <LaserJock> persia: I haven't a clue
[02:46] <ScottK2> TheMuso: Are you still around?
[02:46] <persia> LaserJock: If it's a mess and in multiverse, you might want to have a look.  If the free alternative is good enough, users are better served by redirection than maintenance.
[02:47] <TheMuso> ScottK2: Yep.
[02:47] <TheMuso> Do we wanna go somewhere to have a chat?
[02:47] <ScottK2> TheMuso: I wanted to know what you thought about my proposal for bugfix only upstream releases?
[02:47] <ScottK2> Do we need to?
[02:47] <TheMuso> ScottK2: Probably no actually. Yeah I like your proposal.
[02:47]  * persia doesn't see enough activity here to block a motu-release meeting
[02:48] <TheMuso> fair enough
[02:49] <LaserJock> heh, Randal Schwartz has a bit on GNU smalltalk vs. squeak
[02:50] <LaserJock> he recommends not using GNU smalltalk because you can't contribute code to squeak
[02:50] <ScottK2> persia: Additionally, I prefer discussion in public rather than private when feasible.
[02:50] <TheMuso> nah its fine.
[02:51] <TheMuso> ScottK2, Hobbsee, how are both of you for a general exception for ubuntustudio-* packages?
[02:51] <persia> LaserJock: In that case, best of luck with your effort :)
[02:51] <Hobbsee> TheMuso: fine with it.  they don't break anything else.
[02:52] <Hobbsee> persia: motu-release meeting will have to wait till i get back :)
[02:52]  * ScottK2 too, but It needs to be written and acked
[02:52] <Hobbsee> ScottK2: so, write it.
[02:52] <ScottK2> I think we need a wiki page listing the bugs for the general wave throughs.
[02:52] <ScottK2> Hobbsee: If I cared about ubuntu-studio I would.
[02:53] <persia> TheMuso: How about "flavour coordination packages maintained by the specific flavour team" rather than ubuntustudio-*
[02:53] <Hobbsee> ScottK2: my only feedback is that it sounds like a good idea, but that people should be thinking about whether something is suitable before they sign it, and before they upload it automatically, rather than having to file a bug, encouraging them to actually use a brain.
[02:53] <TheMuso> persia: Yeah that sound sreasonable.
[02:53] <Hobbsee> ScottK2: but you do care about having a list
[02:53] <ScottK2> Hobbsee: Yes.  I'll make the list.
[02:53] <Hobbsee> good.
[02:54]  * ScottK2 wants to put clamav on that list too.
[02:54] <Hobbsee> fine.
[02:54] <Hobbsee> just make sure you get the rdeps
[02:54] <ScottK2> Yeah.  Hobbsee did you see I got clamav updated in Dapper (with all the rdpends)?
[02:55] <ScottK2> I'm pretty thoroughly familiar with the rdepends now.
[02:55] <persia> Given the complexity of clamav, and the number of rdeps, wouldn't it be better to get a second pair of eyes when updating?
[02:55] <Hobbsee> nice work!
[02:55] <Hobbsee> persia: we have to have it.  but, those interested in clamav might check it, sure
[02:56] <ScottK2> persia: It will need some consideration, but we've got a small team of people working clamav and rdepends now.
[02:56] <persia> Hobbsee: I'm just arguing against putting clamav on the wave-through list, as it likely gets one guaranteed motu-release ACK anyway.
[02:56] <ScottK2> persia: Also I've got a good working relationship with the Debian maintainer too.
[02:56] <persia> ScottK: That's what I thought: I just like to avoid things where a single person can push something through late in the cycle.
[02:56] <Hobbsee> persia: if it's a guarenteed ack, and we have to have it, then what's the point in creating more red tape to put it thru?
[02:57] <ScottK2> So given what I'd already do for a clamav update, I don't think a motu-release ack will add much.
[02:57] <persia> Hobbsee: one guaranteed ACK.  One optional ACK.
[02:57] <Hobbsee> persia: and the chances of anyone deciding to say "no, we don't want a security fix in our repos" is?
[02:58] <ScottK2> persia: We updated Feisty less than a week before release and it was the right thing to do.  Unless the break the ABI at the last second, we're going to want it..
[02:58] <persia> Hobbsee: Not rejecting completely, just saying something like "Umm..  I know you haven't slept in 72 hours, but I think you want a tighter versioned Conflicts: there".
[02:59] <Hobbsee> persia: so you're suggesting starting to use 360 deg reviewing for all motu's - or at least for complex packages?
[02:59] <persia> ScottK: I agree with the "we're going to want it", but like apps.  sistpoty and I have been playing ping-pong with a package finally getting it in shape over the past 12 hours just because we've had timezone skew.
[02:59] <ScottK2> persia: If it was really close to the relase, I'd definitely get second looks.
[03:00] <persia> Hobbsee: No, just suggesting that for a complex set of packages primarily watched by a member of motu-release, adding to the "free pass" list might be dangerous in case of over-commitment on the part of that person.
[03:03] <ScottK2> If it's on the free pass list it doesn't matter if I'm on motu-release or not.
[03:04] <persia> Ah.  True.  Maybe I'm arguing against putting complex packages with lots of rdepends on the free-pass list then.
[03:04] <persia> (although you're all welcome to override me: there are reasons I didn't apply for the team)
[03:05] <Hobbsee> persia: perhaps so
[03:06] <ScottK2> Perhaps I'll put a "as long as there's no soname bump in libclamav" caveat in the request.
[03:22] <LaserJock> run!
[03:23] <bddebian> Heh
[03:23] <bddebian> Heya gang
[03:23] <crimsun_> 'lo
[03:24] <bddebian> Hi crimsun_
[03:28] <ScottK2> Heya
[03:28] <CyberMatt> unmeat deps are a pain in the butt
[03:29] <ScottK2> The unmet ones aren't so fun either.
[03:29] <CyberMatt> lol
[03:29] <bddebian> Hi ScottK
[03:29] <ScottK2> Heya bddebian.
[03:30] <ScottK2> bddebian: You see my ping about testresources?
[03:30] <bddebian> ScottK2: No sorry, what's up?
[03:30] <ScottK2> bddebian: Your fix from Debian ftbfs in Ubuntu.
[03:31] <bddebian> Oh, it wasn't the buildd issue?
[03:31] <ScottK2> Nope.  I asked for a give back and it died again.
[03:31] <bddebian> Frick
[03:31] <ScottK2> Over to you maestro.
[03:34] <persia> Does anyone have grep-dctrl magic in their grimoire to recursively find all rdeps and rbuild-deps for all binary packages built by a given source package?
[03:34] <bddebian> shiester
[03:34] <bddebian> grep-dctrl -F Build-Depends "$1" -s Package /var/lib/apt/lists/*_Sources
[03:35] <bddebian> Oh, never mind
[03:35] <ScottK2> grep-dctrl -FBuild-Depends,Build-Depends-Indep,Depends -s Package $BINARYPACKAGENAME -n /var/lib/apt/lists/*_Sources
[03:36] <ScottK2> Doesn't have the recursion though
[03:37] <persia> ScottK2: Also looks for $BINARYPACKAGENAME, rather than pulling all the binary packages from the source package.  I suspect I'll need a bit of a pipelne, but will chase it.
[03:38] <ScottK2> Yes.  It's not the answer to your question, but a step in the right direction.
[03:38] <ScottK2> persia: I suspect if you get a reasonable answer to your question it'd be worth adding to devscripts.
[03:39] <persia> ScottK2: Why?  It's a one-line shell script.  $BINARYPACKAGENAME can be replaced with an $() expression generating the list from the apt-cache.  The recursion is a bit more frustrating though.
[03:40] <ScottK2> persia: For those of us who can't do the one line shell script.  The answer to your question is sufficiently non-trivial you asked rather than just doing it.  I think it qualifies.
[03:40]  * ScottK2 has been wanting just such a think recently.
[03:41] <persia> ScottK: I guess, but to me it's sufficiently trivial that it's not worth fighting with bzr.  I'll at least file it in a bug for consideration.
[03:42]  * ScottK2 has also been wanting a --build-twice-in-a-row uption for pbuilder.
[03:42] <ScottK2> persia: Agreed (about bzr).  If you put it in a bug, I suspect it'll get there.
[03:43] <persia> Personally, I have a short list of nifty shell commands (like grep-dctrl -FBuild-Depends $(BINARY) -sPackage /var/lib/apt/lists/*hardy_universe_source_Sources, and was hoping others didi and would paste.
[03:43] <LaserJock> does reverse-build-depends in ubuntu-dev-tools work?
[03:43] <ScottK2> Maybe that's the answer
[03:44] <persia> LaserJock: no /usr/bin/reverse-build-depends (although there is a manpage)
[03:47] <ScottK2> Good night all.
[03:53] <CyberMatt> question why doesn't firefox have Provides: iceweasel seems like a good idea we could squash a few unmet deps
[03:54] <CyberMatt> or is there somthing I'm missing
[03:55] <persia> CyberMatt: Ubuntu FireFox and Debian iceweasel aren't always in sync.  It's often better to look at things, and many should likely be using xulrunner by preference.
[03:55] <Megaqwerty> Does anyone know what part of an apt repository apt-listchanges and update-manager pull changelogs from?
[03:55] <persia> (of course, asking in #ubuntu-mozillateam would get an official answer)
[03:56] <persia> Megaqwerty: I believe http://changelogs.ubuntu.com/
[03:56] <persia> Megaqwerty: But I'm wrong: that seems the old way it was done.
[03:56] <CyberMatt> ok i just wondering
[03:57] <Megaqwerty> persia: alright. I'll keep looking. I'm basically trying to figure out if it's possible to implement the same thing in another apt repository, for obvious reasons.
[03:59] <CyberMatt> there like three or four unmet deps on my list http://thegnuguru.org/stuff/hardy-unmet-deps.txt  (ubuntuwire is being slow) that result from iw instead of ff
[04:00] <minghua> persia, CyberMatt: I'm rather sure apt-listchanges doesn't need netword access.
[04:01] <minghua> Megaqwerty: ^^
[04:02] <minghua> CyberMatt: Sorry for using the wrong nick.
[04:02] <persia> minghua: Yes, but that's for already downloaded binary packages.  `aptitude changelog foo` downloads an updated changelog without downloading the package.
[04:02] <CyberMatt> np
[04:02] <persia> Megaqwerty: Check the aptitude source for the answer, or possibly even the aptitude changelog
[04:02] <Megaqwerty> persia: I was just going to say that ;)
[04:02] <Megaqwerty> persia: thanks
[04:03] <minghua> persia: Yes, I'm just saying they use different sources.
[04:03] <Megaqwerty> minghua: that's good, because I couldn't figure it out from the apt-listchanges.py file ;)
[04:05] <persia> minghua: Ah.  Right :)
[04:06] <CyberMatt> so to unbreak iceweasl and icedove deps all that needs to be done is to depend on xulrunner instead
[04:07] <persia> CyberMatt: Depending on the reason for the dep, one of xulrunner, xulrunner1.9, or some set of browsers is correct.
[04:08] <persia> In some cases, the package further needs a rebuild to link against the correct libraries (xulrunner1.9 is preferred in these cases, I believe: seek confirmation on #ubuntu-mozillateam)
[04:11] <CyberMatt> persia, thanks
[04:13] <persia> bddebian: I'm pulling WX2.4 patches today, and ran into a FTBFS for survex.  Have you tried these before, or should I just dig into them myself?
[04:14] <bddebian> persia: An FTBFS with my patch?
[04:15] <bddebian> Oh, survex
[04:15] <bddebian> Did it ever get applied?
[04:15] <persia> Ah.  You've seen it before then? (trying yours now...)
[04:15] <persia> Not in Debian, but I'm not waiting any more, as I want to drop wx2.4 before the freeze gets too hard.
[04:17] <LaserJock> bddebian: do you actually have a Debian install?
[04:17] <bddebian> LaserJock: I do since I started doing games team stuff :-)
[04:18]  * persia notes that bddebian is responsible for at least 60% of the improvements to the games for hardy (judging by list volume)
[04:19] <LaserJock> bddebian: do you run unstable?
[04:19] <LaserJock> hmm, I wonder if they speak much english in Prague
[04:20] <bddebian> LaserJock: That's all I've ever run :-)
[04:20] <Hobbsee> LaserJock: i was wondering that. you're going?
[04:20] <Hobbsee> LaserJock: i can't imagine they have too many czech speakers around ubuntu
[04:20] <LaserJock> Hobbsee: well, I just don't know
[04:20] <LaserJock> it's kind of a bad time for me
[04:20] <persia> LaserJock: There's a large expat community, and a fair amount of local study, but as long as you remember to always answer "No" when offered a drink, you'll be fine.
[04:20] <LaserJock> but I didn't go to Boston
[04:21] <LaserJock> persia: you been there?
[04:21] <persia> (for those not familiar with Czech, "No" is the appropriate pronunciation of the bare affirmative)
[04:21] <persia> LaserJock: Yes.
[04:21] <Hobbsee> right then.
[04:21]  * Hobbsee is enlightened.
[04:24]  * CyberMatt thinks he would never in the Czech Rupublic
[04:24] <CyberMatt> live*
[04:25] <persia> CyberMatt: Why?  Nice place.  Good robots.  Flexible night buses.  Best clock in the world.
[04:25] <Hobbsee> persia: is there anywhere you *havent* lived?
[04:25] <persia> Hobbsee: Yes.  Lots of places :p
[04:26] <LaserJock> I doubt it
[04:26] <CyberMatt> It'd be to confusing
[04:26] <Hobbsee> antarctica?
[04:26] <Hobbsee> iceland?
[04:26]  * persia has never been to at least two continents
[04:26] <Hobbsee> and mars.
[04:27] <LaserJock> I've been outside the US for 4 weeks altogether, 2 weeks in Mexico, 1 week in Paris, 1 week in Sevilla
[04:27] <Hobbsee> impressive
[04:27] <LaserJock> hmm, that's kinda cool/sad (depending on how you look at it), half of my "outside the US" experience has been for UDSs
[04:28] <persia> LaserJock: Which free software conference took you to Mexico?
[04:28] <LaserJock> none
[04:28] <LaserJock> that's my non-UDSs trip
[04:28] <LaserJock> when I was like 13
[04:29] <LaserJock> I would have liked to have made Debconf in Mexico perhaps
[04:29] <LaserJock> have they done a debconf in the US
[04:29] <LaserJock> ?
[04:30] <persia> bddebian: Do you have newpki_wx2.6_3.diff somewhere accessible to wget?
[04:31] <persia> bddebian: Never mind.  Quoting helped :)
[04:31] <bddebian> persia: You might have to run that through dos2unix
[04:31]  * Hobbsee goes back on vac
[04:32]  * Hobbsee hopes any other decisions will wait till she gets back
[04:33]  * persia installs tofrodos, and wonders how a patch in the BTS needs dos2unix to apply
[04:33] <bddebian> Because I sent it through my windows box ;-P
[04:33] <StevenK> persia: flip!
[04:33] <persia> StevenK: ?
[04:33] <Megaqwerty> persia: Well, I finally found it in the debian/patch/04_changelog.dpatch you were right, changelogs are pulled from http://changelogs.ubuntu.com
[04:34] <persia> StevenK: OOh.  Much better.  Thanks.
[04:35] <persia> Megaqwerty: Ah.  Good.  I was confused by the dates from http://changelogs.ubuntu.com/changelogs/
[04:36] <Megaqwerty> I've seen this now in c and python, so I've got to ask, does anyone know the significance of "%s" ?
[04:36] <persia> bddebian: Doesn't apply even with dos2unix or filp :(
[04:37] <persia> Megaqwerty: man printf
[04:37] <bddebian> Gah, WTF
[04:37] <Megaqwerty> persia: thanks!
[04:38] <Megaqwerty> persia: am I blind? I don't see it mentioned there.
[04:39] <LaserJock> man this squeak stuff doesn't make any sense
[04:39] <persia> Megaqwerty: Sorry.  `man -S 3 printf` under "conversion specifier"
[04:39]  * persia didn't know there was a coreutils printf, and is abashed
[04:39] <LaserJock> the -sources package contains a single file, which is all the code for a series
[04:40] <LaserJock> and then there are .changes which are a diff against -sources
[04:40] <Megaqwerty> persia: bah, "No manual entry for printf"
[04:40] <Megaqwerty> persia: Is there an online manpage for it?
[04:40] <bddebian> Are recommends getting installed now?
[04:41] <persia> Megaqwerty: Either install manpages-dev or do a web search for "man printf".
[04:41] <Megaqwerty> persia: danke
[04:41] <persia> bddebian: Ought be.  It was on the feature list for hardy, and we're past FF, although it may be late (I've not been tracking the spec)
[04:42] <persia> LaserJock: Just like orig.tar.gz and diff.gz, no?
[04:42] <LaserJock> persia: well kinda
[04:42] <LaserJock> which is a bit unusual for an upstream
[04:43] <LaserJock> all the source in a single file
[04:43] <LaserJock> easy to package though :-)
[04:44] <persia> Maybe licensing issues prevent direct modification of the file?  Also, all source in one file was once popular, although that is often considered the dark ages these days...
[04:47] <LaserJock> no, license is fairly open
[04:47] <LaserJock> the 1 file is 14MB
[04:47] <LaserJock> it maybe just historical
[04:47] <LaserJock> *may be
[05:03] <bddebian> Is there any way to use --force all with apt or is that dpkg only??
[05:08] <persia> bddebian: apt-get --force-yes might help, but it is somewhat dangerous...
[05:09] <persia> The (cleaner) alternative is to use `aptitude download foo` and then `dpkg --force-quux foo_baz.deb.
[05:10] <persia> (By "dangerous", I mean, "Could leave the system is an unbootable and unrunnable state")
[05:11] <bddebian> persia: Pfft, that's hardly dangerous ;-P
[05:12]  * persia misses the IBM 5150, when "dangerous" meant "could cause permanent physical damage to surrounding people and objects"
[05:12] <bddebian> heh
[05:14] <LaserJock> the use of DH_COMPAT in debian/rules is deprecated isn't it?
[05:14] <bddebian> yep
[05:14] <persia> LaserJock: Replaced by debian/compat
[05:18] <LaserJock> hmm, I wouldn't think I'd need configure-stamp and build-stamp rules if I'm not configuring or building anything
[05:19] <persia> LaserJock: Nope.
[05:19] <LaserJock> this is silly to have such a large debian/rules when *all* it is is cp'ing a single file
[05:19] <persia> (but packages should build from source, for some definition of build)
[05:19] <LaserJock> :-)
[05:19] <persia> LaserJock: Use CDBS, include debhelper, and put the file in debian/install.  Four lines total for rules, compat, and install.
[05:20] <minghua> The only required targets are clean, build, binary-arch, binary-indep, and binary.
[05:21] <LaserJock> persia: yeah, I might do that and send it upstream to see if they'll take it
[05:27] <Megaqwerty> Okay, MOTU question. How can I get involved? Also, this would be something I'd only be able to do in my free time between school and homework, so is it even a good idea for me to help out knowing I won't always have time to participate? (Currently I just package for getdeb.net in my spare time simply because it was pretty easy to figure out how everything there worked.)
[05:28] <persia> Megaqwerty: Best way is to help fix bugs and close release targets.
[05:28] <persia> When you have a fix, attach a debdiff for your new candiate version to a bug, and subscribe the sponsors to request upload.
[05:29] <persia> https://wiki.ubuntu.com/MOTU/Contributing has more (but could use a refresh)
[05:29] <persia> When you have questions, ask here.
[05:29] <persia> Current big targets are unmetdeps and NBS, although bugfixes are always welcome.
[05:30] <Megaqwerty> persia: I haven't finished learning programming yet, just packaging. Is there anything in that realm?
[05:30] <persia> Also, if you come from getdeb, you might be interested in new package preparation, although that won't really get going again until May, and various sorts of updates to previous releases (SRUs and backports)
[05:31] <Megaqwerty> cool. Where on launchpad should I look for package update/creation requests?
[05:32] <persia> Megaqwerty: Lots.  https://launchpad.net/ubuntu/+bugs?field.tag=packaging is an incomplete list of bugs that only need packaging changes, and https://launchpad.net/ubuntu/+bugs?field.tag=patch is an incomplete list of bugs for which someone else already prepared a patch, but the patch may need packaging or testing or something.
[05:34] <Megaqwerty> persia: Awesome! Thanks. One more question, how do I subscribe the sponsors when done?
[05:34] <persia> New packaging requests are listed from https://launchpad.net/ubuntu/+bugs?field.tag=needs-packaging, and backports from https://bugs.launchpad.net/gutsy-backports/+bugs.  I recommend working on packaging bugfixes first, to get even more experience with all the different ways packages work before creating too many new packages.
[05:34] <persia> Megaqwerty: The "subscribe someone else" link.  See the MOTU/Contributing link for some links to process docs, etc.
[05:39] <Megaqwerty> persia: So it would be ubuntu-main-sponsors or ubuntu-universe-sponsors respectively?
[05:40] <persia> Megaqwerty: Exactly.  UMS also handles restricted, and UUS also handles multiverse.
[05:41] <persia> Note that we're in feature freeze, which means that some classes of bugs can't be closed now, and must be deferred until the next release, but there's still heaps of stuff to do for hardy.
[05:42] <LaserJock> persia: dude, thanks for the cdbs recommendation
[05:42] <LaserJock> I had two of those packages
[05:43] <Megaqwerty> persia: Thanks a lot! Is there any obligation after you've submitted a new revision? Like...do I actively have to watch that package's main site for new versions, or actively watch for bugs that might affect the package I worked on? Or is this more of an, finish this task, and you're only really obligated to do something if you screwed up your specific task (i.e. forgot a build-dep or something.)
[05:43] <persia> LaserJock: Just don't get addicted.  While CDBS is nice for packages that fall into certain common classes, remember that you can always fall back to a less intrusive use case once you start needing heaps of special variables and overrides, etc.  I find the debian/rules for sendmail to be an excellent argument against CDBS.
[05:44] <persia> Megaqwerty: Generally it's a good idea to check bugs for a bit after you've submitted a new revision to make sure you didn't break anything.  Also, if you are the last uploader, you are responsible for merging the Debian changes for the next cycle.
[05:45] <LaserJock> persia: oh, you don't have to convince me of that ;-)
[05:45] <persia> If you concentrate on just a few packages that interest you, you may find watching them fun: it feels really good to close the last bug in a package, or get everything integrated with Debian.  If you concentrate on targets (e.g. unmetdeps, .desktop files, etc.) you may find that you only want to pay a little attention to each package after the update.
[05:47] <Megaqwerty> persia: what does merging the Debian changes entail?
[05:47] <persia> Megaqwerty: For example, let's say you work on a bug to fix a documetation issue in a manpage.
[05:48] <persia> After you submit the debdiff to Ubuntu, you also send the manpage patch to Debian so they can also use it.  Unfortunately, the Debian maintainer was on holiday, but someone from the security team uploaded a security update (without your fix).
[05:48] <mdomsch_> where can I find the version of lintian that's running on revu?
[05:48] <mdomsch_> it seems to have newer checks than what's in hardy atm
[05:49] <persia> At this point, you would work to make a new candidate that included both the fix from Debian, and your documentation patch.
[05:49] <persia> mdomsch: Looking now...
[05:50] <LaserJock> mdomsch_: hi ;-)
[05:50] <mdomsch_> ah, maybe not
[05:50] <crimsun_> it shouldn't be newer.  IIRC, it's backported.
[05:50] <mdomsch_> I was running only on the deb, not the .dsc
[05:51] <persia> mdomsch: REVU is currently running  1.23.32ubuntu1, and hardy has 1.23.42.  The host running REVU was upgraded recently, so the version generating the output you see might be something different than the 1.23.32ubuntu1 currently available.
[05:51] <persia> Ah.  Yes, that would do it.  REVU only runs on the .dsc.
[05:58] <Megaqwerty> persia: Oh well. It looks like it's going to be too much work for me (factoring in the school and homework.) I guess I'll just have to wait until I graduate to contribute. :(
[05:59] <persia> Megaqwerty: Maybe.  Personally, I started because I had a bug on my local system that annoyed me, and I could fix it.  Even if you just upload the fixes for your own bugs, it would be a great help.  Merging only happens once a cycle, and if you don't have time, people are typically happy to help.
[06:00] <persia> About 320 people have contributed to hardy so far, and most of them only had time for one or two updates.  Every bit helps.
[06:03] <mdomsch_> boo hiss @ linda.  lintian complains I haven't upgraded Standards-Version, linda complains it's too new
[06:03] <persia> mdomsch: linda reports that either you or she is wrong.  Is this case, it is her.
[06:04] <mdomsch_> indeed
[06:06] <AnAnt> Hello, what's u-u-s ?
[06:06] <persia> AnAnt: Ubuntu-universe-sponsors.  The queue is visible from https://launchpad.net/~ubuntu-universe-sponsors/+bugs
[06:09] <minghua> Linda is more often wrong than right these days.
[06:09] <persia> minghua: I haven't seen much bad advice from linda excepting the standards-version and the oddity about shlibs (although I grant there are a number of open bugs).  On the other hand, I find lintian to miss a number of things.
[06:10] <LaserJock> I find I just need to run both
[06:10] <minghua> persia: Yeah, I remember you giving some examples last time we talked about this.
[06:11] <minghua> persia: But she's just not that useful to me anymore.  So I only run lintian these days.
[06:13] <persia> LaserJock: That's my experience as well.
[06:13] <persia> minghua: Maybe.  For my last package, I was lintian-clean from the start, but had a few linda issues to clean up.  Not having run linda would be a less good package.
[06:15] <minghua> Sure, let's just just keep each one's own way of doing things, then.
[06:18] <persia> minghua: Sure, and please feel free to fix anything you notice outstanding from something I've touched :)
[06:21]  * minghua has too many bugs of his own to look at persia's packages, unfortunately. :-(
[06:22] <persia> heh.  I only "have" two packages, most of my stuff is on various random packages.
[06:23] <minghua> Actually, I haven't touched many Ubuntu packages recently, most of the stuff I've done in the past few months are Debian stuff.
[06:25] <persia> Makes sense.  Lenny freeze is coming soon.  I expect we'll see you back a bit for hardy+1 and a fair amount for hardy+2.
[06:30]  * minghua leaves for now, be back later.
[06:57] <AnAnt> persia: oh, how are you ?
[06:57] <persia> AnAnt: recovering.  You?
[06:57] <AnAnt> persia: 2 ubuntme artwork packages are in repos now
[06:57] <AnAnt> persia: thanks !
[06:57] <persia> Should be three.  What is missing?
[06:58] <AnAnt> persia: the third is still in queue
[06:58] <persia> Also, Do you guys have an ubuntume-meta package pending?  We're past feature-freeze, but I think you'd want to submit it quick and ask for a freeze exception, as otherwise it will be hard to install ubuntume-desktop.
[06:58] <AnAnt> persia: btw, is it late to request a sync from Debian ?
[06:59] <AnAnt> persia: no, I still didn't start working on a ubuntume-meta
[06:59] <AnAnt> persia: some ubuntume packages can't enter in Ubuntu repos yet anyways, due to unresolved copyright issues
[06:59] <persia> AnAnt: syncs may be requested up through the end of the cycle, but the freeze rules apply.  If the changes meet the freeze guidelines, or there is a freeze exception, a sync is safe.
[07:00] <AnAnt> persia: it's a request to add a package
[07:00] <persia> Ah.  copyright can be frustrating.  I understand.  If hardy won't have ubuntume-desktop due to external dependencies, I guess we're looking at hardy+! :(
[07:00] <persia> AnAnt: Is the package necessary for hardy in some way?
[07:00] <AnAnt> persia: yes indeed, hardy+something !
[07:01] <AnAnt> persia: I don't think so
[07:01] <AnAnt> persia: it's sorta like, good to have
[07:01] <persia> If you can, try for inclusion from May.  That gives the best chance of being able to have a clean install for the next release.
[07:01] <AnAnt> ok
[07:01] <persia> Ah.  "good to have" packages are unlikely to get freeze exceptions at this point, but you could request one if it was "really good to have".
[07:02] <AnAnt> I see
[07:02] <AnAnt> persia: another thing, I am making a package that makes use of update-alternatives
[07:02] <AnAnt> persia: oops, wrong question
[07:03] <persia> AnAnt: Make sure to work with the other providers for the alternatives to make sure you don't hit a conflict.  It can be frustrating if not everyone is using the same plan.
[07:05] <AnAnt> persia: I got a problem with a postinst script  (http://pastebin.com/m2f1953e2)
[07:07] <AnAnt> persia: it gives me an error when I install the package, hang on till I get it
[07:09] <warp10> Good morning
[07:10] <AnAnt> persia: here's the error:
[07:10] <AnAnt> debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by
[07:10] <AnAnt> another process: Resource temporarily unavailable
[07:11] <persia> AnAnt: That's not something I know about.  You might ask more generally, or send email to ubuntu-motu-mentors@ubuntu.com requesting help.
[07:12] <AnAnt> Hello, can anyone help me with this postinst script: http://pastebin.com/m2f1953e2
[07:12] <AnAnt> I am using debconf in it, and I got this error when I install the resulting deb file: debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable
[07:14] <LaserJock> persia: now 3 out of 5 packages using simple cdbs :-)
[07:15] <persia> LaserJock: You say that like it's a good thing :p
[07:15] <LaserJock> oh it is
[07:15] <LaserJock> all 3 just install 1 file
[07:16] <LaserJock> no need to make things complicated
[07:16] <LaserJock> I should really just use no build helper at all
[07:16] <persia> LaserJock: I agree.  The simpler the debian/rules the better, but you might be amused at a buildlog run with DH_VERBOSE :)
[07:16] <LaserJock> but that'd require some work
[07:17] <persia> No, using debhelper is better than no build helper, as that means your package doesn't have to be manually updated if there is a significant change.
[07:20] <persia> Which reminds me: we should probably try to drop debmake for hardy
[07:21] <LucidFox> What is debmake?
[07:21] <persia> LucidFox: Very old and obsolete mechanism to build binary packages
[07:23] <man-di> persia: Debian dropped debmake already in unstbale/testing so it should not be unpossible
[07:24] <persia> man-di: That was the motivation :)
[07:24] <man-di> my personal next target would be yada...
[07:25] <persia> man-di: Do you happen to have some time to migrate those candidates?  I'm sure it would be welcome :)
[07:25] <man-di> haha
[07:26] <man-di> I have talked with some maintainer who uses yada some time ago
[07:26] <man-di> he still insists its the best packaging helper ever
[07:26] <persia> man-di: On a more serious note, do you know anything about the Apache Derby library?  There seem to be two or three copies of the code in Ubuntu, and there were two new candidates submitted to REVU just near the freeze.  I'm wondering if development is fractured, or if there is one derby to rule them all that everything should target.
[07:27] <man-di> persia: like bist hing since sliced bread
[07:27] <man-di> persia: sorry, I dont know
[07:27] <persia> Yes.  I've seen some blog posts to that effect :)  Still, I consider it a valid target for Ubuntu variation, as we don't document yada practices in the Ubuntu packaging guide.
[07:27] <persia> Do you know who might?
[07:28] <man-di> persia: noone perhaps
[07:28] <persia> OK.  Since all the names on all the changelogs I've seen seem to be Sun people, maybe it's their problem.  Thanks.
[07:29] <man-di> persia: you know, left and right hand and so on...
[07:29] <persia> Unfortunately :(  If I can find the one true derby, I'll try to have someone send it to you so we're in sync.
[07:30] <man-di> perhaps its similar to the jdom situation
[07:30] <persia> JDOM?
[07:31] <man-di> we have 3 versions of it in the archive to make everyhthing work
[07:31] <warp10> persia: regarding bug #192248, thanks for the pointer about the versioning. About the libumlib0-dev issue, it looks like to be available in universe for hardy to me. I just did another rebuild and it built fine.
[07:31] <ubotu> Launchpad bug 192248 in fuse-umfuse-iso9660 "Rebuild for libiso9660-4 -> libiso9660-5 transition" [Low,Incomplete] https://launchpad.net/bugs/192248
[07:31] <man-di> persia: libjdom-java, libjdom0-java and libjdom1-java
[07:32] <man-di> persia: the funny thing is that they are ABI compatible but still incompatible
[07:32] <persia> That just provides a poor taste.  Upstreams need smacking (if only the Java team had enough left over time to chase them all)
[07:33] <persia> warp10: Might just be architecture skew.  Either check the state for other architectures, or push back to the queue and hope the next sponsor to review has your arch.
[07:34] <warp10> persia: hmmm... there isn't an amd64 .deb for it, indeed.
[07:35] <persia> warp10: Maybe there's something else needs fixing first?  Another library push, a FTBFS?
[07:38] <warp10> persia: I'll try to figure out how to fix that before re-attaching the debdiff. Thank you!
[07:38] <persia> warp10: No, thank you for chasing NBS.  It's always frustrating when there is a release and we discover we forgot to rebuild something.
[07:42] <warp10> persia: Indeed. That was the first NBS I worked on out of two, but I have to say It is someway satysfing to shorten the NBS list. :)
[07:53] <persia> Could someone take a look at bug #183446?  That doesn't seem an ideal way to solve the problem to me, but I'd like a second opinion before either accepting or rejecting the patch.
[07:53] <ubotu> Launchpad bug 183446 in mysql-query-browser "mysql-query-browser doesn't appear after connection is made" [Undecided,Confirmed] https://launchpad.net/bugs/183446
[07:55] <NCommander> Hola
[07:55] <persia> NCommander: Welcome
[07:55] <NCommander> I've got a package that I'm a maintainter for Debian
[07:55] <NCommander> (nrss)
[07:56] <NCommander> But the version in debian is incredibly dated
[07:56] <NCommander> But I can't get a sponsor to let me update it
[07:56] <NCommander> And it just got synced into Ubuntu, and I'd like a newer version uploaded
[07:56] <persia> Most of us can't upload to Debian either, but we may be able to sponsor an update to Ubuntu.
[07:56] <NCommander> Right
[07:56] <NCommander> That's what I'd like to do
[07:56] <persia> Unfortunately, we've just entered Feature Freeze, so any new upstream versions need a Feature Freeze exception.
[07:57] <NCommander> Damn it
[07:57] <NCommander> The version in Debian quite buggy
[07:57] <NCommander> I don't even think it works properly in Ubuntu due to the updated wget
[07:57] <persia> NCommander: I sympathize: I've seen a couple packages I watch get new upstreams yesterday that won't be in hardy :)
[07:57] <NCommander> How can I possibly get a freeze exception?
[07:58] <NCommander> Because the package author just blasted me for not updating in a considerable time (long story there)
[07:58] <persia> Anyway, if it really fixes bugs, and is a good improvement, it will likely get approved for an exception.  Feature Freeze is documented at https://wiki.ubuntu.com/FeatureFreeze, and there is a link on that page to the exception process.
[07:58] <persia> Once you have been granted the exception approval, subscribe ubuntu-universe-sponsors to get it uploaded.
[07:59] <NCommander> Can I upload it to REVU?
[07:59] <persia> NCommander: You may, but nobody is likely to pay any attention to REVU until May.
[07:59] <NCommander> Ouch
[08:00] <persia> Better to attach the new diff.gz to the bug (your watch file works, right?), and the submit the FFe documentation.  The reviewers and sponsors will reconstruct the package from that.
[08:01] <NCommander> watch file?
[08:01] <persia> NCommander: http://dehs.alioth.debian.org/maintainer.php?name=nrss&Display=Submit+Query may help, as will the uscan manpage.
[08:02] <NCommander> Thanks
[08:02] <NCommander> Oh
[08:02] <NCommander> He doesn't use FTP, or anything watch can make head or tails of :-/
[08:02] <persia> Does upstream have an internet accessible download location?  You might be able to grab it with wget in a get-orig-source rule
[08:03] <NCommander> a what?
[08:04] <persia> NCommander: A get-orig-source rule to download and repack the latest upstream source.  See http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
[08:06] <NCommander> Neat
[08:06] <NCommander> Very cool
[08:08] <persia> We tend to encourage working watch files and/or get-orig-source rules when adding new packages or upgrading before Debian because the person who upgrades it next is not always the person who upgraded it last, and it's a good way to document the process.
[08:14] <NCommander> You know where I can find an example?
[08:15] <persia> NCommander: There's a few in our packaging guide, but each is different, depending on the nature of upstream
[08:15] <persia> !packaging
[08:15] <ubotu> The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
[08:16] <NCommander> persia: Can't find it
[08:17] <persia> https://wiki.ubuntu.com/PackagingGuide/Complete#head-f8241e4bf5c67fe8c76350a1fb3ef9cf2f926c62
[08:17] <NCommander> persia: Your totally awesome
[08:17] <NCommander> I've learned more about debian packaging in the last ten minutes then a month of lurking in d-mentors
[08:21] <persia> NCommander: We've a few thousand bugs on various packages that need fixing, if you want practice.  Please don't let that interfere with your Debian maintaining activities though: over 80% of Ubuntu is unmodified from Debian, and so we very much appreciate work done there.
[08:21] <NCommander> I'd be glad to help a little
[08:22] <NCommander> But I felt kinda intimidated looking at how to do syncing and such
[08:22] <persia> That's the hard stuff.  Better to chase easy stuff like unmet dependencies, library rebuild version skew, documentation bugs, etc. to get a feel for workflow.
[08:23] <NCommander> ?
[08:24] <persia> Stuff like the bugs listed at https://launchpad.net/ubuntu/+bugs?field.tag=packaging, where there's something wrong with the packaging that needs fixing.  https://wiki.ubuntu.com/MOTU/Contributing provides some guidance on how to submit new candidate for sponsoring.
[08:25] <NCommander> Let me get nrss taken care of
[08:25] <NCommander> Then I'll see about helping
[08:25] <persia> Absolutely.  maintaining your own packages should always take priority.
[08:26] <NCommander> Yeah
[08:26] <NCommander> I also need to update cvsps
[08:26] <NCommander> But it doesn't have any "must have" patches to warrent a freeze wavier
[08:27] <persia> For cvsps you're better off just updating in unstable then.  Ubuntu will pull a sync in May.
[08:30] <NCommander> Yeah
[08:30] <NCommander> persia: I'm rebuilding the new nrss
[08:30] <NCommander> er
[08:30] <NCommander> Wrong chatroom
[08:31]  * persia suspects it was the right "chatroom" :)
[08:31] <NCommander> :-P
[08:31] <NCommander> I finally found someone to sponsor me on Debian for the new package
[08:31] <NCommander> I just bitched loudly
[08:32] <AnAnt> Hello, can anyone help me with this postinst script: http://pastebin.com/m2f1953e2
[08:32] <AnAnt> I am using debconf in it, and I got this error when I install the resulting deb file: debconf: DbDriver "config":
[08:32] <AnAnt> /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable
[08:32] <persia> NCommander: That makes it easier.  Just upload there, and request a FFe for the sync.  If you get stuck with process, ask here for help.
[08:32] <AnAnt> persia: well ubuntume-gdm-themes get into queue or directly into repos ?
[08:32] <NCommander> Thanks
[08:33] <persia> AnAnt: Last I saw it was in Accepted.  Takes a bit to build and distribute.
[08:33] <AnAnt> k
[08:33] <AnAnt> persia: I meant 1.2 btw
[08:33] <persia> AnAnt: Also, you likely want to send email to ubuntu-motu-mentors@ with your debconf issue.  Asking here every several hours won't likely get you a better answer faster.
[08:35] <AnAnt> persia: I wonder if debian-mentors will help me with a ubuntu-related package
[08:37] <AnAnt> persia: regarding sync request, if a package in Debian has an FTBFS fixed, would it be accepted ?
[08:39] <AnAnt> how do I request a package syn ?
[08:39] <persia> AnAnt: I think you'd do better with ubuntu-motu-mentors for Ubuntu packaging, but debian-mentors might help.  For a sync request, fixing an FTBFS is good.  Is there also an upstream update, or just packaging fixes?
[08:39] <persia> !sync
[08:39] <ubotu> Sorry, I don't know anything about sync - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[08:39] <persia> !syncrequestprocess
[08:40] <AnAnt> persia: just packaging fixes
[08:40] <persia> AnAnt: Likely be accepted then.
[08:40] <AnAnt> persia: unfortunately upstream is frozen for years for that package (acon)
[08:41] <AnAnt> !syncrequestprocess
[08:41] <persia> https://wiki.ubuntu.com/SyncRequestProcess is the page for the sync request process.  Subscribe a sponsor for approval.
[08:41] <AnAnt> persia: who would I subscribe ?
[08:42] <persia> For acon, ubuntu-universe-sponsors, because acon is in universe.  You can check whether a package is in main or universe with `rmadison -u ubuntu $(PACKAGE)`
[08:43] <AnAnt> ok
[08:54] <AnAnt> requestsync script doesn't work !
[10:07] <isaac> cool, I have gvfsd-http using 900Mb of RAM
[10:07] <isaac> to copy three 150Mb files
[10:11] <warp10> umview FTFBS on amd64. Build log is at http://launchpadlibrarian.net/12034829/buildlog_ubuntu-hardy-amd64.umview_0.4a-2%7Ewarp10_FAILEDTOBUILD.txt.gz Any Idea about how fixing this issue?
[10:21] <geser> warp10: I've tried to understand why it FTBFS but I didn't find out why gcc sees there a duplicate value
[10:22] <geser> warp10: it's also known in Debian but with no solution (see Debian bug 417047)
[10:22] <ubotu> Debian bug 417047 in umview "umview: FTBFS [amd64] error: duplicate case value" [Important,Open] http://bugs.debian.org/417047
[10:23] <warp10> geser: looks like I can't do anything to fix that, so. Anyway, I need that build to go ahead with bug #192248
[10:23] <ubotu> Launchpad bug 192248 in fuse-umfuse-iso9660 "Rebuild for libiso9660-4 -> libiso9660-5 transition" [Low,In progress] https://launchpad.net/bugs/192248
[10:23] <persia> Aren't __NR_chown and __NR_lchown dupes because  it's a 64-bit arch?
[10:24] <geser> persia: I couldn't find where both symbols are defined as the same value
[10:25]  * persia is reading include/libummod.h
[10:28]  * persia blames um-viewos/defs_x86_64.h line 223
[10:28] <geser> /usr/include/asm/unistd_64.h mentions them too
[10:28] <persia> It collides with line 218
[10:30] <persia> Line 212 indicates to me that it is also unsolved upstream :(
[10:38] <warp10> persia: if we can't fix that, is my debdiff for bug #192248 acceptable, or ftbfs on amd64 is a good reason to reject it?
[10:38] <ubotu> Launchpad bug 192248 in fuse-umfuse-iso9660 "Rebuild for libiso9660-4 -> libiso9660-5 transition" [Low,In progress] https://launchpad.net/bugs/192248
[10:39] <persia> warp10: I won't sponsor it because I use amd64, and the package you are updating is broken on amd64, needing more work.  Someone else might sponsor it (I won't reject it again, assuming you fix the version numbers, etc.).
[10:40] <persia> More generally, I think it's best practice to try to fix the issues recursively, but if you are completely stuck, it shouldn't block something else that is important.
[10:41] <warp10> persia: ack. As a more general situation, I was just wondering if a debdiff that ftfbs on an arch, for for a reason we can't workaround, is acceptable or should be rejected in any case.
[10:42] <persia> warp10: I think it's unacceptable for a sponsor to upload something they cannot build or test, but I don't think an issue specific to one architecture should block release critical bugs (like NBS).  It's better to fix the FTBFS, but if you can't, it's not worth releasing hardy with NBS.
[10:43] <persia> More generally, fixing an issue on several architectures is better than not fixing it because three architectures are still broken
[10:44] <warp10> persia: yeah, makes sense. I have fixed the version number and I'm uploading the debdiff again, maybe a sponsor using i386 or sparch will accept it.
[10:44] <geser> persia: looking at the defines in that header: how can the the *32 defines cause the error as there aren't any *32 defined on amd64?
[10:45] <persia> geser: __NR_chown32 and __NR_lchown32 are both defined as __NR_doesnotexist
[10:45] <persia> This makes them identical (if identically invalid)
[10:46] <persia> Alternately, I don't understand syscalls well enough :)
[10:47] <persia> Then, include/libummod.h defines __NR_chown as __NR_chown32 and __NR_lchown as __NR_lchown32
[10:49] <geser> persia: where does defs_x86_64.h get included?
[10:53] <albert23> wouldn't putting #if __NR_chown != __NR_lchown before case __NR_lchown: solve this?
[11:01] <persia> geser: Sorry.  DIstracted.  Looking now...
[11:01] <persia> albert23: Worth a try.  Does that work for you?
[11:01] <albert23> persia: yes, just tested. However, it fails later with a different error
[11:04] <persia> geser: Good call.  It only gets included for um-viewos, rather than um_viewfs, and so is not the source of the issue.  Deeper the in the stack than I understand, I'm afraid :(
[11:08] <geser> persia: looking at the pre-processed source both __NR_lchown and __NR_chown are replace with -1
[11:10] <persia> Ah.  Hmm..  I wonder from where that is defined: perhaps just a report of the nonexistence of __NR_chown32 and __NR_lchown32 on x86_64 ?
[11:14] <geser> persia: #define __NR_chown __NR_chown32 only happens when __NR_chown32 is defined
[11:15] <persia> Which means that when it's not defined, it stays undefined, which the preprocessor likely reports are -1, which generates the duplicate.
[11:18] <geser> persia: it's include/module.h which breaks it :(
[11:19] <persia> hah!  Maybe those should be -1, -2, -3 ... ?
[11:20] <persia> Alternately, one could do something like http://paste.ubuntu.com/4641/
[11:21] <albert23> persia: in my opinion the #if is ok to fix viewfs.c. The new error I get is in another file (scmap.c:225: error: '__NR_mmap2' undeclared here (not in a function))
[11:21] <albert23> persia: you will get the same error if you just change the value
[11:22] <geser> persia: changing the order of including module.h and libummod.h should do it too
[11:22] <RainCT> Morning
[11:22] <persia> albert23: The issue with ./um-viewos/scmap.c is likely due to um-viewos/defs_x86_64.h
[11:22] <geser> amd64 has __NR_lchown and __NR_chown defined
[11:23] <persia> geser: Is that all?  Excellent!  What about um-viewos ?
[11:23] <geser> persia: I didn't try compiling it yet, but my test with the preproccessor shows that both keep there values
[11:24] <persia> albert23: Could you pastebin your build error so we could see?
[11:24] <albert23> __NR_mmap2 is defined in /usr/include/asm/unistd_32.h but not in /usr/include/asm/unistd_64.h
[11:24] <persia> Hmm..  Can that be wrapped in an #ifdef ?
[11:25] <albert23> persia: http://pastebin.ubuntu.com/4642/
[11:26]  * persia notices the " /* TO DO! */" on line 220
[11:32] <geser> perhaps mappging __NR_mmap2 to __NR_doesnotexist in defs_x86_64.h could fix it
[11:33] <persia> That sounds like a sane plan.
[11:34] <persia> albert23: Does that work for you?
[11:34] <albert23> persia: I am trying the #ifdef you mentioned.
[11:36] <albert23> persia: that goeas much further, but now a link error: /tmp/buildd/umview-0.4a/um-viewos/um_mmap.c:312: undefined reference to `r_llseek'
[11:36] <geser> I'm there too
[11:36] <persia> Hmm....
[11:37] <persia> Odd.  I'd think the presence of __NR_llseek would allow a call to r_llseek.
[11:38] <geser> amd64 seem to only have __NR_lseek
[11:39] <persia> geser: Then how did it get past line 310?
[11:40] <geser> good question
[11:40] <persia> I would expect it to jump directly to line 315, without the error
[11:40] <albert23> include/module.h:163:#define __NR__llseek __NR_doesnotexist (and that means -1)
[11:44] <geser> I've commented that line out and add an #ifdef __NR__llseek around the use in scmap.c
[11:51] <geser> persia, albert23: -rw-r--r--  1 root root   4648 Feb 16 11:51 libumlib0_0.4a-2_amd64.deb
[11:52] <geser> but don't ask me if it also works
[11:52] <persia> geser: Congratulations!  Nice work.
[11:52] <persia> warp10: Can you identify a test case for geser to use before uploading?
[11:56] <warp10> persia: could rebuilding fuse-umfuse-iso9660 be enough?
[11:57] <persia> warp10: That just tests the headers though.  Do you know any use cases for um-viewos?
[11:57] <persia> In the worst case, it could just be uploaded, as having something buggy but available is better than having something FTBFS.
[11:59] <warp10> persia: no ideas, sorry. Maybe we can go ahead uploading it and hope it works fine, or even contact upstream and see if he likes this solutions, since he is not able to find a better one
[12:03] <warp10> gaspa: since you know libumlib0 very good, maybe you can help us finding a test case for the solution geser and persia just found to fix ftfbs on amd64
[12:07] <DktrKranz> persia, liw mailed and piuparts merge in progress, changes are less intrusive since most is due to a piuparts~ backup file
[12:08] <persia> DktrKranz: Cool.  I'm looking forward to having systematic tests once we can get everything together.
[12:08] <persia> (and life will be much easier with hardy+1, as we'll only have to support upgrades from hardy)
[12:09] <DktrKranz> persia, that would be great. I'd like to study AutoUpgradeTools to have something quick than piuparts
[12:11] <persia> DktrKranz: I only like piuparts because I've heard it is good.  Any other tools would also be welcome.  There are two use cases I'd like to see: 1) a quick test for a developer to test install/upgrade/remove/purge with a log to demonstrate it working, and 2) some means for mass-testing which would allow for someone to build a nice front-end to identify problems (in the spirit of the FTBFS page).
[12:11] <albert23> geser: did you also have to tweak wrap_in_statfs64?
[12:11] <persia> Ideally one could have two targets for the upgrade test, to demonstrate it working both against the last release, and the last LTS release.
[12:12] <DktrKranz> persia, when I was playing with pbuilder and some scripts, I was unable to have preseed working. Other than that, it does what piuparts do in half the time (at least on some old hardware)
[12:13] <persia> DktrKranz: Excellent.  That sounds like it is becoming almost a soluable issue.
[12:14] <geser> albert23: http://paste.ubuntu.com/4643/ has all the changes I did
[12:15] <geser> the modified package builds now on amd64 and still on i386
[12:15] <albert23> geser: thanks
[12:15] <DktrKranz> pbuilder has --execute option, we can pass a script to basically do any test we want (upgrade, install, purge). If anyone is comfortable with preeseding (since I'm not), I'd like to dig into it.
[12:17] <persia> DktrKranz: You might write to ubuntu-motu@ to ask for preseeding help, or liw might be interested if you can really demonstrate half the time for almost the same results, as he runs piuparts against main regularly.
[12:18] <geser> DktrKranz: what do you want preseeded?
[12:18] <geser> I've done some presseeding in my pbuilder to get sun-java-* automatically installed
[12:19] <DktrKranz> geser, there are some packages which asks for some input from users during install phase, pbuilder is unable to skip them and answer the default option.
[12:19] <geser> warp10: fuse-umfuse-iso9660 build with the modified umview package on amd64
[12:19] <persia> DktrKranz: Which packages?  Surely those are bugs, no?
[12:19] <DktrKranz> when I tested multiverse some months ago, I encountered some packages which require a manual intervention to be processe
[12:20] <DktrKranz> persia, hard to remember, basically because they're on ubuntuwire...
[12:20] <DktrKranz> (the results)
[12:20] <geser> DktrKranz: the most packages should install fine with DEBIAN_FRONTEND=noninteractive
[12:20] <persia> DktrKranz: Ah.  Makes sense.  Let's continue this conversation when ubuntuwire comes back :)
[12:21] <geser> DktrKranz: the exception is sun-java-* from multiverse
[12:21] <DktrKranz> geser, http://www.wgdd.de/?p=36
[12:22] <persia> Also j2sdk1.4 (Blackdown Java)
[12:22] <geser> yes, that's what I've done inside my pbuilder
[12:23] <warp10> geser: that's a step forward. If you are going to upload libumlib0 I'll wait until it builds to resubscribe u-u-s to bug #192248
[12:23] <geser> j2sdk uses an other debconf question so it must be preseeded seperately
[12:23] <geser> persia: any reason not to upload umview?
[12:24] <geser> warp10: umview on amd64 need to go through binary NEW too
[12:24] <persia> geser: I don't have any reservations, although if gaspa had a use case to verify it worked beforehand, that would be better.  Otherwise, we release it, and get bug reports to tell us what else to fix.
[13:34] <jpatrick> ScottK: with three acks  I can upload?
[13:39] <geser> persia: any idea what to do with the depwait of netbeans? it build-depends on libini4j-java which itself build-depends on jetty from multiverse
[13:39] <persia> geser: bug #192336
[13:39] <ubotu> Launchpad bug 192336 in jetty "Please migrate jetty from multiverse to universe" [Wishlist,Confirmed] https://launchpad.net/bugs/192336
[13:41] <persia> jpatrick: It's early there yet.  With context, maybe someone else could advise you.
[13:41] <jpatrick> persia: bug #192350
[13:41] <ubotu> Launchpad bug 192350 in semantik "[Feature Freeze Exception] New upstream release" [Undecided,New] https://launchpad.net/bugs/192350
[13:41] <RainCT> ScottK, ScottK2: ping
[13:41] <jpatrick> persia: he just commented so I thought he'd be around :)
[13:42] <RainCT> jpatrick: «Go ahead and upload.» pretty obvious :)
[13:43] <persia> jpatrick: Historically, it was 2 motu-release acks (and you only have two), so I'd assume that safe unless motu-release arranges for approval of a new policy for hardy.
[13:43] <jpatrick> RainCT: doulbe-check before I get bashed
[13:43] <jpatrick> persia: I count three :)
[13:44] <persia> jpatrick: Riddell and dholbach only admin the team, they aren't members.
[13:45] <jpatrick> persia: ah ok, I'll upload
[13:49] <pochu_> persia: that's pretty confusing
[13:50] <RainCT> ScottK, ScottK2: pyclamd is ready (should appear soon on REVU) but I can't get it working here (I've installed and started clamav-daemon but trying to do something raises ScanError)
[13:50] <persia> pochu_: Blame it on LP.  I suppose we could transfer admin from those people to MC, which as a group, would more clearly not be members.  Feel free to raise it in the next MOTU meeting if you'd like to request adjustment.
[13:51] <RainCT> >>> pyclamd.init_network_socket('localhost', 3310)  [...]  ScanError: Could not reach clamd using network (localhost, 3310)
[13:52] <pochu_> persia: I will.
[13:52] <pochu_> persia: so motu-council being the team owner would solve the issue. they don't need to be members
[13:52] <pochu_> that only confuses people
[13:53] <persia> pochu_: The Administrator is required to be a member, but by having the Administrator be a team, it may be less confusing.
[13:53] <pochu_> persia: really? at least some time ago it wasn't needed
[13:53] <persia> The individuals who happen to be members of MC would not need to be members of the team.
[13:53] <pochu_> persia: i.e. the team owner can do whatever he wants without being a team member
[13:54] <jpatrick> persia: we could make ~motu-release-admins and put them down as owner
[13:54] <persia> pochu_: Really?  That's different than my understanding.  You may want to get an official answer from the LP team before raising it at a meeting.
[13:54] <pochu_> jpatrick: I think the council should be the admin
[13:54] <pochu_> jpatrick: since the admin would be mainly to add/remove members, and that's a -council task
[13:54] <persia> jpatrick: That could work too, although then we get to discuss who belongs to ~motu-release-admins, which is why I suggested MC.
[13:55] <jpatrick> ah, ok
[13:56] <RainCT> ScottK2: oh ok, it works
[13:56] <RainCT> :)
[14:05] <pochu_> persia, jpatrick: proposal added to the agenda. I'll make sure about the needed of being a member.
[14:05] <persia> pochu_: Thanks.
[14:05] <jpatrick> pochu_: you don't have to - look at ~kubuntu-es and ~kubuntu-es-admins
[14:06] <persia> jpatrick: https://launchpad.net/~kubuntu-es/+members lists "Kubuntu Spanish Admins" as a member.
[14:07] <jpatrick> persia: yes, but it's indirect :)
[14:08] <persia> jpatrick: No, it's direct: see https://launchpad.net/~kubuntu-es-admins/+participation
[14:09] <persia> jpatrick: Specifically, the admin team is a member of the administered team.  The individual members of the admin team are not.  My claim is that the adminstrator (in this case a team) is required to be a member of the administered team.
[14:10] <jpatrick> persia: yes, I'm in that, and it says "You are the owner of this team, but not currently an active member."
[14:11] <persia> jpatrick: Yes, but you as an individual are not the administrator, you just happen to currently belong to the team which is the administrator.  The point being that LP requires the designated administrator (which may be a team) to be a member of the administered team.  It doesn't care about the individuals involved.
[14:11] <jpatrick> ah
[15:06] <ScottK> RainCT: Thanks.  Having a look.
[15:11] <tuxmaniac> any reference package that I can look into for "splitting up a package"
[15:12] <ScottK2> RainCT: Why the versioned dependency on pysupport?
[15:12] <ScottK2> tuxmaniac: What are you trying to do?
[15:13] <tuxmaniac> ScottK, I am trying to split a package. For closing the review point http://revu.tauware.de/details.py?package=alliance
[15:14] <ScottK2> So you want to break one source package up into multiple binary packages?
[15:18] <ScottK2> tuxmaniac: Having to do that with games packages (a separate data package) is quite common, so I'd look in that section.
[15:18] <tuxmaniac> ScottK, aah thanks.
[15:19] <RainCT> ScottK2: policy
[15:19] <RainCT> ScottK2: that's what http://wiki.debian.org/DebianPython/NewPolicy says
[15:21] <ScottK2> RainCT: I'd like it if this package was backportable to Dapper (which IIRC has pysupport 0.1).  Let me look into it a bit then.
[15:21] <ScottK2> RainCT: Also it needs MOTU as maintainer.
[15:24] <ScottK2> RainCT: I'm going to check and see if pysupport 0.1 builds a sane package.  I expect for this it will (it's so simple).
[15:24] <geser> I see that we should add the FF to Current Freezes on our wiki page. Has someone a few suggestions to put into "Current Work Mode"?
[15:25] <RainCT> ScottK2: btw, will this replace python-clamav in Hardy or are they for different things?
[15:25] <ScottK2> They are for different things.  They complement each other.
[15:26] <ScottK2> There were some functions removed from python-clamav in it's most recent version and python-clamd is the recommended way to replace them.
[15:26] <RainCT> ScottK2: ok. they have the same description, should I add something to pyclamd's?
[15:27] <RainCT> *s/description/description right now
[15:29] <ScottK2> RainCT: I'd use the about description from the upstream page: pyClamd is a python interface to Clamd (Clamav daemon). By using pyClamd, you can add virus detection capabilities to your python software in an efficient and easy way.
[15:29] <ScottK2> Short description would be python interface to Clamd (Clamav daemon)
[15:29] <RainCT> ScottK2: that's more or less what it has
[15:30] <RainCT> Python interface to the ClamAV daemon          This package adds virus detection capabilities to Python software in an efficient and easy way, thanks to the ClamAV antivirus toolkit.
[15:31] <RainCT> uh.. should bug 192322 be rejected?
[15:31] <ubotu> Launchpad bug 192322 in acon "Please sync acon 1.0.5-5 from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/192322
[15:32] <RainCT> it is to fix a FTBFS, but it doesn't fail in Hardy (https://launchpad.net/ubuntu/hardy/+source/acon/1.0.5-4)
[15:34] <ScottK2> Are you sure it wouldn't fail if it were built now?
[15:34] <RainCT> I'm trying
[15:35] <ScottK2> K
[15:35] <ScottK2> Nevermind about the versioning of pysupport.  Dapper pysupport doesn't have dh_pysupport in it, so it'll need to be a source backport no matter what.
[15:36] <ScottK2> RainCT: You need to set DEB_PYTHON_SYSTEM=pysupport in debian/rules.
[15:37] <RainCT> ScottK2: ah, right. thx
[15:38] <RainCT> ScottK2: about the maintainer, wasn't any @ubuntu.com ok?
[15:42] <RainCT> ScottK2: anyways, changed. should I reupload to REVU or to Ubuntu?
[15:42] <ScottK2> REVU please.
[15:42] <ScottK2> I missed that it was an ubuntu.com address.  It was fine.
[15:43] <ScottK2> If you intend to personally maintain it and not have the team maintain it that is.
[15:44] <RainCT> ScottK2: ah ok. Yes, I'll get it into Debian too :).
[15:45] <ScottK2> Great.  Did you upload an updated package to REVU?
[15:46] <ScottK2> RainCT: ^^^
[15:49] <ScottK2> RainCT: Also don't forget to do an ITP for Debian.
[15:53] <bddebian> Heya gang
[15:58] <LucidFox> hello bddebian
[15:58] <\sh> moins
[15:58] <CyberMatt> lo
[15:58] <geser> Hi bddebian
[15:58] <geser> Hi \sh
[16:01] <bddebian> Hi LucidFox, \sh, CyberMatt, and geser :-)
[16:01] <LucidFox> wow, four merge bugs, all by the same submitter
[16:05] <LucidFox> hellboy195, you should only re-add Ubuntu debian/changelog entries since the last sync
[16:06] <hellboy195> LucidFox: what package? or in generel?
[16:06] <\sh> bah...debugging wine on amd64 isn't a good idea
[16:06] <hellboy195> \sh: how's the progress ^^
[16:06] <LucidFox> hellboy195> libdvdread
[16:06] <LucidFox> hellboy195> plucker seems to be OK in this respect, looking at the remaining two
[16:06] <\sh> hellboy195: compiling with -fno-stack-protector didn't help...
[16:07] <\sh> hellboy195: I just upgraded my i386 desktop to hardy and try to debug there
[16:07] <hellboy195> \sh: if you need a tester or something like that just ping me
[16:07] <hellboy195> LucidFox: k
[16:10] <\sh> emgent: cacti is fixed ... (dapper, feisty, gutsy, hardy) with edgy i deal later...because of its EOL
[16:11] <ScottK2> RainCT: I'll be back later.
[16:11] <\sh> and gnucash has ofx support again...
[16:16] <calc> anyone happen to know what the command is to turn off buffering on the command line?
[16:17] <calc> i have a program that writes lots of data to stdout and i want it not to buffer it
[16:17] <hellboy195> LucidFox: this means that I should remove every ubuntu entry in the changelog before 0.9.7-2=
[16:17] <hellboy195> s/=/?
[16:19] <LucidFox> hellboy195> yes
[16:19] <LucidFox> hellboy195> since that version was synced with no Ubuntu changes
[16:20] <hellboy195> LucidFox: but 0.9.7-2ubuntu1 has ubuntu changes
[16:20] <LucidFox> hellboy195> yes, but it was uploaded later
[16:21] <LucidFox> look at the upload history: https://launchpad.net/ubuntu/+source/libdvdread
[16:21] <LucidFox> 0.9.7-2, followed by 0.9.7-2ubuntu1
[16:21] <hellboy195> LucidFox: though it was a sync I did over 20 merges and never removed previous ubuntu entries :\
[16:23] <LucidFox> Once a package has been synced, along with the original unmodified debian/changelog, all information about Ubuntu changes is discarded, and the history of said Ubuntu changes begins anew.
[16:24] <LucidFox> If it's merged with existing Ubuntu changes and a modified version is uploaded, then Ubuntu entries are kept.
[16:27] <hellboy195> LucidFox: interesting. It's the first time I heard this. nvm. new debdiff uploaded
[16:30] <LucidFox> hellboy195> all right, I'm currently processing xcin; commented on apt-watch
[16:32] <hellboy195> LucidFox: argh. But if have to say that the last merge also has this mistake and I only copied it :\ But I suppose that's no NEW remaining change. just correcht version number in changelog right?
[16:32] <LucidFox> hellboy195> If the version in control is correct, then yes, change it in changelog
[16:34] <RainCT> ScottK2: it's up now
[16:41] <LucidFox> Holy!.. That's one huge diff.gz that xcin has
[16:43] <hellboy195> LucidFox: I don't suppose this is my fault?
[16:43] <LucidFox> of course not, it's Debian's fault :)
[16:43] <LucidFox> uploaded
[16:43] <hellboy195> fine
[16:49] <LucidFox> hellboy195> now processing apt-watch; the change for xcin is trivial enough that you might consider pushing it back to Debian
[16:50] <LucidFox> it's not like one extra build-dependency would hurt them
[16:52] <hellboy195> LucidFox: ^^
[16:54] <LucidFox> and for apt-watch in Debian, the diff.gz is actually _bigger_ than the orig.tar.gz
[16:54]  * LucidFox headdesks
[16:56] <hellboy195> LucidFox: if you have finished ^^ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451135
[16:56] <ubotu> Debian bug 451135 in xcin "Please add libxext-dev to build depends" [Normal,Open]
[16:56] <LucidFox> Thanks!
[16:57] <LucidFox> Ah, it wasn't you
[16:58] <hellboy195> LucidFox: yep and because of that I wanted to show it to you
[17:05] <hellboy195> LucidFox: ähm this sounds stupid but can you explain me what the diff.gz shows us?
[17:05] <LucidFox> hellboy195> The diff.gz stores all changes between the maintainer's source tree and the orig.tar.gz
[17:06] <LucidFox> which is at least the debian/ directory
[17:06] <hellboy195> LucidFox: from the previous and actual version?
[17:07] <LucidFox> hellboy195> erm...
[17:07] <LucidFox> do you understand what the orig.tar.gz is?
[17:07] <hellboy195> LucidFox: sry. missunderstood it ^^
[17:07] <hellboy195> LucidFox: that means the debian directory must be very big to be bigger than the orig.tar.gz
[17:09] <LucidFox> That diff.gz stores not just the debian directory
[17:09] <LucidFox> the debian dir is small, there are lots of changes outside it
[17:09] <LucidFox> that's one borked package
[17:10] <hellboy195> k
[17:10] <cbx33> hi all
[17:11] <LucidFox> DktrKranz, since you're on plucker, maybe you could process libdvdread as well?
[17:11] <LucidFox> hellboy195> (uploaded apt-watch, by the way)
[17:11] <hellboy195> LucidFox: already saw it ;)
[17:12] <hellboy195> LucidFox: and if you wonder why I did 4 merges. I was bored ^^ hmm shouldn't be next time. 4 merges and 6 debdiffs so far :\
[17:12] <LucidFox> heh
[17:12] <DktrKranz> LucidFox, no problem, I'll assign it to me
[17:13] <LucidFox> I'm not really a fan of merges - when I do a merge, or new Ubuntu changes, I prefer pushing as much stuff to Debian as possible
[17:14]  * hellboy195 will now do his 5. merge today
[17:19] <DktrKranz> hellboy195, on incoming.debian.org there's a new plucker revision, mind checking?
[17:20] <hellboy195> DktrKranz: np
[17:20] <DktrKranz> hellboy195, it's a sync, look at their changes :)
[17:21] <hellboy195> DktrKranz: true
[17:21] <hellboy195> DktrKranz: may I tranform the merge to a sync bug?
[17:21] <hellboy195> *transform
[17:21] <DktrKranz> of course :)
[17:22]  * hellboy195 is on the way
[17:27] <hellboy195> DktrKranz: but
[17:28] <hellboy195> DktrKranz: finished. I hope it's ok
[17:28] <DktrKranz> hellboy195, you can delete your debdiff, if you want
[17:29] <hellboy195> DktrKranz: how ^^
[17:29] <hellboy195> DktrKranz: ah found it
[17:34] <hellboy195> Can somebody tell me if a libgif-dev (>= 4.1.6-3~) is ok as Build-Depend? What does this ~ mean?
[17:35] <broonie> It's part of the version number - it's a separator that sorts before anything else.
[17:36] <hellboy195> broonie: and it's also acceptable in ubuntu? because this is in debian and I haven't seen that in ubuntu so far
[17:36] <geser> why would somebody add a ~ there?
[17:37] <DktrKranz> typo?
[17:37] <broonie> hellboy195: It's just relatively new is all.
[17:38] <hellboy195> broonie: k, thx
[17:38] <tsmithe> hi, is anyone on the backports team available to take a look at https://bugs.launchpad.net/gutsy-backports/+bug/192440 ?
[17:38] <ubotu> Launchpad bug 192440 in gutsy-backports "Please backport mscore 0.9.1d+dfsg-0ubuntu1 from Hardy" [Undecided,New]
[17:38]  * broonie would suspect a typo too.
[17:38] <tsmithe> builds and runs fine on a vanilla gutsy system
[17:38] <james_w> I can't find a clear guide on the wiki for this. I have a debdiff for a bug available, what are the steps to get it sponsored?
[17:38] <tsmithe> ScottK, maybe? ^^
[17:38] <james_w> I guess it is attach it to the bug and subscribe u-u-s, is that correct?
[17:39] <geser> james_w: exactly
[17:40] <james_w> geser: thanks.
[17:40] <DktrKranz> 3.7.3 policy named something about ~, but I don't remember what
[18:26] <tsmithe> thanks jdong
[18:26] <jdong> yeppers
[18:29] <ScottK2> RainCT: I'm back.  Looking.
[18:39] <tsmithe> jdong, when will i know if mscore has been uploaded to gutsy-backports, so i can tell upstream to publicise it?
[18:39] <jdong> tsmithe: subscribe to the bug and when it's processed, the archive admins send out a mail on it
[18:40] <tsmithe> excellent, thanks
[18:44] <ScottK2> RainCT: I'm gonna upload it unless you want to.
[18:44] <RainCT> ScottK2: go on :)
[18:44] <ScottK2> OK.
[18:45] <ScottK2> RainCT: I'm going to make one small change (see my revu comment).
[18:45] <AnAnt> Hello, can anyone help me with this postinst script: http://pastebin.com/m2f1953e2
[18:45] <AnAnt> I am using debconf in it, and I got this error when I install the resulting deb file: debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable
[18:45] <RainCT> What should I do if I'm installing a package with a license that isn't in /usr/share/common-licenses? Installing it with debian/docs lets linda and lintian complain..
[18:46] <ScottK2> RainCT: The full copy of it you put in debian/copyright should be sufficient.
[18:47] <RainCT> argh. 470 lines?!
[18:47] <ScottK2> Yes.  It's a requirement.
[18:48]  * RainCT has seen at least 1 package that doesn't do this
[18:48] <ScottK2> Then I'd file a bug.
[18:49] <ScottK2> Policy requires it.
[18:49] <ScottK2> RainCT: pyclamd is uploaded.  Thanks for jumping right on that.
[18:49] <RainCT> well, the package I remember is going to be removed anyway
[18:51] <ScottK2> RainCT: Interested in trying to make a version of pyclamd that works in Dapper?
[18:51] <RainCT> ScottK2: how would I do that?
[18:52] <ScottK2> You'd have to change your package to use dh_python and creatively get the file into the right spot.
[18:52] <ScottK2> If you don't have a Dapper box it might be kind of hard to test.  I've got one, so I could check anything you came up with.
[18:53] <ScottK2> I can do it if you don't find the idea interesting.
[18:54] <RainCT> ScottK2: uhm.. better you do it
[18:55] <ScottK2> K
[19:17] <ScottK2> RainCT: I notice (now of course) that you have neither a pyversions file, nor the XS/XB python versions foo in debian/control.  I think that's still required.
[19:19] <RainCT> ScottK2: I checked python-support's docs before and there it says that if you don't use it it'll supose the current python version
[19:19] <ScottK2> OK.  Maybe it's not needed.
[19:20] <ScottK2> RainCT: I'd say time to get it into Debian then.
[19:20] <RainCT> ScottK2: yes, just filled an ITP
[19:21] <ScottK2> Great.
[19:22] <ScottK2> BTW, I'm not 100% sure modifying the file in get-orig-source is going to fly in Debian.  Policy says you can't repack a tarball with files you've modified.  Since this is packing and not repacking, I'm really not sure.
[19:22] <ScottK2> I'd be sure and ask about it when you're being sponsored.
[19:22] <crimsun_> james_w: thanks for the debdiff.  As a note, when modifying source packages, please make sure that https://wiki.ubuntu.com/DebianMaintainerField is followed and that the distribution is correct.
[19:27] <james_w> crimsun_: thanks. I'll upload a new diff.
[19:27] <crimsun_> james_w: no need, I've tweaked it and uploaded already.
[19:27] <james_w> crimsun_: ah, great, thanks.
[19:43] <ScottK> RainCT: If you're interested in what changes were needed for the Dapper toolchain, I've put a test version of the package in the ubuntu-clamav PPA: https://launchpad.net/~ubuntu-clamav/+archive
[19:49] <norsetto> howdy all
[19:53] <ScottK> Heya norsetto.
[19:53] <norsetto> heya scottk
[19:53] <ScottK> norsetto: I've been wanting to catch up with you to discuss FFe policy.  Got a minute?
[19:53] <norsetto> scottK: even 5
[19:53] <ScottK> K
[19:54] <ScottK> norsetto: I'm hoping to get agreement on the proposal I made to the MOTU ML about bugfix only upstream changes.
[19:54] <norsetto> scottk: ok, I'm all for it
[19:55] <ScottK> norsetto: So far Hobbsee and TheMuso are in agreement and I'm trying to catch you and sistpoty to see what you think.
[19:55] <ScottK> OK
[19:55]  * ScottK marks off another one.
[19:55] <ScottK> norsetto: The other thing I think we need is a list on the wiki of blanket FFe's so people aren't confused about what's allowed and what's not.
[19:55] <ScottK> That was the cause of some confusion last time.
[19:56] <norsetto> scottk: ok, I can understand
[20:08] <superm1> ScottK, what about if the bugfixes aren't listed locally in launchpad, but only on upstream's tracker?
[20:09] <ScottK2> Is there an upstream changelog?
[20:10] <ScottK2> superm1: ^^^
[20:10] <superm1> ScottK2, only in svn logs
[20:10] <ScottK2> It's a snapshot or a release?
[20:10] <superm1> ScottK2, we're on snapshots right now, and upstream feature froze already
[20:10] <superm1> so its just tracking bug fixes till release
[20:11] <ScottK2> When is release expected?
[20:11] <superm1> ~1-1.5 months
[20:12] <ScottK2> Argh.
[20:12] <superm1> yeah i know :(
[20:12] <ScottK2> How about this for a plan ...
[20:14] <ScottK2> File a standing FFe request for the package, including when you expect a release and when you're going to stop updating, release or not.  Then if that gets approved, you just add a comment each time you take a snapshot and upload that describes the changes for that upload?
[20:14] <ScottK2> superm1: ^^^^ ?
[20:14] <superm1> yeah i can do that at least
[20:14] <ScottK2> Does that sound fair and reasonable from your end?
[20:15] <superm1> well the one thing would be that i'd like to keep updating release or not up until the cutoff on hardy - if its just bug fixes, there should be no harm there
[20:15] <ScottK2> Is the package used outside mythtv?
[20:15] <ScottK2> What package?
[20:15] <superm1> i'll get an FFe together and you guys will be able to look it over though
[20:16] <superm1> it's mythtv, mythplugins, mythtv-theme-*, nuvexport
[20:16] <ScottK2> Don't worry about the diffstats and stuff, just the plan.
[20:16] <superm1> all of them come as a bundle and are only used together
[20:16] <ScottK2> My opinion is that if I can trust you not to mess that one up, we've got a lot of trouble.
[20:16] <ScottK2> Just lay out a plan and ask for approval.
[20:16] <superm1> okay, will do :)
[20:35] <ScottK2> norsetto and TheMuso: I've started the page for standing FFe's https://wiki.ubuntu.com/StandingFeatureFreeze
[20:35] <norsetto> scottk: bookmarked
[20:35] <ScottK2> I'll write mail on the subject too.
[20:38] <jdong> grumble
[20:38] <jdong> try #4 of firefox-3.0
[20:39] <jdong> apt has broken so much I feel like an automatix developer
[20:39]  * ScottK declined to accept that update yesterday.
[20:39] <ScottK> First updates after freeze milestones tend to be a bit ugly.
[20:39] <jdong> hehe
[20:40] <jdong> surprisingly, nothing blew up too badly when I tried it on my macbook
[20:40] <jdong> well the kernel was a big ugly
[20:40] <jdong> bit*
[20:41] <ScottK> So far I'm running Hardy on an old Dell laptop that had enough kernel problems with Gutsy that it got an honorable mention in the distro release notes.
[20:41] <ScottK> Hardy is much better.
[20:43] <jdong> AAH! Stupid symlinks!
[20:43]  * jdong smacks firefox-3.0
[20:44] <jdong> ok I don't nearly begin to trust myself when it comes to these packaging changes, I'm gonna go with the 3-acks-from-testers path.
[20:44]  * jdong primes the backporter ppa
[21:02] <jdong> asac: for bug 191796, bug 191800, I've attached debdiffs and uploaded to PPA's my testing packages. Locally I've made sure they install properly without clobbering firefox 2. When you get a chance, help me glance that over. Thanks
[21:02] <ubotu> Launchpad bug 191796 in gutsy-backports "Please backport firefox-3.0 3.0~b3 final" [Undecided,Confirmed] https://launchpad.net/bugs/191796
[21:02] <ubotu> Launchpad bug 191800 in gutsy-backports "Please backport xulrunner-1.9 1.9~b3 final" [Undecided,Confirmed] https://launchpad.net/bugs/191800
[21:36] <norsetto> time to go testing ...
[22:59] <DRebellion> what does "CVE" stand for?
[22:59] <Nafallo> DRebellion: http://cve.mitre.org/
[23:00] <DRebellion> thanks
[23:16] <pochu> ScottK: #
[23:16] <pochu> ScottK: Upstream microreleases of applications are usually fine after this point if they only fix bugs. This should be verified by reading the detailled upstream changelog and (cursory) reading the diff between the version in the Ubuntu development release and the new upstream version. If in doubt, ask the release team for advice.
[23:16] <pochu> From https://wiki.ubuntu.com/FeatureFreeze
[23:17] <ScottK2> pochu: usually.  Who decides if it's a usually or not.
[23:17] <pochu> (we were discussing whether it's ok to upload bug-fix-only new upstream releases after FF without needing to do paperwork)
[23:17] <pochu> ScottK2: the developer himself
[23:17] <pochu> ScottK2: if he needs to ask the release team, then what would have changed from the past?
[23:17] <ScottK2> I've proposed how we will deal with this on the MOTU list and so far I've got 4 of 5 motu-release members to agree.
[23:18] <pochu> But nothing has officially changed yet.
[23:18] <ScottK2> pochu: It's a question of documentation.  A full FFe has diffstats and other stuff.
[23:18] <ScottK2> Right.  And in the past all upstream releases past UVF needed an exception.
[23:18] <ScottK2> So I'm trying to get that relaxed.
[23:18] <pochu> But we are talking about policy. And current policy says it's ok if the new upstream is bug-fix only
[23:19] <pochu> ScottK2: that was when UVF existed. And it was relaxed with the UVF -> FF change.
[23:19] <ScottK2> But we have no process for this policy change yet.
[23:19] <ScottK2> That's what I'm trying to get worked out.
[23:20] <pochu> When it was UVF, every new upstream release needed an exception. That was changed to FF by pitti's proposal so bug-fix only releases have a general exception.
[23:20] <pochu> ScottK2: the process is "if it's bug-fix only, upload" IMHO.
[23:20] <ScottK2> So far no one agrees with that.
[23:20] <pochu> ScottK2: if you want to add paperwork again, well, that will look like UVF again.
[23:21] <ScottK2> All I want is it written down in a bug what the changes were.  No diffstat, no approvals.  Still much simpler.
[23:21] <ScottK2> For your proposed sync we were originally discussing, the difference is you'd have to add the upstream changes too.  Very minor.
[23:23] <pochu> So with "you need to do FFe exception paperwork" you meant writting the changelog entry in a bug?
[23:24] <pochu> which is covered by "requestsync spe hardy" anyway...
[23:24] <ScottK2> Today (until my proposal is approved) I think you need a full FFe.  If my proposal is adopted, then it's just adding the upstream changes to the sync bug.
[23:24] <pochu> I disagree.
[23:24] <ScottK2> No, request sync just has the debian/changelog entries.
[23:24] <pochu> Today it would be a bug fix only so it's OK to upload.
[23:24] <pochu> Your proposal only adds paperwork AFAICS
[23:24] <ScottK2> pitti doesn't unilaterally set MOTU policy/procedure.
[23:25] <ScottK2> We do that ourselves.
[23:31] <pochu> ScottK2: I had assumed it was applying to universe too. In that case, the wiki is really unclear in that regard.
[23:31] <pochu> ScottK2: and why not stick with the main procedure?
[23:31] <pochu> i.e. bug-fix-only -> upload
[23:31] <ScottK2> pochu: I can see how that might be.  I wish we'd had motu-release team in place more than a day before feature freeze to get all this clear.
[23:32] <ScottK2> Because we have a lot more variability in experience level in MOTU than they do in core.
[23:32] <pochu> I see. That makes sense.
[23:32] <superm1> "they", ScottK2 aren't you a core now :)
[23:32] <ScottK2> I am.
[23:32] <ScottK2> But I'm talking about Universe versus Main policy here as a motu-release person.
[23:33] <pochu> Well I guess it isn't that bad as long as it's only the changelog||news diff
[23:33] <pochu> ScottK2: sorry if I've been rude
[23:33] <ScottK2> pochu: No trouble.  All's well that ends well.
[23:33]  * pochu updates the wiki to make clear that's only Main policy
[23:33] <ScottK2> pochu: Why don't you leave it for now.
[23:34] <ScottK2> I hope sistpoty will appear soon and we can have an agreement shortly.
[23:34] <ScottK2> superm1: Did you see the comments on the mythTV FFe?
[23:35] <superm1> ScottK2, yeah, and laga responded to each of them before I had a chance
[23:35] <superm1> did you look over his responses?
[23:35] <ScottK2> I did, but I've no idea who he is.
[23:35] <pochu> ScottK2: ok.
[23:35] <superm1> ScottK2, oh he is part of ~ubuntu-mythtv
[23:35] <superm1> he has been managing parts of the trunk build and our diskless stuff
[23:36] <ScottK2> superm1: OK.  Would you please comment in the bug supporting what he said since you're the requestor and who I'm going to lean on if it goes bad.
[23:37] <superm1> of course
[23:37] <pochu> ScottK2: this is my second mistake with universe FF in one day... I thought dholback and Riddell were motu-release members, as in fact they are members of ~motu-release. And now this...
[23:37] <pochu> ScottK2: is it known how many ACKs does one need to get a FFexception for Universe?
[23:37] <ScottK2> pochu: It's no trouble.  This is your first release as MOTU, so no problem.
[23:37] <ScottK2> It's been two in the past and no one has proposed changing it.
[23:38] <pochu> ScottK2: but not my first FF exception ;)
[23:38] <pochu> Ok, thanks.
[23:38] <ScottK2> That's part of what I'm trying to get nailed down.
[23:39] <pochu> ScottK2: for the members issue, what do you think about the proposal in the 3rd point in https://wiki.ubuntu.com/MOTU/Meetings ?
[23:40] <geser> pochu: if a ~motu-release member set your ff exception request from new to confirmed, I'd say it got accepted.
[23:41] <ScottK2> pochu: Sounds sensible to me, but I'm not up on the LP foo enough to know if that would work as expected or not.
[23:41] <pochu> ScottK2: it worked in the past for me, but I'll get cleared it anyway from a LP developer, or will do that myself with in staging.lp.net
[23:42] <ScottK2> pochu: I like the idea of MC being the owner of motu-release and not two semi-random Canonical employees.
[23:42] <ScottK2> K
[23:46] <ScottK2> superm1: I just acked (still need a 2nd) for uploads up the the Beta release.  I did that as much as anything to give you leverage with upstream to cut the release.
[23:46] <superm1> great thanks ScottK2
[23:54] <james_w> geser: hi. I don't know if you're still around, but I was wondering what http://patches.ubuntu.com/b/binutils-avr/binutils-avr_2.18-1ubuntu1.patch is saying, i.e. "Update the symlink to the binutils source archive."
[23:55] <james_w> geser: there is no obvious change in the diff, but it sounds like the sort of thing that may not show up in a diff.
[23:55] <james_w> geser: there is a new upload to be merged, so I was wondering if a sync was safe.
[23:56] <geser> james_w: all I changed was a symlink to the binutils-source.tar.gz inside the package (it's a native one)
[23:56] <geser> james_w: if it builds in hardy, it can be synced
[23:57] <james_w> geser: i'll try it, thanks.