[09:35] <rmg51> Morning
[12:14] <teddy-dbear> Morning peoples, dogs, turkeys and everything else
[12:35] <InHisName> Howdy all
[13:32] <ChinnoDog> sup
[13:56] <MutantTurkey> got the S4 Active
[13:56] <MutantTurkey> in terms of software features, holy crap I did not know so many to look cool but be useles.
[13:56] <MutantTurkey> seems sturdier than my S3, supposedly water tight
[13:56] <MutantTurkey> still ordered a case
[14:01] <teddy-dbear> turkey drop coming up
[14:08] <InHisName> Maybe if it is 'drop proof' turkey can take to testing with blunt objects like baseball bats etc.
[14:08] <InHisName> Give a new meaning to tapping the screen.
[14:33] <ChinnoDog> Baseball played with S4 active as the ball would make a good commercial.
[15:44] <MutantTurkey> i'm not going to drop it
[16:23] <teddy-dbear> :-(
[16:33] <KyleYankan> The difference between the s3 and s4 seems trivial. Lots of useless features. but the whole "Active"" thing? I like that.
[16:36] <MutantTurkey> yeah
[16:36] <MutantTurkey> we'll see how it holds up
[16:48] <ChinnoDog> The girlfriends S4 runs noticeably faster than my S3.
[16:48] <ChinnoDog> I do have half the market installed though, so there is that.
[18:59] <ChinnoDog> If I ever need to hire IT staff I am going to be sure that the applicants can also use Linux so I know they can operate a command line.


[06:15] <acheronuk> Kubuntu iso build failed with:
[06:15] <acheronuk> The following packages have unmet dependencies:
[06:15] <acheronuk>  libio-socket-ssl-perl : Depends: libnet-ssleay-perl (>= 1.84-1ubuntu0.1) but 1.84-1build1 is to be installed
[06:23] <acheronuk> that is bionic ^^
[06:28] <acheronuk> xnox: ^
[06:29] <acheronuk> from the control file: Depends: libnet-ssleay-perl (>= 1.84-1ubuntu0.1),
[06:39] <acheronuk> sil2100: morning. FYI, xubuntu and kubuntu daily isos for bionic are failing today due to the libio-socket-ssl-perl SRU in bionic proposed having broken deps in its control file
[06:47] <sil2100> acheronuk: ah, this one, I poked vorlon and xnox about it yesterday already, since it was basically causing FTBFS for another SRU I was driving
[06:48] <sil2100> I hoped it would have been resolved somehow by today
[06:48] <acheronuk> ok. as long as is on someone's radar, then good
[07:00] <sil2100> acheronuk: ok, I actually see an upload that Steve didn't review yesterday, missing piece of the SRU puzzle
[07:02] <acheronuk> sil2100: makes sense. I looked or something like that. maybe I looked in the wrong queue!
[07:03] <sil2100> acheronuk: I totally missed it yesterday as well, since the upload was a bit old
[07:03] <sil2100> So it was hidden in the older entries
[07:03] -queuebot:#ubuntu-release- Unapproved: accepted libnet-ssleay-perl [source] (bionic-proposed) [1.84-1ubuntu0.1]
[07:08] <acheronuk> sil2100: yeah, just found this from last night https://irclogs.ubuntu.com/2019/05/30/%23ubuntu-release.html#t14:58
[07:08] <acheronuk> fort some reason my BNC backlog did not give me that :/
[07:08]  * acheronuk kicks the KDE bnc
[07:16] <sil2100> acheronuk: too bad Steve didn't include that analysis in the SRU bug
[07:17] <sil2100> grrrr
[07:18] <sil2100> xnox, vorlon: since I accepted the SRU that was in the queue, and seeing that I didn't have all the IRC-chat context, I'm now wondering if that was the right thing to do?
[07:21] <sil2100> xnox, vorlon: when reviewing the package I just assumed, as per regression potential, that the behavioral change of read()/write() has been decided and accepted, but I see it is not quite
[07:22] <sil2100> xnox, vorlon: maybe I did accept this package prematurely, but having a partial SRU and bionic-proposed broken was also not great
[07:22] <sil2100> So it was either this or removing the SRU from the -proposed pocket
[07:24] <sil2100> Just follow up with another upload to if this needs to be changed
[10:22] -queuebot:#ubuntu-release- Unapproved: accepted openssl [source] (disco-proposed) [1.1.1b-1ubuntu2.1]
[11:13] -queuebot:#ubuntu-release- Unapproved: xorg-server (bionic-proposed/main) [2:1.19.6-1ubuntu4.2 => 2:1.19.6-1ubuntu4.3] (desktop-core, xorg)
[12:21] -queuebot:#ubuntu-release- Unapproved: sssd (bionic-proposed/main) [1.16.1-1ubuntu1.2 => 1.16.1-1ubuntu1.3] (kubuntu, ubuntu-desktop, ubuntu-server)
[12:26] -queuebot:#ubuntu-release- Unapproved: sssd (xenial-proposed/main) [1.13.4-1ubuntu1.14 => 1.13.4-1ubuntu1.15] (kubuntu, ubuntu-desktop, ubuntu-server)
[13:33] -queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (disco-proposed) [240-6ubuntu5.1]
[13:36] -queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (cosmic-proposed) [239-7ubuntu10.14]
[13:42] -queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10.22]
[14:05] -queuebot:#ubuntu-release- Unapproved: qtwebengine-opensource-src (bionic-proposed/universe) [5.9.5+dfsg-0ubuntu2 => 5.9.8+dfsg-0ubuntu1] (kubuntu)
[16:35] <Eickmeyer> AAs: Ubuntu Studio now has two packages needing review: lsp-plugins, and ubuntustudio-look has a new binary called ubuntustudio-wallpapers-disco that is just moving the disco wallpapers to a new package in prep for new wallpapers on the way.
[21:02] -queuebot:#ubuntu-release- Unapproved: glusterfs (bionic-proposed/universe) [3.13.2-1build1 => 3.13.2-1ubuntu1] (no packageset)


[00:43] <lifeless> ok thats weird
[00:43] <lifeless> http://github.com/matee911/bzr-flakes
[00:43] <lifeless> bzr plugin, hosted on github.
[00:43] <lifeless> We've got a *serious* usability failure to make that happen.
[00:55] <SamB_XP> lifeless: so are you doing followup?
[00:55] <lifeless> SamB_XP: I might
[00:55] <lifeless> we'll see
[00:55] <SamB_XP> apparantly he just imported it to github about two and a half weeks ago, with no commits since?
[00:56] <lifeless> yah
[00:56] <lifeless> it was on lp
[00:56] <SamB_XP> yeah, so it says
[00:56] <SamB_XP> but what I wanna know is why he didn't convert the history
[00:56] <lifeless> wha! wow
[00:58] <SamB_XP> yeah, he left behind a grand total of 3 commits!
[01:35] <mtaylor> mordred@orisndriz03:~/src/drizzle/unittests$ bzr pump
[01:36] <mtaylor> bzr: ERROR: exceptions.AttributeError: 'RevisionTree' object has no attribute 'branch'
[01:36] <mtaylor> pipeline hate me
[08:52] <johnf> Is it possible to get export to also export uncommited changes?
[10:11] <lifeless> johnf: not currently; please ensure there is a bug
[10:33] <ronny> sup
[10:34] <ronny> where did bzrlib.diff._get_trees_to_diff go ?
[10:46] <ronny> whops, it was turned to something more complicated but luckyly its actually a unused import i left in
[12:52] <lukus> hi - i've just started using bzr and i've got a quick question
[12:54] <lukus> i'm using a centralised store - but I'm the only person using bzr .. with my local copy, would it be okay to 'checkout' the trunk and work that independently and then push it back once i'm done, or should i still create independent branches?
[14:02] <michaelforrest> does anybody know how I can get a combined bzr log for two or more branches?
[14:04] <michaelforrest> or - you know - a repository log?
[14:06] <michaelforrest> i.e. a text output of the stuff you see with bzr qlog ?
[14:11] <michaelforrest> hm, okay the qbzr source has a load of 'open_locations' and 'append_branch' etc..  so I guess there's not a straightforward way :(
[17:05] <sproaty> is there a way to exclude a file from a single commit?
[17:05] <sproaty> I want to commit all changes besides one file
[17:06] <beuno> sproaty, not easily
[17:06] <beuno> you can use "shelve"
[17:06] <beuno> to shelve the changes done to that file
[17:06] <beuno> or specify the files you do want to commit, and leave the other one out
[17:07] <sproaty> so I shelve the file, commit and then unshelve
[17:07] <sproaty> and it'll show as a change for the next commit?
[17:08] <beuno> yes
[17:09] <sproaty> awesome  :)
[17:09] <fullermd> Actually, commit has an -x/--exclude arg...
[17:13] <sproaty> cheers
[17:17] <sproaty> done what I wanted :D
[19:01] <u-foka> hy!
[19:01] <u-foka> is there a good way to completely remove a branch from a shared repo?
[19:03] <luks> not easily
[19:03] <luks> you have to re-creeate the repo
[19:04] <u-foka> well, i hoped that an easier way exists :)
[19:05] <u-foka> then stacked branches seems the only solution to the problem?
[19:31] <_buck> I am working with Bazaar (bzr) 2.0.2  Python interpreter: /usr/bin/python 2.6.4 Platform: Linux-2.6.31-19-generic-i686-with-Ubuntu-9.10-karmic. At my university we connect using a http proxy(all protocols).
[19:32] <_buck> When I do bzr launchpad-login eraser029   , I get this error : bzr: ERROR: Connection error: while sending GET /~eraser029/%2Bsshkeys: [Errno 111] Connection refused
[19:32] <_buck> Please help.
[20:21] <_buck> Can somebody tell me how to resolve this issue?
[20:47] <dcraven> I'm using bzr-svn. Is there any way to get an svn style diff outside of using 'bzr send'?
[20:47] <dcraven> I only want a diff of specific local revisions.
[20:58] <jelmer_> dcraven: hi
[20:58] <jelmer_> dcraven: not at the moment, though I agree it would make sense to provide a way to do that
[21:02] <dcraven> Crud :)
[21:03] <jelmer_> dcraven: can you perhaps file a bug about this?
[21:04] <dcraven> jelmer_: I will do that. Thanks.
[21:14] <lifeless> moin
[21:15] <jelmer_> 'lo lifeless
[23:12] <igc> morning
[23:15] <lifeless>  hi


