[00:07] bdmurray: hi [00:07] bdmurray: https://code.edge.launchpad.net/~mathiaz/+patches?start=50&batch=50 [00:07] bdmurray: why is bug 32521 being listed? [00:07] Launchpad bug 32521 in gallery (Debian) "purge doesn't remove all config files" [Unknown,New] https://launchpad.net/bugs/32521 [00:11] bdmurray: same thing for bug 33940 [00:12] Launchpad bug 33940 in mysql-dfsg-5.0 (Debian) "mysql_setpermission broken" [Unknown,New] https://launchpad.net/bugs/33940 [00:12] mathiaz: why on your page? [00:13] bdmurray: yes - and given they're fixed released in ubuntu [00:13] bdmurray: they're not fixed in debian though [00:15] mathiaz: I'm not certain off the top of my head [00:15] bdmurray: the bug link points to the debian project in LP thoughy [00:15] mathiaz: you could try staging and switch the debian task to fixed and see what happens [00:16] bdmurray: so I guess it's because it's still opened in debian that the patch shows up [00:18] bdmurray: you're right [00:19] bdmurray: I've set the bug to fixed released in Debian on staging and it was removed from ~mathiaz/+patches list [00:19] mathiaz: well, you'd guess it [00:19] bdmurray: should I file a bug? [00:20] mathiaz: I don't think so. There is no context for +patches, imagine if you were a debian developer... [00:20] * mathiaz agrees [00:20] bdmurray: well - I'm still interested to have the list of patches in ubuntu though [00:21] ubuntu/+patches then ? [00:23] bdmurray: https://code.edge.launchpad.net/~mathiaz/ubuntu/+patches? [00:23] mathiaz: so from ~me/+patches you want to filter on projects? [00:23] bdmurray: yes [00:24] mathiaz: no I meant launchpad.net/ubuntu/+patches ;-) [00:24] bdmurray: I'd like to have a list of patches I could help with while working on Ubuntu sponsoring [00:24] bdmurray: ubuntu/+patches gives me way too many patches [00:25] mathiaz: okay, a bug seems reasonable but it'd be challenging [00:26] mathiaz: but to be fair I'm new there ;-) [00:26] bdmurray: :) [00:26] bdmurray: that's perfect: some challenge for a newbie ;) [00:32] the kernel needs a rebuild against the new binutils now too for linux-tools, why are we building all of these packages linking to the shared binutils again? === bdrung__ is now known as bdrung === almaisan-away is now known as al-maisan [07:10] Good morning [07:23] good morning === dholbach_ is now known as dholbach [08:08] lool: bonjour Loic [08:11] lool: would you mind if I NMUed debian bug 586261? I'd like to sync it to maverick then, to unbreak calibre [08:11] Debian bug 586261 in python-cssutils "calibre: CSS error on conversion to EPUB" [Normal,Open] http://bugs.debian.org/586261 === hrw|gone is now known as hrw [08:35] pitti: are you DPMT? if you are just commit it there [08:35] lool: DPMT? [08:35] lool: I didn't see a git branch for it in collab-maint, if you mean that? [08:35] Debian Python Modules Team [08:35] lool: no, I'm not [08:36] lool: but last time I uploaded it to Ubuntu only someone came back to me and said "you should have uploaded it to Debian right away" [08:36] or perhaps s/upload/commit/, I don't remember for sure any more [08:36] pitti: Yes, I was Cc:ed to that discussion [08:36] I know about the collab-maint git trees, but it's not there [08:37] pitti: So it's relatively easy to get access to this SVN repo which has packaging for many python packages, I'd recommend you consider asking to be included, you could state you don't intend to maintain any particular pcakage but just try to commit Ubuntu fixes where you can [08:37] pitti: it's in svn+ssh://svn.debian.org/svn/python-modules/packages [08:37] 328 packages ATM [08:37] or probably more in fact [08:38] lool: oh, I'd probably effectively maintain cssutils with calibre [08:38] pitti: I'd love if you'd adopt cssutils then [08:38] pitti: I packaged cssutils as a dep of a package which is slowly going away, and have no strong interest in it [08:38] pitti: Ideally, request DPMT access, and just add yourself to uploaders? [08:39] lool: ok, will do [08:39] lool: I'll mail the list for that? [08:39] pitti: I think so, but you could also ping the admins on IRC [08:40] pitti: Ah the watch file didn't allow upstream versions to use letters in versions [08:41] I had to fix something else, but by and large it was a straightforward update [08:41] lool: uh, I'm not that fancy subscribing to the ML, though [08:41] I don't want to get bug reports for _all_ python modules [08:41] pitti: That's fine, I just PTS subscribe to the package [08:42] pitti: It's kind of a mini-collab-maint, the way I see it [08:42] lool: I mean for asking for commit access [08:42] yeah, I suppose [08:42] lool: whom could I ping on IRC? [08:42] pitti: If POX is around, that would be a good match [08:43] pitti: /join #debian-python@oftc? [08:45] lool, pitti: all DD have write access to the DPMT svn repository [08:45] buxy: Oh right, had forgotten about that change [08:45] ah, nice [08:46] pitti: do you want me to do the new upstream release? [08:46] lool: I'll commit it there, and you upload? [08:50] lool: committed, and new tar is on http://people.debian.org/~mpitt/cssutils_0.9.7~b2.orig.tar.gz [08:51] pitti: thanks, looking now [08:55] pitti: Hmm they are changing the new APIs in the developer releases still, so I hope they are close to 0.9.7 [09:04] pitti: Do you want to be in uploaders? [09:04] lool: I'd like to be, yes [09:16] pitti: Uploaded; thanks for preparing the new upstream release [09:16] lool: merci beaucoup [09:16] lool: so I can upload the next one by myself [09:17] pitti: Sure, any time [09:34] hi all [09:42] pitti: could you review my parted upload to lucid-proposed when you get a moment, please? [09:42] cjwatson: sure, will do right now [09:42] ugh, quite sizable queue [09:42] I got behind :( [09:43] cjwatson: if you are currently attacking it, shall we start on both ends and work towards the middle? [09:43] I can spend some time on it now [09:43] ok :) which end are you attacking? [09:43] * pitti flips a coin and says "end" [09:43] you mean newest? [09:44] oldest, end on https://edge.launchpad.net/ubuntu/lucid/+queue?queue_state=1 [09:44] ok [09:44] but I don't particularly midn [09:44] no that's fine [09:45] * cjwatson tries queuediff for a change [09:46] cjwatson: Is there something wrong with the LP-generated diffs, or is queuediff just nicer? [09:46] don't forget -b, for the full love :) [09:46] wgrant: queuediff is using those now [09:46] Ahh. [09:46] wgrant: but it also parses out the bugs, opens them in the browser, and generates an appropriate sru-accept.py line [09:47] Oh, right, yes. [09:47] I even have a wrapper on top of that which does [09:47] exec queuediff -b "$@" | view - [09:47] * pitti likes looking at patches in vim [09:47] er, wow, what, the gdm diff is weird [09:48] cjwatson: ^ how so? [09:48] structurally the diff seems to be correct? [09:48] cjwatson: NB that the previous gdm is still in -proposed [09:48] but I think it's about ready to go to -updates [09:48] './queuediff -s lucid-proposed gdm' [09:49] has huge piles of weird differences, like lots of deletions from debian/changelog [09:49] the diff in LP looks right though [09:49] -s lucid (or just skip it) [09:49] cjwatson: it doesn't even accept -s lucid-proposed any more, is that really from bzr head? [09:49] oh, I shouldn't be using that? [09:49] I wasn't quite up to date, am now [09:50] cjwatson: LP just generates the diff to the latest version in whichever pocket, so I dropped the pocket bit; it's just release now [09:50] in some cases that's wrong, of course [09:50] but in the vast majority it's the right thing [09:50] yeah, that's fine [09:50] majority ... of cases.. [09:51] If you can work out a better ancestor, give me a yell. [09:51] do you have any spare info about building a live cd without a package designed for this task ? [09:51] i mean from scratch :D [09:51] cjwatson: does the parted SRU require a d-i/ubiquity upload to pick it up? [09:51] no [09:56] In the last weeks, I saw a lot of packages pending a build on sparc; I just got an upload error with one of them (oprofile) [09:56] 2010-06-17 22:18:35 ERROR Exception while accepting: Unable to find source package oprofile/0.9.6-1ubuntu8 in maverick -> http://launchpadlibrarian.net/50512886/oFLBwGIJoMxnRKhJUeWGfwllX3o.txt [09:56] looks like there was a new upload shortly afterwards, but the sparc build had already been scheduled [09:56] the 0.9.6-1ubuntu9 build for sparc has already succeeded and been installed [09:57] so I think you can ignore that [09:57] cjwatson: Indeed, seeing 0.9.6-1ubuntu9 now, the upload failure was 0.9.6-1ubuntu8; thanks [10:02] pitti: I fixed queuediff to handle package names like 'gtk+2.0' [10:03] ah, thanks [10:03] needs some escaping, I figure [10:04] two levels [10:06] whoever is doing sru review thanks [10:06] cjwatson, did you move the previous gdm sru to updates before accepting the new one? [10:07] no ... [10:07] bugger, let me see if I have time [10:08] ok, don't worry otherwise we can get the new version tested and move in a week [10:08] two out of five bugs verified? [10:08] well I talked with pitti about it yesterday [10:08] * cjwatson looks [10:09] 2 of those non verified ones are variants of the one EtienneG confirmed fixed [10:09] haven't checked yet, but most of them should be easy to verify [10:09] ie triggering events on autofs user dirs [10:09] or nfs ones [10:09] autofs is one of the harder ones; I meant the ones sourcing ~/.Xresources etc. [10:10] pitti, that one was not listed in the changelog [10:10] pitti, the .Xresources bug was fixed in lucid already IIRC [10:10] ah, ok [10:10] pitti, your fix just enabled to do the ".xsession" session [10:10] which we didn't include in that upload [10:10] I thought we needed a patch for ~/.xinitrc or similar [10:10] -ETOOMANYDOTFILES [10:11] anyone here use the displaylink drivers? [10:11] bug #586503 is not fixed in the sru [10:11] Launchpad bug 586503 in gdm (Ubuntu Lucid) "/etc/gdm/PostLogin/Default file not run if automatic login is enabled" [Low,Fix committed] https://launchpad.net/bugs/586503 [10:11] right, I was just going to say [10:11] the bug is about postlogin scripts not being run and the fix was one for init scripts [10:11] so how about I copy this, and then you reopen that bug? [10:11] so similar issues but not quite the right one [10:12] cjwatson, would work for me ;-) [10:12] damn, I'm sorry, it won't let me [10:12] ok, don't worry [10:12] cjwatson: not even with -e? [10:12] 2010-06-18 09:12:02 ERROR Could not find source 'gdm/2.30.2.is.2.30.0-0ubuntu1' in Primary Archive for Ubuntu: lucid-PROPOSED [10:12] there was no hurry for those fixes [10:12] pitti: I tried that first [10:12] ok, let's just test the new one then [10:12] let's wait another week and test the new version [10:12] I just want it in lucid [10:12] I just want it in lucid .1 [10:12] it can wait another week in lucid-proposed [10:13] . o O { can we please replace gdm with an xsetbg, readline, and startx shell script? } [10:13] I'm pondering if I should limit the bug numbers in the changelog to things easy to test in next upload though [10:13] we have often issues because 6 of the 8 fixes are tested [10:13] but the update doesn't move because it's not all green [10:14] it certainly makes it less obvious during processing [10:14] even if it fixes 6 bugs and doesn't have any issue [10:14] I have to actually read [10:14] and think [10:14] (fx: sad trombone) [10:16] didrocks: should the main task on bug 33288 still be open? I gathered this was an upstream fix, and maverick has a newer upstream version [10:16] Launchpad bug 33288 in poppler (Ubuntu) "Evince doesn't handle columns properly" [Medium,Triaged] https://launchpad.net/bugs/33288 [10:17] cjwatson: it has been merged in trunk and should be in maverick now, let me see [10:17] maverick just got 0.14 [10:17] cjwatson, didrocks: right, it can be closed [10:17] last time I checked it wasn't in maverick yet, so I kept it open [10:17] I uploaded the new poppler yesterday [10:17] but 0.14 should have picked up all those, I hope? === tkamppeter_ is now known as tkamppeter [10:18] pitti: second opinion on ubuntuone-client: it's a new upstream release, so I'd normally say "please backport instead", but it looks to me as if the new release was entirely driven by the listed bugs [10:19] cjwatson: confirmed, it can be closed [10:19] pitti, it did, there is only one change left in the debian patches for the new version [10:19] didrocks: ok, please do [10:19] done [10:19] cjwatson: process-wise that seems ok, they usually wrap up fixes in new microreleases [10:19] thanks :) [10:19] cjwatson: want me to take a look at the diff? [10:20] no, that's ok [10:50] pitti: skipping landscape-client for now as there's at least one private bug in there that I can't see [10:50] cjwatson: ok; I guess that goes for the older release SRUs as well [10:50] if they want an SRU they can follow the policy and subscribe the SRU team to the bugs :P [10:50] didn't check [10:50] I now hit the kernel package mess [10:51] * pitti starts with mvl-dove === cking_ is now known as cking [11:12] smb: can you please upload a meta for linux-fsl-imx51 in lucid-proposed? (just accepted) [11:13] pitti, There is none needed. Licid's fsl-imx51 is based on 2.6.31 (Karmic) which had no ABI bump [11:13] smb: ah, I see [11:14] ti-omap (2.6.33) would not have needed normally, but had some changes that made it necessary. Its fun. ;-P [11:15] smb: I'll accept the metas once the kernels are built and NEWed [11:15] smb: or do they build-depend on something with the new ABI, so that they'll just depwait? [11:15] pitti, Perfect, thanks. [11:15] pitti, No I don'T think, yet [11:15] pitti: cjwatson: thanks for the sru reviews :) [11:16] smb: OOI, is there any chance linux-ec2 goes away at some point? it doesn't change anything different than the linux source itself [11:17] and frankly I don't have enough time to slam an additional set of 3 tasks (ec, fxl-imx51, ti-omap) to a million bugs, since I think we won't individually verify them anyway on arms [11:17] so I just send out calls for testing to the architecture specific bugs (i. e. not the ones which were already fixed in the linux SRUs); hope that suits you? [11:18] pitti, I cannot say for sure. I might speak wit John about that. But as it also decouples ec2 from the main kernel uploads, I guess it will stay [11:18] uh, and qcm-msm as well [11:19] smb: do you know why http://launchpadlibrarian.net/50319468/linux-ti-omap_2.6.33-502.8_source.changes refers to bug 576274 again? [11:19] Launchpad bug 576274 in linux-ti-omap (Ubuntu) "ti-omap: unable to build due to abi-check failures" [High,Fix released] https://launchpad.net/bugs/576274 [11:20] pitti, qcm-msm will actually goe away [11:20] pitti, I only did that upload one more time because apw spend some work on that. But otherwise its dead [11:20] smb: also, most of the maverick tasks are still open; can you guys please have a look at https://bugs.edge.launchpad.net/~ubuntu-sru/+subscribedbugs?field.searchtext=linux at some point and close out the ones which are still unfixed in maverick? (and actually upload the outstanding fixes to maverick) [11:21] pitti, The reference might be a laps in me cleaning the changelog [11:21] smb: ok, I'll ignore 576274 then, thanks [11:21] it piled up some 370 open bugs which have been fixed in SRUs, but never in the development release [11:22] pitti, Ok, I have a look on that list later [11:22] which violates not only the SRU policy, but also keeps a high potential for regressions [11:22] smb: thanks [11:22] would be nice to make that list actually useful again :) [11:23] pitti, Understandable. :) [11:23] smb: will qcm-msm need a -meta? [11:24] pitti, No, that is another branch based on 2.6.31 [11:24] cjwatson: ok, please keep the linux-meta stuff until the kernels were built and NEWed [11:24] pitti: thanks for the SRU round :) [11:30] cjwatson: are you looking at empathy? [11:30] cjwatson: seems to be the last one in the lucid queue now [11:31] just accepted [11:31] \o/ [11:32] cjwatson: so, should I go on with looking at the kernel bits in karmic, and you perhaps take hardy? [11:32] cjwatson, pitti: thanks for cleaning the sru queue! [11:33] pitti: ok (hardy kernel too?) [11:33] oh, hardy has one as well? [11:33] didn't look into the hardy queue yet [11:36] wgrant: the chkrootkit diff in the hardy queue was generated against 0.47-1.1 in hardy, rather than against 0.47-1.1ubuntu0.1 which is in both hardy-security and hardy-updates [11:38] wgrant: (I've accepted it now; hopefully I haven't destroyed the evidence) [11:58] hardy queue emptied [12:19] cjwatson: Ah, yeah, it only looks in $uploadpocket and RELEASE. [12:20] It should probably know about the... sorta hierarchy. [12:20] yeah === MacSlow is now known as MacSlow|lunch === al-maisan is now known as almaisan-away [13:27] Daviey: Hey [13:27] Daviey: I started working on screen before you attached your branch, but did the same fix along others; thanks for the branch though! [13:29] lool: bah.. [13:29] lool: I guess i won the race. right, right :) [14:11] cjwatson: Can i do the verification for bug # [14:11] bug 583698 [14:11] Launchpad bug 583698 in apache2 (Ubuntu) "[SRU] If /usr/sbin/apache2 is set -x, upgrades fail" [Low,Triaged] https://launchpad.net/bugs/583698 [14:12] I thought it had to be someone from ~sru-verification ? [14:12] no [14:12] Daviey: not really, anyone is welcome to help testing [14:12] you are welcome to confirm that upgrades work [14:13] hmm.. ok https://wiki.ubuntu.com/ArchiveAdministration#Standard case [14:13] * Daviey really feels doc's and policy for SRU isn't clearly defined [14:14] Daviey: https://wiki.ubuntu.com/StableReleaseUpdates#Verification says that anyone can help [14:15] and so do the "please test" emails that we send to the bugs [14:15] pitti: Will this confirms that policy isn't clear, as AA's are working from a different procedure to the rest of us.. And also doesn't make it clear the purpose of ~sru-verification === MacSlow|lunch is now known as MacSlow [14:16] there is a sru-verification team? [14:16] AAs aren't dont verification [14:16] sorry [14:16] tAAs don't do verification [14:16] not with their AA hat on [14:17] pitti: oh i agree.. but according to their page.. they shouldn't be moving from -proposed to -updates unless someone from ~sru-verification has ack'd [14:17] Daviey: as soon as a bug is v-done, they can move it [14:18] pitti: ok, thanks [14:22] Daviey: We went through this issue a while ago and tried to clarify that anyone can test and mark v-done. If there's documentation that's still unclear, let's fix it. [14:25] ScottK: ok [14:42] cjwatson: bug 583698 is marked verification-passed FYI :) [14:42] Launchpad bug 583698 in apache2 (Ubuntu) "[SRU] If /usr/sbin/apache2 is set -x, upgrades fail" [Low,Triaged] https://launchpad.net/bugs/583698 [14:50] Daviey: thanks - I just need to wait for it to build everywhere [14:54] cjwatson: Super, thanks [15:17] cjwatson, have you changed landed in todays iso ? [15:19] no [15:20] I'm in the process of putting them together at the moment [15:20] I keep getting dragged off for other stuff though [15:25] upstart-related question if i may [15:25] trying to create a puppet upstart script [15:26] but service puppet start always hangs while polling sa_family=AF_FILE, path=@"/com/ubuntu/upstart"}, [15:26] does DebianImport working? === bjf[afk] is now known as bjf [16:31] cjwatson: No change rebuild - bug 595978, should be hitting the hardy NEW queue shortly; can you fast track that through when you copy apache*0.17 from -proposed to -updates please? [16:32] Launchpad bug 595978 in apache2-mpm-itk (Ubuntu) "No-change rebuild to handle updated apache source." [Undecided,New] https://launchpad.net/bugs/595978 [16:32] NEW, not UNAPPROVED? [16:32] erm, yes -s orry [16:37] cjwatson: Will that be going straight to -updates, or do you want it to land in -proposed first? [16:38] -proposed please [16:38] cjwatson: dammit, just been upoaded with the -updates pocket [16:39] please reupload, I really don't like accepting things straight to -updates unless it's some absolutely horrible emergency [16:39] cjwatson: ok [16:52] hey there I have a question about Glipper [16:52] I just finished translating it to Polish [16:52] jdstrand, when do sysctl's get applied if the module to which they apply has not been installed by initramfs? For example, net.netfilter.nf_conntrack_acct=1. I figured you might know something about this because of your ufw work. [16:52] and would very much like my translation to be incorporated in the package [16:53] unfortunately, Glipper's upstream hasn't been active for something like ~2 years now [16:53] so I figured it would be better to ask the one who packages Glipper for Ubuntu (since there is no to little chance for new Glipper release) [16:54] is anyone responsible for Glipper here? Synaptic simply reports ubuntu-devel as maintainer. [16:54] tgardner: that is a good question. I would think it would trigger a module load, but I don't know. if ufw is enabled, it ends up loading the modules it needs before running sysctl, so I've not run into this [16:55] jdnf_conntrack can get loaded becasue of kvm et al, but I'm not sure /etc/sysctl.conf is reexamined. [16:55] jdstrand, ^^ [16:57] tgardner: there isn't anything particular magical about /etc/sysctl.conf. it is 'sourced' in /etc/init/procps.conf after the system. if nothing is calling sysctl on that file in initramfs, I wouldn't expect the change to be available will in initramfs [16:58] s/system/leaving initramfs/ [16:58] jdstrand, I'm thinking that in the kvm example host side NAT is not started until the user launches his VM. [16:59] so nf_conntrack won't get installed until way after the usual startup has completed [16:59] tgardner: well, if you have libvirt installed, it will add some NAT rules, so it'll be there [17:00] I can fire up a vm and see [17:00] I wonder about the oddball case where someone just wants to hack in some iptables rules. === MacSlow is now known as MacSlow|capoeira [17:03] $ sudo sysctl -w net.netfilter.nf_conntrack_acct=1 [17:03] [sudo] password for jamie: [17:03] error: "net.netfilter.nf_conntrack_acct" is an unknown key [17:03] tgardner: ^ [17:03] Daviey: last architecture being published now ... === beuno is now known as beuno-lunch [17:03] cjwatson: great! [17:03] jdstrand, thats the exact problem. the key doesn't appear until _after_ the module is installed. [17:03] tgardner: so it won't load the module. I guess if someone is going to do what you are suggesting, they need to add their iptables rules, then apply the sysctl [17:03] Daviey: nothing in hardy-proposed yet? [17:03] tgardner: yeah [17:03] cjwatson: really? [17:04] should be.. /me pokes [17:04] Daviey: is the apache2-mpm-itk upload vital to have at the same time? [17:04] cjwatson: well yes.. apache2-mpm-itk is statically built and if it doesn't go out.. a case of SRU breaking apache sites [17:04] (if people use apache2-mpm-itk) [17:04] meh [17:05] err [17:05] Daviey: you uploaded it to -updates again [17:06] cjwatson: i had it sponsored.. guess they didn't bzr pull [17:07] * Daviey quietly gets frusated with sponsorship. [17:14] Daviey: point me at the bzr branch [17:16] cjwatson: lp:~davewalker/ubuntu/hardy/apache2-mpm-itk/lp595978 [17:16] barely worth it :/ === hrw is now known as hrw|gone [17:17] tgardner: yeah, just to satisfy my own curiosity and to be 100% sure, I can say definitively that sysctl.conf is not examined after module load [17:18] tgardner: but, on the plus side net.netfilter.nf_conntrack_acct defaults to '1' in maverick, but you probably already knew that ;) [17:18] jdstrand, thats pretty much my finding. I think I'll ask this question on the ubuntu-devel mailing list [17:20] Daviey: I think you forgot to pushs [17:20] push [17:20] apache2-mpm-itk (2.2.6-01-1build3.9) hardy-updates; urgency=low [17:23] cjwatson: Quite right, my bad. [17:24] (done now) [17:26] Daviey: nope. I have revno 24 [17:31] cjwatson: Odd, i had pushed [17:31] "Pushed up to revision 25." [17:32] * Daviey branches. [17:33] Branched 25 revision(s). [17:37] oh, there it goes [17:38] uploaded === yofel_ is now known as yofel [17:47] cjwatson: rocking, thanks for your time [17:47] so just need to get that built everywhere (I'll score it up), check that it hasn't exploded, then copy [17:48] cjwatson: Okay, assume you won't need verfication? [17:50] "check that it hasn't exploded" === beuno-lunch is now known as beuno [18:27] pitti, Can I configure apport to report stacktraces on crashes on a per-package basis or is it all or none? [19:30] Daviey: any chance of a quick check of the apache2-mpm-itk build to see that it still basically works? it's published now === jtechidna is now known as JontheEchidna [19:48] could somebody please sponsor bug #596034 ? thanks in advance [19:48] Launchpad bug 596034 in apache2 (Ubuntu) "Please merge apache2 2.2.15-5 (main) from debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/596034 [19:52] BlackZ: wasn't that already uploaded? [19:52] micahg: seems not [19:52] Hello everyone, I have a few projects, particularly a certain game that I would like to clean up (make GPL friendly, etc...) and possibly have it included in the repos. What steps should I take? [19:53] BlackZ: was uploaded about 25 minutes ago [19:53] oh, 1 hour ago [19:53] I didn't noticed [19:53] :) [19:54] marking as 'Fix released' then [19:54] BlackZ: if the bug isn't in the changelog [19:55] micahg: hm? [19:55] BlackZ: LP will auto close if the bug # is in the changelog [19:55] micahg: I know but it's not [19:55] :) [19:56] BlackZ: right, so yes to your question then :) [20:00] Hello, is there any reason because the latest glade is still not packages in maverick? Should I file a bug? [20:01] jjardon, hi, which one is that? does it require to have gtk3? [20:01] no [20:02] seb128, indeed that is no glade package in maverick [20:02] http://packages.ubuntu.com/search?keywords=glade [20:02] jjardon: p.u.c doesn't have maverick yet [20:02] micahg, p.u.c? [20:02] jjardon: it has the same version as Lucid ATM [20:02] jjardon: packages.ubuntu.com [20:03] ah, ok [20:04] well, the latest release (3.7.1) doesnt depend on GTK+3 [20:04] but 3.7.2 will depend on it [20:04] right [20:04] that's why we don't update [20:04] (yet) [20:04] we will likely update when gtk3 is packaged later on [20:05] seb128, makes sense [20:06] BTW, I requested the GTK+3 package for Debian, maybe you are interesed: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585385 [20:06] Debian bug 585385 in wnpp "RFP: gtk+3.0 -- the GTK+ 3.0 user interface library" [Wishlist,Open] [20:08] unity clock is off by one minute [20:09] it seems to be updated just several seconds before each minute [20:09] Okay, just posted a debdiff for messaging indicator support in Liferea: bug #540490 [20:09] Launchpad bug 540490 in liferea (Ubuntu) "liferea should be added to the indicator applet" [Undecided,Confirmed] https://launchpad.net/bugs/540490 [20:09] It calls autogen.sh, though. Would it be better to include autoreconf changes as a (bloody huge) separate patch? [20:10] zyga, there is a bug open about it on launchpad I think [20:10] seb128, ah, good then [20:10] jjardon, thanks, the issue is not to have a bug opened though but somebody doing the work [20:11] jjardon, I've been watching what happens there since we want gtk3 in the next weeks, we will help getting there if that's done yet [20:12] jjardon, slomo has been starting some changes in the debian pkg-gnome svn and there is a launchpad ppa some build as well it seems... [20:12] zyga, check indicator-datetime bugs [20:13]