[00:44] <bananapie> I did a git checkout of the kernel sources for wily. Is it possible to recompile a single driver ( gpu/radeon ) without recompiling everything? I want to do testing on the driver based on comments from freedesktop.org, and I don't want to spend hours compiling the kernel.
[20:38] <hallyn> apw: anyone on the team well-versed in the cgroup code?
[22:11] <apw> hallyn, well versed prolly not, but ask and we cna think on it ...


[16:42] <arraybolt3> tsimonq2: brace for impact, sandbox server reboot imminent
[16:43] <arraybolt3> will probably reboot at 11:00 AM unless that's a problem


[13:32] <shadeslayer> coolbhavi: ok so the patch was done, but i cant seem to be able to use it in my package :(
[13:32] <shadeslayer> i have this rules file http://paste.ubuntu.com/505094/
[13:37] <shadeslayer> anyone else have a ideaa?
[14:36] <persia> shadeslayer, I can't find enough context to understand what to suggest.  If you're still about, could you provide some?
[14:50] <shadeslayer> persia: ive added a patch to a 1.0 format package, with that rules file
[14:50] <shadeslayer> but i dont see the patch being applied :(
[15:05] <persia> shadeslayer, How did you add the patch?
[15:05] <shadeslayer> persia: by following quilt section of packaging guide
[15:06] <shadeslayer> https://wiki.ubuntu.com/PackagingGuide/Complete#quilt (Example Package: xterm)
[15:06] <shadeslayer> ive never worked with patches + 1.0 source format :(
[15:07] <persia> quilt new, quilt add, quilt refresh, quilt pop ?
[15:08] <shadeslayer> yes
[15:09] <persia> OK, so that would be right.
[15:09] <persia> Now, how isn't it working?
[15:10] <shadeslayer> its not applying the patch during debuild -S -sa
[15:10] <shadeslayer> or debuild even...
[15:10] <shadeslayer> thats the part im having trouble figuring out
[15:10] <persia> That's fine.  Format 1.0 packages don't apply patches at source build time.
[15:11] <shadeslayer> uh.. alright, but i can still reproduce my issue that the patch is supposed to fix
[15:11] <shadeslayer> persia: also... quilt uses -p1 right?
[15:12] <persia> quilt doesn't set a -p level as such, it's more complicated than that.
[15:13] <shadeslayer> hmm.. well.. what to do
[15:13] <shadeslayer> persia: heres the patch http://paste.ubuntu.com/505135/
[15:13] <shadeslayer> package is choqok
[15:14] <persia> OK.  What happens if you call `debian/rules patch` in the source directory?
[15:15] <shadeslayer> it seems to have patched the file
[15:16] <shadeslayer> patching file microblogs/twitter/twittereditaccount.cpp
[15:16] <persia> and `debian/rules unpatch` ?
[15:16] <shadeslayer> Removing patch kubuntu_01_consumerkey.diff
[15:17] <persia> Well, that's expected output.
[15:17] <persia> So, if you do a binary build, do you see similar entries in your build log?
[15:17] <shadeslayer> yeah, but when i install the deb file i created with debuild, it doesnt use the consumer key i specified
[15:19] <shadeslayer> maybe my patch is wrong.. who knows... ill talk with upstream
[15:19] <persia> Aha!  So I think you want  /usr/share/cdbs/1/rules/patchsys-quilt.mk instead of /usr/share/quilt/quilt.make (based on /usr/share/doc/quilt/README.Debian
[15:19] <shadeslayer> ok lets see
[15:26] <lucidfox> http://volatile-minds.blogspot.com/2010/10/re-elect-jesus-christ-vote-for-rick.html
[15:26] <lucidfox> o_O
[15:26] <lucidfox> What is this doing on Planet Ubuntu?
[15:28] <persia> lucidfox, Are you complaining about the content or the poster?
[15:32] <shadeslayer> persia: thanks, works now :D
[15:34] <lucidfox> persia> Content
[15:35] <persia> lucidfox, The common way to deal with that has been to firstly contact the poster, and ask for them not to post that, or if they must, please send only some tags to Planet Ubuntu.  If this is not received well, inform the Community Council that you find the content objectionable for some reason, and there will be discussion.
[15:35] <persia> I think there's only ever been one case where it needed the second: most folk seem to post mostly related stuff *or* filter what hits planet.
[15:36] <persia> (and the case in question was, potentially, on-topic, in some ways)
[19:05] <juanito28> hola alguien habla español
[19:06] <crimsun> juanito28: por lo general inglés, por favor
[19:07] <juanito28> no speak ingles
[19:19] <zooko> I'm working on this wiki page: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/OSPackages
[19:20] <zooko> I seem to remember that ubuntu always had working https, but at the moment it appears not.
[19:20] <zooko> Oh well, back to http.
[20:44] <Mjiig> hi everyone, i'm not a motu (or good enough to be one :)) but i wanted to ask if anyone had any recommendations for projects i could do/help on as i learn C?
[21:25] <geser> tumbleweed: I saw your commit to u-d-t (r767): have you checked that checkUpload returns True/False? see my comment regarding it in lpapicache.py: "checkUpload() throws an exception if the person can't upload"
[21:26] <tumbleweed> geser: it returned True/False in my tests, but then so did isSourceUploadAllowed (I thought)
[21:26] <tumbleweed> oh, I didn't test for false False with checkUpload, good catch


[00:00] <tarpman> teward: not being snarky - being specific so you know where to look for more details :)
[00:00] <tarpman> teward: but now I'm curious, how do you have rsync but not the manpage?
[00:00] <teward> tarpman: question asked by coworker over texts
[00:00] <teward> IRCing from my iPhone :p
[00:00] <tarpman> fair!
[00:19] <Xin> yo homies
[00:19] <Xin> any rsync peeps in here
[00:19] <Xin> I need to set up a bi-directional file sync
[00:20] <Xin> well, actually between 3 nodes
[00:20] <Xin> so 2 links per node
[00:20] <Xin> basically so all my servers self-replicate changes, wherever they're made
[00:21] <Xin> overwriting files with newer modified times, adding new files, deleting explicitly deleted files
[00:21] <Xin> or is there something better than rsync for that?
[00:22] <Xin> like some kind of replicating filesystem or somesuch
[00:37] <Hawky__> I found a dead link on the http://conjure-up.io homepage. It's been there for weeks. I emailed<EMAIL_ADDRESS>and<EMAIL_ADDRESS>but it's still busted
[00:38] <Hawky__> the link is: The latest CONJURE-UP news - More CONJURE-UP news from Ubuntu Insights
[00:39] <Hawky__> thought I might as well report it here incase any of the web admins for conjure-up.io are listening :)
[00:40] <Xin> a broken link? ON A WEB PAGE?!
[00:40] <Xin> CALL THE PRESIDENT WE NEED TO GET HIM ACROSS THIS ISSUE NOW
[00:40] <therealtbe> report it to w3c immediately
[00:40] <Hawky__> lol
[00:40] <therealtbe> thunderbirds r go
[00:40] <Hawky__> Slap bang in the middle of the homepage no less!
[00:42] <therealtbe> ubuntu server 14.04 installing from usb key;  it says it cannot mount CD-ROM.  there is no cdrom.  it's running from usb key duh
[00:43] <Hawky__> lol
[00:43] <therealtbe> why does it try to mount cd-rom when there is no cd-rom
[00:51] <therealtbe> hello?
[01:19] <teward> ikonia: jrwren: thanks to you both on the dovecot assists the past week or so - thanks to your assistance, and the Ubuntu community at large, and Google, my migration task of 9.10 -> 14.04 is DONE ^.^
[01:19]  * teward can now work on the fifty other projects he has
[01:29] <Xinny> hey peeps is there a way I can dump a file of packages loaded in apt-get so I can pipe it into apt-get on another system to do an approximately same/same setup?
[01:29] <Xinny> php -i
[01:29] <Xinny> ...
[01:29] <Xinny> lol soz
[01:35] <teward> Xinny: dpkg --get-selections
[01:35] <teward> if you want to store it so you can move the file over: dpkg --get-selections > packages.txt
[01:35] <teward> then move packages.txt
[01:36] <teward> that's one way anyways
[01:37] <Xinny> thx teward - someone in #ubuntu suggested apt-clone too
[01:37] <Xinny> both look perfect
[01:37] <teward> Xinny: the one I just stated doesn't save auto or manual installed data though
[01:37] <teward> not sure about apt-clone
[01:37] <teward> also, for the future...
[01:37] <teward> !crosspost | Xinny
[01:37] <teward> pick one, wait there
[01:37] <Xinny> fair enough haha :)
[01:37] <teward> if you don't get a reply in an hour consider a crossposte
[01:37] <teward> crosspost*
[01:37] <Xinny> lool who's got an hour to sit on their hands
[01:38] <Xinny> for that kind of time id use forums
[01:38] <Xinny> xD
[01:38] <teward> :P
[02:14] <Xinny> hey why does ubuntu server not include 'mail'
[02:14] <Xinny> where do I get that
[03:11] <jrwren> congrats teward
[03:28] <dirty> need some help guys; I have a new supermicro server with 10 drive bays filled with 512GB SSDs, I have two SATA controllers, one is sSATA and the other SATA
[03:28] <dirty> four of the drives are on the sSATA controller, the other six on the SATA controller, in the installer for ubuntu server, under the partitioner for guided LVM, I get raid10 device #126 973.0 GB - Software RAID device
[03:29] <patdk-lap> so, what exactly is this so called sSata thing?
[03:29] <patdk-lap> hopefully they are ahci controllers though
[03:29] <dirty> patdk-lap: it's the second bios controller applicable to four of my 10 drives
[03:30] <dirty> they are ahci
[03:30] <dirty> the other six are on a "SATA Controller"
[03:30] <patdk-lap> yes, but you are not naming the controllers
[03:30] <dirty> s/bios controller/bios sata controller/
[03:30] <patdk-lap> well, everything has a bios, and the bios is unrelated to anything else in the system
[03:30] <dirty> patdk-lap: right, that's the nomenclature under the aptio BIOS within the supermicro mobo
[03:31] <patdk-lap> yes, so what is it?
[03:31] <patdk-lap> or maybe, what is it you are attempting to do?
[03:31] <patdk-lap> instead of talking about all this non-meaningful infomation
[03:32] <dirty> uhm, how else do I make this clear... I have 10 drive bays, four are controller by a "sSATA controller" under the aptio bios, the other six are under the "SATA Controller", all are set to AHCI, not RAID, and not IDE
[03:32] <patdk-lap> they have names and model numbers :)
[03:32] <dirty> patdk-lap: be tact, or don't attempt to help please?
[03:32] <dirty> I need help, not chiding
[03:34] <patdk-lap> actually, you need help locating *any* infomation first
[03:34] <dirty> the problem is with the drive configuration recognition for the Guided - use entire disk and set up LVM
[03:34] <patdk-lap> like the model of your supermicro motherboard, the model number of the chipsets used
[03:34] <patdk-lap> and the all overal best part, the actual question or problem you have
[03:34] <patdk-lap> the overall description above doesn't even matter yet
[03:34] <dirty> wow
[03:34] <Xinny> whats the package I need to add for ssh?
[03:34] <patdk-lap> cause no one knows what it is in relation to
[03:34] <patdk-lap> Xinny, openssh-server or openssh-client
[03:35] <Xinny> ty, and what about for vpn
[03:35] <Xinny> openvpn-server?
[03:35] <Xinny> xD
[03:35] <patdk-lap> vpn?
[03:35] <patdk-lap> well, if you mean openvpn, openvpn
[03:36] <Xinny> virtual private network
[03:36] <Xinny> haha ok ty
[03:36] <patdk-lap> yes, that is a generic concept :)
[03:36] <patdk-lap> could mean, openvpn, ipsec, pptp, ...
[03:36] <Xinny> Sure, its an open question. I dont have any specific security model in mind.
[03:36] <Xinny> It just needs to be a tunneling protocol of some variety I can use on both windows and linux
[03:37] <patdk-lap> openvpn for more simple, or strongswan if you want to have real fun :)
[03:37] <Xinny> openvpn will probably do just fine
[03:38] <dirty> patdk-lap: I'm setting up LVM across 10 drives, six of which are being recognized as SCSI[1-10], of which 5-8 are being globbed as RAID10 device #126 - 973.0 GB Software RAID Device, this is a SuperMicro SuperServer 1018R-WC0R
[03:38] <dirty> does that help?
[03:38] <patdk-lap> so the question is?
[03:39] <dirty> I need the RAID10* device "unwrapped" as individual block devices to manage
[03:39] <patdk-lap> you don't want that raid10 thing?
[03:39] <dirty> patdk-lap: yeah
[03:39] <patdk-lap> ah, just go into your bios and tell it to use ahci, and not raid
[03:39] <dirty> patdk-lap: did that, they're already labelled AHCI buddy
[03:39] <patdk-lap> any more specific, I still need your model info
[03:39] <patdk-lap> and time to actually real your motherboard manual
[03:40] <patdk-lap> if it was, it wouldn't show as raid
[03:41] <dirty> patdk-lap: calling my bluff then?not trying to start any ego crap, but seriously, I did my diligence and triple sanity checked
[03:41] <dirty> it's AHCI on both controllers
[03:41] <dirty> not RAID or IDE
[03:41] <patdk-lap> yes, and my instructions are generic
[03:41] <patdk-lap> since I still don't know what you have
[03:42] <dirty> what else do you need? starting to crack me up here, I swear I'm being as clear as I can
[03:42] <patdk-lap> http://superuser.com/questions/384536/how-do-you-disable-bios-raid-on-supermicro-x9scl-x9scm-motherboard
[03:42] <patdk-lap> you still have not posted any model infomation at all
[03:42] <patdk-lap> I asked several times for the model of your motherboard, and sata controllers
[03:43] <patdk-lap> ah, once the raid infomation is set, looks like your screwed
[03:43] <patdk-lap> have to wipe it manually
[03:44] <dirty> patdk-lap: I never set it to RAID, and for good measure I wiped the drives manually using dd if=/dev/zero of=/dev/sd? bs=512 count=4
[03:44] <dirty> from the rescue shell
[03:44] <patdk-lap> that hardly even clears the mbr
[03:45] <patdk-lap> it won't touch a gpt partition
[03:45] <patdk-lap> or raid config
[03:45] <patdk-lap> try, dmraid -r /dev/sd?
[03:45] <dirty> patdk-lap: here's the mobo http://www.supermicro.com/products/motherboard/Xeon/C600/X10SRW-F.cfm
[03:45] <patdk-lap> if you really want to use dd
[03:46] <patdk-lap> atleast use bs=1M count=10
[03:46] <patdk-lap> that will work if it's at the start
[03:46] <patdk-lap> can't remember if it is at the end or not
[03:46] <dirty> patdk-lap: alright, excuse my reactions, thanks for attempting to help, I'll attempt your suggestion and be right back here, carry on if you have more info I'm trying.
[03:47] <patdk-lap> -r E /dev/sd? likely
[03:48] <RoyK> dmraid?
[03:48] <RoyK> !dmraid
[03:49] <dirty> RoyK: trying to say don't use dmraid there?
[03:49] <RoyK> something like that
[03:49] <dirty> patdk-lap: alright I'll dd larger to bs=1M
[03:49] <patdk-lap> maybe mdadm :)
[03:49] <dirty> with a count of 10
[03:50] <dirty> what would be the mdadm command suggestion to be sure if there's any RAID shit set, that it's unset
[03:50] <patdk-lap> no difference
[03:50] <patdk-lap> dmraid can handle more than mdadm
[03:50] <RoyK> dirty: I didn't follow - what sort of raid are you building?
[03:50] <dirty> so mdadm -r /dev/sd?
[03:50] <patdk-lap> I think mdadm can only do two of those types
[03:50] <patdk-lap> dmraid can do more
[03:50] <patdk-lap> royk, he is attempting to destroy it
[03:51] <patdk-lap> it was built automatically
[03:51] <RoyK> ah - dd is the guy, then
[03:51] <dirty> right
[03:51] <dirty> we'll see how it goes
[03:51] <dirty> I'm almost to the rescue shell
[03:51] <patdk-lap> the intel raid header is a complex mess though
[03:51] <dirty> this installer is a bit drawn out
[03:51] <dirty> patdk-lap: seems that way
[03:52] <patdk-lap> it's kindof like audio wave files
[03:52] <Xinny> how do I enable root for openssh
[03:52] <patdk-lap> very flexable and nice, but kindof hell to deal with
[03:52] <Xinny> actually nm ill google it
[03:52] <RoyK> patdk-lap: some audio porn to help the raid up?
[03:52] <patdk-lap> you want a moaning track?
[03:52] <dirty> bout time, got to my shell
[03:52] <dirty> attempting the dd @ 1M
[03:55] <dirty> hmm interesting, the target block devices seem to be giving me output on the dmraid -r /dev/sd?
[03:56] <dirty> patdk-lap: I'll run through the installer again and see where I get this time, thanks for trying to help me ;)
[03:57] <dirty> also applied the dd @ 1M bs at 10 counts
[03:57]  * dirty fingers crossed
[04:00] <RoyK> some raid systems store metadata at the end of the disk
[04:01] <Magnetz741> When I get "Server accepts key:" in ssh -v, while my attempts at authenticating give "Permission Denied (publickey)" does that mean it won't accept my AuthorizedKeysFile?
[04:02] <RoyK> Magnetz741: try chmod 0600 $HOME/.ssh/authorized_keys
[04:02] <Magnetz741> It asks for the passphrase on the key, even though there isn't one. If I set PasswordAuthentication yes, it asks for both keys and doesn't fail to connect
[04:03] <Magnetz741> RoyK: Alright, I had it at chmod 700
[04:03] <dirty> ahhh yay, well now the installer is showing something a bit different fellas, so instead of the "RAID10 device #126 - 973.0 GB Software" now I'm getting "RAIDmd126 device #:RAIDactive device #(auto-read-only)RAIDraid10 device....
[04:03] <dirty> RoyK and patdk-lap any other suggestions?
[04:03] <RoyK> Magnetz741: no need for +x for a config file
[04:03] <patdk-lap> you need to reboot likely
[04:03]  * RoyK has no idea
[04:03] <patdk-lap> it's cause you just dd'd it
[04:04] <patdk-lap> but it didn't remove what it had already knew about
[04:04] <dirty> patdk-lap: well I also peformed the dmraid -r /dev/sd?
[04:04] <dirty> so, next step please? this almost feels like progress
[04:04] <patdk-lap> ya, but that is the same as dd really
[04:04] <patdk-lap> it doesn't remove it from the system
[04:05] <dirty> well ff, I'm open to suggestions... again, the controllers in the BIOS are both AHCI...
[04:05] <dirty> so... I'm open for suggestion
[04:06] <dirty> need to get this damn server rolling for prod soon, this is a drawn out "fun" hangup I didn't expect
[04:07] <Magnetz741> RoyK: Weird, .ssh seems to be owned by root, in /home/user/.ssh/, I still get Permission Denied (Publickey)
[04:07] <dirty> s/th AH/th set to AH/
[04:09] <dirty> patdk-lap: "10x SATA3 (6Gbps) via C612" on that mobo... so I guess the controller is a C612?
[04:10] <patdk-lap> but that only does 8 I believe
[04:10] <RoyK> Magnetz741: it must be owned by the user
[04:10] <dirty> patdk-lap: well the way it appears in the BIOS is 4 and 6
[04:11] <dirty> the other would be... Intel SATA
[04:11] <dirty> that's f'in generic
[04:11] <patdk-lap> strange
[04:11] <dirty> I have four in question... the other six show up fine in the ubuntu server installer
[04:12] <dirty> that's why I kept bringing up the sSATA and SATA crap... my assumption is the C600 controller is handling the four and labeled "sSATA controller" in the aptio BIOS
[04:12] <dirty> yeah it's a bit bizarre to me
[04:13] <patdk-lap> ah
[04:13] <patdk-lap> it's the normal 6 via the intel ICH
[04:13] <patdk-lap> and 4 via the c612
[04:14] <dirty> right...
[04:14] <dirty> that aligns with my thought
[04:14] <patdk-lap> the manual on the board is horrible
[04:14] <dirty> ns
[04:14] <dirty> leave it to .tw
[04:15] <patdk-lap> hmm, dunno about the ssata thing
[04:15] <patdk-lap> have never used it before :(
[04:15] <dirty> the ssata thing is just how the C612 appears in the BIOS
[04:16] <dirty> it's very similar to the Intel SATA in terms of configuration
[04:16] <patdk-lap> ya, it's a funny chip, it actually doesn't do anything, pretty much just gpio pings
[04:16] <patdk-lap> and the driver has to emulate sata on it
[04:17] <dirty> patdk-lap: the intent here is to do software RAID 1 on two of the drives for the OS, and the other 8 RAID 10 if that means anything, but wiht this hangup holding four of my drives hostage, I'm in a bit of a ringer
[04:20] <Magnetz741> Royk: Well if I do chmod 600 on ~/.ssh I can't even read the permissions, even while I've chowned the file to the correct user, every guide says chmod 700 for .ssh and it hasn't given my issues with logging in while ~/.ssh is chmod 700 and PasswordAthentication yes is set in /etc/ssh/sshd_config, I get "Permission denied (publickey)" when I set PasswordAuthentication no, and it still asks for both the rsa key's passp
[04:20] <Magnetz741> RoyK*
[04:21] <Xinny> weird question, I want to rename something to the current unix timestamp ?
[04:21] <Xinny> dynamically
[04:21] <dirty> patdk-lap: when I attempted an FBSD install... it reconized all 10 of the block devices distinctively; but bhyve is too experimental for my goal, so I went to Ubuntu server in hopes that I could do LVM instead of ZFS and get KVM rolling
[04:22] <RoyK> Magnetz741: the dir should have 0700 - the files under it should have 0600
[04:22] <dirty> I don't know if that makes any difference to you, maybe it's a device driver issue with the current ubuntu-server stack?
[04:23] <patdk-lap> no
[04:23] <patdk-lap> did you do a reboot yet?
[04:23] <dirty> I had
[04:23] <dirty> I'll do it again right now for good measure
[04:26] <Magnetz741> RoyK: Yeah, that's how it's set now, still get Permission denied (publickey)
[04:27] <Magnetz741> RoyK: I also doublechecked the keys, they match
[04:27] <patdk-lap> and owned by the user of that folder?
[04:27] <patdk-lap> not root?
[04:27] <Magnetz741> patdk-lap: Yep
[04:27] <Magnetz741> patdk-lap: Host/Server is Ubuntu 14.04 LTS while the client is Arch
[04:28] <Magnetz741> Checking ssh versions
[04:29] <dirty> patdk-lap: same crap on reboot
[04:29] <dirty> should I do a longer dd, is there anything else you can think of to destroy this pseudo RAID array?
[04:30] <Xinny> is it possible to config my domains dns records so that it tries my dev server first, and if its offline, refer the request to a backup server?
[04:30] <Xinny> or do I have to reset my a record each time
[04:30] <patdk-lap> :(
[04:31] <patdk-lap> longer won't help likely
[04:31] <patdk-lap> but wiping the last 10megs of the disk, probably won't hurt
[04:37] <dirty> man, what a effin pita
[04:48] <Magnetz741> I'm trying to remember how the hell I had this set successfully before
[04:48] <Magnetz741> -_-
[04:51] <Magnetz741> ssh is backwards compatible right?
[04:52] <Magnetz741> So differing versions couldn't be the issue, client being Arch and later than the server which is Ubuntu 14.04?
[05:07] <RoyK> ssh is backwards compatible unless you use something like ssh v1, but that dates back 15 years
[05:23] <Magnetz741> RoyK: It was because I was trying to authenticate using the public key x'D
[05:26] <dirty> YESSSS!!!!!
[05:26] <dirty> thanks guys!
[05:27]  * RoyK likes a YESSS
[05:27] <Magnetz741> Now here's the real question, should I dist upgrade my webserver?
[05:27] <RoyK> Magnetz741: I always do that
[09:40] <syeekick> "error connecting to /tmp/tmux-1000/default (No such file or directory)
[09:40] <syeekick> " anyone had this error before, i've never had tmux fail on me


[00:28] <dtchen> apw: in trawling older bug reports, when you see mentions of four-digit Ubuntu bug numbers, they're bugzilla entries. I do not know if there's a read-only mapping available, though purportedly they were all migrated over to Launchpad.
[00:28] <dtchen> (patching sound/pci/intel8x0.c ATM)
[00:31] <bjf-afk> dtchen, I plan on requesting a pull of that prealloc-4mb-dmabuffer patch right after alpha1 (maybe tomorrow)
[00:32] <dtchen> bjf-afk: oh, good; I was just cloning ubuntu-lucid.git to do that
[00:32] <dtchen> bjf-afk: thanks!
[00:33] <bjf-afk> dtchen, in fact I may as well do it now
[00:33] <dtchen> all right
[00:48] <bjf-afk> dtchen, I just submitted the pull request, feel free to add your $.02 whenever it hits the mailing list :-)
[11:27] <Kano> hi, did you see <IP_ADDRESS>? it has now 3 webcam fixes too which you didnt like to accept as patch...
[14:25] <rtg> apw, was 'ext4: Fix insufficient checks in EXT4_IOC_MOVE_EXT' the result of surbhi's debug work?
[14:25] <apw> rtg that one came down from on high
[14:27] <mdz> rtg, the server team will need bug 495060 fixed to support their hardware test setup (USB ethernet); can you see that the trivial fix gets applied?
[14:27] <ubot3> Malone bug 495060 in linux "nic-usb-modules should include cdc_ether" [Undecided,New] https://launchpad.net/bugs/495060
[14:29] <rtg> mdz, just Lucid?
[14:29] <mdz> rtg, yes
[14:29] <mdz> no point in doing it anywhere else, since it would need new CDs anyway
[14:29] <apw> rtg i'll do that one
[14:29] <rtg> apw, ack
[14:39] <apw> smb, ok i've got the first stab at a config enforcer going
[14:39] <apw> how does this look as a syntax
[14:40] <apw> value CONFIG_DEBUG_RODATA y
[14:40] <apw> ( arch armel & value CONFIG_DEFAULT_MMAP_MIN_ADDR 32768 ) | \
[14:40] <apw>         ( value CONFIG_DEFAULT_MMAP_MIN_ADDR 65536)
[14:42] <smb> I looks like a reasonable starter
[14:42] <smb> Understandable at least to me
[14:43] <amitk> apw: this would be used when rebasing to newer kernels?
[14:43] <smb> would undefined be take as "value CONFIG_x n"?
[14:43] <apw> amitk, this is a build check
[14:43] <apw> checked at prepare-generic time
[14:43] <smb> amitk, No anytime you compile after fiddling around with options
[14:43] <apw> smb, yes
[14:43] <amitk> aaah, k
[14:44] <smb> actually anytime on  build, yes
[14:44] <smb> Its to make us remember why certain things are the way they are
[14:45] <amitk> will it be a free form text file with a parser then? Can it take comments?
[14:46] <smb> amitk, I would assume comments are not a problem. Though free from sounds a bit too... free
[14:47] <amitk> well, free form meants no restrictions wrt to white spacing, ordering, etc.
[14:48] <amitk> so I assume this is to sanity check that certain CONFIG option values don't change automatically
[14:49] <amitk> but these 'rules' can be in any order in the file
[14:49] <amitk> with comments and all
[14:49] <smb> That for one and stuff like USB_DEVICEFS remains off even with all the users lament because otherwise other stuff breaks (udev)
[14:50] <amitk> ok
[14:50] <smb> I would think, but I don't want to speak too much for apw (as he is coding it)
[14:51] <apw> amitk, yeah has commet syntax and line continuations
[14:51] <apw> +#
[14:51] <apw> +# SECURITY items
[14:51] <apw> +#
[14:51] <apw> +value CONFIG_CC_STACKPROTECTOR y
[14:51] <apw> +value CONFIG_COMPAT_BRK n
[14:51] <apw> +value CONFIG_COMPAT_VDSO n
[14:51] <apw> +value CONFIG_DEBUG_RODATA y
[14:51] <apw> +( arch armel & value CONFIG_DEFAULT_MMAP_MIN_ADDR 32768 ) | \
[14:51] <apw> +       ( value CONFIG_DEFAULT_MMAP_MIN_ADDR 65536)
[14:52] <researcher1> I did everything as suggested here https://help.ubuntu.com/community/RecoveringUbuntuAfterInstallingWindows  but still cant boot from hard disk.HELP please?
[14:52] <amitk> researcher1: you will have more success asking this on #ubuntu
[14:53] <researcher1> ok
[15:07] <apw> amitk, smb, i've also integrated the thing into updateconfigs so you get a slapping when you break it
[15:08] <rtg> apw, and this slapping will be sufficiently verbose that its painfully obvious what you've done wrong?
[15:08]  * smb is glad apw cannot cause physical harm by programs
[15:09] <rtg> apw, the ABI and module checks are a bit terse
[15:09] <apw> rtg yep its in your face about it
[15:10] <apw> it is also an early build failure, i've added 'prepare' checks which stop the build too
[15:10] <apw> check-config: /tmp/tmp.RiQ9ZiuYbW/armel-config.flavour.versatile-full: loading config
[15:10] <apw> check-config: /home/apw/git2/ubuntu-lucid/debian.master/config/enforce: loading checks
[15:10] <apw> check-config: FAIL: value CONFIG_SYN_COOKIES y
[15:10] <apw> check-config: 13/14 checks passed -- exit 1
[15:10] <apw> *** ERROR: 1 config-check failures detected
[15:10] <apw> that is the bottom of the updateconfigs output with this applied
[15:13] <smb> apw, does that mean the actual value is y and it fails because its supposed to be n or the other way round?
[15:13] <apw> it means the predicate 'value CONFIG_SYN_COOOKIES y' failed
[15:14] <apw> ie the value is not that value, but it could be more like
maybe it can use a bit more verbosity?</hint>
[15:14] <apw> (value A y | value A b | value B c)
[15:15] <apw> which is hard for the parset to tell you which bit failed, as they all did
[15:16] <amitk> apw: can't you just dump the comments for a predicate when it fails?
[15:16] <apw> we could consider that yes
[15:17] <apw> perhaps each needs a 'WHY' field
[15:17] <apw> generally they are not complex though and it should be obvious what the failure
[15:18] <smb> right or "FAIL: the following expression was not true"
[15:18]  * amitk nods, since in this case we are imposing policy on our configs
[15:18] <amitk> apw: sometimes the historical perspective is missing when team members change or get shuffled around.
[15:18] <apw> yep and the comments should be in the file for sure
[15:19] <apw> i am unsure if it makes much difference if they are visible at fail time
[15:19] <rtg> amitk, what, you're saying I don't remember _everything_ thats gone on in the last 3 years?
[15:19] <apw> as the only way to fix them is to edit the enforce file, which should have comments
[15:19] <apw> so we may need a policy to say that we should have damn good comments for each
[15:19]  * apw finds lots of issues in the ports configs
[15:23] <amitk> rtg: no no. Not you. Ofcourse you'd remember. I was talking about us old farts. :)
[15:23] <rtg> amitk, man, sometimes I can't remember what I had for breakfast
[15:24] <amitk> heh
[15:26] <apw> rtg whats breakfast?
[15:27] <smb> apw, Thats the first cup of tea you have in the morning
[15:27] <apw> ahhh ... life
[15:28] <smb> brain the size of a planet?
[15:29] <apw> cirtainly my diodes are shot
[15:29]  * apw applies heat to water
[16:05] <dandel> apw, bug 338701 has found the final cause of it, (see kernel bugzilla bug #14736  for details )
[16:05] <ubot3> Malone bug 338701 in linux "acpi_irq is not set properly." [Medium,In progress] https://launchpad.net/bugs/338701
[16:05] <ubot3> Malone bug 14736 in linux-source-2.6.15 "Sluggish performance unless ACPI is disabled" [Medium,Fix released] https://launchpad.net/bugs/14736
[16:09] <Kano> could somebody explain me way the v4l updates where not merged?
[16:10] <Kano> or basically <IP_ADDRESS> not at all
[16:12] <apw> Kano, cause it released yesterday and we had a pending security update and a pending proposed update, and there are over a hundred patches to review
[16:12] <Kano> well when will it be there
[16:13] <Kano> just in git, no package needed
[16:13] <apw> a few days depending on how mind mangling the patches are
[16:13] <smb> its done when its done
[16:51] <sconklin> apw: if I have several remotes in a git tree and have a commit SHA1, is there a way to get git to tell me which remote(s) it's in?
[16:51] <apw> you can ask which heads lead to it
[16:51] <sconklin> how?
[16:51] <apw> git describe --contains sha1
[16:52] <apw> i think --all gives you them all
[16:52] <sconklin> ohh, so easy and sensible
[16:52]  * sconklin needs to study everything that describe can do
[16:52] <rtg> sconklin needs to buy a book on git
[16:52] <sconklin> rtg: recommend one
[16:53] <rtg> of which there are 2
[16:53] <rtg> sconklin, Oreilley - Version control with git
[16:53] <sconklin> I think I can search within a set of 2
[16:54] <rtg> sconklin, Pragmatic version control using git, Travis Swicegood
[16:55] <syn-ack> jjohansen, You notice anything with the current mainline aa kernel where the ld avg sky rockets into the high high 1.'s when particular profiles are running?
[16:56] <syn-ack> stop the app or put the profile into complain and the avg goes to where it's supposed to be
[17:00] <jjohansen> syn-ack: I hadn't noticed, which apps?
[17:01] <syn-ack> jjohansen, skype... I'm kinda hacking that one up to get it running and that's what it's happening with
[17:02] <jjohansen> hrmm, can you send me the profile you are using and I'll give it a try
[17:02] <syn-ack> sure.
[17:02] <jjohansen> which version of skype?
[17:02] <syn-ack> <IP_ADDRESS>
[17:03] <syn-ack> jj sent off to ya
[17:04] <jjohansen> thanks
[17:04] <syn-ack> np
[17:04] <syn-ack> jjohansen, I even checked it against a production kernel and it still does it though not *quite* as bad
[17:05] <jjohansen> syn-ack: okay I'll look at both
[17:06] <syn-ack> You don't notice anything in that profile that I may have fscked up on do ya?
[17:09] <jjohansen> syn-ack: not at first glance
[17:09] <syn-ack> hrm
[17:10]  * syn-ack goes back to pulling audits against that profile then
[17:10] <syn-ack> did you notice that spike though?
[17:13] <jjohansen> syn-ack: haven't gotten that far yet, I am just pulling that version of skype now
[17:13] <syn-ack> ah. sorry to rush you then. :P
[17:14] <jjohansen> syn-ack: another question 32bit, or 64bit?  Or 32 bit app under 64 bit OS
[17:14] <syn-ack> 32 under 64. :/
[17:15] <jjohansen> okay, well I will try 64/64 first and then can move to 32/64
[17:19] <syn-ack> jjohansen, I've been obsessing over this particular profile for the last 3 days trying to bug it out. >:|
[17:21] <jjohansen> hrmm, any particular usage pattern?
[17:22] <syn-ack> not really. I have set as a service which starts when Gnome loads
[17:23] <syn-ack> jjohansen, Most of the time it's just sitting waiting for an incoming.
[17:23] <syn-ack> Dude, standby
[17:23] <jjohansen> ok
[17:23] <syn-ack> I have a 5 month old
[17:24] <syn-ack> ANYWAY... when I start it with the profile enabled, it goes from a 0.0 to about a 1.78 where it will stay, eatting one of my cores
[17:25] <syn-ack> Start video on it and it spikes up to 2.5 to 3
[17:26] <jjohansen> ouch
[17:27] <syn-ack> Yeah, I was wondering why my keyboard was literally getting hot to the touch... tracked it down to that
[17:28] <syn-ack> And if you grep your current audit of the profile you'll notice trivial denials that shouldnt cause that
[17:28] <syn-ack> That's something I was working on till I found the spike issue
[17:29] <jjohansen> well, you would think that but denials can do strange things to apps
[17:29] <syn-ack> yeah?
[17:29] <syn-ack> hrm
[17:30] <jjohansen> not saying that is the case hear, just I have seen where apps didn't like a deny and went into loops etc
[17:30] <jjohansen> not properly handling error cases
[17:30] <syn-ack> hrn
[17:32] <jjohansen> so it is certainly pegging my cpu, some denies in the audit log, so have reproduced now to figure what is going on
[17:33] <syn-ack> well, as long as it's reproduced thats what I care about.
[17:33] <syn-ack> That way I know *I'm* not losing it
[17:34] <jjohansen> hehe no.  It looks to be spinning on a request to clock_gettime
[17:35] <syn-ack> Since I'm still learning, how did you find that?
[17:37] <jjohansen> strace skype
[17:38] <syn-ack> Dammit, next time I'm going with my gut
[17:39] <jjohansen> hehe
[17:42] <syn-ack> I did'nt think that'd work since well... it's not open source
[17:44] <jjohansen> nah its will work on any app, well at least for the syscall layer
[17:44] <syn-ack> jjohansen, I think I've taken enough of your time. I know you've got quite a bit going on so I'll leave you alone for now. I really appreciate your help and mentoring.
[17:44] <syn-ack> jjohansen, That's good to know.
[17:45] <jjohansen> syn-ack: np, and it isn't taking up my time.  I need to make sure it is working properly it looks like we are missing an audit message
[17:45] <jjohansen> so the tools can't learn the behavior
[17:46] <jjohansen> its is great having a reproducable test case
[17:46] <syn-ack> heh
[17:46] <syn-ack> I'm sure it is
[17:46] <syn-ack> I can only imagine some of the crap you guys get
[17:46] <syn-ack> "Y IT NO WERK ON MAH BOX?!!!??!1?"
[17:51] <jjohansen> :)
[17:55] <syn-ack> jjohansen, I'm still really just going off the techdoc from Novell for app armor and with the way it's laid out it can be kinda confusing for me
[18:09] <Kano> will the new openfww be in u too or not
[18:09] <Kano> it is in fedora 12
[18:10] <Kano> openfwwf i mean
[18:13] <syn-ack> in me?
[18:13] <jjohansen> syn-ack: well the tech doc isn't the best laid out, but it is okay
[18:14] <jjohansen> what we need to do is get a new wiki up and start updating the documentation
[18:14] <syn-ack> yeah
[18:16] <syn-ack> jjohansen, basically what I did was see that the profile was in "not stable" profiles, pulled it and started working on by going off the doc, and sec 3.9 doesn't really go into any detail which would explain why I missed that strace
[18:20] <jjohansen> yeah they skip lots of things
[18:20] <hifi> I have a .patch and apt-get sourced 2.6.32, whats a simple way to add this patch that applies to this code into the build process?
[18:37] <syn-ack> jjohansen, btw that mainline kernel source... has it been updated since the last time we talked about it?
[18:38] <jjohansen> syn-ack: hrmm, I think tuesday afternoon was the last update I did
[18:38]  * syn-ack pulls the new source then
[18:38] <jjohansen> give me a minute
[18:38] <syn-ack> kk
[18:38] <jjohansen> I pulled in linus upstream, when I did that and it was failing to build
[18:39] <syn-ack> Then I'll just wait a bit
[18:39] <syn-ack> Yeah, I pulled in linus' upstream too and it wasn't building either, come to think of it
[18:39] <jjohansen> I am going to rebase and do a test build, hopefully the breakage has been fixed
[18:40] <syn-ack> k
[18:40] <jjohansen> yeah that is the danger of the merge window
[18:40] <hifi> thanks for the quick reply!
[18:44] <syn-ack> hifi, I would imagine just using patch
[18:44] <hifi> I did, I thought there would be a debian/patches
[18:44] <syn-ack> Then again, I'm not a kernel dev proper so I probably shouldnt be answering that one.
[18:45] <syn-ack> iirc, there is
[18:46] <hifi> btw. is the kernel compiled only once?
[18:46] <syn-ack> Linux Neptune 2.6.31-16-generic #52-Ubuntu SMP Thu Dec 3 22:07:16 UTC 2009 x86_64 GNU/Linux
[18:46] <syn-ack> I'd say not
[18:49] <hifi> uh
[18:49] <hifi> how long it would approximately take on "slow" dual core system to rebuild the whole package?
[18:49] <hifi> -j4 applied
[18:49] <syn-ack> Depends on what's in it
[18:50] <rtg> hifi, I suggest you follow the instructions in https://wiki.ubuntu.com/KernelTeam/KernelMaintenance to get and build from source.
[18:50] <hifi> last time I build the kernel was when forcedeth was experimental
[18:50] <hifi> built*
[18:51] <hifi> oh, I should've read that before
[18:52] <hifi> I just want a relatively quick -generic build
[19:02] <hifi> for the love of god, out of disk space while building
[19:02] <hifi> not my day today
[19:02] <hifi> is it possible to continue the build somehow
[19:21] <ghostcube> apw: i checked now that after a day not booting machine the cam was dark after boot up, then i updated and new kernel and other updates came in now the cam works i will tell you when i boot up tomorrow if the cam is dark.
[19:21] <ghostcube> and if it comes up as i think after any update like you mentioned at the beginning
[19:21] <ghostcube> :)
[19:34] <syn-ack> second monitor == goodness.
[19:53] <jjohansen> syn-ack: the apparmor repo has been updated to latest kernel and is building again
[19:54] <syn-ack> Oh goodie
[19:54]  * syn-ack kills the kernel compile. :P
[19:59] <syn-ack> jjohansen, Pulling it down now. Thanks.
[21:15] <syn-ack> jjohansen, This new kernel built and boots quite nicely and aa loaded nicely too
[21:17] <jjohansen> :)


