[00:59] <calc> anyone object to me doing bug 299161 for after beta?
[00:59] <calc> if possible anyway, it adds support for a lot of newer chipset (including mine)
[01:00] <slangasek> I hope that throw-away comment on IRC isn't meant to pass for a freeze exception request :)
[01:00] <calc> no just wanting to make sure there wasn't any obvious objection before i file for a freeze exception
[01:01] <calc> i noticed it in particular due to needing to find out why my laptop is dying
[01:02] <slangasek> calc: when preparing the request, please do a test build and let us know how the package size compares with the current version, since this is a package that goes on all CDs
[01:02] <calc> slangasek: ok will do
[01:05] <calc> its already packaged in debian but we have a changeset to merge, i should have something available by tomorrow (barring any more hardware failures)
[01:16] <CodyT07> hey
[01:17] <Hobbsee> greetings
[01:18] <CodyT07> hope u dont mind, where can i start on learning how to be an ubuntu developer?
[01:19] <CodyT07> im strongly curious on how u guys make this awesome os
[01:19] <cjwatson> http://wiki.ubuntu.com/ContributeToUbuntu http://wiki.ubuntu.com/UbuntuDevelopment
[01:20] <cjwatson> ha. bug 338788 is an excellent demonstration of how including helpful features can make problems harder to debug
[01:21]  * slangasek sighs.  Yes, opening display preferences causes the intel driver to generate log messages... so don't launch it when in the middle of drafting the technical overview when X has been running for > 28h. :/
[01:21] <cjwatson> that really is an embarrassing bug
[01:22] <CodyT07> one more question, pyhton the language to learn?
[01:22] <Snova> Yes.
[01:23] <CodyT07> much appreciated
[01:23] <Snova> If you have prior programming skills, it is used in many places in Ubuntu; if you don't, it is a good language to begin with.
[01:23] <cjwatson> CodyT07: Python is one possible language to learn which is likely to come in useful, but Ubuntu developers need to work with several languages on a day-to-day basis
[01:23] <cjwatson> CodyT07: so my advice is to stay flexible
[01:24] <CodyT07> i try, languages arent exactly my 'thing'  but i give it a try
[01:25] <cjwatson> the language you'll find yourself working in most depends very much on what your "thing" is
[01:25] <CodyT07> im better at finding answers to a sitatuion. E.g debugger
[01:26] <CodyT07> i cant write anything in php. but if something is broke i am usually good at finding what it is
[01:26] <calc> anyone else seen weird graphical issues on intel video on jaunty amd64 (today's cd)
[01:26] <calc> i'm not sure if it is a sign of my laptop dying or bugs somewhere
[01:27] <calc> i was getting graphics corruption and fonts not displaying in the right color (seemed to be background color)
[01:38] <nixternal> are we in freeze right now, or do we have a bit of time left? like say a few more hours?
[01:38] <cjwatson> we have been in beta freeze for some days
[01:38] <cjwatson> see ubuntu-devel-announce@
[01:38] <cjwatson> what is the problem?
[01:39] <nixternal> string freeze is today/26th
[01:39] <nixternal> odd that it sould be the same day as the beta release
[01:39] <nixternal> s/sould/would
[01:40] <cjwatson> if in doubt, drop a mail to the translators/documenters list s
[01:40] <cjwatson> lists
[01:40] <nixternal> oh well, I will just wait until after beta release to upload the kubuntu-docs...nothing life threatening
[02:13] <calc> when i reinstalled my laptop i used gpt, seems to work nicely with grub :)
[03:55] <doctormo> Does trackerd have an irc channel? or a place where developers go?
[03:58] <crdlb> doctormo: #tracker on gimpnet perhaps
[04:12] <slangasek> zul: could you please have a look at Debian bug #521225 for jaunty?
[05:58] <dholbach> good morning
[07:20] <DanMcGoo> Hi
[07:20] <DanMcGoo> I am trying to build my first debian package and I got some little problem
[07:20] <DanMcGoo> Someone can help me ?
[07:21] <RAOF> #ubuntu-motu is a better channel for that.
[07:21] <DanMcGoo> ok thanks
[07:27] <pitti> Good morning
[07:27] <pitti> james_w: problem> it still is, since it causes CK to exit, and thus CK doesn't work at all
[07:28] <pitti> james_w: shutdownkit> yes, nobody except William particularly liked this functionality in CK in the first place for this reason; and hal == shutdownkit, too
[07:29] <pitti> slangasek: 264336> I plan to do something about it in jaunty, yes; either by handling the failure more gracefully at install time, or creating more dynamic defaults. however, I want to consult with upstream about this first
[07:35] <slangasek> pitti: ok (morning)
[07:36] <pitti> slangasek: I'm confused; nvclock doesn't build a smartdimmer package, nor does the nvclock binary ship it
[07:36] <slangasek> pitti: correct, that will happen with the next upload of nvclock - it couldn't happen before the MIR was approved
[07:36] <slangasek> because smartdimmer is already in main, from a different (obsolete) source
[07:37] <pitti> ah, it's stil in the sponsoring queue
[07:37] <slangasek> no, it's in the "Steve isn't uploading this because he doesn't want it accidentally accepted into main because it looks like a universe package" queue
[07:38] <pitti> slangasek: seems we shuold remove the smartdimmer source from the archive then?
[07:38] <pitti> the only other (except hal) rdepends is acpi-support
[07:38] <slangasek> yes, but not during the freeze...
[07:38] <pitti> and I guess that should be obsolete
[07:38] <pitti> slangasek: right, just planning
[07:38] <pitti> I won't move nvclock to main either
[07:38] <pitti> I just saw the MIR approval
[07:39] <slangasek> FWIW, I have a handle on this on my end and am ready to push the buttons once beta is out
[07:48] <ogra_> slangasek, do you have any idea what tool cjwatson used to copy my babbage image in place ?
[08:05] <slangasek> ogra_: other than 'cp'?  no
[08:05] <ogra> well, its owned by cdimage
[08:06] <ogra> and only writeable by the user
[08:06] <slangasek> is that unusual?
[08:06] <ogra> i'd like to do one update (there was one preseed option added to the cmdline, its tested and ok, but i cant copy the img (while i can edit the html in the dir)
[08:07] <slangasek> probably 'cp', in any case
[08:07] <ogra> i'm not the cdimage user :)
[08:07] <slangasek> do you not have sudo access?
[08:07] <ogra> i'm only in its group
[08:07] <ogra> i cant sudo to cdimage, it asks for a pw
[08:08] <ogra> tried that already indeed
[08:08] <slangasek> ok, I'll change the perm to match the other files
[08:08] <ogra> thanks
[08:08] <slangasek> done
[08:09] <ogra> hmm, now the dir name doesnt match anymore indeed ...
[08:09] <ogra> can i just mv it from 25 to 26 ?
[08:09] <ogra> ugh, and the md5sum might not ... sigh
[08:10] <ogra> slangasek, i think we need to wait for cjwatson here, i dont feel safe poking around there on my own
[08:12] <pitti> james_w: hm, I looked deeper at the PK code, and it already does the right thing if the context is NULL, or the .conf file is absent
[08:12] <pitti> james_w: if we could fix this robustly in PK, then it would apply to all apps, not just CK
[08:12] <pitti> well, I'll play around with this a bit
[09:19] <Meiz_n810> what is the stage of plasma-mid?
[09:20]  * Meiz_n810 wants to try it on his n810, and wonders when it will be available :P
[10:04] <pitti> seb128: nice, amd64 retracer caught up, i386 almost
[10:05] <seb128> pitti: ;-)
[10:05] <seb128> you rock!
[10:06] <Kano> hi, is the dkms maintainer here?
[10:07] <pitti> Kano: that's superm1
[10:07] <Kano> ic
[10:09] <tjaalton> asac: hey, I've got issues with an Option GE0301 3G card, it refuses to connect (hso_auth_done(): Authentication failed). Should I blame the kernel?-)
[10:10] <asac> tjaalton: so you are not using networkmanager? ;)
[10:10] <asac> or you are not running latest jaunty ;)
[10:11] <asac> tjaalton: is that a regression?
[10:11] <tjaalton> asac: using NM, current jaunty
[10:11] <tjaalton> I've never used the device before
[10:12] <tjaalton> had to use ozerocdoff to make the driver work at all
[10:13] <tjaalton> I'll grab the 2.6.29 vanilla deb to see it it's any better
[10:13] <asac> tjaalton: yes. please check that
[10:18] <Kano> tjaalton: did you try to compile current karmic git
[10:21] <tjaalton> Kano: no, it's the same upstream version
[10:21] <tjaalton> asac: still the same :/
[10:22] <asac> tjaalton: whats the product/vendor id of that modem?
[10:22] <tjaalton> 0af0:7011
[10:23] <Kano> tjaalton: with fixed aufs at least the generic kernels work in live mode. you only need a squashfs-tools cvs package for newer mksquashfs
[10:23] <Kano> i could not get the server kernel to compile
[10:23] <tjaalton> uh
[10:23] <tjaalton> I'm not interested in aufs
[10:24] <Kano> you dont need live mode ;)
[10:25] <tjaalton> correction, I don't need aufs :)
[10:25] <Kano> what do you want to use instead
[10:25] <soren> Kano: I think tjaalton's point is: Why are you telling him about aufs?
[10:25] <tjaalton> right..
[10:26] <soren> I'm wondering the same thing, incidentally.
[10:26] <Kano> so what do you use instead of aufs in case you want to create a live image
[10:27] <tjaalton> I've no need to create a live image
[10:58] <rniamo> hi
[10:58] <rniamo> is it normal that xorg use 90% of cpu unit ?
[10:58] <rniamo> 3125 root      20   0  417m  60m  24m R   84  6.1  69:52.53 Xorg
[11:02] <tjaalton> perfectly normal
[11:02]  * tjaalton runs for lunch
[11:02] <rniamo> why ?
[11:04] <tjaalton> it's probably doing something really important
[11:04] <rniamo> always ?
[11:05] <tjaalton> running compiz
[11:05] <tjaalton> ?
[11:05] <rniamo> yes
[11:05] <rniamo> but usually it's work normally
[11:05] <tjaalton> try not to
[11:06] <tjaalton> or just file a bug.. 'ubuntu-bug xorg-server'
[11:06] <rniamo> without it's ok but ... it is withou
[11:07] <tjaalton> maybe your driver doesn't support some of the fancier effects, and it's falling back to software rendering
[11:07] <rniamo> ok
[11:13] <tkamppeter> pitti, hi
[11:14] <tkamppeter> I am trying to merge the Intrepid CUPS branch back into my branch with LP, but I did not find out how to do the actual merge. I have posted a merge request and approved it, but the merge does not happen.
[11:21] <Laney> tkamppeter: while in the base branch you do bzr merge <target>
[11:24] <pitti> hi tkamppeter
[11:24] <pitti> tkamppeter: as I mailed you, please just "pull", that'll clean up history
[11:25] <pitti> tkamppeter: the merge won't happen automatically, you need to manually do this
[11:25] <pitti> tkamppeter: a merge request in LP is someone else asking *you* to review and merge their branch into your's
[11:25] <pitti> tkamppeter: the thing you mean is called "PQM" (patch queue manager), but we don't use that for most projects
[11:31] <cjwatson> ogra: so what did you do to custom/20090325-armel+imx51? The timestamp of the image seems to have been updated
[11:32] <cjwatson> ogra: hmm, and it now matches the one currently in your home directory
[11:32] <cjwatson> (yes, I read scrollback)
[11:32] <ogra> cjwatson, yeah
[11:32] <cjwatson> ok, you generally shouldn't ever change existing files on cdimage
[11:32] <ogra> but i didnt know what to do for the MD5SUM
[11:32] <ogra> oh, ok, you said i should edit the html just there
[11:32] <cjwatson> html fine, but not images
[11:32] <ogra> ok
[11:33] <cjwatson> I've moved it to 20090326-armel+imx51
[11:33] <ogra> thanks
[11:33] <cjwatson> that'll fix up any mirrors of cdimage that have got confused
[11:33] <ogra> have you seen bug 348660 ?
[11:33] <cjwatson> I've also updated MD5SUMS and MD5SUMS.gpg
[11:33] <ogra> thanks as well
[11:34] <cjwatson> no, I had a really late night and am just getting started
[11:34] <ogra> while emmets fix is good, i think there is still some issue with the logic for ubiquity/install_bootloader=false
[11:34] <cjwatson> I'll look at it
[11:34] <ogra> thanks
[11:34] <cjwatson> as Emmet says the real fix is to have a proper bootloader installer component in ubiquity
[11:34] <ogra> indeed
[11:35] <ogra> thats fine, but ubiquity/install_bootloader is a boolean so imho "if not (automatic_mode and install_bootloader):" is wrong
[11:36] <ogra> i'm never in automatic mode by default, so automatic_mode is unset (i guess None)
[11:36] <ogra> if i define  ubiquity/install_bootloader=false thats translationg to: "if not (None and False):"
[11:37] <ogra> which in the end turns true
[11:37] <ogra> which in case where you dont have a system that uses grup will automatically set  ubiquity/install_bootloader=True
[11:37] <ogra> *grub
[11:38] <ogra> making the user end up with the exact opposite he selected through preseeding
[11:38] <persia> ogra, It's *not* wrong.  That's the expected behaviour with preseeding ubiquity if you aren't in automatic mode.
[11:39] <persia> Mind you, the logic could be a bit nicer, and have some interaction, but that's a separate issue.
[11:39] <ogra> persia, setting UBIQUITY_AUTOMATIC in /etc/profile ... doing a relogin got me the exact same behavior though
[11:40] <persia> Hrm!  If you *are* in automatic mode, it should respect the preseed.
[11:40] <ogra> it doesnt, it still moves on to the function and dies there
[11:41] <cjwatson> ogra: the point is basically that install_bootloader wasn't really designed for preseeding, but for internal use by ubiquity. Given that, nitpicking its logic is a bit pointless
[11:41]  * Mithrandir twiddles thumbs as he upgrades his laptop to jaunty.
[11:42] <ogra> cjwatson, ah, well, we have a proper fix, its just confusing behavior imho ... i doubt i'll ever use it again anywa
[11:42] <ogra> y
[11:42] <persia> ogra, My hack is *not* a proper fix.
[11:42] <persia> I've branched flash-installer, and will look at a proper fix, but it's not going to use "pass".
[11:43] <ogra> your hack is 80% of the proper fix we have to do in ubioquiry
[11:43] <ogra> *ubiquity
[11:43] <seb128> is anybody working on openchange in ubuntu?
[11:43] <seb128> bug #338982 is a frequent evolution-mapi crasher
[11:43] <seb128> supposed to be fixed in openchange and libmapi 0.8.2
[11:43] <persia> ogra, No, it's not.  It's about 3%.
[11:43] <cjwatson> ogra: your percentages are different from mine
[11:43] <ogra> persia, the rest is copy paste from one of the above functions and adjusting the binary name
[11:44] <cjwatson> perhaps because I have actually implemented this stuff before
[11:44] <cjwatson> ogra: I've done this before. Trust me
[11:44] <ogra> i do :)
[11:44] <persia> ogra, The majority of the work is making flash-kernel-installer not expect that the udeb postinst will be run, and still working.
[11:44] <ogra> thats nothing you have to do in ubiquity
[11:45] <persia> Beyond that, it's just creating a FilteredComponent to drive it, and then, yes, just a quick change to install.py
[11:45] <ogra> right, thats what i'm referring to
[11:45] <cjwatson> it might as well be in ubiquity. ubiquity has to incorporate flash-kernel if it's going to use it like this.
[11:45] <ogra> i agree that we have to do massive changes to flash-kernel-installer but thats not beein in my scope
[11:45] <ogra> *been in
[11:45] <persia> Indeed, and flash-kernel needs to be investigated to make sure that it's compatible with the way ubiquity is built.
[11:46] <ogra> no, flash-kernel wont be touched by ubiquity
[11:46] <persia> Yes it will.  That's how ubiquity works.
[11:46] <ogra> its either run by flash-kernel-installer directly or only from the linux-image postinst as its done on all other armel platforms
[11:46] <cjwatson> persia is correct
[11:47] <persia> The flash-kernel-installer is created from the flash-kernel package.  The flash-kernel package will need to be split, or it will need to be embedded entire within ubiquity.
[11:47] <ogra> why would we change its default behavior ?
[11:47] <cjwatson> there's no need to split it
[11:47] <persia> (this is because udebs are not installed during a live install).
[11:47] <persia> cjwatson, That's good news.  I hadn't tested a build yet.
[11:48] <persia> ogra, Because right now flash-kernel-installer is 90% postinst, and we're not going to run the postinst.
[11:48] <cjwatson> you just arrange for that bit of d-i/source/ to be built only on armel. There are list files for this
[11:48] <ogra> flash-kernel-installer needs to dump redboot in place with the proper offset and then call flash-kernel (which is anyway done by the linix-image package)
[11:48] <ogra> *linux
[11:48] <persia> cjwatson, I was more concerned about not wanting to include the contents of the flash-kernel package, but just the flash-kernel-installer udeb, and then add flash-kernel to bootloader-depends.
[11:49] <cjwatson> persia: sounds like makework to me
[11:49] <ogra> if we change flash-kernel-instaler that massively we should probably just do a new script
[11:49] <persia> ogra, That's not what flash-kernel-installer does at all.
[11:49] <cjwatson> persia: I have a fix for the preseeding logic in bug 348660. Do you want to keep that bug open for the flash-kernel work, or shall I just close it?
[11:49] <ogra> persia, but thats what we need (additional to the kernel-img.conf work it already does)
[11:49] <persia> cjwatson, Feel free to just close it, if you're changing the logic.  The stuff I was looking at is easily separable.
[11:50] <cjwatson> persia: there's actually nothing necessarily wrong with just running the postinst, is there?
[11:50] <cjwatson> it looks a plausible enough approximation to what we'd need to run
[11:51] <persia> cjwatson, I haven't dug in much, but I renamed the postinst to flash-kernel-installer, added a postinst that called that, and installed it with an install, which gives us /usr/bin/flash-kernel-installer
[11:51] <ogra> right, it just needs to grow something that dumps redboot in place ... and if its a call to an additional redboot-install script or something
[11:51] <ogra> the rest can go as is
[11:51] <persia> I thought that would be easier to trigger from FilteredCommand.
[11:51] <cjwatson> persia: that sounds unnecessary. See the stuff in debian/rules that handles {kboot,yaboot,silo}-installer
[11:52] <cjwatson> all you need to do is install the postinst under /usr/lib/ubiquity/ somewhere
[11:54] <persia> cjwatson, Oh, I see.  Indeed, that would be simpler.
[11:54] <tkamppeter> pitti, thanks, then it seems that "Request Merge" is simply a messaging system between the two branch owners and nothing to do web-interface controlled operations on the branches.
[11:54] <pitti> tkamppeter: exactly
[11:54] <cjwatson> I think I'll leave the bug open after this preseeding work since it does actually appear that most of the work belongs in ubiquity
[12:01] <tkamppeter> pitti, branch is merged back now. Thanks.
[12:15] <zul> slangasek: done
[12:17] <cjwatson> ogra: so given that preseeding doesn't work, what are we doing about the image? Are you applying persia's quick hack to your image for the time being?
[12:18] <ogra> well, its not doing any harm (since its teh very last step anyway), i just noted it on the wiki
[12:18] <cjwatson> no, it is not the very last step
[12:18] <ogra> well, before the reboot message which users need to ignore anyway to set the bootloader
[12:19] <cjwatson> after boot loader installation comes: installing any additional required packages (e.g. language packs); removing packages that are not required (e.g. the installer itself); copying log files; and a few other bits and pieces
[12:19] <ogra> not here
[12:19] <cjwatson> I'm looking at the damned code
[12:19] <ogra> my langpacks get installed, removal is done
[12:19] <ogra> weird
[12:19] <ogra> i had all that
[12:19] <cjwatson> well, I don't know how on earth you can possibly have that
[12:19] <cjwatson> that stuff is clearly after configure_bootloader
[12:20] <ogra> very weird
[12:20] <ogra> well, i'm not sure how to apply that fix from my script since i cant access the squashfs
[12:21] <cjwatson> you might just have to copy it off to another machine where you have root
[12:21] <ogra> or squashfs-tools
[12:21] <ogra> hmm
[12:21] <cjwatson> oh, I could RT that
[12:22] <ogra> that would be cool
[12:22] <ogra> seems helpful to have on antimony anyway
[12:23] <cjwatson> RTed and asked #is
[12:24] <maxb> Who can I chase up a problem with paste.ubuntu.com with, after mailing rt@ubuntu.com resulted in no response?
[12:27] <highvoltage> ask in #canonical-sysadmin
[12:27] <cjwatson> ogra: 12:25 <agy> cjwatson: done
[12:27] <ogra> thanks :)
[12:27] <ogra> i'll look at the script after the meeting
[12:28] <cjwatson> ogra: careful though, do armel and amd64 have the same endianness? can you in fact safely build a squashfs for the former on the latter?
[12:28] <ogra> no idea, i'll try it
[12:28] <cjwatson> ogra: ISTR that squashfs' format is independent of the creating architecture but I know this changed a while back and I can't remember the direction in which it changed
[12:29] <cjwatson> mksquashfs has -le and -be options in case you need to override it
[12:29] <ogra> ok
[12:37] <directhex> amd64 is little endian
[12:42] <pitti> seb128: ah, tail of  apport-retracer-amd64-hardy/log_dupcheck.txt is music in my ears :)
[12:42] <pitti> seb128: however, it seems that invalid bugs just account for half of the slowness; I'll track this down further this afternoon then
[12:43] <pitti> seb128: seems some bugs like bug 332378 don't have a coredump and no needs-*-retrace tag
[12:44] <pitti> weird
[13:20] <lool> ogra: I don't think flash-kernel should install redboot
[13:20] <lool> cjwatson, persia: poke
[13:20] <lool> cjwatson: So basically we're abusing flash-kernel
[13:20] <ogra> lool, thats why i proposed a redboot-install script
[13:20]  * cjwatson would like to hear the problem statement before the solution proposal
[13:20] <lool> cjwatson: the board has this special behavior that it will run redboot from SD and have a flash directory in SD, while it's usually in soldered on flash
[13:20] <ogra> but being called by flash-kernel-installer
[13:21] <lool> cjwatson: There's a switch on the board; either you boot from soldered internal flash (which is tiny so not an option anyway for now) or you boot from SD (what we do)
[13:21] <lool> cjwatson: Now problem is that we're starting an install from SD and we would like to offer an installed system in the end; but usually we don't overwrite the install media
[13:22] <lool> So we had multiple options; one is to ask for an USB SD reader and install on another SD as the target, but this also requires installing redboot and special hardware
[13:22] <ogra> which we need to do in this case to get something like a lilo bootfloppy
[13:22] <lool> The option we're currently aiming at is to install the target kernel and initramfs on the install medium: the SD, hence erasing the ones from the installation live SD card
[13:22] <lool> cjwatson: (does that make any sense until now?)
[13:23] <liw> in /proc/mounts, should the kernel encode mount options that contain spaces? (ref. https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/112272)
[13:23] <lool> cjwatson: Now if we try to fit flash-kernel in this picture, it's usually meant to write to mtd devices; I changed it to use dd and fis to write to specific offsets of a hardcoded /dev: the SD cards
[13:23] <lool> cjwatson: It's ugly at various levels, one being that we shouldn't hardcode that /dev in flash-kernel itself IMO
[13:24] <lool> That's one issue
[13:24] <mvo> liw: that would be nice indeed - I think this problem is "fixed" in the code in u-m, it will ignore lines it can not parse
[13:24] <ogra> we could just rip your changes out of flash-kernel and stick it into a redboot script
[13:24] <lool> Another issue is that we need to pass the initramfs size in the bootscript launching the kernel, the redboot bootscript, and update it when it changes
[13:24] <liw> mvo, oh right, I meant to say that, too
[13:25] <ogra> it could well be its own
[13:25] <lool> cjwatson: I think this can be solved more elegantly, I'm reluctant to let flash-kernel parse and update the bootscript on each upadte-initramfs update
[13:25] <ogra> but we're to late to fix it differently imho
[13:25] <lool> Finally, there are two side issues which I'd better mention: it seems flash-kernel is sometimes called before the initramfs has been generated (discussed in debian in the past I think) due to triggers, and the other is that we need a redboot udeb if we want to support installation into a fully bootable SD card
[13:26] <cjwatson> lool: I tend to think that introducing a new component is going to be more trouble than it's worth, and if it can be crowbarred into flash-kernel in a way that isn't completely unreasonable, we should do that
[13:26] <mvo> liw: yep, just confirmed
[13:26] <liw> mvo, me too; alas, I'm not sure that makes it OK to close the bug, since perhaps it should be reassigned to the kernel
[13:26] <mvo> liw: right, I agree
[13:26] <mvo> liw: I wonder what mount does in this case
[13:27] <liw> mvo, does mount parse /proc/mounts? and not /etc/mtab?
[13:27] <lool> cjwatson: Ok; I didn't really consider a new component so far; I had in mind that perhaps we should have a flash kernel config for the /dev hardcoding issue, and a redboot udeb -- that qualifies as a new component -- if we care about installing to a SD card, but it's harder than just redboot
[13:28] <cjwatson> lool: redboot-udeb in itself would be rather trivial; it would basically just ship the binaries, right?
[13:28] <lool> cjwatson: Basically, a sense of taste is welcome for the current flash-kernel hacks we're doing, and we also need help on the initramfs size issue
[13:28] <mvo> liw: I would have to look at the code to know that :)
[13:28] <lool> cjwatson: No, I had in mind that it would allow installation of redboot at the right place on a SD card
[13:28] <cjwatson> lool: the installer integration logic is the expensive bit that is worth not duplicating
[13:28] <ogra> cjwatson, and a dd command to punch it in place
[13:28] <lool> cjwatson: Currently, we don't install redboot
[13:28] <lool> Just kernel and initramfs
[13:28] <mvo> liw: I closed the u-m task for the bug now, but we should probably open onefor the kernel
[13:28] <lool> cjwatson: I see
[13:29] <cjwatson> lool: but wouldn't that involve a sequence of bootloader installation steps?
[13:29] <cjwatson> redboot, then the kernel
[13:29] <mvo> liw: or use mtab if that is correctly encoded
[13:29] <ogra> the order doesnt matter, but yes
[13:29] <lool> Personally, I don't care much with install redboot; I see it's useful, but our hardware is a corner case and it can be done without the help of the installer
[13:29] <lool> cjwatson: Yes, that's correct
[13:29] <cjwatson> lool: in general, the way d-i works means that there must be one package responsible for bootloader installation (on a given subarch, blah)
[13:29] <lool> cjwatson: Aha, we kind of faced this situation when we wondered whether flash-kernel would qualify as a bootloader
[13:29] <cjwatson> lool: the installer will not cope very well if you try to have a sequence of packages, so it will work better if you have flash-kernel-installer do the lot
[13:30] <cjwatson> flash-kernel-installer qualifies as a bootloader installer in this sense
[13:30] <ogra> flash-kernel is similar to update-grub while we'Re missing grub-install
[13:30] <lool> cjwatson: Perhaps it's best if we implement the flash-bootloader feature in flash-kenrel then, but only for some subarches and only when redboot is available and only when a debconf entry is set
[13:30] <cjwatson> apart from anything else, it Provides: bootable-system
[13:30] <cjwatson> which is the key thing that d-i uses
[13:31] <lool> cjwatson: What makes the babbage different here is that the bootloader is on the installation medium and it's not clear whether it's reused to boot the target system or not
[13:31] <cjwatson> lool,ogra: you can tweak the logic using isinstallable scripts, but it tends to be easier if you keep it to one bootloader installer per subarchitecture
[13:31] <lool> Usually, the bootloader is in the plaform's soldered flash
[13:31] <cjwatson> by "bootloader installer" in d-i in general I include "bootloader configurator"
[13:31] <cjwatson> the task is to make the system bootable
[13:32] <cjwatson> whether the bootloader is there already is a distraction, at that level
[13:32] <persia> The interesting bit is that flash-kernel-installer installs additional packages that get used by flash-kernel.  The same sort of logic could be used to install redboot, if required.
[13:32] <lool> cjwatson: The thing is that you can remove this SD card and swap it with the kernel one
[13:32] <cjwatson> something that provides bootable-system should just get the job done whatever way it needs to
[13:32] <lool> Or you might want to keep booting from the install SD card
[13:32] <persia> As long as running flash-kernel does the right thing later on.
[13:32] <liw> mvo, I just checked: mtab is correctly encoded, but I still think this is a kernel bug
[13:32] <cjwatson> lool: sure, it makes sense to me that you'd want the kernel SD card to be bootable if possible
[13:32] <lool> cjwatson: So if we care to support both scenarii, we need to have some prompting for it I think
[13:33] <cjwatson> why not just make both bootable?
[13:33] <lool> cjwatson: I don't think we can distinguish a SD in USB mass storage from an USB disk though
[13:33] <ogra> there is only one SD slot :)
[13:33] <ogra> which carries your install media
[13:33] <cjwatson> so you need a step involving switching media?
[13:34] <cjwatson> how is that going to work while the installation medium is mounted on /cdrom?
[13:34] <lool> cjwatson: We could make both bootable I guess indeed; we need a way to run flash-kernel twice on the two devices
[13:34] <ogra> wont work with live images i guess
[13:34] <cjwatson> which it will be
[13:34] <ogra> right
[13:34] <cjwatson> I don't think it will work even with d-i
[13:34] <lool> cjwatson: switching media after boot
[13:34] <lool> Not during install
[13:34] <ogra> the only way is to either use a USB SD reader as target
[13:34] <mvo> liw: thanks, just open a task for it then please
[13:34] <ogra> or to wipe your install media
[13:34] <liw> mvo, just figuring out how to do that :)
[13:34] <lool> cjwatson: A bit like you would install to an external USB SATA enclosure, then take the disk out of the enclosure and boot your laptop on it
[13:34] <mvo> heh :)
[13:35] <lool> +if
[13:35] <persia> lool, Let's call that a separate case.  Let's have 1) modification of the installation medium to boot the installed system with no changes, and 2) modification of a boot target from an installed system.
[13:35] <cjwatson> ogra: you can't wipe the install media, it's mounted during installation, surely?
[13:35] <cjwatson> medium
[13:35] <ogra> cjwatson, i can wipe the bootloader parts
[13:35] <cjwatson> sure
[13:35] <ogra> and thats what *i* am aiming for atm
[13:35] <lool> persia: Yes, that's what I wanted to do in the beginning, but cjwatson raised two points: we should implement that in a single component, and also we could simply make the two things bootable
[13:35] <ogra> since thats the only sane setup
[13:36] <lool> cjwatson: The part which we touch isn't mounted: it's a special partition at the beginning of the media which holds the redboot data
[13:36] <cjwatson> it seems to me that when doing 2) you have the same general goal
[13:36] <persia> lool, See, I'd consider case 2 to be well outside "The installer", and just be an end-user use-case.
[13:36] <ogra> all others will require hoops to jump through like "install to usb cardreader"
[13:36] <cjwatson> you just want to make the thing bootable
[13:36] <lool> the redboot partition table, redboot, the redboot config, the kenrel and the initramfs
[13:36] <cjwatson> you don't want to have to jump through multiple hoops to do it
[13:36] <persia> And I don't think we can "simply make the two things bootable" since we can't know whether a given target *can* be made bootable.
[13:36] <ogra> right
[13:37] <cjwatson> you can tell whether redboot is already there, and otherwise warn
[13:37] <ogra> my target is to make the SD a "lilo like bootfloppy"
[13:37] <lool> persia: We can still make it bootable and it will be if it's SD
[13:37] <ogra> which a) means we wont need to dump redboot in place at all
[13:37] <cjwatson> on the initramfs size, if redboot simply has to be told, then I don't see any way around having to invoke flash-kernel after every update-initramfs
[13:37] <cjwatson> or something that will update the configuration
[13:37] <ogra> and b) only means to update the initramfs and redboot script
[13:37] <lool> cjwatson: So on my thecus that's not needed
[13:37] <ogra> yes, thats clear
[13:38] <lool> cjwatson: I copied the logic to do padding like the N2100 one in flash-kernel
[13:38] <cjwatson> lool: this is why flash-kernel is insanely system-specific, though?
[13:38] <lool> cjwatson: and tried passing initrd= and mem= to the kernel, and it didn't help
[13:39] <lool> cjwatson: I don't mind doing padding, but I hate having to parse a boot script, just like a grub menu.lst, each time we upgrade the initramfs just because it seems I can't figure out how to tell the kernel or redboot that this is a padded initrd
[13:40] <ogra> well, there isnt so much parsing
[13:40] <ogra> the option cant move around
[13:40] <ogra> and in the end its only one single value we change
[13:40] <lool> ogra: It's possible, but you'll have to handle space, tabs, the user removing the -s etc.
[13:40] <ogra> comparing that to update-grub is a bit much
[13:40] <ogra> the user cant remove the -s
[13:41] <ogra> then it wont boot
[13:41] <pitti> seb128: i386 retracer crashed, I'm looking into it
[13:41] <cjwatson> does the redboot configuration file format have any support for including other files, setting variables ...?
[13:41] <lool> cjwatson: http://lists.debian.org/debian-arm/2009/03/msg00122.html
[13:41] <seb128> pitti: thanks
[13:41] <ogra> cjwatson, cmdline can change
[13:41] <lool> cjwatson: No; it's an array of typed values (bool, int, string, bootscript) and the bootscript lists the commands which redboot runs
[13:42] <lool> cjwatson: There must be something I'm doing wrong which explains why it works on N2100 and not on iMX51
[13:42] <cjwatson> you're way out of my league here
[13:42] <ogra> cjwatson, http://paste.ubuntu.com/138253/
[13:43] <ogra> what we catively change is only "bootscript_data"
[13:43] <ogra> and of that we only change the last line
[13:43] <ogra> (usually even only the value for -s)
[13:44] <ogra> (ignore oqwi74239 ... thats from me playing)
[13:44] <lool> cjwatson: Ok; so you recommend a) changing flash-kernel to also install redboot + b) falsh-kernel to both target device and to install SD
[13:45] <lool> cjwatson: What about config, /etc/flash-kernel.conf ok?
[13:45] <lool> (to have a way to tell flash-kernel to flash either device and to tell it what to write)
[13:45] <persia> lool, How can you tell if the install medium is an SD?
[13:45] <lool> persia: i can't
[13:45] <lool> persia: But we could have a knob for it, and do it unconditionally
[13:45] <cjwatson> doesn't it show up in /sys?
[13:45] <persia> I think it's best to concentrate on the simple case first.
[13:45] <lool> cjwatson: it will show as usb mass storage
[13:45] <cjwatson> lool: what configuration?
[13:46] <lool> cjwatson: the dev to flash; currently I hardcode /dev/mmcblk0
[13:46] <lool>                 # XXX allow for other devices than SD
[13:46] <lool>                 dev="/dev/mmcblk0"
[13:46] <cjwatson> ah, yes
[13:47] <ogra> well, given that the actual flash is to small and we can only boot from SD ... whats the issue here ?
[13:47] <persia> Might make sense to get the value from debconf, and default to /dev/mmcblk0 for now.  That makes it easy to add an interface later, if desired.
[13:47] <cjwatson> hmm
[13:47] <ogra> we do not have any other bootdevcie
[13:47] <cjwatson> persia: I don't think that's easy to do given that flash-kernel's interface permits it to be called without a debconf frontend
[13:47] <lool> ogra: If the value ever changes; I'm not too confident the name doesn't change
[13:48] <cjwatson> well, I suppose it could operate standalone
[13:48] <ogra> lool, thats totally not jaunty though
[13:48] <cjwatson> but it'll produce lots of junk on stdout
[13:48] <persia> cjwatson, I was thinking of flash-kernel-installer vs. flash-kernel.
[13:48] <lool> cjwatson: So what I'd expose in the config: a) what components do you want to flash b) where to flash it
[13:48] <cjwatson> persia: won't help with the post-installation case
[13:48] <lool> cjwatson: actually it's to stderr
[13:48] <cjwatson> lool: probably depends on frontend
[13:49] <persia> Don't we need flash-kernel to be installed post-installation anyway, just to handle update-initramfs?
[13:49] <cjwatson> you could use debconf-communicate
[13:49] <cjwatson> not very nice, but could work
[13:49] <cjwatson> but I think a configuration file would be more elegant
[13:49] <lool> ogra: I don't think having a flash-kernel.conf is hard
[13:49] <cjwatson> persia: yes
[13:52] <lool> cjwatson: the other option for the components to install or the target device would be to extend the command line flags of flash-kernel
[13:52] <lool> That would allow for running flash-kenrel on the two SDs and writing redboot to one
[13:52] <lool> But only once
[13:53] <persia> So when run during install, you could install the bootloader to several places, but once installed it just updated it?
[13:53] <lool> Yes
[13:53] <lool> Once installed it would only update the current place
[13:54] <lool> Bah I'm just not convinved wiht this whole two SD approach, it makes things more complex and ugly
[13:55] <persia> I think it's easier to just overwrite the contents on the media from which you booted in the simple case.  Those who want to do a two-SD solution may well be served by documentation.
[13:55] <ogra> ++
[13:55] <persia> s/the contents/the boot configuration/
[13:56] <liw> mvo, if you have time: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/116465 -- edgy to feisty upgrade, no duplicates, no info from other people than reporter; I can't seem to easily test that upgrade, but my guess would be that there was something broken back then, in some cases, but it's fixed since -- what do you think?
[13:56] <cjwatson> lool: in general I have no problem with programs having both configuration files and command-line flags :-)
[13:56] <persia> lool, All the more so because by default the partitioning scheme for any target device isn't going to match that which is required to be able to install redboot, so you'll have to document a procedure anyway.
[13:57] <lool> persia: Ah thanks for saying aloud what I was thinking from the start (with two SDs)
[13:57] <persia> As long as the end-user is *able* to point flash-installer at an alternate medium post-install.
[13:57] <mvo> liw: yeah, agreed. back in those days the qt frontend was not very stable
[13:57] <lool> Ok; then I don't need to make flash-kernel write redboot either
[13:57] <lool> I mean I can, it's nice, but not required
[13:58] <liw> mvo, I'll close it then
[13:58] <ogra> yeah
[13:58] <cjwatson> lool: you do for the installer side of things, don't you?
[13:58] <mvo> liw: it probably just crashed somewhere in qt, no python backtrace nothing
[13:58] <persia> That means that a sufficiently motivated end-user can partition a second SD just so, and then run the appropriate commands to install a bootloader on the alternate SD, and update their kernel and initramfs on the alternate SD, and boot from that, if they like.
[13:58] <ogra> cjwatson, no, we have everyting on the install media we need
[13:58] <ogra> cjwatson, we just change the config
[13:59] <ogra> for that ambitioned user i can easily cut out the necessary snippets fom my builder script
[13:59] <ogra> and another big big plus is that fconfig doesnt actually need to grow an init command for jaunty
[14:01] <persia> ogra, Well, as long as the end-user can do the right thing later.
[14:01] <ogra> with my script snippet and the fconfig.bin blob
[14:01] <ogra> no prob
[14:03] <ogra> persia, http://paste.ubuntu.com/138266/ thats all thats needed
[14:03] <lool> cjwatson: I personally think the dual SD install involves a lot of masoshism from us to support it: we would need to teach the installer about creating a special partition to protected the redboot data, then init the redboot partition, redboot config, copy redboot and tell flash-kernel about this non-standard SD card location; if however we drop that usecase, and hence overwrite the SD installation media as the target boot media, we just need ...
[14:03] <lool> ... to run flash-kernel as I wrote it
[14:03] <liw> is linuxmce well known?
[14:04] <lool> But then that dual SD card has been brought up over and over and I thought we had to deal with it, but given the above discussion I'm inclined to kill it from installer
[14:07] <persia> ogra, The fconfig.bin blob is included in the redboot-tools, package, right?
[14:07] <ogra> no
[14:09] <ogra> its published on http://cdimage.ubuntu.com/custom/20090326-armel+imx51/
[14:10] <cjwatson> lool: oh, right, of course the install medium already has redboot
[14:10] <cjwatson> I forgot about that
[14:12] <ogra> it has everything, thats the big plus here, we just need to modify whats there
[14:13]  * maxb applauds Hobbsee's comment on bug 332945
[14:15] <liw> mvo, https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/122197 -- edgy to feisty, no duplicates, log files from someone else but they didn't give any info, can't quickly find anything else wrong than a conffile prompt in the bug reporters log files -- what do you think?
[14:18] <pitti> seb128: hah; turns out that the remaining inconsistency cases in the dupdb consolidation is a p-lp-bug apparently :) it works fine with launchpadlib
[14:24] <ogra> cjwatson, sigh ... "create_inode: could not create character device squashfs-root/dev/agpgart, because you're not superuser! Success"
[14:24] <ogra> so unsquashfs isnt an option :/
[14:25] <cjwatson> isn't there a fuse-squashfs thing?
[14:25] <cjwatson> I guess antimony might not have fuse
[14:25] <ogra> it has
[14:25] <ogra> but i'm not in the group
[14:25] <ogra> (i guess nobody is)
[14:25] <ogra> its loaded though
[14:25] <cjwatson> just sync it elsewhere then, you'll have to
[14:26] <ogra> well, then i can as well roll the image at home :(
[14:27] <cjwatson> time is short ...
[14:27] <ogra> yep
[14:27] <cjwatson> I can't think of any quick workarounds :(
[14:28] <ogra> me neither ... what i fear is that my laptop wont survive and my nslu2 install is at pkgsel after 4h already ...
[14:29] <ogra> but well, no risk, no fun
[14:29]  * ogra pulls filesystem.squashfs
[14:34] <istaz_> hey
[14:36] <istaz_> I have  noticed a reccuring bug since migrating from intrepid to jaunty
[14:36] <istaz_> python (2.6) can't seem to find certain packages
[14:36] <istaz_> I had the bug happend with python-msn and python-elisa
[14:36] <istaz_> reconfiguring the packages with dpkg-reconfigure fixed the problem in each case
[14:37] <cjwatson> they probably need to be rebuilt against 2.6
[14:38] <istaz_> yes probably
[14:38] <istaz_> when imported in python2.5 they work fines I forgot to mention
[14:39] <cjwatson> bug 348752 for pymsn, but you should file a bug on elisa for the other one
[14:39] <cjwatson> just saying "needs to be rebuilt for 2.6" would be quite sufficient I imagine
[14:40] <istaz_> cjwatson: yes I was the one who reported  that bug
[14:40] <istaz_> cjwatson: oh you meant the package itself need rebuilding
[14:41] <cjwatson> istaz_: yes
[14:42] <cjwatson> istaz_: routine for new python versions
[14:42] <istaz_> ok I will do that
[14:42] <istaz_> thanks for you informations
[14:43] <cjwatson> istaz_: I'm not sure you can, you don't have upload privileges
[14:43] <cjwatson> oh, unless you mean "will file a bug on elisa"
[14:43] <istaz_> cjwatson: yes I mean that
[14:44] <BUGabundo> hi
[14:44] <BUGabundo> good afternoon everyone
[14:44] <BUGabundo> anyone here covering wubi?
[14:45] <BUGabundo> something I noticed recently: if a machine requires no acpi to work, wubi will install and then fail to boot
[14:45] <BUGabundo> messing both OSs some times and leaving new and no so experienced users (the target of wubi)
[14:46] <BUGabundo> with no way out!
[14:46] <cjwatson> I don't believe that any of the wubi experts are here. File a bug?
[14:46] <BUGabundo> cjwatson: seems ill have
[14:46] <BUGabundo> but this was more of discussion then bug
[14:46] <BUGabundo> the bug it self is hw support
[14:46] <BUGabundo> but I wanted to know if wubi would do some preliminary testing before install
[14:46] <BUGabundo> to check for this prb
[14:47] <cjwatson> xivulon only has very patchy IRC access. You should find other non-IRC ways to have a discussion about it.
[14:47] <tkamppeter> pitti, I want to ask you something about Apport. See bug 348316. There are three lines of the error_log in the initial posting from Apport, but the complete error_log is not attached. I think it would be nmice to have the complete error_log.
[14:47] <BUGabundo> will do cjwatson
[14:47] <BUGabundo> will email installer ML then
[14:50] <istaz_> hum apparently for elisa I still had the ppa version of intrepid. Changelogs for the official packet in jaunty claim to have fixed the packet. bug 337438
[14:52] <ebroder> Anyone from motu-sru around? We've got a bug in Hardy proper that's causing a regression in a backport: bug #348865
[14:52] <ebroder> (bug 348865?)
[14:52] <ebroder> Oh, never mind
[14:52] <cjwatson> istaz_: yes, so it has. I was looking at the wrong version myself by mistake
[15:01] <liw> mvo, what's DelCount in MyCache in update-manager? (https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/144773)
[15:14] <ogra> cjwatson, just fyi whilöe i see it, there is a "/etc/.pwd.lock" file in the squashfs ... i dont think that belongs there
[15:16] <mvo> liw: the amount of package that are marked for removal
[15:17] <liw> mvo, hmm... testing that with assert seems sub-optimal (that and BrokenCount); is this tested earlier so that the UI can say something useful?
[15:18] <mvo> liw: agreed, let me check the code
[15:19] <cjwatson> ogra: I suspect it's harmless since I have that on my installed system too
[15:19] <ogra> indeed
[15:20] <cjwatson> my guess at the source would be lckpwdf()
[15:20] <ogra> ah
[15:21] <BUGabundo> question: is spark still supported and actively developed? some one asked on #identica
[15:24] <ScottK> It's a community supported architecture.  No official Canonical support.  For Jaunty the port seems (from the outside) to be in reasonably good shape.
[15:26] <BUGabundo> thanks ScottK
[15:33] <liw> mvo, I need to go now, but I'll read any comments you add to the bug about this, or message me privately, but in the meanwhile I closed #115131 :)
[15:38] <ogra> cjwatson, test install running with changes syslog.conf and the two-liner in ubiquity
[15:38] <ogra> *changed
[15:39] <cjwatson> ok
[15:39] <ogra> i'll rsync it up to my dir on antimony alongside
[15:40] <philsf> has the beta been released yet?
[15:40] <ogra> sent 99 bytes  received 20 bytes  79.33 bytes/sec
[15:40] <cjwatson> no
[15:40] <ogra> total size is 584148992  speedup is 4908815.06
[15:40] <pitti> seb128: retracers operational again, including sourceful stack trace FYI
[15:40] <cjwatson> philsf: subscribe to ubuntu-announce@ to be notified
[15:40] <ogra> wow, that was fast :)
[15:41] <Ghennadi_> :-)
[15:41] <seb128> pitti: waouh!
[15:41] <cjwatson> ogra: that looks suspiciously like a null rsync ...
[15:41] <philsf> k thanks
[15:41] <ogra> cjwatson, two lines in ubiquity and three lines in syslog.conf
[15:41]  * ogra checks md5sum
[15:41] <cjwatson> oh, well, md5sum it to be sure but don't complain I suppose :)
[15:42] <ogra> hmm, you are ringt
[15:42] <ogra> *right
[15:43] <cjwatson> bigon: your pymsn upload should be versioned 0.3.3-0ubuntu3, not 0.3.3-0ubuntu2build1. buildN is useless for packages that already have an "ubuntu" substring in their version
[15:48] <ogra> hmm
[15:48]  * ogra wonders why it doesnt work
[15:50] <ogra> ah, touching the file helps ... silly rsync
[16:21] <kany> hi hi
[16:21] <kany> need help badly
[16:22] <kany> :( if anyone is here that could pm me and walk me through the steps of connecting to the internet through kubuntu i would be very pleased. i kno wi sound lazy i have tryed everything and cant connect. So if there is anyone here who has time i would really appreciate the help
[16:22] <kany> I have a talktalk cd and i think i also have the key /
[16:23] <DktrKranz> kany: this is not the right channel to ask, #ubuntu is a better place :)
[16:23] <kany> :( if anyone is here that could pm me and walk me through the steps of connecting to the internet through kubuntu i would be very pleased. i kno wi sound lazy i have tryed everything and cant connect. So if there is anyone here who has time i would really appreciate the help
[16:23] <kany> oh ok
[16:23] <sistpoty|work> mvo: regarding faumachine and fault injecting for blocks on a cdrom: this might take a bit longer than expected, the cdrom controller code is pretty ugly and needs a major face lift :(
[16:24] <kany> cant join #ubuntu im on a proxy
[16:24] <kany> ffs im screwed :( lol
[16:25] <kany> :X
[16:32] <mvo> sistpoty|work: thanks for looking into that! no problem, I will just burn a regular one and use a sharp instrument to simulate a faul I guess :)
[16:33] <sistpoty|work> mvo: ok :)
[16:34] <calc> slangasek: ping
[16:35] <ogra> calc, dont wanke him up !
[16:36] <ogra> *wake
[16:36] <calc> ogra: oh he went to bed late?
[16:37] <ogra> 7h ago and he will release if he gets up ...
[16:37] <calc> ah lol
[16:57] <ogra> cjwatson, ok, i'm at the restart message of ubiquity, publishing the current image from my home is fine
[17:04] <cjwatson> ogra: thanks, done (20090326.1-armel+imx51). could you please put the patches you applied in that directory as well?
[17:05] <ogra> ugh
[17:05] <ogra> xant i just link to the fix in the bzr branch for ubiquity ?
[17:05] <ogra> *cant
[17:05] <ogra> (i agree on syslog.conf)
[17:05] <cjwatson> ogra: that's OK too if you're specific (i.e. link to the diff rather than the branch)
[17:05] <ogra> good
[17:06] <ogra> god, that netsplitting starts to get on my nerves
[17:06] <cjwatson> ogra: although that might go away if the branch is deleted ... but perhaps persia can promise not to do that :)
[17:06] <ogra> ah, well, i'll put the two diffs in to prevent probs
[17:12] <ogra> cjwatson, ok, both copied
[17:13]  * ogra twiddles thumbs ... nslu2 install at 69% of pkgsel after 6h ...
[17:18] <jcastro> slangasek: assuming you're the one writing it, I think it would be useful to point users to the appport-best practices mdz pointed out in the release announcement, what do you think?
[17:20] <cjwatson> ogra: can you give me a brief description of what the syslog.conf patch is for?
[17:21] <ogra> cjwatson, "suppressing all kernel messages that are not debug state in logfiles"
[17:22] <cjwatson> ta
[17:22] <mdz> jcastro: it's already in the release announcement, see https://wiki.ubuntu.com/JauntyJackalope/BetaAnnouncement
[17:22] <cjwatson> ogra: "non-debug kernel messages" then?
[17:23] <ogra> yeah
[17:23] <ogra> better
[17:23] <jcastro> mdz: ah, thanks!
[17:24] <cjwatson> ogra: ok, HTML syncing out
[17:25] <mdz> ogra: can you give me a link to the installation instructions for babbage?
[17:26] <ogra> mdz, http://cdimage.ubuntu.com/custom/20090326.1-armel+imx51/ its linked from the download page ... direct link is https://wiki.ubuntu.com/BabbageJauntyBetaInstall
[17:26] <ogra> i'm not 100% finished yet
[17:27] <ogra> (though the notes are tested, but the phrasing could need some love)
[17:27] <mdz> ogra: thanks
[17:34] <cjwatson> I like the recent change in LP to show bug summary changes in the log
[17:34] <cjwatson> https://bugs.edge.launchpad.net/ubuntu/+source/pkgsel/+bug/348393
[17:35] <sbeattie> hrm, should linux-firmware really be in main and not restricted?
[17:36] <ion_> It’s not exactly software, but more like a part of your hardware.
[17:36] <cjwatson> IIRC that was intentional; the Ubuntu licensing policy explicitly says that we will consider firmware on a case-by-case basis
[17:36] <sbeattie> cjwatson: it gets included in a free-software only install, which IMO is a bug.
[17:37] <ion_> sbeattie: Does the free-software-only install demand open-source hardware?
[17:37] <cjwatson> sbeattie: that's a matter of opinion, I think.
[17:37] <ion_> sbeattie: Your BIOS and processor microcode are already likely to be non-free, for instance.
[17:38] <cjwatson> sbeattie: the free-software-only install is defined as main(/universe) only
[17:38] <cjwatson> sbeattie: so I think if it meets *our* definition of main, that's where it should stand
[17:38] <cjwatson> besides IIRC there was a practical upgrade problem with putting linux-firmware in restricted, although I'd have to go and check the logs
[17:38] <cjwatson> dinnertime, anyway
[17:39] <sbeattie> cjwatson: okay, thanks.
[17:41] <sbeattie> ion_: I personally do not care, as I'm not dogmatic about using free software only; but I find it somewhat dubious to ask for only free software to be installed and then get handed a pile of binary firmware blobs.
[17:50] <allquixotic> Anyone know how to stop Firefox from trying to open *all* files in OpenOffice.org? :( Extension is irrelevant; if it's a file and I download it, it tries to open it (or even the containing folder!) in OpenOffice. Nautilus' mime types are fine, and in the Applications tab of FF, I don't see anything borked there either
[17:55] <calc> allquixotic: for me it does nearly the opposite, won't open documents even if they are OOo type, heh
[17:55] <ogra> cjwatson, oh silly me ... the babbage ubiquity apt error is cuased by the fact that mcopy doesnt copy the subdirs in dist/ from the iso into my image ...
[17:55] <calc> allquixotic: i think it has to do with the /usr/lib/mimetype stuff
[18:07] <LaserJock> Keybuk: nice blog post, gave me some food for thought
[18:09] <Keybuk> LaserJock: :-) that's the intent
[18:09]  * Keybuk likes to stir up pleasant debate
[18:10] <LaserJock> I'm just a hobbyist programmer, so everybody told me to do everything in Python
[18:10] <LaserJock> but after having to rewrite some data analysis code for my PhD in C I can definitely see your point
[18:13] <ogra> LaserJock, haha ... hobbyist
[18:13] <slangasek> calc: contentless pong
[18:13] <ogra> LaserJock, nobody belives you
[18:13] <calc> slangasek: oh yea sorry about that, i updated the bug report, let me find the number
[18:13] <calc> slangasek: bug 299161
[18:14] <LaserJock> ogra: I don't stand up to the likes of you anyway :-)
[18:14] <calc> slangasek: not sure who i should subscribe it to
[18:14] <calc> slangasek: i haven't uploaded it yet obviously but it is ready on my hd
[18:14] <ogra> LaserJock, come on, you're doing edubuntu just fine
[18:15] <slangasek> jcastro: I think the best practices need to be referenced from the website we already point users to for bug reporting, instead of adding more links to the release announcement
[18:15] <LaserJock> ogra: well, distro development is != app develoment exactly :-)
[18:16] <ogra> often very close though
[18:16] <slangasek> ah, apparently this has been addressed by changing which link we point to ;)
[18:17] <calc> apparently this new memtest even supports the intel chips coming out later this year (yipee) :)
[18:41] <calc> slangasek: is there anything else i need to do wrt bug 299161?
[18:42] <slangasek> calc: can't say, no time to look at it today
[18:42] <calc> slangasek: ok no problem
[19:07] <calc> wow git has a progress meter, thats nice esp on this 100MB repo
[19:14] <slytherin> can any of the archive admins please clear jack-audio-connection-kit from queue?
[19:18] <cjwatson> slangasek: ^- is jack-audio-connection-kit OK to accept? I would default to "no" since it's on the studio CDs
[19:18] <slangasek> cjwatson: let's call it a "no", there's no hurry on it it's just NBS cleanup
[19:18] <slangasek> (well, and out-of-date fixing)
[19:19] <cjwatson> that's what I thought, shame Onkar didn't bother to say why he wanted it ...
[19:40] <slytherin> any maintainer of fusa here? the logout confirmation dialog shows icon for shutdown, should I file a bug?
[19:41] <cjwatson> 19:18 <cjwatson> slangasek: ^- is jack-audio-connection-kit OK to accept? I would default to "no" since it's on the studio CDs
[19:41] <cjwatson> 19:18 <slangasek> cjwatson: let's call it a "no", there's no hurry on it it's just NBS cleanup
[19:41] <cjwatson> 19:18 <slangasek> (well, and out-of-date fixing)
[19:41] <cjwatson> slytherin: ^- re your request earlier
[19:42] <slytherin> cjwatson: I was asking from point of view of fixing gst-plugins-bad0.10 FTBFS on some arch. Anyway, I will wait.
[19:43] <slangasek> yes, that's the same reason I uploaded it - but it's covered by the beta freeze currently :)
[19:44] <slytherin> slangasek: fine.
[19:44] <slytherin> Can anyone advice me on this fusa issue?
[20:36] <jtisme> who is in charge of regression testing kde
[20:37] <ScottK> jtisme: Kubuntu development questions are better on #kubuntu-devel.
[20:38] <jtisme> I agree but do we (ubuntu community) perform any type of regression tests on kde before deploying?
[20:39] <ScottK> Yes.
[20:40] <ScottK> In the Kubuntu context though.
[20:40] <ScottK> So the people most likely to answer any questions you have are less likely to be on this channel than #kubuntu-devel.
[20:41] <jtisme> Ok, sorry I mis read you original post saw it as Kde devel will go there thanks
[20:41] <jtisme> will go to #kubuntu-devel that is
[21:58] <ebroder> Anybody around who could look at bug 348865?
[22:13] <Aquina> Is it ok to advertise other distros often in launchpad /Ubuntu?
[22:20] <directhex> hm, have i just found a bug in scp?
[22:20] <ScottK> Aquina: What do you mean?
[22:21] <Aquina> Exactly (literaly) what I told you. There is a person advertising a dirsto named "Volvix" (I think) at times.
[22:22] <Aquina> (https://launchpad.net/~tomdavies04)
[22:22] <ScottK> I'm pretty sure there's no rule against that.
[22:24] <ianm_> is it known if/when Wacom tablets will work fully (eg. the eraser side and the extra buttons on the tablet itself) ?
[22:31] <Aquina> ok
[22:32] <cjwatson> directhex: yes
[22:33] <directhex> cjwatson, like i said in #ubuntu-motu, i'm boring and unoriginal in my bug discovery. boo!
[22:34] <cjwatson> directhex: my observation was purely statistical
[22:36] <slangasek> haha
[22:51] <Hobbsee> maxb: :)
[22:55] <ebroder> Is there a way to search for the list of packages that build-dep on a package? It doesn't seem like aptitude search is able to do it...
[22:56] <TheMuso> ebroder: grep-dctrl I think it is can do that.
[22:56] <Hobbsee> yes, but it involves grep-dctrl
[22:56] <ebroder> Ah, ok, sure
[22:56] <Hobbsee> grep-dctrl -F Build-Depends libsoprano-dev -s Package -n /var/lib/apt/lists/*_Sources for searching for packages which have a build-depend on libsoprano-dev
[22:56] <Hobbsee> ebroder: my notes say ^.  Modiy as appropriate
[22:57] <ebroder> Yep. That's exactly what I'm looking for. Much thanks
[22:57] <Hobbsee> that should probably go into a script for ubuntu-dev-tools, too
[22:58] <TheMuso> Hobbsee: I'd agree with that. Make it check all the sources list files etc.
[22:58] <cjwatson> seems a bit overkill, I think there should just be a grep-sources symlink in dctrl-tools that operates on /var/lib/apt/lists/*_Sources
[22:58] <cjwatson> anything more than that will be too specific
[22:58] <cjwatson> (note the existence of grep-available, grep-aptavail, grep-status)
[23:33] <[reed]> is jaunty beta still today?
[23:34] <slangasek> yes
[23:34] <slangasek> coming soon to a mirror near you
[23:35] <TheMuso> heh
[23:35] <TheMuso> That always sounds so "promo/marketing"
[23:35] <TheMuso> to me at lesat.