[12:38] <slangasek> Fujitsu: I had notes telling me there was supposed to be an advance warning of the impending freeze, but I was counting down from the wrong point and didn't notice it until the day of the freeze itself (today) :/
[12:39] <osmosis> how come I dont see a Xen team listed ?
[12:40] <Fujitsu> osmosis: ubuntu-xen
[12:40] <osmosis> Fujitsu: where ?
[12:40] <Fujitsu> osmosis: On Launchpad.
[12:40] <osmosis> Fujitsu: https://wiki.ubuntu.com/MOTU/Teams
[12:41] <Fujitsu> Xen is special and not entirely universe, so probably doesn't have a page.
[12:41] <Fujitsu> And the wiki is woefully out of date in places.
[12:41] <pochu> https://launchpad.net/~ubuntu-xen
[12:42] <Fujitsu> slangasek: When did the release schedule change
[12:42] <Fujitsu> *?
[12:42] <Fujitsu> Well, actually, I guess the final freeze isn't marked...
[12:42] <slangasek> yeah, that's the problem
[12:42] <persia> Fujitsu: It's hidden under "ReleaseCandidate"
[12:43] <slangasek> except the freezing mentioned under ReleaseCandidate is still different
[12:43] <Fujitsu> ReleaseCandidate says that after it only showstoppers. But nothing about ReleaseCandidateFreeze, hm...
[12:43] <Fujitsu> (and it should probably be clarified that it now applies to universe too)
[12:44] <persia> Certainly that.  Freezes applying to Universe are fairly new (Excepting UVF and New Packages).
[12:45] <slangasek> well, in practice the BetaFreeze "applied" to Universe in that packages had to be hand-approved
[12:45] <slangasek> doesn't mean there was much review of them along the way
[12:45] <Fujitsu> That has always been regarded as a Soyuz limitation.
[12:45] <Fujitsu> It was a given that packages would be waved through without checking.
[12:46] <persia> slangasek: But it specifically says in BetaFreeze that the freeze is lifted after BetaRelease.
[12:47] <DktrKranz> slangasek, must MOTUs stop to upload packages and wait for an ack from RC team or they simply do as usual and RC will review them by hand?
[12:47] <slangasek> DktrKranz: the latter
[12:47] <DktrKranz> ok, thanks
[12:49] <DktrKranz> anyway, I think there should be an accurate selection before uploading a package in ordert to avoid high loads for RC. Am I wrong?
[12:49] <persia> Now I'm confused.  I thought that we were only to work on specific release-relevant bugs, rather than doing as usual.
[12:51] <Fujitsu> persia: As usual, as opposed to asking for prior RM approval.
[12:51] <slangasek> persia: I'm requesting clarification from veteran members of the release team.  the notes I'm going from don't distinguish between universe and main and so I also didn't distinguish in my mail, but it's entirely plausible to me that it's not meant to apply to universe
[12:51] <persia> Fujitsu: Ah.  Right.
[12:51] <Fujitsu> Aha. Yay for lack of documentation!
[12:52] <persia> slangasek: OK.  Thanks.  I'll prep stuff as if it would be applied then (pending resolution).
[12:53] <slangasek> persia: ok, it's intended that https://wiki.ubuntu.com/FreezeExceptionProcess#head-c29dbda80b94dddd19d454dc8f454fcadc6b3302 applies, which means that even though the archive is "frozen", we'll give only a passing review to universe uploads.  Sorry for the confusion.
[12:54] <persia> slangasek: That makes more sense.  Thanks.  No worries on the confusion: I've been away for around three months, so carry a fair amount of uncertainty returning.
[12:55] <Fujitsu> slangasek: Aha, thanks for the clarification.
[12:55] <slangasek> do you think a follow-up email is warranted, or will word-of-mouth take it from here?
[12:56] <persia> slangasek: You're probably safe.  People who want to upload will likely check here if there are questions.
[12:56] <slangasek> ok, cool
[12:57] <DktrKranz> thanks for clarifying that
[12:57] <Fujitsu> Might be an idea to stick something in the topic of either here or #ubuntu-devel.
[12:59] <persia> It still needs manual (if light) review by the Release Team, so in a sense, it is frozen anyway.  Perhaps in /topic here, but in -devel?
[01:07] <TheMuso> pochu: Thanks for doing minutes, not that there was much to cover. :)
[01:07] <pochu> TheMuso: hehe, true that :-)
[01:11] <persia> TheMuso: Hi.  I wanted to ask about ubuntustudio-desktop as a dependency of ubuntustudio-*.
[01:12] <TheMuso> persia: Yes, we don't want that either, we were trying to get things straightened out for disks, but I've just uploaded a new meta to remove that.
[01:12] <persia> TheMuso: Ah...  Cool.  I was just confused.
[01:22] <minghua> Should new upstream version upload of a package already in archive use REVU?
[01:22] <persia> minghua: If you need UVFe, it should be in an alternate repository (REVU is a good example of such a repository).
[01:23] <minghua> persia: Not my package.  Just a question about the general policy.  I'll take that as a yes, thanks.
[01:24] <persia> minghua: More generally then, before UVF, it just gets uploaded.  After UVF, it needs to be somewhere for review.
[01:25] <minghua> persia: But non-MOTU can still upload to REVU for review, right?
[01:25] <persia> minghua: Sure (although I'm not sure what the answer will be after UDS).
[01:26] <minghua> BTW is there any REVU admin around?  My account seems to be removed after the move.
[01:27] <minghua> (...or should I upload a package, therefore create an account, then bother the admins to add privilege for me?)
[01:27] <persia> minghua: I don't appear to be a REVU admin anymore, but what are you trying to accomplish?
[01:27] <minghua> persia: Just add a comment.
[01:28] <minghua> Not urgent at all, obviously.
[01:29] <persia> minghua:  Ah.  I think you'll need an admin then (unless something has changed).
[01:29] <minghua> persia: Or if you are so kind, please comment on http://revu.tauware.de/details.py?upid=339 and ask the uploader to run lintian (at least read the lintian output after uploading).
[01:29] <persia> minghua: On the other hand, the work described in https://lists.ubuntu.com/archives/ubuntu-motu/2007-August/002104.html might have given you a different account.
[01:30] <Fujitsu> minghua: Anybody with an account on sparky (ie. ubuntu-dev) can actually promote users.
[01:30] <persia> Fujitsu: it's not a direct map to ubuntu-dev (or my account would work).
[01:31] <minghua> Fujitsu: Thanks.  Let me try the thing in persia's link first.
[01:31] <minghua> Thanks to persia too. :-)
[01:31] <Fujitsu> persia: The accounts on sparky should be pretty much everybody, though the syncing script apparently hasn't run in a while.
[01:32] <persia> Fujitsu: Around 6 months, but I understand that the administrator will be more active again soon :)
[01:34] <minghua> Yay, I'm in now.
[01:34] <minghua> persia: Thanks, the procedure in the mail you pointed to worked.
[01:34] <persia> minghua: Great.  I've also relayed your comment.  Let me know if you want to rephrase, and I'll delete.
[01:34] <minghua> Apparently iceape is quite stubborn about remembering my logins.
[01:36] <minghua> persia: The comment is good, thanks (actually, more polite than I would have put it :-P).
[01:36] <persia> minghua: I like to provide encouragement :)
[01:56] <minghua> Fujitsu: Apache 1 or Apache 2 packages?
[01:56] <Fujitsu> minghua: Apache 1.
[01:57] <slangasek> because they're packages someone uploaded 8 years ago with a userbase of 5? :)
[01:57] <Fujitsu> slangasek: Heh, probably.
[01:57] <minghua> Fujitsu: I think all apache 1 packages are out of testing now.  But I'm sure slangasek knows better than I do.
[02:01] <slangasek> afraid they aren't
[02:01] <slangasek> wish they were :)
[02:01] <slangasek> (the main holdout is php4)
[02:04] <persia> Isn't PHP4 EOL?
[02:04] <Fujitsu> persia: Not until December, IIRC.
[02:12] <slangasek> persia: php4 is already dead in unstable, it's stuck in testing because it has the same problem as apache1 itself
[02:12] <slangasek> (too many reverse-deps that won't go awaaaaayyy)
[02:13] <persia> slangasek: Ah.  I can sympathise.
[02:13] <Fujitsu> Surely 4 months is enough for somebody to come and kill them without the maintainer?
[02:13] <persia> Are there removal bugs filed?  If not, they may never go...
[02:15] <LaserJock> ok, so what is a good CLI way to take out a variable string from another string?
[02:15] <Fujitsu> LaserJock: How is the variable string separated from the rest?
[02:15] <LaserJock> slangasek: are you the one we need to ask for a RC freeze exception?
[02:15] <persia> LaserJock: Do you mean something like s/$foo//?
[02:15] <Fujitsu> And by take it out, do you mean return the variable bit, or remove it from the original?
[02:16] <LaserJock> persia: basically yeah
[02:16] <LaserJock> I'm doing some translation stuff
[02:16] <persia> LaserJock: I like sed for that.
[02:16] <slangasek> LaserJock: if necessary, though usually you should let the uploads do the talking :)
[02:16] <LaserJock> I need to turn about-edubuntu-CC.po into CC.po
[02:16] <Joe_CoT> https://bugs.edge.launchpad.net/ubuntu/+source/deluge-torrent/+bug/149050 Found the issue, worked with the developer for the patch, patch works. Anyone wanna package it, or does anyone wanna sponsor mine?
[02:16] <ubotu> Launchpad bug 149050 in deluge-torrent "Deluge torrent client: Cannot set file priority, as it continually claims that Full Allocation is not set" [Undecided,Confirmed] 
[02:16] <persia> (e.g. `sed -i s/'REMOVE ME'//g foo`)
[02:16] <LaserJock> but the "about-edubuntu-" part will change depending on the doc I'm working on
[02:17] <slangasek> Fujitsu: feel free to join the Debian QA team to try to identify these and get them cleaned out? :)
[02:17] <LaserJock> persia: ok, right, but can I stick a variable in there for "REMOVE ME" ?
[02:17] <persia> LaserJock: You can, but it sounds like you'd do better in a bash context (see http://www.faqs.org/docs/abs/HTML/string-manipulation.html)
[02:17] <LaserJock> slangasek: is anybody free to join Debian QA?
[02:18] <slangasek> LaserJock: yes; by "join" I basically mean "do the work to identify packages that should be orphaned or removed, post to debian-qa to get a consensus"
[02:18] <persia> e,g, ${$FOO#$BAR (close brace) removes $BAR from $FOO
[02:18] <slangasek> and then "if approved by the team, file bug reports"
[02:20] <LaserJock> slangasek: does Debian QA have a wiki/web page that describes what tasks they do?
[02:20] <Fujitsu> LaserJock: qa.debian.org?
[02:20] <LaserJock> hah
[02:20] <LaserJock> those Debian guys think of everything ;-)
[02:20] <persia> LaserJock: It's practice what does it.
[02:21] <LaserJock> anybody know if Debian has implemented the new Debian Maintainer thing?
[02:21] <Fujitsu> LaserJock: Not yet.
[02:21] <slangasek> it's not fully implemented yet, no
[02:21] <Fujitsu> Although I am a bit behind on debian-devel.
[02:22] <LaserJock> hmm, I'd like to sign up for that when it's working I think
[02:22] <slangasek> there's some prototype code
[02:23] <LaserJock> I was quite surprised how well it worked and looked ;-)
[02:24] <Joe_CoT> Ok, let's try this again :) I fixed #149050, I've got the patch, and I'm not really sure how to proceed. It's correct, tested, and I have a package for it. Anyone want to look at the patch and put it in? Anyone want to sponsor mine? Not sure how to proceed.
[02:24] <persia> bug 149050
[02:24] <ubotu> Launchpad bug 149050 in deluge-torrent "Deluge torrent client: Cannot set file priority, as it continually claims that Full Allocation is not set" [Undecided,In progress]  https://launchpad.net/bugs/149050
[02:24] <Fujitsu> bug #149050
[02:25] <persia> Joe_CoT: The next step is to wrap the patch (along with any other fixes from https://bugs.launchpad.net/ubuntu/+source/deluge-torrent/ with easy fixes) in a candidate revision patch, and subscribe ubuntu-universe-sponsors.
[02:27] <persia> Joe_CoT: Note that there may be a conflict with bug 139518.  You'll want to review to see which is better for a final solution (at this point, I think targeted patches are preferred).
[02:27] <ubotu> Launchpad bug 139518 in deluge-torrent "UVF Exception: latest stable version 0.5.5" [Wishlist,Confirmed]  https://launchpad.net/bugs/139518
[02:28] <Joe_CoT> well, i went and worked with the devs to get the patch, since we're in feature freeze. Updating to 0.5.5 fixes the issue, but I didn't think that was happening at this point
[02:28] <minghua> Joe_CoT: Can you provide a full debdiff as well?
[02:29] <minghua> Joe_CoT: i.e., with debian/patches/00list and debian/changelog changes.
[02:29] <persia> Joe_CoT: I also don't think it will be happening, as we've just entered the ReleaseCandidateFreeze, so the next step is to prepare a new candidate revision.  There's some instruction available from https://wiki.ubuntu.com/MOTU/Contributing, although it may be slightly out of date.
[02:30] <Joe_CoT> minghua: I can, but I'm not sure how to do so. if you give me a hint I'll get on it and attach it
[02:30] <Joe_CoT> persia: yeah, i figured, and that's why I wanted to just patch the bug
[02:31] <persia> Joe_CoT: one-bug revisions are good.  Just ask here if you have any trouble with the instructions.
[02:32] <minghua> Joe_CoT: The link given by persia has instructions about using debdiff.
[02:32] <minghua> Although to be honest, that patch confuses me quite a bit.
[02:34] <persia> Looks to me like a change to the preferences model: combining two mutually opposed booleans into a single entry.  Am I missing something?
[02:35] <Joe_CoT> persia: yes, that's it. The problem is that, in the current version, preferences sets both use_full and use_compact to 1, so compact is always used. In 5.4.1, only use_compact is actually used.
[02:35] <minghua> persia: Why is the first hunk necessary?
[02:36] <Joe_CoT> so, setting compact sets use_compact =1, setting full sets use_compact=0
[02:36] <persia> minghua: The first hunk removes the logic to auto-set the alternate boolean when one is set, and replaces it with a radio control.  The second uses the radio control instead of the boolean to set a value.
[02:38] <Joe_CoT> minghua: added the debdiff
[02:39] <fedefede0101> hi guys, just a question.....build-stamp and config-stamp are lock files right?? so, they're supposed to be empty at the end of the building process...
[02:39] <fedefede0101> am I right??
[02:39] <fedefede0101> sorry, I'm preety new with packaging....
[02:39] <fedefede0101> :)
[02:39] <minghua> Hmm.  Let me download the deluge-torrent package.
[02:39] <TheMuso> fedefede0101: THey are used to indicate that that part of the package build has completed successfully.
[02:40] <persia> Joe_CoT: A few notes:  1) In the changelog, describe the issue resolved so that admins don't need to check lauchpad.  2)  The syntax (LP: #nnnnn) in the changelog will automatically close the bug for you.
[02:40] <minghua> persia: BTW I am still not convinced, I don't see anything removed in the first hunk.  I see it as a functional-equivalent change.
[02:40] <Joe_CoT> persia: ok, I'll make that change
[02:40] <persia> minghua: I'll defer to you: my python-fu is really more python-bu
[02:40] <fedefede0101> ok, thanks TheMuso :) so, I was right...
[02:41] <fedefede0101> I'm trying to learn as much as I can...
[02:41] <minghua> persia: Nah, I am a green newbie on python, too.
[02:42] <Joe_CoT> minghua: the change is that now, instead of the full radio being set to use_full, and the compact radio set to use_compact, the compact radio is set to use_compact, and the full radio is set to !use_compact. use_compact is the only one actually used, and that was the problem
[02:42] <fedefede0101> good night...and thanks again!! :)
[02:42] <persia> Grrr...  www.jp.debian.org isn't mirroring...
[02:43] <persia> I get it: so an alternate solution would be to add another if clause checking the state of radio_full_allocation (although this is nicer).
[02:43] <minghua> Joe_CoT: Yes, I understand the logic.  But I don't see anything involved with "use_full_storage" in the first hunk.
[02:43] <Joe_CoT> minghua: exactly. the tag is now gone
[02:44] <minghua> Joe_CoT: Then why change the first hunk?
[02:44] <minghua> ...If it has nothing to do with the removed tag.
[02:46] <Joe_CoT> minghua, the first chunk is probably unnecessary, correct. It looks like it's just a more streamlined version. If you'd like, I can try without the top chunk and see if it works correctly.
[02:46] <minghua> Joe_CoT: No need.  If the patch comes from upstream, keep it as is.
[02:47] <minghua> Joe_CoT: I'm just making sure I'm understanding the patch correctly.
[02:47] <persia> (Just be prepared to defend it :))
[02:47] <Joe_CoT> ok. yeah, the only change is i changed it from patch to dpatch
[02:50] <minghua> Joe_CoT: Also, please mention that the patch comes from upstream in debian/changelog.
[02:50] <Joe_CoT> ok
[02:51] <minghua> Actually, I think I see the point of the first hunk now.
[02:53] <minghua> persia: Are you familiar with the freeze exception process?
[02:55] <persia> minghua: This freeze is new for me, and I've been away for a while.  From what I understand from this morning's MOTU meeting, there are a number of active sponsors who could provide review (if the bug is subscribed to the team).
[02:56] <crimsun> still the same process as before.  File bug against source package, attach debdiff, sub motu-uvf, yadda.
[02:56] <Fujitsu> crimsun!
[02:56] <minghua> persia: I have done the review.  I think the patch is good.  I just don't know the procedure (how many acks?  can I just upload?  should I ping release managers after upload?)
[02:56] <minghua> Hi crimsun.
[02:57] <Joe_CoT> persia: Added more to changelog and patch, changed to use (LP: #xxxxx) syntax. http://paste.ubuntu-nl.org/39724/
[02:57] <Joe_CoT> is that better than the other debdiff?
[02:58] <Joe_CoT> minghua ^ as well
[02:58] <persia> Joe_CoT: That's a much better changelog, although if you could keep the line length to < 80, it would be even better :)
[02:58] <Joe_CoT> ok, 1 sec. Same with the patch description, or is that ok?
[02:58] <Joe_CoT> how do I spit it. another "-" line?
[02:58] <Joe_CoT> *split
[02:58] <minghua> Joe_CoT: Also, I'm not sure mentioning a dpaste.com url in changelog is exactly a good idea...
[02:58] <persia> The patch description is seen by fewer people, so it's more OK, but if you don't mind...
[02:59] <Joe_CoT> minghua: i have no other method of showing it. that's what the dev gave me on irc. i could just not include it
[02:59] <crimsun> minghua: upload is blocked on one approval from an ~motu-uvf member; the approval can be via any medium (SMS, IRC, e-mail, yadda)
[02:59] <persia> Joe_CoT: You don't need a new "-".  Just wrap it, and indent inside the previous "-".
[02:59] <minghua> Joe_CoT: Just say it's from upstream would be good enough.  This is not a court. :-)
[02:59] <Joe_CoT> ok. give me just a se
[02:59] <Joe_CoT> *sec
[03:00] <minghua> crimsun: Thanks.
[03:00] <minghua> Joe_CoT: yeah, remove the leading "-", and just put (LP: #nnnnn) at the end.
[03:01] <Joe_CoT> minghua: ? sorta confused what you mean
[03:02] <Joe_CoT> i also gotta go really soon, so if you explain, i'll upload the diff and be walking out the door :)
[03:05] <minghua> Joe_CoT: http://paste.ubuntu-nl.org/39725/
[03:05] <minghua> Joe_CoT: That's how I would write it.
[03:05] <Joe_CoT> ok, well i gotta go. I'll look later. bye!
[03:12] <minghua> Hmm.  Joey Hess wrote a patch to make dpkg understand git.
[04:07] <bddebian> Heya
[04:32] <bluefoxicy> I don't believe I like the virtualbox OSE package.
[04:32] <bluefoxicy> it rolls in an SDK (i.e. a -dev package)
[04:33] <bluefoxicy> the lack of a proper kernel module package (only source) also is irksome but.
[04:53] <TheMuso> Youch. The ATI driver upload FTBFS.
[04:54] <StevenK> Yay. Let's beat up Bryce.
[04:55] <bddebian> heh
[04:55] <TheMuso> Actually it was tepsipakki who uploaded it. :)
[04:57] <StevenK> Let's beat up Bryce anyway
[04:58] <bddebian> Wow, tough crowd :-)
[05:24] <ScottK> Well I guess I should have read the scrollback before I posted to ubuntu-devel....
[05:30] <minghua> ScottK: It's okay.  Since the idea is people would ask the motu-uvf team before uploading anyway, and you are likely the only one who still don't know the exact freeze rules, I'd say all is good. :-)
[05:31] <ScottK> This is still different than I remember Feisty being, but I was still pretty new then.
[05:39] <ScottK> minghua: Well I used the wrong e-mail address to post it and so it got moderated and I could kill it.
[05:40] <Hobbsee> ScottK: to where?
[05:41] <ScottK> Hobbsee: I responded to the freeze anounement message on ubuntu-devel before I read the scrollback here.
[05:41] <ScottK> Universe is still slushy, not entirely frozen.
[05:41] <Hobbsee> ScottK: did you kill it?
[05:41] <Hobbsee> or is it still there?
[05:41] <minghua> Aha.  So I guessed what ScottK's mail is about without seeing it. :-)
[05:41] <ScottK> I did (kill my mesage.)
[05:41] <Hobbsee> oh right
[05:41] <Hobbsee> ScottK: i have mod powers for that list, btw
[05:41] <ScottK> OK.
[05:42] <Fujitsu> We're fairly slushy until "<release> is so frozen you wouldn't believe" freeze.
[05:42] <ScottK> Normally when I screw up and send with the wrong address, I just kill it and resend.
[05:42] <Hobbsee> yeah, same here
[05:42] <ScottK> Fujitsu: Yes, which isn't what the RM mailing said.
[05:42] <Hobbsee> yeah, but whether steve thinks of universe is an interesting questoin
[05:45] <bddebian> Anyone know what "!C menu-2" in a menu file means?
[05:51] <TheMuso> 3/c
[05:51] <TheMuso> ugh
[05:51] <bddebian> ScottK: I've really avoided that whole thread.. :-)
[05:52] <ScottK> bddebian: Don't worry.  The LP devs appear to understand how we do stuff better than we do and will make LP wonderful for us.