[12:22] <rick_h_> morning
[12:43] <_stink_> uh oh... error on kernel upgrade.  /etc/kernel/postinst.d/initramfs-tools exited with return code 1
[12:43] <_stink_> now i don't know what state my machine is in
[12:44] <rick_h_> happy?
[12:45] <_stink_> if i never reboot, i never have to find out :)
[12:51] <_stink_> was https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/798414
[12:52] <_stink_> purge-old-kernels and some aptitude fiddling got it happy again
[12:55] <rick_h_> yay
[13:29] <cmaloney> woo woo


[00:30] <bdmurray> evand: quitting a only ubiquity install takes me to a full desktop is that expected?
[01:49] <evand> bdmurray: if you quit the installer, you mean?
[01:49] <evand> err yeah, that's what you said :)
[01:49] <evand> yes, it's expected
[01:54] <bdmurray> evand: 'kay, thanks
[09:33] <soren> cjwatson: lp:~soren/tasksel/limit-section You like?
[09:36] <CIA-50> tasksel: cjwatson * r1377 ubuntu/ (debian/changelog tasksel.pl): merge from lp:~soren/tasksel/limit-section
[09:37] <cjwatson> soren: WFM
[09:37] <cjwatson> thanks
[09:38] <soren> Great. Thank *you*.
[10:08] <CIA-50> oem-config: cjwatson * r534 oem-config/ (debian/changelog oem-config-firstboot): Log messages from update-rc.d rather than throwing them away.
[10:58] <davmor2> xivulon: wubi still has no backdrops for Xubuntu or Kubuntu during install was that something that couldn't be fixed?
[11:00] <xivulon> avmor2 haven't tested kubuntu yet
[11:01] <davmor2> np's
[11:01] <xivulon> more importantly I had a chat with cjwatson yesterday, and he submitted a patch reverting the umountfs changes
[11:02] <xivulon> would be good if you could test those changes as I will be able to do so only tonight
[11:02] <davmor2> cool so it should unmount cleanly now?
[11:02] <davmor2> cjwatson: did that fix get into the re-re-re-rolled cds from yesterday?
[11:02] <cjwatson> no
[11:02] <xivulon> don't think they are in the ISO yet, you will probably have to patch /etc/init.d/umountfs manually
[11:03] <cjwatson> I just sent them to xivulon by mail
[11:03] <xivulon> cjwatson a paste would do I guess
[11:03] <cjwatson> http://paste.ubuntu.com/53150/
[11:03] <xivulon> davmor2 all yours :)
[11:04] <davmor2> right so in time for rc then or the day after beta is released :)
[11:05] <xivulon> I did test similar changes (my version offline) and it worked well, should be almost identical to the above but did not have a chance to compare/test yet
[11:07] <cjwatson> day after beta if it works for somebody
[11:09] <davmor2> I has kubuntu wubi installing now what do I need to do?
[11:09] <davmor2> s/has/have
[11:12] <cjwatson> after it's installed, apply that patch to /etc/init.d/umountfs, then reboot and see if it's clean
[11:14] <davmor2> cjwatson: Right never applied a patch is it a magic command line thing or just swapping the file out?
[11:17] <cjwatson> wget -q -O- http://paste.ubuntu.com/53153/plain/ | sudo patch /etc/init.d/umountfs
[11:17] <davmor2> it's installed now just booting up
[11:17] <cjwatson> you'll need to install the patch package first
[11:17] <xivulon> cjwatson no chance to have the patch in for beta?
[11:17] <davmor2> cjwatson: thanks :)
[11:17] <cjwatson> no
[11:17] <cjwatson> xivulon: ^-
[11:17] <xivulon> :(
[11:17] <davmor2> xivulon: we will not re-test again ;)
[11:18] <xivulon> cjwatson I guess it will be okish if people will get it via updates
[11:22] <cjwatson> xivulon: there was no possible way you could have expected it to get into beta when it wasn't tested until the day of beta
[11:22] <davmor2> patched rebooting now
[11:23] <davmor2> bingo
[11:24] <davmor2> cjwatson: It' worked,  do you want it rebooting again just to be sure?
[11:25] <cjwatson> once is fine
[11:25] <cjwatson> I'll upload that, thanks
[11:26] <davmor2> okay
[11:26] <xivulon> thanks a lot
[11:26] <cjwatson> that doesn't mean it's in for beta - the beta CDs have already been rolled
[11:27] <davmor2> :D
[11:27] <xivulon> cjwatson I assume that if it is in the archive people will get it on first update, correct?
[11:27] <cjwatson> xivulon: once it's built, yes
[11:27] <xivulon> this should minimize tickets
[11:27]  * davmor2 scurries off to write down patch info
[11:28] <xivulon> Can we edit the release note caveats and suggest people to update?
[11:31] <cjwatson> feel free
[11:31] <cjwatson> I assume they're on the wiki, haven't looked yet
[11:31] <cjwatson> but really, people running the beta will be upgrading anyway
[11:32] <xivulon> yep should be fine
[11:32] <xivulon> thanks a lot
[11:45] <xivulon> superm1 will test the preseed tonight
[11:47] <xivulon> davmor2 can you remind me of the backdrop bug #?
[11:50] <davmor2> https://bugs.launchpad.net/wubi/+bug/208818
[11:50] <davmor2> only now both xubuntu and Kubuntu have no backdrop whereas Ubuntu does
[11:53] <xivulon> davmor2 not sure that one is in wubi domain
[12:11] <xivulon> davmor2, when you tested ntfs syncio, was that booting from a normal intrepid installation
[12:13] <davmor2> yes I did an install along side of xp and tested
[12:13] <davmor2> I think let me double check
[12:15] <davmor2> xivulon: no I did it on both wubi and an install if memory serves but definitely an intrepid install I used it to check m-a
[12:18] <davmor2> xivulon: Why?
[12:35] <xivulon> cking asked
[12:36] <xivulon> I guess he was checking whether it was a loop issue rather than an ntfs one
[13:54] <davmor2> cjwatson: why is the default hostname ubuntu on alternate even on a kubuntu and Xubuntu installs?  is it just a individual package that is used across all the desktops, he guesses wildly hoping to be right.
[13:55] <cjwatson> the latter, and because it's not especially clear to me that it's worth changing
[13:55] <cjwatson> bug 120087
[13:56] <cjwatson> I'd do it if the Kubuntu or Xubuntu developers (respectively) came to me and asked for it
[13:56] <davmor2> Okay cool I just wondered I never normally look at it
[13:56] <davmor2> just hit enter
[13:56] <cjwatson> I don't want to do it unilaterally
[14:10] <CIA-50> debian-installer: cjwatson * r968 ubuntu/ (14 files in 3 dirs): Move ports architectures to 2.6.25-2 kernels.
[14:14] <StevenK> cjwatson: Does that mean I can NBS out 2.6.25-1?
[14:16] <cjwatson> no
[14:16] <cjwatson> please wait until (a) after beta (b) linux-ports-meta is done
[14:16] <StevenK> Certainly
[14:17] <StevenK> cjwatson: d-i is one of the steps, and is usually done after -meta, so I thought I'd ask
[14:17] <cjwatson> StevenK: note that I have not uploaded the above change
[14:17] <cjwatson> I was just sticking it into bzr while I remembered
[14:18] <StevenK> Mmmmm, point
[14:30]  * cjwatson goes argh at bug 274219
[14:30] <cjwatson> I think I want a stretch to do nothing else but fix all our LVM and RAID bugs
[14:47] <CIA-50> partman-base: cjwatson * r108 ubuntu/ (choose_partition/partition_tree/do_option debian/changelog):
[14:47] <CIA-50> partman-base: Disable backup while displaying device/partition locked errors; it makes
[14:47] <CIA-50> partman-base: no sense and it can cause us to exit without closing the FIFO to
[14:47] <CIA-50> partman-base: parted_server (LP: #274219).
[16:23] <mathiaz> Hi - when defining a partition recipe, what's the order of the limits ? min_size max_size priority ?
[16:24] <cjwatson> see doc/devel/partman-auto-recipe.txt in debian-installer
:=<minimal size>_<priority>_<maximal size>_<parted fs>
[16:24] <mathiaz> cjwatson: right - however the preseed example in https://help.ubuntu.com/8.04/installation-guide/amd64/preseed-contents.html seems to be different
[16:24] <mathiaz> cjwatson: in the section about partitioning raid
[16:25] <mathiaz> cjwatson: 1000 5000 4000 raid
[16:27] <mathiaz> cjwatson: hm - it seems that only this line is odd - all the other examples in expert_recipe makes sense.
[16:29] <cjwatson> priority isn't necessarily <max
[16:29] <cjwatson> it's a bit weird
[16:29] <CIA-50> debian-installer: cjwatson * r969 ubuntu/ (3 files in 2 dirs): Move mainline architectures to 2.6.27-5 kernels.
[16:51] <kirkland> cjwatson: TheMuso: http://people.ubuntu.com/~kirkland/Screenshot-1.png
[16:52] <kirkland> cjwatson: looks like a bug against partman-base
[16:53] <cjwatson> kirkland: heh, looks like it
[16:53] <kirkland> cjwatson: i'm filing a bug now, will try to fix it
[16:56] <kirkland> cjwatson: another question...
[16:56] <kirkland> cjwatson: i tested an upgrade from hardy to intrepid, as I was curious what the default BOOT_DEGRADED value would be set to
[16:56] <kirkland> cjwatson: it was set to "true" which was unintended and unexpected
[16:57] <kirkland> cjwatson: I'm looking at mdadm.config and mdadm.postinst, where I have
[16:57] <kirkland>     db_get mdadm/boot_degraded
[16:57] <kirkland>     BOOT_DEGRADED="${RET:-false}"
[16:57] <kirkland> and i'd expect it to default to "false" if unset, but that's not happening, empirically
[16:58] <cjwatson> I think you need a DEBCONF_DEBUG=developer trace
[16:59] <cjwatson> trying to zen it will be a pain
[16:59] <kirkland> cjwatson: okay, so i'd like to simplify my test case
[16:59] <kirkland> cjwatson: intrepid install that doesn't actually have raid or mdadm installed
[16:59] <kirkland> cjwatson: so no BOOT_DEGRADED value
[17:00] <kirkland> cjwatson: and then install mdadm
[17:00] <kirkland> cjwatson: that should run the same exec path, right?
[17:00] <kirkland> cjwatson: rather than doing a full hardy -> intrepid upgrade, correct?
[17:00] <cjwatson> ... maybe
[17:01] <cjwatson> that's not obviously the same as a hardy system with mdadm installed
[17:01] <cjwatson> it depends on the maintainer scripts
[17:01] <cjwatson> you could take an intrepid install that doesn't have mdadm installed, install hardy's mdadm (if that works), and then upgrade
[17:01] <kirkland> cjwatson: okay, that sounds better
[17:05] <persia> There seems to be a piece I'm missing in lpia grub support, and I'm having trouble tracking it down.  Specifically, I'm failing with a DeconfError that grub-installer/bootdev doesn't exist.  While this isn't in the debconf DB, From my reading of the code, I'd expect to receive a return value of '', rather than an error.  Could someone point me at what I may be missing?
[17:09] <cjwatson> if it's not in the DB at all then you'll get an error
[17:09] <cjwatson> though I'm surprised it's not in the db
[17:11] <persia> I was a little surprised as well, given that ubiquity appears to have an extra hammer to force the setting: that's why I assumed I was supposed to skip it with a ''.
[17:11]  * persia looks at ubiquity again, harder
[17:12] <cjwatson> check /var/lib/dpkg/info/ubiquity.templates
[17:12] <cjwatson> and also try 'echo GET grub-installer/bootdev | sudo debconf-communicate' from a terminal on the live CD
[17:13] <persia> before or after a failed install?
[17:13] <cjwatson> either
[17:19] <kirkland> cjwatson: what do the :sl1: and :sl3: mean in the templates file?
[17:21] <kirkland> cjwatson: i notice that other text with embedded %s have :sl1: and seem to be working properly...  while partman/text/raid_device has :sl3:
[17:21] <cjwatson> they're translation categorisations from Debian
[17:21] <cjwatson> they have no significance to the installer itself
[17:21] <cjwatson> %s is handled manually with printf, not by anything in (c)debconf
[17:21] <kirkland> red herring then
[17:25] <kirkland> cjwatson: the odd thing is that the only way I can actually get a literal "RAID%s" printed to screen in the installer shell is to:
[17:25] <kirkland> printf "RAID%%s"
[17:25] <kirkland> or
[17:25] <kirkland> printf "RAID%s" %s
[17:25] <cjwatson> well, or anything that doesn't go through printf
[17:26] <kirkland> cjwatson: the relevant code is extracted here: http://pastebin.ubuntu.com/53228/
[17:26] <cjwatson> I can't even find that text
[17:27] <cjwatson> ah, right
[17:27] <kirkland> cjwatson: partman-base
[17:28] <cjwatson> kirkland: the 0 there is suspicious too
[17:29] <cjwatson> provisionally, bearing in mind I'm on the phone, I suspect buggered debconf protocol interaction
[17:32] <kirkland> cjwatson: is there a possibility that this code is duplicated elsewhere?
[17:33] <kirkland> cjwatson: partman-* is a bit of a maze to me, still
[17:33] <cjwatson> I don't *think* so
[17:33] <cjwatson> at the risk of being a broken record, DEBCONF_DEBUG=developer is your friend
[17:34] <persia> cjwatson: Thanks.  That was it precisely.
[17:34] <kirkland> cjwatson: :-)  sure
[17:36] <cjwatson> persia: hmm. what was it? :)
[17:36] <persia> cjwatson: Missing templates.
[17:37] <cjwatson> do you know why?
[17:37] <persia> No, but at least I know have a path I can follow.
[17:37] <persia> s/know/now/
[17:38] <cjwatson> ok
[17:52] <kirkland> cjwatson: the DEBCONF_DEBUG=developer goes on the kernel boot line?
[17:58] <cjwatson> yes
[18:21] <kirkland> cjwatson: http://pastebin.com/f2265a5d0  <- partman debconf debugged
[18:24] <kirkland> Oct  2 17:16:30 debconf: --> METAGET partman/text/raid_device description
[18:24] <kirkland> Oct  2 17:16:30 debconf: <-- 0 RAID%s device #%s
[18:24] <kirkland> Oct  2 17:16:30 debconf: --> METAGET partman/text/raid_device description
[18:24] <kirkland> Oct  2 17:16:30 debconf: <-- 0 RAID%s device #%s
[18:24] <kirkland> that's from syslog
[18:24] <cjwatson> can I have the full syslog? context would be good
[18:25] <cjwatson> debconf debugging doesn't show up in /var/log/partman
[18:59] <kirkland> cjwatson: fwiw, Hardy does *not* suffer the same string formatting problem
[18:59] <kirkland> cjwatson: i debdiff hardy vs. intrepid partman-base, and didn't find a bloody glove
[19:00] <kirkland> cjwatson: i suppose I can check debconf hardy v intrepid, if you think that might be more productive
[19:01] <cjwatson> I don't think it's remotely likely that it's a debconf fault
[19:01] <cjwatson> could I have the full syslog?
[19:09] <kirkland> cjwatson: all attached to that bug
[19:09] <kirkland> cjwatson: https://bugs.launchpad.net/ubuntu/+source/partman-base/+bug/277153
[19:10] <persia> And now I even know why, and how to fix it.  While I'm at it, is there a reason partman-efi is built for amd64, except in ubiquity?
[19:21]  * persia looks for amd64 bugs against partman-efi, with the intention of turning it on
[19:44] <CarlFK> cjwatson: [   38.557201]  sdb: unknown partition table
[19:44] <CarlFK> different box/everything from that other box
[19:44] <CarlFK> should I open a new bug?
[19:45] <CarlFK> http://dev.personnelware.com/carl/a/dhcp91/sfdisk.txt
[19:45] <CarlFK> http://dev.personnelware.com/carl/a/dhcp91/fdisk.txt
[19:46] <CarlFK> maybe the boot=?
[19:50] <cjwatson> persia: no, that just sounds like a bug
[19:51] <cjwatson> CarlFK: that means that the kernel doesn't understand the partition table
[19:51] <cjwatson> (not the installer)
[19:51] <persia> cjwatson: Thanks for the confirmation.  I'll definitely fix it then, rather than continuing my search for previous bugs that would have disabled it.
[19:51] <cjwatson> CarlFK: and fdisk doesn't seem to think it's all that great either
[19:51]  * persia files a summary bug for tracking, and prepares a branch for pushing
[19:53] <CarlFK> cjwatson: it is similar to https://bugs.launchpad.net/ubuntu/+bug/273379 - wondering if I should append logs to it or open a new bug
[19:55] <cjwatson> CarlFK: I have no way to know
[19:55] <cjwatson> CarlFK: if in doubt, a new bug explicitly referencing the old bug is better
[19:55] <CarlFK> will do.
[19:55] <cjwatson> and saying that you don't know whether it's the same bug, to fend off triagers
[19:56] <cjwatson> it looks different, at first glance
[19:58] <CarlFK> another issue: same box, after picking the partitions on hdc:  [File system has an incompatible feature enabled.  Compatible features are has_journal, dir_index, filetype, sparse_super and large_file.  Use tune2fs or debugfs to remove features.]
[19:58] <CarlFK> logs: http://dev.personnelware.com/carl/temp/Oct02/b/dhcp91/
[19:59] <CarlFK> pretty sure this isn't my fault..
[20:00] <cjwatson> that's a well-known bug :-(
[20:01] <CarlFK> need more logs ?
[20:03] <cjwatson> hmm, or is it, I can't find a bug where it should be (partman-basicfilesystems)
[20:04] <cjwatson> oh, of course, bug 59620
[20:05] <cjwatson> CarlFK: could you attach that syslog and partman to bug 59620? this is a new manifestation (ext2 with some unusual feature enabled)
[20:06] <CarlFK> will do.
[20:06] <cjwatson> CarlFK: 'tune2fs -l /dev/sdc1' would be good too
[20:12] <CarlFK> cjwatson: should the first be against parted or linux?
[20:13] <cjwatson> CarlFK: linux
[20:18] <cjwatson> kirkland: note how most of the matches for "RAID%s" are closely followed by something where the substitution *did* work
[20:19] <cjwatson> kirkland: it's only right at the end where it went nuts
[20:19] <kirkland> cjwatson: well, i was more puzzled by the fact that that's the only screen that *doesn't* work
[20:20] <kirkland> cjwatson: lots and lot of RAID.*%s.* all over that interface that printed fine
[20:20] <cjwatson> kirkland: I diagnose debconf protocol getting out of step, perhaps due to random stuff echoed to stdout somewhere
[20:20] <kirkland> cjwatson: i know, because I've clicked through those screens _thousands_ of times this release cycle :-P
[20:20] <cjwatson> so the debconf protocol is command on stdin, response on stdout
[20:20] <cjwatson> if something else witters on stdout, it can get confused
[20:21] <kirkland> cjwatson: that seems, um, fragile?
[20:21] <cjwatson> it works :-)
[20:21] <kirkland> :-)
[20:21] <cjwatson> it's considered a bug, yes
[20:21] <cjwatson> but it's very very difficult to fix
[20:21] <cjwatson> it's been considered a bug almost as long as debconf has existed
[20:22] <cjwatson> for the most part, various workarounds take care of it - for example the standard debconf shell confmodule redirects stdout to stderr so that you can't hit it by accident that way
[20:22] <kirkland> yeah
[20:22] <cjwatson> but that's not altogether foolproof and accidents do happen
[20:22] <kirkland> cjwatson: so, i verified that we don't have this problem in hardy
[20:22] <kirkland> hardy.1 anyway
[20:23] <cjwatson> oh
[20:23] <cjwatson> I have a guess
[20:23] <cjwatson> let me verify it
[20:24] <cjwatson> hmm, bad guess, never mind :)
[20:24] <cjwatson> (I thought debconf-set-selections might write to stdout)
[20:24] <kirkland> :-(
[20:25] <cjwatson> it does seem to be right there where it screws up though
[20:26] <cjwatson> oh, of course
[20:26] <cjwatson> we pipe input to debconf-set-selections, which uses debconf ...
[20:26] <cjwatson> go to jail, go directly to jail, do not pass go, do not collect two hundred pounds
[20:27] <evand> haha
[20:28] <cjwatson> I think it might be easier to just duplicate debconf-set-selections' functionality
[20:29] <cjwatson> which in this case is just writing to the logfile
[20:30] <cjwatson> kirkland: try http://paste.ubuntu.com/53261/
[20:30] <kirkland> cjwatson: which source are you looking at?
[20:30] <kirkland> cjwatson: ah
[20:30] <cjwatson> mdadm
[20:30] <cjwatson> sorry, that was my fault, I should have known better
[20:31] <kirkland> cjwatson: okay, i'll give that a shot
[20:40] <CarlFK> can I create a .tar with the BusyBox tar ?
[20:40] <CarlFK> pretty sure I have been told no before
[20:41] <CarlFK> Usage: tar -[zxtvO] - assuming those are the same as http://www.busybox.net/downloads/BusyBox.html there is no -c
[20:43] <cjwatson> debian/config/config.udeb:# CONFIG_FEATURE_TAR_CREATE is not set
[20:43] <persia> Fix for bug 277225 about udebs for grub-installer/lpia and partman-efi/lpia+amd64 is in lp:~persia/ubiquity/lpia-grub
[20:43] <CarlFK> cjwatson: thanks.  I'll note that in my script for the next time I try to figure this out :)
[20:44] <cjwatson> persia: huh, I thought I added grub-installer/lpia already
[20:44] <cjwatson> oh, d-i/lists. bah
[20:44] <persia> cjwatson: Yeah.  I was sure the debian/ubiquity.install-lpia was the last bit, and then found this one.
[20:45] <cjwatson> thanks, I wrote that so should've known :)
[20:45] <persia> Anything else you can think of?
[20:45] <cjwatson> well, I didn't think of this
[20:45] <cjwatson> that *should* be it
[20:45] <persia> OK.  Let's hope this is good then :)
[20:45] <CIA-50> ubiquity: cjwatson * r2871 ubiquity/ (d-i/lists/lpia d-i/lists/amd64 debian/changelog): merge from lp:~persia/ubiquity/lpia-grub
[20:46] <cjwatson> the lp: short form is the finishing touch on this workflow for me
[20:47] <cjwatson> for some reason it makes a big difference
[20:47] <persia> Not having to type the entire string?
[20:47] <cjwatson> I guess so, though that seems trivial
[20:48] <persia> No, it's time consuming, and easy to get wrong.  Short is good.
[20:48] <cjwatson> maybe it's just that I get to use the keyboard rather than having to copy-and-paste with the mouse, and that feels better
[20:48] <persia> I must say, that for all I'm still unhappy with the few universe or multiverse packages that use bzr packaging that I occasionally encounter, working with bzr packaging on the installer has been incredibly pleasant.
[20:49] <persia> I find myself actually almost looking forward to proper source-package branches, although I still need to sort out performance issues.
[20:49] <cjwatson> I wonder what the difference is
[20:50] <cjwatson> I think it makes a big difference to be working on the same branches a lot; the worst slownesses are branching from scratch and pushing up new branches
[20:50] <cjwatson> (and the latter should be fixed once they get stacked branches working)
[20:51] <persia> It's also my special combination of high bandwidth and high latency.
[20:52] <persia> I can download 1GB over a well-served torrent in about 5 minutes.
[20:52] <persia> Anything where I can get a big TCP window, I can download fast, but the slow-start algorithm means I need a lot of bits to fill the pipe.
[20:52] <persia> bzr does lots of little transactions, which is particularly bad for me, especially at 150-200ms from LP.
[21:15] <CarlFK> cjwatson:  some how this: #3 primary   29.7 GB   K ntfs       /windows    (good)
[21:15] <CarlFK> caused Oct  2 19:36:25 kernel: [ 3492.564405] ReiserFS: sdc3: warning: unknown mount option "umask=007"
[21:16] <CarlFK> stuff: http://dev.personnelware.com/carl/temp/Oct02/c/dhcp91/
[21:21] <kirkland> cjwatson: \o/  that fixed it
[21:22] <kirkland> cjwatson: also, i've regression tested the default-BOOT_DEGRADED-to-false-on-upgrade change I made,
[21:22] <kirkland> cjwatson: both look good
[21:24] <cjwatson> cool
[21:25] <cjwatson> CarlFK: sorry, it's after 9pm and I have a headache, I'm not sure I can look at this now
[21:25] <CarlFK> no prob - uploadng stuff to lp
[21:25] <cjwatson> something asynchronous would be better, yes :)
[21:25] <CarlFK> package: installer?
[21:26] <cjwatson> no such package
[21:26] <cjwatson> debian-installer would be fine
[21:26] <CarlFK> thaks
[21:42] <xivulon> cjwatson can confirm that the umountfs patch works well
[22:05] <xivulon> evand, cjwatson, could you please have a quick look at cking comment on https://bugs.edge.launchpad.net/wubi/+bug/204133/comments/59 and let me know what you think is the best course of action about activating syncio in wubi?
[22:06] <xivulon> my 2c is that we should turn it on, since cking is concerned about data loss (although I did not have any such report in 8.04)
[22:07] <xivulon> the wubi delta is minimal, I only add it to the ROOTFLAGS in menu.lst if fs==ntfs, not sure about the actual impact in terms of performance
[22:08] <xivulon> in case we can remove lupin-sysctl hacks
[22:12] <xivulon> superm1, I see you have metalinks up :)
[22:12] <xivulon> on the dailys though the URL contains the builddate, which makes things tricky
[22:13] <xivulon> would it be possible to have a stable URL (redirect or server side symlink)?
[22:13] <xivulon> I would also need a link for what will be the final metalink URL
[22:15] <superm1> xivulon, can you let tgm4883 know?
[22:15] <superm1> he's the one who handled all the metalink stuff
[22:15] <xivulon> sure
[22:16] <superm1> xivulon, so about the no networking thing - it happens in the "install only" mode on the disk too (no live env)
[22:16] <superm1> is that the same case as the regular ubuntu too?  Is network manager wrecking havock?
[22:17] <xivulon> superm1 can you remind me about the networking issue?
[22:22] <superm1> xivulon, network manager doesnt' start up on it's own
[22:22] <superm1> when you go into only-ubiquity or automatic-ubiquity
[22:22] <superm1> i would guess this affects Ubuntu too, but I can't tell for sure since I can't switch VTs in only-ubiquity in a VM
[22:23] <xivulon> would not think that is an issue for wubi, except for updates
[22:24] <superm1> well it is for the mythbuntu installed wubi
[22:24] <superm1> because that means that you cant connect to your backend - which is critical for it to work
[22:24] <xivulon> ah of course
[22:25] <superm1> that's the exact issue you were seeing
[22:25] <superm1> i bet it's because the init script for ubiquity is set to start before network manager's and they don't run in parallel
[22:26] <superm1> bingo.  S29ubiquity and S30NetworkManager
[22:26] <superm1> evand, was there a good reason why you chose 29 for ubiquity's init script then?
[22:27] <xivulon> I am building a new version to try
[22:27] <xivulon> there is no i386 iso for today http://www.mythbuntu.org/devel/dailies/081001/
[22:27] <xivulon> or yesterday
[22:28] <xivulon> I'll use the 30th
[22:28] <xivulon> ps rsync on the server would be welcome :)
[22:30] <superm1> xivulon, http://uk.cdimages.mythbuntu.org/mythbuntu-8.10-beta-desktop-i386.iso
[22:30] <superm1> that's a later one
[22:30] <superm1> what should be syncing across servers right now
[22:30] <superm1> the daily build for i386 broke yesterday i believe
[22:34] <xivulon> downloading
[22:35] <persia> superm1: Which VM solution are you using?
[22:35] <superm1> persia, virtualbox
[22:36] <superm1> when i hit ctrl-alt-fX, it switches my VT of the host system even if the keyboard is grabbed
[22:36] <persia> Ah.  I have a solution for switching VTs in KVM, but not for vbox.
[22:36] <superm1> vmware grabs it fully too
[22:36] <superm1> but my box with vmware workstation is out of commission for now
[22:42] <xivulon> superm1 in vb it is Alt Gr + Fn
[22:43] <cjwatson> xivulon: umountfs> cool, thanks. apparently I uploaded it and forgot about it anyway :)
[22:43] <xivulon> cjwatson, well I tested the original patch, not the actual package
[22:44] <cjwatson> sure, but that's ok
[22:44] <cjwatson> xivulon: syncio> seems like it makes sense to activate it
[22:44] <xivulon> agreed
[22:44] <cjwatson> superm1: 29> it needs to go before gdm
[22:44] <xivulon> I am building a new version with mythbuntu too right now
[22:45] <cjwatson> superm1: NetworkManager probably needs to move a bit earlier in order to give us space for ubiquity without having to change the name :-)
[22:45] <xivulon> cjwatson in case we need to deactivate lupin-sysctl
[22:45] <cjwatson> superm1: uk.cdimages is a pretty confusing name
[22:45] <superm1> cjwatson, that's the main mirror that our images start at before they get spit out
[22:46] <cjwatson> is that United Kingdom or Ukraine? :-) (neither one has the ISO-3166 code UK)
[22:46] <superm1> cjwatson, and then we have a redirect URL that people use
[22:46] <cjwatson> the UK's code is GB
[22:46] <superm1> cjwatson, ah.  it should be united kingdom.
[22:47] <cjwatson> compare gb.archive.ubuntu.com
[22:47] <superm1> cjwatson, but our redirect URL detects where you're coming from and if you are united kingdom and the bandwidth is within limits for the month offer that mirror
[22:47] <superm1> ah i always assumed uk.archive.ubuntu.com was united kingdom too
[22:47] <cjwatson> only due to wildcard DNS
[22:48] <cjwatson> and the fact that the master is in the UK
[22:48] <superm1> ah
[22:49] <superm1> well Daviey, see the above ^.  You want to get that DNS corrected?
[22:52] <superm1> cjwatson, is the order of resolving init scripts case sensitive?  So if NetworkManager was brought down to 29, would it resolve before or after ubiquity?
[22:56] <cjwatson> it's C locale, in which N < u
[22:56] <cjwatson> though n < u anyway so case doesn't matter
[22:58] <xivulon> cjwatson have pushed rev111 for lupin disabling lupin-sysctl
[22:59] <cjwatson> ok, what happens to people upgrading from wubi beta installs if they upgrade to that version of lupin?
[23:11] <cjwatson> xivulon: I also changed it to 0.22 not 0.21ubuntu1 - might want to use dch -iU rather than dch -i for when you're changing packages maintained natively in Ubuntu
[23:12] <xivulon> made note
[23:13] <xivulon> cjwatson good point, as it is now I guess upgrading will be left with lupin-sysctl
[23:13] <cjwatson> that's probably as desired, since they won't get menu.lst changed ...
[23:14] <xivulon> correct
[23:14] <cjwatson> I was worried about lupin getting upgraded but menu.lst not having syncio yet
[23:14] <cjwatson> xivulon: could you add an explicit note about that to the changelog in case others don't follow the reasoning?
[23:14] <cjwatson> possibly as a comment in debian/rules too
[23:15] <xivulon> sure
[23:21] <Daviey> superm1, cjwatson: UK domain noted, will sort it.
[23:21] <cjwatson> thanks
[23:25] <kirkland> cjwatson: kees was about to sponsor my mdadm changes, fyi
[23:26] <kirkland> cjwatson: if you wanted to check them first
[23:26] <cjwatson> if it's basically just including the patch I suggested, I don't think I need to
[23:26] <kirkland> cjwatson: it does that, plus 2 more things....
[23:26] <kirkland> cjwatson: it solves the default-to-false on hardy->intrepid upgrades
[23:27] <cjwatson> ok, sure, I can have a look
[23:27] <kirkland> cjwatson: which is also a 2-liner
[23:27] <kirkland> cjwatson: and mathiaz really wanted to change the debconf text
[23:27] <kirkland> http://people.ubuntu.com/~kirkland/mdadm/mdadm.debdiff
[23:27] <kirkland> cjwatson: apologies, that debdiff contains all the po BS
[23:28] <cjwatson> kirkland: I think that makes sense, except that your changelog comment for the root_on_raid fix is incorrect
[23:29]  * kirkland looks
[23:29] <cjwatson> kirkland: the problem isn't writing to stdout (that was just a hypothesis I had), it's that we're causing debconf-set-selections to read from a pipe from echo rather than from the debconf input fd
[23:29] <cjwatson> so perhaps something like "do not pipe input to debconf-set-selections as that breaks debconf; write directly to the preseed log file instead" would be more accurate
[23:30] <kirkland> cjwatson: my bad
[23:30] <cjwatson> I'm all for pedagogical changelog entries :)
[23:31] <cjwatson> anyway, otherwise fine
[23:34] <xivulon> cjwatson rev 113
[23:34] <xivulon> superm1 can you please remind how to get the password for the backend
[23:35] <cjwatson> xivulon: ok, you didn't need the second changelog line :-) users will see it all at once
[23:35] <superm1> xivulon, as indicated in the gui, /etc/mythtv/mysql.txt :)
[23:35] <cjwatson> I removed it
[23:36] <cjwatson> xivulon: uploaded, thanks
[23:49] <xivulon> superm1, yep nm really needs to be started up upfront
[23:49] <superm1> xivulon, i filed a bug against network manager on it
[23:50] <superm1> xivulon, too bad, that's the only gating factor from wubi working with mythbuntu with that preseed that i see
[23:50] <xivulon> do you want also a backend role?
[23:50] <xivulon> or maybe leave the question unanswered?
[23:51] <superm1> xivulon, well that's a complicated question.  you can't preseed to setup multiple drives can you - both a loop mount and a real file system?
[23:51] <xivulon> by the way mounted with syncio started copying files 1m ago'
[23:53] <xivulon> is it? hmm I have ROOTFLAGS=syncio, but cannot see any trace in /proc/mounts...
[23:56] <xivulon> not sure how to check that
[23:57] <superm1> xivulon, because you'd have to mount the recordings partition to be on your NTFS filesystem and the install on the loop mount.  can you do that with a preseed right now?
[23:58] <xivulon> well the ntfs partition is going to be mounted as /host, so you can preseed /host/yourpath
[23:59] <superm1> is it always mounted as /host?
[23:59] <xivulon> yes
[23:59] <superm1> if we preseed a path that doesnt yet exist, like C:/ubuntu/mythtv, would that get made by the installer?


