[00:07] is there anyone in here who can upload Sauerbraten fixes? No updates without the fix, all have updates. Fix on launchpad board. I admit I am begging. [00:13] RainCT, ping? [00:13] NCommander: pong [00:14] RainCT, if I roll the sauerbraten fixes, will you upload? [00:16] NCommander: what changes are it? [00:16] I'm looking for the patch now [00:19] gtg [00:20] NCommander: Doesn't he mean bug 252037, which has to be processed by a core dev? [00:20] Launchpad bug 252037 in sauerbraten-data "sauerbraten cannot upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/252037 [00:24] Laney: (it's on production now, with anchor) [00:25] good night [00:51] in a cdbs package, how can I ensure that reverse-patches is only ever called after make distclean in the clean target? [00:51] google search seems to think that this is the default behavior for cdbs simple-patchsys [00:52] I thought the default behaviour was to reverse-patches _before_ running the clean target. [00:53] that's not what https://wiki.duckcorp.org/DebianPackagingTutorial/CDBS says, for instance; and it's not a sane default either way :P [00:53] ah, behavior was changed in bug #387103 [00:54] great, so to support tarball-in-tarball, they've instead broken being able to patch build systems via simple-patchsys [00:54] * slangasek exudes nothing but love in the direction of simple-patchsys [00:54] In the form of a rusty knife? [00:55] StevenK: I was thinking "hepatitis C cultures", but ok [00:55] Haha [00:56] So, a rusty syringe [00:56] heh, and there's a follow-up to that bug from pitti that was never acknowledged, awesome [00:57] oh, there are also follow-ups from /me/ to that bug :) [00:57] Hah [00:58] * slangasek considers unarchiving and reopening the bug [00:58] * slangasek also considers what the heck he's going to do in the short term to get libgweather working right [01:00] slangasek: Ah, I was wondering. [01:00] StevenK: yes, I'm not touching either cdbs or simple-patchsys by choice :-P [01:06] hello to all [01:06] * slangasek waves [01:06] :) [01:14] makefile-clean:: apply-patches [01:14] include /usr/share/cdbs/1/rules/simple-patchsys.mk [01:14] clean:: [01:14] make -f debian/rules cleanbuilddir [01:14] CHEMICAL. FIRE. [01:14] [01:15] Haha [01:16] so to work around simple-patchsys brokenness, we do: unpatch; patch; distclean; unpatch [01:16] \o/ [01:17] Ha [01:17] Which poor CDBS maintainer is going to feel your wrath? [01:17] do I really have to pick only one? ;) [01:18] * StevenK grins [01:20] oh, hah; even better, bug #424080 was fixed with a change that eliminated the reason for the bug #387103 change [01:22] slangasek: the true fire is bug 255819 [01:22] Launchpad bug 255819 in slack "prerm will rm -rf / when /etc/slack.conf is empty" [Critical,In progress] https://launchpad.net/bugs/255819 [01:22] :) [01:23] Ha! [01:23] ... clever [01:23] this is why I never install anything with "slack" in its name [01:23] hahaha [01:23] old Legend.. Devian Vs Slackware [01:24] s/Devian/Debian/ [01:40] if I want to build a package for intrepid but the clean script will fail on hardy, is there a way to tell pbuilder to skip calling make clean? [01:42] sharms: Build the source package in an Intrepid chroot? [01:42] I was hoping to just get away with a pdebuild command [01:42] some flag like --do-make-clean-in-pbuilder-chroot [01:43] Hm... dpkg-buildpackage -nc doesn't run the clean target, IIRC. [01:46] which can be used only in conjunction with -b or -B, yes [01:48] ah ha --use-pdebuild-internal [01:49] ++to pbuilder docs [01:56] RAOF: so, you probably work with cdbs more than I do; aside from the tarball case, is there any reason why one would be /expecting/ reverse-patches to be run before clean? [01:56] (before I go patching this behavior away) [02:02] I have a build question for someone. I requested a sync for a lib (liblicense) and LP shows that it has been successfully built for Intrepid, but when clicking on the link under "resulting binaries" gives me a 404 [02:02] https://edge.launchpad.net/ubuntu/+source/liblicense/0.8-1/+build/686396 [02:03] is there something I am missing? [02:07] greg-g: which binary arch? [02:08] 386 [02:08] drats, irssi fail [02:08] i see it greg-g [02:09] clear your cache maybe? [02:09] vorian: from here? https://edge.launchpad.net/ubuntu/intrepid/i386/liblicense3/0.8-1 [02:10] yes [02:10] hmmm [02:10] greg-g: pm me your email, i'll send you the build log [02:19] slangasek: It seems to be the most common behaviour when using debhelper? (the clean: target often depends on unpatch). I can't think of a technical reason why you'd want that behaviour, though. [02:23] RAOF: well, you want clean: to depend on unpatch because 'clean' is the policy-mandated target :) [02:23] and in the debhelper case, unpatch is often done before make distclean because you're writing the rules by hand, and you generally aren't patching the build system so don't run into problems doing it this way [02:24] and it's the simpler way to do it [02:24] but cdbs needs to handle the not-simple cases... [02:28] Right. clean: obviously has to do the unpatching, and in simple cases that's most easily handled by making it a dependency of clean:. I don't think anyone would _depend_ on that behaviour, though. [02:33] RAOF: alrighty, well, patch committed to bzr, and bug being filed upstream :) [03:12] would putting the kqemu in intrepid into hardy be a backport, or an SRU? [03:15] Almost certainly a backport, but it depends on why you'd be putting it in Hardy. [03:15] the version is unchanged, except for the -ubuntu1 suffix [03:15] it closes 6 launchpad bugs or so [03:17] So there are a bunch of patches applied? That could be SRU worthy (but would probably be sru'd as a bunch of patches against Hardy's kqemu, not by copying Intrepid's source package). [03:18] intrepid's source pkg _is_ a bunch of patches against hardy's kqemu [03:19] at least at this point [03:21] the only changes at all are to fix the packaging peculiarities inherited from debian [03:25] RAOF: i imported the intrepid source pkg unchanged into my ppa, but with a hardy target, and installed it from there. works perfectly [03:25] erm, no, the changes are implementing new features [03:25] * Adding DKMS support [03:26] that's what closes some of the launchpad bugs [03:26] which is fine, but I wouldn't expect that to pass muster for an SRU [03:27] Yeah. Adding DKMS support is hardly going to fix any regressions :) [03:27] Looks like you'll want to backport it. [03:28] ok, i'll file against hardy-backports. since i've already tested it, it's got a head start anyway [03:33] ubottu: bug 255909 [03:33] Launchpad bug 255909 in hardy-backports "Please backport kqemu from Intrepid. Thank you." [Undecided,New] https://launchpad.net/bugs/255909 [03:38] seems to me, that request can probably go directly to "Triaged" state, right? [03:49] are we debian-sync frozen yet ? [03:50] lifeless: Autosync is off, yes. [03:50] lifeless: In an automated fashion, yes. Of course, if you've a good reason, manual sync is accepted [03:50] new package === persia_ is now known as persia [03:51] RAOF: "Triaged" is ok in this case, right? [03:51] antlr3 if you are curious [03:51] I'm just paging in process [03:51] sn9: I don't think you've got the two required "it works" confirmations for the "triaged" state; but see the Backports documentation. [03:52] lifeless: Deadline for new packages is FeatureFreeze (August 28th). On the other hand, you have to acually want the new package now, as opposed to it being automatically pushed. [03:52] RAOF: oh, it needs two? "Confirmed" then? [03:52] !backports > sn9 [03:52] sn9, please see my private message [03:52] I'm not sure what the correct status is; but backports use the statuses to mean specific things. See the doucmentation. [03:53] i did -- that's why i said "Triaged" [03:53] Hm. Then ignore me :) [03:53] slangasek: should i ignore RAOF? :) [03:54] That documentation is authoratative; my memory of it is not :) [03:54] hmm, its already in intrepid, now that I get around to checking all my facts [03:54] so its really easy to sync :> [03:54] (as in not-needed) [03:55] lifeless: rmadison is your friend :) [03:55] persia: yes, but its so damn slow [03:56] RAOF: hmm, seems one needs to be an admin to set "Triaged" [03:59] $ time rmadison antlr3 [03:59] real 0m3.193s [03:59] $ time apt-cache madison [03:59] real 0m0.027s [03:59] Yes, but that only covers your local apt-cache: not so ideal if you're running hardy. [04:00] persia: huh? just add all suites you want to sources.list as deb-src [04:01] $ time apt-cache madison antlr3 [04:01] antlr3 | 3.0.1+dfsg-2 | http://archive.ubuntu.com intrepid/universe Sources [04:01] antlr3 | 3.0.1+dfsg-2 | http://ftp.au.debian.org sid/main Sources [04:01] real 0m0.519s [04:02] lifeless: I suppose, although that can be confusing with trivial use of apt-get source if there is unexpected version skew. [04:03] (and yes, there are ways around that too) [04:03] like putting your distro's version at the top of sources.list :P [04:04] Well, no, that's insufficient. If the versions are the same, it will pull from the top, but if a lower entry has a newer version, it will pull that instead unless you set priorities for the sources. [04:05] This distinction is unlikely to be important for intrepid, but can be useful if e.g. Debian has a new upstream version and we want to backport some of the fixes to fix our bugs without pulling the new upstream version. [04:05] oh hmm [04:05] anyhow, yes - but I know to look closely :P [04:05] So, yes, you can set priorities for the sources, and put them all in sources.list, and everything does the right thing (plus you can specify *which* version you want when you pull, which is nice for SRUs). [04:05] and often do want to grab newer versions, e.g. to see if a backport will play nice [04:06] On the other hand, I tend to have chroots for each distrorelease I may want, and just call apt-get source foo there to get the right data (without looking closely). With that workflow, rmadison is more informative (although it does take a few seconds). [04:07] lifeless: Sure. It entirely depends on one's workflow. If one tends to be focused on a small number of packages, my model is far too much overhead. [04:08] persia: I have chroots too [04:08] but they are on my home server which is fairly regularly ETOOFAR [04:09] Right. I've 16 entries from schroot -l on my laptop, and more on my workstation. Like I said, perhaps too much overhead. [04:28] Hey all, I've put some more work into my pyrocket package - was wondering if any MOTU's are around to advocate? http://revu.ubuntuwire.com/details.py?upid=3240 [04:43] Is anyone on this channel so late? [04:43] kostmo, I am, but I'm not an MOTU [04:43] Just a REVU admin [04:44] any suggestions on the right time of day to find a MOTU here? [04:44] kostmo: It's not late for everyone :p [04:44] MOTU are here all day, every day. [04:45] (There are MOTU from UTC+11 through UTC-7 currently, and more timezones would be welcome) [04:45] i c [04:46] Which reminds me: MOTU Meeting in 15 minutes in #ubuntu-meeting !!! [04:46] i would say that the channel is more active while i'm sleeping (on europe work tine) [04:46] can I pitch my package at the motu meeting? :) [04:46] kostmo: Please don't. [04:46] persia: i almost forgot it! [04:47] oh noes! a meeting! [04:47] sure [04:47] I guess I'm having a difficult time finding interested MOTUs - my package serves a pretty niche function [04:48] kostmo: What does your package do? Why is it cool? Why should it be included in Ubuntu? [04:49] kostmo: most people find that, i think... [04:49] My package "pyrocket" is a driver for several of the USB rocket launchers that you might find on ThinkGeek or other novelty shops [04:50] heh [04:50] geek toys [04:50] It exposes a few features of the devices that aren't accessible from the Windows drivers [04:50] Haha [04:51] kostmo: Such as? :-) [04:51] kostmo: persia is a toy lover, but only if can get it out of his pockets and people would say "ooohhhhh!!!" [04:51] persia: don't you? [04:51] Bwahaha [04:52] I'd definitely be interested in such a device, and *very* interested in the driver. Unfortunately, I've not seen any of the cube-warfare class of stuff in local shops. [04:52] i forgot how HORRIBLE gentoo was [04:52] * nxvl rm -rf vm [04:52] nxvl, why are you running gentoo O_o? [04:52] For example, on one of the Dream Cheeky launchers, my program allows super fine control of the aiming mechanism, where the bundled Windows application only allows rough positioning [04:52] NCommander: just for vm fun [04:53] and I have a webcam interface that's begging for some augmentation with computer vision [04:53] nxvl, ugh, BTW< the comment about persia's toy will forever be etched into my mind. Just like COBOL77, and brainfuck (also goes by the names MIPS assembler, and dak) [04:53] to auto-track your missile targets [04:54] NCommander: See, if you'd actually seen my smallest laptop, it wouldn't be so disturbing :) [04:54] (Sharp 922SH) [04:54] heh [04:54] * nxvl love's persia's laptop [04:54] persia, my mental image of you now involves a trenchcoat, a hat, and ... [04:54] ugh [04:54] * NCommander twichs [04:54] * persia a [04:55] * NCommander hides from persia [04:55] * persia has the trenchcoat and the hat, even the special trenchcoat liner with extra pockets [04:55] Speaking of which, persia , you need to merge your REVU accounts [04:55] he doesn't use any case or backpack or nothing, just his belt [04:55] NCommander: Why? I already have too high a number in statistics. [04:55] persia, I guess you don't miss your reviewer status ;-) [04:55] nxvl: I don't wear a belt: pockets always win [04:56] persia, as an advocate, I suppose you would want to be able to run the program with the device yourself? [04:56] heh [04:56] ok [04:56] NCommander: I'm an admin: I fixed that with a sledgehammer when I discovered it. [04:56] s/belt/where the belt should be/ [04:56] persia: better? [04:56] without context, this conversation would probably persia on some of those predator watch lists [04:56] * NCommander unfixes it, and then modifies REVU's code to reject alter_user.py -n persia ;-) [04:57] * persia wants the sledgehammer back [04:57] * NCommander uses it on persia [04:57] Unless of course you vote yes to me becoming a contributator developer so I can get the shiny @ubuntu.com email [04:57] I was wondering if maybe I should post a video on youtube of pyrocket in action, since not a lot of MOTU's probably have the hardware themselves [04:58] * persia is amused to note that earthquakes sound like thunder when one is sufficiently close [04:58] Anyway, #ubuntu-meeting is the place to be ... [04:58] * NCommander thinks persia should go AFK, earthwake [04:59] persia, when's the next motu meeting? [04:59] NCommander: Now. [04:59] wow [04:59] Amazing timing I choose to bitch at the right time :-) [04:59] ScottK: did you get change to review the merge? [05:00] StevenK, are you a MOTU? I could go into more enticing details about pyrocket if it would generate interest [05:00] kostmo: is pyrocket in revu? [05:00] ScottK: you around? [05:01] yup: http://revu.ubuntuwire.com/details.py?upid=3240 [05:01] nxvl: Patch failed for me again. Only a little. [05:01] LaserJock: Barely. [05:01] ScottK: on patching? [05:02] ScottK: nvm then, I've got some questions about matplotlib (maintained by python-modules-team) [05:02] btw, I just added support recently for another model - the Striker II USB Laser Guided Missile Launcher [05:02] LaserJock: OK. How about tomorrow. [05:02] ScottK: I can ask another day if you're busy/tired [05:02] ScottK: np [05:03] the rockets for Striker II are pretty lame, but at least you get a pan/tilt USB laser pointer [05:03] C [05:03] Bah [05:04] Call me when some Patriot Missle Systems get USB connectivity. [05:05] They just had one of these launchers on woot.com [05:05] and one guy was asking if they work on linux: http://www.woot.com/Forums/ViewPost.aspx?PostID=2327015&PageIndex=1&ReplyCount=47#post2327044 [05:06] and yes, they do - but they need my package [05:06] kostmo: the pachage has a needs-packaging bug on LP? [05:07] nxvl: yes, here: https://bugs.launchpad.net/ubuntu/+bug/242910 [05:07] Launchpad bug 242910 in ubuntu "[needs-packaging] pyrocket" [Wishlist,In progress] [05:09] even though they're kind of random toys, I think having support for them in Linux is a positive thing for linux adoption in general [05:10] StevenK, I do have plans in the next release for automatic tracking of targets, if that counts [05:10] not quite a Patriot missile, but a step in the right direction [05:11] Maybe a dumb question, but when doing get-orig-source, should the tar end up the same name as the package name that i'm aiming for in the repo? [05:11] This guy has a webcam built into it, if you haven't seen it before: http://dreamcheeky.com/index.php?pagename=product&pid=41 [05:16] tgm4883_laptop: It should be $(package-name)_$(version).orig.tar.gz [05:17] persia, right, so for instance, if I was making mythstream-parser-youtube and the downloaded tar was just named youtube4.tar.gz I would want it to end up as mythstream-parser-youtube_4.orig.tar.gz [05:18] * SolarWar is looking for advocates (http://revu.ubuntuwire.com/details.py?package=qlix) Its a package of an (awesome) GUI application that allows users to sync music to Zunes and other MTP devices [05:18] tgm4883_laptop: Right. Note that if you don't need to mangle the tarball manually, uscan will create a symlink for you. [05:19] persia, awesome, thanks [05:24] I'm wondering if I would need to find a MOTU with USB rocket launcher hardware in order to advocate pyrocket? [05:33] kostmo, i don't think advocators care about whether the software works, just that the packaging adheres to standards [05:34] SolarWar: Well, it's supposed to be both, although testing is typically minor. [05:35] i see [05:35] moin [05:35] I'm trying to decide whether SolarWar is trolling me [05:35] hrm? [05:36] SolarWar: "advocators don't care if the software works" :) [05:36] actually I was wondering what degree of responsibility MOTU's do have for the functionality of the package [05:36] slangasek, did you mention something to contrary earlier? I was afk for a bit [05:36] :) [05:37] slangasek, i think it would be fairly difficult to test packages that require certain hardware, whether its rocket launchers or MTP devices [05:37] SolarWar: no, I didn't; I'm just musing to myself whether you're trolling, since I'm predisposed to flying into a rage at people who don't take responsibility for the quality of packages that they upload :) [05:38] SolarWar: Generally we like to have at least one good test report from a MOTU, or several good test reports from non-MOTU. [05:38] In the case of awkward hardware, there is sometimes a call for testers (one example would be a new DVB app in hardy) [05:39] is it appropriate to post requests for MOTU advocates or testers on the motu mailing list? [05:39] kostmo: We prefer not for advocates. If you've one advocate on the packaging, and can't find a tester, that would be appropriate. [05:39] slangasek, I didn't know that about your personality :) good to know- by quality of packages you don't mean the packaging itself, but the upstream software right? [05:40] SolarWar: I mean that the package as a cohesive whole should be usable... :) [05:40] (and integrate well with the system) [05:40] (also- i didn't mean to troll, no one who has commented on my package has said anything about well the upstream program works, but i welcome bugreports since i'm the author!) [05:40] persia, oh, okay- that sounds fair [05:41] so there's the whole "polling" vs. "interrupt" thing that contrasts IRC with the mailing list [05:41] it can be quite a time investment to troll for interested MOTUs [05:42] and I mean "troll" in a good way [05:43] I feel like to catch the attention of someone that might be interested, I would want to repost the same info on IRC at some frequency [05:43] kostmo: Indeed. The optimum frequency is about every 30 hours, to both hit MOTU in all timezones, and not get below 24 hours (which makes some people refuse to review). [05:44] It's less bad when we have organised REVU Days, but this cycle we've not been very good about organising those. [05:44] * SolarWar has been yelled at for pitching Qlix [05:44] too often. [05:44] \me is glad he is not SolarWar [05:44] * kostmo is a bit new to irc [05:44] i *like* being me [05:45] Each person does best being themselves, and we are each that because of our interactions with each of the rest of us. Ubuntu. [05:45] nice. [05:51] so, I keep on getting: W: bzr-upload source: native-package-with-dash-version [05:51] and I can't quite put my finger on what I'm doing wrong [05:51] any ideas? [05:52] is the .orig.tar.gz file missing from your parent directory? [05:52] (or misnamed) [05:53] it's there. It may be misnamed. It should be the exact name as the parent dir? [05:54] moin warp10 [05:55] hi emgent [05:58] slangasek, solved it, thanks (permissions issues) [06:00] When updating a packaging for a new upstream version, what do I do with the debian patches that are in the previous version package? [06:02] xnevermore: Review them. Apply those that are still required, or fix useful bugs. Drop those that are adopted upstream or rendered irrelevant by upstream changes. [06:05] I have a question about package maintenance: I know that getting a package initially accepted into Universe requires 2 MOTU advocates. Once that package is accepted, if the Upstream author releases a new version, how does the repackaged version get accepted back into Universe? [06:05] is it 2 motu's each time? [06:05] No. [06:05] Someone files a bug asking for a new version, and attaches the updated diff.gz. That requires one MOTU to sponsor the new version. [06:05] kostmo: Nope, just ask for sponsorship [06:06] ok, thanks [06:07] Mind you, the testing requirement for new upstreams is usually more strictly enforced, so for a rocket launcher, your choices may be more limited. [06:08] persia, which choices do you mean? [06:08] kostmo: choices for sponsors [06:09] Are there any MOTUs around that would be willing to review my awesome gesture recognition application? [06:09] It's very well-received, see http://ubuntuforums.org/showthread.php?t=837032 [06:10] TomJaeger: The URL to the app is likely a more powerful incentive than the URL to comments about it :) [06:10] Also, there's a MOTU Meeting on now, so few people are likely to review. [06:11] I was especially curious about the sponsorship requirements - because I'm wearing both hats - as the upstream developer and the packager - I have some really cool computer vision stuff in the works for "pyrocket", but I'm trying to decide whether it would be best to get it into the initial version, or a later release [06:12] Sorry, didn't know about the meeting. [06:13] Anyway, the website of the app: http://easystroke.wiki.sourceforge.net/#content [06:13] TomJaeger: And the REVU link? [06:13] persia, your suggestion to TomJaeger brings a question to mind for me - would polling Ubuntu Forums for user interest in "pyrocket" make a persuasive argument for MOTU advocacy? [06:14] kostmo: Not pursuasive, although it may help with the testing requirement if no MOTU has the hardware. [06:14] It's on top of this list: http://revu.ubuntuwire.com/details.py?package=easystroke [06:14] There you go :) Now anyone who isn't busy in the meeting can get to a place to do the review with one click. [06:14] so MOTU's are unswayed by the din of the masses [06:18] kostmo: I've heard they're more easily swayed by bribes [06:19] I have some high quality USB rocket launchers... [06:20] * kostmo is off to code up a sweet rocket launcher demo to win MOTU favor [06:22] good morning === dholbach_ is now known as dholbach === superm1 is now known as superm1|away === dholbach_ is now known as dholbach [06:31] if I have to alter a dpatch, should I rename it? what other changes do I have to make? [06:32] xnevermore: No. Just document that you've changed it in debian/changelog [06:32] ScottK: do I add a credit to myself in the patch itself? [06:33] It's a judgement call. For a minor change I wouldn't. [06:33] alright. fair enough. thanks [06:37] persia, your comment still puzzles me. If I can demonstrate that users like my application and that I stand behind it and listen to my user's concerns, surely that's more important than having a shiny homepage? (Which frankly, I don't because I'd rather spend my time improving the software than with marketing) [06:37] hiya nxvl :) [06:37] TomJaeger: Not the homepage: the REVU page. Having a quick click to review tends to make reviewers more likely to actually perform the review. [06:37] It's not about the application homepage. [06:38] dholbach: :D [06:38] Many reviewers will look at an application on it's own merits, rather than looking for a strong userbase, so the interested users may not matter to the reviewer, as long as the application is good and the packaging is done right. [06:38] well I'd already posted the REVU link a million times, that never accomplished anything [06:39] dholbach: time for GBJ is reaching [06:39] actually we are on GBJ time NOW [06:39] yeah and I look forward to it :) [06:39] I'm going to mail all organisers in a bit [06:40] i'm very excited about that, i have just been noticed that the Gnome dev, the debian deb, the OOo guy and the kde contributor are going to be there! [06:40] it's awesome [06:41] "the" Gnome dev? [06:41] Isn't that Vincent? [06:41] * StevenK hides [06:41] slangasek: you know... the guy who wrote GNOME [06:41] heh [06:41] The guy who started it doesn't work on it any more [06:41] the peruvian gnome dev [06:41] oh, we're talking about Peru :) [06:42] we have one on each project [06:42] one in ubuntu, actually 2 now [06:42] one in debian (actually 2 now counting myself) [06:42] one in gnome [06:42] so "the Debian dev" == Rudy Godoy? [06:42] one in KDE, and one in OOo [06:43] yup [06:44] ah, well, say hi to him for me then. :) [06:44] i will! [06:44] he's a good friend of mine [06:44] the FOSS community in peru is really close and small [06:46] slangasek: are you busy or have some time to review a package update? [06:46] nxvl: I'm busy trying and failing to detach myself from the computer so I can sleep [06:46] heh [06:46] :D [06:46] i'm on the same problem [06:46] :D [06:47] but my packages are waiting for me [06:47] i've just noticed that augeas released a new version [06:48] persia, I'd be happy if I had gotten MOTUs interested on "the app's own merit", but that hasn't been the case, so what was I supposed to do? It seems to me that you don't have the manpower to review every package, so I felt it might be helpful to tout the app a little bit, rather than just being annoying. [06:48] persia: Explain. [06:48] persia, yup [06:49] TomJaeger: Understood. This cycle has been incredibly poor for REVU. At the recent MOTU Meeting, we've had a couple people who might help get REVU working smoothly again, which may help you. [06:50] So, to provide context: I was asked " What do you think about individual maintainers for packages not in Debian.", to which I said I was very strongly against it. [06:50] agreed [06:50] we don't work that way [06:50] The reasoning for this is that I think we operate best as a team, and one of my favorite things about Ubuntu Development is that we work collaboratively. [06:50] But we do have packages that have a Maintainer (@ubuntu.com) [06:51] Sure. It's allowed. [06:51] But that doesnt't stop NMUs here [06:51] That said, I've nothing against smaller teams declaring support for a set of packages, but that's different. [06:51] NCommander: Yes, but I don't like that anyway (and we don't even acknowledge the concept of NMU usually) [06:51] Note that there is value to having packages specifically maintained. [06:51] I personally don't have an issue with individual maintainers as long as anyone form the MOTU team can update a package [06:52] I think that is best expressed in Ubuntu by subscribing to the package in LP, filing regular update bugs, and working with upstream (documenting this in the bugs), [06:52] If someone is doing a good job of this, others are likely to leave them to it. [06:52] So why not mark the maintainer then? [06:52] Since that's essentially what they are doing [06:52] Further, if someone has demonstrated expertise in a package or set of packages, others are likely to point to them when an opinion is sought. [06:53] NCommander: yes, you can use the maintainer field with your name, but NMU are allowed and don't need special versioning [06:53] Right [06:53] NCommander: Because I simply don't see *any* value in marking the maintainer: what is the point? [06:53] and people are free to change the maintainer field if they feel like [06:53] By having your name in the Maintainer field, it makes it offical your the first person you go to support, and who handles it [06:53] persia: My use case is if you want your package in Ubuntu, you have to volunteer to maintain it. [06:53] NCommander: Except that we delete that information from all binary packages. [06:54] ScottK: I don't agree with that: I'd rather have things get in because people are interested, and get dropped if they cannot be maintained. [06:54] let me rephrase [06:54] persia: well, the possible advantage I see is having a way to flag that a package has ended up de-facto orphaned [06:54] ScottK: yes, but it doesn't stop the community to work on your package [06:54] slangasek: We have that: http://qa.ubuntuwire.com/uehs/ [06:55] It's a rare case that anything appears on UEHS for long if it isn't orphaned (and yes, that includes packages orphaned in Debian) [06:55] ScottK: i have some package with my name in the Maintainer field, but i won't get mad if for example you touch it without asking me first [06:55] Agreed. [06:55] where do the meeting logs go to? [06:55] nxvl: But someone might. I don't like the possibility because it may be misinterpreted. [06:55] persia: what am I supposed to see here? [06:55] the "not in sync with upstream" bit? [06:55] It's just a question if you aren't willing to sign up to mind the package, why should I be troubled to upload it. [06:55] NCommander: irclogs.ubuntu.com [06:55] Into the depths of mootbot [06:55] persia: agreed [06:56] persia: but the only thing we can make against it, is specifically say that on a policy or something [06:56] slangasek: Any of the classes: those with no watch file, those not in sync, or those with no upstream checkable. Note that there are some false posivites in the first and third case, but not so many. [06:56] nxvl: Which means more policy, which I don't like. More policy raises the bar to participation. [06:57] persia: well, it's the false-negatives that concern me [06:57] mmm [06:57] slangasek: Packages that appear maintained and aren't? [06:57]