[00:03] it's been sitting here for like 20 minutes [00:03] I'm just gonna start over [00:04] alt-f something should give you a console, try killing something [00:08] ah hah [00:08] I had to kill debian-installer and start a new one up [00:11] now we're cookin' [00:11] jdong, any chance of backporting libgpod 0.6 to gutsy and building amarok against that? missing support for new ipods ッ [00:14] DarkMageZ: isn't that done already? [00:14] in the ipod-touch ppa? [00:14] oh. yay for ppa ッ [00:15] https://launchpad.net/~ipod-touch/+archive [00:15] there [00:16] tho realistically i think it should atleast be in backports so it's findable [00:26] persia: I will. [00:29] 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] for now I'd have to recommend the ipod-touch PPA too === Spec is now known as x-spec-t [02:20] * Hobbsee waves [02:22] Hey Hobbsee [02:23] Hey Hobbsee, persia. [02:23] What was this abount: " persia)) RAOF: How familiar do you need?" [02:24] * persia misses ubuntulog [02:24] persia: I looked in backscroll, but that didn't seem to help much :) [02:24] 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] Actually, yes. Now that I look at it. [02:25] Again. [02:25] oh yay, feature freeze should be done [02:25] I hate it when I don't make the deadlines :( [02:26] 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] 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] 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] persia: what are you feelings on getting a MOTU ack for NEW packages if it's just switching packaging? [02:28] persia: i'm on VAC. [02:28] I'm afraid no one is gonna wanna look at these packages [02:28] * Hobbsee has been on VAC since the 13th [02:28] 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] ok, so I'm redoing the squeak packages from Multiverse [02:29] they all have different names so they need to go through NEW [02:29] but it's just different packaging, not different sources [02:29] do I need a MOTU review? [02:29] LaserJock: Can you do it in such a way that it is binary NEW but not source NEW? [02:30] kinda [02:30] but that would defeat the purpose [02:30] I'm trying to sync up with "official" packages [02:30] but it's 5 new source packages :/ [02:30] Ah. We have odd orig.tar.gz files, and you're fixing that, but to do so you need new source packages? [02:31] well, the problem originates because Debian doesn't have it [02:31] i would have thought that source name changes shouldn't have to go thru again [02:31] that being siad, running a diff thru the entire source wouldn't be hard [02:31] we originally got the packages from some Spansih distro back in like hoary/breezy [02:32] or is it more than a name change? [02:32] oh, the crack...the crack... [02:32] 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] but there's actual a couple guys that maintain the official "unofficial" packages now [02:32] and our old packages were not the best [02:32] but they use a different naming scheme [02:33] well, the upgrade is totally screwed [02:33] I gotta figure out something [02:33] but I wanted to get something in the archive first [02:34] 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] hmmpf [02:34] well, I guess since I missed the deadline I might as well spend a couple more weeks working on upgradability [02:35] I'm just so sick of these packages [02:35] 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] yes [02:36] I'll kill of around 10 bugs [02:36] *off [02:36] and OLPC people want the packages [02:36] although I'm a little annoyed that OLPC is using this stuff since it's non-free [02:36] 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] there's nothing sane about squeak, but yeah [02:37] ;-) [02:37] yay, insanity! [02:37] Hobbsee: Since you're on VAC, I gather motu-release should get itself organized without waiting for you? [02:37] it took me several weeks to figure out the licensing [02:37] Ah. s/remained somewhat sane/fixed verifiable bugs/ then. Thinking about it, the aolserver4 mess wasn't actually sane either. [02:38] In a single directory there was a LICENSE, COPYING, and COPYRIGHT file [02:38] ScottK: i'm back on wednesday [02:38] and all 3 were different licenses [02:38] 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] Hobbsee: Did you read my proposal to the MOTU ML on bugfix only upstream releases? [02:39] ScottK2: i'm still sorting thru my *inbox*, let alone other mail. [02:39] squeak is an opposite case of java [02:40] the VM is GPL, but the language is non-free [02:40] or something like that [02:40] * Hobbsee is getting there... [02:40] Huh? How can a language be non-free? [02:40] Hobbsee: OK. I think that's the only potential point of discussion. I'd appreciate your feedback. [02:40] persia: well, not the language itself [02:40] I'm gonna confuse myself [02:41] but there's these images that you run on the VM [02:41] and those are non-free [02:41] LaserJock: Sounds like far too many Games packages. [02:42] yeah, probably [02:42] thing is, I don't have a clue about what this stuff is even for, and I don't really care [02:42] makes packaging not as fun [02:43] 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] Then why are you packaging it? [02:43] user demand [02:43] ScottK: Also, repackaging: we already have squeak [02:43] LaserJock: Users you particularly care about? [02:43] and I once wrote a zenity script to start the bloody thing from the menu and I became the "maintainer" [02:43] ScottK2: I guess [02:44] Ah. Touched it once and stuck with it forever. [02:44] a lot of edu people like it [02:44] yeah [02:44] Is it that much better than gnu-smalltalk? [02:44] in fact that's something that I have to deal with for the upgrade path [02:45] I wrote the script to do sane things [02:45] sent it upstream [02:45] but now they have a different script [02:45] which works [02:45] but works totally differently [02:45] persia: I haven't a clue [02:46] TheMuso: Are you still around? [02:46] 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] ScottK2: Yep. [02:47] Do we wanna go somewhere to have a chat? [02:47] TheMuso: I wanted to know what you thought about my proposal for bugfix only upstream releases? [02:47] Do we need to? [02:47] 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] fair enough [02:49] heh, Randal Schwartz has a bit on GNU smalltalk vs. squeak [02:50] he recommends not using GNU smalltalk because you can't contribute code to squeak [02:50] persia: Additionally, I prefer discussion in public rather than private when feasible. [02:50] nah its fine. [02:51] ScottK2, Hobbsee, how are both of you for a general exception for ubuntustudio-* packages? [02:51] LaserJock: In that case, best of luck with your effort :) [02:51] TheMuso: fine with it. they don't break anything else. [02:52] 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] ScottK2: so, write it. [02:52] I think we need a wiki page listing the bugs for the general wave throughs. [02:52] Hobbsee: If I cared about ubuntu-studio I would. [02:53] TheMuso: How about "flavour coordination packages maintained by the specific flavour team" rather than ubuntustudio-* [02:53] 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] persia: Yeah that sound sreasonable. [02:53] ScottK2: but you do care about having a list [02:53] Hobbsee: Yes. I'll make the list. [02:53] good. [02:54] * ScottK2 wants to put clamav on that list too. [02:54] fine. [02:54] just make sure you get the rdeps [02:54] Yeah. Hobbsee did you see I got clamav updated in Dapper (with all the rdpends)? [02:55] I'm pretty thoroughly familiar with the rdepends now. [02:55] 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] nice work! [02:55] persia: we have to have it. but, those interested in clamav might check it, sure [02:56] persia: It will need some consideration, but we've got a small team of people working clamav and rdepends now. [02:56] 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] persia: Also I've got a good working relationship with the Debian maintainer too. [02:56] 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] 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] So given what I'd already do for a clamav update, I don't think a motu-release ack will add much. [02:57] Hobbsee: one guaranteed ACK. One optional ACK. [02:57] persia: and the chances of anyone deciding to say "no, we don't want a security fix in our repos" is? === wolfger_ is now known as wolfger [02:58] 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] 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] persia: so you're suggesting starting to use 360 deg reviewing for all motu's - or at least for complex packages? [02:59] 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] persia: If it was really close to the relase, I'd definitely get second looks. [03:00] 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] If it's on the free pass list it doesn't matter if I'm on motu-release or not. [03:04] Ah. True. Maybe I'm arguing against putting complex packages with lots of rdepends on the free-pass list then. [03:04] (although you're all welcome to override me: there are reasons I didn't apply for the team) [03:05] persia: perhaps so [03:06] Perhaps I'll put a "as long as there's no soname bump in libclamav" caveat in the request. [03:22] run! [03:23] Heh [03:23] Heya gang [03:23] 'lo [03:24] Hi crimsun_ [03:28] Heya [03:28] unmeat deps are a pain in the butt [03:29] The unmet ones aren't so fun either. [03:29] lol [03:29] Hi ScottK [03:29] Heya bddebian. [03:30] bddebian: You see my ping about testresources? [03:30] ScottK2: No sorry, what's up? [03:30] bddebian: Your fix from Debian ftbfs in Ubuntu. [03:31] Oh, it wasn't the buildd issue? [03:31] Nope. I asked for a give back and it died again. [03:31] Frick [03:31] Over to you maestro. [03:34] 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] shiester [03:34] grep-dctrl -F Build-Depends "$1" -s Package /var/lib/apt/lists/*_Sources [03:35] Oh, never mind [03:35] grep-dctrl -FBuild-Depends,Build-Depends-Indep,Depends -s Package $BINARYPACKAGENAME -n /var/lib/apt/lists/*_Sources [03:36] Doesn't have the recursion though [03:37] 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] Yes. It's not the answer to your question, but a step in the right direction. [03:38] persia: I suspect if you get a reasonable answer to your question it'd be worth adding to devscripts. [03:39] 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] 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] 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. === calc__ is now known as calc [03:42] * ScottK2 has also been wanting a --build-twice-in-a-row uption for pbuilder. [03:42] persia: Agreed (about bzr). If you put it in a bug, I suspect it'll get there. [03:43] 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] does reverse-build-depends in ubuntu-dev-tools work? [03:43] Maybe that's the answer [03:44] LaserJock: no /usr/bin/reverse-build-depends (although there is a manpage) [03:47] Good night all. === asac_ is now known as asac [03:53] question why doesn't firefox have Provides: iceweasel seems like a good idea we could squash a few unmet deps [03:54] or is there somthing I'm missing [03:55] 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] Does anyone know what part of an apt repository apt-listchanges and update-manager pull changelogs from? [03:55] (of course, asking in #ubuntu-mozillateam would get an official answer) [03:56] Megaqwerty: I believe http://changelogs.ubuntu.com/ [03:56] Megaqwerty: But I'm wrong: that seems the old way it was done. [03:56] ok i just wondering [03:57] 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] 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] persia, CyberMatt: I'm rather sure apt-listchanges doesn't need netword access. [04:01] Megaqwerty: ^^ [04:02] CyberMatt: Sorry for using the wrong nick. [04:02] minghua: Yes, but that's for already downloaded binary packages. `aptitude changelog foo` downloads an updated changelog without downloading the package. [04:02] np [04:02] Megaqwerty: Check the aptitude source for the answer, or possibly even the aptitude changelog [04:02] persia: I was just going to say that ;) [04:02] persia: thanks [04:03] persia: Yes, I'm just saying they use different sources. [04:03] minghua: that's good, because I couldn't figure it out from the apt-listchanges.py file ;) [04:05] minghua: Ah. Right :) [04:06] so to unbreak iceweasl and icedove deps all that needs to be done is to depend on xulrunner instead [04:07] CyberMatt: Depending on the reason for the dep, one of xulrunner, xulrunner1.9, or some set of browsers is correct. [04:08] 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] persia, thanks [04:13] 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] persia: An FTBFS with my patch? [04:15] Oh, survex [04:15] Did it ever get applied? [04:15] Ah. You've seen it before then? (trying yours now...) [04:15] 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] bddebian: do you actually have a Debian install? [04:17] 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] bddebian: do you run unstable? [04:19] hmm, I wonder if they speak much english in Prague [04:20] LaserJock: That's all I've ever run :-) [04:20] LaserJock: i was wondering that. you're going? [04:20] LaserJock: i can't imagine they have too many czech speakers around ubuntu [04:20] Hobbsee: well, I just don't know [04:20] it's kind of a bad time for me [04:20] 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] but I didn't go to Boston [04:21] persia: you been there? [04:21] (for those not familiar with Czech, "No" is the appropriate pronunciation of the bare affirmative) [04:21] LaserJock: Yes. [04:21] right then. [04:21] * Hobbsee is enlightened. [04:24] * CyberMatt thinks he would never in the Czech Rupublic [04:24] live* [04:25] CyberMatt: Why? Nice place. Good robots. Flexible night buses. Best clock in the world. [04:25] persia: is there anywhere you *havent* lived? [04:25] Hobbsee: Yes. Lots of places :p [04:26] I doubt it [04:26] It'd be to confusing [04:26] antarctica? [04:26] iceland? [04:26] * persia has never been to at least two continents [04:26] and mars. [04:27] I've been outside the US for 4 weeks altogether, 2 weeks in Mexico, 1 week in Paris, 1 week in Sevilla [04:27] impressive [04:27] 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] LaserJock: Which free software conference took you to Mexico? [04:28] none [04:28] that's my non-UDSs trip [04:28] when I was like 13 [04:29] I would have liked to have made Debconf in Mexico perhaps [04:29] have they done a debconf in the US [04:29] ? [04:30] bddebian: Do you have newpki_wx2.6_3.diff somewhere accessible to wget? [04:31] bddebian: Never mind. Quoting helped :) [04:31] 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] Because I sent it through my windows box ;-P [04:33] persia: flip! [04:33] StevenK: ? [04:33] 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] StevenK: OOh. Much better. Thanks. [04:35] Megaqwerty: Ah. Good. I was confused by the dates from http://changelogs.ubuntu.com/changelogs/ [04:36] I've seen this now in c and python, so I've got to ask, does anyone know the significance of "%s" ? [04:36] bddebian: Doesn't apply even with dos2unix or filp :( [04:37] Megaqwerty: man printf [04:37] Gah, WTF [04:37] persia: thanks! [04:38] persia: am I blind? I don't see it mentioned there. [04:39] man this squeak stuff doesn't make any sense [04:39] 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] the -sources package contains a single file, which is all the code for a series [04:40] and then there are .changes which are a diff against -sources [04:40] persia: bah, "No manual entry for printf" [04:40] persia: Is there an online manpage for it? [04:40] Are recommends getting installed now? [04:41] Megaqwerty: Either install manpages-dev or do a web search for "man printf". [04:41] persia: danke [04:41] 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] LaserJock: Just like orig.tar.gz and diff.gz, no? [04:42] persia: well kinda [04:42] which is a bit unusual for an upstream [04:43] all the source in a single file [04:43] easy to package though :-) [04:44] 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] no, license is fairly open [04:47] the 1 file is 14MB [04:47] it maybe just historical [04:47] *may be [05:03] Is there any way to use --force all with apt or is that dpkg only?? [05:08] bddebian: apt-get --force-yes might help, but it is somewhat dangerous... [05:09] The (cleaner) alternative is to use `aptitude download foo` and then `dpkg --force-quux foo_baz.deb. [05:10] (By "dangerous", I mean, "Could leave the system is an unbootable and unrunnable state") [05:11] 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] heh [05:14] the use of DH_COMPAT in debian/rules is deprecated isn't it? [05:14] yep [05:14] LaserJock: Replaced by debian/compat [05:18] hmm, I wouldn't think I'd need configure-stamp and build-stamp rules if I'm not configuring or building anything [05:19] LaserJock: Nope. [05:19] this is silly to have such a large debian/rules when *all* it is is cp'ing a single file [05:19] (but packages should build from source, for some definition of build) [05:19] :-) [05:19] LaserJock: Use CDBS, include debhelper, and put the file in debian/install. Four lines total for rules, compat, and install. [05:20] The only required targets are clean, build, binary-arch, binary-indep, and binary. [05:21] persia: yeah, I might do that and send it upstream to see if they'll take it [05:27] 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] Megaqwerty: Best way is to help fix bugs and close release targets. [05:28] 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] https://wiki.ubuntu.com/MOTU/Contributing has more (but could use a refresh) [05:29] When you have questions, ask here. [05:29] Current big targets are unmetdeps and NBS, although bugfixes are always welcome. [05:30] persia: I haven't finished learning programming yet, just packaging. Is there anything in that realm? [05:30] 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] cool. Where on launchpad should I look for package update/creation requests? [05:32] 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] persia: Awesome! Thanks. One more question, how do I subscribe the sponsors when done? [05:34] 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] Megaqwerty: The "subscribe someone else" link. See the MOTU/Contributing link for some links to process docs, etc. [05:39] persia: So it would be ubuntu-main-sponsors or ubuntu-universe-sponsors respectively? [05:40] Megaqwerty: Exactly. UMS also handles restricted, and UUS also handles multiverse. [05:41] 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] persia: dude, thanks for the cdbs recommendation [05:42] I had two of those packages [05:43] 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] 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] 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] persia: oh, you don't have to convince me of that ;-) [05:45] 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] persia: what does merging the Debian changes entail? [05:47] Megaqwerty: For example, let's say you work on a bug to fix a documetation issue in a manpage. [05:48] 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] where can I find the version of lintian that's running on revu? [05:48] it seems to have newer checks than what's in hardy atm [05:49] At this point, you would work to make a new candidate that included both the fix from Debian, and your documentation patch. [05:49] mdomsch: Looking now... [05:50] mdomsch_: hi ;-) [05:50] ah, maybe not [05:50] it shouldn't be newer. IIRC, it's backported. [05:50] I was running only on the deb, not the .dsc [05:51] 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] Ah. Yes, that would do it. REVU only runs on the .dsc. [05:58] 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] 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] 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] boo hiss @ linda. lintian complains I haven't upgraded Standards-Version, linda complains it's too new [06:03] mdomsch: linda reports that either you or she is wrong. Is this case, it is her. [06:04] indeed [06:06] Hello, what's u-u-s ? [06:06] AnAnt: Ubuntu-universe-sponsors. The queue is visible from https://launchpad.net/~ubuntu-universe-sponsors/+bugs [06:09] Linda is more often wrong than right these days. [06:09] 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] I find I just need to run both [06:10] persia: Yeah, I remember you giving some examples last time we talked about this. [06:11] persia: But she's just not that useful to me anymore. So I only run lintian these days. [06:13] LaserJock: That's my experience as well. [06:13] 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] Sure, let's just just keep each one's own way of doing things, then. [06:18] 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] heh. I only "have" two packages, most of my stuff is on various random packages. [06:23] 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] 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] persia: oh, how are you ? [06:57] AnAnt: recovering. You? [06:57] persia: 2 ubuntme artwork packages are in repos now [06:57] persia: thanks ! [06:57] Should be three. What is missing? [06:58] persia: the third is still in queue [06:58] 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] persia: btw, is it late to request a sync from Debian ? [06:59] persia: no, I still didn't start working on a ubuntume-meta [06:59] persia: some ubuntume packages can't enter in Ubuntu repos yet anyways, due to unresolved copyright issues [06:59] 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] persia: it's a request to add a package [07:00] 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] AnAnt: Is the package necessary for hardy in some way? [07:00] persia: yes indeed, hardy+something ! [07:01] persia: I don't think so [07:01] persia: it's sorta like, good to have [07:01] 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] ok [07:01] 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] I see [07:02] persia: another thing, I am making a package that makes use of update-alternatives [07:02] persia: oops, wrong question [07:03] 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] persia: I got a problem with a postinst script (http://pastebin.com/m2f1953e2) [07:07] persia: it gives me an error when I install the package, hang on till I get it [07:09] Good morning [07:10] persia: here's the error: [07:10] debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by [07:10] another process: Resource temporarily unavailable [07:11] 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]