[00:55] <kklimonda> what is the right pocket to use when preparing a security release for universe package?
[00:55] <kklimonda> lucid-proposed?
[00:55] <micahg> kklimonda: should be lucid-security
[00:55] <micahg> I thikn..
[00:55]  * micahg checks
[00:56] <micahg> kklimonda: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation seems to imply -security for all
[00:59] <kklimonda> right, mplayer is in multiverse and still has a -security pocket
[00:59] <kklimonda> thanks
[00:59] <micahg> kklimonda: made it to universe for maverick :)
[00:59] <kklimonda> finally - if there is one thing I can't live without it's mplayer :)
[01:00] <kklimonda> it should be in main ;)
[01:00] <micahg> kklimonda: well, if you can file an MIR with a good reason, you have a chance now :)
[01:02] <kklimonda> meh, I don't think being the swiss-army knife of media players is reason good enough - especially if what I've heard about code quality is true ;)
[01:02] <persia> main/universe is an outdated distinction.
[01:02] <kklimonda> persia: sure - now we only need few years for us contributors and users to stop making this distinction. :)
[01:02] <persia> The only value to MIR is the code review, but we'd do better to have some override flag that let us identify which packages are reviewed.
[01:03] <persia> kklimonda, Indeed :)
[01:03] <persia> (although we also have to fix the package selectors a bit more, and LP)
[01:04] <kklimonda> persia: what will happen when we finish reorganization? will the universe and multiverse apt components be replaced by ubuntu-core, ubuntu-server, ubuntu-desktop-core etc. ?
[01:04] <kklimonda> that would be mess..
[01:05] <kklimonda> maybe now, that we have ubuntu-status-support, we could just use main..
[01:05] <kklimonda> ubuntu-support-status even
[01:06] <persia> kklimonda, No.  We end up with three areas, which aren't likely to be called "main", "restricted-software", "restricted-drivers", but those names identify the contents well.
[01:06] <kklimonda> makes sense
[01:07] <persia> ubuntu-support-status is part of the work, but unfortunately it's still too narrow.  We have no way of identifying who provides said support, which tends to lead to disagreements about some things (where one person claims they will support it, and another doesn't want to do so, etc.)
[01:08] <persia> So, we'll probably end up with something broader, so that groups like Canonical, Kubuntu Developers, Dell, Mozillateam, Oracle, etc. can claim they support specific sets of packages.
[01:08] <kklimonda> by "who" do you mean which team or is this distinction between canonical and community-based teams?
[01:08] <kklimonda> ah, nice
[01:09] <kklimonda> I guess Oracle isn't exactly "community-based" team *cough* but I get the idea.
[01:10] <persia> I don't like to make distinction between "Canonical" and "Community": my viewpoint is that Canonical participates in the Community.  That said, there's perhaps a useful distinction between artificial people (e.g, Dell), and loose conglomerations (e.g. Mythbuntu Developers)
[01:11] <persia> And while Canonical deserves great thanks for the sheer volume of contribution to Ubuntu, I'm not sure it's very special compared to other corporates who pay developers to work on Ubuntu and support various parts of it.
[01:12] <persia> Well, Oracle also participates: I know for certain that there are Oracle employees whose job descriptions include making sure various things work correctly in Ubuntu.  They deserve thanks for that, regardless of other opinions we may hold of Oracle in general.
[01:12] <kklimonda> persia: well, that's great - wish they showed themselves so we can thank them :)
[01:14] <persia> Coincidentally, better coordination of corporate contributions was brought up at a recent CC meeting.
[01:15] <kklimonda> that would be great if more contributions like it were hilighted
[01:16] <persia> Yeah.  We're pretty good about thanking people who help.  We're less good about thanking organisations that fund people to help.
=== em is now known as emma
[03:33]  * micahg wonders if requestsync is not working for others as well
[03:40] <persia> http://irclogs.ubuntu.com/2010/08/17/#ubuntu-release.txt has some pithy comments about why the use of requestsync is dangerous anyway.
[03:41] <persia> Err, nevermind.
[03:41]  * persia has confused requestsync and sycnpackage again
[03:41] <micahg> persia: yeah, I know about syncpackage
[03:41] <micahg> persia: requestsync is telling me packages aren't in unstab;e
[03:42] <persia> which package?
[03:42] <micahg> sqlite3
[03:45]  * micahg figures this is the last chance to get it updated
[03:46] <persia> I get "E: The versions in Debian and Ubuntu are the same already (3.7.0.1-1). Aborting." trying to run requestsync against sqllite
[03:46] <micahg> persia: yeah, that's because Debian's QA madison is out of date, I'm using the UDD madison
[03:47] <persia> Hrm.
[03:47] <persia> You could just file it manually, not that hard, really.
[03:47] <micahg> yeah
[03:48] <persia> I suspect there's some subtle dependency somewhere on the QA rmadison server
[03:54] <micahg> I filed it manually
[06:01] <tbielawa> Greetings MOTUs, gnu-smalltalk was excluded from Lucid and I would like to have it available. I would like to know what I can do to make this happen.
[06:02] <lifeless> fix up the FTBFS that it was experiencing
[06:02] <tbielawa> Ok
[06:02] <micahg> tbielawa: yeah, it's in lucid, just not built
[06:02] <lifeless> it may be fixed in Debian already, in which case requesting a sync should be sufficient
[06:02] <tbielawa> INdeed
[06:02] <tbielawa> I've been working on this.
[06:02] <tbielawa> Is it possible to have a newer version used in it's place instead, since it was never included?
[06:03] <lifeless> you could get such a thing into backports.
[06:03] <tbielawa> micahg: https://bugs.launchpad.net/ubuntu/+source/gnu-smalltalk/+bug/557290 is relevant
[06:03] <ubottu> Launchpad bug 557290 in gnu-smalltalk (Ubuntu) "Make gnu-smalltalk build on lucid" [Undecided,New]
[06:04] <tbielawa> It sounds like I just need to make the debdiff and let the SRU group know about it.
[06:05] <micahg> tbielawa: well, a debdiff to fix the FTBFS if you want 3.0.3, file a backports request if you want 3.2 in lucid
[06:07] <tbielawa> micahg: The people I'm supporting would prefer 3.2. I'll work on the FTBFS first and then apply for a backport.
[06:08] <tbielawa> Seems more likely that getting the FTBFS fixed would get it included.
[06:08] <micahg> tbielawa: well, i386 is built for maverick, but you probably want to fix amd64 before the backport
[06:09] <tbielawa> You mean amd64 is broke for maverick?
[06:10] <micahg> tbielawa: yep, when I said FTBFS before I was referring to Lucid, amd64 is broke for maverick as well
[06:10] <micahg> https://launchpad.net/ubuntu/+source/gnu-smalltalk/3.2-1/+build/1735324/+files/buildlog_ubuntu-maverick-amd64.gnu-smalltalk_3.2-1_FAILEDTOBUILD.txt.gz
[06:11] <nigelb> g32
[06:11] <nigelb> err, #fail, sorry.
[06:13] <tbielawa> you know, there's a hidden file, .gdbm in the upstream source, I wonder if that got misplaced somewhere
[06:14] <tbielawa> oh, that file says it's contains debugging commands for smalltalk
[06:15] <tbielawa> So for lucid, I should start at https://code.launchpad.net/~ubuntu-branches/ubuntu/lucid/gnu-smalltalk/lucid and fix the FTBFS.
[06:15] <micahg> tbielawa: depends which version you're interested in
[06:15] <tbielawa> I've picked the wrong source for code before and had to redowork
[06:15] <tbielawa> Just fixing the 3.0 FTBFS
[06:15] <micahg> If you want the 3.0.3-2 in archive, yes
[06:16] <tbielawa> micahg: thanks for your help
[06:16] <micahg> tbielawa: np
[06:17] <tbielawa> target in changelog should be lucid, nothing special right?
[06:17] <micahg> tbielawa: lucid-proposed
=== _martin is now known as m4rtin
[06:44] <micahg> Is it worth filing sync requests for a long stream of build deps at this point for a depwait in maverick?
[06:46] <persia> Depends.  If they are independently worthwhile (e.g. pulling in a chain of recent Debian RC-fix uploads), then absolutely.  If they don't seem useful, maybe patch the depwaiting package to not need them.
[06:47] <micahg> it's java stuff, so it seems like circular deps
[06:47] <micahg> but a few of the packages are out of date in maverick comapred to sid
[06:47]  * persia wants specifics
[06:48] <micahg> tiles is depwait on libspring-core-2.5-java which is in the source libspring-2.5-java which requires are newer libhibernate3-java which requires the version of tiles that won't build
[06:54] <micahg> persia: ^^
[06:56] <persia> Ugh.  That's frustrating.  You might ask drazzib (#debian-java@OFTC) for recommendations, but I haven't seen him work much on Ubuntu, so I'm unsure if you'll get quick or useful advice.
[06:57] <micahg> persia: is it worth pulling in something like that though?
[06:57] <persia> I'd say yes: it fixes at least two RC bugs, and a security bug.
[06:58] <micahg> persia: oh, how do I tell that?
[06:58] <persia> But that's only for the three packages you mention: it may be the case that there is more goodness down the stack.
[06:58]  * persia reads abridged changelogs from packages.qa.debian.org
[06:58] <micahg> ah
[06:59] <micahg> well, we have our Global Jam on Sunday, maybe i can get people to help me research these things
[06:59] <persia> heh
[07:00]  * micahg is supposed to review a list of mozilla bugs for the reviews team on Sunday as well
[07:02] <micahg> persia: PM?
[07:27] <tbielawa> micahg: nothing like fixing a FTBFS to end the night. I got that debdiff created but I'm going to test it once more tomorrow before submitting it.
[07:28] <micahg> tbielawa: great :)
[07:57] <raywang> hi, please how to install a deb package without any further post-conf?
[07:59] <persia> Hrm?  How do you mean?  Not running the maintainer scripts?
[07:59] <raywang> persia, well, i guess so
[08:00] <raywang> like when you're installing postfix, and don't want to be interrupted by the post-configuration
[08:01] <persia> Given the volume of things done in the postfix postinst, I suspect you don't really want to not run it.
[08:01] <persia> My recommendation would be to search for docs on debconf preseeding, and ask in #ubuntu-server for specific support once you have some background.
[08:02] <raywang> persia, well, actually postfix is just a dependency here, I don't really need it
[08:03] <raywang> what i want is just a non-interactive installing process, so i have no need to configure it. :)
[08:03] <persia> Yeah, you want preseeding.
[08:03] <raywang> persia, do you have any idea how to ignore the postinst?
[08:03] <raywang> persia, sorry, i don't get it. :)
[08:04] <persia> Again, you *don't* want to ignore the postinst: you want to preseed debconf so it doesn't bother you.
[08:04] <persia> Also, this isn't a good channel for support.
[08:04] <raywang> yeah, you're right
[08:05] <raywang> persia, ok, I want to preseed something for debconf when installing a package, and what channel would be the best? :)
[08:07] <persia> Depends on the package.  I'd probably start in #ubuntu-server, as there's been a lot of work on server packages to be non-interactive, but I'd read the preseeding information in the installation guide (package: installation-guide-${arch}) first, and maybe the debconf documentation.
[08:07] <persia> And you can probably use the knowledge you get with that to apply to any other packages.
[08:07] <raywang> persia, ok, thanks for the guiding. appreciated! :)
[08:08] <persia> raywang, Good luck.
[08:09] <raywang> thanks
[08:09] <dholbach> good morning
=== dholbach_ is now known as dholbach
[09:26] <\sh> maco, very nice blog article ... thx a lot for that :) you rock :)
[09:26] <ajmitch> hey \sh
[09:26] <maco> \sh: thanks :)
[09:26] <\sh> ajmitch, moins :)
[09:27] <maco> the packaging recipes need some love
[09:28] <maco> will have to poke them at a sane time of da
[09:28] <maco> *day
[09:28] <ajmitch> you mean recipes in launchpad?
[09:28] <ajmitch> or some other use of the word? :)
[09:28] <maco> on the wiki
[09:28] <ajmitch> ah
[09:28] <maco> there are packaging recipes... short howto's for packaging that follow some very rote steps
[09:28] <ajmitch> we should rename the wiki then
[09:28] <StevenK> maco: That's a good blog article -- a small itch, if you don't specify the Section for the binary package, it uses the source package's Section
[09:29] <ajmitch> it'll be confusing once LP recipes are in common use
[09:29] <maco> StevenK: oooh computers being logical!
[09:29] <persia> 90% of the time one probably *shouldn't* have the Binary section.
[09:29] <StevenK> maco: Say it ain't so!
[09:30] <maco> i got a comment saying i should switch it for quilt instead of native. you guys think so?
[09:30] <ajmitch> it can be useful
[09:30] <StevenK> Ewww, quilt
[09:30] <ajmitch> because then adding patches is less effort
[09:30] <ajmitch> StevenK: I know you're waiting patiently for 3.0 (git)
[09:31] <maco> StevenK: were you the one who asked me in barcelona when i was going to apply to motu and i answered "when i figure out quilt"?
[09:31] <StevenK> maco: It could be ... I can use quilt, I don't have to like it :-)
[09:31] <StevenK> And I dislike git with fire and brimstone
[09:32] <maco> i need to get better with git so i can have it not be a hindrance as i try to sort out how the heck the kernel works
[09:32]  * wgrant just uses bzr-git
[09:32] <wgrant> bzr-git is awesome.
[09:32] <maco> also.... kde is going git (woo no more svn!)
[09:32] <StevenK> maco: Why do you want to figure out how the kernel works?
[09:32] <ajmitch> not so easy to use git-buildpackage & assorted tools with that
[09:33] <maco> StevenK: because i want to grow up to be valerie aurora?
[09:33] <wgrant> ajmitch: No... you just use bzr-buildpackage.
[09:34] <ajmitch> wgrant: for existing packages in debian, and it does all the proper tagging, changelog entries?
[09:35] <wgrant> ajmitch: It *should* work pretty much fine.
[09:35] <ajmitch> it's when you want to work with a team & sponsor uploads (hi Laney!) that having to use the other tools is frustrating :)
=== arjun_ is now known as arjun
[10:22] <Laney> git-dch <3
[10:40] <bilalakhtar> tumbleweed: Thanks for the review!
[10:45] <tumbleweed> bilalakhtar: hope it was useful
[10:46] <bilalakhtar> tumbleweed: Very much! I am going to apply in the meeting on september the 14th
[10:46] <tumbleweed> cool, good luck
[10:46] <bilalakhtar> tumbleweed: Let me give you a bug. Check if its the right wqay to go
[10:50] <bilalakhtar> tumbleweed: bah, I just filed a bug in BTS, lost its bug number. Hell!
[10:58] <lucidfox> <lucidfox> I wonder
[10:58] <lucidfox> <lucidfox> What is it with Java that makes it so prone to overengineering?
[10:58] <lucidfox> <lucidfox> IHammer hammer = HammerFactoryBuilderImpl.getHammerFactory(new DefaultHammerBindingConstants()).newHammer();
[11:03] <sebner> lucidfox: it's hammer time! \o/
[11:11] <directhex> lucidfox, a desire to avoid inflexibility, i guess.
[11:42] <Zhenech> hyperair, copyright file is not uptodate?
[12:04] <kklimonda> lucidfox: probably because Java naming is so long - developers just decide to go with the flow..
[12:04] <kklimonda> naming conventions*
[12:04] <kklimonda> lucidfox: I love examples like this one - is it a real piece of code?
[12:05] <kklimonda> ;)
[12:05] <hyperair> Zhenech: for geany-plugins?
[12:05] <hyperair> whoops.
[12:05] <Zhenech> hyperair, yepp
[12:06] <hyperair> you mean just debian/copyright?
[12:06] <hyperair> weird, i thought i documented things in there.
[12:06] <lucidfox> kklimonda> No, I made it up, but most real "enterprise"(tm) Java applications have plenty of code like that
[12:07] <hyperair> Zhenech: hmm looks like i didn't. i'll bring it up to date then.
[12:08] <kklimonda> lucidfox: I'd love to find a real example like that - I'd print it, frame it and hang on my wall..
[12:08] <Zhenech> hyperair,
[12:08] <Zhenech> To git+ssh://git.debian.org/git/pkg-geany/packages/geany-plugins.git
[12:08] <Zhenech>  * [new branch]      squeeze -> squeeze
[12:08] <kklimonda> but I can't really stand reading Java code.. and I have an android app in plans :/
[12:08] <Zhenech> look in there :)
[12:08] <hyperair> Zhenech: ooh.
[12:09] <hyperair> Zhenech++
[12:09] <Zhenech> hyperair, i guess it's ok for you that I added myself to uplaoders?
[12:16] <hyperair> Zhenech: sure no problem
[12:17] <bilalakhtar> howdy hyperair
[13:21] <AnAnt> Hello
=== hannesw_ is now known as hannesw
[14:43] <ari-tczew> lfaraone: ping
[14:44] <lfaraone> ari-tczew: yep?
[14:45] <ari-tczew> lfaraone: could you sponsor something for me in Debian?
[14:45] <lfaraone> ari-tczew: what package?
[14:45] <ari-tczew> lfaraone: agg
[14:46] <lfaraone> ari-tczew: new upstreeam version or bugfix?
[14:47] <ari-tczew> lfaraone: bugfix. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575620
[14:47] <ubottu> Debian bug 575620 in libagg-dev "libagg-dev: no #include for INT_MAX and abs" [Minor,Open]
[14:56] <lfaraone> ari-tczew: sure, but I won't be able to get to it right now. can you send me an email?
[14:56] <ari-tczew> lfaraone: sure.
[14:56] <ari-tczew> lfaraone: could you give me adress on private message?
[14:57] <lfaraone> ari-tczew: myircnick at debian dot org
[14:57] <ari-tczew> ok :)
[14:58] <Laney> ari-tczew: you don't maintain that package, do you think it's worth a NMU?
[14:58] <Laney> given that the severity is minor
[14:58] <lfaraone> what Laney said. :)
[14:59] <ari-tczew> Laney: what do you suggest?
[14:59] <Laney> I don't know the bug
[15:00] <Laney> you've to think about the squeeze freeze. Maybe you should give the maintainer some time to respond.
[15:02] <ari-tczew> IIRC av doesn't have time for maintaining, but ok. I can wait some days.
[15:02] <Laney> well then he should get some co-maintainers or hand the package over ;)
[15:03] <ari-tczew> Laney: I'm only interested in uploading this one.
[15:03] <Laney> not to you
[15:04] <ari-tczew> requestsync doesn't work :(
[15:19] <ari-tczew> tumbleweed: got a time?
[15:20] <geser> ari-tczew: can you be more specific than "doesn't work"?
[15:21] <ari-tczew> geser: now I requested bug manually and I have to get a package to sync for test.
[15:21] <ari-tczew> I didn't save error message.
=== JanC_ is now known as JanC
[15:40] <lfaraone> james_w: when you get a chance, can you merge in spiv's fix to bug #623736 in bzr-builddeb?
[15:40] <ubottu> Launchpad bug 623736 in bzr-builddeb (Ubuntu) "bzr crashed with UnboundLocalError in _import_archive()" [High,Confirmed] https://launchpad.net/bugs/623736
[15:40]  * lfaraone is using bzr in a chroot right now :(
[15:43] <james_w> lfaraone: yes, I just commented
[15:45] <lfaraone> aha, I see.
[16:09] <Laney> right, here goes Maverick's Haskell transition
[16:10]  * Laney quivers
[16:10] <Laney> should only be a little one
[16:23] <directhex> more haskell transitions?
[16:23] <directhex> seems fragile, abiwise
[16:23] <Laney> this upload changes the abi of one library
[16:24] <Laney> but i don't understand why
[16:24] <Laney> only touches stuff in debian/
[16:25] <Laney> at least we made it so that apt will save users from having a broken system
=== fta_ is now known as fta
[17:18] <ari-tczew> geser: http://paste.ubuntu.com/483532/
[17:18] <ari-tczew> requestsync fails
[17:51] <lfaraone> Do I need to explicitly specify universe/$SUBSECTION in packages that are destined for Ubuntu only?
[17:52] <james_w> no
=== ivoks_sleeping is now known as ivoks
=== yofel_ is now known as yofel
=== ivoks is now known as ivoks_away
[20:57] <lfaraone> For completely new packages, if I'm a MOTU, can I just file the needs-packaging bug, subscribe ~ubuntu-release, and go ahead and upload to the queue? Or do I need ~ubuntu-release approval first?
[20:58] <hyperair> i think you need a FFe?
[20:59] <BlackZ> lfaraone: for new packages you will need a FFe
[21:00] <Laney> I doubt it matters if you upload to the queue first or after
[21:00] <lfaraone> hyperair, BlackZ, right. I'm wondering if it's done similar to ~ubuntu-sru, where you need SRU approval, but they want it in the queue first.
[21:01] <BlackZ> lfaraone: no, you will need a FFe before to upload the package
[21:02] <hyperair> but it doesn't really matter, does it? if the FFe isn't granted, the package will get rejected from the queue. no harm done.
[21:08] <tbielawa> Would some one please review this SRU request and tell me if I did it correctly? https://bugs.launchpad.net/ubuntu/+source/gnu-smalltalk/+bug/557290
[21:08] <ubottu> Launchpad bug 557290 in gnu-smalltalk (Ubuntu) "Make gnu-smalltalk build on lucid" [Undecided,New]
[21:10] <nigelb> tbielawa: everything seems to be done right
[21:11] <tbielawa> nigelb: thanks for the confirmation!
[21:18] <BlackZ> hyperair: what about if you will upload a new package and the FFe for it isn't garanted yet when an archive admin will check it?
[21:18] <hyperair> BlackZ: then it gets skipped?
[21:18] <BlackZ> hyperair: it may get skipped, yes
[21:21] <hyperair> BlackZ: so nothing bad, right?
[21:25] <BlackZ> hyperair: yes, if when you will upload a new package and the FFe for it isn't garanted yet when an archive admin will check it, it doesn't really matter if you will upload it first or after (as Laney said)
[21:27] <Laney> so nobody is arguing, good
[21:27]  * hyperair nods
[21:27] <micahg> this is after beta freeze, right?
[21:27] <Laney> now
[21:27] <Laney> that doesn't mean anything for universe
[21:28] <micahg> Laney: I thought it jsut meant that uploads need to be processed by an AA
[21:28] <micahg> oh, me  just checked the scrollback
[21:28] <Laney> well stuff gets held in unapproved
[21:28] <micahg> nm'
[21:30] <BlackZ> lfaraone: so it's a your choice to upload the new package (a package that isn't in Ubuntu nor Debian) first or after that the FFe got approved/rejected
[21:32] <BlackZ> s/approved/rejected/granted/not granted
[21:36] <iulian> lfaraone: Is that new package going to be uploaded to Debian as well?
[21:37] <lfaraone> iulian: No, it isn't.
[21:38] <lfaraone> iulian: I'm a DD, so I'm usually in favor of submitting it to Debian and sync it over, but this package is not really useful outside of Ubuntu.
[21:38] <iulian> lfaraone: That was actually my next question.
[21:39] <ajmitch> you probably want to mention the FFe in the changelog for the archive admins, but that ends up being slow waiting for -release before you can upload
[21:40] <lfaraone> iulian: "ubuntu-sugar-remix-default-settings" and a "ubuntu-sugar-remix" metapackage are about as useful in Debian as having "debian-edu-*" in Ubuntu.
[22:05] <ScottK> lfaraone: If I approve ubuntu-sugar-remix, is that going to cause more FFes to appear or is this it?
[22:06] <lfaraone> ScottK: yes and no.
[22:06] <ScottK> Please clarify?
[22:06] <lfaraone> ScottK: the package only depends on what's in the archive, of course.
[22:07] <lfaraone> ScottK: but we've a few packages that are in Debian that we'd like to get synced over to Ubuntu.
[22:07] <ScottK> So there's more that's no in the archive that you'd add if you can?
[22:07] <ScottK> OK.  Anything that's not in Debian?
[22:08] <lfaraone> ScottK: one in NEW, and I think there may be one or two unpackaged. But right now we're focusing first on what's already packaged.
[22:09] <ScottK> lfaraone: I'm good for an FFe for the metapackage, the default settings, and syncing from Debian.  If you want new packages not in Debian, find an archive admin with time (not me) to agree to do the New review and include that in the FFe for the new pacakge.
[22:09] <lfaraone> ScottK: 1 in new, 2 packaging in process of being packaged, and 2 unpackaged.
[22:09] <lfaraone> ScottK: okay, great.
[22:14] <lfaraone> ScottK: so in the future for packages meeting those criteria (syncs), should I just subscribe ubuntu-archive?
[22:15] <ScottK> lfaraone: No.  They still need release team approval.  I'm just telling you now I'll give it.
[22:50] <lfaraone> ScottK: ah, okay.,