[06:01] <bddebian> Ah, thx persia
[06:15] <YokoZar1> Akk, does the archive freeze mean I can't upload my new Wine package?
[06:15] <YokoZar1> Or is that just for non universe?
[06:17] <persia> YokoZar1: It means that any upload should have a good reason, and will require manual approval from the release administrators.  You'll want to get approval from someone in motu-uvf before uploading (I think).
[06:17] <YokoZar1> Already have it :)
[06:21] <ScottK> YokoZar1: I'd say lets give it a shot.
[06:22] <YokoZar1> ScottK: Thanks.  This week has been really busy.  Also it took me literally all day to fetch/rebuild the ia32-libs package now (which I'm about to upload to REVU)
[06:22] <slangasek> ScottK: right, the mailing didn't mention universe explicitly at all, because the notes I was working from didn't either; I don't have a problem with anything that the MOTU think is best for handling universe at this stage
[06:22] <slangasek> so feel free to take my comments as only applying to main
[06:22] <YokoZar1> ty slangasek
[07:07] <bryce> ScottK: doh!
[07:07] <bryce> ScottK: well of course we see 15 min after tepsipakki's upload, upstream released a new -ati :-P
[07:08] <StevenK> Hah
[07:08] <StevenK> bryce: "Correct bozo idiot error" ? :-)
[07:09] <bryce> a CBIE, yes
[07:09] <bryce> actually we knew alex would be doing a new -ati release "some time this weekend", we just didn't know it'd be Friday afternoon ;-)
[07:10] <StevenK> I can't expand out CBIE. Can't Believe I <something>, right?
[07:10] <bryce> why, "Correct Bozo Idiot Error" of course
[07:11] <StevenK> Ahhh
[07:22] <Hobbsee> hiya bryce
[07:29] <ScottK> slangasek: Thanks.
[07:29] <ScottK> bryce: ScottK/StevenK
[07:37] <bryce> ScottK: whoops.  I guess you SmumbleK's look much the same ;-)
[07:37] <ScottK> bryce: No trouble.  Happens all the time.
[07:38] <ScottK> In real life when someone gets my name wrong it's almost always Steve for some reason I don't understand, so it's not just tab completion.
[07:40] <StevenK> And people usually hear my name as 'Dave' on the phone. It's odd.
[07:40] <tonyyarusso> People think I'm my mom on the phone
[07:41] <StevenK> Er, bites
[07:41] <superm1> bryce, you still here?
[07:41] <bryce> yup
[07:42] <StevenK> ScottK: ^U is your friend
[07:42] <persia> Hmmm..  sbuild 0.56 is still broken for me.  Does it work for anyone else?
[07:42] <superm1> bryce, can you comment to how recent of a i810 driver we have: whether this patch discussed here will be necessary http://mythtv.org/wiki/index.php/Installing_MythTV_on_an_Intel_Mac_Mini_using_Ubuntu#Viewing_HD_Material
[07:42] <ScottK> StevenK: Sure, but I actually thought better instead of just pretending to this time.
[07:43] <ScottK> tonyyarusso: Did we backport Kompozer to Feisty yet?
[07:43] <tonyyarusso> ScottK: No, I've been distracted.
[07:43] <ScottK> It's probably a good time for it...
[07:43] <tonyyarusso> yeah
[07:43] <tonyyarusso> remind me of the process?
[07:44] <ScottK> !backports | tonyyarusso
[07:44] <ubotu> tonyyarusso: If new updated Ubuntu packages are built for an application, then they go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
[07:44] <bryce> superm1: yeah lemme look
[07:45] <ScottK> Nixternal's an hour west of me and he just said he was going to bed (on #kubuntu-devel).  I guess I better too.
[07:45] <ScottK> Good night all.
[07:45] <slangasek> pff, sleep
[07:45] <bryce> night St...ScottK
[07:45] <slangasek> night, ScottK
[07:45] <bryce> superm1: ok here's the skinny
[07:46] <bryce> superm1: i810 is deprecated.  Upstream in xorg they alias i810 to "intel" starting with version 2.0
[07:46] <tonyyarusso> ScottK: Should I file one bug affecting feisty, edgy, dapper, or separate ones for all, or just bother with feisty since the others have nvu?
[07:46] <bryce> for Ubuntu, rather than use the alias, we held back i810 to version 1.7.4
[07:46] <bryce> as far as I know, there is no "newer" version than that, as development on that driver ceased when intel took over
[07:47] <bryce> however because the driver is aliased on some platforms, there is a risk that when people say "new i810" they could mean "intel"
[07:47] <superm1> bryce, oh interesting.
[07:48] <bryce> the linked-to instructions however do seem appropriate to our i810 (references to 915resolution, date on posts, et al)
[07:48] <bryce> as a general rule though, starting with Gutsy you should not need to worry about the i810 driver... encourage users of it to switch to intel
[07:50] <bryce> hrm, now why is it that when I specify "iface eth1 inet static" and give it a static address it keeps coming up with a dhcp-provided one... hrm
[07:50] <bryce> ironically, this is my mythtv box doing it.  ;-)
[07:51] <superm1> bryce, well the thing that sparked this was that a user had to switch to i810 on a mac mini
[07:51] <superm1> using gutsy
[07:52] <superm1> and pointed me at that, so i was a bit confused with regard to taht
[07:52] <bryce> ahh
[07:52] <superm1> they had said they couldn't get higher resolution otherwise
[07:52] <bryce> that sounds wonky
[07:53] <superm1> yeah that's what i thought.
[07:53] <bryce> well, as long as they know that i810 is not going to be supported and that they're more or less on their own with it...
[07:53] <bryce> while the intel driver does have its bugs, at least people will be working on it
[07:54] <superm1> the guy posted this in our thread for showing what hardware works and doesnt on mythbuntu.  i'll have him form a more complete thread and bring this discussion to him.
[07:54] <superm1> thanks bryce :)
[07:55] <bryce> sounds good, sure
[07:55] <superm1> bryce, oh and about openchrome.  i forgot to tell you before why i never filed the MIR.
[07:55] <superm1> there was finally a real release of it
[07:55] <superm1> and it uses a full out different driver name and all
[07:55] <bryce> wow
[07:55] <superm1> i considered doing the whole UVFe thing for it, but this late into the cycle i know its going to break some of the ubiquity stuff we have coded for mythbuntu
[07:56] <superm1> so i don't want to bother at this point
[07:56] <tonyyarusso> ScottK: Bug #149715 filed.
[07:56] <ubotu> Launchpad bug 149715 in feisty-backports "Please backport KompoZer 0.7.10" [Undecided,New]  https://launchpad.net/bugs/149715
[07:57] <superm1> bryce, here was the announce that i saw: http://mythtvnews.com/2007/09/20/first-openchrome-official-release-030/
[07:57] <superm1> so for hardy i'll package that up
[07:57] <superm1> and then get the mir made for it
[07:57] <bryce> superm1: put it on your todo list to remind me once hardy starts, and we'll get it in, and make the decision about making it the default for the appropriate hardware
[07:58] <superm1> bryce, do you want to discuss it at uds perhaps?
[07:58] <bryce> sure
[07:58] <superm1> or not worthy of a sprint really?
[07:58] <bryce> probably not worthy of having a session, but maybe we can just chat about it over a beer or something
[08:00] <superm1> okay sounds good
[08:05] <bryce> superm1: hey I have a question for you
[08:05] <bryce> superm1: on my mythtv box, navigation in the menus is quite slow
[08:05] <bryce> this is a pretty powerful amd box with tons of memory and such, so its a bit weird
[08:06] <bryce> it plays video fine, and outside mythtv its quite speedy and snappy
[08:08] <bryce> I have a new but pretty cheap video card (nvidia G72 geforce 7300 LE), which I'm suspicious of, and I'm wondering if swapping that out with a different card might matter, or if this is something you already are aware of?
[08:09] <superm1> bryce, what card do you have in there right now?
[08:09] <superm1> its the nvidia?
[08:10] <bryce> yes
[08:10] <superm1> you have the proprietary driver activated?
[08:10] <bryce> nope, running -nv
[08:10] <superm1> if you can install the proprietary driver, it improves performance immensely
[08:10] <bryce> ok cool
[08:10] <superm1> and lets you turn on the opengl accelerated menu system
[08:11] <superm1> Settings->Appearance->Theme Painter after you install things.
[08:16] <pwnguin> just what is it doing that openGL fixes?
[08:22] <pkern> So this means that universe is frozen too?
[08:24] <persia> pkern: Essentially, although the threshold is smaller.
[08:24] <persia> Hobbsee: I thought we were looking for motu-uvf nods before uploading.
[08:25] <Fujitsu> persia: Not until the last week, IIRC.
[08:25] <TheMuso> Hobbsee: The rest of universe?
[08:25] <Hobbsee> persia: for new package exceptions, uvfe's.
[08:25] <Fujitsu> TheMuso: That's what I thought...
[08:25] <persia> Fujitsu: Ah.  My misunderstanding then.  I thought we were pushing it a week earlier this time.
[08:25] <StevenK> Not until hard freeze.
[08:25] <StevenK> Which will be after RC
[08:25] <Hobbsee> TheMuso: the rules havent changed since last release.
[08:26] <persia> Also, uploads to get manually approved, so it's at least slushy, if not frozen.
[08:26] <TheMuso> Hobbsee: But you said the resto of universe in the topic.
[08:26] <slangasek> TheMuso: the universe is all that is or ever was or ever will be
[08:26] <Hobbsee> TheMuso: there you go
[08:26] <slangasek> therefore, main is also part of the universe
[08:26] <Fujitsu> What part of universe is frozen, Hobbsee?
[08:26] <Hobbsee> slangasek: not for upload rights.
[08:26] <slangasek> insignificant details on a cosmological scale
[08:27] <Hobbsee> Fujitsu: nothing has changed since last week.
[08:27] <Fujitsu> Hobbsee: What? I am confused. Is there a part of universe that *is* frozen?
[08:27] <Hobbsee> Fujitsu: therefore if you want a feature freeze exception, uvf exception, etc, you can still get them, but bugfix releases are fine, as per the new policy
[08:28] <Hobbsee> Fujitsu: if you upload something with a bunch of new features, without an exception, yes, you'll still get killed.
[08:28] <persia> I don't see the diff in the last change.
[08:28] <Fujitsu> Oh, like that, I see.
[08:28] <Hobbsee> persia:  | --> -
[08:28] <Hobbsee> Fujitsu: like i say, same as the last few weeks.
[08:28] <persia> Hobbsee: Thanks.
[09:52] <YokoZar1> Are svg or png files better for icons?
[09:56] <persia> YokoZar1: svg usually looks nicer, but both work.
[09:57] <YokoZar1> I have both sent to me, so I guess i'll use the svg
[09:57] <persia> YokoZar1: If you have both, you may as well install both, and just not pass the extension: that way the environment can select the best.
[09:57] <YokoZar1> oh, good point
[09:57] <YokoZar1> didn't realize it didn't need an extension
[09:58] <persia> YokoZar1: Depends on the context.  If you're using a library pixbuf loading routine, it should auto-select.  If you're actually loading the file, you need the extension.
[09:58] <YokoZar1> persia: these are going into .desktop files
[09:59] <YokoZar1> persia: i have wine.png and wine.svg, I'm assuming I can just put Icon=wine into the .desktop file and copy both to /usr/share/pixmaps?
[09:59] <persia> YokoZar1: That's what I thought.  No extension.  No path.  Just drop it somewhere in the iconcache directories (I usually use /usr/share/pixmaps)
[09:59] <YokoZar1>  /usr/share/pixmaps is what the freedesktop.org spec calls for
[09:59] <persia> YokoZar1: Exactly.  That's best practice, because then someone could create wine.xpm as part of a theme, and override the default.
[10:01] <persia> Regarding the interleave: I thought the spec only indicated that path as preferred, and that menu systems were supposed to also search there, but that implementors could generate the icon cache in any desired manner.
[10:01] <YokoZar1> http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html
[10:02] <YokoZar1> err wrong link
[10:02] <YokoZar1> Icons and themes are looked for in a set of directories. By     default, apps should look in $HOME/.icons (for backwards compatibility),     in $XDG_DATA_DIRS/icons and in /usr/share/pixmaps (in that order).     Applications may further add     their own icon directories to this list, and users may extend or     change the list (in application/desktop specific ways)
[10:02] <persia> http://standards.freedesktop.org/menu-spec/menu-spec-latest.html
[10:03] <persia> Right.  /usr/share/pixmaps is required to be one of the source directories when building the icon cache, but there may be others (and are in Ubuntu).
[10:04] <YokoZar1> persia: ahh.  So, another question regarding the menu
[10:04] <YokoZar1> Wine adds its own menu entry (Applications->Wine)
[10:04] <persia> YokoZar1: It's my favorite type of question to answer :)
[10:04] <YokoZar1> I'd like to put some of the Wine bundled apps (eg notepad) into there
[10:05] <YokoZar1> But Wine doesn't generate that submenu until a user runs Wine once
[10:05] <persia> YokoZar1: Is intended as a user menu, or a system-wide menu?
[10:06] <YokoZar1> So Wine has your user apps (say, stuff you install into ~/.wine) as a user menu, but I guess I'd like to create a Wine system-wide menu to shove some wine-specific things into (eg, regedit and winecfg)
[10:06] <YokoZar1> It's kinda weird having them elsewhere (say, in System->Preferences)
[10:07] <persia> YokoZar1: Hmmm..  I'm not deeply familiar enough to understand how user menus and system menus are merged, but I suspect you'll want to play with installing something to /etx/xdg/menus
[10:08] <persia> s/etx/etc
[10:09] <YokoZar1> Do you know where Wine would copy its user level one so I can use that as a template?
[10:11] <YokoZar1> ahh, nevermind.  It appears Wine copies stuff into ~/.config/menus/applications-merged
[10:11] <persia> YokoZar1: If it was a pure system menu, I think you'd put an entry in /etc/xdg/desktop-directories/, but for a merged menu, you might need to do something special (check http://standards.freedesktop.org/menu-spec/menu-spec-latest.html, and the source for gnome-menus for ideas.
[10:12] <persia> YokoZar1: That's roughly comparable to /etc/xdg/menus/applications-merged, but the tricky part is making sure any new local ($HOME) entries show up properly in a system menu (something I've not tested)
[10:14] <YokoZar1> so I don't have a /etc/xdg/desktop-directories/ folder
[10:15] <YokoZar1> I'm guessing I should tell the package to make a folder /etc/xdg/applications-merged/ and then put a wine.menu there yes?
[10:17] <persia> YokoZar1: I'd probably try using applications-merged first (as that's what the local setting does).  This should reduce the other effort needed to get everything to work.
[10:26] <YokoZar1> persia: so it looks like <Directory> entries can refer to nonexistant .directory files
[10:26] <YokoZar1> in the case of, say, no localization
[10:28] <persia> YokoZar1: That's my understanding.  I believe that non-existent files are not rendered, but you'll want to check one of the implementations to verify.
[10:28] <YokoZar1> persia: so it looks like my best bet is to make a category for Wine
[10:30] <persia> YokoZar1: I don't recommend making such a change for gutsy - it's possibly intrusive UI-wise (and we're in FeatureFreeze and UIFreeze).  More generally, you'll probably want to get in touch with the -desktop team to discuss it: there are a few people with strong opinions about how the menus should be displayed.
[10:30] <YokoZar1> yeah
[10:30] <YokoZar1> The thing is
[10:30] <YokoZar1> Wine already displays its own subtree
[10:30] <persia> YokoZar1: Technically speaking, a category is probably the easiest way to make it look nice.
[10:30] <YokoZar1> I could just manually refer to each wine.desktop file
[10:31] <persia> YokoZar1: In that case, if you can get something working with /etc/xdg that looks the same, it should be cleaner, overall.
[10:33] <YokoZar1> like a wine.menu file to go in /etc/xdg/applications-merged/
[10:33] <persia> YokoZar1: Right.
[10:35] <YokoZar1> if I have a higher menu include category wine, and a lower menu include category wine and category accessories, will it put it in both places or just the latter?
[10:36] <persia> YokoZar1: If the menus are hierarchical, I believe just the latter.  If they are parallel branches in the tree, I believe both.
[10:54] <YokoZar1> persia: what if I want to add something to places?
[10:55] <persia> YokoZar1: You're getting more advanced than my knowledge.  I know that two menu categories in parallel trees generates two entries, but I'm not sure about hierarchy.  I suggest trying it and seeing what happens, or looking at the details of the implementation.
[10:56] <YokoZar1> persia: I meant a more basic question: how do I add something to places (ie, what category)
[10:57] <persia> YokoZar1: That's controlled by the <Include> directives in the .menu file
[10:57] <YokoZar1> I'm looking for the right .menu file though
[10:57] <YokoZar1> in /etc/xdg
[10:59] <persia> YokoZar1: ggzcore-bin installs /etc/xdg/menus/applications-megred/ggz.merge.menu, which may be a good example.
[11:00] <YokoZar1> thank you, I'll look at that
[11:29] <pochu> StevenK, zul: mind looking at bug 144258? ScottK already ACKed it.
[11:29] <ubotu> Launchpad bug 144258 in scribes "[UVFe]  Please sync scribes (universe) 0.3.2.9-1 from Debian Unstable (main)" [Medium,New]  https://launchpad.net/bugs/144258
[11:31] <pkern>  The result is a text editor that provides a fluid user experience.
[11:31] <pkern>  An editor that is easy and fun to use. And an editor that ensures the
[11:31] <pkern>  safety of your documents at all times.
[11:31] <pkern> That overeggs the pudding (thanks dict.leo.org).
[11:44] <persia> When a patch is dropped, recreating a bug, it is better to reopen the original bug, or open a new bug?
[11:45] <sladen> persia: technically probably to re-open;  however realistically, I would re-file, and link to the previous report
[11:45] <sladen> persia: what got dropped?
[11:46] <persia> sladen: bug #5362.  The argument for reopening is that the same fix works.  The argument for a new bug is that the original reporter might not care.  Perhaps I'll just reference the old bug in the changelog...
[11:46] <ubotu> Launchpad bug 5362 in torcs "Torcs crashed (because it has no sound?)" [Medium,Fix released]  https://launchpad.net/bugs/5362
[11:53] <norsetto> hyall
[12:05] <white> if anyone feels like testing a new version for nagios-plugins (I am interested in the check_http plugin), please do so and give some feedback :)
[12:05] <white> http://developer.skolelinux.no/~white/debs/security/sid/nagios-plugins/
[12:05] <white> it is mainly important that the check_http plugin still works as before
[12:16] <Fujitsu> white: What's the change?
[12:20] <white> Fujitsu: mainly a patch for http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5198
[12:20] <ubotu> Buffer overflow in the redir function in check_http.c in Nagios Plugins before 1.4.10 allows remote web servers to execute arbitrary code via long Location header responses (redirects). (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5198)
[12:21] <white> Fujitsu: feel encouraged to be my tester :)
[01:07] <pkern> ScottK: You don't like bzr? ;)
[01:15] <RAOF> I'd like some comments about bug #147587 - on one hand, miro doesn't actually require libxine1-ffmpeg, but most of the default feeds do.
[01:15] <ubotu> Launchpad bug 147587 in ubuntu "grub menu.lst update in gutsy make lvm unbootable" [Undecided,New]  https://launchpad.net/bugs/147587
[01:15] <RAOF> Ahem.
[01:15] <RAOF> bug #147589
[01:15] <ubotu> Launchpad bug 147589 in miro "Miro fails to play films when using default renderer (gstreamer works OK)" [Medium,Incomplete]  https://launchpad.net/bugs/147589
[01:16] <TheMuso> Evening folks.
[01:16] <RAOF> Evenin' TheMuso!
[01:17] <persia> RAOF: I'd leave it as is: let restricted-formats handle that (which does depend on -ffmpeg)
[01:18] <persia> Umm..  Rather libxine-extracodecs
[01:18] <RAOF> persia: You mean *buntu-restricted-extras?  I don't think that's in ubuntu-r-e (but it is in x- & k-)
[01:19] <persia> RAOF: Right.  In Ubutnu, one must manually install libxine-extracodecs.
[01:20] <RAOF> Which seems to no longer exist, but never mind :)
[01:20] <persia> Ah.  It's stuck in a mirror.  Sorry then.  Ignore everything I've said.
[01:21] <RAOF> Heh.
[01:21] <RAOF> Well, I'm inclined to leave the dependencies as they are.  Miro already Recommends -ffmpeg.  I just want some 2nd opinions.
[01:23] <rexbron> persia: Hello, I packaged genpo (it is in the ubuntu studio PPA). Care to give it a peruse?
[01:23] <RAOF> Woah, while I'm at miro - bug #149736.  We can't stop people running probably broken programs while their system is being updated, right?
[01:23] <ubotu> Bug 149736 on http://launchpad.net/bugs/149736 is private
[01:24] <persia> rexbron: I took a quick look a couple days ago, and it seemed sane (as opposed to the previous lack of licensing for the organ definitions).  I'll add it to my list, but I won't be sponsoring any new packages for gutsy.
[01:24] <persia> RAOF: That's PEBKAC.
[01:24] <rexbron> persia: I was looking at this package in the hardy time frame from the outset. Personally, I was suprised I finnished it so quickly.
[01:25] <RAOF> persia: Not entirely, but yeah.
[01:25] <persia> rexbron: Perfect then :)  If you don't mind the wait, I'll take a closer look once I've cleared up the remaining two or three annoyances I have with gutsy.
[01:25] <rexbron> persia: if you have time, I would apprecate any testing you could throw at it.
[01:26] <rexbron> persia: have fun. :)
[01:27] <persia> RAOF: I guess.  More generally, if it started before the upgrade, it shouldn't be an issue.  Checking for an apt-lock, and checking depdencies for upgrading status when launching a program sounds like a general wrapper :)
[01:27] <persia> rexbron: Sure.  I've only two devices, but I'm excited about the idea of getting pedals working.
[01:28] <RAOF> persia: So I'll file a wishlist "should provide a wrapper for all programs so they don't get run in an inconsistent state" bug against dpkg :D
[01:28] <rexbron> persia: Seeing as I lack the appropreate hardware, that would be valuable information. :)
[01:28] <persia> RAOF: :)
[01:30] <persia> rexbron: vkeybd and qmidicontrol should be able to simulate most of it (although it's hard to do things simultaneously).
[01:35] <persia> I'm chasing an x86_MMX bug.  OpenAL seems to crash under certain circumstances on AMD64, when linked against the provided i386 MMX arch-specific libraries.  There are some configure checks to make sure only a subset of the i386 MMX libraries are included.  Is this ever safe, or should I be seeking a comparison of the i386 and x86_64 MMX instruction sets?
[01:36] <StevenK> persia: If it's only MMX, and not something like SSE{,2}, both i386 and x86_64 should be able to handle it.
[01:37] <persia> StevenK: Ah.  I was afraid of that.  I guess I'll have to learn some more rather than just disabling MMX.
[01:37] <RAOF> StevenK, persia: Maybe alignment issues?
[01:37] <pkern> Unexpectedly non-broken dependency apache2-mpm-itk 2.2.3-04-3build3 -> {apache2.2-common 2.2.4-3}!
[01:37] <pkern> Yay. /me goes removing apache2...
[01:39] <persia> RAOF: It sounds impressive, but it's really just looking at the beginning of a stack trace, and noticing it's calling something in .../arch/i386/ on a AMD64.
[01:39] <pkern> Haha. And removing apache2.2-common suggests me to install mzscheme (after suggesting webfs).
[01:39] <RAOF> persia: Awww. :)
[01:47] <RAOF> Hey bigon!  Good timing, I'm just about off to bed :)
[01:48] <LongPointyStick> RAOF: bed?  but it's time for dinner!
[01:48] <RAOF> LongPointyStick: Not if you wake up at 6am
[01:49] <bigon> RAOF: hi :)
[01:49] <RAOF> bigon: At some point you'll throw up a bzr branch of libgnome-keyring-cil, I suppose?
[01:51] <LongPointyStick> RAOF: ew.
[01:51] <LongPointyStick> RAOF: whatever did you do that for?  oh, motu meeting?
[01:52] <RAOF> No.  Because that's when I woke up.  Darn sunlight!
[01:52] <bigon> RAOF: done, http://router.bigon.be/bzr/gnome-keyring-sharp
[01:53] <bigon> RAOF: mmm wait,  http://router.bigon.be/~bigon/bzr/gnome-keyring-sharp/
[01:53] <RAOF> :)
[01:53] <RAOF> Not on LP?
[01:55] <bigon> RAOF: I will upload it there, but now I'm going to eat
[01:55] <persia> Found it.  Adding 4 to a pointer is bad :)
[01:55] <RAOF> bigon: And I'm off to sleep :)
[01:56] <RAOF> persia: Of course!
[01:56] <pochu> LongPointyStick: mind looking at bug 144258?
[01:56] <ubotu> Launchpad bug 144258 in scribes "[UVFe]  Please sync scribes (universe) 0.3.2.9-1 from Debian Unstable (main)" [Medium,New]  https://launchpad.net/bugs/144258
[02:01] <rexbron> persia: so you found one of the bugs?
[02:02] <persia> rexbron: I found a bug in torcs which was a bug in openal, if that's what you mean.
[02:02] <rexbron> persia: patching time?
[02:03] <persia> rexbron: Eventually.  I still need to learn MMX, and tune the assembly...
[02:03] <rexbron> persia: thats hardcore
[02:17] <bigon> RAOF: uploaded to the LP
[02:46] <bddebian> Heya gang
[02:54] <norsetto> heya bddebian
[02:56] <bddebian> Hi norsetto
[03:34] <_polto_> hello
[03:35] <jsomers> the package visudo has a manpage bug, open since april and fixed upstream in april, how come it has not been fixed in gutsy?
[03:35] <jsomers> I can't image that the package source has not been fetched from the upstream cvs since
[03:35] <_polto_> Fujitsu, sorry but did you had some time to investigate and why not apply our patch for mplayer ?
[03:46] <minghua> jsomers: What is the bug number?
[03:48] <joejaxx> Hello Everyone :)
[03:48] <bddebian> Heya joejaxx
[03:49] <minghua> jsomers: If you are talking about bug #105877, it was only fixed in Debian on Sept. 5th.
[03:49] <ubotu> Launchpad bug 105877 in sudo "visudo manpage typo" [Undecided,Confirmed]  https://launchpad.net/bugs/105877
[03:49] <jsomers> ah, yes
[03:50] <minghua> jsomers: And nobody came and ask us to get this fix from Debian, so basically nobody was aware of the fix.
[03:50] <jsomers> ah, so packages are always coming from debian?
[03:51] <minghua> jsomers: Yes, most came from Debian originally.  We do some changes ourselves, but we constantly sync new versions and bug fixes from Debian as well.
[03:52] <minghua> jsomers: In this case, if will certainly be fixed in the next cycle (hardy, 8.04), because we'll sync from Debian again.
[03:52] <jsomers> ok then
[03:52] <jsomers> I was just wondering, since it has been a while
[04:24] <pochu> wow, this Virtual Box really looks great! But what a pity it isn't GTK...
[05:00] <ScottK> pkern: bzr is neither good nor bad IMO.  It's just that it's one more VCS on top of CVS, SVN, and Git that I already have to deal with.
[05:01] <ScottK> From my perspective it's and Ubuntu specific tool with a non-trivial learning curve that I don't have time for.  I know others use it, but Ubuntu is the only place I've run into it.
[05:04] <broonie> To be fair, one of the reasons I bother with bzr at all is that the learning curve for basic usage is pretty trivial.
[05:05] <broonie> I got a comment at a job interview recently along the lines of "wow, you're the first person I've met who's actually used bzr"
[05:05] <ScottK> broonie: True.  And I have used it a bit for some Kubuntu stuff.
[05:05] <ScottK> Heh.
[05:06] <ScottK> I object to it as part of MOTU new package review processes because it's more complexity for me as a reviewer.
[05:06] <ScottK> Dput the package to REVU, I dget the package, and then give comments is simple and works well.
[05:10] <minghua> I think i like bzr better than git.  At least I can "bzr checkout" and "bzr update" if I only want to peek into the repository.
[05:11] <broonie> minghua: That works just as well with git IME?
[05:12] <minghua> It's true not many people outside of Ubuntu uses bzr though.
[05:12] <minghua> broonie: Really?  Then why can't I find a new user guide saying so...
[05:12] <minghua> It almost always start with "git clone".
[05:13] <broonie> Oh, you're very bandwidth constrained?
[05:14] <minghua> No I am not.  It's just that I never see a tutorial mentioning that simple "git checkout" and "git update" would work.
[05:15] <minghua> It's always clone, pull, commit and stuff.
[05:15] <minghua> My situation is pretty special because I deal with these repos mostly for translation work.
[05:15] <ScottK> minghua: The point from my perspective is that I never get to pick the tool.  The project I work on that uses Git, I didn't pick it.  I've only got room for some many VCS in my head (the limit seems to be slightly less than one in my case so it's a real PITA).
[05:16] <norsetto> lol
[05:16] <broonie> The equivalent of a checkout, update workflow is clone, pull.
[05:16] <minghua> And I don't really care about distributed VCS or creating my own branch, I just want to checkout the HEAD and then send a patch.
[05:17] <minghua> ScottK: I completely agree, I'm in a similar situation.
[05:18] <minghua> Actually I ran into a mercurial repo a few days ago as well, and decided not to bother.
[05:58] <AstralJava> Sorry to bug you guys, but could anyone from motu-uvf take a look at bug #149606, it's a FreezeException bug for python-gammu, a dependency of wammu, the phone sync app. Would be greatly appreciated! Thanks. :)
[05:58] <ubotu> Launchpad bug 149606 in python-gammu "FreezeException for python-gammu 0.22-2" [Undecided,Invalid]  https://launchpad.net/bugs/149606
[06:04] <pkern> ScottK: Actually bzr hasn't got in my way yet, in conjunction with bzr-builddeb. I knew darcs and getting used to bzr *with LP* was easy. I disagree on the learning curve, especially as I found git just weird (but that's probably related to the fact that I tried git-core in Debian etch).
[06:05] <pkern> asac: I thought I already saw granparadiso in Gutsy, but looking at LP it only built yesterday and is in NEW?
[06:08] <ScottK> pkern: My thing about new package reviews and bzr is that we already have a nicely functioning process without it.  I tend to be against changing stuff to make it harder even if it's only a little bit.  Totally agree on Git being weird.
[06:09] <pkern> ScottK: Did you read of Joey Hess's efforts on having git source packages? ;)
[06:10] <pkern> [asterix]  ~ > firefox-3.0
[06:10] <pkern> [: 32: /home/pkern/.mozilla/firefox: unexpected operator
[06:10] <pkern> A pleasant experience. :D
[06:11] <pkern> asac: line 32 in /usr/bin/firefox-3.0 in 3.0~alpha8-0ubuntu1~mt has a weird character.
[06:11] <ScottK> pkern: No.  I know lamont is doing with Postfix, but haven't looked at it in detail.  Is there a pointer you can give me towards something to read?
[06:11] <pkern> ScottK: Yep, hold on.
[06:11] <pkern> ScottK: http://wiki.debian.org/GitSrc
[06:12] <pkern> ScottK: That's *very* new and nothing has been decided upon. (I guess the wiki entry was created today or yesterday.)
[06:13] <pkern> asac: And a missing dup on xulrunner-3.0
[06:13] <pkern> asac: s/3.0/1.9/
[06:17] <ScottK> pkern: Thanks.  Interesting.  I see some parallels there with my kvetching about bzr and LP.
[06:18] <pkern> ScottK: Especially the "git.d.o build queue" thing.
[06:19] <lamont> ScottK: git is love. do not deny the git. :-)
[06:20] <lamont> ScottK: all my packages are in git now
[06:21] <lamont> util-linux included
[06:21] <lamont> I don't see any reason to have the git repo in the tar.gz, given that I can use debian-control to point any dpkg-source -x users at the git repo on the net
[06:21] <ScottK> Personally, I see the advantages of a VCS, but I'm concerned that it dilutes the notion that the actual repository is the canonical (pun intended) source for the distro.
[06:22] <ScottK> For Debian pakcages with one/few maintainers or a team that's agreed to use a VCS, it's fine.  I just don't think it scales to Ubuntu with team maintenance of literally thousands of packages.
[06:22] <bddebian> Amen brother :)
[06:23] <lamont> generally speaking, source is kept in a VCS somewhere, and the developer takes code from there and ships it.  So there is a canonical repository for the packager, which then becomes a collection of sources which form the canonical origin of a distro
[06:23] <minghua> ScottK: Joey's argument is that learning multiple VCS systems is not that different from learning multiple patch systems.
[06:24] <lamont> util I moved my packages to git, the VCS was local to my machine and not visible on the net.  -> suckage for others
[06:24] <lamont> minghua: and joeyh is right
[06:24] <ScottK> I agree and that's a PITA too.
[06:25] <minghua> lamont: Yes, I think that's valid argument.
[06:25] <lamont> I will admit that when I'm on a NMU-athon, that dbs packages tend to get pushed to the bottom of the queue unless the bug really, uh, bugs me.
[06:25] <ScottK> I still have to study man dpatch pretty hard every time I add dpatch to a package.
[06:25] <lamont> dpatch I've pretty well internalized.
[06:26] <lamont> I even used it in several of my packages, until I switched everything to git and killed dpatch as painful and no longer worth it, given a real VCS.
[06:26] <lamont> with cvs, dpatch is a savior.
[06:26] <ScottK> lamont: I've been doing Debian packaging less than a year now, so all this stuff is only shallowly etched in my brain so far.
[06:26] <lamont> then again, with cvs, a gun to the head is pretty close to salvation as well. :-)
[06:26] <pkern> I got so many comments about `why did you switch this particular package to quilt'. Heh.
[06:27] <lamont> "creating a new patch?  dpatch-edit-patch name $name-of-last-patch"
[06:27] <lamont> "editing an existing patch?  dpatch-edit-patch $name-of-patch"
[06:27] <ScottK> lamont: Which is a lifesaver.  I'd be doomed otherwise.
[06:27] <lamont> and then just dink around with 00list as needed
[06:27] <lamont> quilt?  yeah I hear that's "better" than dpatch.  I interpret it as "more complicated"
[06:27] <lamont> s/it/that/
[06:28] <ScottK> It's the adding dpatch to debian/rules for the first time that get's me confused.
[06:28] <bddebian> The games team seem to be moving everything to quilt :-(
[06:28] <lamont> ScottK: that's where I'd commit to git (or bzr), and do the patch inline.
[06:28] <lamont> bddebian: quilt is better.
[06:28] <pkern> You need a bloody bit of setup (i.e. setting an environment variable to point it to a Debian'ish location for the patches), but wandering through the patch stack is beautiful.
[06:29] <lamont> OTOH, dpatch, quilt, and the rest are just attempting to preserve the branch so that it can be rebased to a new upstream... that's what git or bzr are _FOR_
[06:30] <lamont> pkern: so is "gitk --all"
[06:30] <ScottK> Also though, with patches I can see what Debian's done to a package versus what upstream's done pretty easily.  Once it's all inline, it's harder to sort (I can't just apt-get source and look in debian/patches anymore).
[06:30] <lamont> ScottK: right. you have to go to the VGS
[06:30] <lamont> VCS even
[06:31] <lamont> which, if it's private, justifies dpatch/quilt.
[06:31] <lamont> if it's public, well.  tough.  go fetch.
[06:31] <ScottK> Go to the VCS = harder unless you are the maintainer who's got it handy.
[06:31] <lamont> apt-get source postfix on gutsy and read what it says...
[06:33] <lamont> hrmpf.
[06:33] <lamont> not postfix
[06:34] <ScottK> No, not postfix.
[06:36] <lamont> where did I see that...
[06:36] <pkern> apt? But that's bzr
[06:37] <minghua> Are we talking about the gutsy dpkg-source recognizing the various XS-VCS-* stuff?
[06:37] <lamont> apt 0.7.6ubuntu10:
[06:37] <lamont> NOTICE: 'alsa-oss' packaging is maintained in the 'Svn' version control system at:
[06:37] <lamont> svn://svn.debian.org/pkg-alsa/trunk/alsa-oss
[06:37] <pkern> Please use:
[06:37] <pkern> bzr get http://code.launchpad.net/~ubuntu-core-dev/apt/ubuntu
[06:37] <pkern> to retrieve the latest (possible unreleased) updates to the package.
[06:37] <pkern> *more helpful*
[06:37] <lamont> pkern: except for the s/possible/possibly/
[06:37] <lamont> tell me that's not in released code...
[06:38] <pkern> lamont: Of course it is. Aren't we in string freeze? :-P
[06:38] <lamont> pkern: string freeze is so we can translate the strings... I think that one needs to be translated to english. :-P
[06:38] <broonie> The dpatch UI for working on patches always strikes me as fairly painful due to the copying.
[06:39] <lamont> broonie: it used to not copy.  that was worse when it had patch failures.
[06:39] <broonie> Really, why?
[06:39] <pkern> quilt solves that one ;)
[06:39] <broonie> quilt deals with that pretty naturally, I find.
[06:39] <lamont> because then you have a broken tree, in some semi-random state in dpatch, not unpatchable (because of the rejects), etc.
[06:39] <minghua> lamont: Actually, adding an English translation is probably a better fix for now. :-)
[06:40] <ScottK> lamont: Poorly worded info note is still way better than the stop and ask are you sure you actually want the actual source package that you already said you wanted behavior that preceeded what we have now.
[06:40] <lamont> heh
[06:40] <lamont> anyway, in trouble now and leaving the house... my bad.
[06:40] <pkern> ScottK: Nice phrase.
[06:41] <ScottK> Well I'm still not over my reaction to that one the first time I hit it.
[07:52] <leonel> no debootstrap for gutsy on feisty ?
[07:52] <leonel> leonel@journey:~$ sudo debootstrap  gutsy gutsy-chroot
[07:52] <leonel> E: No such script: /usr/lib/debootstrap/scripts/gutsy
[07:54] <pkern> leonel:
[07:54] <pkern> (Bah.)
[07:54] <pkern> You could either copy the script from gutsy debootstrap or backport it altogether.
[07:55] <leonel> pkern: ok
[07:55] <pkern> There is a 1.0.1~feisty1 in feisty-backports
[07:55] <ScottK> leonel: There's one in feisty-backports that supports gutsy
[07:55] <ScottK> Yeah.  That one.
[07:55] <leonel> ScottK: thanks  found it  and  downloading
[07:55] <pkern> .oO( packages.u.c does not list files for *-backports? )
[07:56] <pkern> ScottK: Otherwise I would have suggested one. ;)
[07:56] <ScottK> pkern: You have to look in LP to get *-backports.
[07:56] <leonel> leonel@journey:~$ sudo debootstrap  gutsy gutsy-chroot
[07:56] <leonel> I: Retrieving Release
[07:56] <leonel>    <-- YES   Thank  you !
[07:56] <ScottK> They are technically a separate project.
[07:57] <pkern> ScottK: That wouldn't give me a file list neither. ;)
[07:57] <ScottK> Blessed by Ubuntu TB and supported by the Ubuntu archive, but not "Ubuntu".
[07:57] <pkern> Aye.
[07:57] <pkern> ScottK: It does list the version but shows "no information available" on the file list.
[07:57] <pkern> ScottK: (packages.u.c)
[07:57] <ScottK> Ah.
[07:59] <pkern> ScottK: http://packages.ubuntu.com/src:pkgname
[07:59] <pkern> It's not that the infrastructure isn't there. ;)
[07:59] <ScottK> Ah.  Hadn't noticed that.
[07:59] <ScottK> Thanks.
[08:00] <ScottK> I don't think that used to be there, but I also think lots of things that aren't true.  Who know.
[08:00] <ScottK> know/knos
[08:00] <ScottK> knos/knows even
[08:02] <pkern> ScottK: It's on packages.d.o since ages.
[08:02] <pkern> ScottK: Or did you mean *-backports?
[08:03] <ScottK> OK.  I meant the source package thing on p.u.c.
[08:03] <ScottK> p.d.o I use for source package info all the time.
[08:03] <pkern> The two sites share the codebase. ;)
[08:04] <pkern> Bah, it would be too hard for git to support `update', right? /me coughs.
[08:06] <ScottK> IIRC what happened is I once got burned trying to figure something out because p.u.c was lagging the archive and LP wasn't and so from then I tend to look in LP.
[08:06] <pkern> Yeah ok, it's lagging.
[08:06] <jeromeg> hello all
[08:06] <pkern> The script is called `bin/daily' so I guess it updates only once a day ;)
[08:06] <ScottK> Probably.
[08:06] <ScottK> hello jeromeg
[08:08] <jeromeg> who should i bother to fix bug 149763 ?
[08:08] <ubotu> Launchpad bug 149763 in vim "vim: packages missing in repository" [Undecided,Incomplete]  https://launchpad.net/bugs/149763
[08:08] <jeromeg> it's a problem with the dapper cz.archive.ubuntu.com
[08:09] <jeromeg> it seems to be incorrectly synced with the main one
[08:10] <ScottK> jeromeg: Not sure, but #canonical-sysadmin comes to mind as a possibility.
[08:10] <jeromeg> ScottK: ok thank you
[08:11] <jeromeg> ScottK: btw did you had some time to look at the gimmie backport request ? python-sexy is ok now
[08:11] <ScottK> jeromeg: I'll look now.
[08:12] <jeromeg> ScottK: thx
[08:22] <jeromeg> bye all
[08:26] <Kopfgeldjaeger> what do i have to specify in a .desktop file if i want a application to show up in the "Open with other application" "menu" ?
[08:29] <ScottK> Kopfgeldjaeger: If no one has specific suggestions, I'd suggest look here: http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec
[08:31] <pochu> Kopfgeldjaeger: I'm not sure, but maybe the mime information?
[08:32] <Kopfgeldjaeger> hum.. i already added MimeType=X (and the files are associated with the applications (all but flv files..)), but it does not show up in that menu
[08:46] <pochu> Kopfgeldjaeger: did you run dh_desktop?
[08:47] <Kopfgeldjaeger> pochu: er... no. i copy the files manually into */applications/*. what exactly does dh_desktop do?
[08:48] <pochu> It calls update-desktop-database, which I think updates the MimeType database...
[08:48] <pochu> so just run update-desktop-database
[09:32] <pkern_> Bloody Freenode.
[09:45] <xtknight> is there a good list of targets you can use in debian/rules?
[09:47] <pkern> You can use anything. :-P
[09:47] <pkern> xtknight: http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
[09:47] <pkern> get-orig-source (optional)
[09:47] <xtknight> pkern, i don't see "install" or "binary-install" here
[09:47] <pkern> This target fetches the most recent version of the original source package from a canonical archive site (via FTP or WWW, for example) [...] 
[09:47] <pkern> Haha.
[09:47] <pkern> xtknight: There isn't anything like install.
[09:48] <pkern> xtknight: It's called binary.
[09:48] <xtknight> pkern, e.g. "install/fluid::"
[09:48] <xtknight> maybe this is something w/ debhelper?
[09:48] <pkern> Maybe this is something w/ *dbs?
[09:48] <xtknight> not sure
[09:49] <xtknight> buildcore,autotools,debhelper.mk
[09:49] <xtknight> trying to make a patch for bug 139980
[09:49] <ubotu> Launchpad bug 139980 in fltk1.1 "fluid missing menu icon" [Undecided,New]  https://launchpad.net/bugs/139980
[09:49] <pkern> debhelper.mk... that sounds like *dbs. I don't know anything about that!
[09:49] <xtknight> and the archive admins would like it so that it only modifies debian/ for now
[09:55] <xtknight> i need to figure out how to modify what actually gets placed in the deb.  like i want to move a file within the deb, at the last second, somehow by using debian/rules
[09:55] <xtknight> under binary-install "mv debian/tmp/usr/share/applnk/Development/fluid.desktop debian/tmp/usr/share/applications" this didn't yield anything different in the final deb
[09:55] <xtknight> ahh here we go https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml#id2480675
[09:55] <xtknight> woohoo, you can actually modify a makefile too in rules
[09:55] <lamego> xtknight, are you using cdbs ?
[09:55] <xtknight> lamego, i think so.  i am using debhelper
[09:55] <xtknight> these rules on the page correspond with what i'm seeing in the rules file that i am modifying.
[09:55] <xtknight> for example they already have some binary-install stuff there to do various things
[09:55] <xtknight> well "install", "binary-predeb" rather
[09:56] <xtknight> i need to move a file at the last second.  the deb gets built and file "A" gets put in it.  well i need to move file "A"  to the correct location right before it spits a .deb file out.  i have to find the right rule to do this
[09:57] <xtknight> binary-predeb perhaps
[09:57] <ScottK2> xtknight: What's wrong with mv ...
[09:58] <lamego> if you are using debhelper you are not using cdbs :)
[09:58] <xtknight> ScottK, well nothing but i need to find where to put mv ;)
[09:58] <lamego> with cdbs that would go into install/package::
[10:01] <xtknight> ah well first i needed  a peak at debian/fluid.install
[10:02] <xtknight> peek *
[10:02] <lamego> that allows to copy, not to move
[10:02] <xtknight> right
[10:02] <xtknight> altlhough i was copying the wrong filename
[10:03] <xtknight> see when i changed applnk/Development to applications, i forgot to do it in fluid.install
[10:03] <xtknight> got it working now though
[10:03] <xtknight> i added my stuff to the install/fluid:: rule (move applnk/Development->applications in debian/tmp), and then in fluid.install i modified applnk/Development to applications and all is well
[11:32] <imbrandon> moins fellas
[11:35] <pochu> hey imbrandon, would you mind uploading liferea for me, if you have some time?
[11:36] <imbrandon> pochu: yea give me a few seconds and a url to grab
[11:38] <pochu> imbrandon: thanks, it's at http://emilio.pozuelo.org/~deb/liferea_1.4.4-0ubuntu1.dsc , and these are the changes to debian/ dir: http://emilio.pozuelo.org/~deb/liferea-debian.diff
[11:39] <imbrandon> pochu: kk, give me a few minutes and i'll look it over and upload it
[11:39] <imbrandon> i'll prod you when its done
[11:39] <pochu> Sure, thanks a lot :-)
[11:43] <pwnguin> im just gonna put this out there: packaging firefox adblock without a filterset is pretty useless
[11:55] <superm1> imbrandon, aren't we in a freeze right now though, are you allowed to upload to main?
[11:56] <pochu> superm1, imbrandon: slangasek approved it yesterday.
[11:57] <superm1> ah i see
[11:57] <superm1> universe is still okay to upload to though right?  just needs a prod from ~ubuntu-archive after its in
[11:57] <pochu> I think so.
[11:58] <superm1> any idea on the hard freeze date for universe then?
[11:58] <superm1> that we can't even do that
[11:58] <imbrandon> pochu: i dont see an "ok" in the changelog refrenced anywhere, got a url for me ?
[11:59] <pochu> imbrandon: an url for the approvation?
[11:59] <imbrandon> yes
[12:02] <pochu> imbrandon: http://people.ubuntu.com/~fabbione/irclogs/ubuntu-devel-current.html , 01:06
[12:03] <imbrandon> erm there isnt even a lp bug with it acked? i'm not sure whom slangasek is or if he has the authority to ack it or if it was actualy him on irc authenticated
[12:04] <imbrandon> pochu: ^
[12:04] <pkern> imbrandon: He has the authority.
[12:05] <pkern> imbrandon: He's RM.
[12:09] <pochu> imbrandon: I would say he was authenticated, since he has been online for ~ 3 days or so...
[12:09] <pochu> slangasek: pingaling :-)
[12:09] <imbrandon> pochu: i got it
[12:25] <pochu> imbrandon: I'm off to bed, thanks again :-)
[12:25] <pochu> Night all!