[00:07] <nhandler> Congrats jpds!
[00:11] <Laney> what's the outcome of the vote?
[00:12] <nhandler> Laney: https://edge.launchpad.net/~ubuntu-dev/+polls
[00:12] <nhandler> Yes majority on all 3 votes
[00:12] <Laney> nice one, congrats
[00:12] <Laney> (I didn't know how to interpret the results)
[00:13] <ajmitch> just a rubber-stamp
[00:13] <ajmitch> if more yes than no, it passes
[00:14] <dtchen> Andrew Mitchell for MOTU Council in 2007  - closed on 2007-02-15 ;-)
[00:14] <dtchen> geez, we're fogeys
[00:14] <Laney> *ancient*
[00:14] <ajmitch> yep
[00:14] <ajmitch> such a long time ago now
[00:36] <blackmoon105> if i rebuild a .deb package that already exist in the debian repositories (with a debian mantainer), i must write my name as mantainer in the "control" file for the ubuntu build, it's right?
[00:37] <nhandler> Where are you building the package blackmoon105 ? In your PPA?
[00:38] <blackmoon105> nhandler: yes, in my PPA
[00:39] <blackmoon105> nhandler: yes, i'm building the package in my PPA
[00:40] <nhandler> blackmoon105: Then I would set yourself as the Maintainer and move the Debian Maintainer to the XSBC-Original-Maintainer field
[00:41] <blackmoon105> nhandler: ok, thanks
[01:18] <wasabi> savvas: ping
[01:21] <Kamping_Kaiser> is there an ubuntu equivilant to Debians dev-ref? I've found the customised Ubuntu debian-policy, but not the ref.
[01:25] <ScottK> Kamping_Kaiser: Is there something specific you're looking for?  Most of our stuff is in w.u.c somewhere.
[01:26] <Kamping_Kaiser> ScottK, the build dependancies allowed/disallowed between parts of the archive (main/universe/restrcited and release/release-updates/release-security etc)
[01:27] <ScottK> I'm sure that's documented somewhere, but I couldn't tell you exactly where.
[01:27] <ScottK> I can tell you how it works though if you want.
[01:28] <Kamping_Kaiser> please do. (it'll give me a starting point to try and find the 'proper' documentation)
[01:30] <ScottK> OK
[01:31] <ScottK> Each layer of the archive has to be completely self contained.
[01:31] <ScottK> Packages in Main can only build-dep, depend, or recommend other packages in Main.
[01:32] <ScottK> Then for Universe it's Universe + Main.
[01:32] <ScottK> Restricted is Main + Restricted.
[01:32] <ScottK> Multiverse is Main, Restricted, Universe, and Multiverse.
[01:32] <ScottK> Is that sensible?
[01:33] <Kamping_Kaiser> yep, with you so far.
[01:33] <ScottK> OK.
[01:33] <ScottK> At release time you get the release pocket.
[01:34] <ScottK> -updates and -security both build on themselves and -release.
[01:34] <ScottK> The trick is that -security updates get copies from -security to -updates on some periodic.
[01:34] <ScottK> So -updates ends up with all the post-release changes.
[01:35] <ScottK> (if a package has a -update and then gets a security fix in -security you have to change the package in -updates (or -proposed) to have that security fix.
[01:36] <ScottK> Packages destined for -updates are uploaded to -proposed and then built and tested there.
[01:36] <ScottK> Once blessed they are copied from -proposed to -updates.
[01:36] <ScottK> How's that?
[01:37] <ScottK> Kamping_Kaiser: ^^^
[01:37] <Kamping_Kaiser> so if i undestand correctly, -release is equivilant to debians 'frozen'. then after release -updates builds using -updates and -release, security builds using -security and -release. but does not build using -security, -release *and* -updates ?
[01:38] <ScottK> Yes.  I'm not certain, but I think -updates also builds against -security although it doesn't matter much because stuff gets copied from -security to -updates anyway.
[01:39] <ScottK> The reason for this is that running with just security updates and not bugfixes is a supported use case.
[01:39] <ajmitch> security is considered more conservative, so it won't grab any of the 'riskier' stuff from -updates
[01:39] <Kamping_Kaiser> i see. this bit is specifically what i'm trying to find a policy on.
[01:39] <ScottK> ajmitch: I'd put it slightly differently.  I'd say it's considered more essential.  The risk may be higher or lower, but it's more worth taking.
[01:40] <ajmitch> same thing, different perspective really
[01:40] <Kamping_Kaiser> ScottK, current linux-image in hardy-security depends on stuff in -updates to build and install. this is a pita for gNewSense, since we dont offically support updates, and which is whats started me looking into this whole thing. (i posted on -dev about this last night but go no bites)
[01:40] <ScottK> There was a recent discussion on this in ubuntu-devel because of gcc updates getting into -updates and the risk of some stuff ending up misbuilt.
[01:41] <ajmitch> the discussion on -devel sounds like exactly what you're talking about with the kernel there
[01:41] <ScottK> Yes
[01:41] <Kamping_Kaiser> and since my recollection was '-updates should be optional', and we've had packages rebuilt because they depended on -updates before, i was surprised to be told privately -security could depend on -updates
[01:42] <ScottK> It's not supposed to as I understand it.  I'd ask kees.
[01:42] <ajmitch> or doko, he seemed to know about it as well, since it was gcc
[01:43] <Kamping_Kaiser> would sending kees an email be the best move, or ping him on irc later?
[01:43] <Kamping_Kaiser> I guess email, then i can include this convo for background.
[01:45] <Kamping_Kaiser> ScottK, and ajmitch  thanks very much for the help
[01:46] <ajmitch> you've read the thread about this time last month about kernel-compiler mismatches?
[01:46] <Kamping_Kaiser> no, but i could do.happened on u-dev list?
[01:47] <ajmitch> yeah it did, it pretty much covers what you were talking about, I think
[01:47] <Kamping_Kaiser> I'll go and check, thanks.
[01:47] <ajmitch> https://lists.ubuntu.com/archives/ubuntu-devel/2009-February/027366.html
[01:48] <Kamping_Kaiser> ta
[02:01] <Kamping_Kaiser> I dont see anyone object to ScottK 's mention of the 'without updates' usecase, so I might file a bug on the linux packages
[02:27] <Kamping_Kaiser> I've jut fired off an email. Thanks again. I'm sure I'll be back later.
[03:23] <jdong> what do people feel about backporting config-package-dev?
[03:23] <jdong> bug 315264
[03:23] <jdong> I was looking over the diff and couldn't really see anything that would pose a problem
[06:13] <dholbach> good morning
[06:18] <iulian> Morning dholbach.
[06:18] <dholbach> hey iulian!
[07:13] <fabrice_sp_> Hi. About python2.6 transition. What should I do if a package still depends on python2.5, but build with python2.6, and don't have any issues with python2.6? add an entry for package rebuild in changelog?
[07:13] <fabrice_sp_> and submit hte debdiff?
[07:15] <fabrice_sp_> have to go now. Bye!
[08:27] <Toadstool> g'morning
[09:28] <dholbach> directhex: OK, if I re-add the planet ubuntu thing?
[09:29] <directhex> dholbach, oh, oops. yes, go ahead
[09:29] <dholbach> directhex: also I'll run update-maintainer for you - it's time you get a ubuntu.com mail address! :)
[09:31] <directhex> i am the king of upsate-maintainer suck
[09:32] <slytherin> does anyone have any idea if libdvdread is used by xine? If not then it should be removed from kubuntu-restricted-extras dependencies.
[09:38] <directhex> slytherin, try playing a dvd with xine - libdvdread spams output on stdout iirc
[09:40] <dholbach> directhex: uploaded
[09:41] <directhex> dholbach, thanks. sorry for the debdiff cock-up. i wasn't thinking properly - it's a while since i've merged anything since full syncability was a jaunty goal
[09:41] <dholbach> directhex: no worries
[09:42] <directhex> which gnome# 2.24's abi break hasn't helped with. such is life
[09:44] <slytherin> directhex: Will try tonight
[09:45] <directhex> dholbach, i'll ask the maintainer if he'd consider adding planet ubuntu at that end
[09:45] <dholbach> directhex: super, thanks
[10:06] <dholbach> can't believe there's not more people in the motu group: http://identi.ca/group/motu
[10:07] <directhex> i don't "get" this twittering things
[10:07] <directhex> also, not a motu
[10:07] <dholbach> ... yet :)
[10:08] <cristi> dholbach: hy, are you Daniel Holbach ?
[10:08] <dholbach> cristi: yep
[10:09] <cristi> dholbach: you asked for mmkeys.so here https://bugs.edge.launchpad.net/ubuntu/+source/sonata/+bug/341409
[10:09] <cristi> dholbach: i don't know what are you refering
[10:09] <dholbach> cristi: run less on the old python-mmkeys .deb and on the new one and compare
[10:09] <dholbach> or dpkg -c
[10:10] <dholbach> you'll see that the old package had two versions (one for python2.4, one for python2.5) of the .so file, the new package just has one for python2.5
[10:11] <cristi> dholbach: i see your point now
[10:11] <dholbach> ok good
[10:11] <dholbach> I'm not an expert, I just thought it might be a problem :)
[10:12] <cristi> dholbach: however, since 2.4 will not be used anymore, and it was posted for the python transition, is it necessary to add the 2.4 version?
[10:12] <dholbach> cristi: no, dropping 2.4 is fine - there's just no 2.6 version
[10:16] <cristi> dholbach: i am new with packaging, so i don't really know what i have to do now. i followed https://lists.ubuntu.com/archives/ubuntu-devel/2009-February/027528.html for the python transition. i used a jaunty pbuilder to build. what should i do?
[10:16] <dholbach> cristi: to be honest, I don't know - as I said: I'm not an expert
[10:18] <cristi> dholbach: oh, mkay, then hopefully soon a motu will take a look for sponsoring, and give me a feedback with what is wrong
[10:18] <dholbach> yep
[11:03] <jpds> nhandler: Thank you, you too!
[11:44] <AdamDH> if I change my package to a different Series say Januty instead of Intrepid but the version does not change do I need a change log entry to reflect this?
[11:44] <AdamDH> I noticed some package do some do not, just wanted to know what was best practice
[11:51] <directhex> you can't have 2 different packages with the same version number
[12:08] <AdamDH> I am just changing the packaging more than anything not the actual source
[12:08] <directhex> so?
[12:09] <AdamDH> so just bump the version and change the changelog to show the packaging has been updated?
[12:09] <AdamDH> this is the first time I have been in this situation with packages I have created
[12:09] <hyperair> AdamDH: that's right.
[12:10] <hyperair> AdamDH: you cannot have two packages of the same version in the same repository, even if it's in a different series
[12:10] <directhex> AdamDH, the bit after the - is specifically for packaging-related versioning
[12:10] <directhex> that's why -2, -3, etc, exist
[12:11] <AdamDH> so could I just append say -0ubuntu1~ppa1 to show the packaging has been update and change the changelog?
[12:11] <AdamDH> or is it just -0ubuntu1 and increase the 1?
[12:11] <hyperair> AdamDH: something like that.
[12:12] <hyperair> AdamDH: read the packaging guide
[12:12] <hyperair> and read the ppa guide
[12:12] <directhex> AdamDH, append -0ubuntu1~ppa1 to what existing version?
[12:12] <AdamDH> 0.14 is the version
[12:13] <hyperair> try not to have <upstream-version>-N or <upstream-version>-NubuntuM in a ppa.
[12:13] <hyperair> add a suffix
[12:13] <directhex> AdamDH, 0.14 is the PACKAGE version?
[12:13] <hyperair> ~somethingX if you want it to be superseded by the corresponding ubuntu/debian version
[12:14] <hyperair> +somethingX otherwise
[12:14] <AdamDH> yup 0.14 is the upstream version
[12:14] <hyperair> okay, and what's the ubuntu version?
[12:14] <directhex> AdamDH, i didn't ask that, i asked what the PACKAGE version was.
[12:15] <directhex> AdamDH, packages are versioned upstreamver-pkgrevision, unless they are "native" packages (i.e. the distro is upstream and it's only used in the distro), say... update-manager
[12:16] <AdamDH> there is no pkgrevision yet I am doing the revision
[12:16] <hyperair> then 0ubuntu1
[12:16] <hyperair> 0ubuntu1 if it goes into ubuntu
[12:17] <hyperair> 1 if it goes into debian
[12:17] <directhex> you said you were changing your package though. you have an EXISTING package, with package version number 0.14?
[12:17] <hyperair> and 0ubuntu1~ppa1 if it goes into a ppa
[12:17] <AdamDH> yes there is an exsisting package for intrepid with version 0.14 but the code will not change just the packaging
[12:17]  * hyperair headdesks
[12:17] <hyperair> i give up
[12:17] <directhex> sigh, i feel i'm having trouble communicating here
[12:17] <hyperair> directhex: you and me both
[12:18] <AdamDH> sorry The versioning ubuntu is using is just confusing me at the moment
[12:18] <directhex> 0.14 is NOT A VALID PACKAGE VERSION, other than a HIGHLY specific exception. if you've been using it, you've been doing things wrong.
[12:18] <hyperair> AdamDH: did you read ANY DAMN THING that directhex just said?!
[12:19] <AdamDH> yes I did, want to start a fresh so I can explain what I have started with?
[12:19] <directhex> if the upstream tarball says 0.14, and versions are meant to be upstream-revision, then the format must be 0.14-1 or 0.14-0ubuntu1
[12:19] <AdamDH> I think your refering to something I know as something else so its causing a little confusion, sorry
[12:19]  * hyperair will now head out to eat dinner.
[12:19] <directhex> using a native package causes significant issues, as it kills off the orig/diff system
[12:20] <directhex> i.e. you no longer have a pristine upstream tarball (orig) against which your packaging work applies (diff) so updates to the existing version are impossible (can't re-use orig)
[12:20] <AdamDH> the upstream tar is 0.14 so it should be upstream-revision? so I should be using 0.14-1 or 0.14-0ubuntu1 ?
[12:20] <AdamDH> right makes sense
[12:21] <directhex> and if you're only going into a PPA for now, append ~ppa1 to the end, meaning "this is the PPA version of 0.14-0ubuntu1, but i want the 'real' 0.14-0ubuntu1 to be installed given the option"
[12:21] <directhex> that way a distro 0.14-0ubuntu1 repolaces your PPA version
[12:22] <AdamDH> the packages I created in my PPA I did msp430-binutils - 2.19.1-0ubuntu1~ppa4 etc
[12:23] <AdamDH> but I am working with packages created by some one else at the moment hence the confusion and updating those
[12:23] <AdamDH> thanks for the help directhex, hyperair
[12:26] <directhex> james_w, ping
[12:26] <james_w> directhex: hey
[12:27] <directhex> james_w, can you forward me the monodevelop-debugger-gdb reject mail? it's simply not on the ubuntu-archive archive
[12:27] <james_w> the reject mail is just the autogenerated one
[12:27] <james_w> I haven't received an explanation mail
[12:28] <directhex> no clue who rejected?
[12:28] <james_w> nope
[12:38] <kaushal> hi
[12:38] <kaushal> what does motu means ?
[12:38] <Pici> !motu
[12:38] <kaushal> Thanks Pici
[12:38] <Pici> kaushal: surely
[12:39] <kaushal> will tomboy 0.12 be backported to Ubuntu 8.04 Desktop ?
[12:41] <kaushal> ii  tomboy                            0.10.1-1                          desktop note taking program using Wiki style links
[12:42] <directhex> only if someone does the work
[13:47] <slytherin> directhex: xine uses it's own private version of libdvdread/libdvdnav and while option to compile against external libdvdread exists it is not recommended (as said by configure --help)
[13:53] <directhex> slytherin, how lame
[13:54] <jdstrand> Kamping_Kaiser, ScottK: while kees is the person to talk regarding the kernel -security/-updates issue, I can say that systems without -updates enabled are entirely supported and anything in -security that depends on -updates is a bug
[13:56] <Kamping_Kaiser> jdstrand, bril, thank you! I've sent kees an email. with any luck i'll still be awake when he gets on IRC (its about 5am where he is i think).
[13:58] <bddebian> Heya gang
[13:58] <nhandler> Hey bddebian !
[13:58] <jdstrand> Kamping_Kaiser: fyi, in these cases it is entirely appropriate just to send to security@ubuntu.com
[13:58] <jdstrand> Kamping_Kaiser: we'd all get it and then also be in the loop on it
[13:58] <Kamping_Kaiser> bddebian, hey mate.
[13:58] <bddebian> Hello nhandler
[13:59] <bddebian> Heya Kamping_Kaiser
[13:59] <jdstrand> Kamping_Kaiser: don't feel you have to resend though-- just fyi
[13:59] <slytherin> directhex: Do you think we should compile xine against the libdvdread/libdvdnav in repos? Because a private copy means that we are not sure of it's status.
[14:00] <Kamping_Kaiser> jdstrand, ok. I've been getting mixed messages, and been unable to find anything in an Ubuntu policy about it.
[14:00] <jdstrand> Kamping_Kaiser: sorry about that. I can fix the policy. Where were you looking?
[14:01] <jdstrand> Kamping_Kaiser: and where did you expect to find it?
[14:01] <Kamping_Kaiser> jdstrand, I was going through the ubuntu-policy package, but hadnt found it (iirc i was 10-15% of the way through).
[14:02] <jdstrand> Kamping_Kaiser: interesting-- I can take a look at it
[14:02] <Kamping_Kaiser> none of my searches using google got me joy either, but its one of those situations where i'm not sure what i can search for to get the right results.
[14:04] <jdstrand> Kamping_Kaiser: I think going to wiki.ubuntu.com/Security and/or SecurityTeam should get you there
[14:04] <jdstrand> Kamping_Kaiser: I say 'should' as in "I'm going to check to make sure it does"
[14:05] <Kamping_Kaiser> hehe. ok, thanks. I'll have a try too
[14:05] <jdstrand> Kamping_Kaiser: if there is an appropriate place in ubuntu-policy for referencing it, then we can have a generic blurb and maybe reference the wiki
[14:05] <directhex> slytherin, hm, i'd ask someone like siretart for opinion on that
[14:05] <directhex> slytherin, FWIW i ignore recommendation & use distro cairo for moon
[14:05] <jdstrand> Kamping_Kaiser: but the team will talk about improving the situation
[14:06] <siretart> slytherin: have you verified the changes done to those libraries in xine?
[14:07] <Kamping_Kaiser> jdstrand, thanks. I was specifically looking in the section regarding repository split up (main/universe/r/m) in ubuntu-policy, but if theres a better place I wouldnt object to reading further for it
[14:09] <jdstrand> Kamping_Kaiser: I know I have certainly talked about that in several places-- and pretty sure I wrote about it in the wiki. I think I also came across it the other day in ArchiveReorganisation
[14:09] <jdstrand> Kamping_Kaiser: thanks for your feedback. We'll get that fixed up
[14:10] <Kamping_Kaiser> jdstrand, tbh, even though I can roughly describe what I'm trying to get at, and ScottK explained it all, i'm still not sure i'd know what to search for to find the right answer. (a personal problem, but perhaps relevant when trying to work out what to put on the page)
[14:11]  * jdstrand nods
[14:11] <jdstrand> Kamping_Kaiser: I fully agree that it is not widely known
[14:11] <jdstrand> (which is why I've talked to a bunch of people about it :)
[14:11] <Kamping_Kaiser> :)
[14:11] <slytherin> siretart: not yet, but the last entry in upstream changelog about update of libdvdnav is from December 2004
[14:12] <Kamping_Kaiser> jdstrand, if i can be a help re this, feel free to ping me.
[14:13] <jdstrand> Kamping_Kaiser: cool. thanks :)
[14:14] <Kamping_Kaiser> np! thanks for /your/ help
[14:36] <c_korn> does someone know when mok0 usually comes online?
[15:04] <ripps> Hey, I'm trying to run a PPA team repository that keeps in sync often with git. The problem is that the program has about 20 plugins that need to be rebuilt whenever a change happens to the main program. Is there some way to automate the rebuilding process for these plugins?
[15:05] <ripps> This isn't counting all the backports for the plugin, the archive contains
[15:23] <Kamping_Kaiser> hopefully almost kees-gets-back-oclock. *tick tock tick* :)
[15:26] <porthose> Would a kind MOTU from the release team please have a look at Bug #338408 thx;-)
[15:34] <gaspa> dholbach: did you see my proposal for harvest-data?
[15:34] <dholbach> gaspa: no, sorry - seems I did not get that mail - will take a look at it in a sec
[15:35] <gaspa> thanks. ;)
[15:48] <mbudde> I'm working on packaging pidgin-plugin-pack 2.5.1. When I build it I get loads of dpkg-shlibdeps warnings (see http://launchpadlibrarian.net/23781571/buildlog_ubuntu-jaunty-i386.purple-plugin-pack_2.5.1-0ubuntu1~ppa2_FULLYBUILT.txt.gz ) Is there something wrong and can I do anything about it?
[16:06] <hyperair> mbudde: look into banshee packaging, and copy the debian/patches/99_ltmain-as-needed.patch
[16:06] <hyperair> mbudde: then add LDFLAGS += -Wl,--as-needed into debian/rules
[16:07] <hyperair> mbudde: if the patch doesn't apply due to some context changes in ltmain.sh, you may need to manually make those changes and refresh the patch
[16:08] <mbudde> hyperair, ok, I'll take a look at it :) Thanks!
[16:08] <hyperair> mbudde: np
[16:22] <wasabi> savvas: added to group
[16:22] <wasabi> savvas: curios about your plans for gapti
[16:34] <Kamping_Kaiser> jdstrand, btw, the KernelMaintenance page at the bottom has a section "main, proposed and security". Might be worth linking from there to whatever doco gets put together about the -updates/-security bit.
[16:34] <Kamping_Kaiser> sneaky bastard. :o
[16:40] <Kamping_Kaiser> jdstrand, btw, the KernelMaintenance page at the bottom has a section "main, proposed and security". Might be worth linking from there to whatever doco gets put together about the -updates/-security bit. (sorry to the channel who have to see this twice)
[16:40] <jdstrand> Kamping_Kaiser: thanks. I also found where I wrote it: SecurityTeam/FAQ
[16:40]  * Kamping_Kaiser looks
[16:41] <jdstrand> Kamping_Kaiser: it isn't really that exciting :)
[16:41] <Kamping_Kaiser> jdstrand, how exciting can you make kernel packaging? ;)
[16:41] <jdstrand> heh
[16:43] <Kamping_Kaiser> Now i have to go and look at the email i sent kees to check how much is still relevant *heh*
[16:43] <RainCT> Is anyone here using LXDE?
[16:44] <kees> Kamping_Kaiser: heh, it'll be a bit before I get through my email this morning.  :)
[16:44] <Kamping_Kaiser> kees, i've waited to 3am, i'm sure i can wait another hour or two.
[16:45] <Kamping_Kaiser> now, where did i put that can of caffeine...
[16:45] <Toadstool> RainCT: yep, I am
[16:46] <kees> Kamping_Kaiser: heh, ah, just got to it.
[16:46]  * RainCT has just installed it out and can only say.. "wow" :). Login time is less than 1 second and it has panel and everything (unlike openbox) and actually looks great :D
[16:47] <Kamping_Kaiser> kees, dont recall exactly what i wrote, but since then i'm told canonically that -security should stand alone, so anything about confusion can be ignored. the bit about 'what happens now' remains.
[16:47] <Kamping_Kaiser> RainCT, o_0 1 second? thats faster then e16 :o
[16:47] <RainCT> Toadstool: .. but I've got some untranslated entries in the menu (like "Game" and "Network"), do you happen to know why that happens?
[16:47] <RainCT> heh
[16:48] <RainCT> well, it's on a new laptop here.. I'll try it on my sister's PC later (which has 256MB RAM)
[16:48] <Toadstool> RainCT: uh, er, no, I am using LANG=en_US here
[16:48] <kees> Kamping_Kaiser: right, it is a bug that anything in -security would depend on -updates.  it sounds like fixing the compiler glitch needs to move forward.
[16:49] <kees> Kamping_Kaiser: is this a problem for hardy, intrepid, or both?
[16:50] <Kamping_Kaiser> kees, i know its a problem in hardy (gNS bases off it), dont know about intrepid
[16:50] <kees> Kamping_Kaiser: okay
[16:52] <Kamping_Kaiser> kees, is there a bug about the gcc shuffle i can sub to? i'd like to keep a tab on it.
[16:52] <kees> Kamping_Kaiser: let me ask the kernel team...
[16:53] <Kamping_Kaiser> kees, ok. i'm in there too, so i can hang around if theres no quick reply.
[16:55] <RainCT> uhm.. e16 looks interesting, but I don't like it on a first try (and it took ages to generate a menu :P)
[16:56] <Kamping_Kaiser> e ftw.
[16:58] <RainCT> hm, perhaps I could even get used to it.. anyway, I'm off, cya
[16:59] <Kamping_Kaiser> later mate
[17:17] <Kamping_Kaiser> kees, I might head to sleep. I'm still in -kernel, so if the bug report gets found i'll subscribe myself tomorrow. Thanks for looking into it.
[17:21] <kees> Kamping_Kaiser: cool, g'night
[17:22] <Kamping_Kaiser> later mate.
[17:25] <ripps> I'm trying to setup an autoppa system for maintaing a bunch of packages. I have 20 plugins that I want to bundle into a single source package that I can upload and build into 20 seperate binary packages. I've seen other packages do this, is there some information somewhere on how to do this?
[17:34] <eMerzh> I'm looking for a motu to review my package at http://revu.ubuntuwire.com/details.py?package=sqliteman
[17:34] <savvas> wasabi: well not much, just planning to fix it upstream to be compatible with python 2.6 / 3.0 - we'll see how it goes heh :)
[17:34] <savvas> be back later
[18:46] <fabrice_sp> Hi. gcompris appears as depending in python2.5 in Jaunty, but it build fine in a schroot. Should I open a bug to bump the version to force the rebuild or it will be automatically rebuild at some point?
[18:47] <fabrice_sp> (it's for python2.6 transition)
[19:13] <ScottK> It won't get automatically rebuilt.
[19:22]  * fabrice_sp will open a bug, then.
[19:40] <Ornedan> Depends line of libghc6-network-doc: Depends: ghc6-doc (>= 6.8.2), ghc6-doc (<< 6.8.2+), libghc6-parsec-doc (= 2.1.0.0-2)
[19:40] <Ornedan> Is that as self-contradictory as it seems to be?
[19:41] <ScottK> It's not.
[19:42] <Ornedan> Ok. So what does that << mean, then?
[19:43] <soren> Ornedan: The '<<' means what you expect. The '+' probably doesn't.
[19:44] <Ornedan> 'k. Something does seem contradictory, though, since trying to install the package fails with
[19:44] <Ornedan> Depends: ghc6-doc (>= 6.8.2) but it is not going to be installed Depends: ghc6-doc (< 6.8.2+) but it is not going to be installed
[19:44] <ScottK> Ornedan: It means any version  6.8.2 - 6.8.2+ inclusive of 6.8.2, but exclusive of 6.8.2+.
[19:44] <directhex> i.e.  6.8.2-*
[19:45] <directhex> 6.8.2-1 or 6.8.2-10ubuntu67~ppa3 matches that
[19:45] <ScottK> Ornedan: What version of ghc6-doc do you have?
[19:47] <Ornedan> Hmm... Seems none. Blargh and nvm. I was trying to get haskell set up with haddock more recent than is available from the official repositories, seeing as the version there is 0.8 and latest release is 2.4.1
[19:49] <ajmitch> ghc6 is another one of those special packages
[19:49] <soren> "spethial"
[19:49] <Ornedan> And the documentation syntax has changed somewhat since 0.8, so it fails on some 1/3 of recent libraries
[19:50] <jdong> nxvl, other motu-SRU and similar folk, can someone weigh in on bug 341832?
[19:51] <unit3> #ubuntu-dev pointed me here. I'm doing some backporting with prevu, but I can't seem to pass it -j8 or similar to do some parallel building.
[19:51] <Ornedan> Someone did have haddock 2.4.1 & a more recent ghc packaged in their PPA, but that ghc was missing the critical standard libraries :P
[19:51] <unit3> Is there a way to pass that through prevu to dpkg-buildpackage so I can take advantage of all my iceccd installs?
[19:51] <jdong> well that should be a DEB_MAKE_OPT in debian/rules.
[19:52] <jdong> and is not a prevu-specific problem -- it's a debian packaging problem
[19:52] <jdong> err DEB_BUILD_OPTIONS rather.
[19:52] <unit3> ok, but generally, I can go "dpkg-buildpackage -j8 -b" and it does what I expect.
[19:52] <soren> #ubuntu-dev?
[19:53] <unit3> so how do I get prevu to call dpkg-buildpackage that way?
[19:53] <jdong> well, you really shouldn't.
[19:53] <jdong> prevu does not support such options, just like the Ubuntu build servers
[19:53] <jdong> to do parallel builds you should really edit your rules file to do so correctly
[19:54] <unit3> Ok, is there a way to get prevu to just grab and unpack a specific source release, so at least I don't have to manually hunt that down?
[19:54] <unit3> then I can edit the debian/rules file myself.
[19:54] <unit3> also... if you're not supposed to do that, then why does dpkg-buildpackage have a -j option?
[19:54] <unit3> it's confusing, to say the least.
[19:55] <jdong> well dpkg-buildpackage has a lot of liberties for in place builds that pbuilder/sbuild do not.
[19:55] <unit3> ok.
[19:55] <jdong> http://www.debian.org/doc/debian-policy/ch-source.html
[19:55] <jdong> see 4.9.1 about parallelism
[19:55] <maxb> jdong: Why shouldn't prevu/pbuilder do parallelism?
[19:56] <jdong> maxb: it shouldn't handle it sopecially as a -j flag IMO. AFAIK setting DEB_BUILD_OPTIONS in your environment passes it in correctly
[19:56] <unit3> That seems not particularly well thought out. I mean, I see it there, but the package build system has no idea what level of parallelism is appropriate to my build environment, so why does hardcoding the number of jobs there make sense?
[19:56] <jdong> which is AFAIK how the buildd's do it.
[19:56] <unit3> oh, you can set the environment var?
[19:57] <unit3> that makes more sense.
[19:57] <unit3> and I'm fine with that. :)
[19:57] <jdong> unit3: no no, having your build system support DEB_BUILD_OPTIONS as per 4.9.1. then setting environment :)
[19:57] <maxb> unit3: note that dpkg-buildpackage -jX is only a shorthand for setting MAKEFLAGS and DEB_BUILD_OPTIONS envvars anyway.
[19:58] <jdong> correct
[19:58] <unit3> jdong: ok, I'm confused again. my build system is prevu. Does it support the DEB_BUILD_OPTIONS stuff?
[19:58] <jdong> unit3: no no, your buildsystem is the debian/rules file.
[19:58] <jdong> prevu/pbuilder is your build...er? I guess
[19:58] <jdong> whatever the correct terminology is.
[19:58] <unit3> erm... hrm... that terminology doesn't make sense to me. but I see what you're saying now.
[19:59] <jdong> lol that could be my fault or the pre-existing terminology's fault ;-)
[19:59] <unit3> yeah, it's existing terms, I just mapped them to something else in my head. ;)
[20:00] <jdong> maxb: I'm surprised MAKEFLAGS is being set by dpkg-buildpackage though... are the debian/rules targets really parallel-safe?
[20:00] <jdong> or am I confusing MAKEFLAGs with MAKEOPTS again?
[20:00] <jdong> stupid similarly named environment variables.
[20:00] <unit3> again, though, hardcoding number of jobs into debian/rules still seems badly planned. it certainly means prevu is much less handy ootb in my environment, since I now have to manually unpack all the source packages and edit the debian-rules manually.
[20:00] <unit3> or, at least, that's how I'm reading this.
[20:00] <jdong> unit3: no no, your environment has DEB_BUILD_OPTIONS="parallel=3" or something
[20:00] <unit3> Oh! I see.
[20:00] <maxb> unit3: prevu is a simplified wrapper around pbuilder.  pbuilder is a means to invoke dpkg-buildpackage in a minimal clean environment.
[20:00] <jdong> and debian/rules is responsible for parsing out parallel=3 into -j3
[20:00] <unit3> and then debian/rules handles it.
[20:00] <unit3> if appropriate.
[20:00] <jdong> right
[20:00] <unit3> Gotcha.
[20:01] <unit3> That makes so much more sense. :)
[20:01] <jdong> that's what the snippet of makefile under 4.9.1 is for :)
[20:01] <unit3> Ahhh.
[20:01] <unit3> Ok, I'll try that. Hopefully mysql builds in parallel, because it takes a really long time on my system without the build cluster to help. ;)
[20:01] <jdong> that it does :)
[20:01] <jdong> kernels, too.
[20:02] <unit3> Awesome. :)
[20:02] <unit3> I've got about 6-8 faster cores I can use via icecc, so I'd like to. ;)
[20:04] <directhex> 8 cores?
[20:05] <unit3> directhex: on multiple machines, available via icecc. hence the need for parallel job processing.
[20:05] <jdong> pfft don't provoke directhex
[20:05] <jdong> he'll pull out his 9000000 core itaniums
[20:05]  * directhex fluffles jdong 
[20:05] <unit3> hahahaha
[20:05] <directhex> jms@orac:~> grep -c ^processor /proc/cpuinfo
[20:05] <directhex> 256
[20:05] <jdong> what did I just tell you?
[20:05] <unit3> oh man. I wish. no, I'm using consumer grade amd64 stuff.
[20:05] <directhex> and yet gnome still runs like a dog ;)
[20:06] <unit3> hahahaha
[20:06] <unit3> switch out metacity for xfwm. your system will thank me. ;)
[20:06] <directhex> and it's crap for x264 dvd ripping
[20:06] <unit3> why? too many optimizations for x64 in x264's codebase?
[20:06] <directhex> more or less
[20:07] <unit3> 'cause otherwise I'd expect it to just scale through the roof, so that's too bad.
[20:08] <jdong> it doesn't scale to more than 4 or so threads well does it?
[20:08] <jdong> I always felt x264 did much better with one core twice as fast than two cores the same speed.
[20:08] <unit3> I thought they showed it scaling up to 8 at least on the new core i7 stuff?
[20:10] <jdong> it barely scales well to 4 on a core 2 quad I tested.
[20:10] <directhex> unit3, it scales well on i7 :)
[20:11] <jdong> it was very much margin of diminishing returns for me...
[20:11] <directhex> unit3, well... except it doesn't fill the hyperthreads, but that's not news
[20:11] <directhex> HT in "sucks" shocker
[20:11] <unit3> yeah.
[20:11] <unit3> But I thought part of the benchmarks I saw indicated that that just showed that i7 scales better than core 2 does in general, and that x264 will scale well if the arch lets it.
[20:12] <directhex> nothing scales like itanic
[20:14] <jdong> unit3: does it really scale better than having one or two cores under the +300MHz IDA boost?
[20:14] <unit3> directhex: yeah? I'd be curious to see how something like luxrender scales on it, then...
[20:14] <unit3> jdong: dunno, tracking down the benchmarks I saw before to try and determine that, since I don't remember well enough.
[20:14] <directhex> most people don't want scalability, they want throughput.
[20:14] <directhex> where clocks can often win
[20:15]  * jdong agrees
[20:15] <unit3> true.
[20:15] <unit3> but only at the bottom end.
[20:15] <unit3> of course, the bottom end is huuuuge now. ;)
[20:15] <jdong> I still feel if you're talking your average person doing X264 encodes, 2 faster cores is better than 4 not-as-fast ones.
[20:15] <unit3> computing: now with more junk in the trunk!
[20:15] <jdong> scalability is a different topic.
[20:15] <jdong> doesn't x264 still slice the image in some arrangement to thread?
[20:16] <unit3> jdong: no, I seem to recall it was more comprehensive than that, and tried to look at thread count and stuff.
[20:16] <jdong> i.e. somewhat reduced PSNR?
[20:17] <directhex> jdong, don't forget i7 is faster per clock than anything else
[20:18] <unit3> true too.
[20:18] <jdong> absolutely is.
[20:18] <directhex> trust me :)
[20:18] <unit3> I think I was thinking of these two: http://arstechnica.com/hardware/reviews/2008/11/nehalem-launch-review.ars/9 http://arstechnica.com/hardware/reviews/2008/11/nehalem-launch-review.ars/6
[20:18] <directhex> directhex@desire:~$ grep name /proc/cpuinfo | tail -1
[20:18] <directhex> model name	: Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz
[20:18] <unit3> Which shows i7 scaling well with more threads in another test.
[20:18] <unit3> but also a little more oomph using 8 threads with HT than 4 threads and no HT.
[20:18] <unit3> So inconclusive I guess.
[20:19] <unit3> You'd want to get a system with 2x4core nehelem xeons or something and bench with threads from 4-16
[20:20] <unit3> Meh. Once a mobo+cpu combo is < $300 I'll upgrade my desktop to i7, but I imagine that won't be for a while.
[20:22] <jdong> unit3: you're thinking the core i5.
[20:23] <unit3> jdong: huh? I thought i7 was just branding for the desktop version of nehelem?
[20:23] <jdong> unit3: the core i5 is an upcoming consumerization of the nehalem
[20:23] <jdong> should bring prices way down into the current core 2 ranges
[20:24] <jdong> unfortunately you're not gonna get your nerdcore 24xSLI whatnot gaming leet card slots
[20:24] <jdong> but you can build yourself a nehalem architecture machine without selling a kidney
[20:24] <directhex> only dual-channel ram though :'(
[20:24] <directhex> laaaaame!
[20:24] <unit3> that's fine.
[20:24] <jdong> *cough* :)
[20:24] <unit3> I never even max out my RAM on my home desktop.
[20:24] <directhex> Mem:          5974       5938         35          0         25       5081
[20:24] <unit3> and DDR3's still expensive.
[20:25] <unit3> erm RAM bandwidth that is, I totally max out RAM usage. ;)
[20:25] <unit3> yeah, looks like i5 is what I'll be after for home, and then the Xeon i7 stuff for work once it's a little cheaper.
[20:25] <jdong> unit3: that's how I figure.
[20:26] <jdong> I would like to be able to justify to myself building a xeon mac pro like workstation
[20:26] <jdong> but umm... never worked out.
[20:26] <unit3> yeah, me too, but not in this recession. contract work to buy toys is pretty hard to come by right now. :P
[20:26] <jdong> you know I have the money, just don't feel THAT is what I should dump it on.
[20:26] <jdong> hwoever, IMO in this economy rainy day bank money is a bad thing to keep.
[20:27] <jdong> just watching it lose its value is depressing.
[20:28] <unit3> heheh
[20:28] <geser> the question is what will lose value faster: your desktop or your bank money
[20:28] <unit3> I guess it depends on where you're keeping it.
[20:28] <unit3> yeah, computers generally depreciate the fastest.
[20:33] <e-jat> Successfully uploaded packages.
[20:33] <e-jat> Not running dinstall.
[20:33] <e-jat> anyone can help me?
[20:33] <jpds> e-jat: That sounds fine, are you loading to revu?
[20:34] <e-jat> my ppa
[20:49] <e-jat> jpds: uploaded to revu
[20:50] <jpds> e-jat: What exactly was your problem?
[20:51] <e-jat> not running dinstall .. sorry.. its my 1st package ..
[20:51] <jpds> That's not a problem, you can ignore that message. :)
[20:52] <e-jat> jpds: owh ok .. thanks ..
[20:52] <e-jat> hoping/waiting that someone will comment about it .. so i can learn from my mistake ..
[21:01] <hyperair> e-jat: i've received that message for every upload i've made, and i still haven't figured out what it means ;)
[21:02] <e-jat> owh ..
[21:02] <hyperair> jpds: do you know what it means? =\
[21:02] <hyperair> i mean what's dinstall for?
[21:03] <broonie> When uploading to Debian it used to be possible to run dinstall, the tool that processed uploads, by hand to check that the package was acceptable to dinstall.
[21:03] <broonie> So dput has the ability to do that automatically when uploading via SSH.
[21:03] <hyperair> i see
[21:09] <unit3> heh, my backport of mysql failed yesterday, and now I see in the build that the test which failed is marked as "[ disabled ]  randomly fails on Ubuntu amd64 buildds".
[21:09] <unit3> Good to know. :)
[21:31] <blizzkid> lo all. Screen resolution on my EEE900 dropped to 800 by 600 after today's upgrade, and no option of 1024 by 600. Any idea how I can get it back?
[22:06] <blizzkid> noone any idea about the resolution?
[22:06] <ajmitch> ask in #ubuntu, or #ubuntu+1 if you're using jaunty
[22:07] <blizzkid> ajmitch: it's jaunty, it was fine until todays upgrade
[23:02] <unit3> Heh... went to all this work backporting the jaunty mysql-server-5.1 packages to hardy, and they don't include the mysql-cluster / ndb stuff.
[23:02] <unit3> Can someone clue me in what's going on with 5.1 in Ubuntu, since packages says MOTU is maintaining that one?
[23:03] <savvas> gfax: Depends: libgnomeprint2.2-0 (< 2.18.6) but 2.18.6-1 is to be installed.
[23:03] <savvas> is anyone working on this?
[23:04] <ScottK> unit3: #ubuntu-server is a better channel to ask mysql stuff.
[23:04] <unit3> oh ok. will do.
[23:04] <unit3> Just looked here first since it had MOTU stamped on it. ;)
[23:05] <ScottK> Reasonable enough.
[23:08] <Laney> savvas: does it just need a rebuild?
[23:08] <savvas> Laney: I'm checking it right now :)
[23:09] <savvas> Laney: should I file a bug? I'm one button away :P
[23:09] <Laney> find out!
[23:09] <savvas> ok :)
[23:14] <savvas> libgnomeprint2.2-0 (>= ${misc:libgnomeprint-upversion}), libgnomeprint2.2-0 (<< ${misc:libgnomeprint-next-upversion})
[23:14] <savvas> Laney: yes, I think it does, should I make a quick ppa test build?
[23:14] <Laney> why ppa?
[23:14] <Laney> don't you have pbuilder?
[23:15] <savvas> I do but.. the logs include more info
[23:15] <savvas> ok, pbuilder it is :)
[23:29] <savvas> Laney: works on amd64! :) rebuilt and runs fine: http://paste.ubuntu.com/130391/ http://paste.ubuntu.com/130393/
[23:30] <Laney> cool
[23:30] <Laney> I'll upload a rebuild
[23:30] <savvas> thanks
[23:40] <Laney> done, thanks for investigating
[23:47] <bcurtiswx> hi all, i followed dholbachs youtube packaging tutorials and got to the debuild stage but it failed... since this is my first time building a package, would someone mind helping me troubleshoot the errors?
[23:53] <nhandler> bcurtiswx: Could you pastebin the output?
[23:56] <savvas> friday the 13th again hehe :p
[23:56] <nhandler> savvas: I still have a few more hours ;)
[23:56] <Laney> I donated my 13th pint of blood yesterday....
[23:57] <bcurtiswx> hi all, sorry i got disconnected, did anyone reply to my debuild debugging request
[23:57] <savvas> nhandler: the funny thing is that it was friday the 13th last month too :)
[23:57] <nhandler> bcurtiswx: I did. Could you pastebin the output?
[23:58] <nhandler> savvas: I noticed that. We also have Pi Day coming up
[23:58] <bcurtiswx> nhandler: instead of in the channel, may i PM you?
[23:58] <nhandler> bcurtiswx: That is fine. But please pastebin the output instead of sending it all in /msg's
[23:59] <maxb> Though other people may also try to help if you keep things in the channel.
[23:59] <nhandler> That is true
[23:59] <nhandler> It also allows other users to learn from the problem
[23:59] <bcurtiswx> ok, i will keep in chan.. sorry if this is a dumb ?, but what is pastebin