[04:40] <siretart> kees: what's wrong with libavfilters yadif filter (accessible via avconv)?
[04:40] <siretart> kees: it's taken from mplayer/mencoder after all
[04:42] <siretart> kees: unfortunately, there is no debian mplayer, ubuntu followed debian's removal. ironically, it was me who requested its removal after years of fighting to get it into debian. :(
[05:30] <darkxst_> stgraber, did you see bug 1408853 ?
[12:53] <Laney> There's a mail in u-d-a moderation if someone passes by
[13:32] <cjwatson> Laney: .
[13:45] <dpasqualin> Hello, a simple question. Is the ubuntu-sdk the recommended way to develop for ubuntu desktop too or just for mobile?
[15:56] <stgraber> darkxst_: I haven't


[02:50] <i915> Just rambling main question is does anybody given a task_struct know how to distingish a kernel task from a user task /process
[10:08] <Laibsch> considering bug 1529917 how are trusty users supposed to install the mainline kernel?
[10:09] <Laibsch> Trusty gcc 4.8 lacks fstack-protector-strong
[10:48] <apw> not even waiting half an hour ...
[14:20] <ricotz> apw, hi, while yakkety is targetting 4.8, will there still be a 4.7 kernel packages?
[14:21] <apw> ricotz, likey briefly yes
[14:22] <ricotz> apw, I see
[14:23] <apw> much as there is meant to be 4.6 ones too, though we have yet to achieve that
[14:31] <ricotz> apw, yeah currently using "inux - 4.6.0-7.8" which could need an update to 4.6.3
[14:32] <apw> ricotz, yeah i think someone is doing that "now"-ish
[14:33] <ricotz> ah, alright :)