[00:07] ScottK: so the revolution R people are JUST NOW sending me their packages... === yofel_ is now known as yofel [01:52] So.. how do you make a package for the kernel? [01:53] Or is it pretty much just like any other package? [01:53] https://wiki.ubuntu.com/KernelTeam/KernelMaintenance [01:53] pretty much, just read the knowledgebase [01:54] meaning: "essentially you need to read the KB" [01:54] not: "it's essentially the same as any other package" [01:54] crimsun: I don't get what you mean, is there a wiki or anything? [01:54] :P [01:55] crimsun: thanks [02:00] what is the distinction between PPA and backports? [02:00] or, why would a package only be in a PPA? [02:02] sometimes it doesn't make sense to continuously push to $release-backports [02:02] e.g., daily builds of $package [02:03] so does the frequency of firefox patches push it above that threshold? [02:03] I don't understand your intended question [02:03] why is firefox 3.6 not in backports? [02:03] for which release? [02:03] security patches are too often? [02:04] karmic [02:04] crimsun: wow [02:04] are you not using the ubuntu mozillateam security ppa? [02:04] crimsun: there's a LOT to that... [02:04] ^^ CTho [02:05] CTho: also, backports is not intended for security. [02:05] crimsun: should that be set by default? [02:05] CTho: you're asking questions that I can't answer for an entire distribution. [02:06] i'm apparently not using the mozillateam ppa [02:13] You shouldn't need to. [02:13] Security fixes get pushed via the regular updates process. [02:14] Ubuntu backports are part of the Ubuntu distribution and you can be assured that anything in an Ubuntu backport has been checked by an Ubuntu developer. [02:14] Anyone can have a backport and put anything in it they want, so you need to evaluate them indifvidually and determine if you trust them. [02:14] PPAs are not part of Ubuntu. [02:16] ScottK: Did you mean 'Anyone can have a *PPA*'? [02:16] wgrant: I did. Thanks [02:16] Long day. [02:16] Heh. [02:26] Is it still worth working through FTBFS packages at this stage? [02:54] funkyHat: Yes. [02:54] The fewer FTBFSes we have, the easier LTS is going to be. [02:54] If we need to do an SRU or security update on a package that we can't build, we are in trouble. [03:38] Just finished bug #565152 -- doesn't look like it will be relevant to debian unfortunately as they have a separate ftbfs relating to gcc 4.5 [03:38] Launchpad bug 565152 in memcached "1.4.2-1ubuntu2 FTBFS in Lucid" [Undecided,New] https://launchpad.net/bugs/565152 [03:44] ouch not good i need memcached /me looks [03:46] funkyHat: i havent looked at the debdiff yet, but i noticed you say in the bug that you changed a bit of code, you did this via a patch file hopefully, correct ? [03:47] funkyHat: i actualy would like to see that fixed too so if it all works after a bit of testing i'll sponsor it for ya [03:47] imbrandon: yes, there were already some patches in the package so I added a new one. It's using quilt [03:47] funkyHat: great, give me about ~30 min to look it over etc and i'll sponsor if its ready [03:47] imbrandon: great ⢁) [04:13] IIRC there was a memcached upload earlier today. [04:14] Ah, which didn't build either [04:14] * ScottK lart's zul. === RoAk is now known as andreserl [04:17] lol [04:18] this one looks fine, still doing a cursory test build though [04:19] funkyHat: looks good build / test install finished fine, patch looks sane, i'm just gonna update your changelog entry to be a bit more desciptive and upload , ok ? [04:21] * imbrandon is really suprised memcached isnt in main [04:22] It's odd, yes. [04:22] Particularly since LP uses it now., [04:22] Then that's probably a bug. [04:23] But if Canonical IS doesn't care, why should I? [04:23] Heh. [04:23] lol === RoAkSoAx is now known as andreserl [04:26] funkyHat: uploaded [04:27] wgrant: just out of curiosity ( if you know ) what does LP use to run its python stack ? apache ? [04:28] err apache2 + mod_* === andreserl is now known as roaksoax [04:30] Not in the queue yet. [04:31] ScottK: [ubuntu/lucid] memcached 1.4.2-1ubuntu3 (Waiting for approval) [04:32] imbrandon: haproxy in front of Apache in front of a Zope server running on Twisted. [04:32] There it is. Let me have a look.... [04:32] wgrant: ahh sounds like a fun job for the IS guys/gals === roaksoax is now known as andreserl [04:34] Nice. [04:34] imbrandon and funkyHat: Accepted. [04:34] ScottK: thanks [04:34] funkyHat: and thanks for looking at the bug [04:34] * ScottK hearts queuediff [04:35] i have fell in love with offlineimap, i have no idea why i never used the GREAT tool untill this week [04:36] You were participating in the movement to avoid email at all costs? [04:36] imbrandon: Would you mind taking a look at libgda4 and making a recommendation. It's FTBFS in lucas_' rebuild and we're several upstream versions behind. What's the shortest/safest path to something that builds. [04:37] persia: lol [04:37] ScottK: sure [04:37] Thanks. [04:39] ScottK: upstream or upstream;upstream ? ( did that make sense ? e.g. Debian or further up ) [04:39] imbrandon: Debian. [04:39] k [04:40] my gut says a sync but lemme look at our deltas and such though [04:40] ( havent even looked yet ) [04:41] ScottK: That reminds me. I should see how hard it is to hook the diffs up into the UI. [04:41] * wgrant suspects three lines of template should do it. [04:41] Nice. [04:57] dget http://ftp.de.debian.org/debian/pool/main/libg/libgda4/libgda4_4.0.8-1.dsc [04:57] err [05:00] ScottK: it looks like it can be just a solid sync, they have adopted all our deltas ( even the ones they dident need specifcly for debian , how nice of them ) BUT it might ftbfs on x86_64 [05:00] thats what i'm checking now [05:00] per lp bug 537379 [05:00] Launchpad bug 537379 in libgda4 "Sync libgda4 4.0.8-1 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/537379 [05:00] OK. [05:00] Also look at the rdepends and see if it might affect any of them negatively. [05:01] yup [05:03] suprisingly it has very few rdepends, but ya checkign them [05:07] imbrandon: BTW, this one is in Main, so it's useful for your core-dev reactivation [05:12] ScottK: i noticed ;) [05:56] ScottK: looks like it builds fine on x86_64 too [05:56] dunno why it is not in debian [05:56] Cool [05:56] anyhow looks like a solid sync, all deltas are accounted for, i'll say so on the bug [05:56] if you wanna do the honors [05:56] rdepends are also fine [05:56] there are only 3 real ones and none will be affected [05:58] done [05:59] imbrandon: File the sync request then and give me the bug number so I can ack it. [05:59] Explain how much you tested it [05:59] ok [06:08] ScottK: bug 537379 [06:08] Launchpad bug 537379 in libgda4 "Sync libgda4 4.0.8-1 (main) from Debian unstable (main)" [Low,New] https://launchpad.net/bugs/537379 [06:11] imbrandon: Ack'ed. Thanks. [06:11] imbrandon: Want another one? [06:13] sure [06:18] imbrandon: How about flite3 ee http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi [06:19] imbrandon: err flite 1.3-release-2 [06:19] k [06:20] strange ver nums ;) [06:21] sf.net hosts thinkgeek ? wow never knew [07:14] ScottK: please check bug 565207 [07:14] Launchpad bug 565207 in flite "Sync flite flite-1.4-release-2 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/565207 [07:27] ScottK: btw per the jorge and planet ... [07:27] * imbrandon hugs ScottK [07:49] ScottK: bug updated ( FFe info added ) [08:17] ScottK: ping === azeem_ is now known as azeem [11:46] hi, I'm looking at pushing a fix to bug 64917 into my ppa. I've added a libwebkit-dev Build-Depends: into the debian/control.in file, but I can't work out how to regenerate the debian/control file from it [11:46] Launchpad bug 64917 in rhythmbox "Description of podcast episodes doesn't support HMTL formatting" [Wishlist,Fix committed] https://launchpad.net/bugs/64917 [11:54] dutchie - the debian/control file should be regenerated automatically when you build the source package (debuild -S) [11:54] AFAIR it's regenerated as part of the clean target [11:55] ok [11:58] dutchie - /usr/share/gnome-pkg-tools/1/rules/uploaders.mk has the hook for regenerating it, in case you are curious [11:58] cool, thanks === traveller_ is now known as traveller [16:01] Would any MOTU have a chance to approve the merge of a SRU to {Karmic, Jaunty, Intrepid} in bug 301190? (already been approved by ~ubuntu-sru) [16:01] Launchpad bug 301190 in etoys "etoys does not launch" [High,Fix released] https://launchpad.net/bugs/301190 === Zic_ is now known as Zic [16:48] can someone review a patch for me in lucid libruby? [16:49] bug 561432 [16:49] Launchpad bug 561432 in ruby1.8 "Improper undefined method error" [Undecided,New] https://launchpad.net/bugs/561432 === yofel_ is now known as yofel [18:33] lfaraone: thanks [18:35] kobrien: no problem. looks fine, but I'm not a MOTU :) [18:37] lfaraone: ah, I see. so what happens next? [18:38] kobrien: we wait for a sponsor (who *is* a MOTU) to go through the sponsorship list and commit your fix. [18:38] lfaraone: you aren't? i thought you were. [18:38] hyperair: are you? [18:38] * hyperair is. [18:39] a motu with no time. [18:39] I see, I know my patch works. Wouldn't take long :). [18:39] wait until after my exams and i'll look through anything you like. [18:39] hyperair: heh, thanks, feel free to mention that on https://wiki.ubuntu.com/LukeFaraone/MOTUApp when you *do* have time :) [18:39] lol, I know the feeling [18:39] lfaraone: sure ;-) [18:39] kobrien: glad you understand =) [18:40] hyperair: I've got 2.5 weeks to finish off my project and thesis. :) [18:40] hyperair: actually, I just remembered ruby is in main, so we'll need to snag a core dev. [18:41] well, I'm sure a motu will get to it. As soon as the thesis is done, I'm full steam for becoming a motu. :) [18:41] kobrien: i've got 6 days to cover 2 months worth of study backlog ;-) [18:41] RoAkSoAx: ping [18:41] kobrien, pong [18:41] hyperair: good luck [18:41] kobrien: thanks [18:41] * lfaraone seconds kobrien wrt hyperair. [18:42] lfaraone: thanks [18:42] kobrien, how may I help you [18:42] RoAkSoAx: are you a motu? [18:42] i guess that's how grim my situation is eh >_> [18:42] kobrien, yep [18:42] good you review a patch for me? [18:42] could* [18:42] kobrien, bug? [18:42] kobrien: you don't just need a motu, you need a core dev. [18:42] bug #? [18:42] RoAkSoAx: bug 561432 [18:42] Launchpad bug 561432 in ruby "Improper undefined method error" [Undecided,Fix released] https://launchpad.net/bugs/561432 [18:42] oh ok, I misunderstood [18:43] kobrien: I misspoke earlier, no worries. [18:44] kobrien, ruby is in main so you'll need a core dev [18:45] RoAkSoAx: thanks. Seeing as how someone has subscribed "ubuntu sponsors" and "ruby motu" to the bug, do I need to do anything more? [18:46] be patient :) [18:46] cool cool. :) [18:47] geser: hm. that won't make it into lucid, will it... [18:47] kobrien, nope, just wait for someone to review it and upload it [18:47] RoAkSoAx: cheers [18:47] RoAkSoAx: but while we have your attention, could you review the merge proposals for SRUing bug 301190 ? [18:47] Launchpad bug 301190 in etoys "etoys does not launch" [High,Fix released] https://launchpad.net/bugs/301190 [18:47] lfaraone: hard to tell [18:48] RoAkSoAx: (it's the same change in each SRU, and I tested/built each in their own VM) [18:50] lfaraone, ok will take a look at it [18:50] RoAkSoAx: thanks :) [18:53] eh, someone has changed my bug to wishlist but I really don't agree. [18:53] feedback? [18:54] ah, it's RoAkSoAx :) [18:55] kobrien, whenever you subscribe to ubuntu-sponsors you changed the bug to confirmed, and if possible, to wishlist [18:55] i see, so is it still considered a bug, cause it is incorrect behaviour of the code? [18:56] lfaraone, I'd get approvel from ubuntu-sru first, and then I'll sponsor your upload. And could you please provide buildlogs (of PPAs if possible) to test it? [18:56] RoAkSoAx: uh, I thought persia approved it when he accepted the SRU request. Did I miss something? [18:57] lfaraone, i dont see any sru ack [18:58] I didn't approve anything but the nomination. [18:58] lfaraone, ^^ [19:00] kobrien, yes whenever you subscribe to ubuntu-sponsors mark the bug as confirmed [19:00] RoAkSoAx: personally I can't [19:01] kobrien, btw... I just saw that ruby1.8 is using a patch system. You should make your change in a patch [19:02] RoAkSoAx: debdiff won't work? there's a link in the bugreport to a ruby site with a patch. [19:03] kobrien, yes you have to attache the debdiff, however, you are modifying the source directly. You need to create a patch and make the change in the patch [19:06] RoAkSoAx: ah, I've found docs, ok. thanks [19:07] kobrien, i have unsubscribe your bug from ubuntu-sponsors for now, subscribe again when you made the proper changes.. [19:08] RoAkSoAx: ok, understood [19:53] persia: my apologies. would you have time to review the attached branches? [19:56] lfaraone: I can't approve an SRU: you really want someone in the SRU team. [20:01] jdong: poke. [20:03] lfaraone: yeah, what bug number? [20:04] jdong: bug 301190 [20:04] Launchpad bug 301190 in etoys "etoys does not launch" [High,Fix released] https://launchpad.net/bugs/301190 [20:05] *looking* [20:05] apologies, I'm a bit behind in my SRU bug tracking. [20:06] jdong: no problem, I only posted it two days ago :) [20:07] lfaraone: ok, you've got a SRU ack :) [20:07] I do like the shiny new workflow with bzr :) [20:12] jdong: you and me both. I detested debdiffs, and the pretty colors make it easy to review. [20:12] RoAkSoAx: see above :) [20:12] debdiffs rock. [20:12] lol and I started a war ;-) [20:12] ;-) [20:12] hyperair: but when you need to make a fix you need to build a new source package, generate the debdiff, upload it as an attachment... :P [20:13] (vs. "commit, push, wait") [20:13] lfaraone: actually no you don't. [20:13] lfaraone: the thing about debdiffs are that... they are diffs. [20:13] lfaraone: any -p1 diff would do. [20:13] hyperair: good point :) [20:13] my workflow is: git diff , and fire off an email [20:14] well, we'll have both methods working for the immediate future; I don't think anybody's suggesting we dump them, I just think new people may find it easier. But I should shut up, since I havne't done testing. [20:15] lfaraone: there are many who share that opinion [20:15] lfaraone: but i just dislike bzr. [20:21] * ScottK tried the new way and found it slower and more complex so far. [20:27] ScottK, i tried it, then hyperair informed me (correctly) that the bzr branch on launchpad wasn't the same as the package in the archive. which annoyed me [20:28] I can imagine. [20:28] given i'd spent my time preparing a bunch of changes which were already in the archive but not in bzr [20:29] directhex: interesting. usually it is only 12h behind or so. [20:30] 12h is way more than 0h [20:30] Laney: ideally, we'd use push mirroring :) [20:30] it's a good thing we don't have a release coming, or an un-warned 12h delay between developer doing one thing and being able to make changes to it would be vexatious [20:30] i imagine it must take 12 hours to import all the changes made in the archive into the bzr trees >_> [20:31] I just accidently put Britain's Got Talent on [20:31] * Laney scrubs eyes with acid [20:31] lol [20:31] * ScottK notes a distressing lack of stuff to review in the queue. Please fix stuff. [20:31] * Rhonda sighs. [20:31] ScottK: if you have main upload privileges go upload indicator-application please =p [20:32] Laney, i thought that wasn't until thursday evening [20:32] dunno, check ITV1 if you dare [20:32] I do, but I'm not going to touch that one. Also, stuff I upload, I can't accept. [20:32] ScottK: Good that I asked you to sync wesnoth 1:1.8-1 right ahead, seems my support for parallel build in 1:1.8-2 is giving troubles, at least on Debian buildds. %-/ [20:32] IT'S A FUNNY POLITICS JOKE [20:32] heheh [20:32] oh [20:32] :( [20:32] Rhonda: I was about to ask. [20:33] ScottK: oh yeah, i filed a sync request about nautilus-share. [20:33] Rhonda: Is there anything in -2 we should cherrypick for a -1ubunu1 upload? [20:34] ScottK: The two patches that I pulled from upstream would make a lot of sense, yes. [20:34] bug #565418 [20:34] Launchpad bug 565418 in nautilus-share "Sync nautilus-share (main) 0.7.2-13 from Debian Unstable" [Undecided,New] https://launchpad.net/bugs/565418 [20:34] hyperair: It's best to wait for an archive admin with shell access to deal with the syncs. [20:35] ScottK: okay. === RoAkSoAx_ is now known as RoAkSoAx [20:35] Rhonda: If we could get a bug with a debdiff, then we could get that going. [20:35] ScottK: i think it still needs an ack from someone with main-upload-privileges though. [20:35] hyperair: I don't really know enough about Gnome stuff to have an opinion. [20:36] ScottK: alright then [20:38] how does the rcbugs page look? [20:38] it's always interesting to see "ubuntu1) karmic" in debian changelogs :) http://packages.debian.org/changelogs/pool/main/n/ncpfs/ncpfs_2.2.6-7/changelog.html [20:39] looks like those changes should have been forwarded [20:39] Laney: they were merged back, yes. [20:39] Laney: Lots of bugs on it. [20:39] * lfaraone is currently looking at syncing ncpfs. [20:39] pulled though, not pushed [20:45] ScottK: can you take a look at bug #542634 please? I'm a little bit lost there :/ [20:45] Launchpad bug 542634 in zope.security "Add python-zope.security-untrustedpython metapackage" [Undecided,Incomplete] https://launchpad.net/bugs/542634 [20:45] Sure. [20:45] thanks [20:48] * ScottK is confused too. [20:50] * imbrandon is always confused [20:50] sistpoty: Let's see if we can get an opinion from doko [20:50] ScottK: did you see my note about libgda ? [20:50] imbrandon: I did. I subscribed the release team. I think it's reasonable, but didn't want to decide all by myself [20:50] k [20:51] bdrung: ping ( re: apt-mirror ) [20:51] sistpoty: sorry that I didn't comment on it, but I don't know that part well enough [20:52] k, thanks ScottK and ajmitch [20:53] zope has further turned into small piles of black magic :) [20:53] lol [20:54] ajmitch: it's always been magic :P [20:54] but they've cut it up into smaller piles [20:54] ScottK: do you know if ~ubuntu-archive is still syncing packages? [20:55] imbrandon: pong [20:55] ajmitch: It's a matter if someone has time. [20:55] Should be so. [20:55] so I have to bribe someone, or perhaps change the importance away from wishlist [20:56] Just put something suitable RC sounding in the description. [20:56] "package is burnt toast with php 5.3" [20:57] bdrung: i seen you applied ( and authored ) a few patches in apt-mirror, just wanted to let you know i have commited those to upstreams svn today [20:57] so they will be in the next release ( maybe today if i can get the other patches ready ) [20:58] imbrandon: great [20:58] bdrung: Is Audacious all sorted out? [20:59] imbrandon: one thing that does not work properly: killing apt-mirror with ctrl+c (it kills only a subprocess) [20:59] ScottK: no, two bugs remain: bug #564087 and #564092 [20:59] Launchpad bug 564087 in g15daemon-audacious "FTBFS against audacious 2.3" [Undecided,New] https://launchpad.net/bugs/564087 [20:59] Launchpad bug 564092 in xmp "FTBFS against audacious 2.3" [Undecided,New] https://launchpad.net/bugs/564092 [21:00] bdrung: probably, never thought about it being run interactively, my mindset is normaly run as a cron, but yea i'll have a look at that [21:00] sistpoty: Since you approved the audacious FFe, I think you should help with those. [21:00] imbrandon: thanks [21:00] bdrung: hm. whenever I kill it, the network IO stops, so I assume the threads die with it. [21:00] crap, that's what you got for only checking rdepends but not build-rdepends [21:00] but the lockfile does not go away :) [21:01] lfaraone: yea the lockfile bug is fixed in svn now [21:01] * sistpoty fixes [21:02] excellent. [21:10] sistpoty: and i forgot to check it completely. [21:10] well, yeah, things happen... :( [21:10] lfaraone: do you use the latest version? [21:12] bdrung: no, I mean the version in karmic. Is there a behavioral change in this regard in Lucid? [21:13] sistpoty: I'd appreciate your opinion on Bug 561631. [21:13] Launchpad bug 561631 in libpcap "Lucid Sync-Request FFE libpcap version 1.1.1" [Undecided,Incomplete] https://launchpad.net/bugs/561631 [21:13] *looking* [21:14] lfaraone: yes, the lock file removal is fixed in lucid [21:17] yes, and once 0.4.7 is out i'm going to do a -backport, just need to find enough fingers to get it all done ;) [21:18] imbrandon: backport? [21:18] for apt-mirror to older supported releases [21:18] ScottK: libpcap is in main, and has very many rdepends, I fear I'll need to thouroughly review the entire diff [21:19] sistpoty: I think it's worth considering, but I don't know enough to really decide. [21:29] imbrandon: which releases? [21:31] bdrung: all that are still under support, should be fairly simple given the lax dependencys [21:31] sistpoty: it's a bit big for my comfort, but I understand the discomfort with carrying the current version for 5 years, too. [21:32] sistpoty: I'm happy to help; there seem to be only 3 source packages that b-d on libpcap0.8-dev [21:33] 3 in main, that is [21:35] crimsun: sure, any help is welcome [21:35] crimsun: can you test the 3 packages in main? [21:36] sistpoty: sure. I'll work on that in about seven hours for a stretch [21:36] excellent, thanks crimsun [21:37] crimsun: and if you find anything other noteworthy, just add a comment to the FFe in question [22:00] geser: You TIL rbot. There's a security fix in Debian I think we'd want. Would you please have a look at a merge? [22:03] ScottK: can do. Does the switch to v3 format need a FFe? [22:03] geser: No. [22:04] If that's going to cause problems it'll almost certainly fail to build and we'll know [22:20] ScottK: merged [22:20] geser: Thanks. I'll accept it when it hits the queue. [22:22] * ScottK looks at http://qa.ubuntuwire.com/bugs/rcbugs/ and invites others to find fixes we could benifit from. [22:26] ScottK: do you know if sync requests will be processed in time or should packages get synced with the syncpackage script? [22:27] I don't know for sure, but I think they will. [22:42] ScottK: commented on libpcap. I think I'm ok with getting it in, but I'd like someone else take a look at it as well (crimsun maybe?) and see testing of all rdepends in main [22:42] sistpoty: OK. Please ask for that in the bug. I think we should let slangasek make the final call on this one. [22:43] ScottK: already done. an opinion from slangasek would certainly be preferred :) [22:43] lucas_: Is it possible your last rebuild was done with Main only even for Universe packages? I see a lot of FTBFS due to non-existant packages that do in fact exist in Universe. [22:47] ScottK: the more i look at libgda4-4.0.8 ( and subsuqent fix for ftbfs ) we'll need to push that as a sru when we get the x86_64 worked out [22:47] ( thats the opinion of the DD's too from the gnome team ) [22:47] imbrandon: OK. Thanks for looking into it. BTW, I think deciding stuff shouldn't be uploaded yet should count on core-dev apps too. [22:48] heh [22:49] sistpoty: do you have the bug # handy for that one? [22:49] slangasek: bug #561631 [22:49] Launchpad bug 561631 in libpcap "Lucid Sync-Request FFE libpcap version 1.1.1" [Undecided,New] https://launchpad.net/bugs/561631 [22:50] slangasek: crimsun volunteered to test rdepends in main, but will need a few hours before doing so [22:53] bdrung: do you have the HW to test g15daemon-audacious? [22:53] bdrung: as I've got a trivial fix around now [22:54] sistpoty: no. you can give me 100 euro and i will buy the HW ;) [22:54] If a sync request would fix a bug (say, bug 549692), should I modify that bug, or create a new one? [22:54] Launchpad bug 549692 in paros "paros won't start because it can't find license file" [Undecided,Confirmed] https://launchpad.net/bugs/549692 [22:55] bdrung: haha... then let's just cross fingers that it'll still work with the ftbfs fix (just updating one include directive) [22:58] bdrung: I haven't forwarded the change to debian yet, and am quite sure that I'll forget to do so... can you do that please (if it affects unstable as well)? [22:58] sistpoty: currently it affects only experimental [22:58] bdrung: ah, ok [22:58] sistpoty: didn't we have a tool for sending our changes to debian? [22:59] bdrung: could be... I prefer reportbug after checking on an unstable system though [23:01] to get programm to universe i found i need to post to launchpad request for packaging or package myself. if that is done then i post it to revu but http://revu.ubuntuwire.com/ is down [23:01] ups its forbiden [23:01] Kangarooo: new packages are not being accepted right now, so there's no rush :) [23:01] Kangarooo: hm? revu is down? [23:01] bdrung: submittodebian? never used it personally [23:01] Kangarooo: I'd ask about it in #ubuntuwire [23:01] crap, revu *is* down :( [23:01] * sistpoty fixes it [23:01] geser: yes [23:01] sistpoty: the server itself is down? [23:02] ajmitch: nope, just apache returns a 403 [23:02] submittodebian works pretty well in my experience, but occasionally picks up extraneous changes (like debian/control) [23:02] sistpoty: ugh, that's bad [23:02] ajmitch: not necessarily, looks like md is not mounted [23:02] (where revu resides) [23:03] fun fun [23:04] that's still bad [23:04] ajmitch: or can you take a look, since you're already logged in? [23:04] and what to do if i asked for packaging and someone else packages then will he also post to revu or i need to check LP page and get and post to revu that package? [23:04] yeah I can confirm it's not mounted [23:04] but /dev/md0 isn't looking happy [23:05] Kangarooo: most likely the packaging will not be done unless you do it yourself :) [23:05] is revu still on spooky ? [23:05] sistpoty: the server was rebooted ysterday? [23:05] imbrandon: yep [23:05] ajmitch: i hope this is small problem and server is in cloud :) [23:06] like in cloud computer not rip [23:06] Kangarooo: revu will be fixed, its just a matter of when ( depending on the severity of the issue ) [23:06] Did I update bug 549692 properly to reflect its status as a sync request? (syncing would fix the bug the reporter asked) [23:06] Launchpad bug 549692 in paros "Sync paros 3.2.13-6 (universe) from Debian testing (main) [paros won't start because it can't find license file]" [Medium,Confirmed] https://launchpad.net/bugs/549692 [23:07] lfaraone: but if i post package request then if not me then someone from motu packages it or anyone also who is not motu can do that? (if yes dont answer- i think yes but not sure) [23:08] Kangarooo: somebody *may* package it. if they are not in MOTU, they'll post it to REVU and be responcible for getting it accepted. [23:09] sistpoty: I think someone needs to take a look at the raid setup there, /dev/md0 doesn't want to go [23:10] ok thx. ok now the bigest question this maybe a security issue: is programm put to universe checked by someone like checked All code it contains? [23:10] ajmitch: ok, I'll take a look [23:10] sistpoty: thanks :) [23:10] http://doctormo.org/2010/04/17/input-debian-packaging-guide/ [23:10] sistpoty: g15daemon-audacious accepted. Thanks. [23:10] Kangarooo: uh, yes, that's the purpose of the sponsorship / mentorship guide. [23:10] Kangarooo: * system, I mean [23:10] I'm after some really simple deb packaging guides, I got a few links so far, but they're rather more verbose. [23:10] ScottK: thanks! [23:11] doctormo: The problem is that packaging is inherently complex. Anything simple is wrong or dangerously incomplete. [23:11] Making it simple is an unsolved problem. [23:11]