[00:07] <Neko> it copies the asm stuff right but it seems any platform with a plat- and a mach- doesnt copyor link the plat-blah/include stuff into place
[00:47] <Neko> hmn doesn't do it for omap either
[00:47] <Neko> kernel bugggggg
[00:47] <persia> Indeed.  This may explain a number of fail-to-build module reports on armel installs.
[00:50] <Neko> how would you work out what the parent plat-???? directory is to the mach you're building for though, to fetch the right headers
[00:52] <persia> Well, linux-image-${target} could depend on linux-headers-${target}, and one could encode the requirements in the specific dependencies for linux-headers-${target} with a lookup table in the package source.  That said, doing it without the packaging sugar would be lots harder.
[00:52] <Neko> that assumes the target is directly related to the machine
[00:53] <persia> ah, but ${target} might support several machines?
[00:53] <Neko> all scripts/headers.sh knows is arch, srctree, and what kind of header build it's doing (check or install)
[00:53] <Neko> umm no
[00:53] <Neko> but what if the target is, like in Ubuntu -generic or -server
[00:54] <Neko> right now there's fsl-imx51 but what about fsl-imx53.. or does it get changed to fsl-mx5?
[00:54] <Neko> that still doesn't give you a direct indication of the need for the includes from plat-mxc
[00:54] <persia> They're just strings, and the semantic meaning is weak.
[00:55] <Neko> isn't what what I am saying? :D
[00:55] <Neko> I don't want the fix to be a case block in a bash script
[00:55] <persia> Sure, but in practice, we assign semantics.  For example, the -omap kernels only work on omap3
[00:55] <Neko> what about -omap4
[00:55] <persia> makefile, but yeah, there ought be a better way :)
[00:55] <Neko> seperate kernel?
[00:55] <persia> Currently, yes.
[00:56] <persia> If someone is able to make a kernel that boots both cleanly with full support, I'd expect that there would be available headers will the same level of support.
[00:56] <Neko> currently make headers_install calls scripts/headers.sh arm arm install
[00:56] <persia> So if someone created -generic for armel, I'd expect that to work for nearly every device (this is probably some years off)
[00:56] <Neko> or something similar
[00:57] <Neko> makefile doesn't do much, in the end there's a perl script too
[00:57] <persia> Most of the packaging sugar is managed by debian/rules, which is traditionally a makefile, which is why I mention make.
[00:57] <Neko> loops over files and unifdefs them
[00:58] <Neko> debian headers rules from kernel-package makes some clever changes but it still does not handle it
[00:58] <Neko> IMO it's a kernel bug not a packaging bug
[00:58] <persia> Indeed: that's the bug.
[00:58] <Neko> it's not a packaging bug
[00:58] <Neko> make headers_install needs to do this as well or the headers are useless
[00:58] <persia> I agree it's a kernel bug.  It could be masked with a packaging-class fix, but fixing it in the kernel would be vastly superior
[00:58] <Neko> mach/memory.h comes from plat- on 10 subarches of arm
[00:58] <Neko> you can't build libc without that file
[00:59] <Neko> there are google pages for hacks to fix bionic compilation with broken headers like that
[04:12] <rsalveti> apw: patches sent to our kernel team and linux-omap
[04:12] <rsalveti> apw: finally working at normal beagle and xM
[04:13] <rsalveti> spent a lot more time building and testing than actually coding
[04:13] <rsalveti> recreate the rootfs, etc
[04:13] <rsalveti> but should be fine now, I'm able to see the console and X11
[04:22] <ka6sox> rsalveti, what should I expect the rndis ethernet device to show up as in maverick?
[04:54] <sanket> hii
[05:45] <bagge> hi :) I'm about to install ubuntu-arm on my phone, but I'm wondering about something... I can only get packages that are made for ARM right?
[06:00] <Neko> bagge, if you have to ask that I'd say you're not ready to install ubuntu on a phone :D
[06:13] <bagge> Neko: I'll have to crash my phone to learn ;)
[06:18] <ka6sox> bagge which phone?
[06:22] <bagge> ka6sox xperia x10 mini pro (hehe)
[06:30] <ka6sox> Good Luck...I have no experience with that.
[12:44] <ogra> hrw, console-setup (1.57ubuntu5) was just uploaded, that should solve all hangs of the keyboard stuff on upgrade/dist-upgrade and install
[12:50] <hrw> cool
[12:57] <apw_> rsalveti: yo ... saw your patches, have some kernels building with them applied, will you be about in about half hour to test them?
[12:57] <rsalveti> apw: yup, lunch is in one hour :-)
[12:57] <rsalveti> apw_: ^
[13:01] <apw_> rsalveti: ok cool
[13:01] <apw_> will get it to you before then :)
[13:01] <rsalveti> :-)
[13:05]  * ogra wornders if you can actually make sure that with all these food things around these kernel patches since yesterday you dont leave breadcrumbs and fatty finger prints on the package :)
[13:06] <ogra> every time i see you guys talking about these patches one of you is busy with food stuff :)
[13:09] <rsalveti> :P
[13:10] <apw_> ogra: the kernel always has a bunch of fingerprints all over it :)
[13:10] <ogra> heh
[13:27] <apw> rsalveti, http://people.canonical.com/~apw/misc/arm/linux-image-2.6.38-1-versatile_2.6.38-1.28~pre1_armel.deb
[13:27] <apw> if you could do the honours
[13:27] <rsalveti> downloading :-)
[13:33] <rsalveti> apw: the name versatile is right?
[13:33] <apw> rsalveti, no i've pushed the wrong one cause i am stupid
[13:33] <rsalveti> ok :-)
[13:34] <apw> be about 5 mins ... bottom
[13:34] <rsalveti> np
[13:36] <apw> rsalveti, http://people.canonical.com/~apw/misc/arm/linux-image-2.6.38-1-omap_2.6.38-1.28~pre1_armel.deb
[13:36] <apw> silly apw
[13:47] <rsalveti> ok, installing
[13:59] <apw> rsalveti, how they looking?
[14:00] <rsalveti> apw: and we have a winner, using normal desktop :-)
[14:02] <rsalveti> apw: and tim already applied at master-next
[14:02] <apw> rsalveti, heh yeah he and i are duplicating work today :)
[14:02] <rsalveti> :-)
[14:02] <rsalveti> ok, sounds good timing for lunch
[14:03] <apw> rsalveti, yep, you are done, thanks muchly
[14:03] <rsalveti> apw: ping me if you want any test or have any update on the omap side
[14:03] <apw> rsalveti, will do indeed, i expect there will be a final final a2 kernel on monday to test
[14:03] <rsalveti> apw: cool
[14:03] <rsalveti> and it seems that it'll work fine, at least it didn't explode at my face yet
[14:04] <rsalveti> apw: do you want the patch to remove the WARN_ONCE from the erratum?
[14:04] <rsalveti> we could just use a simple printk
[14:04] <rsalveti> I have it here if you think it's worthy
[14:05] <rsalveti> apw: http://rsalveti.net/tmp/0001-OMAP3630-PM-don-t-warn-the-user-with-a-trace-in-case.patch
[14:05] <apw> rsalveti, i think it is worth while, send out to the kernel-team list, i recon
[14:06] <rsalveti> apw: ok, will do
[16:52] <apw> ogra, i am not sure what you mean about srus being pushed out by securty.  we h
[16:52] <apw> we haven't done that for the last two months at least
[17:06] <ogra> apw, well it happens occasionally i dont think its currently the issue
[17:06] <apw> ogra, ok so what is the issue
[17:06] <ogra> none, its just that not all SRUs have been tested yet
[17:07] <ogra>  * Maverick kernel SRU testing is still in progress
[17:07] <ogra> thats all i said
 and we wlao often clash with security uploads
 which force the SRU out of -updates
