[00:16] <cjwatson> ScottK: done
[01:37] <ScottK> cjwatson: Thanks.
[05:23] <un214> what would it take to bring back sysvinit?
[06:02] <joshmuffin> can anyone help me, im using ubuntu 10.04 and I compiled gnome-shell from source, when i gnome-shell --replace it flickers and is unusable for about 30secs before it crashes, terminal output: http://paste.ubuntu.com/456343/
[06:03] <joshmuffin> Think its a problem with my ati graphics card
[06:10] <iulian> joshmuffin: Please see /topic.
[06:21]  * achiang wonders if anyone's ever tried building gir1.0-atk-1.0
[06:22] <TheMuso> achiang: Thats not a package...
[06:23] <achiang> TheMuso: oh, i suppose atk1.0 is the actual package
[06:23] <TheMuso> achiang: Yes.
[06:23] <achiang> maybe that's where i'm going wrong
[07:19] <dholbach> good morning
[08:04] <TheMuso> 8/c
[08:49] <pitti> Good morning
[08:50] <sebner> huhu pitti :)
[09:19] <slangasek> dholbach: there's a merge of cryptsetup staged already in the bzr branch listed in vcs-bzr... :)
[09:20] <dholbach> slangasek: sorry, I didn't check that
[09:20] <slangasek> no worries
[09:43] <dholbach> apachelogger, seb128, slangasek, dpm, Riddell, Laney, nigelb, jcastro, beuno_, warp10: can you please go and check https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep and see if you're happy with your session title/description and update it if necessary?
[09:43] <seb128> oh right, doh
[09:44] <nigelb> interesting response :p
[09:44] <seb128> I still don't know what I want to talk about there
[09:44] <warp10> dholbach: yeah, perfect description :)
[09:44] <dholbach> warp10: great, thanks
[09:44] <dpm> dholbach, mine looks great, thanks!
[09:44] <nigelb> dholbach: mine looks great too :)
[09:45] <dholbach> thanks nigelb and dpm
[09:45] <nigelb> seb128: perhaps on "how to help desktop team" or "how to be a desktop developer"?
[09:45] <dholbach> this UDW will kick arse!
[09:49] <asac> directhex: i asked slangasek and his crew to take a look. i dont get why you say that ubuntu patches broke debian though
[09:50] <directhex> asac, i can't build 2.6.3-2, which includes the ubuntu patches, on the debian porterbox. but as i've stressed, access to hardware makes this whole thing immensely difficult to coordinate
[09:52] <asac> directhex: what ubuntu patches are in there?
[09:53] <directhex> http://git.debian.org/?p=pkg-mono/packages/mono.git;a=shortlog;h=refs/heads/debian/patches/arm_cpuinfo_parsing, http://git.debian.org/?p=pkg-mono/packages/mono.git;a=shortlog;h=refs/heads/debian/patches/arm_thumb2_support and http://git.debian.org/?p=pkg-mono/packages/mono.git;a=shortlog;h=refs/heads/debian/patches/armel_fix_configure_fpu_check
[09:56] <dholbach> seb128: I'll update it in the timetable too
[09:56] <dholbach> seb128: oh, you're still editing
[09:56] <seb128> dholbach, commited, is the current description ok?
[09:57] <dholbach> seb128: looks great
[09:57] <dholbach> seb128: shall I got and update in the timetable?
[09:57] <seb128> dholbach, could you change the "is work on" to "is working on"
[09:57] <seb128> dholbach, while you edit
[09:57] <seb128> dholbach, yes please, thanks
[09:57] <seb128> sorry I forgot about this one
[09:58] <dholbach> seb128: fixed
[09:58] <seb128> dholbach, danke
[09:58] <dholbach> de rien mon ami
[10:00] <dholbach> didrocks: can you please go and check https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep and see if you're happy with your session title/description and update it if necessary?
[10:00] <didrocks> dholbach: I'm happy about it, that's why I didn't shout at your email ;) danke!
[10:01] <dholbach> didrocks: great, thanks
[10:01] <directhex> asac, i don't know if 2.6.3-2 builds on an ubuntu ARM box - this is impossible for me to test. i know 2.6.3 upstream, without any arm-related patches, builds on debian
[10:21] <Laney> directhex: #ubuntu-arm is probably a good place to find people
[10:21] <Laney> (think that's right)
[10:22] <directhex> Laney, good place to ask questions, not such a good place for receiving replies
[10:22] <Laney> I thought that was The Place for Arm Related Stuff
[11:33] <pitti> Riddell: any idea why koffice wants to go to universe?
[11:36]  * Riddell checks
[11:41] <Riddell> pitti: fixed in seeds
[11:41] <pitti> Riddell: thanks
[11:41] <pitti> I cleaned up component-mismatches a bit, which should reduce http://people.canonical.com/~ubuntu-archive/testing/maverick_probs.html
[11:42] <pitti> but this will require some more iterations
[12:31] <bdrung> sbeattie: ping
[12:49] <Kano> hi, why is maverick still not hybrid?
[12:50] <Kano> look at suse, they patched syslinux and you just need to update it
[12:51] <Kano> i even wrote a launchpad bug last year about it
[12:52] <Kano> https://bugs.launchpad.net/ubuntu/+source/syslinux/+bug/524803
[12:55] <cjwatson> Kano: it's on my list and will happen
[12:56] <Kano> cjwatson: cant wait for it... i have got a script for your kind of iso images but i prefer hybrid ones
[12:56] <Kano> with hybrid mode the script does not need to be root
[13:01] <zul> can i get someone from the foundations team to review the upstart script in bug #574554 please?
[13:02] <cjwatson> Keybuk: ^- would you have time to review the tgt bug above?
[13:03] <cjwatson> I looked at it but was not sufficiently sure of the semantics of 'start on (filesystem and net-device-up IFACE=lo)' to comment
[13:03] <Keybuk> it'll block lo from coming up until the filesystem does
[13:03] <cjwatson> zul: this is by no means a complete review, but you're missing 'runlevel' after 'stop on'
[13:03] <zul> cjwatson: thanks
[13:04] <Keybuk> which will have an interesting repercussion for the rc-sysinit/rc scripts
[13:04] <Keybuk> so I would avoid doing that if possible
[13:09] <Keybuk> zul: followed up on the bug with a suggested alternate line
[13:14] <mdz> SpamapS: packages listed in Depends are not guaranteed to be present/configured when preinst runs (only Pre-Depends packages are), Debian policy 7.2
[13:15] <mdz> SpamapS: usually adduser is invoked from postinst, rather than preinst
[13:20] <cjwatson> mvo: I've got a LOT of grub2 bugs that amount to the debconf frontend reporting that it lost its X connection, and then exiting 1.  Do you know what might be going on?
[13:21] <mvo> cjwatson: let me check one of them. is this during a normal update or a dist-upgrade? maverick I assume? if maverick it could be the switch in update-manager to aptdaemon as default backend
[13:22] <mvo> cjwatson: it does support debconf, but there may still be bugs
[13:22] <cjwatson> mvo: lucid
[13:22] <cjwatson> mvo: bug 576716 for example, I typically don't get more information than that
[13:22] <cjwatson> mvo: I was wondering if it could also be a pop-under dialog, and eventually the user got frustrated and closed the window
[13:22] <mvo> cjwatson: checking
[13:22] <cjwatson> but it's hard to tell
[13:26] <jibel> cjwatson, most of the time this error occurs on wubi setup
[13:26] <jibel> cjwatson, in the bug you mentioned there is loop=/ubuntu/disks/root.disk in the kernel boot command
[13:27] <cjwatson> jibel: are you sure?  they typically look like upgrade logs.
[13:27] <jibel> cjwatson, the pattern seems to be as follow
[13:27] <Riddell> asac: uxlaunch accepted but I filed bug 599772
[13:27] <jibel> install ubuntu with wubi
[13:27] <jibel> then update the system.
[13:27] <jibel> It's not reproducible or I haven't found a user able to reproduce
[13:28] <cjwatson> jibel: while I know there are problems with wubi upgrades, I'm at a loss for why that would result in this particular error.
[13:28] <cjwatson> as in, the technical mechanism.
[13:28] <asac> Riddell: thx
[13:28] <cjwatson> there should be no way for an individual package to be able to trigger that
[13:28] <jibel> reporters describe a system hang and  kill the upgrade thus the display error
[13:29] <cjwatson> right, if they kill it by hand then that's certainly one thing
[13:29] <cjwatson> it's not clear to me that every hang is necessarily due to wubi!
[13:29] <jibel> I seen 1 report where the reporter was able to catch a hang due to a "device busy" on an ntfs partition.
[13:30] <jibel> cjwatson, but I don't known if it's the general issue.
[13:30] <cjwatson> bug 574852: here's one that isn't wubi
[13:31] <cjwatson> of course I imagine bug 576724 is contributing to all this
[13:32] <cjwatson> if there are hangs when attempting grub-install to particular types of partitions, then that could explain part of it.  I'm hesitant to generalise here, though
[13:33] <jibel> cjwatson, bug 561374, not wubi but the "device busy" thing
[13:35] <cjwatson> hm, right, I'm not convinced that's a grub2 bug
[13:35] <cjwatson> let's not generalise from that one case
[13:36] <cjwatson> seems like hardware error -> the ntfs-3g mount fell over -> os-prober couldn't unmount -> grub-setup got stuck; I'm not sure which userspace components could have done anything about this
[13:36] <jibel> cjwatson, I agree, that's why I didn't duplicate them all
[13:36] <cjwatson> jibel: BTW is there a reason you keep asking reporters about BIOS virus protection?  it's pretty unlikely to be relevant to hangs
[13:37] <cjwatson> it might be relevant to problems that occur at boot time, but that's different
[13:38] <jibel> cjwatson, I seen some cases where the bios prevent grub to install on the mbr. But it's not relevant in the case of an upgrade since the boot loader is already installed.
[13:38] <mvo> cjwatson: hrm, that bug is odd, in lucid we still use synaptic as the backend, its the normal debconf frontend code used. let me play with it a bit
[13:39] <cjwatson> jibel: do you have links?  I can't see how the BIOS is even in a position to prevent ATA writes
[13:39]  * mvo waves to jibel
[13:41] <pitti> tkamppeter: our ghostscript package recently balooned from 0.8 MB to 2.8 MB, due to the /usr/share/ghostscript/8.71/Resource/CMap/ files
[13:41] <jibel> cjwatson, I'll check for links. I experienced this problem on dell gx desktops , where you had to disable bios virus protection in order to allow the installation of the boot loader
[13:42] <pitti> tkamppeter: Debian strips them out, "shipped separately, registered with DeFoMa).
[13:42] <pitti> "
[13:42] <pitti> tkamppeter: can we do the same?
[13:42] <ogra> cjwatson, MBR virus protection
[13:42] <pitti> we need to claim back 20 MB of CD space
[13:42] <ogra> cjwatson, some BIOSes have such an option that prevents you from accessing the MBR
[13:42] <pitti> tkamppeter: we already have a set of cmap-adobe-* packages which ship them
[13:42] <jibel> Hey mvo
[13:43] <cjwatson> ogra: reference please
[13:43] <mvo> jibel: just wanted to say thanks again for the flashplugin-nonfree sru verification! you rock
[13:44] <jibel> mvo, no prob, that's what SRU verification is done for.
[13:44] <jibel> mvo, btw I pushed this morning a fix for synaptic to build against latest libept 1.0 otherwise it FTBFS in maverick since last week.
[13:46] <mvo> jibel: thanks a lot, I merge it
[13:46] <ogra> cjwatson, cant give you one, but i know that even fdisk /mbr fails under windows if such an option is set, i doubt BIOS manufacturers make the details public about that feature
[13:49] <ogra> cjwatson, i'm pretty sure it only works if the system uses an onboard controller the BIOS manages though
[13:51] <jibel> cjwatson, about the apport hook for grub2, bug 591753, I don't know how passwords are stored in /etc/default/grub, any doc or reference ?
[13:51] <jibel> cjwatson, do I simply filter the string .*password.* ?
[13:52] <cjwatson> grep -v '^password'
[13:53] <jibel> cjwatson, thanks, I'll update the apport hook.
[14:11] <mpt> directhex, hi, would you be able to fix bug 546936 sometime this cycle? It's a one-line fix and would make life easier for potential developers
[14:20] <ttx> cjwatson: looking at https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/576066 ... I'm not sure it's categorized correctly. Are the kernel modules available to the Server installer really decided by seeds ?
[14:22] <Riddell> chrisccoulson: you uploaded a fix to bug 429841 but didn't comment on the bug?
[14:22] <tkamppeter> pitti, where are the cmap-adobe-* files located? Are they part of main, standard installation, or CDs? Note also that we are phasing out defoma.
[14:22] <Riddell> and mvo also uploaded a fix
[14:25] <mvo> Riddell: the fix is pretty trivial, the debdiff should be obvious
[14:25] <mvo> Riddell: sorry for the double upload
[14:26] <chrisccoulson_> Riddell - sorry, i forgot to comment
[14:26] <chrisccoulson_> i did mention to mvo that i would fix it though ;)
[14:49] <cjwatson> ttx: no, the kernel packaging decides that
[14:50] <ttx> cjwatson: so I should reassign to "linux" with a comment
[14:50] <cjwatson> yes
[14:50] <ttx> cjwatson: ok, thx for the confirmation
[15:20] <mvo> cjwatson: I tried to reproduce the grub-pc failure, but the only way I was able to trigger the io error 11 was a xkill. when killing the session I got a different io error. really odd
[15:20] <cjwatson> it's all very strange
[15:20] <cjwatson> I need to find some time to do some organised testing of wubi upgrades
[15:30] <bdrung> DktrKranz: ping
[15:31] <DktrKranz> hey bdrung
[15:32] <tkamppeter> pitti, where are the cmap-adobe-* files located? Are they part of main, standard installation, or CDs? Note also that we are phasing out defoma.
[15:32] <bdrung> DktrKranz: you worked on ubuntu-dev-tools, but andrew did some work too: https://code.launchpad.net/~andrewsomething/ubuntu-dev-tools/man-pages/+merge/28566
[15:32] <bdrung> DktrKranz: can i revert your last commit?
[15:33] <DktrKranz> bdrung: sure thing, I didn't spot that branch, feel free to do so
[15:33] <DktrKranz> just, if you can save (closes: #xxxxxx), that would be awesome :)
[15:34] <bdrung> DktrKranz: k, will add that to andrews branch
[15:37] <LucidFox> Once in a while, I get a drive to review some packages on REVU.
[15:37] <LucidFox> Like I did before. Then I look at the pile of unreviewed packages stretching back to May 2009, and...
[15:39] <dholbach> cody-somerville: I can't find charlie-tca - can you have a look at https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep and see if the description of the session is OK?
[15:40] <cody-somerville> dholbach, Looks adequate to me :)
[15:40] <dholbach> thanks cody-somerville
[15:43] <LucidFox> Would it make sense to archive REVU packages for karmic (and maybe lucid) with a single like like "Wrong target Ubuntu release"?
[15:43] <LucidFox> (Sadly, REVU still seems broken in regards to 3.0 (quilt) packages)
[15:51] <pitti> tkamppeter: they are separately packaged; if they are useful, we can integrate them into language-selector
[15:52] <pitti> tkamppeter: but we didn't ship them at all until now
[15:57] <micahg> was libstdc++5 supposed to get back into the archive?
[15:58] <pitti> eek, no; did it?
[15:58] <micahg> pitti: yep, it was uploaded recently
[15:58] <micahg> pitti: might not have been approved though...
[15:58] <pitti> hm, madison says that it disappeared in karmic
[15:59] <micahg> pitti: ah, it's in NEW :)
[15:59] <pitti> it should be in OLD_AND_CRAPPY
[15:59] <cjwatson> sync from gcc-3.3 in Debian, wasn't it?
[15:59]  * micahg got worried when it was on the maverick-changes list :)
[15:59] <cjwatson> he says, guessing
[15:59] <pitti> might have been a wrong autosync
[16:00]  * micahg thinks someone did it by accident
[16:01] <pitti> I'm happy to axe it again
[16:01] <pitti> it's cheap to bring back if needed, after all
[16:01] <directhex> ISV apps still need it on occasion
[16:02] <pitti> we did without it for two releases, and it's unmaintained
[16:02] <pitti> and in that case we could put it into partner, or the ISV include it
[16:02] <pitti> these tend to come with bundled libs anyway
[16:04] <micahg> pitti: bug 598854
[16:07] <pitti> ok, that was ack'ed by a MOTU
[16:08] <pitti> IMHO it doesn't exactly help to encourage ISVs to bother with rebuilding their stuff against a slightly less ancient toolchain, but *shrug*
[16:08]  * pitti accepts the binary then
[16:09] <pitti> there, NEW down to 3
[16:09] <micahg> pitti: why?  perhaps the MOTU didn't see all the previous discussion about it?
[16:10] <pitti> because binary-only rejection doesn't really make sense
[16:10] <pitti> if we remove the package again, the binary will just die with it
[16:11] <micahg> pitti: k, I was jsut wondering why not nuke it again?
[16:11] <pitti> that should be discussed on the ML or in a bug first, instead of just igoring our processes and the approved sync request
[16:14] <micahg> pitti: I was just wondering if a process was skipped to reintroduce something like this.  Is that a MOTUs call whether or not to reintroduce anything into universe?
[16:14] <pitti> I think so
[16:15] <pitti> archive admins have a certain say in that, of course
[16:15] <pitti> but someone synced it, so that happened
[16:15] <micahg> pitti: k
[16:16] <micahg> pitti: thanks :) I still have more to learn I guess
[16:17] <pitti> micahg: but please do feel free to bring it up on the ML
[16:17] <micahg> pitti: I just checked the removal bug and the reason cited is not maintained in debian, not OLD_AND_CRAPPY, so I guess there isn't an issue
[16:28] <tkamppeter> pitti, they help for example to make msttcorefonts working with Ghostscript, see bug 321932. Probably there are more fonts (or input files with embedded fonts) which work better with these files present by default.
[16:29] <pitti> tkamppeter: could ttf-mscorefonts-installer then depend on or recommend those cmap files instead?
[16:33] <tkamppeter> pitti, I did not know that they were already part of the non-CD part of the distro and as Ghostscript upstream developers told me that Adobe has changed the license of these files aand also after I heard that Defoma gets deprecated I have added them, also in the hope of getting less bug reports of "PDF file XYZ" does not print.
[16:45] <smoser> cjwatson, are you going to tell me "go fly a kite" on bug 599840 ?
[16:46] <cjwatson> smoser: shouldn't think so, although I'll probably push it upstream
[16:52] <tkamppeter> pitti, the cmap-adobe-* packages are only for CJK (Chinese, Japanese, Korean), the files I added are only for no-CJK (Latin, Russian, ...) so with my addition we should have a complete set now.
[16:54] <tkamppeter> pitti, -cns1 is Simplified Chinese, -GB1 is Traditional Chinese, -japan1/2 is Japanese, -korea1 is Korean.
[17:01] <pitti> tkamppeter: so how were we able to do without those maps until lucid?
[17:02] <pitti> tkamppeter: I'm trying to find out whether we can identify the cases where we do need them and handle them on demand
[17:05] <tkamppeter> pitti, probably with many files not rendering and us no knowing why.
[17:05] <tkamppeter> pitti, note also that Defoma is deprecated, Defoma can perhaps have replaced a part of the functionality of CMaps.
[17:06] <Chipzz> tkamppeter: what is defoma being replaced with?
[17:06] <pitti> tkamppeter: ok, thanks
[17:06] <pitti> tkamppeter: btw, I'm updating cups to 1.4.4
[17:06] <pitti> I need to rebuild it anyway against the new poppler
[17:11] <hallyn> stupid question
[17:11] <hallyn> what is the trigger to make sbuild apply quilt patches under debian/patches ?
[17:13] <Daviey> hallyn: Is this for Maverick or SRU?
[17:13] <hallyn> maverick
[17:13] <hallyn> so far the seabios package didn't have any patches
[17:13] <Daviey> hallyn: Consider changing to DEB source 3, the you get it for free.
[17:13] <hallyn> how do i do that?
[17:14] <Daviey> hallyn: one moment
[17:14] <SpamapS> mkdir debian/source && echo '3.0 (quilt)' > debian/source/format
[17:14] <SpamapS> I think
[17:14] <Daviey> yup
[17:14] <hallyn> ok, i looked at the qemu package and didn't see anything there so assumed it woudl jsut do it fo rme :)
[17:15] <Daviey> hallyn: traditionally it's done with one of the quilt debhelpers (assuming it's quilt)
[17:15] <hallyn> Daviey: SpamapS: trying, thanks
[17:17] <hallyn> success!  thanks!
[17:17] <Daviey> cool!
[17:19] <Daviey> hallyn: Make sure you comment in the debian/changelog that you switched to dpkg-source 3.0 (quilt) format
[17:25] <hallyn> Daviey: yup, done, thanks
[17:25] <Daviey> hallyn: awesome
[17:30] <Laney> woah, I wouldn't change source format of a package that's in Debian
[17:30] <Laney> is it?
[17:32] <hallyn> Laney: well this package isn't taken from debian
[17:33] <hallyn> (though there is a version in debian)
[17:33] <pitti> seb128: thanks for the g-i-t fix! how much smaller is it now?
[17:33] <hallyn> alas it has to be closely tied - and hacked up - to match the qemu version, which also is different from the debian versions.  hopefully we can work on that after 0.13
[17:33] <pitti> seb128: I'll upload a new cups to drop the old libpoppler5, FYI
[17:34] <cjwatson> hallyn: FYI, in the cause of understanding the model - sbuild isn't responsible for applying patches
[17:34] <Daviey> Laney: *everthing* hallyn is working on is seperate from Debian :(
[17:34] <seb128> pitti, some 2.4meg
[17:34] <pitti> seb128: cheers
[17:35] <pitti> so with that and new cups, 3 down, 17 to go..
[17:35] <cjwatson> hallyn: sbuild extracts the package with 'dpkg-source -x', and calls dpkg-buildpackage (or an equivalent interface), which ends up basically doing 'debian/rules build && fakeroot debian/rules binary'
[17:35] <cjwatson> hallyn: the old model is that you have debian/rules apply the patches somewhere; the 3.0 (quilt) model is that dpkg-source -x applies the patche
[17:35] <cjwatson> *patches
[17:36] <cjwatson> (not meaning this to come across as pedantry, but sometimes it helps to know what calls what)
[17:38]  * Daviey has never known a geek that is a pedant.
[17:39] <hallyn> cjwatson: thanks.  yeah i never use dpkg-buildpackage by hand, and dunno how it works, but was aware that sbuild uses them :)
[17:39] <hallyn> so dpkg-source applies that patches now.  that makes sense
[17:39] <hallyn> thanks
[17:40] <pitti> seb128: oh, and I'll upload a new anthy with a dependency fix, another 3 MB :)
[17:40] <seb128> pitti, nice, still some way to go though
[17:40] <ogra> Daviey, i know some greeks that are pedants :)
[17:41] <Daviey> heh.
[17:43] <tkamppeter> Chipzz, I do not know, are there any font experts around?
[17:43] <smoser> hi. i'm building uec image and hitting a bug in pycentral or pyyaml
[17:43] <smoser> http://uec-images.ubuntu.com/maverick/20100629.1/log.stdout.stderr
[17:43] <smoser> pycentral pkgremove: package python-yaml is not installed
[17:43] <smoser> is that known and in progress of being fixed ?
[17:45] <slangasek> directhex: hi, do you have a build log for the current mono armel failure in experimental?
[17:53] <Daviey> smoser: I guess you've seen it's newly built, ScottK might be the best person to speak to.
[17:55] <directhex> slangasek, no, the lack of experimental arm buildd gets in the way. i can fire off a build on agricola though
[17:55] <slangasek> directhex: ah. I thought it was reported to FTBFS on armel in Debian?
[17:56] <directhex> slangasek, not formally. we're evaluating using it for squeeze, so i started experimenting. and i'll get it in the neck if i upload something to maverick which breaks on ubuntu's ARM
[17:57] <slangasek> heh, I thought mono was already broken on armel in Ubuntu?
[17:57] <directhex> slangasek, it's just crap. that's a primary motivator - 2.6.3 drops from 43 test suite failures to 7. and i'm trying to extract promises of a 2.6.6 in time for feature freeze
[17:58] <directhex> (versus lucid's 2.4 branch snapshot, this is)
[18:00] <slangasek> directhex: do you have a merge of 2.6.3 for Ubuntu that would be useful as a starting point for testing?
[18:01] <directhex> slangasek, i stopped plans to prepare one when i ran into the ARM trouble. the only ubuntu changes these days are depends/recommends/suggests fiddles, afaik
[18:01] <slangasek> ok
[18:02] <directhex> slangasek, oh, i uploaded the debian package to my PPA, if it's any easier to work with from there
[18:02] <smoser> Daviey, what is newly built? https://launchpad.net/ubuntu/+source/pyyaml is 7 days old
[18:02] <directhex> https://launchpad.net/~directhex/+archive/monoxide?field.series_filter=maverick
[18:06] <directhex> slangasek, actually, i think i *might* have a build log. hang on
[18:07] <directhex> no, bugger, that's amd64. wonder why i saved THAT
[18:09] <pitti> Riddell: hm, http://people.canonical.com/~ubuntu-archive/testing/maverick_probs.html says that koffice is uninstallable, do you already know why?
[18:11] <Riddell> pitti: koffice is build dep waiting on pstoedit which I had moved to main but seems to have slipped back into universe
[18:12]  * Riddell moves it to main again
[18:12] <pitti> Riddell: that would be a binary dep then, I guess?
[18:12] <pitti> Riddell: might have fell victim to a c-m cleanup during the time koffice wanted to go to universe
[18:12] <pitti> if that was me, sorry about taht
[18:13] <pitti> but pstoedit makes much more sense as a runtime dependency
[18:13] <Riddell> pitti: yes it's a runtime dep (although we keep it as a build time dep too to keep the build log cleaner)
[18:14] <pitti> Riddell: right, understood
[18:16] <pitti> Riddell: also seems to pull in a new package create-resources
[18:16]  * pitti promotes back the other bits
[18:17] <directhex> for reference, agricola.debian.org is slow. i could do with a quad-core 2.26ghz arm bof to test this stuff
[18:17] <pitti> Riddell: and libspnav and librcps
[18:28] <cjwatson> ogasawara: FYI, I've moved the kernel upload permissions to be attached to the ubuntu-kernel-uploaders team.  If this breaks anything (either upload permissions for the four of you, or the ability to target bugs to releases), then please let me know
[18:28] <ogasawara> cjwatson: will do, thanks
[18:35] <sbeattie> bdrung: pong?
[18:35] <SpamapS> so this MIR is in status "In Progress" but unassigned : https://bugs.launchpad.net/ubuntu/+source/libmemcached/+bug/586638
[18:35] <SpamapS> does that mean it needs to be added to a seed next?
[18:47] <Daviey> smoser: Does it, where?
[18:48] <Daviey> smoser: I'm seeing the build as 6 hours old.
[19:09] <pitti> RAOF: can we please drop /usr/share/doc/xserver-common/changelog.gz? it's almost a MB, and we are despearate for CD space
[19:10] <pitti> RAOF: it's a simple fix in debian/rules, and I'm happy to upload it, but I can't commit to git
[19:30] <Z-RAY_> after amateur tries to update MLT to 0.5.6 i have left without ffmpeg modules and even ffpmeg is installed, kdenlive says that some not installed at all. also it says that some sound module is not installed. i spent all day to make "lines and dots" bug dissappear (white lines and dots - was promised to be fixed in MLT 0.5.5) and i couldn't make it, even worse - now modules "avformat module", "Quimage module", "Title module" are missing and reinstalling
[19:30] <Z-RAY_>  of the program and ffmpeg does not helping.
[19:30] <Z-RAY_> help me please to make this thing work correctly. my skype is "woanerges", or write me here. please, bro's, come on, i need some support here!
[19:30] <Z-RAY_> white dots and lines examples:
[19:30] <Z-RAY_> http://kdenlive.org/sites/default/files/shot1_0.png
[19:30] <Z-RAY_> http://www.youtube.com/watch?v=nrFXr_bx2a0
[20:26] <ogra_cmpc> NCommander, grmbl
[20:36] <smoser> Daviey, you were right. i was looking at "seven days ago".  The timestamp on the changelog. the build is fresh.
[20:37] <bdrung_> sbeattie: ping
[20:38] <sbeattie> bdrung_: what's up?
[20:38] <bdrung_> sbeattie: is the replaces in bash-completion still required (bug #389633)?
[20:40] <bdrung_> sbeattie: the conflicting version was only available in the development release.
[20:46] <sbeattie> bdrung_: hrm? svk 2.2.1-0ubuntu1 was available for jaunty; I don't know offhand anymore if svk 2.0.1-1ubuntu3 in hardy contained it. However, for maverick, it should be okay to drop, as people upgrading should have come from lucid.
[20:47] <sbeattie> (and thus should have the updated version of svk that doesn't contain the bash completion file)
[20:49] <bdrung_> sbeattie: i looked at the history - svk was removed from lucid
[20:50] <sbeattie> bdrung_: hah, so it was.
[20:52] <bdrung_> sbeattie: so we just need to add the replaces to bash-completion in karmic, right?
[21:00] <sbeattie> bdrung_: for karmic, I *think* both replaces and conflicts are needed to ensure that on upgrades from jaunty, svk gets upgraded first.
[21:10] <ogra_cmpc> lamont, somehow i end up with the subarch attached to the project name in the livefs filename, i'm glaring at the code but dont get why
[21:11] <lamont> ogra_cmpc: because it hates you?
[21:11] <ogra_cmpc> i.e. i suddenly get livecd.ubuntu-netbook-omap.ext3
[21:11] <lamont> I mean, I'm not sure.
[21:12] <Kano> hi, why does my cpu run with lowest speed with maverick
[21:12] <ogra_cmpc> which makes debian-cd or rather find-live_filesystem fail indeed
[21:12] <lamont> prolly from fixing the subarch - that is, you might have not actually been the one to introduce this
[21:12] <lamont> ogra: what should it say?
[21:12] <ogra_cmpc> well, i only reverted to code that was there in luciod
[21:13] <ogra_cmpc> lamont, nothing, i'm looking for ideas, i dont see the issue
[21:13] <lamont> looking
[21:13] <ogra_cmpc> i see FSS="$FS${SUBARCH:+-$SUBARCH}" in livecd.sh
[21:13] <ogra_cmpc> but that line wasnt touched since lucid
[21:13] <Kano> which livecd.sh?
[21:14] <ogra_cmpc> so i dont get why FSS would be mangled while it wasnt before
[21:15] <ogra_cmpc> Kano, the one from livecd-rootfs
[21:16] <lamont> ogra: so...  in the past, SUBARCHARG only got set if you said -s.. now it unconditionally gets set
[21:16] <lamont> no, my bad
[21:17] <ogra_cmpc> your bad ?
[21:17]  * ogra_cmpc cant imagine
[21:20] <lamont> no
[21:20] <ogra_cmpc> the subarcharg stuff in buildlivecd is fine, its definately somewhere in livecd.sh
[21:20] <lamont> I misread when it got set
[21:20] <lamont> no clue
[21:20] <lamont> I suppose we could do a -x run for giggles
[21:20] <lamont> ogra_cmpc: say the word and I'll tweak it on acron
[21:21] <lamont> acorn, even
[21:21] <ogra_cmpc> phew that might produce a 500M log
[21:21] <lamont> not all that bad, really
[21:21] <lamont> there aren't all that  many commands in livecd.sh
[21:21] <ogra_cmpc> well, i'm pretty sure its the abive line that mangles FSS but that was added by infinity ages ago
[21:22] <ogra_cmpc> so i dont get why its changing just now
[21:22] <lamont> in rev 116, for that matter
[21:22] <lamont> brb
[21:23] <ogra_cmpc> yep
[21:26] <ogra_cmpc> i wonder if FSS was chnaged in a later line before and that reformatting was dropped
[21:28] <lamont> how many images are you handing it?
[21:28] <ogra_cmpc> only omap3 and 4 (for A2 even only omap3)
[21:29] <lamont> hrmpf
[21:29] <ogra_cmpc> for me it looks like FSS=$FS would be fine but why would that not have caused issues in lucid
[21:31] <ogra_cmpc> lamont, 28.2 was correct (it didnt have SUBARCH set at all)
[21:32] <ogra_cmpc> sadly the missing subarch made us miss a kernel/initrd
[21:34]  * lamont has to run off for a while
[21:41] <ogra_cmpc> lamont, i dont get the FSS line and i think i'll just change it to FSS=$FS for now, apart from armel noboduy is using subarches yet anyway
[21:59] <BlackZ> seb128: could you re-try the build of bug-buddy ? the bug has been fixed by didrocks
[21:59] <seb128> BlackZ, we will yes
[22:27] <ogra> lamont, so i guess initially the FSS mangling was added for the ps3 build but looking at cdimage and debian-cd i dont get how that would ever have worked
[23:08] <cjwatson> ogra: it certainly worked at one point
[23:10] <ogra_cmpc> cjwatson, thats very weird since i see no code that uses a livefs thats named livefs.ubuntu-ps3.squashfs, there is certainly no special casing in find-live_filesystem
[23:11] <ogra_cmpc> what bothers me more though is that livecd.sh seems to suddenly produce these filesystems for armel while it didnt for lucid builds
[23:11] <ogra_cmpc> i have worked around that for now but i still do get why behavior changed at all
[23:12] <ogra_cmpc> s/do/dont/