[00:01] pschulz01: this link should answer all your needs: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages [00:03] DarkMageZ: Not really.. I want to know how to go from an upstream release 3.0.0 to 3.0.1 (say), given that I have the packaging source (diff) for 3.0.0 [00:04] pschulz01: cp the new tarball to an .orig.tar.gz and then unpack it and drop in the old debian/ [00:05] like LaserJock said. then just add a changelog entry and build [00:05] pschulz01, yes. it's really that easy. [00:05] .. or just use uupdate! [00:06] yep [00:06] * DarkMageZ must look @ this uupdate tool [00:06] Fujitsu: watch/file buddy ? [00:06] Fujitsu: I think that was what I was after in the first place! [00:06] proppy: What? [00:07] Fujitsu: I mean is uupdate related to debian/watch file or am I completly mistaken ? [00:08] related, but not dependent I don't think [00:08] uscan uses uupdate if it finds a new upstream. [00:08] ok :) [00:09] Fujitsu: Woot! That worked. [00:09] pschulz01: Great :) [00:10] I wonder why pulseaudio/i386 on hardy is showing pending still. [00:10] Fujitsu: Now just have to keep doing it otherwise the information will fall off the bottom of my heap. [00:10] it's built and available for the other arches [00:10] Fujitsu: No more tea breaks for me. [00:11] crimsun: perhaps an arch: all backlog? [00:11] LaserJock: ... [00:12] crimsun: Pending == NEEDSBUILD [00:12] I presume you mean Currently Building. [00:12] Oh, wtf... It doesn't even have a builder assigned. [00:12] And there is no cprov to be found. [00:13] Woohoo. Pulseaudio for Hardy can be set up to replace the system beep through the pc speaker with a sound of one's own choice. [00:13] TheMuso: Yay! [00:13] crimsun: I saw a bug similar to that a couple of nights back, on a PPA. [00:13] Fujitsu: Yeah, I think its time we had something like this. KDE has had it for ages. [00:19] right. It doesn't make sense that ndiswrapper, which was uploaded only today, is available in pool, while pulseaudio isn't for i386. [00:19] Fujitsu: ok, thanks. [00:19] crimsun: Note how it is labeled as building but has no builder or start date. [00:20] Fujitsu: right. [00:20] == great example of Soyuz's reliability. [00:21] Why is pulseaudio i386 only now currently building? [00:21] I suspect thats what you are talking about. [00:22] TheMuso: yes, that's the symptom which is apparently a known issue. [00:22] Right [00:22] (apologies for the gnome-audio snafu) [00:23] np [00:23] hardy ubuntu-desktop deps are somewhat broken atm anyway, so new installs can't easily be done for the desktop at least. [00:24] How long has that been building? I get the feeling for a while now. [00:24] TheMuso: It's not building. Note the lack of builder or start time. [00:24] Fujitsu: ah ok. [00:25] * TheMuso pulls the source and builds locally. I want to do some testing. === doko_ is now known as doko [00:27] night all [00:28] Would a give back solve that? [00:28] TheMuso: It may, but it could well not show the button. [00:29] s/may/probably would/ === lakin_ is now known as lakin [00:53] anybody seen this gtk packaging GUI called debcreator? [01:03] (https://launchpad.net/debcreator) [01:04] eeek. [01:04] it looks like text entry fields for control, etc. [01:05] (is it really adding anything to the end user besides window decorations?) [01:08] Does anyone know of a good example of a perl (cgi) package that hooks into Postgres/Mysql. I'm looking for suitable setup scripts. === bmk789_sleep is now known as bmk789 [01:48] this is so strange... [01:49] I'm trying to package iourt (a modified ioquake3 engine) from source.. if i build it quickly just using "dpkg-buildpackage -rfakeroot" it works just fine.. but if i do it properly "debuild -S -sa" then "sudo pbuilder --build ../iourt-4.0-0ubuntu1.dsc" the compile fails >_< [01:50] jscinoz: Could you put your build output in a pastebin? It sounds like a missing build-dependency [01:52] you'll need to have all the dependencies from ioquake3 in the control file + any extra to cover the modifications [01:56] yeah one second. [01:56] just going to try it first with a small tweak to debian/rules [02:00] persia, heres as much output before the scroll limit http://pastebin.ubuntu-nl.org/47312/ [02:01] jscinoz: OK. Could you paste debian/control ? [02:01] yeah one sec. [02:02] http://pastebin.ubuntu-nl.org/47313/ [02:03] jscinoz: Yep. You need to include the SDL libraries in Build-Depends: [02:03] ah [02:03] just libsdl-dev? [02:03] silly mistake >_< [02:04] jscinoz: Grep in /usr/include for SDL_UnloadObject, and then find the package that provides the containing file. [02:11] yep it was libsdl1.2-dev [02:11] all good now :) [02:11] doh >_< i forgot to include the .desktop file i made for it >_< [02:31] persia: have you already made a run through ~u-u-s bugs today? [02:32] LaserJock: Not yet. [02:42] hmm, should I take a Kmos bug? [02:42] LaserJock: No reason not to do so: just look at it with care. [02:44] hmm, it's a little fishy but it's getting there [02:46] I still think it's a bit overkill to add a patch system for a one line diff [02:46] I don't think it's worth it. [02:48] yeah, but is it worth telling somebody to redo the debdiff [02:48] especially when another MOTU said they should add the patch? [02:49] seems like people are giving mixed messages [02:49] * persia grumbles at people who insist on patch systems [02:49] LaserJock: Are there any other patches to the package in the diff.gz? [02:50] * StevenK appears [02:51] persia: it's a native package ... [02:51] argh.. stupid question but.. what is the syntax to leave a blank line in the long-description in debian/control? [02:51] jscinoz: " ." [02:51] LaserJock: I7d suggest that a native package should never have a patch system. That just doesn't make any sense at all. [02:52] LaserJock: Yes, it's worth redoing the debdiff, and yes, it's worth slapping the MOTU who advocated a patch system for a native package. [02:54] thanks stevenk [02:54] LaserJock: What bug? [02:55] bug #174239 [02:55] Launchpad bug 174239 in dhelp "Please merge dhelp 0.6.5 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/174239 [02:55] * ScottK looks to see who needs slapping. [02:57] hmmpf [02:57] I have to say, working on his bugs aren't very easy [02:58] * TheMuso avoids kmos bugs, and has done so for a while now. [02:58] LaserJock: He doesn't make them very easy, either. [02:58] I've dealt with enough of them to know that he's not likely to get a clue any time soon. [02:58] Yes. He's often right about many things, despite being wrong about others. [02:59] And I hope, but at at the same time doubt, that he'll request syncs for packages after debian import freeze for good reasons. [02:59] so he made a changed one thing in the Makefile, but then includes a changelog entry that references a different change [02:59] IMO the odds do make it worth betting the opportunity cost of what I didn't do if I expend the time to look. [02:59] LaserJock: That's unfortunately exceedingly common: acceptable work with seemingly random documentation :( [03:00] TheMuso: He'd been told even before the first round of mass sync bugs for Gutsy not to do it, so don't get too focused on that hope. [03:00] ScottK: As I said, I doubt it. [03:02] LaserJock: In this case, consider reviewing the patch in https://bugs.launchpad.net/ubuntu/+source/dhelp/+bug/174239/comments/17, which is perhaps more sensible. [03:02] Launchpad bug 174239 in dhelp "Please merge dhelp 0.6.5 (universe) from Debian unstable (main)" [Wishlist,Confirmed] [03:02] Well until I was doing research for my recent request to the MC, I didn't know he'd been told not to even before the first time. [03:02] Strangely, back in feisty close / gutsy open, the work was of higher quality. [03:03] Well let's get it fixed then. We'll recruit an army of new people who have no experience to help out and that'll solve the kwality problem. [03:04] oh dear. [03:04] * Hobbsee looks up backscroll [03:05] persia: what was of higher quality? [03:05] ScottK: Well, no, but it will increase the volume of work, which may be good. [03:05] LaserJock: Submissions from kmos [03:05] Well, we've got some easy tasks for new contributors. [03:05] Namely tailing Kmos. [03:05] persia: yeah, I think perhaps he's doing some of it on purpose to spite some people [03:05] Ah. I thought persia was making a broad statement. [03:06] LaserJock: I actually don't think he has a dishonest bone in his body. The scary part is that he really is doing his best. [03:06] * TheMuso chuckles at the e2fsprogs mail on gutsy-changes [03:06] ScottK: No. Specific. Broadly, I think new contributors always make mistakes, and after 10-15 bugs reach a level where their work is demonstrably good (or they leave before reaching that number). [03:06] ScottK: but why would the quality go down? [03:07] what's this kmos thing? it keeps on getting refered to... [03:07] DarkMageZ: Kmos is a contributor. [03:07] fsvo contributor. [03:07] contributor to what, though? [03:07] DarkMageZ: Kmos is probably the most painfully disruptive person we've had show up here to 'help'. [03:07] TheMuso: I get them all the time. [03:07] DarkMageZ: A specific person whose Contributions often don't meet sponsor requirements, and whose submissions take a larger volume of sponsoring time than those of others. [03:07] Though what the heck happened there? Security uploads aren't announced... [03:07] LaserJock: I dunno. Maybe he's getting nervous. [03:08] TheMuso: if he reqeusts a whole bunch of syncs after DIF, he is going to die a horrible, painful death. [03:08] LaserJock: Don't ask me to explain how his mind works. I've already got a headach. [03:08] ScottK: I'd like to think he's not doing it on purpose [03:08] i *doubt* he's that stupid to try again [03:08] kmos = microsoft sabotor? [03:08] LaserJock: I don't think he is. [03:08] Hobbsee: Careful: there may be reasons for the syncs. I tend to request heaps of them, especially for edge stuff (not libraries). [03:08] DarkMageZ: may as well be. have a look at the messages for this month on motu-council@l.u.c [03:08] persia: having seen the last lot... [03:09] DarkMageZ: I don't think so, but he's the primary reason I'm not doing UUS anymore. [03:09] Hobbsee: Yes, I know. Still, I find that > 70% of his requests actually have some root in a good thing (although it would be quicker for me to address it directly than sort out what he is trying to do). [03:09] persia: then in the interests of time, i'd suggest you take the latter option. [03:09] :) [03:09] * Fujitsu likes the addition to /+builds. [03:09] persia: yeah, the pre-DIF ones are. [03:10] persia: the post-DIF ones just seem to be "sync it because it has changes in debian, and might fix bugs" [03:10] Hobbsee: Even post-DIF (but I'm an advocate of continued selected syncs / merges post-DIF for non-libraries). [03:10] I'd be happy to see lots of sync requests if the update in Debian fixes a known issue. [03:11] (this does, however, require documentation of the issue) [03:11] * ScottK feels he has done his duty and more wrt Kmos (both helping him when that seemed possible and lately), so whatever happens, he's done with it. [03:11] ScottK: Good plan. Less stress for you :) [03:11] Yeah. [03:11] ok, I think he got this one right [03:12] LaserJock: Now for the fun question: would it take you half an hour to process the merge directly? [03:12] hmm, probably not [03:13] And this gets into the negative value thing. Even when he's right, he suck the productivity out of people. [03:13] although he caught something I probably wouldn't have [03:13] although I don't know that it's really very important [03:13] the more bugs he files, and the more people become accepting of his low level of quality, (not necessarily accepting the bugs, but not telling him "please don't do this again", and making sure he doesn't) the less i feel like i can be a part of the team. [03:13] * Hobbsee shrugs [03:14] Hobbsee: right, but it's difficult to blanket reject somebody [03:14] Hobbsee: How can we "make sure"? [03:14] lock the LP account. [03:14] MC hasn't appeared to actually do anything about it yet. [03:14] * persia notes that LP accounts are easy to open [03:14] this is a volunteer, contributor run organization we need to figure out good ways of dealing with such things [03:15] this is true, but there are ways around it. [03:15] Hobbsee: You can't ignore him? [03:15] StevenK: Ignoring is hard: he clutters the sponsors queues, and other fora [03:15] StevenK: it's a perception of quality over the entire MOTU project, rather than ignoring a particular contributor [03:15] persia: True. [03:16] Further, the work he reviews often needs doing, and blanket rejecting it makes it not appetising to someone else. [03:16] Hobbsee: Oh, your point is he smears our reputation and drags us all down? [03:16] if the quality has dropped to his substandard level, then why should i put in time attempting to fix it? [03:16] StevenK: exactly. [03:16] StevenK: you put that very well. [03:16] * ScottK is back. I had to get alcohol. [03:17] *giggles* [03:17] very large amounts? [03:17] ScottK: You're starting the -motu drinking game? [03:17] * Hobbsee drinks, in preparation for work [03:17] Hobbsee: Not yet. The topic just had me headed for the liquor cabinet for solace. [03:18] StevenK: Every time I complain everyone has to take a drink. [03:18] ScottK: Then we'll all get smashed in about ten minutes? [03:18] * StevenK ducks [03:18] StevenK: Isn't that the point of drinking games? [03:19] Heh, yeah well [03:19] Bit early to start drinking here, anyway. [03:20] Speaking of mistakes, openssl097 got removed from partner today. [03:20] It got removed like two days ago [03:20] It's still today for me. [03:21] * StevenK doesn't look at -partner [03:21] and my computer decided to freeze, when looking at the issue, clearly [03:22] heh, this is kinda silly [03:22] * ScottK doesn't as a rule, but when I saw an upload with a remote code execution unpatched (that I'd expended time to get out of Universe) on gutsy-changes, I got interested. [03:22] LaserJock: Which? [03:22] the Makefile checks the debian/changelog for the package version, and then check to see if the version is the same as what is in the Makefile [03:23] so every time you update the changelog you gotta change the Makefile [03:23] * StevenK drops his shovel, and fires up the backhoe to dig through the net-snmp merge. [03:23] Note that the common thread between Kmos and the openssl097 upload is that more and more of us (IMO) have come to view public shaming as the only way to correct bad work. [03:23] But public shaming has had no effect on him! [03:23] ScottK: ah, right [03:23] StevenK: Not that we didn't try. [03:23] that was kinda rough [03:23] LaserJock: Which, the blog post on openssl? [03:23] He's like bad in-laws, he just keeps coming back. [03:24] ScottK: yeah [03:24] that should have been an email to -devel methinks [03:24] LaserJock: I disagree. It's partner, it's not part of the Ubuntu development process. [03:24] hmm, I guess [03:25] although I generally consider partner to be a part of the grand Ubuntu universe [03:25] ScottK: Did you see Colin's comment on the partner-isn't-Ubuntu-you-stupid-LP bug? [03:25] LP has been modified to make it look like part of Ubuntu (separate issue), but it's not. [03:25] Fujitsu: Yes I did. [03:25] * Fujitsu wasn't pleased. [03:25] Fujitsu: I didn't, point me at the bug? [03:25] Parter should be a special case of PPA. [03:25] *Partner [03:25] Fujitsu: about? [03:25] LaserJock: Ummm.. As a Master of the Universe who can't upload to Partner, I think you'd see it different. [03:25] Bug #153798 [03:25] Launchpad bug 153798 in soyuz "canonical partner repo packages showing as "in ubuntu"" [Undecided,Confirmed] https://launchpad.net/bugs/153798 [03:25] Fujitsu: Yes. [03:25] persia: What? [03:25] persia: why? [03:26] Fujitsu: "Partner should be a special case of PPA" [03:26] Ah, yes. [03:26] Fujitsu: Well I like that he supported the concept that it was wrong. He's not an LP dev, so I don't worry so much about his, it'll be hard. [03:26] LaserJock: You aren't the master? [03:26] persia: heh, I see [03:26] Fujitsu: What's wrong with that? [03:26] When I see a non-canonical person with upload rightw to partner, then there's something to discuss. [03:27] Fujitsu: I see nothing displeasing about Colin's comment. [03:27] rightw/rights [03:27] well, it just doesn't bother me what they do much with partner [03:27] LaserJock: And rightly. [03:27] and I consider it to be generally a part of broader Ubuntu [03:27] LaserJock: It only bother's me to the extent it affects Ubuntu's reputation. [03:28] so I would consider -devel an ok place to ask questions about it [03:28] Uploading known vulnerable software is not a good step. [03:28] for lack of a better place perhaps [03:28] imbrandon blogging got people's attention. [03:28] * persia suggests that the issue is resolved, and that there are >1000 issues open that we can resolve that are more worthy of discussion [03:29] persia: sure, it's just an interesting thing [03:29] persia: True, but the meta issue is relevant. [03:29] I generally try to only blog positive things [03:29] StevenK: Does it not basically say it won't be resolved in the near future? [03:29] but what about when bad things happen, should be discuss things in blogs or no [03:29] ScottK: LaserJock: Agreed, but I don't think this is a useful forum for resolution of those issues. [03:29] that's the interesting part to me [03:29] Fujitsu: But that's about like me saying a Gnome bug will be tought to fix, so don't hold your breath. [03:30] LaserJock: If we only talk about the good stuff we are marketing, not being a community. [03:31] ScottK: This is something that is clearly wrong and most misleading. [03:31] ScottK: yeah, but throwing around the dirty laundry isn't necessarily great either [03:32] LaserJock: I'd say if people don't want blog entries about vulnerable software being uploaded to Ubuntu, then they shouldn't do it. [03:32] * persia wonders if it's worth regenerating all the source packages that use the Homepage: header that were sync'd / merged prior to the new dpkg. [03:32] Additionally, I think proprietary developers working in a FOSS space get less slack. [03:33] persia: I'd say no. [03:33] persia: The round of rebuilds will catch that, when/if we do them, so I'd wait... [03:33] ScottK: proprietary developers? [03:33] LaserJock: Partner is not a FOSS repository. [03:33] Fujitsu: Rebuilds for uploads? These would all be new-in-hardy packages. [03:33] persia: It's likely that most will be uploaded again at some point, but we'll see... [03:34] Fujitsu: Ah. Good point. [03:34] Those that have been merged likely have maintainers that are alive. [03:35] Fujitsu: Hmm.. But are such maintainers concerned? I just don't know if it's actually an issue. The package works, it's just the Homepage listings were silently dropped in many cases. Likely only affects packages.ubuntu.com, if that code is updated to look for the header. [03:36] persia: I meant maintainers in Debian, such that there will be a new version to merge before DIF. But I guess we're far too close for that now. [03:37] Fujitsu: That was my thought. Further, I don't think syncs need rebuild, just merges / refreshes / REVU / patches. [03:38] Anyway, I think you're right: it's a late-cycle thing to look to see what packages with Homepage: were uploaded before the new dpkg, and check to see if they still need refresh just before release. === stdin_ is now known as stdin [03:39] It would have been a whole lot better if dpkg had been merged earlier. [03:39] To Ubuntu or Debian? [03:39] The former. [03:39] StevenK: to Ubuntu (and, yes, we're all guilty) [03:42] But merging dpkg is *hard* [03:42] StevenK: That's why it was delayed :) [03:50] ok, we'll see if I got shot for this [03:50] * StevenK shoots LaserJock [03:50] LaserJock: what? [03:50] LaserJock: ponies! [03:50] Right! [03:50] persia: uploading kmos' debdiff [03:50] * persia thinks LaserJock is immune to being shot for ponies [03:50] LaserJock: PONIES! [03:51] LaserJock: Remember, it's about the work, not the person. Certain people just cause more effort when reviewing work. Please leave a description of what should be done better next time in a comment. [03:52] persia: it was actually good except for adding the patch thing, which was nixternal's fault anyway ;-) [03:52] LaserJock: In which case, the comment should reflect that. [03:52] * persia notes that occasional rare praise is a good seasoning for excoriation. [03:53] Hello stratus. I didn't notice you there. [03:55] persia: I set it to "Fix Committed" is that alright? [03:55] LaserJock: That's what I do: it's not mandatory. The changelog should be closing the bug. [03:56] right, I just didn't want to leave a comment saying I uploaded without changing the status [03:56] It's fairly useless to set it these days; sources have publishing records create as uploads are processed, so the bug will be closed within 5 minutes of the dput. [03:56] s/create/created/ [03:56] Fujitsu: I just wanted the record [03:56] Fujitsu: Agreed. It's only meaningful in rare cases. [03:58] yikes [03:58] this person bumped the version for each time he attached a new debdiff [03:59] Haha. [04:00] LaserJock: Someone from Debian mentors I expect. Disabuse them gently, please. [04:00] persia: you know I'm a softy ;-) [04:02] bah [04:02] I think they provided debdiffs to a package they put on REVU [04:02] LaserJock: A new package? Which bug? [04:02] new upstream [04:03] LaserJock: We do new upstream in UUS as well. [04:03] bug #174467 [04:03] Launchpad bug 174467 in gnome-schedule "Please sponsor gnome-schedule-1.2.1 into Hardy" [Wishlist,New] https://launchpad.net/bugs/174467 [04:03] right, but they put the initial upstream on REVU and then put debdiffs for changes [04:03] That's special. [04:04] LaserJock: Ah. I see. Generally we prefer all the changes wrapped in one revision, and an interdiff (until I can come up with something better: suggestions welcome) [04:04] well, it would have been better to put it all on REVU IMO [04:05] LaserJock: I disagree, for all the reasons stated in https://wiki.ubuntu.com/UbuntuDevelopment/Interdiff [04:06] I don't really see any reasons listed there [04:07] LaserJock: Sections 3 & 4: deprecated foo [04:07] right, just found that [04:08] hmm [04:08] well if people review right it shouldn't be a problem, IMO [04:08] LaserJock: I consider the matter open for discussion: if you've a suggestion of a better way, please share. [04:09] I see the point about it being a bit confusing to have both NEW and updated source packages on REVU [04:09] but I don't see why a link to a dget'able would really be a problem [04:10] LaserJock: untrusted orig.tar.gz mostly. [04:10] but I don't see an issue there [04:10] if it's a matter of people not doing a proper job of reviewing shouldn't we fix that? [04:11] Essentially, anyone who can upload something gets root on millions of systems. For those who are insufficiently trusted to be able to upload directly to Debian or Ubuntu, hiding something in the orig.tar.gz is a good way to do interesting things. [04:11] right [04:11] LaserJock: How do we "fix that"? [04:11] but that's the case always [04:11] why wouldn't you check? [04:11] * ScottK applauds persia's level of paranoia. [04:12] we should just put in a New Upstream Release Review checklist to check the .orig.tar.gz [04:12] LaserJock: If policy doesn't require get-orig-source / working watch file, how can you check? [04:12] you go and download the source [04:12] that's what I do anyway [04:12] If policy does require it, why would you want to download it twice? [04:12] From where? [04:13] from the site of the app [04:13] same as you would with a NEW package [04:13] LaserJock: And how do you get the site of the app? How about for repacks? [04:13] debian/copyright should say where you got the app [04:13] LaserJock: I don't like it for NEW either, but I don't have a good model that allows the flexibility of REVU yet. [04:14] and for repacks it should be documented [04:14] LaserJock: Right. One of the goals of using interdiff is to change "should" to "must". [04:15] but why not just make checking the .orig.tar.gz a "must" then [04:15] LaserJock: No enforcement mechanism. [04:15] it seems like added complexity [04:15] persia: so? isn't that part of being a MOTU [04:15] LaserJock: I make mistakes. I expect you to make mistakes. More importantly, I don't expect anyone else to be as paranoid as I am. [04:16] right, so we should have a minimal paranoid level and have that be policy [04:16] but enforcement should be on MOTUs for the most part [04:17] LaserJock: Maybe. I think it's easier just to not pass around large binary orig.tar.gzs that need reinspection. Waste of bandwidth. [04:17] hmm, perhaps [04:17] but I've heard people having problems with interdiffs so I don't think we should make it mandatory [04:18] sounds like it might be a good practice and a recommendation [04:18] LaserJock: What sorts of problems? [04:18] * persia is working on a new system, but wants more input [04:18] not being able to recreate the package correctly [04:18] LaserJock: Do you have an example? [04:19] no sorry [04:19] I just remember like a week ago or so somebody saying in here that they were screwed cause the interdiff didn't work, but they may have resolved it [04:19] LaserJock: Were you at the meeting today? [04:20] The only cases I've encountered so far were broken watch files, lack of get-orig-source for repacks, contributors sending interdiff -z -p1 foo bar. [04:20] Oh, and one case where the new package didn't match upstream (as upstream hadn't released yet). [04:21] ScottK: no sorry, I've actually never been able to make a MOTU Meeting in the last year or so :( [04:21] * StevenK wonders if the dpkg in Debian now has triggers. [04:21] * Fujitsu forgot about the meeting. [04:21] LaserJock: No problem. Just we discussed this today. Someone (I don't recall who) persia? has started a script to make the interdiff bit easier. [04:22] My (weak) script is at http://people.ubuntuwire.com/~persia/process-interdiff (as it has been since the Interdiff docs were posted) [04:22] Hey everyone... [04:22] persia: do you have to have a watch file or get-orig-source for interdiff to work? [04:22] I'd like to introduce/reintroduce stratus. [04:22] hey :) [04:22] stratus is a DD interested in becomeing a MOTU. [04:23] hi stratus [04:23] In fact he was my first Debian sponsor. [04:23] LaserJock: No, it just makes reconstruction of orig.tar.gz lots easier, and the lack of a working watch file is considered a bug in Debian. [04:23] hey LaserJock, what's up? :) [04:23] stratus: Welcome. [04:23] stratus: workin' on stuff ;-) [04:23] persia: hey, thanks! :) [04:24] LaserJock: heh as usual, I guess. [04:24] persia: hmm, I'm not sure I totally agree with that [04:24] stratus: yeah [04:24] persia: I've run across sources that may be impossible to automate getting the .orig.tar.gz [04:24] LaserJock: Which? That a watch file should be required? Especially with team maintenance, how else are we to know about new upstream versions? [04:24] btw, I've forwarded ScottK a entire new package and I will have some patches to other stuff anytime soon [04:25] LaserJock: I don't believe you (for non-native). Show me the package, and I'll write a get-orig-source. [04:25] that's why I decided come out of the shadows again and become a MOTU, since it wil be easier upload by myself in due time [04:25] stratus: The best way to get your patches in is likely to attach a debdiff to a bug, and subscribe the ubuntu-universe-sponsors queue. That way, you don't need to rely only on ScottK (although that works too). [04:25] Which I'm going to upload for him (he's just moved and is currently GPG key contrained). [04:26] persia: oh, I heard about that. thanks! :) [04:26] persia: well, I'm pretty sure I've come across a few science packages that had no machine downloadable sources [04:26] Assuming it builds and produces a sane package, I'll advocate it. [04:26] I moved and then went on road to US, so decided to keep my priv key secured at $HOME :) === asac_ is now known as asac [04:27] LaserJock: Really? Please point me towards them if you encounter them again. It's likely one of A) Odd upstream, B) Orphaned upstream (and in need of adoption), or C) very weak documentation. [04:28] usually A, sometimes B [04:28] In the case of A), it's worth checking with upstream to find out why they don't distribute source, and inviting them to use one of the many fine distribution services. In the case of B, it's worth adopting the package to a new project on one of those distribution services. [04:29] there are a few that are no longer available online, but of course then we'd not be expecting a lot of new upstreams [04:30] LaserJock: That would be B), and I'd encourage the creation of a project on sourceforge, google code, launchpad, savannah, etc. [04:30] Err. "one of" should be in there somewhere. [04:30] well sure, that may be nice [04:30] LaserJock: Takes about 20 minutes :) [04:30] I'm just saying that you can't assure that 100% of packages have a machine downloadable upstream [04:31] LaserJock: Further, it's essential to ensure the code can be shared between all distributions, making the general cause of free software stronger. [04:31] yep [04:31] I had a talk with Fink (OS X stuff) about watch files once [04:32] they wanted to use Debian to track software, but since there were so few watch files it was impossible to do it [04:33] perhaps the situation is much better now [04:33] LaserJock: Right. For some things, watch files don't work (I've been given many cases), but even for those, one can construct an orig.tar.gz, as long as upstream exists. [04:34] sure [04:34] it's not currently that way [04:34] Further, for packages updated in Ubuntu, I think it's not much extra effort to generate the watch file / get-orig-source as compared to integrating the new upstream in the packaging. [04:34] but it'd be nice [04:35] LaserJock: So, in the spirit of "it'd be nice", join in enforcement for new upstream candidates :) [04:35] persia: But we don't have (widely accepted) something like Debian QA page where you see when your packages need updating. [04:35] hmm, that enforcement bit is what gets me ;-) [04:35] ScottK: What's wrong with http://qa.ubuntuwire.com/uehs/ ? For stuff in Debian, I'll trust the maintainer, but for the rest... [04:36] persia: That's where the 'widely accepted' bit came in. Now that we have that watch files make more sense, but people have to know about it. [04:37] ScottK: OK. I admit I'm behind on documentation and annoucements :) [04:37] * persia notes that others are more than welcome to advocate and promote QA efforts. [04:37] persia: Is that all of Ubuntu or just Universe? [04:38] ScottK: That's just packages in Ubuntu that aren't in Debian and haven't been removed from Debian. [04:38] OK. [04:38]