[17:08] <apw> well you said that which prompted my question
[17:08] <apw> i think everyone would have taken that as the reason the testing was not done from the context
[17:08] <ogra> hmm, i didnt mean it like that
[17:08] <ogra> though its often enough the cause
[17:08] <ogra> not thins time though
[17:09] <apw> well its going to be rare now as most security is going in the hopper with the rest of the updates
[17:09] <apw> as long as we don't have a process issue between us i am happy
[17:09] <ogra> i think we dont
[17:09] <ogra> but that would be a question for GrueMaster
[17:10] <ogra> since he is the one who suffered from it in the past
[17:11] <ogra> i really didnt mean to blame anyone i just tried to quieten marjo :P
[17:11] <ogra> sorry if it came across that way
[17:11] <apw> ogra, no harm no foul, just wanted to make sure we'd not missed something, ta
[17:11] <ogra> (the phrase above is always in my report since it is nearly always true that there are some SRUs to test)
[17:12] <ogra> *nobody* ever asked about it :P
[17:12] <apw> ogra, yep and we are making more now-a-days so it'll be even more true
[17:53]  * GrueMaster hears his name being mentioned.
[17:54] <GrueMaster> what kernel in maverick still needs testing?
[17:54] <GrueMaster> ogra: apw ^^^
[17:58] <rsalveti> ogra: both images are using the new x-loader package, so we should be ok to remove the x-loader-omap4 one
[18:43] <ogra> rsalveti, awesome
[18:44] <ogra> GrueMaster, dunno, i just saw several uploads this week and assumed some would still need testing
[18:46] <GrueMaster> ogra: I haven't seen anything for omap4.  Until Monday, I can't test omap3 stuff easily, unless I build a stripped down image for my beagle.  Too painful otherwise.
[18:47] <ogra> GrueMaster, right, i was referring to omap3 rather
[18:49] <GrueMaster> Well, unless there is a specific patch for omap3 in the main kernel, I'm not too worried.  Security updates usually get pushed through without my help.  It is specific omap3 bug fixes I usually have issues getting tested on time.


[13:03] <intekk> hi, i wondered if i could get a little clarification on an issue regarding an edubuntu lts


