[00:51] <Chipzz> playya_: the changelog should be in the debian dir, and hence end up in the .diff.gz
[00:52] <Chipzz> so you shouldn't have to upload multiple tarballs
[00:52] <playya_> hmm. yes
[00:52] <playya_> maybe is should just ask for a bzr import on launchpad
[00:53] <playya_> is it possible to build multiple packages from one bzr repo on lp?
[00:54] <slangasek> playya_: backing up here, what is it you're trying to achieve?  Is this for a ppa, an SRU, a backport?
[00:55] <playya_> a ppa
[00:56] <playya_> i want to package vala-dbus-binding-tool, cornucopia, libfso-glib and maybe zhone from http://git.freesmartphone.org/
[00:56] <slangasek> playya_: https://help.launchpad.net/Packaging/PPA/Uploading, https://help.launchpad.net/Packaging/PPA/Copying
[00:56] <slangasek> though PPA usage is more on topic for #launchpad than here
[00:56] <playya_> ok
[00:57] <slangasek> as for building multiple packages from one bzr repo... yes, that's possible, though one-repo-per-package is the recommended convention generally
[00:58] <playya_> ok
[01:00] <playya_> if i try to test my stuff with pbuilder(native build), i get the following error: configure: error: C compiler cannot create executables
[01:00] <playya_> i only know the error from cross compiling
[01:04] <slangasek> playya_: sounds like you haven't installed the 'build-essential' metapackage in your environment
[01:05] <playya_> i did iirc
[01:11] <playya_> i was my ccache setup :/
[01:18] <SpamapS> when I use pbuilder to try and rebuild elinks, I get this: Dependency is not satisfiable: liblua50-dev
[01:18] <SpamapS> but liblua50-dev is available.. do I need to re-create my maverick environment?
[01:38] <james_w> SpamapS: you may not have universe enabled inside the chroot
[01:39] <SpamapS> james_w: I added this to my .pbuilderrc: COMPONENTS="main universe"
[01:40] <SpamapS> now do I need to re-create the chroot?
[01:50] <arand> SpamapS: pbuilder --update --ignore-config    iirc
[01:50] <samliu> hey there, I was wondering if someone could answer some questions about packaging on ubuntu for me?
[01:51] <samliu> I'm trying to package a tomcat-driven web application
[01:51] <samliu> so far I've read all of http://www.debian.org/doc/maint-guide/
[01:52] <samliu> and I've managed to create a .deb
[01:52] <samliu> but it has nothing inside it...
[01:52] <samliu> am I supposed to have a makefile and install file?
[01:52] <samliu> I dont have either
[01:52] <samliu> my software takes like 240mb too
[01:52] <samliu> but the .deb has only 1.7kb for some reason
[01:53] <arand> SpamapS: sudo pbuilder update --override-config   rather.
[01:53] <samliu> I guess my question is, how do I turn my application into a .deb package
[01:59] <lifeless> samliu: the @ubuntu-packaging channel exists with a focus on helping people learn how to make debs
[01:59] <lifeless>  you may get more success asking there
[02:09] <samliu> oh thanks
[02:09] <samliu> :D
[02:15] <CynthiaG> What is DIF in Ubuntu terms? I try to Google 'Ubuntu DIF' and it asks me if I mean 'diff'.
[02:16] <CynthiaG> It was used in this context, "If it's included before DIF we should be able to sync/merge it over", so I assume it must be some kind of time point/timeframe
[02:19] <CynthiaG> Oh! Never mind. It's Debian Import Freeze.
[03:09] <ccheney> anyone happen to know if there is a way to mess with lvm via a library instead of just the commands directly?
[03:24] <ccheney> appears there is liblvm its just not packaged for some reason, part of lvm2 source
[04:44] <spenguin[work]> hey anyone using kernel 2.6.33 on a thinkpad x201?
[04:44] <spenguin[work]> Im refering to this https://bugs.launchpad.net/ubuntu/+source/linux/+bug/554569
[04:44] <spenguin[work]> Im still unable to have X running with KMS and the patch
[06:17] <spenguin[work]> anyone using linux on a x201 laptop
[06:19] <lifeless> I'm using an x201s which is similar
[06:22]  * RAOF is using an x200, which is also similar, but with a different GPU
[06:29] <lifeless> RAOF: and CPU
[06:29] <RAOF> Well, yeah.
[06:30] <RAOF> I like to think of CPUs as essentially interchangable.
[06:30] <lifeless> ha
[06:30] <lifeless> ha
[06:30] <lifeless> ha
[06:30] <lifeless> I know you *like* to think that
[06:30]  * RAOF is aware that there's practically a whole kernel subtree dedicated to maintaining this illusion.
[06:31] <lifeless> perhaps I should have said
[06:31] <lifeless> you like to *think* that
[06:31] <TheMuso> crimsun_: do you have your packaging for ossproxy anywhere?
[06:32] <hyperair> hmm? cpus aren't interchangable?
[06:33] <spenguin[work]> lifeless: oh what kernel?
[06:34] <lifeless> spenguin[work]: lucid
[06:34] <spenguin[work]> and could you post what libdrm version
[06:34] <lifeless> lucid
[06:34] <spenguin[work]> hrm
[06:34] <lifeless> if you're encountering a problem
[06:34] <lifeless> it might help to describe it, briefly.
[06:35] <spenguin[work]> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/554569
[06:35] <spenguin[work]> Im on a vanilla kernel though
[06:36] <spenguin[work]> 2.6.33
[06:37] <spenguin[work]> tried 2.6.34 too
[06:39] <spenguin[work]> but I dont get help for that do I? :p
[06:42] <RAOF> You could concievably wait a couple of days and try a Maverick LiveCD.  That'll have 2.6.35 (which has a bunch of ironlake fixes in it), a new X server, and a new intel DDX.
[06:43] <RAOF> Well, 2.6.35-rc1 :)
[06:43] <spenguin[work]> hrm
[06:43] <hyperair> ooh maverick's got .35?
[06:43] <hyperair> i thought .35-rc1 had some issue with udev going 100% though?
[06:44] <RAOF> Not in Maverick.
[06:48] <hyperair> ah
[06:48] <hyperair> it wasn't in lucid either, come to think of it.
[06:49] <hyperair> Sarvatt did mention that there was an issue with the CPU not entering C4, though.
[06:49] <RAOF> Well, there is that, yeah.
[06:49] <lifeless> spenguin[work]: have you applied the new BIOS from lenovo ?
[06:49] <lifeless> I know there was one for the x201s, I'm not sure if there was/wasn't for x201
[06:50] <lifeless> spenguin[work]: and are you in 32 or 64 bit mode?
[06:52] <spenguin[work]> 64but
[06:53] <spenguin[work]> 64bit*
[06:53] <spenguin[work]> and I havnet applied the bios
[06:53] <lifeless> things got considerably better for me with the may bios fix
[06:55] <spenguin[work]> www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-74984 ?
[06:56] <lifeless> looks like it
[06:57] <lifeless> and definitely try with lucid
[06:57] <lifeless> not vanilla - I'm told there are platform things in the 6?0's that needed enablement
[06:57] <lifeless> the might not be upstream yet
[06:57] <spenguin[work]> hrm im on an old one -  (1.05 )
[06:59] <spenguin[work]> lifeless: how did you update the bios
[06:59] <spenguin[work]> burn the cd etc etc?
[06:59] <lifeless> yeah
[06:59] <lifeless> burn the cd
[06:59] <lifeless> usb cd drive
[06:59] <lifeless> power, blue key, alternate boot, boom-tish
[07:00] <spenguin[work]> hrm
[07:00] <lifeless> (the x201s has no builtin cd drive)
[07:00] <spenguin[work]> yeah
[07:01] <spenguin[work]> was thinking of getting the iso onto a usb stick
[07:01] <spenguin[work]> with unetbootin
[07:01] <spenguin[work]> what do you think?
[07:02] <lifeless> no opinion
[07:07] <spenguin[work]> hrm
[07:22] <pitti> Good morning
[07:22] <pitti> Sarvatt: ah, thanks for the heads-up; I thought it was introduced in lucid for supporting a slightly newer nouveau
[07:37] <spenguin[work]> lifeless: its been my stupid mistake.
[07:38] <spenguin[work]> was expecting the X pointer with a white screen
[07:38] <spenguin[work]> startx works :s
[07:38] <spenguin[work]> even ctrl+alt+backspace doesnt work in the latest xorg hence thought x was locking up
[07:59] <dholbach> good morning
[10:44] <apw> tseliot, you about ?
[10:54] <tseliot> apw: yep
[10:54] <tseliot> apw: I have to reboot. brb
[10:54] <apw> tseliot, where do i find the current source for bcmwl, the links seem to be wrong
[11:00] <apw> tseliot, where do i find the current source for bcmwl, the links seem to be wrong
[11:01] <apw> tseliot, or is it just to use the apt-get source job ?
[11:01] <tseliot> apw: what link are you looking at?
[11:02] <apw> tseliot, when you apt-get source ...
[11:02] <apw> NOTICE: 'bcmwl' packaging is maintained in the 'Bzr' version control system at:
[11:02] <apw> https://code.launchpad.net/~broadcom-sta-hackers/broadcom-sta/ubuntu
[11:02] <apw> Please use:
[11:02] <apw> bzr get https://code.launchpad.net/~broadcom-sta-hackers/broadcom-sta/ubuntu
[11:02] <apw> but that doesn't seem to match the real source
[11:03] <tseliot> apw: it looks like someone forgot to commit his changes to the bzr branch...
[11:03] <tseliot> apw: so, yes your best bet is either apt-get source or https://launchpad.net/ubuntu/+source/bcmwl
[11:04] <apw> tseliot, man this bzr stuff just gets in the way, specially when people arn't using it :/
[11:04] <apw> tseliot, i've got a fix for bcmwl for 2.6.35, is there a way to say 'this patch applied for 2.6.35 and later ?
[11:04] <apw> tseliot, in the dkms.conf ?
[11:05] <tseliot> apw: right, you can specify it there
[11:05] <apw> tseliot, whats the syntax?  i found how to make it for exactly 2.6.35
[11:05] <tseliot> apw: something like
[11:06] <tseliot> PATCH[0]="vga_arbiter_workaround.patch"
[11:06] <tseliot> PATCH_MATCH[0]="^2.6.35"
[11:06] <apw> is that not just equal to though?
[11:07] <tseliot> yes, let me find the proper syntax for that
[11:07] <apw> tseliot, the manuals are awful for this thing :/
[11:07] <tseliot> apw: you can bug superm1 about it :-P
[11:08] <apw> heh
[11:08] <apw>                 echo $1 | egrep -q "${PATCH_MATCH[$index]}"; then
[11:09] <apw> tseliot, seems its checked that way, so i think you can only say 'for this version'
[11:09] <apw> tseliot, i only need it because i would like the updated bcmwl packages to be installable on lucid, as a lot of us use the latest kernel in lucid this early in the cycle
[11:09] <tseliot> apw: I'm pretty sure that something like either 2.6.3[5-6] or 2.6.3[5|6] was allowed
[11:10] <apw> yeah i guess we could do something like that
[11:10] <apw> tseliot, so if i get this built and tested in PPA would you be able to sponsor it for me
[11:10] <tseliot> apw: sure
[11:13] <tseliot> apw: I was right. Here's what I found in http://linux.dell.com/dkms/dkms-ols2004.pdf (mentioned in the man page): PATCH_MATCH[0]="2.4.[2-9][2-9]"
[11:14] <tseliot> also make sure that the number that you use in both PATCH[0] and PATCH_MATCH[0] (i.e. 0 in this case) is not already in use
[11:14] <tseliot> by some other patch in dkms.conf
[11:15] <apw> '^2.6.(3[5-9]|[4-9][0-9])-' looks to be the thing
[11:15] <apw> tseliot, yeah we already have 3
[11:16] <tseliot> ok
[11:30]  * ogra curses
[11:30] <ogra> why the heck are dashes not allowed in initramfs script names
[11:40] <highvoltage> ogra: that's weird :)
[11:40] <Kano> hi cjwatson , why does the u grub2 package allow install into partitions and the debian one not with dpkg-reconfigure grub-pc
[11:41] <Kano> also why does http://packages.ubuntu.com/search?keywords=grub-pc&searchon=names&suite=maverick&section=all find nothing
[11:51] <mdz> dholbach: the countdown meter in your blog post is broken on planet ubuntu for some reason
[11:55] <apw> Kano, the list of suites at the top does not appear to include maverick, so its possible there is no maverick data in there
[11:56] <Kano> it is selectable
[11:58] <apw> but the results list all series and its not included
[11:58] <apw> (across the top as options)
[11:59] <apw> tseliot, ok ... i've added the debdiff for bcmwl to bug #590924, i have also built the source packags (and diff) and put them on chinstrap:~apw/sign perhaps you could review them for me
[12:00] <apw> robbiew, about ?
[12:01] <tseliot> apw: ok, thanks, I'll have a look at it
[12:01] <apw> tseliot, i built it in my 'blue' ppa and it seems to install and work too
[12:02] <apw> https://edge.launchpad.net/~apw/+archive/blue/+packages
[12:02] <tseliot> ah, even better
[12:08] <mpt> pitti, hi, <https://wiki.ubuntu.com/ReleaseTeam/FeatureStatus> begins with two copies of <http://people.canonical.com/~pitti/workitems/maverick/all-maverick-alpha-2.svg>. Is that a mistake?
[12:16] <mpt> hm, according to <https://launchpad.net/ubuntu/maverick>, Maverick doesn't have a release manager
[12:16] <mpt> Should we be concerned? :-)
[12:20] <didrocks> mpt: don't you know about autorelease mode? :-)
[12:24] <alonswartz> cjwatson: where would be the appropriate place to file bugs against casper? The project on LP isn't configured for bug reporting.
[12:26] <ogra> alonswartz, against the source package in ubuntu
[12:27] <alonswartz> thanks ogra, will do.
[12:28] <cjwatson> mpt: more true than you know
[12:29] <cjwatson> (but technically this is just disconnect between LP's terminology and Ubuntu's)
[12:37] <ogra> hmm, do we have any documentation how to write text on top of the plymouth splash ?
[12:37]  * ogra knows how to do it with usplash. but there doesnt seem to be any docs for plymouth 
[12:38] <ogra> resizing a partition on first boot takes 5-6min on a 4G SD card i'D like to tell the user that the system isnt hung :&
[12:39] <cjwatson> plymouth --help
[12:39] <ogra> heh, to simple :P
[12:40]  * ogra tried man plymouth and google :)
[13:02] <pitti> mpt: not sure why it's duplicated
[13:04] <dholbach> mdz: the server went down for maintenance
[13:05] <dholbach> mdz: it should be back up
[13:05] <jussi> what is keybuk's normal timezone?
[13:06] <Tm_T> jussi: in my lastlog he's been talking between 1500 and 2200
[13:06] <Tm_T> or so
[13:06] <jussi> right, thanks
[13:07] <jussi> well if someone sees him, please prod him to pm me
[13:07] <pitti> try email?
[13:08] <mdz> dholbach: ah, ok
[13:08] <mdz> dholbach: I clicked through and it looked fine on your site, but not on planet
[13:09] <dholbach> mdz: hum… weird
[13:09] <dholbach> mdz: glad it works now :)
[13:43] <ari-tczew> dholbach: did you saw my email?
[13:44] <dholbach> ari-tczew: yes, but I'm quite busy right now
[13:44] <dholbach> ari-tczew: I actually prefer if the archive admins take care  of it
[13:44] <ari-tczew> dholbach: do you will change your prefer?
[13:44] <tseliot> apw: is the final dash in PATCH_MATCH[3]="^2.6.(3[5-9]|[4-9][0-9])-" a typo?
[13:44] <dholbach> ari-tczew: if syncs are not performed regularly enough this should be fixed
[13:45] <apw> tseliot, the version numbers are the full kernel abi numbers so ... 2.6.35-1 etc
[13:45] <apw> so i added the - to ensure i matched the entire number
[13:46] <ari-tczew> dholbach: upload package by script reduces all time to waiting for archive admins
[13:47] <dholbach> ari-tczew: the archive admins double-check stuff and know if there's other important builds going on, I don't want to override them if it's not super urgent and necessary
[13:48] <tseliot> apw: I think it should be enough to match the kernel version
[13:48] <apw> tseliot, am ambivalent either way, the version is the -k parameter which is always that full form right?
[13:49] <tseliot> apw: yes, that's the full name. I was just worried about vanilla kernels
[13:50] <tseliot> which may not have the -1
[13:50] <apw> tseliot, ok i'll chop it off and regenerate it
[13:50] <tseliot> apw: perfect, thanks
[13:51] <Riddell> mvo: how come libxbase doesn't get packaging updates?  you seem to have given up on it years ago
[13:54] <apw> tseliot, that should be it, in the same place
[13:54] <tseliot> apw: ok, I'll sign and upload
[13:54] <Riddell> mvo: reason for asking is bug 591239
[13:56] <mvo> Riddell: *cough* it was a bit underused in the past, if its now used for something like krita I shall resurrect it and/or find a (co)maintainer
[13:59] <ogra> mumble mumble
[13:59] <ogra> is there any way to tell ureadahead to not run ?
[14:00] <amitk> apt-get remove ureadahead will tell it _very firmly_ not to run
[14:01] <ogra> amitk, i'm not sure that works nowadays
[14:01] <ion> Comment out the “start on...” line probably.
[14:01] <ogra> well, i have issues in initramfs
[14:01] <ogra> wont help to fiddle with initscripts
[16:11] <shtylman> what would be the best way to set the scaling governor to performance during certain times of the day?
[16:11] <shtylman> a cron job? or would an init script be able to do something there?
[16:19] <micahg> doko: how do I get openjdk to build w/the openjdk team as the maintainer?
[16:20] <Kano> control
[16:24] <lamont> NCommander: around?
[16:24] <lamont> NCommander: did we decide that qt4-x11 actually needs a longer timeout, or just needs to be not-lzma-on-arm?
[17:03] <mathiaz> pitti: slangasek: hi - I've a question related an sru
[17:03] <mathiaz> there is currently a sru for eucalyptus in lucid-proposed, ubuntu30.1
[17:04] <mathiaz> I'm planning to upload a new version to lucid-proposed (ubuntu30.2)
[17:04] <mathiaz> that fixes more a bugs and revert a patch that went into 30.1
[17:05] <mathiaz> so I'd like to have 30.1 marked as failed (as it will be superseeded by30.2)
[17:06] <mathiaz> when I'm preparing the 30.2 upload should I include the changelog entry of 30.1 in the .changes file as well (given that 30.1 wasn't published in -updates)?
[17:06] <mathiaz> slangasek: pitti: ^^
[17:06] <slangasek> mathiaz: yes, you should
[17:06] <mathiaz> slangasek: ok - what should be done with 30.1?
[17:06] <mathiaz> slangasek: just leave it in -proposed?
[17:07] <mathiaz> slangasek: or should it be rejected somehow?
[17:07] <slangasek> mathiaz: it will be overwritten when 30.2 is accepted
[17:07] <mathiaz> slangasek: ok - so nothing is required for 30.1
[17:08] <slangasek> mathiaz: only if you were worried that it would be incorrectly copied to -updates before 30.2 is accepted; in that case you should take care to tag as 'verification-failed' whichever of the SRU bugs are causing you to reroll
[17:08] <mathiaz> slangasek: right - I've already added the verification-failed tag to the SRU bug we're reverting in 30.2
[17:09] <slangasek> mathiaz: then that's everything :)
[17:09] <mathiaz> slangasek: great - thanks for helping out
[17:09] <slangasek> n/p
[17:26] <mathiaz> slangasek: eucalyptus 30.2 uploaded to lucid-proposed - if you could have a look at it it would be helpful as we'd like to start the verification process today
[17:36] <mistery> hi all
[17:37] <mistery> i'm investigating what is required for me to start contributing from a dev perspective.
[17:37] <mistery> anyone I can chat to? thanks
[17:38] <mathiaz> mistery: I'd start from http://www.ubuntu.com/community
[17:39] <mathiaz> mistery: ^^ this page outlines different ways to get involved and provides links to ressources
[17:39] <mistery> hi mathiaz.. been there and started reading some of the basic resources already
[17:39] <mistery> that's where i got this channel from
[17:39] <mistery> how do I actually find something to work on? Some small to start with :)
[17:41] <mathiaz> mistery: which area are you interested in? desktop, server, mozilla?
[17:41] <mistery> probably desktop for now
[17:42] <mathiaz> mistery: I'd suggest to go over https://wiki.ubuntu.com/DesktopTeam/GettingStarted
[17:43] <mistery> mathiaz: thanks, i'll start looking into that now.
[17:43] <mathiaz> mistery: np - happy reading !
[17:44] <mistery> mathiaz: thx :)
[17:50] <Q-FUNK> doko: would you have any instructions for how to proceeed with bug #587186 ?
[18:37] <slangasek> mathiaz: accepted
[18:40] <mathiaz> Daviey: ^^
[18:48] <slangasek> mathiaz: eh, bug #579942 is marked private; SRU bugs need to be visible
[18:48] <mathiaz> slangasek: I've marked the bug public
[18:48] <slangasek> mathiaz: thanks!
[18:56] <Daviey> mathiaz / slangasek: Great, thanks
[18:58] <Riddell> zul: bug 240519 is assigned to you, any progress or should we reject it?
[18:58] <Riddell> bug https://bugs.edge.launchpad.net/ubuntu/+source/php5/+bug/ is blocking
[18:58] <zul> reject it...ill probably have another look at it later
[19:02] <Riddell> Daviey: what are you expecting to happen with bug 583698 ? there's an upload in unapproved but no patch on the bug and sru aren't subscribed
[19:03] <Daviey> Riddell: good point!
[19:03] <Daviey> Riddell: i will sort this today
[19:06] <Chipzz> Riddell: I'ld say this is a user error
[19:06] <Chipzz> iirc apache has an option in /etc/default/apache which can be used to disable it, no?
[19:07] <Chipzz> hrrrrm it seems it doesn't
[19:08] <Chipzz> although I remember it doing so
[19:08] <Chipzz> maybe in an earlier version
[19:30] <Riddell> cjwatson: what's the status of bug 591199 ?  there's an upload but ubuntu-sru aren't subscribed and I don't see a patch on the bug, there's no test case too (presumably fairly trivial for docs)
[19:44] <cjwatson> Riddell: ubuntu-sru subscribed, patch linked
[19:44] <cjwatson> Riddell: I'm all for standard format but I don't see the point in writing a test case here, there's no way it can be anything other than "check that it now looks right"
[19:45] <cjwatson> (I wouldn't require a test case if this were somebody else's SRU)
[19:45] <Riddell> I'm impressed you didn't just accept it yourself :)
[19:45] <Sarvatt> any chance for oprofile rebuild against the new binutils so llvm-dev is installable? one was just uploaded today to rebuild against last weeks binutils but there was another newer binutils released right after..
[19:46] <Riddell> Sarvatt: already?
[19:46] <Sarvatt> yep..
[19:46] <Sarvatt> worst decision I ever made trying to package daily builds of something that needs llvm-dev, thats broken more than its not
[19:48] <Riddell> Sarvatt: uploaded oprofile
[19:50] <Sarvatt> \o/ thanks Riddell!
[20:03] <Sarvatt> Riddell: your changelog message looks like mine, except its degenerated to "no change rebuild #15 for this @%!* package." now :)
[20:18] <cjwatson> Riddell: I'm a good boy
[20:20]  * maco gives cjwatson a cookie
[20:21] <Riddell> imbrandon: what's the status of bug 537379 ?
[20:56] <imbrandon> Riddell: lemme check
[20:57] <imbrandon> Riddell: still no fix from upstream or debian on x86_64 ftbfs
[20:57] <imbrandon> so if we sync it we loose that build
[21:17] <kees> weird, procps didn't show up on the "needs merging" list.
[21:41] <pwnguin> a friend of mine suggested i386 support was being dropped in meerkat, but I can't find any official documentation for this assertion. the most ive found is a bug report within launchpad
[21:44] <pwnguin> oh neat, i also found this draft blueprint
[21:44] <pwnguin> https://wiki.ubuntu.com/FoundationsTeam/Specs/Maverick686DefaultCompile
[21:44] <ajmitch> pwnguin: I thought I'd seen it on ubuntu-devel-announce, but I just checked & it's not there
[21:45] <pwnguin> boy, the blueprint is very draft as in forked from a template unrevised
[22:22] <lfaraone> Should SRU bugs that are waiting for approval be triaged, or fix committed?
[22:31] <JFo> lfaraone, my money is on Triaged as they will not get committed until they are approved for the SRU
[22:31]  * micahg thinks there's a script which sets status and comments for them
[22:39] <cjwatson> lfaraone: makes no difference to SRU processing.  I tend to use In Progress personally but I wouldn't "correct" it if I saw something different
[22:40] <ajmitch> darn, I just changed a bug away from 'in progress'
[22:40] <geser> Riddell: in what way got bug 586509 fixed? LP doesn't list a git source package for maverick and I don't see it in the new queue either (or did I miss something)
[22:41] <lfaraone> cjwatson: ah, mk.
[22:42] <Riddell> geser: hmm, the version number is too small
[22:42] <ajmitch> with an epoch?
[22:43] <Riddell> geser: hardy had 4.3.20-12  so syncing version 1.7.1 won't work
[22:43] <geser> Riddell: 1:1.7.1-1 is bigger than 4.3.20-12
[22:43] <Riddell> although.. it does have an epoch
[22:43] <Riddell> there's also this error
[22:43] <Riddell> E: git-core is in main but its source (git) is not.
[22:44] <cjwatson> there's a sync-source option for that
[22:45] <cjwatson> it requires a switch because that's a situation an AA should check manually (it'll probably involve making sure the new source is overridden to main)
[22:46] <geser> git-core got renamed to git, so it has to be moved to main too (git-core was in main)
[22:47]  * Riddell tries the --force-more switch
[22:47] <geser> there was a different git in the archive in the past, therefore git (the VCS) got named git-core but as appararently enough time has passed it got renamed to git
[22:48] <Riddell> that did it
[22:48] <aganice> hey, i'd like to release this kobo ereader app thing to the multiverse repository, who should i talk to?
[22:50] <lifeless> is it packaged? do you have upload rights?
[22:51] <aganice> it's packaged as a .deb, and the project lead at the company asked me to find out how to offer their app in the repository, so yesish to upload rights?
[22:51] <NCommander> lamont: I think it might just be easier to do a longer timeout as I keep not finding time to change the packaging, then test to make sure it will build
[22:51] <lifeless> aganice: upload rights is an ubuntu thing
[22:52] <geser> Riddell: as the new "git" source package builds the same binary debs as the current "git-core" will it be automatically picked up (by some script) that "git-core" can be removed or is a bug needed?
[22:52] <aganice> lifeless, thanks. the answer is no, then, clearly :p
[22:52] <lifeless> so, if you want it in multiverse, I'd start by putting it up on REVU and getting the packaging reviewed, then when its ready an Ubuntu developer can 'sponsor' it into the archive for you.
[22:52] <Riddell> geser: git-core will appear in the NBS list soon and an archive admin will remove it one day
[22:53] <aganice> lifeless, thanks very much!
[22:53] <lifeless> aganice: alternatively, you can become a canonical partner (details on the website, I can find a link for you if you like), and it can be uploaded to the Canonical partner archive.
[22:53] <cjwatson> it'll probably happen more or less as soon as it has no reverse-dependencies
[22:54] <geser> Riddell: NBS lists also source packages without any binary debs left too? (all binary debs build from git-core (source) are now build by git (source))
[22:55] <cjwatson> no, it doesn't
[22:55] <aganice> lifeless, thanks very much, i'll do that.
[22:55] <cjwatson> removal of obsoleted source packages does require a bug
[22:55] <ari-tczew> Riddel: why do you sync package without information who has uploaded the package?
[22:55] <geser> ok, will file one once git got build
[22:56] <lifeless> aganice: http://www.canonical.com/about-canonical/partnerships - about partnerships
[22:57] <slangasek> cjwatson: multi-catalog> oh; the usual problem is that PC BIOSes don't know to check the architecture field.  Have you made sure the BIOS boot image is first?
[22:57]  * slangasek ran into this when trying to build multiarch i386+amd64+ia64 ISOs
[22:58] <cjwatson> pretty sure grub-mkrescue puts it first
[22:58] <lamont> NCommander: ok.  give me a source-package name and a timeout :p  I'll be rolling a new lp-buildd today or tomorrow and would love to put it in thene
[22:58] <lamont> then, even
[22:59] <slangasek> cjwatson: ok - then that solves the only problem I knew of at the time, which was PCs trying to boot the first el torito image regardless of architecture :)
[22:59] <Riddell> ari-tczew: such as which?
[22:59] <NCommander> lamont: qt4-x11, 10 hour timeout?
[22:59] <Riddell> ari-tczew: tab completion advised on irc else I won't see your message if you misspell my nick
[22:59] <cjwatson> slangasek: (I could be wrong, do you know an easy way to check?)
[23:00] <lamont> NCommander: is that a WAG, or expected max?
[23:00] <NCommander> lamont: WAG
[23:00] <slangasek> cjwatson: my memory is fuzzy on that part, sorry.  I thought it was a matter of the ordering of the arguments to mkisofs
[23:00] <lamont> NCommander: ok
[23:00] <cjwatson> mm, well this is using xorriso at least in part because I think it permitted hybrid ISO/USB images
[23:01] <cjwatson> we definitely put the BIOS options first though
[23:01] <cjwatson> slangasek: I think the assertion in the Fedora wiki page was that some BIOSes just plain didn't like multi-catalog at all, but I couldn't find citations
[23:02] <ari-tczew> Riddell: I forgot about tab, sorry. Today sync seems to be ok, but 18th May you did syncs without uploader information
[23:02] <NCommander> lamont: disregard, qt4-x11 magically fixed itself it seems
[23:02] <Riddell> bryceh: xf86-input-evtouch is blacklisted from sync, should I change that for bug 589535 ?
[23:02] <bryceh> Riddell, yeah it needs fakesync
[23:02] <cjwatson> (FWIW, the image I have boots in kvm both normally and with an EFI firmware image)
[23:03] <cjwatson> ari-tczew: exactly what uploader information do you mean?
[23:03] <Riddell> bryceh: ok, will you do that?
[23:03] <lamont> NCommander: coolness
[23:04] <ari-tczew> cjwatson: in launchpad "Uploaded by" and there person who has requested sync
[23:04] <cjwatson> ari-tczew: do you mean that the person who requested the sync is there and shouldn't be, or that it shouldn't be there but is?
[23:05] <slangasek> cjwatson: well... could be, but that would imply malice on the part of the implementor instead of just stupidity :)
[23:05] <NCommander> lamont: maybe disregard the disregard ...
[23:06] <bryceh> Riddell, is there anyone else that can do it?  it should be pretty trivial but I'm kinda tied up at the moment
[23:06] <ari-tczew> cjwatson: lol, look, I requested sync in bug 579593 and I'm not as uploader of this. check then https://launchpad.net/ubuntu/+source/connman/0.48+dfsg-2
[23:07] <Riddell> bryceh: I'll subscribe ubuntu sponsors
[23:07] <bryceh> thanks
[23:07] <lamont> NCommander: heh.  I'll ping you before I do the upload.  not sure when that'll be, but hopefully before the next time all the i386 virtual builders faceplant
[23:07] <lamont> since the upload is to specifically address that
[23:07] <bryceh> in fact, there may be an open question if we should just drop -evtouch.  I think rickspencer3 was suggesting that course of action for maverick
[23:08] <bryceh> but I'll leave that to RAOF to consider
[23:08] <rickspencer3> was I?
[23:08] <cjwatson> ari-tczew: assume accident rather than malice, then
[23:09] <ari-tczew> I see language barrier
[23:09] <cjwatson> hmm?
[23:10] <cjwatson> slangasek: excessive assertions of what they mistakenly believed to be correct, perhaps - hard to tell with BIOSes
[23:10] <slangasek> indeed :)
[23:11] <cjwatson> I have to say I'm not sure how to make Intel Macs continue to use the BIOS boot loader
[23:11] <cjwatson> presumably they'll notice that the EFI catalog entry is there and use it if they can
[23:11] <slangasek> I would imagine so
[23:12] <slangasek> though given that most of the El Torito spec was written for Apple's benefit, perhaps their implementation is smart enough that you can point it at a better option
[23:13] <slangasek> (well - not most of the El Torito spec perhaps, but most of the multi-catalog support)
[23:19] <slangasek> cjwatson: hah - I have a cdrkit patch on my hard drive from 2007 to add a -eltorito-efi option to permit setting the correct platform ID
[23:19] <slangasek> cjwatson: perhaps it would be useful to you? :)
[23:22] <cjwatson> slangasek: I'm not sure I want to rip out grub's use of xorriso at this point :)
[23:22] <cjwatson> though it might not hurt for reference
[23:22] <slangasek> right :)
[23:24] <slangasek> "Mark El Torito boot image for use with EFI (Itanium)" - <chuckle>
[23:25] <slangasek> cjwatson: http://people.canonical.com/~vorlon/cdrkit-eltorito-efi.patch
[23:25] <slangasek> the other key part, as I said, is the ordering of the options to genisoimage
[23:26] <slangasek> (which I have recorded here as well if it's useful)
[23:27] <cjwatson> thanks, sure
[23:27] <cjwatson> FWIW, the image I posted was generated by an *almost* vanilla grub-mkrescue from grub trunk
[23:28] <cjwatson> the only thing I changed was a bit of brutalisation to get it to know where to find the BIOS and EFI modules at the same time, since those two grub packages aren't coinstallable yet
[23:28] <cjwatson> which essentially meant running it from the build tree with a hacked prefix and copying some files about
[23:28]  * slangasek nods
[23:29] <slangasek> cjwatson: http://people.canonical.com/~vorlon/multiarch-cd.txt, then
[23:30] <cjwatson> right
[23:31] <cjwatson> FWIW I think the arguments here are coming out as -b boot/grub/i386-pc/eltorito.img -no-emul-boot -boot-info-table --embedded-boot embed.img --efi-boot efi.img
[23:31] <cjwatson> or words to that effect
[23:31] <cjwatson> where efi.img is a FAT filesystem image with /efi/boot/bootx64.efi and /efi/boot/bootia32.efi in it
[23:31] <cjwatson> some of these are probably xorriso-specific options
[23:33] <slangasek> what does the --embedded-boot do?
[23:37] <cjwatson> I think it's an alias for -generic-boot
[23:38] <cjwatson> :q
[23:38] <cjwatson> dodh
[23:38] <cjwatson> you know it's late when you can't spell doh
[23:38] <CynthiaG> and when you type :q in the wrong window, 5 seconds in-between
[23:41] <cjwatson> slangasek: source for this is http://lists.gnu.org/archive/html/grub-devel/2010-04/msg00000.html and thread, you may do better than I at deciphering it
[23:44] <cjwatson> slangasek: oh, this is from the el torito spec I think
[23:45] <cjwatson> slangasek: if you have it in front of you, there's a figure on page 6 labelled "Three types of CD-ROM configuration", and the one labelled "Multiple Boot-Image Configuration" has a bootable disk image in the first 16 sectors, which is normally unused in single-catalog configurations
[23:45] <cjwatson> slangasek: that's what this is doing
[23:45] <slangasek> ah, right
[23:47] <cjwatson> slangasek: the effect of this, I think, is to make it bootable as a USB stick as well
[23:47]  * slangasek nods
[23:49] <cjwatson> or possibly a floppy
[23:49] <cjwatson> I know that nowadays grub-mkrescue produces a single image that's all three at once
[23:51] <cjwatson> barry: ooh, your MBP says i386-pc, that's interesting
[23:51] <cjwatson> that implies that, given the choice between BIOS and EFI boot images, it picks BIOS
[23:51] <cjwatson> barry: do you have some kind of special arrangement with refit or whatever, or is that all bypassed here?
[23:52] <cjwatson> (BTW this is the desired situation!  it's just slightly unexpected)