[01:03] <CIA-3> ubiquity: cjwatson * r3082 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py):
[01:03] <CIA-3> ubiquity: * GTK frontend:
[01:03] <CIA-3> ubiquity:  - Fix suggested keymap handling so that selecting that option after
[01:03] <CIA-3> ubiquity:  selecting a custom keymap applies the suggested keymap (LP: #337998).
[01:52] <CIA-3> ubiquity: cjwatson * r3083 ubiquity/ (debian/changelog partman/check.d/03partition_too_small):
[01:52] <CIA-3> ubiquity: Add a fudge of 20% to the size of each tree on the live filesystem
[01:52] <CIA-3> ubiquity: (other than / and /boot, which already have their own fudge factors) for
[01:52] <CIA-3> ubiquity: the purposes of the partition-too-small check (LP: #298318).
[02:10] <Haegin> Hey, I have just installed jaunty (twice) and noticed that certain parts of the installer don't seem to honour the keyboard layout chosen at the start of the install process
[02:11] <Haegin> In particular the user name and password fields were qwerty when the previous screens had been in dvorak (though I might not have actually checked that come to think of it)
[02:14] <cjwatson> not bug 337998 by any chance?
[02:14] <cjwatson> Haegin: if it's not that bug, please run the installer with 'ubiquity -d' and get us /var/log/installer/debug
[02:14] <cjwatson> and /var/log/syslog too
[02:16] <Haegin> Ok, it isn't that bug as far as I can tell
[02:17] <Haegin> I also had the same old problem with grub that seems to have plagued the last 3 or 4 releases
[02:20] <Haegin> and I doubt I will be able to get those bug reports as it now boots to a blank screen
[02:20] <cjwatson> you mean multiple disks?
[02:20] <Haegin> yup
[02:21] <cjwatson> yes, we now believe that to be unfixable except by adding UI to let you control it :-(
[02:21] <cjwatson> which is a right pain
[02:21] <Haegin> somehow it gets confused about where grub should install to and I have to reboot and rerun grub-install manually :(
[02:21] <cjwatson> Haegin: did you select the dvorak keyboard layout at the CD boot menu, or did you select it in the installer?
[02:21] <cjwatson> Haegin: and what CD boot menu option did you use - "Try Ubuntu" or "Install Ubuntu"?
[02:22] <Haegin> I was using the alternate CD and selected it in the installer. I didn't realise there was a keyboard layout option at the menue
[02:22] <Haegin> s/e^//
[02:22] <Haegin> *$
[02:23] <cjwatson> ... alternate? oh. ok
[02:23] <Haegin> Old habits die hard
[02:23] <cjwatson> I wonder if the keyboard layout is getting reset when console-setup is installed into the chroot
[02:23] <cjwatson> that would be annoying
[02:24] <Haegin> I'll check it again as it looks like it needs reinstalling a third time...
[02:24] <cjwatson> no, I wasn't objecting to you using alternate, I was just in ubiquity mode tonight and therefore had to adjust
[02:24] <Haegin> ah ok, sorry - I should have said
[02:24] <cjwatson> if the keyboard layout is changed at that point, that could explain some other slight weirdness I've encountered lately
[02:25] <cjwatson> that said, even if it pokes the keyboard layout into the kernel again, the installer integration is supposed to arrange that it pokes in the *same* layout
[02:25] <cjwatson> Haegin: perhaps you could file a bug on /ubuntu/+source/console-setup just quoting this IRC conversation?
[02:26] <cjwatson> maybe minus the unrelated bits about grub
[02:26] <Haegin> sure, I'll just double check it actually does set it to dvorak in the first place...
[02:28] <Haegin> does console-setup get run before or after the hostname is set?
[02:28] <cjwatson> before
[02:28] <cjwatson> specifically, before any point when you might need to type anything non-trivial
[02:29] <Haegin> it was in dvorak mode when I set the hostname and when I labelled a few partitions
[02:29] <Haegin> but it certainly switches to qwerty when I enter the username and a password
[02:32] <cjwatson> that's after base system installation, at which stage console-setup gets installed into /target
[02:32] <cjwatson> this is without proof, but that's overwhelmingly likely to be the point when it breaks
[02:32] <cjwatson> very little else messes with the keyboard layout in any way
[02:33] <cjwatson> Haegin: which layout specifically - US Dvorak?
[02:36] <Haegin> I selected UK dvorak (but not the one with UK punctuation)
[02:38] <cjwatson> reproduced
[02:40] <cjwatson> oh, bah
[02:40] <cjwatson> base-installer (1.92) unstable; urgency=low
[02:40] <cjwatson>   * Call base-installer.d hooks after running debootstrap, for consistency
[02:40] <cjwatson>     with live-installer. (So, pre_install_hooks is run after bootstrap, but
[02:40] <cjwatson>     before anything is installed with apt. So the name still makes a kind
[02:40] <cjwatson>     of sense, if you squint..)
[02:41] <cjwatson> I knew that would break something
[02:43] <Haegin> was it that fix that caused the issue?
[02:45] <cjwatson> yes
[02:45] <cjwatson> do please file a bug, I'll fix it in the morning
[02:45] <cjwatson> (the above wasn't written by me BTW)
[02:46] <Haegin> I might have to file it tomorrow - I'll need to gather the info and I'm going to be crashing as soon as this install is setup updating and installing while I sleep
[02:46] <cjwatson> no need to gather any information
[02:46] <Haegin> oh ok then
[02:46] <cjwatson> just a summary of the above discussion will be entirely fine
[02:47] <cjwatson> "keyboard layout gets reset when console-setup is installed during base system installation" or some such
[02:47] <Haegin> ok, what project is it?
[02:47] <charlie-tca> cjwatson: still got the error with the suggested change to /lib/partman/commit.d/30parted
[02:47] <cjwatson> https://bugs.launchpad.net/ubuntu/+source/console-setup/+filebug
[02:47] <cjwatson> (I might reassign it, but that will do)
[02:48] <cjwatson> charlie-tca: bah, ok, thanks for trying. I can't dive into it now since I need to sleep
[02:48] <charlie-tca> Sorry for being gone so long.
[02:48] <charlie-tca> Okay, I am going to try to get the monitor log yet
[02:49] <cjwatson> charlie-tca: what you could also try instead of running the monitor is: find the udevd process; kill it (yes, really; just make sure nothing else is happening); run 'UDEV_LOG=err udevd --debug >udev.log 2>&1'; run through partitioning as before; extract udev.log
[02:49] <cjwatson> (using the same scp technique as before)
[02:50] <charlie-tca> Okay, I'll try to get that.
[02:50] <cjwatson> charlie-tca: that's a bit more effort, but it will get us information about what udevd is running as well as what messages it received (which is basically what monitor tells us)
[02:50] <cjwatson> I'd be surprised if Keybuk couldn't figure it out given that
[02:50] <charlie-tca> I got a couple of hours, so I'll do what I can then
[02:52] <cjwatson> thanks
[02:52]  * cjwatson goes to snooze
[02:56] <Haegin> cjwatson: reported as bug 340308
[04:36] <CIA-3> casper: TheMuso * r585 trunk/ (3 files in 3 dirs):
[04:36] <CIA-3> casper: * scripts/casper-bottom/30accessibility && ubiquity-hooks/30accessibility:
[04:36] <CIA-3> casper:  - Adjust sudoers file to allow ORBIT_SOCKET_DIR, XDG_SESSION_COOKIE and
[04:36] <CIA-3> casper:  GTK_MODULES environment variables through to root, for v2, v3, and
[04:36] <CIA-3> casper:  braille profiles. This allows users to use administrative GTK/GNOME
[04:36] <CIA-3> casper:  applications executed by gksudo with accessibility tools like orca.
[04:39] <CIA-3> casper: TheMuso * r586 trunk/debian/changelog: releasing version 1.160
[09:19] <juanje> hi guys
[09:21] <evand> hello
[09:23] <cjwatson> Haegin: thanks
[09:24] <juanje> I'm working with a frontend for Ubiquity on Guadalinex (actually a wrapper of the gtk_ui) and I was working on earlier versions of Ubiquity (at least for Guadalienx editions) is there anything I can help with the Ubiquity? If I can give a hand on anything just tell me :-)
[09:27] <cjwatson> send patches for bugs :-)
[09:27]  * evand indeed, was just typing that :)
[09:27] <juanje> cjwatson:  is there any channel about casper?
[09:28] <cjwatson> this one is the best there is
[09:28] <juanje> cjwatson: hehe, ok, I was checking (and I will)
[09:29] <juanje> cjwatson: ok, because I woking in some things about casper and I like to know if there is any posibility yet to have any in jaunty
[09:30] <juanje> cjwatson: for ejample the bug #337723 (The SSL certificate is the same in any Live box) which has branch with proposed solution
[09:32] <cjwatson> any reason it's private? I can't even see it myself
[09:32] <juanje> ups
[09:32] <juanje> I don't know exactly why. I guess is because I put the check for a securrity issue
[09:33] <juanje> now is public
[09:33] <juanje> sorry
[09:33] <cjwatson> thanks
[09:34] <juanje> cjwatson: other are things like having some English path fixed (/home/$USERNAME/Destktop) so in other languages mess with the XDG names
[09:34] <juanje> I'm working on that right now (I was about to put the bug, but I didn't yet...)
[09:35] <cjwatson> 337723 should definitely be fixed; I'm looking at your branch right now
[09:35] <cjwatson> as for /Desktop I'm less sure about that. I think for the Ubuntu live CD it's always /Desktop regardless of language, and xdg-user-dirs might move translated directories around at login
[09:36] <cjwatson> I'm be OK with merging a patch for that if it were careful to deal with both possibilities
[09:36] <davmor2> cjwatson: after you've sorted that did you have any joy reproducing the "races" issue?
[09:36] <cjwatson> davmor2: no :-(
[09:36] <cjwatson> 02:49 <cjwatson> charlie-tca: what you could also try instead of running the monitor is: find the udevd process; kill it (yes, really; just make sure nothing else is happening); run 'UDEV_LOG=err udevd --debug
[09:36] <cjwatson>                  >udev.log 2>&1'; run through partitioning as before; extract udev.log
[09:36] <cjwatson> 02:49 <cjwatson> (using the same scp technique as before)
[09:36] <cjwatson> davmor2: if you can manage that, it'd help
[09:38] <davmor2> cjwatson: I'll have a look at it in a bit as soon as I know I got todays images, hopefully they'll install this time :)
[09:39] <davmor2> I'm guessing the bits between quotes should all be on one line
[09:39] <juanje> cjwatson: I was working with xdg-dirs-update to have the right final XDG-* vars avaibles in casper so we can use them. We (in Guadalinex) had before to change by hand the directory because the xdg-user-dirs moving thing wasn't working. But I'll check again before keep working
[09:39] <cjwatson> yes
[09:40] <CIA-3> casper: cjwatson * r587 trunk/ (scripts/casper-bottom/22sslcert debian/changelog):
[09:40] <CIA-3> casper: Regenerate SSL certificate at boot so that it isn't the same for all
[09:40] <CIA-3> casper: live CD users (LP: #337723).
[09:40] <cjwatson> that merges your branch, thanks; I'll just tweak it a little
[09:40] <juanje> cjwatson: great :-) Thanks
[09:41] <CIA-3> casper: cjwatson * r588 trunk/scripts/casper-bottom/22sslcert: use sentence case for progress messages
[09:43] <CIA-3> casper: cjwatson * r589 trunk/scripts/casper-bottom/22sslcert: don't break if ssl-cert is not installed in /root
[09:45] <evand> yay, autorun.inf on the latest daily-live is fixed.
[09:45] <davmor2> evand: :) Yay \o/
[09:47] <CIA-3> base-installer: cjwatson * r354 ubuntu/debian/ (bootstrap-base.postinst changelog):
[09:47] <CIA-3> base-installer: Revert Joey's patch to call base-installer.d hooks after running
[09:47] <CIA-3> base-installer: debootstrap, which broke console-setup's expectation of being able to
[09:47] <CIA-3> base-installer: insert its configuration file into /target before console-setup is
[09:47] <CIA-3> base-installer: installed by debootstrap (LP: #340308).
[09:54] <CIA-3> base-installer: cjwatson * r355 ubuntu/debian/changelog: releasing version 1.98ubuntu3
[09:57] <juanje> cjwatson: Well, seens xgd-user-dirs makes its job, but in Spanish enviroment you have then "Escritorio" pointing to "~/Desktop" in nautilus, it is not moved, just virtualy liked, so in some views you see "Escritorio" and in others "Desktop" and in the terminal you have just "~/Desktop". I'll fill a bug about it, ok?
[10:09] <cjwatson> juanje: well, that sounds more or less as desired actually. It's much *easier* when the filesystem paths stay the same.
[10:10] <cjwatson> I've been trying to campaign against having the filesystem paths changed for some time; it's better when they stay the same but the presentation layer takes care of it (I don't count terminals among presentation layers)
[10:11] <cjwatson> if I had my way it would be called ~/dsk/ or ~/.desktop/ or something so that it was out of the way and not expected to have an intelligible name
[10:12] <juanje> cjwatson: well, then the problem it's the layers, because nautilus itself get lost some times with those paths. I can see in Jaunty in one view Desktop instead of Escritorio and then Escritorio in other...
[10:15] <cjwatson> bug in nautilus, but not in the directory name, imo
[10:15] <cjwatson> changing those directory names just breaks things
[10:15] <juanje> cjwatson: yeah, probably....
[10:19] <cjwatson> evand: OK if I do a quick ubiquity upload for alpha-6?
[10:19] <CIA-3> ubiquity: cjwatson * r3084 ubiquity/ (d-i/manifest debian/changelog):
[10:19] <CIA-3> ubiquity: Automatic update of included source packages: choose-mirror 2.27ubuntu4,
[10:19] <CIA-3> ubiquity: clock-setup 0.97ubuntu3, partman-partitioning 64ubuntu5.
[10:20] <evand> sure thing
[10:20] <cjwatson> righto
[10:20] <CIA-3> usb-creator: evand * r85 usb-creator/setup.cfg: Re-enable i18n.
[10:20] <cjwatson> installer translations should be imported into Rosetta fairly soon for jaunty, BTW
[10:20] <cjwatson> (belatedly, but ...)
[10:21] <evand> indeed, I saw that LP Answers request.  Thanks for the heads up though.
[10:26] <CIA-3> ubiquity: cjwatson * r3085 ubiquity/debian/changelog: releasing version 1.11.16
[10:29] <davmor2> evand: did you manage to fix the map from install?
[10:30] <evand> davmor2: not completely yet.  Still working on it.
[10:30] <davmor2> np's I was gonna test it if you had :)
[10:31] <davmor2> cjwatson: should I run the udev-debug as earlies as possibly?
[10:31] <davmor2> possible even?
[10:32] <cjwatson> davmor2: no, when the first partitioner question appears, switch to tty2 and follow the steps I gave
[10:32] <davmor2> right so not before then
[10:32] <davmor2> no probs
[10:32] <cjwatson> no, it'll just produce vast quantities of junk if you do :-)
[10:34] <davmor2> cjwatson: so you don't want it running from host name then, like last time?
[10:36] <cjwatson> nope
[10:36] <cjwatson> won't hurt if you do, but it's more than we need
[10:37] <davmor2> cjwatson: it a relatively safe place to kill udev though I'd of thought :)
[10:37] <davmor2> installing alt now
[10:39] <cjwatson> it doesn't make a difference since you're starting it back up again immediately, and nothing will happen while the UI's waiting for input from you
[10:39] <davmor2> true :)
[10:40]  * davmor2 scrolls back up to find command
[10:40] <CIA-3> casper: cjwatson * r590 trunk/debian/changelog: releasing version 1.161
[10:53]  * davmor2 slaps self on head for hitting the wrong install method :( and starts again
[11:06] <CIA-3> usb-creator: evand * r86 usb-creator/ (debian/changelog usbcreator/backend.py): Support SD cards and other removable devices. Thanks Eric Butler!
[11:06] <evand> FireRabbit: ^ Thanks for your patch.  I reworked it a bit.
[11:08] <lool> Hi folks, Xorg crashed during an install of UNR on an EeePC701SD here; gdm restarted a session; I'd like to collect enough debug info for a bug
[11:09] <lool> I'm checking /var/log/installer/debug and it has various warnings, an assertion error in the gtk frontend, and then "ubiquity: Fatal IO error 104"
[11:09] <lool> Which I think is gtk failing to talk to Xorg
[11:10] <lool> It crashed just after setting the time from NTP during install
[11:10] <lool> Oh I wonder whether the time changed confused Xorg
[11:10] <lool> I see negative times in the Xorg.0.log.old
[11:11] <lool> [626609.129118] (EE) PreInit returned NULL for "Video Bus"
[11:11] <lool> Sorry "[-26609.129118]" not "[626609.129118]"
[11:21] <lool> I think it boils down to Xorg crashing when time goes back, albeit I'm not sure which part of Xorg
[11:33] <lool> Is there a way to resume the install?
[11:33] <cjwatson> sounds like you're right about Xorg; you should be able to restart the installer by just running ubiquity
[11:37] <lool> BTW folks the new timezone selection is nice
[11:41] <evand> thanks.  Just trying to fix the plotting of the timezone points on that.
[11:45] <davmor2> hey evand when does the new colour scheme go in is that a pre ui freeze job?
[11:48] <evand> davmor2: it just went in with cjwatson's ubiquity upload.  I'll have to shoot an email to the documentation team.
[11:54] <davmor2> cjwatson: http://www.davmor2.co.uk/udev.log
[11:54] <cjwatson> thanks, Scott and I are in the process of figuring out a fix
[11:55] <davmor2> for some unknown reason though it doesn't lock up when you restart udev or is that the debug bit?
[11:56] <cjwatson> it's a race condition
[11:56] <cjwatson> debugging slows one side of the race down and therefore can easily have the result of making it "go away"
[11:56] <cjwatson> doesn't make the data invalid though; indeed it confirms what we'd seen from another log
[11:57] <cjwatson> the remove is racing with a change event that runs vol_id on the same device
[11:59] <davmor2> cjwatson: Okay.   So what's happening in laymen's terms then is udev is running vol_id and therefore accessing the partition you're trying to write too so it fails, is that about right-ish?
[12:00] <davmor2> just trying to understand things better :)
[12:02] <davmor2> install fails anyway do too compiz :( meh
[12:08] <cjwatson> that's correct except "accessing the partition you're trying to remove" not write to
[12:08] <cjwatson> libparted needs to tell the kernel to reread the partition table
[12:09] <cjwatson> it does this by telling the kernel to remove its internal memory of all the old partitions, and then telling it to add the new ones
[12:09] <cjwatson> (some of these partitions may of course be identical to ones that were there before)
[12:11] <tjaalton> cjwatson: I attached the logs to bug 334278, but looks like you already know what's happening
[12:11] <cjwatson> well, we think so
[12:11] <cjwatson> although we've thought that before :)
[12:12] <lool> persia: I filed a bug for the syslinux main menu on the UNR images: "Check disc for defects" should also be fixed like the usplash shutdown prompt to press enter
[12:12] <cjwatson> yours is the first confirmation on LVM
[12:12] <lool> persia: 309396; you're sub-ed
[12:12] <lool> Err no, that's not the right id
[12:14] <davmor2> cjwatson:  Ah okay I'm with you now :)
[12:15] <davmor2> cjwatson: if you get a fix and can respin before say 2 I can retest it for you :)  However I'm off to oxford at about 3
[12:16] <persia> lool, 309396 is currently waiting on the SRU process.  The fixed syslinux is in -proposed.
[12:17] <cjwatson> davmor2: we're still exploring, so I think before 2 is unlikely
[12:17] <persia> lool, Oh, you mean the text change for USB/SD/CD/DVD/etc. ?
[12:17] <davmor2> cjwatson: no probs
[12:19] <lool> persia: Yes
[12:20] <lool> Grmpf the wifi here ate my bug report
[12:20] <persia> lool, I'm not sure it's really the same bug.  Maybe part of 290696, or maybe a new bug.
[12:20] <lool> ah no
[12:20] <cjwatson> beware that that text is translated in gfxboot
[12:21] <lool> persia: 340440
[12:21] <lool> persia: I think it's the same type of bug, but in a different place
[12:21] <cjwatson> so common text suitable across the board would be nice; if not, be careful to change translations
[12:21] <persia> Right.  New bug is probably best.
[12:21] <cjwatson> err, add translatable messages
[12:21] <cjwatson> "install media" => "installation media" but that might be getting quite long
[12:21] <cjwatson> if it fits, that could work
[12:23] <lool> persia: I also filed #340438, I don't know whether we simply miss stuff in the image or whether it's some bug with my hw TBH
[12:23] <lool> It's the language prompting appearing briefly, but disappearing immediately
[12:23] <cjwatson> for the record such bugs should be filed on the gfxboot-theme-ubuntu package in Ubuntu
[12:24] <lool> cjwatson: Aha, thanks
[12:24] <persia> And that looks suspiciously like a dup of 309396
[12:24] <lool> persia: So you see the menu with the fix?
[12:24] <persia> lool, Can you try running any of hardy-proposed, intrepid, or jaunty syslinux on the image pre-dd?
[12:25] <persia> Yes.
[12:25] <lool> persia: Let's recheck when the update is installed and the next daily is built
[12:25] <persia> Well, then you get an incomplete :)
[12:25] <lool> persia: Hmm sure, Tobin has it, will ask him
[12:26] <lool> persia: Tobin is running intrepid; it's working fine in intrepid's syslinux you say?  I'll ask him
[12:26] <StevenK> Just re-syslinux the .img
[12:26] <persia> No, it needs to be re-syslinux'd.  See the updated description in 309396
[12:30] <lool> persia: I told him to re-syslinux the USB key or the image
[12:30] <lool> and to join here
[12:31] <cjwatson> it should be possible to tell the difference visually between "language menu disappeared mysteriously but gfxboot is still running" and "gfxboot crashed, back to syslinux"
[12:31] <cjwatson> if you show me a photograph I can tell you which is which straight off
[12:31] <persia> Indeed.  The easy way is whether the first menu option is truncated.
[12:31] <persia> (especially for the long string "Ubuntu Netbook Remix".
[12:32] <persia> cjwatson, Now that it doesn't serve as a reminder anymore, where ought the string truncation when we aren't using gfxboot be fixed?
[12:32] <persia> Is that in syslinux itself?
[12:33] <cjwatson> no, debian-installer (build/boot/x86/menu.cfg)
[12:34] <cjwatson> or possibly stdmenu.cfg or one of the others
[12:34] <lool> So I also have another bug, Advanced Options menu is empty, but I'm waiting to see it after the syslinux update
[12:34] <persia> Thanks for the pointer.  I'll take a look about (although given that it's typically masked, I'll not be in a hurry).
[12:34] <persia> lool, That's also 309396.
[12:35] <cjwatson> masked?
[12:35] <cjwatson> oh, gotcha
[12:35] <persia> Because under normal circumstances we *are* using gfxboot
[12:35] <lool> persia: aha
[12:35] <cjwatson> if you're seeing an Advanced Options menu, you are *definitely* encountering 309396
[12:35]  * persia dupes 340348
[12:37] <lool> persia: Yes, new syslinux fixes both bugs; thanks
[12:38] <lool> Ah dupped already
[12:38] <persia> lool, If you happen to have used the hardy-proposed syslinux, please add a note to 309396.  Otherwise, just remember to run syslinux until that hits the infrastructure.
[12:38] <lool> cjwatson: Yes exactly, no advanced options anymore after running sysliniux
[12:38] <lool> persia: No, the intrepid one
[12:38] <persia> Oh well.  We knew that worked :)
[12:38] <lool> So I had another bug
[12:38] <lool> Which is likely fixed as well
[12:39] <lool> When I press "enter" on this syslinux screen, I wouldn't get any feedback for a while
[12:39] <lool> I think it's the same bug
[12:40] <persia> That's related to oddities between keymappings and the base syslinux menu.  I've encountered it sporadically, but nothing I could track down or reliably reproduce on alternate HW/alternate environments.  Given that we typically use gfxboot, it's not usually visible.
[12:40] <persia> Note that the things you've found *are* bugs, they just aren't supposed to be end-user visible, so aren't considered very important (although 309396 makes them visible today).
[12:41] <lool> Understood
[12:41] <lool> So otherwise, I had relatively simple bugs
[12:42] <lool> The installer part was fine except for screen size issues, an issue with simple passwords, and a focus issue
[12:43] <persia> Issue with simple passwords?  Which image?
[12:45] <lool> persia: UNR
[12:45] <persia> What sort of issue?  There's an intentional change to expect strong passwords, and the UNR image oughtn't have any preseeding that affects password choice.
[12:45] <lool> persia: So if you enter a too simple password, you get a dialog
[12:46] <StevenK> Then pick a better password?
[12:46] <StevenK> That strikes me as a feature
[12:46] <lool> persia: if you agree you need to change it and go changing it, you get *another* red warning near the password field
[12:46] <lool> StevenK: I wasn't done explaining the bug
[12:46] <persia> evand, Is that intentional behaviour?
[12:47] <lool> It's not because what red warning says is "You entered an empty password, which is not allowed."
[12:47] <lool> And it was certainly not a blank password
[12:47]  * StevenK regenerates the UNR daily
[12:47]  * lool lunch &
[12:53] <persia> Oh.  I see.  That's because passwd/user-password is set to "" when it's weak, and triggers it that way.
[12:54] <persia> Not sure how to get back to STATE=6 in a sane way without a blank password, but perhaps there's something that needs tweaking in the UI?  Maybe a new error state?
[12:55] <persia> Ah.  "# TODO would be better to extend state machine" :)
[12:56] <persia> lool, ^ Your bug is known, but needs more thought as part of the password-strength implementation.
[12:56] <cjwatson> err, not known, I hadn't thought about the empty password interaction
[12:57] <persia> Sorry then.  I thought the TODO was because it could cause issues.
[12:57] <cjwatson> just inelegant
[12:59] <cjwatson> it's pretty weird that you get another warning there
[12:59] <cjwatson> lool: can you file a bug on ubiquity about this?
[13:01] <persia> Won't it just bounce to STATE=6, and then hig user-setup/password-empty, or should it be catching on the request for passwd/user-password?  (I'm a little unclear how many times d-i components can loop behind ubiquity)
[13:01] <persia> s/hig/hit/
[13:02] <cjwatson> but state 6 should then sit and wait for the password to be entered
[13:02] <cjwatson> actually the problem may be that ubiquity thinks it's finished
[13:03] <cjwatson> http://paste.ubuntu.com/129287/ might do it
[13:05] <persia> Quite likely, yes.
[13:06]  * persia tries
[13:25] <persia> cjwatson, Confirmed that your patch fixes this: the "You entered an empty password ..." text no longer appears with manual addition of the change to /usr/lib/ubiquity/ubiquity/components/usersetup.py on an image.
[13:25] <persia> (and I can reproduce without the change)
[14:00] <davmor2> charlie-tca: morning dude
[14:00] <charlie-tca> good morning
[14:04] <kirkland> cjwatson: i have updated https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/327348 with some new information for you
[14:14] <cjwatson> kirkland: ok, will try. vnc is a lot less convenient for my typical use, which is why I don't generally use it
[14:15] <persia> kirkland, I wonder which is the correct behaviour.  While I also nearly always use SDL, I notice that with vinagre, alt-tab doesn't let one switch easily to other windows on one's local desktop.
[14:15] <kirkland> cjwatson: understood, and I agree
[14:15] <kirkland> cjwatson: persia: i don't use vinagre/vnc either
[14:15] <kirkland> it's an issue that upstream is aware of
[14:16] <persia> kirkland, Could perhaps SDL clear all currently active pressed keys on focus loss?
[14:16] <kirkland> it's a fairly complex operation, trying to determine when the guest "should have received" an alt/shift/ctl up event and the focus has already been shifted away
[14:17] <persia> Is it ever harmful to send an extra alt/shift/ctrl/meta/super up?
[14:17] <kirkland> persia: cjwatson: as I said in the bug, they are working on heuristics to help determine this
[14:17] <kirkland> as you might imagine, caps-lock/num-lock/scroll-lock present the same problems
[14:17] <persia> Most apps don't respond too carefully to key release events.
[14:18] <persia> Well, similar, but I think it's less intuitive that one needs to press "Alt" to get the release than that one needs to toggle the locks separately.
[14:19] <kirkland> persia: i'm curious....
[14:19] <kirkland> persia: you're saying that vinagre does not work well for you, on alt-tab?
[14:20] <persia> Right.  When I press Alt-Tab with focus on vinagre, it absorbs the key event, and passes to the guest.
[14:20] <persia> This makes sense, and might even be correct, but it makes it hard to, say, do parallel editing of a file, or similar.
[14:31] <evand> cjwatson: Can you please review this when you have a moment: http://pastebin.ubuntu.com/129337/
[14:33] <cjwatson> evand: looks plausible if -w /cdrom works as a test
[14:35] <evand> indeed, it appears to.
[14:35] <evand> ok, will commit and upload then
[14:36] <CIA-3> casper: evand * r591 casper/ (2 files in 2 dirs):
[14:36] <CIA-3> casper: If /cdrom is writable, call the diverted update-initramfs and copy
[14:36] <CIA-3> casper: the resulting kernel and initrd to /cdrom/casper (LP: #292159).
[14:39] <persia> On the VFAT images, the initrd.gz seems to be in the root directory, rather than in casper.  Is this an image construction bug, or should the logic verify the target file exists before copying?
[14:44] <CIA-3> casper: evand * r592 casper/debian/changelog: releasing version 1.162
[15:12] <lool> cjwatson: Yup, I had in mind to file a bug anyway, just got distracted by lunch and other discussions
[15:15] <lool> 340549
[16:17] <cjwatson> tjaalton,charlie-tca: I'd hugely appreciate it if you could try the image at http://cdimage.ubuntu.com/tmp/20090310/ (when it arrives; it seems to be taking its own sweet time)
[16:17] <cjwatson> tjaalton,charlie-tca: it should rsync well against the current server image. Sorry I can't do amd64 easily
[16:17] <CIA-3> ubiquity: evand * r3086 ubiquity/ (3 files in 3 dirs):
[16:17] <CIA-3> ubiquity: * Pack the timezone_map in an AspectFrame instead of a regular Gtk Frame.
[16:17] <CIA-3> ubiquity: * Plot the time zone cities using a Miller cylindrical map projection with
[16:17] <CIA-3> ubiquity:  adjustments for the shifted left edge and missing arctic region of the
[16:17] <CIA-3> ubiquity:  map.
[16:18] <cjwatson> tjaalton,charlie-tca: this contains an extra udev patch from Scott to make udevadm settle work a bit harder
[16:19] <evand> ^ That doesn't solve the time zone city placement bug, but the change at least makes the placement more accurate and doesn't worsen as the map grows anymore.
[16:20] <evand> Suggestions welcome on further refinement.  That bug is definitely doing my head in.
[16:23] <cjwatson> http://cdimage.ubuntu.com/tmp/20090310/jaunty-server-i386.iso exists now
[16:25] <cjwatson> evand: you seem to have added the changelog entries to an existing release rather than creating a new one
[16:26] <evand> arrr, my mistake
[16:26] <evand> I'll fix that now
[16:28] <charlie-tca> I'm downloading the image now.
[16:28] <cjwatson> charlie-tca: thanks!
[16:29] <charlie-tca> no problem
[16:29] <cjwatson> 16:00 <cjwatson> slangasek: yes :-( if you care about the details, it's because udevd has inotify watches on devices so that it can update uuids/labels/etc. when they change, so when libparted opens (writably)
[16:29] <cjwatson>                  a block device and closes it later this causes a change event to be scheduled; udevadm settle doesn't make sure that the inotify queue is flushed so if you happen to call udevadm settle before
[16:29] <cjwatson>                  udevd gets round to processing the ...
[16:29] <cjwatson> 16:00 <cjwatson> ... inotify then it won't necessarily wait for udev to be finished, so change events race with rereading the partition table
[16:29] <cjwatson> 16:00 <cjwatson> if you call udevadm settle once udevd has processed the inotify queue and scheduled a change event, it all works fine because *that*'s something that udevadm settle will wait for
[16:29] <cjwatson> 16:01 <cjwatson> Scott has a patch for this which I'm testing
[16:29] <cjwatson> 16:01 <slangasek> you are in a maze of twisty races
[16:29] <cjwatson> 16:03 <cjwatson> some of which, but not all, may sometimes appear to be alike
[16:29] <cjwatson> (from #ubuntu-release)
[16:29] <cjwatson> what I am now hoping is that this is in fact the race you were encountering
[16:29] <charlie-tca> I see. Thanks for that info
[16:30] <cjwatson> it's entirely possible that we spent the day fixing yet another race
[16:30] <cjwatson> that isn't actually the one you're hitting :-/
[16:30] <cjwatson> but hopefully that isn't the case
[16:31] <CIA-3> ubiquity: evand * r3087 ubiquity/debian/changelog: Whoops. Create a new version for the changelog entry.
[16:35] <charlie-tca> I hope you are right.
[16:41] <CIA-3> ubiquity: cjwatson * r3088 ubiquity/ (debian/changelog ubiquity/components/usersetup.py):
[16:41] <CIA-3> ubiquity: Stop the user-setup component from believing it's done after the user
[16:41] <CIA-3> ubiquity: selects "go back" at a weak password dialog (LP: #340549).
[16:41] <cjwatson> evand: I'm sure that timezone map change must have closed some bugs :-)
[16:44] <evand> cjwatson: It's not accurate enough yet (London is sitting in the English channel), so I'm hesitant to close any bugs. :/
[16:45] <evand> It's just technically accurate for the projection and adjustments for the map position and missing arctic section, unless I'm missing something.
[16:46] <evand> I'll have to further refine it without making some points accurate and others wildly inaccurate somehow.
[16:47] <FireRabbit> evand: glad i was able to help, thanks for finishing it.
[16:47] <evand> sure thing :)
[16:51] <FireRabbit> evand: quick question, i see you removed the storage.removable check, does that mean any usb hard drive will show up?
[16:53] <evand> Possibly.  But it's the only way to get full SD card support as built in readers apparently show up with storage.removable = False
[16:54] <evand> Actually, we could just say if bus == usb and storage.removable
[16:55] <FireRabbit> i was thinking it might actually be useful, but perhaps not a good thing to enable by default without a big warning
[16:58] <evand> my concern has always been that people accidentally use it on the wrong drive, but I guess enough people would want to install to external USB drives and we provide enough information to the user to discern between drives that it's probably ok as-is.
[17:00] <charlie-tca> cjwatson: same error on partitioning
[17:00] <cjwatson> ARGH
[17:00] <charlie-tca> device or resource busy
[17:00] <cjwatson> oh, hang on
[17:00] <charlie-tca> I did add the logs from another install to the bug, including the udev log
[17:00] <cjwatson> I bet you didn't have the settle before commit, since that was something I asked you to apply by hand
[17:01] <charlie-tca> aw, crap
[17:01] <charlie-tca> I just ran the cd
[17:01] <cjwatson> this time round, could you edit /lib/partman/commit.d/30parted before the partitioner starts and put 'update-dev --settle' right above 'open_dialog COMMIT'?
[17:01] <cjwatson> not your fault, I should have remembered to say that
[17:01] <cjwatson> tjaalton: ^- same goes for you if you're testing this
[17:02] <charlie-tca> Well, sure. I will have to set it up and do it again.
[17:02] <cjwatson> my apologies
[17:04] <charlie-tca> no problem, I probably just made a mistake, myself
[17:09] <FireRabbit> evand: oh was wondering, will this be in Jaunty or is it too late for that?
[17:12] <evand> FireRabbit: I'll speak with the release manager about it and see what he says
[17:13] <FireRabbit> okay
[17:53] <cjwatson> charlie-tca: any luck?
[17:54] <charlie-tca> Just adding the commit line
[17:56] <charlie-tca> error again
[17:57] <charlie-tca> added 'update-dev --settle' to /lib/partman/commit.d/30parted ; no luck
[17:57] <cjwatson> is it *exactly* the same error?
[17:58] <charlie-tca> Let me look at the logs
[17:58] <cjwatson> charlie-tca: I think what I'll need is a repetition with the same hack, plus a log after killing and restarting udevd in the previously prescribed manner
[17:59] <charlie-tca> Apparently not, hitting ignore let it keep going, and it only gave the error on the extended partition, sdc2
[17:59] <charlie-tca> It never gave any error for sdc1 or sdc5 or sdc6
[18:00] <CIA-3> ubiquity: evand * r3089 ubiquity/ (debian/changelog ubiquity/timezone_map.py ubiquity/tz.py):
[18:00] <CIA-3> ubiquity: Account for daylight savings when highlighting a region in the
[18:00] <CIA-3> ubiquity: timezone_map (LP: #335355).
[18:01] <charlie-tca> okay, I'll do it again, and get the udevd log with the rest
[18:01] <cjwatson> charlie-tca: sure, I'm not surprised that it only affects one partition
[18:01] <cjwatson> once this error occurs we have lost
[18:02] <charlie-tca> It was giving the errors on all the partitions. Is that progress?
[18:07] <cjwatson> no, it's luck ;-)
[18:08] <cjwatson> you can't compare two instances of a race condition and say that one has improved because it was a little less serious
[18:08] <cjwatson> of course it's possible that this means there are two races and we fixed one of them
[18:10] <charlie-tca> okay, I'll just get it set and run it all again
[18:27] <cjwatson> this is going to be a long night, I can tell :-/
[18:29] <tjaalton> cjwatson: ok, I'll try it out tomorrow
[18:47] <cjwatson> charlie-tca: any luck?
[18:48] <charlie-tca> Got the warning, and it is continuing. Can I interupt the install to get the logs?
[18:49] <cjwatson> just switch to tty2 and copy stuff out
[18:49] <cjwatson> there's no need to wait for it to complete
[18:49] <charlie-tca> It went right to "Installing the base system" after the warning
[18:50] <cjwatson> actually it's really easier if you just stop at the warning and copy the logs out right then, rather than continuing
[18:50] <cjwatson> continuing doesn't tell us anything new
[18:50] <cjwatson> and it makes the logs bigger and noisier :)
[18:51] <charlie-tca> Trying to scp now
[18:54] <charlie-tca> attaching to the bug
[18:55] <charlie-tca> bug 340188
[18:55]  * cjwatson adds a section on partition table problems to Installer/FAQ
[18:55] <charlie-tca> last three attachments
[18:55] <cjwatson> thanks
[18:57] <charlie-tca> Sorry it takes so long.
[18:58] <cjwatson> charlie-tca: can you confirm exactly when you restarted udev?
[18:59] <charlie-tca> Partition disk screen came up, kill udevd, then select guided partitions
[18:59] <charlie-tca> It is the very first partition screen
[19:00] <cjwatson> ok
[19:00]  * cjwatson tries to figure out why there's only one 'remove' event showing up
[19:10] <cjwatson> oh, of course it wouldn't if the remove *failed*
[19:11] <charlie-tca> Did I screw up again?
[19:11] <cjwatson> not to my knowledge ;-)
[19:12] <charlie-tca> I keep trying to get it right.
[19:20] <cjwatson> I have a theory
[19:21] <cjwatson> (it could be bunnies)
[19:21]  * cjwatson moves to #ubuntu-devel for a wider audience
[19:24] <_MMA_> cjwatson: Any luck on the GTK installer front? Has directfb been fixed up?
[19:25] <cjwatson> not to my knowledge. Somebody was working on it in Debian
[19:25] <cjwatson> it is not a priority for me this cycle
[19:26] <_MMA_> cjwatson: Ok. I'll hope for next cycle. :)
[21:40] <CIA-3> debian-installer: cjwatson * r1059 ubuntu/ (5 files in 2 dirs): Move mainline architectures to 2.6.28-9 kernels.
[21:46] <btm> What generates the initial /target/etc/passwd before user-setup runs?
[21:47] <cjwatson> base-passwd
[21:50] <CIA-3> debian-installer: cjwatson * r1060 ubuntu/ (5 files in 2 dirs): Move ports architectures to 2.6.28-4 kernels.
[21:52] <CIA-3> debian-installer: cjwatson * r1061 ubuntu/debian/changelog: releasing version 20081029ubuntu24
[23:55] <btm> is there a way to pass a udeb into a network install without putting it in the repository (it's mirrored)?
[23:56] <cjwatson> btm: you can fetch it at run-time and install it with udpkg -i, e.g. from a preseed/early_command hook
[23:57] <cjwatson> that might be a viable approach


[07:30] <AlecTaylor> hi
[07:30] <AlecTaylor> What is the standard way of interfacing apt with private sources? - Editing the source.list? - PPAs look interesting, but I also need some commercial ones...
[07:35] <wgrant> AlecTaylor: You can specify credentials separately in /etc/apt/auth.conf
[07:35] <wgrant> Most private repositories just use a basic username and password over HTTPS.
[07:37]  * AlecTaylor has some commercial applications that he wants to distribute over internal apt based servers... as well as some open-source applications that he'd happy to share .debs' of to the world
[07:38] <AlecTaylor> wgrant: So should I have a PPA and an internal server; or is there a more integrated solution?
[07:40] <wgrant> AlecTaylor: Launchpad provides private PPAs as a commercial service.
[07:40] <wgrant> or you could host your own internal apt repository.
[07:51] <AlecTaylor> wgrant: Is it only private; or can I pick and choose what to make public if I go the commercial service option?


[05:05] <kbmonkey> Hope all had a good weekend. Back to the grindstone eh.
[05:07] <superfly> hey kbmonkey
[05:08] <kbmonkey> hey superfly
[05:09] <kbmonkey> I spent the weekend in Newcastle.  Making decent coffee is an art
[08:08] <Kilos> nê
[08:09] <Maaz> Coffee's ready for Kilos!
[08:10] <Kilos> Maaz, thanks bud
[08:10] <Maaz> Kilos: np
[08:18] <Kilos> see ya later need to use fone on other pc
[08:19] <superfly> hi Kilos
[09:46] <nuvolari> lo everyone
[11:06] <nlsthzn> Everyone working hard on this Sunny Monday in ZA land?
[11:17] <superfly> yep
[11:19] <nlsthzn> cool :)
[11:34] <linuxboy> pretending to
[11:35] <nlsthzn> haha
[11:48] <Kilos> hi linuxboy nlsthzn  howzit
[11:50] <nlsthzn> Hi uncle Kilos :)
[11:52] <Kilos> hehe
[11:53] <nlsthzn> Glad to see you back on the net...
[11:55] <nuvolari> lo oom Kilos, linuxboy, nlsthzn
[11:55] <nlsthzn> nuvolari: hiya :)
[11:55] <Kilos> lo nuv gaan dit goed seun
[11:55] <Kilos> grrr
[11:55] <Kilos> nuvolari,
[12:02] <nuvolari> dit gaan goed dankie en met oom?
[12:02] <nuvolari> werk net by alie af :P
[12:02] <Kilos> goed dankie
[12:02] <Kilos> eish
[12:08] <superfly> nlsthzn: the company I work for just released 3 new sites, hence me working hard
[12:13] <nlsthzn> superfly: Working hard is good... I intend trying it out this year :D
[13:03] <Kilos> nuvolari, did you go for the cellc modem
[13:03] <Kilos> Ian asks if the data expires every month or does it carry over
[13:04] <Kilos> or anyone else that can help please
[13:08] <Kilos> brb
[16:23] <Morganvd> evening all
[16:23] <superfly> hi Morganvd
[16:23] <Kilos> hi Morganvd
[16:24] <nlsthzn> Hi *waves*
[16:24] <superfly> anyone recommendations for ISP for uncapped ADSL?
[16:24] <Tonberry> anyone know how to convince ISC DHCPd to listen on a tap device?
[16:24] <Kilos> bad year 2011
[16:24] <superfly> s/anyone/any/
[16:24] <Kilos> ubuntu-za has become like a morgue
[16:25]  * nlsthzn loves uncapped ADSL
[16:25] <Kilos> mweb seems good superfly
[16:25] <Kilos> R219 a month
[16:26] <superfly> Kilos: that's just for 0.3Mbps, I'm going for the big guns, 4Mbps
[16:26]  * nlsthzn hates Telkom's MoNoPoLy
[16:26] <Kilos> hehe well done
[16:26] <Kilos> superfly, do you have um
[16:26] <Kilos> er
[16:26] <Kilos> the newish guys
[16:26] <nlsthzn> The most expensive country in the middle east is still twice as cheap than SA :/
[16:27] <superfly> Kilos: eh?
[16:27] <Kilos> sec trying to think
[16:27] <Kilos> they like competition to telkom
[16:27] <Kilos> neotel
[16:28] <superfly> they're worse than telkom
[16:28] <Kilos> sorry , took a while
[16:28] <Kilos> eish
[16:28] <superfly> yeah, just when we thought you couldn't get worse
[16:28] <nlsthzn> But isn't neotel partially owned by Telkom>
[16:28] <nlsthzn> ?
[16:29] <superfly> no
[16:29] <superfly> not in the slightest
[16:29] <Kilos> http://www.hotfrog.co.za/Products/Uncapped-Adsl
[16:29] <Kilos> look there superfly
[16:30] <Kilos> http://imod.co.za/2010/03/21/south-african-uncapped-adsl-options/
[16:30] <Kilos> there were some adds on the idiot box a while back  but i forget now. sorry
[16:41] <superfly> Kilos: no worries, I'm looking for personal recommendations
[16:41] <Kilos> ah
[16:47] <linuxboy> superfly: mweb
[16:48] <Kilos> confluency, wb
[16:49] <nuvolari> Kilos: nee oom, ek is nog op vodacom
[16:49] <nuvolari> noggie by 'n cell © sim uitgekom nie
[16:49] <Kilos> lol ek het hom gese hy moet die mense vra wat dit verskaf
[16:50] <Kilos> maar daai offer van 2g vir 149 is baie goed
[16:53] <nuvolari> ja... maar as ek net 8kbps gaan kry help dit my niks :P
[16:54] <Kilos> lol. so min
[16:54] <nuvolari> ek dink nie c/© is goed gevestig hier nie
[16:54] <nuvolari> nie eens vodacom is betroubaar hier nie
[16:54] <Kilos> hulle adverteer dan dis wooooosh finig
[16:54] <Kilos> vinig
[16:54] <nuvolari> *vinnig
[16:54] <nuvolari> :P
[16:54] <Kilos> daai ding ja
[16:54] <Kilos> dankie
[19:11] <Kilos> night all sleep tight
[19:31] <kbmonkey> greets everyone
[19:52] <superfly> evening kbmonkey
[19:53] <kbmonkey> hello superfly
[19:55] <Symmetria> sup superfly
[19:56] <kbmonkey> can someone please tell me, if I can get my blog added to the ubuntu ZA planet section, an how? ")
[19:56] <superfly> hey Symmetria
[19:56] <superfly> kbmonkey: have you signed the Ubuntu code of conduct?
[19:56] <Symmetria> hrm
[19:56] <Symmetria> I need to know a good sound card to buy
[19:56] <Symmetria> but something, really really nice
[19:56]  * Symmetria just bought himself a new sound system and wants a sound card to go with it
[19:57] <kbmonkey> superfly: yes I have
[19:58] <kbmonkey> I can point you to my launchpad page if you need
[19:58] <superfly> I haven't bought a sound card in years
[19:58] <superfly> last one I bought was a creative 4D
[19:59] <superfly> kbmonkey: what's your blog url?
[19:59] <kbmonkey> most on-board sound has 5.1 channels so there's no need, unless you want studio recordings
[19:59] <superfly> -_- 3 sec lag
[20:00] <kbmonkey> superfly, it is darknet.co.za - mainly Ubuntu and GNU / Linux based
[20:00] <kbmonkey> I plan to be more active there and here, now that I have DSL :-)
[20:01] <superfly> rss feed?
[20:01] <Symmetria> heh kbmonkey just want something that is really high quality
[20:01] <Symmetria> my new sound system is... not exactly a toy
[20:01] <Symmetria> and would like audio feeds to go with it
[20:01] <kbmonkey> the feed url is http://news.darknet.co.za/feed/ superfly :)
[20:02] <Symmetria> heh got myself a yamaha rx-v567 amp and a full set of kef speakers
[20:03] <superfly> oh yeah, another humble indie bundle fan :-D
[20:03] <Symmetria> huh? :)
[20:04] <superfly> talking about kbmonkey
[20:04] <kbmonkey> The games in the humble bundle are fantastic!
[20:05] <kbmonkey> Symmetria: nice. You plan to do some recording?
[20:06] <Symmetria> kbmonkey nah, its just for my home theater system, am getting a new tv next month as well
[20:06] <Symmetria> I like my AV toys :)
[20:08] <kbmonkey> nice Symmetria :) toys are always good
[20:08] <Symmetria> ok time for a smoke then Im gonna unbox this system and go actually install it :P
[20:08] <Symmetria> this is gonna be a mission :)
[20:09] <Symmetria> lol
[20:09] <Symmetria> the whole system barely fitted in my car :P
[20:09] <Symmetria> put the 2 main speakers on the back seat, the sub on the front passager seat, the tweaters and bookshelves and amp in the boot and JUST made it :)
[20:10] <superfly> kbmonkey: http://news.darknet.co.za/feed/
[20:10] <superfly> ag
[20:11] <superfly> kbmonkey: http://ubuntu-za.org/planet
[20:15] <kbmonkey> thanks superfly!
[20:15] <kbmonkey> I'll buy you a beer one day :-)
[20:16] <superfly> no thanks, I don't generally drink :-)
[20:16] <drubin> superfly: Not even fancy coloured cocktails? :)
[20:17] <superfly> drubin: never had a cocktail in my life, to be honest...
[20:18] <superfly> if I do drink something alcoholic, I'll drink a cider, and I'll only do that if I'm not driving
[20:19] <drubin> hehe
[20:20] <kbmonkey> no problem superfly, I'm a big fan of fruit smoothies myself :-)
[20:21] <superfly> kbmonkey: yeah, that'll work :-)
[20:26] <superfly> hey kbmonkey, how far did you get with using your netbook as a DAW
[20:28] <kbmonkey> well superfly, it worked fine, but you really need lots of screen space
[20:29] <kbmonkey> so it really defeats the purpose as a on-the-go DAW
[20:29] <kbmonkey> unless you carry a second monitor around ;)
[20:29] <superfly> yeah, I got a 1600x900 screen here, works well for audio apps like LMMS and FL Studio
[20:30] <kbmonkey> it did however work great for dj'ing, I used it a few times doing gigs, I used Mixxx to dj
[20:30] <superfly> ok
[20:30] <superfly> I'm not into DJing, just doing a little music making
[20:33] <superfly> *yawn*
[20:33] <superfly> well, it's bed time for me
[20:33] <superfly> night folks
[20:34] <kbmonkey> night superfly.
[21:04] <kbmonkey> huh. My desktop doesn't have a ps2 port. So much for a new keyboard :p


[18:03] <pleia2> nhandler: I should have time late tonight to review the ubuntu-news site preferences side by side, I'll keep you updated
[18:12] <highvoltage> anyone know what's happening with uwn?
[18:28] <pleia2> last update from akgraner and alourie was on monday, they were working on this week's issue
[18:28] <pleia2> not sure beyond that, my week is stupid busy so I couldn't commit to anything
[23:47] <Joeb454> akgraner: ping :)