[09:44] <ogra_> http://www.theinquirer.net/inquirer/news/2186842/canonical-intels-efilinux-ubuntu-uefi-secure-boot
[09:44] <ogra_> "LINUX VENDOR Canonical will drop Grub 2 in favour of Intel's efilinux as its bootloader in order to comply with Microsoft's UEFI Secure Boot."
[09:44] <ogra_> lovely if reporters do proper research :P
[10:12] <CIA-12> ubiquity: cjwatson * r5521 trunk/ (d-i/manifest debian/changelog):
[10:12] <CIA-12> ubiquity: Automatic update of included source packages: clock-setup 0.112ubuntu1,
[10:12] <CIA-12> ubiquity: debian-installer-utils 1.91ubuntu1, flash-kernel 3.0~rc.4ubuntu4,
[10:12] <CIA-12> ubiquity: partman-base 156ubuntu1, partman-basicfilesystems 74ubuntu1,
[10:12] <CIA-12> ubiquity: partman-btrfs 9ubuntu1, partman-ext3 70ubuntu1, preseed 1.51ubuntu1.
[13:31] <CIA-12> ubiquity: cjwatson * r5522 trunk/debian/changelog: releasing version 2.11.7
[15:20] <xnox> cjwatson: should ubiquity/d-i/sources.list include proposed?
[15:23] <cjwatson> If there's anything in -proposed that it needs to pull in
[15:25] <xnox> cjwatson: you are right, nope nothing is needed. I was pondering because kernel keyboard update for the respin went into -proposed.
[15:25] <cjwatson> ubiquity doesn't need to know about the kernel
[15:25] <cjwatson> But d-i will need to build against -proposed for that, yes
[15:26] <xnox> ok
[15:26] <xnox> gotcha
[15:28] <cjwatson> Can't remember if that requires a source change, I'll check when I do it


[17:27] <crimsun_> charlie-tca: I just committed a fix for your 613054
[17:28] <crimsun_> charlie-tca: I'm going to let it stew a couple hours for other devs to test it before I push it
[17:28] <charlie-tca> Thank you
[17:29] <charlie-tca> anything I can do to help?
[17:29] <crimsun_> test it, I think?
[17:29] <crimsun_> it's a very simple change, actually, a one-liner
[17:30] <crimsun_> (flood coming)
[17:30] <crimsun_> [17:30] <crimsun_> --- debian/udev.script  2009-11-06 00:17:14 +0000
[17:30] <crimsun_> +++ debian/udev.script  2010-09-05 15:55:28 +0000
[17:30] <crimsun_> @@ -5,6 +5,6 @@
[17:30] <crimsun_>  (
[17:30] <crimsun_>         DEV_BASENAME="${DEVNAME##*/}"
[17:30] <crimsun_>         N="${DEV_BASENAME#controlC}"
[17:30] <crimsun_> -       exec /sbin/alsa-utils start $N
[17:30] <crimsun_> +       exec /sbin/alsactl init $N
[17:30] <crimsun_> just apply that change to /lib/udev/alsa-utils
[17:32] <charlie-tca> I will give it go
[17:46] <charlie-tca> crimsun_: It does not work on my maverick 386 install
[17:46] <charlie-tca> fails to unmute
[17:50] <charlie-tca> volume drops to 2% and is muted when I boot now


[04:25] <pitti> Good morning
[04:26] <pitti> smoser: infinity reconfigured the VMs to use 4 GB of RAM, to avoid over-committing (that wreaked havoc, as VMs encountered kernel paging errors)
[04:26] <pitti> smoser: three VM qemus still need to be restarted; it's not urgent any more as the total RAM is now sufficient, but I understood he wanted to do it at some point
[04:27] <pitti> smoser: we couldn't do it on Tuesday with a build queue of 500 items or so (glibc + qt), but now things are quiet
[07:19] <doko> jamespage, maven main alarm
[09:55] <LocutusOfBorg1> pitti, simple question: will vivid have systemd by default? I don't see online anything related ATM
[10:00] <seb128> LocutusOfBorg1, http://summit.ubuntu.com/uos-1411/meeting/22401/systemd-transition/
[10:00] <seb128> UOS session today
[10:02] <LocutusOfBorg1> wow thanks!
[10:03] <LocutusOfBorg1> seb128, quick question
[10:04] <LocutusOfBorg1> vivid universe package universe/net/boinc-client requires systemd migration (sysv=True, upstart=False, systemd=False)
[10:04] <LocutusOfBorg1> if you sync it from experimental you fix the issue :)
[10:05] <seb128> LocutusOfBorg1, depending strictly on systemd before it's default seems buggy
[10:05] <seb128> or do you mean the experimental version resolves that?
[10:06] <seb128> what's the question exactly? ;-)
[10:07] <LocutusOfBorg1> yep, I added the service file in the experimental upload
[10:08] <LocutusOfBorg1> I was lookit at the blueprint link See: http://people.canonical.com/~jhunt/systemd/packages-to-convert/ (updated daily).
[10:08] <LocutusOfBorg1> since I do not want to spare anybody's time I already did the file and uploaded on experimental
[10:09] <seb128> LocutusOfBorg1, why not unstable?
[10:09] <LocutusOfBorg1> freeze :/
[10:10] <seb128> isn't 'make it work with the default init system' a value reason to get a freeze exception?
[10:10] <LocutusOfBorg1> don't know :)
[10:11] <LocutusOfBorg1> asking now on release channel
[10:12] <seb128> thanks
 it very much isn't.
[10:13] <seb128> k
[10:13] <LocutusOfBorg1> I can upload anyway, and revert if an RC steps up
[10:14] <LocutusOfBorg1> it is not a major release
[10:23] <pitti> LocutusOfBorg1: right, aiming for it, but it depends on getting more hands on porting upstart-only packages (still ~ 200 to go )
[10:27] <LocutusOfBorg1> pitti, I understand, systemd handles the systemV scripts, but not the upstart ones?
[10:28] <LocutusOfBorg1> what about patching systemd then? :)
[10:29] <pitti> LocutusOfBorg1: to do what? :-)
[10:34] <LocutusOfBorg1> to avoid porting creating 200 service files prior to vivid release :)
[10:34] <LocutusOfBorg1> it will give us a "smoother" transition
[10:34] <LocutusOfBorg1> but maybe most of that 200 packages just needs to be sync'd over from debian I guess
[10:34] <pitti> LocutusOfBorg1: well, there was an alternative proposal to run upstart alongside systemd
[10:34] <pitti> but nobody looked at that
[10:35] <LocutusOfBorg1> I guess you will avoid that ;)
[10:35] <pitti> LocutusOfBorg1: nope; those 200 are mostly the ones where we have heavy ubuntu development/deltas; mostly in the cloud/server/touch space
[10:35] <LocutusOfBorg1> oh... ok
[10:35] <pitti> LocutusOfBorg1: conceptually upstart and systemd are so far apart that it's pretty much impossible to "just run" upstart jobs by systemd
[10:36] <LocutusOfBorg1> anyway creating a .service file is something easy for a person with enough knowledge I guess, I never saw a service file more than 20 lines
[10:36] <LocutusOfBorg1> long
[10:36] <pitti> right, every individual one isn't hard, it's just cumulatively hard due to sheer number
[10:36] <LocutusOfBorg1> anyway, I guess you know what to do, who am I? :)
[10:36] <LocutusOfBorg1> yes of course, 200 is an high number
[10:37] <LocutusOfBorg1> I guess I'll try to help a little bit, but I'm really not a systemd person (at least not now)
[10:37] <pitti> so if you want to help out with submitting missing systemd units (or even just init.d scripts), that'd be greatly appreciated
[10:38] <LocutusOfBorg1> you mean vivid/main packages right? I see 191 left
[10:43] <LocutusOfBorg1> grub-common seems a false-positive, hostname might just need a sync/revert, ifupdown needs a little merge?
[10:45] <LocutusOfBorg1> oh... many of them seems to be sysv=True, so grep "sysv=False" |wc -l returns just 106 entries
[10:45] <LocutusOfBorg1> I hope I'm on the right list http://people.canonical.com/~jhunt/systemd/packages-to-convert/2014-11-13.txt
[10:53] <pitti> right
[10:54] <pitti> jodh_: ^ I think we should really start with that -- if a package has an init.d script, it's fine for now
[10:54] <pitti> then it doesn't block the switch and thus shoudln't be part of the transition
[10:54] <LocutusOfBorg1> yep, 106 seems a better number :)
[10:55] <LocutusOfBorg1> and of the 106 many are still false positive, like "upstart*"
[10:56] <LocutusOfBorg1> or "systemd*"
[10:56] <LocutusOfBorg1> I guess you need to start with sysv=False && systemd=False
[10:57] <LocutusOfBorg1> grep "sysv=False" |grep "systemd=False" |wc -l
[10:57] <LocutusOfBorg1> 91
[10:57] <LocutusOfBorg1> even better
[11:41] <LocutusOfBorg1> Laney, how do you feel about this patch for the transparency problem of gnome.-terminal? https://bug695371.bugzilla-attachments.gnome.org/attachment.cgi?id=274727
[11:41] <LocutusOfBorg1> bug 1292282
[11:41] <Laney> LocutusOfBorg1: what transparency problem?
[11:41] <Laney> -> #ubuntu-desktop maybe
[11:42] <LocutusOfBorg1> well yes
[11:46] <cjwatson> LocutusOfBorg1: grub-common isn't entirely a false positive, I just haven't yet worked out how to do that "run as late as possible to approximate the system being fully booted" thing in systemd
[11:47] <cjwatson> It's not urgent though, as the sysv file should do the job for the time being
[11:47] <LocutusOfBorg1> cjwatson, I meant "also a debian issue" :)
[11:48] <cjwatson> Sure
[12:50] <cjwatson> bdmurray,ev,pitti: ubuntu-rtm has Contents now, would be good to confirm that retraces can now work
[12:56] <pitti> cjwatson: hooray, thanks!
[13:02] <pitti> barry: FYI, autopkgtest 3.8 is now in vivid, that also contains the funny apt fix
[14:02] <jamespage> doko, ack
[14:02] <jamespage> doko, not much time today but will look as soon as I can
[14:22] <barry> pitti: awesome, thanks
[14:40] <smoser> pitti, stgraber i've rebooted host on wolfe
[14:40] <smoser> and restarted your instances there.
[14:42] <pitti> smoser: ack, thanks
[14:45] <stgraber> smoser: thanks
[14:48] <stgraber> smoser: is it just my imagination or did we get a memory downgrade in those VMs?
[14:48] <pitti> might be that infinity reconfigured your's as well
[14:49] <pitti> the intention (from my POV) was to just reduce mem from 8 to 4 GB for wolfe-02 to -09 (the autopkgtest ones)
[14:49] <stgraber> yeah, looks like we got downgraded from 8GB to 4GB, which may be a slight problem for us since we run all our builds in tmpfs as I/Os were horribly slow on there (10min on tmpfs vs 1h30 on disk last time I tested)
[14:51] <pitti> stgraber: I think the wolfe host now has enough RAM left to run your's with 8
[14:52] <pitti> rebooting the autopkgtset ones free'ed 12 GB, and we were under the "64 GB total" line before
[14:55] <infinity> stgraber: What are you building that has such awful I/O characteristics?
[14:55] <stgraber> infinity: tons of debootstraps
[14:55] <infinity> stgraber: In theory, wolfe should be no different than denneed, fisher, and postal, and they perform quite well.
[14:56] <stgraber> usually 3-4 of those in parallel
[14:56] <infinity> stgraber: Ask smoser to start your guests with cache=unsafe
[14:56] <infinity> stgraber: Then watch 'em fly.
[14:57] <stgraber> infinity: yeah, cache=unsafe on the data volume would probably help quite a bit
[14:57] <pitti> infinity: do they all need to have the same size?
[14:58] <pitti> infinity: because we certainly do have the RAM now
[14:58] <infinity> pitti: No, they don't have to be.  He can certainly have bigger ones.
[14:58] <infinity> pitti: But "I like building in tmpfs" is also a lousy reason to eat all the RAM. ;)
[14:58] <pitti> well, who doesn't :)
[14:58] <infinity> Exactly.
[14:58]  * pitti builds nowhere else at home
[14:59] <pitti> also, if we can get the same cache=unsafe hack on "my" wolfes, I wouldn't complain loudly either (and it might even be easier as all VMs use the same config)
[14:59] <stgraber> infinity: well, my concern was that our testsuite and image building scripts do a ton of IOPs so tmpfs obviously make things faster for us and also means we don't hammer the disks for everyone else on the box
[14:59] <stgraber> but cache=unsafe may very well do that too just at a different layer :)
[15:00] <pitti> can you just swap the stickers on the motherboard, so that we have 1 TB RAM and 64 GB disk? should be enough to fit the VM images :)
[15:00] <pitti> (TGIF!)
[15:00] <infinity> As long as no one cares about losing the occasional syslog or whatever, cache=unsafe isn't really all that unsafe on a VM where the base system doesn't change much.
[15:01] <pitti> for my VMs, I don't care at all; if they break, I run my magic script to set up a fresh one
[15:01] <infinity> (Okay, it's horribly unsafe, but if you don't like your data...)
[15:01]  * pitti likes "fast" better than "safe" in this case
[15:05] <stgraber> infinity: well, that's why we've got two disks on those VMs right? I sure don't want to loose data on the main volume, but the data volume I don't care about
[15:05] <stgraber> so setting cache=unsafe for /dev/vdb would be perfectly fine
[15:13] <infinity> stgraber: Do you have a host I can kill and restart to test this?
[15:13] <infinity> s/host/guest/
[15:16] <infinity> stgraber: I hacked up smoser's guest-start script to start the ephemeral image with cache=unsafe, want to test that I did it right.  Just make sure that only sdb is affected, sda pretty much never changes and is a pain to setup so I'd like that one to be properly saved to disk :)
[15:22] <infinity> That looks like it worked (for wolfe-08)
[15:22] <infinity> stgraber: Want to halt 01 for me, or shall I just kill it?
[15:23] <infinity> pitti: Check wolfe-08 seems happy, that's the one I twiddled.
[15:23] <stgraber> infinity: shutting down now
[15:23] <pitti> infinity: yep, already at it
[15:24] <infinity> If this hack makes you guys happy, it's a simple diff to scott's guest-start that just applies cache=unsafe to all eph* images.
[15:25] <infinity> stgraber: 01 should be back.
[15:26] <infinity> smoser: http://paste.ubuntu.com/9007931/
[15:27] <infinity> smoser: That's what I applied to wolfe.
[15:27] <infinity> stgraber: If that's not responsive enough for you, we can give you more RAM too, but I suspect that should be pretty decent.
[15:27] <pitti> infinity: doesn't really feel faster to me (doing another lxc-create), but at least it seems to work
[15:28] <infinity> Well, I suppose it's also possible cache=unsafe is a noop for non-virtio...
[15:28] <infinity> I have no idea.
[15:28] <pitti> eek, this isn't virtio?
[15:28] <infinity> qemu and I, we're not best buddies.
[15:29] <infinity> pitti: No.  virtio is buggy as heck on !x86.
[15:29] <infinity> pitti: This is ibm-vscsi, which is pretty performant, in my testing.
[15:29] <stgraber> root@wolfe-01:/var/lib/lxc# dd if=/dev/zero of=blah.img conv=fsync bs=4M count=1000
[15:29] <stgraber> 1000+0 records in
[15:29] <infinity> But a bunch of VMs all contending for the same disk will hurt any I/O subsystem.
[15:29] <stgraber> 1000+0 records out
[15:29] <stgraber> now to test with a real load
[15:29] <stgraber><PHONE_NUMBER> bytes (4.2 GB) copied, 3.09727 s, 1.4 GB/s
[15:30] <infinity> stgraber: Well, the real test is if unsafe is doing as advertised, and not passing syncs down to the host.
[15:30] <infinity> stgraber: Since that's the slow down for debootstrap/dpkg.
[15:31] <stgraber> infinity: still get 1.5GB/s with conv=sync so it looks like it's ignoring syncs as expected
[15:32] <stgraber> the fs is also mounted with data=writeback for good measure too :)
[15:32] <pitti> I'm running lxc-create under eatmydata, add force-unsafe-io to dpkg, but it still sucks :/ (there is a looong time during debootstrap when eatmydata isn't active)
[15:35] <stgraber> pitti: you could use the download template, that'd at least make that part faster
[15:35] <pitti> stgraber: I tried that a while ago, and there was some reason why it wasn't practical, but I forgot; probably firewalled or so
[15:36] <stgraber> root@wolfe-01:/var/lib/lxc# grep proxy /etc/environment
[15:36] <stgraber> http_proxy=http://squid.internal:3128
[15:36] <stgraber> https_proxy=http://squid.internal:3128
[15:36] <stgraber> then it works fine
[15:36] <stgraber> it may also have been that back then there were no ppc64el images
[15:36] <pitti> ah
[15:36] <pitti> stgraber: or that
[15:38] <pitti> hm, jenkins-slave fails to start now, WTH
[16:13] <stgraber> infinity: test build was about as fast as on tmpfs, so I'm fine with sticking to that
[16:13] <infinity> stgraber: \o/
[16:13] <infinity> stgraber: Did you have two guests that needed this treatment, or just that one?
[16:14] <stgraber> I just have the one
[16:14] <infinity> Kay, cool.
[16:14]  * infinity logs out of wolfe and wanders off.
[16:15] <stgraber> 16min vs 14min and since that's still about 4x as faster than our armhf builder, we're good :)
[16:15] <stgraber> with the previous I/O performances I was getting on wolfe, it was slower than my armhf devboard (which arguably does SATA-3 and uses a SSD) which seemed a bit ridiculous :)
[16:16] <infinity> stgraber: Yeah, I imagine that was just insane I/O contention with every guest on there syncing like crazy.
[16:16] <infinity> stgraber: Since the machine has 9 guests, all of whom pretty much just run dpkg a whole lot.
[16:16] <infinity> stgraber: And qemu/kvm performs very poorly in that scenario with default settings.
[16:16] <stgraber> clearly
[16:19] <infinity> stgraber: The only thing to watch out for with cache=unsafe is that it really is very unsafe.  A poorly-timed crash could mean that filesystem needs reformatting on reboot.
[16:20] <stgraber> which is fine because that's what I do at every reboot anyway :)
[16:20] <infinity> Handy.
[16:20] <stgraber> I never want crap sticking around in /var/lib/lxc
[17:06] <dpm> willcooke, slangasek, shadeslayer, who is doing the developer track summary?
[17:06] <dpm> i.e. the presentation at the end
[17:07] <willcooke> I guess me
[17:08] <dpm> cool, thanks willcooke
[17:10] <dpm> gaughen, and I guess you're presenting the summary for the cloud track?
[17:10] <gaughen> dpm, well actually I have a conflict. trying to see if i can re-arrange it.
[17:10] <gaughen> it's with a partner
[17:11] <dpm> gaughen, thanks. Otherwise, perhaps another cloud track lead can do it? Just let us know
[17:59] <pitti> jodh_: ah, thanks for updating the systemd conversion lists!
[18:00] <jodh_> pitti: np - scripts are here fwiw: http://people.canonical.com/~jhunt/systemd/scripts/
[19:02] <pitti> wgrant: can we move the langpack schedule to produce RTM langpack exports on Tuesday evening or Wednesday early morning?
[19:02] <pitti> ogra_: ^ so when exactly do you want the new packs in RTM? then we can calculate back from that
[19:03] <pitti> about 1.5 h to prepare the sources, upload them, have them build, and propagate through -proposed, and about 6 hours for the export, plus two hours safety margin
[19:04] <ogra_> pitti, as per https://wiki.ubuntu.com/LandingTeam/MilestoneSchedule we are freezing wed. morning (EU time) now ...
[19:05] <pitti> ogra_: does the freeze include the langpacks, or you want to freeze, then export/upload langpacks, to catch the last string changes before freeze?
[19:06] <ogra_> pitti, well, we freeze to be able to do image rebuilds for single fixes ... would eb good if everything langpack realted would be in place when the freeze starts so it doesnt taint tested images that get re-rolled
[19:07] <pitti> sure
[19:07] <pitti> wgrant: so could we kick off RTM exports around Tue 21:00 UTC? then I'd build packs around Wed 05:00 UTC, and we would be ready to build images around 07:00 UTC
[19:07] <pitti> ogra_: ^ does that fit?
[19:09] <ogra_> that sounds good, yeah
[19:09] <pitti> ack; I'll adjust the cronjobs as soon as I get wgrant's ok
[19:10] <jodh_> pitti, slangasek: just fixed and re-run http://people.canonical.com/~jhunt/systemd/scripts/ - outstanding main packages to convert figure is now 77.
[19:10] <slangasek> jodh_: neato, thanks
[19:10] <pitti> wgrant: if that collides with some other exports, I'm happy to move the other stuff around too
[19:10] <pitti> jodh_: yay; can you fix it some more? :-)
[19:10] <slangasek> jodh_: btw, do we know if any of these are packages that just require no-change rebuilds with current debhelper?
[19:11] <pitti> jodh_: ah, and there's things like "upstart" and "mountall" which don't need conversion
[19:11] <slangasek> you mean I don't get to write a mountall systemd unit?
[19:11] <pitti> jodh_: could this grow a "known false positive" blacklist?
[19:11] <jodh_> slangasek: no - it's a very crude script atm :)
[19:12] <jodh_> slangasek: ... like it even shows that upstart and upstart-bin needs conversion so atleast a few false-positives there :)
[19:12] <slangasek> sure
[19:12] <pitti> or ureadahead
[19:13] <slangasek> jodh_: oh, and there's no separation of user session jobs vs. system jobs
[19:13] <pitti> or hostname
[19:13] <slangasek> (indicator-*)
[19:13] <jodh_> pitti: yes, it need to.
[19:13] <jodh_> slangasek: right. still some whittling to do.
[19:13] <slangasek> jodh_: thanks for making this script!  Let us tell you everything that's wrong with it
[19:13] <pitti> oh right, all the indicator bits are session upstart
[19:13] <slangasek> ;)
[19:13] <jodh_> slangasek: yeah, I should be asking you for patches :)
[19:13] <pitti> which is kind of fair, as we need to vet them for signals
[19:14] <pitti> jodh_: is that based on xnox's scripts? ISTR that they spat out quite a bit more
[19:15]  * pitti waves good night
[19:15] <pitti> /qui/quit
[19:15] <pitti> ok, let's try that again :)
[19:37] <jodh_> pitti: no - it's a rewrite in python that uses a local mirror for speed. It's now here: https://code.launchpad.net/~ubuntu-foundations-team/+junk/migration-to-systemd
[23:29] <dannf> i'm looking at a vnc4 upload, rebasing on debian to pull in arm64 support. i noticed that, though it has been rebased since, it is retaining some old ubuntu changelog (<= hardy): http://paste.ubuntu.com/9014774/
[23:29] <dannf> should i follow suit and keep the recent ubuntu entries, or just add a Merge, Remaining changes: entry to the top?


[01:47] <pifreak> How do I get my game into the official Ubuntu software center? IS there a guide or blog about it? Thanks! I bet it's hard, but I hope I can do it some day. It's a free open source C++ game.
[02:04] <valorie> pifreak: the easiest way is to get it into the debian archive
[02:04] <valorie> then it is simply a matter of syncing it over to the Ubuntu archive
[02:05] <valorie> well, a few other paperwork things
[02:08] <pifreak> :)
[02:08] <valorie> debian channels in general aren't here on freenode; they are on OFTC
[02:15] <pifreak> But you think to get into the Ubuntu software center / apt-get Ubuntu repositories, it's doable as long as my software is stable? :D I for some reason assumed it's pretty regulated and they'd never take my software because I'm a noob
[02:16] <pifreak> Thanks valorie! I will look into some debain guides and find a debian-specific IRC if I need further help with creating packages and such. I appreciate the advice!
[02:16] <valorie> great!
[15:32] <sgs> Hi all. I've been maintaining my own repo building software containing some of my own patches and modification. I have been following the "Debian New Maintainers' Guide" https://www.debian.org/doc/manuals/maint-guide/index.en.html. Since Ubuntu 18.04 I started experiencing some problems while building packages:
[15:34] <sgs> I am basically unpacking my archive, cd <package> && dh_make -f ../<archive>
[15:38] <sgs> then in the debian directory modifying control, changelog (sometimes rules) and finally running: dpkg-buildpackage <some options> .... what started happening is that the configure scripts started failing (after 18.04)... if I run the build manually ./configure && make ... everything works fine.
[15:40] <sgs> My question is: Is there any updated tutorial for building .deb packages (not interested in src. packages)? Any other hints and advice are more than welcome.
[22:08] <cjwatson> sgs: I think people are probably going to need to see a full transcript of exactly what you're doing and the failures in order to be able to help.  The fundamentals of how to build binary packages haven't changed.
[22:09] <cjwatson> sgs: So it's probably something like missing build-dependencies or some kind of mistake in debian/rules or similar.
[22:12] <sgs> cjwatson: OK... In a nutshell I am building my own version of the sylpheed client. After running dh_make -f ... in debian/rules I have:
[22:12] <sgs> override_dh_auto_configure:
[22:12] <sgs>     dh_auto_configure -- --prefix=/usr --disable-updatecheck --disable-updatecheckplugin
[22:14] <sgs> After 18.04 build fails with:
[22:14] <sgs> dh_auto_configure: ./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu --libexecdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr
[22:14] <sgs> --disable-updatecheck --disable-updatecheckplugin returned exit code 2
[22:14] <sgs> make[1]: *** [debian/rules:24: override_dh_auto_configure] Error 2
[22:15] <sgs> As far as I can see, the "new arrival" is: --runstatedir=/run
[22:17] <cjwatson> sgs: Can you post the whole build log on paste.ubuntu.com?
[22:17] <cjwatson> It's true that debhelper in 18.04 passes --runstatedir=/run, but only in compat level 11; you would have had to specifically opt into this.
[22:21] <sgs> cjwatson: https://paste.ubuntu.com/p/rSJCCSXTVz/
[22:22] <cjwatson> --runstatedir is not the problem here.
[22:22] <sgs> cjwatson: I don't understand what do you mean by compat level 11. I am sorry, but I am quite new into Debian/Ubuntu pkg.
[22:22] <cjwatson> The thing in debian/compat, which is documented in "man debhelper".
[22:23] <cjwatson> This is the actual problem:
[22:23] <cjwatson> ./configure: line 13484: syntax error near unexpected token `ac'
[22:23] <cjwatson> ./configure: line 13484: `SYLPHEED_ACLOCAL_INCLUDE(ac)'
[22:23] <sgs> cjwatson: When I build sylpheed manually ./configure ...etc --runstatedir=/run is the only option it doesn't recognize.
[22:24] <cjwatson> Translating: your debian/rules runs autoreconf (because debhelper does that automatically as of compat level 10), but you don't have the right build-dependencies for it to be able to regenerate the build system.
[22:24] <cjwatson> Irrelevant, you're changing too many variables there so that's not a valid test.
[22:25] <cjwatson> (Specifically you evidently didn't run autoreconf first ...)
[22:26] <cjwatson> Let's see, just investigating
[22:28] <cjwatson> To fix this particular bug I think you need to add this to debian/rules, to make sure that autoreconf picks up sylpheed's local autoconf bits:
[22:28] <cjwatson> override_dh_autoreconf:
[22:28] <cjwatson>         dh_autoreconf ./autogen.sh
[22:28] <cjwatson> Note that the second line should begin with a hard tab character, not eight spaces, since debian/rules is a Makefile
[22:29] <cjwatson> You may of course run into some other problem later.  Is there some reason you aren't sticking with the presumably tried-and-tested packaging in the sylpheed source package, even if you need to change some bit of it?
[22:29] <sgs> OK...
[22:30] <cjwatson> If you aren't familiar with packaging, then trying to do it all yourself isn't a recipe for success.
[22:30] <cjwatson> Or at least is a recipe for having to read a lot of documentation.
[22:30] <cjwatson> dh_make is for when you need to package something that nobody else has packaged before, not for when you need to make some relatively minor tweak to an existing package.
[22:31] <cjwatson> In other words, while we can probably help to fix the specific things you're running into, it sounds like you're going about the whole thing the wrong way.
[22:33] <sgs> cjwatson: The problem is that Ubuntu / Debian are still packaging 3.5.1 which is quite old.
[22:33] <cjwatson> Sure, but you really do not have to completely redo the packaging from scratch in order to upgrade to a new upstream version.
[22:33] <cjwatson> And in fact you should not.
[22:34] <cjwatson> Running dh_make is saying "there is absolutely nothing of value in the existing packaging and I know better".
[22:34] <cjwatson> But in fact you don't know better since you said you're new to this :-)
[22:34] <cjwatson> You'd be better off transplanting the packaging parts (i.e. debian/*) from the existing source package, and massaging them as necessary for the new upstream version.
[22:35] <cjwatson> You might have to e.g. adjust and/or drop some of the patches a bit.  But still better than entirely throwing away the existing packaging.
[22:39] <sgs> cjwatson: Sure. I'll do that.
[22:43] <sgs> dh_autoreconf ./autogen.sh
[22:43] <sgs> ./autogen.sh: 6: ./autogen.sh: aclocal-1.14: not found
[22:43] <sgs> dh_autoreconf: ./autogen.sh returned exit code 127
[22:45] <cjwatson> Ah right, I guess maybe "dh_autoreconf autoreconf -- -fi -I ac" would work better in that case.
[22:45] <cjwatson> But I still think this is the wrong approach.
[22:46] <cjwatson> (Upstream's autogen.sh hardcodes a particular version of Automake that was superseded in 2014, for some reason.)
[23:01] <sgs> cjwatson: It worked :) Thank you so much for your time. :)
[23:11] <cjwatson> np


[01:18] <Mylon> Is Rasbperry pi ARM or am I in the wrong channel?
[01:18] <Mylon> The ubuntu pi build isn't working for me.
[01:22] <lilstevie> Mylon which raspberry pi do you have? the original raspberry pi will not work with Ubuntu because it is ARMv6 and Ubuntu is built for ARMv7
[01:22] <Mylon> I have the pi3.
[01:22] <Mylon> I'm using the build linked via raspberrypi's website.
[01:22] <Mylon> https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/
[01:23] <Mylon> I got it to boot using the raspbian image, but I had to SSH in because hdmi didn't work with the default config.txt
[01:24] <Mylon> Using snappy, no display, no IP address.
[01:29] <Mylon> Is the network card disabled until the first boot?
[02:10] <lpotter> the hdmi out is known issue. I thought that had been changed
[02:11] <Mylon> When I try to boot using ubuntu the Pi flashes 4 long, then 4 short times as an error code.
[02:12] <Mylon> If I guess the number of dashes is all that matter, that means "sdram not recognized"?
[02:14] <Mylon> I can't seem to figure out how to get it to work so maybe I'll just use the Raspbian.


[19:48] <shibumi> Hey everybody, a while ago I asked here for help but without outcome. Maybe it will work this time. I desperately try to boot an Ubuntu server with a cloud config on ESXI. Do you have any idea how I have to prepare the cloud-init config? I tried a few ways already and all of them failed. I tried creating an image and a iso with the cloud-init tools and then writing this to a disk or virtual CD
[19:48] <shibumi> disk and attaching it to the VM, but it gets straight ignored


[00:16] <elmo> I think I must be losing my mind; I just upgraded to karmic and 'apt-get install amarok' is failing, even though I can see the package in main
[00:31] <lifeless> elmo: what error?
[00:32] <dtchen> Darxus: your intel8x0 quirk may not land in Karmic final but will be in Lucid for certain
[00:46] <MenZa> I hope this isn't offtopic. I'm curious as to why the ncurses interface of the alt cd doesn't spend ages re-scanning partitions when manually setting a partition layout, and ubuquity makes me want to stab myself. Could anyone tell me if this is a technical limitation of ubiquity or the library used for it? :\
[01:09] <ryanakca> Hmmm.. http://summit.ubuntu.com/openid/login?next=/uds-l/sponsorship/done/ sends me on a redirect loop between summit.ubuntu.com and login.launchpad.net
[01:10] <ryanakca> (to whoever runs summit.ubuntu.com)
[01:34] <MenZa> ryanakca: Believe I had that with Ubuntu One earlier today as well.
[01:55] <jdong> I'm assuming seeing the [sda] assuming write-through doesn't go well with our "pretty silent bootup" goal?
[02:25] <arand> Is there some problem with the torrents for the beta, there's a few people mentioning  tracker authorization issues in #+1 due to missing files on tracker?
[02:56] <ewrjiwor> !ops
[02:56] <Pricey> ewrjiwor: Hi?
[02:56] <Rashko> hi all
[02:56] <ewrjiwor> sup
[02:56] <ewrjiwor> Ban me
[02:56] <Rashko>  I need help please
[02:57] <Rashko> How to enable ubuntu 8.04 supoort multiport pci card ?
[03:07] <nixternal> Pricey: he just wanted to get banned, not K-lined :p
[03:25] <slangasek> cjwatson: think> no ;)
[06:17] <al-maisan> Good morning!
[06:49] <dholbach> good morning
[06:52] <nixternal> good morning to you sir!
[06:53] <dholbach> hey nixternal!
[07:01] <dholbach> pitti: does 'fix committed' in bug 415297 mean that it's all sponsored already?
[07:02] <dholbach> if so, I'll unsub the sponsors team
[07:32] <pitti> Good morning
[07:32] <pitti> dholbach: yes, I should have noted that in the bug trail
[07:32] <pitti> dholbach: I sponsored pretty much all the pending DX/OLS stuff last night
[07:33] <dholbach> pitti: I'l unsub the sponsors
[07:33] <pitti> sharms: usblp> it's back in the cups upload in unapproved
[07:33] <pitti> sharms: but no, I didn't get your message; where did you send it, /query?
[07:53] <dholbach> slangasek: does bug 432578 look OK to you? acpi-support portion?
[07:54] <dholbach> bug 425155 probably too
[07:57] <Mez> is there a channel for jammers?
[07:59] <dholbach> Mez: #ubuntu-locoteams (and #ubuntu-devel #ubuntu-bugs #ubuntu-doc #ubuntu-testing #ubuntu-translators)
[08:01] <Mez> dholbach: I was thinking there might be a channel specific to the jam like last time :D
[08:01] <dholbach> I can't remember if there was
[08:02] <dholbach> as you can see above - there's a bunch of channels already :)
[08:07] <dholbach> tjaalton: HAPPY BIRTHDAY!!!
[08:09] <tjaalton> dholbach: :)
[08:10] <tjaalton> thanks
[08:11] <Mez> dholbach: there was #ubuntu-bugjam
[08:11] <Mez> and a couple of uk based ones
[08:12] <dholbach> Mez: might be, I just think it's a good idea to bring people together with others who do packaging/translations/documentation/bugs/testing more regularly
[08:14] <Mez> dholbach: but probably not for announcing video feeds of jams etc etc
[08:14] <dholbach> I'm not going to stop you open up another channel :)
[08:15] <Mez> dholbach: unless you use your CC powers to overrule the IRCC, you can't :D
[08:15] <Mez> and I doubt you ever would.
[08:15] <Mez> tis just lonely in there.
[08:16] <Mez> dholbach: so, ready for the shock of me actually doing some ubuntu work again ? :P
[08:16] <dholbach> I have to get used to the thought ;-)
[08:17] <Mez> dholbach: :P I'm actually working towards my Ubuntu certified professional ')
[08:17] <dholbach> nice
[08:17] <Mez> but for most of my stuff, (packaging et al) its easier to filter down from debian (no delta needed)
[08:17] <dholbach> right
[08:17]  * dholbach takes the dog for a walk - bbiab
[08:18] <Mez> have fun
[08:18] <dholbach> :)
[08:19] <robert_ancell> hey, does anyone know where http is handled in gio?
[09:33] <cjwatson> MenZa: it's somewhere between a technical limitation of ubiquity and a bug
[09:33] <cjwatson> MenZa: actually, the slowness is evident in d-i too, you just don't notice it so much because of the different UI structure
[09:33] <cjwatson> MenZa: ubiquity's partitioner tries very very hard to use the same logic as d-i's (I don't ever want to end up maintaining two different installer partitioners ...)
[09:34] <cjwatson> MenZa: and the way it does this is sort of the equivalent of driving the underlying partitioner around to get all the information it needs to display
[09:35] <cjwatson> MenZa: so the "scanning disks" stage is about the same speed as it would be to select each partition in turn in the text interface
[09:36] <cjwatson> MenZa: some of this should be solved by just plain making the underlying interface faster (perhaps by rewriting some inner-loop bits in C, although that's trickier than it looks), and some of it should probably be solved by smarter caching or even just utter hacks at the ubiquity level
[09:36] <cjwatson> MenZa: there's been a bug open about it for a good while, but it's not straightforward
[09:44] <pitti> seb128: flushing unapproved, and asking IS to thaw, FYI
[09:45] <seb128> pitti, rock on!
[09:50] <liw_> I upgraded my laptop to karmic, and the upgrade seemed to go OK. But it can't boot into the upgraded system: I get just a b&w Ubuntu logo about a second or two into the boot, and then nothing. Ideas? Could this be related to the laptop disk being encrypted?
[09:52] <pitti> liw_: try booting without "splash"?
[09:54] <liw_> the command line in grub does not have splash in it
[09:55] <pitti> uh, that's not tested any more?
[09:55] <liw_> perhaps I just don't know how to use grub
[09:55] <dholbach> holy crap - that's a lot of uploads
[09:56] <chrisccoulson> heh, it's going to be an interesting afternoon of updates ;)
[09:56] <liw_> pitti, what should I actually do to avoid splash?
[09:56] <pitti> liw_: you can explicitly specify "nosplash"
[09:57] <pitti> liw_: however, it shouldn't start at all if there's no "splash" in the kernel command line
[09:57] <pitti> reading /usr/share/initramfs-tools/scripts/init-top/usplash, anyway
[09:57] <pitti> dholbach: stuff piled up over the freeze :)
[09:58] <liw_> if I change "quiet" to "nosplash" and then press b in grub, it blackens the screen, and about a second later shows me the bios post screen
[09:59] <pitti> oh, right, that's still grub 1
[09:59] <pitti> hm, that sounds bad..
[09:59] <pitti> liw_: is that an intel card?
[09:59] <liw_> meh, sorry about that, having trouble with pidgin's UI
[09:59] <Chipzz> liw_: there was someone complaining about not being able to boot from a crypted partition earlier this night too
[10:00] <liw_> pitti, lenovo x200s, I'll need to check the graphics chipset
[10:00] <Chipzz> not at all sure if it's related
[10:00] <pitti> liw_: if it's intel, you can try with "i915.modeset=0" to disable KMS
[10:00] <liw_> pitti, yeah, it's intel
[10:00] <pitti> I didn't try with encrypted disk recently, that very well sounds like a potential problem source
[10:02] <liw_> pitti, no change with i915.modeset=0
[10:02] <pitti> liw_: does init=/bin/bash work?
[10:02] <Chipzz> pitti, liw_:
[10:02] <Chipzz> 22:25 < rrva> hi.. trying to figure out how to solve http://bugs.launchpad.net/bugs/438962 blocks me from booting
[10:02] <Chipzz> 22:25 < ubottu> Launchpad bug 438962 in udev "upstart/mountall does not boot after mounting crypto disks" [High,Confirmed]
[10:02] <liw_> just to be sure, after I edit a kernel command line parameter in grub, is the b key the right way to boot into the system with the edited command line?
[10:02] <Chipzz> like I said, not sure if it's related at all
[10:05] <cjwatson> liw_: that should be right
[10:05] <cjwatson> (with grub1; it's C-x in grub2)
[10:06] <liw_> hm, after minutes of waiting at the "ubuntu logo" screen, with the machine not responding to any keypressed (ctrl-alt-del, alt-f1, ctrl-alt-f1, caps lock, ...), it dropped into a busybox shell, complaining it can't see the disk (partition), named via a uuid
[10:07] <liw_> unfortunately, I didn't see more details, I was pressing the power button at the time, and a second later the machine powered off
[10:08] <liw_> after rebooting, the hard disk is making whining noises... I know how it feels
[10:09] <pitti> liw_: right, that seems it spins for the root fs and times out; cryptsetup/upstartification regression apparently :-(
[10:09] <liw_> pitti, in that case, I'll need to reinstall?
[10:10] <pitti> liw_: you should be able to unlock the root fs in the initramfs prompt?
[10:10] <liw_> pitti, how?
[10:10] <pitti> try "cryptsetup luksOpen /dev/yourrootdevice myroot
[10:10] <pitti> the value for "myroot" shouldn't matter much
[10:10] <pitti> since fstab should be uuid-based
[10:11] <pitti> but you can search for "crypttab", it shuold be somewhere in the initramfs
[10:11] <pitti> probably just in /etc/
[10:12] <liw_> there is no crypttab
[10:12] <liw_> the cryptsetup command worked, what next?
[10:12] <pitti> hm, that sounds wrong
[10:13] <pitti> liw_: what was the root= argument on the kernel command line?
[10:13] <pitti> uuid or dev/mapper/myroot ?
[10:13] <liw_> pitti, how do I check?
[10:13] <pitti> liw_: cat /proc/cmdline
[10:13] <liw_> ah, of course
[10:13] <pitti> liw_: if its' UUID, just pressing Ctrl-D should work
[10:14] <liw_> pitti: root=/dev/mapper/havelock-root
[10:14] <pitti> liw_: if it's name-based, you need to specify "myroot" at cryptsetup lulsOpen
[10:14] <pitti> "havelock"?
[10:14] <liw_> hostname
[10:14] <pitti> ah :)
[10:14] <pitti> liw_: ok, so please:
[10:14] <pitti> cryptsetup luksClose myroot
[10:14] <pitti> cryptsetup luksOpen /dev/yourencryptedrootdev havelock-root
[10:14] <pitti> exit
[10:14] <liw_> luksClose failed: Device busy
[10:15] <pitti> bah
[10:15] <pitti> liw_: perhaps just reboot, and do it again
[10:15] <liw_> ack, doing that
[10:20] <liw_> pitti, rebooted, waited for initramfs busybox prompt, said "luksOpen /dev/sda1 havelock-root", then "exit", immediately got back the prompt, with some preceding error messages saying the disk by-uuid doesn't exist
[10:21] <pitti> liw_: hmm
[10:21] <pitti> shouldn't udev generate those automatically?
[10:21] <liw_> I would assume so
[10:22] <liw_> attempting to mount the rootfs manually (just to see if it's ok), I get an error saying the mount command does not exist
[10:22] <pitti> bwah
[10:22] <pitti> liw_: I guess it's some magic mountall invocation now
[10:22] <pitti> liw_: does calling that do anything?
[10:22] <liw_> but if I run just "mount" it lists the mounted filesystems
[10:22] <liw_> mountall: not found
[10:23] <pitti> liw_: hm; I'm afraid this needs Keybuk now
[10:23] <pitti> I'm not familiar yet with the new boot process, I'm afraid
[10:24] <liw_> Keybuk is not present, hmm
[10:27] <liw_> I'm going to be needing this laptop to do useful stuff, so I guess I'll have to reinstall now :(
[10:34] <cjwatson> mountall isn't used in the initramfs
[10:35] <cjwatson> the initramfs mounts the root filesystem in the usual way; mountall takes over for everything else after that
[10:35] <pitti> liw_: hm, so if just "mount" works and displays the mounts, how can it "not exist" when you try to monut the root fs? or did you mean the device doesn't exist?
[10:36] <liw_> pitti, "/bin/sh: mount: not found" -- that's the error I get
[10:37] <liw_> both the device node and the target directory exist
[10:41] <pitti> liw_: does mount --help work?
[10:42] <liw_> pitti, yes
[10:44] <pitti> liw_: do you have some stuff in /conf/conf.d/cryptroot which looks enlightening?
[10:44]  * pitti just stabs into the dark now, there's not much more I can squeeze out of reading /usr/share/initramfs-tools/scripts/local-top/cryptroot
[10:45] <pitti> the heart of this is to call cryptsetup luksOpen with the correct name, so that the root device appears (/dev/mapper/whatever), and the normal root mounting can go on
[10:45] <liw_> pitti, that /conf/conf.d/cryptroot file contains two lines, with target=sda1_crypt,source=/dev/disk/by-uuid/.....,key=none,lvm=havelock-root in one, and s/-root/-swap_1/ for the other
[10:46] <pitti> right
[10:46] <pitti> swap shoulnd't be utterly importnat, but of course you can unlock it, too
[10:46] <pitti> liw_: last time I did that, I just had to luksOpen and control-d
[10:47] <pitti> but that was some 1.5 years ago..
[10:48] <liw_> hm, how do I unlock the swap partition?
[10:49] <liw_> modifying the luksOpen command results in an error saying it's not a LUKS partition
[10:50] <pitti> so perhaps you don't have encrypted swap then, or it's encrypted without luks and a random passphrase
[10:50] <pitti> but it shouldn't really stop the boot
[10:50] <liw_> it should be luks + random passphrase
[10:55] <liw_> ok, starting re-install now
[10:59] <Laney> where are u-m hints stored?
[11:01] <dholbach> /var/lib/update-notifier/user.d/
[11:04] <Laney> thanks
[11:51] <ogra> when did we drop the video group from the default user groups (and why)
[11:54] <liw_> hngh, installed karmic from scratch, installed epiphany-webkit, it just core dumps
[11:54] <maxb> Are there any gdm specialists around? I have a regression-potential nominated-for-karmic bug that I'd really like some more eyes on: bug 401047
[11:56] <unimatrix> X server 1.7 is finally out with MPX support \o/
[11:56] <unimatrix> what are the chances we see it in Karmic?
[11:56] <pitti> maxb: hi! still? I spent half a day to fix gdm/g-s-d
[11:56] <maxb> Also, bug 407457 is apparently going to be an actual regression in karmic, how can I submit it for release-noting?
[11:57] <pitti> maxb: ah, actually sounds like the very thing I fixed; new gdm is currently building
[11:57] <maxb> pitti: Still as of last time I booted, in the last ~24 hours. Let me do an update+reboot ... ah.. ok.... I will wait for that to build then :-)
[11:57] <pitti> maxb: will take a bit to build; marked as a dupe
[11:58] <maxb> whoa, impressive build queue
[11:58] <maxb> :-)
[12:05] <maxb> pitti: I don't see anything particularly related in the gdm 2.28.0-0ubuntu9 changelog?
[12:06] <ogra> pitti, do you know why we have no video group anymore in the default groups ?
[12:06] <pitti> maxb: you want ubuntu10
[12:06] <pitti> maxb: see the master bug (bug 412121)
[12:07] <pitti> meh, not that one; well, you should have bug mail
[12:07] <pitti> ogra: why would we need it?
[12:07]  * ogra is currently packaging API libs for imx51 boards that need access to certain specific devices for image and video processing, i dont want to include udve rules making the devices 777
[12:07] <ogra> *udev
[12:08] <ogra> the users need to have rw access to these devices
[12:08] <pitti> ogra: local users get permission to /dev/dri* stuff from udev-acl
[12:08] <ogra> ah, cool, i'll take a look
[12:08] <dholbach> slangasek, pitti: will there be new dailies tomorrow (with all the fixes after beta)? I'm aksing because there's lots of ubuntu jams happening over the WE and people will test CDs like mad
[12:09] <ogra> i guess for the simcard device i also support i can just use dialout
[12:09] <ogra> or is that going away as well ?
[12:09] <maxb> bug 421212
[12:09] <maxb> pitti: My issue is not with variants, it's GB vs USA
[12:10] <pitti> dholbach: CD cronjobs are still off, but I guess we can re-enable them today; I leave that to slangasek, though, there might be a reason
[12:10] <pitti> maxb: hm, you said "dvorak"
[12:10] <dholbach> pitti: alrightie
[12:10] <maxb> I never did :-)
[12:10] <pitti> and since these are variants, they would be broken right now (and fixed in that bug)
[12:10] <dholbach> pitti: in any case I'll run another rsync tomorrow morning, so if ISOs change we can test them too
[12:10] <pitti> My symptoms are the same as bug 395103: although my keymap is set to dvorak in HAL, and previous versions of gdm honored this, it's now using a USA keymap.
[12:10] <pitti> maxb: ^
[12:10] <cjwatson> oh, glad to hear that, I got some baffling installer bug reports about broken variants
[12:11] <cjwatson> I think somebody was complaining that es_ast was broken
[12:12] <maxb> Oh, I guess my problem is subtly different to the original reporter's after all :-/ I'll wait for the builds, and retest
[12:13] <liw> *phew* things are slowly starting to work for me in karmic
[12:14] <pitti> liw: did you reinstall with crypted root?
[12:14] <liw> pitti, nope, I'd rather not hit my head against the desk more than necessary this month
[12:15] <pitti> liw: I gave up cryptroot when ecryptfs came along..
[12:15] <liw> I am not convinced ecryptfs is a sufficient solution for any use case I have, though
[12:21] <liw> hngh, every time I start a new app in karmic, I find bugs... only reporting those that make me angry, though
[12:28] <mwider> hi
[12:28] <liw> there is no gdm.conf anymore?
[12:28] <mwider> I have one question about debuging package
[12:29] <liw> I mean /etc/gdm/gdm.conf
[12:38] <pitti> liw: no; what are you trying to do? There's still a custom.conf
[12:38] <pitti> (created by gdmsetup)
[12:38] <liw> pitti, I want to shut gdm up
[12:38] <liw> it makes a noise when it starts up
[12:39] <pitti> liw: normal GNOME session startup sound, I presume?
[12:39] <liw> no, before I even type a username
[12:39] <pitti> liw: right; gdm _is_ a gnome session
[12:40] <liw> when I logged in the first time, the african-style noise soudned; when gdm starts up, it's more of a bleep kind of noise
[12:49] <zul> morning
[13:04] <cjwatson> initramfs debugging can be fearsomely difficult
[13:04]  * cjwatson has been at it for three hours now
[13:06] <cjwatson> I'm leaving straces lying around for myself in /dev/.initramfs :)
[13:08] <asac__> ogasawara: hi. we get more reports saying that ath9k is in not so good shape :/ see 439723 and 414560 ... previously we only had issues with background scanning. now it seems to be unstable for "older" chipsets even without that
[13:11] <liw> so, what is the way to configure the gdm "gnome session"?
[13:38] <tkamppeter> Riddell: What is currently the standard tool in KDE for running an application as root (GUI-based sudo, like gksudo or gksu)?
[13:38] <Riddell> tkamppeter: /usr/lib/kde4/libexec/kdesu
[13:40] <Riddell> tkamppeter: also in a .desktop file X-KDE-SubstituteUID=true will make it start with the right app (unfortunately that's not in the .desktop spec)
[13:50] <tkamppeter> Riddell: Thanks, seems to change from version to version, there are always reports that HPLIP does not find this tool.
[13:51] <tkamppeter> Riddeel, is there perhaps some xdg-utils wrapper so that one does not need to add a new tool to the list for every release?
[13:51] <tkamppeter> Riddell: ^^
[13:53] <Riddell> tkamppeter: it has always been /usr/lib/kde4/libexec/kdesu in KDE 4, although you could also use kdesudo (we set kdesu as a link to kdesudo in Kubuntu).  I'm not  aware  of an xdg-wrapper tool, the "menu" package from Debian has su-to-root but I don't know how well t hat  works
[14:05] <tkamppeter> Riddell: Thanks.
[14:07] <tkamppeter> Riddell: For me /usr/bin/kdesudo is a binary executable from the kdesudo package.
[14:08] <tkamppeter> Anyone knows what is the default replacement for System->Administration->Services (managing and starting/stopping/restarting services)? See bug 440397.
[14:09] <Riddell> tkamppeter: yes, and /usr/lib/kde4/libexec/kdesu will point to it via an alternate
[14:09] <ScottK> Riddell: My experience with su-to-root has been good, but we'd probably have to split the menu package to avoid pulling it all into Main.
[14:27] <Amaranth> tkamppeter: there isn't a replacement for that yet
[14:28] <Rashko> hi all
[14:28] <Rashko> I need help please
[14:28] <Rashko> please any one help me
[14:28] <tkamppeter> Amaranth: So Karmic will ship without a GUI tool to restart services?
[14:29] <Rashko> need to enable ubuntu 8.04 more than 4 serial port pci card
[14:30] <Amaranth> tkamppeter: I guess so
[14:37] <thatscoteng> hi folks,
[14:37] <thatscoteng> I am wanting to report a problem with the installer system but not sure of the package
[14:37] <thatscoteng> I had selected dvorak keyboard during the install of karmic beta, but this has been ignored and I have been given the default keyboard
[14:38] <thatscoteng> dholbach sent me here, cjwatson or  evand may have been discussing it earlier
[14:40] <Pici> thatscoteng: If its on the Live CD installer the package name is ubiquity, on the alternate/server cds its debian-installer
[14:40] <thatscoteng> thanks
[14:41] <evand> thatscoteng: it's already reported
[14:41] <evand> one second, I'll find you the bug number
[14:43] <thatscoteng> bug #40627 ?
[14:44] <evand> thatscoteng: bug 421212
[14:45] <thatscoteng> thanks
[14:45] <evand> so it will be fixed soon
[14:47] <davmor2> ttx: Dude I'll have another look at the test docs, next week when things have settled a bit.  I'll work through the stages and track what worked.
[14:47] <ttx> davmor2: ping me if you need me
[14:48] <davmor2> ttx: will do probably start monday afternoon.
[14:48] <ttx> ok
[15:09] <MenZa> cjwatson: Thanks for that very verbose answer :D
[15:42] <thatscoteng> what package does gnome-keybinding-properties belong to?
[15:42] <thatscoteng> (or how do I find out which package ...)
[15:44] <joaopinto> thatscoteng, dpkg -S gnome-keybinding-properties
[15:44] <cjwatson> thatscoteng: if it's installed on your system, use dpkg -S; otherwise, packages.ubuntu.com
[15:45] <thatscoteng> thanks
[15:45] <thatscoteng> (twas gnome-control-center if anyone else cares)
[15:48] <maxamillion> I was curious how the local mail from cron and logwatch was being handled since there is no longer a MTA by default, was there some patch, a trick, or are the messages just simply lost?
[15:54] <siretart`> fun: empathy segfaults on startup only on the local display, though it works via ssh-x11-forwarding...
[15:54] <siretart`> segfaults happens somewhere in libgobject
[15:54] <liw> a lot of gtk apps are crashing on karmic, it seems
[15:54] <siretart`> liw: details?
[15:57] <cjwatson> evand: are you working on a new devicekit-disks for bug 419796 now that beta's out, or is somebody else?
[15:58] <evand> cjwatson: already sorted
[15:58] <evand> we have 007 in the archive
[15:58] <evand> I'll close the bug
[15:58] <cjwatson> ah, thanks
[15:59] <mat_t> cjwatson: hi and sorry for a lame question - if I perform a clean install now, will I get GRUB 2 automatically?
[16:00] <cjwatson> mat_t: yes
[16:00] <cjwatson> mat_t: just not on upgrades
[16:00] <mat_t> cjwatson: ok, thanks!
[16:01] <slangasek> pitti: debian-cd still needs set back to !beta before re-enabling the cronjobs
[16:04] <cjwatson> slangasek: oh, that was my fault, sorry
[16:05] <cjwatson> Keybuk: is bug 438335 basically a duplicate of bug 431184?
[16:05] <dholbach> cjwatson, slangasek: does that mean new dailies tomorrow? :)
[16:05] <cjwatson> (don't want to dup without asking, but they're both on the agenda for the release meeting and seem to have basically the same status)
[16:05] <cjwatson> dholbach: yes
[16:05] <dholbach> yoohoo
[16:05] <dholbach> gracias
[16:05] <Keybuk> cjwatson: who knows
[16:05] <cjwatson> dholbach: wouldn't have been any point today for the most part
[16:06] <Keybuk> you're ALWAYS going to see console text
[16:06] <sharms> I cant seem to download any packages today from archive, I guess beta is taking its toll
[16:06] <Keybuk> because certain developers really can't stop themselves deliberately adding it
[16:07] <cjwatson> Keybuk: for karmic, I assume we'll want to both chip away at messages, as well as the splash timeout discussed at UDS?
[16:07] <dholbach> cjwatson: sure... I was just going to ask a bunch of jam participants tomorrow in Berlin to test-install and I know that a bunch of bugs have been fixed directly after beta, so I'll rsync tomorrow before I head out
[16:07] <cjwatson> (according to pitti anyway, I don't have a very good memory of that discussion)
[16:07] <Keybuk> cjwatson: for lynx
[16:08] <Keybuk> for karmic I've lost the will to care ;)
[16:08] <Keybuk> especially when I sit and tell people we don't want console messages for over an hour
[16:08] <Keybuk> and they go and stick one in anyway
[16:09] <cjwatson> which one in particular?
[16:09] <Keybuk> there were ones in ufw, apparmor, etc.
[16:10] <zul> asac: ping when you get a chance can you look at #434836
[16:10] <jdstrand> I don't recall being told not to do it...
[16:11] <jdstrand> (before I did that is)
[16:14] <doko_> gah, type 'reset' in a gnome terminal, and all windows close :-/  that was fixed before ...
[16:14] <dholbach> doko_: I can't see the problem here
[16:15] <liw> doko, oh foo, I just tried that
[16:15] <doko_> dholbach: amd64?
[16:16] <dholbach> doko_: yes - vte 0.22.0-0ubuntu1?
[16:16] <liw> happens on both my karmic machines
[16:16] <liw> (both amd64)
[16:16] <doko_> liw: there must be another condition, now I can't see it with a newly opened window
[16:17] <liw> doko, me neither
[16:38] <mdz> kirkland: good morning
[16:38] <kirkland> mdz: howdy
[16:38] <mdz> kirkland: do you have a view yet on merging eucalyptus from trunk?
[16:39] <kirkland> mdz: ttx and I decided to do it together, on a shared screen session on Monday
[16:39] <mdz> kirkland: so it's on hold until then?
[16:39] <kirkland> mdz: i was going to spend today trying to solve the kvm attached storage issue, testing the new iso with ubuntu13, and figuring out the cloud restart problem
[16:39] <mdz> kirkland: ok
[16:39] <robbiew> Keybuk: question, if we set console=tty6 on the kernel line, it seems to help silence the non-kernel messages at boot....but obviously redirects messages to tty6...if we did this by default, what breaks? :P
[16:40] <kirkland> mdz: unless you'd like me to reprioritize it above that ^
[16:40] <kirkland> mdz: ttx and I agreed that it would be good to have two sets of eyes on the merge
[16:40] <Keybuk> robbiew: booting without "quiet"
[16:40] <kirkland> mdz: particularly considering that neither of us have done it before
[16:40] <ogra> systems that dont use 6 ttys
[16:41] <ttx> ... and that lots of our changes need to be dumped.
[16:41] <robbiew> Keybuk: we use quiet by default, so presumably anyone removing that would redirect console to wherever
[16:41] <robbiew> ogra: good point
[16:41] <robbiew> ogra: what about tty2? :P
[16:42] <robbiew> i suppose same arguement holds
[16:42] <ogra> robbiew, dropping quiet switches on the text messages in usplash if you keep splash ion place
[16:42] <robbiew> all I know is that it sure cleans up the fsck and apparmor and other chatter
[16:42] <ogra> i assume that would break as well
[16:43] <robbiew> ogra: I know what quiet does...I'm saying if the problem with moving the console away from tty1 is that dropping "quiet" won't work...then we don't have a problem, because a user has to edit the default line to remove quiet anyway
[16:44] <robbiew> so he/she could also remove the console line
[16:44] <ogra> so you would put it on cmdline, not tell the kernel to default to it
[16:45] <robbiew> right..sorry, by default I meant in the default grub line :/
[16:45] <robbiew>  /etc/default/grub
[16:45] <ogra> right
[16:46] <robbiew> i wonder if we could detect the number of ttys on a system during install, and then add "console=tty6" to systems with the standard setup
[16:47] <liw_> is the number of ttys ever different from what we set it to during install? I guess post-install the user may change it
[16:47] <ogra> well, the actual number is only limited by the kernel actually ...
[16:48] <ogra> what we set during install (or what Keybuk sets during install of upstart) are the 6 gettys that run on ttys
[16:48] <Keybuk> that's irrelevant
[16:48] <Keybuk> console=tty6 would still work
[16:48] <ogra> and now that i think of it, i dont think systems with less than 6 ttys will have any prob, the kernel doesnt care where you direct the boot output
[16:49] <robbiew> I just think it's an easy solution to a lot of the boot messages
[16:50] <robbiew> that aren't kernel related
[16:50] <ogra> you will definately get complaints from power users
[16:50] <mvo_> Mirv: hey! is lp:~timo-jyrinki/language-selector/evol_ooo still relevant/needed (sorry, I'm not fully up-to-date with language-selector anymore)
[16:51] <ogra> the "something changed we are used to" factor :)
[16:51] <robbiew> ogra: power users can just turn it off
[16:51] <ogra> yeah
[16:57] <asac> zul: yes i have time to MIRs now that beta is out. will do that latest monday morning
[16:57] <zul> asac: great thanks..
[17:03] <doko_> cjwatson, pitti: can gcc-4.3 be demoted? there are only references to archs in the b-d's which are not in ubuntu
[17:04] <cjwatson> doko_: IIRC you filed a bug, which'll be in the archive admin queue
[17:04] <doko_> ok, just seen it building on the buildds ... will lower the prio manually
[17:05] <cjwatson> it should be demotable, I just haven't had time to look yet
[17:08] <mdz> cjwatson: given we didn't get bug 364649 in, should I implement cr3's casper.log hack instead?
[17:09] <cjwatson> mdz: oh, yeesh, that's trivial, we'll get it done
[17:10] <cjwatson> evand: ^- could you look at that please?
[17:10] <mdz> cjwatson: don't want to distract from more important things
[17:10] <cr3> cjwatson: thanks!
[17:10] <cjwatson> evand: should just be a matter of dumping out .disk/info to a specific file if it exists
[17:10] <evand> indeed, will do
[17:10] <cjwatson> err, /cdrom/.disk/info
[17:11] <cjwatson> evand: ideally, both in ubiquity and in d-i (installation-report)
[17:17] <Ng> http://www.ubuntu.com/testing/karmic/beta#Upstart links to alpha5 which isn't on cdimages anymore
[17:17] <Ng> seemingly none of the alphas are there anymore
[17:24] <Keybuk_> Warning: testing usplash can be detrimental to your X server, or any applications running on it
[17:24] <ogra> pfft, X ...
[17:24] <robbiew> lol
[17:28] <jpds> Ng: Sounds like something for -website.
[17:28] <Ng> a good point
[17:34] <siganderson> I installed emesene 1.5 on kubuntu karmic koala beta, I can't connect because I can't write in the username field! What happened?
[17:35] <Riddell> support requests in #ubuntu or #ubuntu+1 siganderson
[17:36] <Riddell> cjwatson: is archive reorg active now?
[17:36] <maco> siganderson: +1 in this case since karmic
[17:36] <c_korn> I have a half-translated gnome. against what package should I file a bug ?
[17:36] <cjwatson> Riddell: well, ish. we still don't have a kubuntu development team that we might approve for kubuntu upload rights, afaik
[17:37] <Riddell> cjwatson: so it's just blocking on us?
[17:37] <maco> haha
[17:37] <siganderson> ok I will request there
[17:37] <cjwatson> well, until you unblock at which point it will block on the TB again to approve that team, but hopefully only fairly briefly
[17:39] <olmari> would sort-of-bug-squashing report be proper to discuss here?
[17:39] <Riddell> cjwatson: and having done that is there an agreed  protocol for  how  we add  people to it?  i.e. should can kubuntu-council act alone or should developer-membership-board be consulted somehow?
[17:40] <maco> olmari: triaging, or development? if the former, #ubuntu-bugs
[17:40] <maco> (unless -bugs people already went "uhh....ask a dev")
[17:41] <cjwatson> Riddell: we would like you to define that protocol, and we'll look it over; we're having a bit of an, er, discussion about the minimum requirements, but I think there's some consensus that the application process needs to be fairly similar to the MOTU Council's, and the way you report new developers should be similar too, but you may want to vary how you approve people; you might as well start with the MC's process as a ...
[17:41] <cjwatson> ... guideline if that's OK with you
[17:42] <olmari> maco: well I'm not sure... I found out that 1) when I "eject" the usb dvd drive in karmic and reconnect it (at any later time) it changes device number
[17:42] <olmari> I mean when it is first on /dev/sr1, then when I take it out and put back it becomes /dev/sr2
[17:43] <olmari> until sr4 is used and then havoc"
[17:43] <maco> olmari: so youre needing to figure out which package to report the bug against?
[17:45] <olmari> maco: well... that too I suppose, but generally also that there is such bug and also I have second bug related to at least dvd if not more generally to device handling...
[17:46] <maco> olmari: is there a bug filed already or no? i heard dtchen talking about a dvd bug yesterday
[17:47] <olmari> maco: don't know... sorry... I'm starting to feel too stupid here :-p
[17:47] <maco> olmari: ok well lets move to #ubuntu-bugs and talk there
[17:49] <sharms> asac__: any idea if the commit was made yet that resolves LP #300438
[17:53] <asac__> sharms: please try todays/yesterdays trunk build: https://edge.launchpad.net/~network-manager/+archive/trunk
[17:53] <asac__> let me know
[17:53] <sharms> will do thanks
[17:55] <Riddell> cjwatson: kubuntu-dev created, I invited developer-membership-board to be a member who I can make an admin
[17:55] <ScottK> cjwatson: Could we use the protocol of "must be approved by the developer membership board" until we get a delegated protocol written and approved?
[18:00] <Darxus> Launchpad still won't let me nominate for Lucid :P
[18:02] <cjwatson> ScottK: I'd really prefer we didn't, there's limited benefit unless we delegate and the DMB is not really all that directly aware of who's useful
[18:02] <robbiew> Keybuk: is couchdb still starting automatically?
[18:02] <robbiew> I thought that was fixed
[18:02] <cjwatson> Darxus: no, and it won't until lucid is open, which won't be until right after karmic releases (long-standing limitation)
[18:02] <ScottK> cjwatson: OK.  We've got a couple of people who are clearly ready, and it'd be nice if they didn't get blocked too long on procedure.
[18:03] <Keybuk> robbiew: I think that's fixed
[18:03] <robbiew> okay...that's what I thought
[18:03]  * robbiew is triaging a boot bug...fun times
[18:03] <cjwatson> ScottK: if you wanted to just use the motu-council procedure with the serial numbers filed off by substituting kubuntu-council (or other appropriate body) for motu-council, I think that would be fairly uncontroversial
[18:04] <cjwatson> I thought there was some concern about whether kubuntu-council was the right body?
[18:04] <cjwatson> or did that get resolved / I was just confused?
[18:04] <ScottK> I mentioned that as it's not a developer body.  It's more broadly based.
[18:04] <ScottK> I need to discuss it with Riddell.
[18:10] <nixternal> ScottK: I think I might be able to lend a hand when it comes to approving :)
[18:11] <ScottK> Yeah, well we need to figure out the right group.
[18:17] <mdz> checking status of bug 429379, bug 429004, bug 428188, bug 428010
[18:20] <Amaranth> hmm, how do you go about getting a package removed? just file a bug against it?
[18:20] <cjwatson> Amaranth: yes, and subscribe ubuntu-archive
[18:20] <Amaranth> Will do
[18:20] <kirkland> cjwatson: testing today's iso, the node-preseed file isn't available; where is that supposed to be located on the filesystem?
[18:22] <cjwatson> kirkland: /etc/eucalyptus/node-preseed.conf
[18:22] <kirkland> cjwatson: bummer, that wasn't created
[18:22] <kirkland> cjwatson: looks like a regression since beta
[18:22] <kirkland> cjwatson: ideas, before i start digging?
[18:24] <cjwatson> kirkland: surprising that that would have regressed, since I didn't think that code had been touched. Did you definitely use the UEC installation option, not server?
[18:24] <cjwatson> as in, at the CD boot menu
[18:24] <kirkland> cjwatson: absolutely
[18:24] <cjwatson> check syslog I guess
[18:24] <cjwatson> see if the eucalyptus-udeb finish-install script got run
[18:25] <kirkland> cjwatson: uh, /var/log/installer doesn't exist
[18:25] <kirkland> cjwatson: this install is b0rked
[18:25] <kirkland> i'm starting over
[18:25] <cjwatson> this time, check before you reboot, and if /target/var/log/installer/ doesn't exist, extract /var/log/syslog
[18:26] <maco> is it too late to do a FFe for yanking a package from Sid to Universe in Karmic?
[18:29] <apw> cjwatson, is there any issues with having a large debian/changelog file?
[18:30] <cjwatson> no
[18:30] <cjwatson> other than simple size
[18:31] <apw> so having one of the order of a 1M is nothing to worry about?  is there a size when it is to be worried about?
[18:31] <cjwatson> so the only issue really is that it will all be in the binary package and take up CD space and such, and you should look at the *compressed* size (changelogs tend to compress well)
[18:32] <cjwatson> if you're concerned about the size, you could have debian/changelog.old
[18:32] <apw> does changelog.old get handled automatically ?
[18:32] <liw_> changelog.old would remain in the source package, I assume
[18:32] <cjwatson> the purpose of changelog.old is to avoid it all going in the binary package, which some packages want, so there's no handling to do
[18:32] <apw> i think this thing is wanted installed
[18:32] <cjwatson> there are a few packages that keep very long piles of changelog entries in that way
[18:33] <liw_> my current largest compressed changelog.Debian* is 194817 bytes, so a megabyte compressed is a bit big
[18:33] <cjwatson> debconf for example does this, and puts the full changelog in debconf-doc
[18:33] <cjwatson> you might consider putting the whole thing in linux-2.6.31-doc or something
[18:33] <cjwatson> is it in fact a megabyte compressed?
[18:33] <apw> cjwatson, yeah i think the desire is to be about to get it out
[18:33] <apw> no it is currently 600k uncompressed
[18:34] <cjwatson> my desire, personally, is to have the information available without having to dig through revision contorl
[18:34] <cjwatson> having it in the source package would be fine by me, although if possible it would be good to have in a binary package
[18:34] <apw> 215k compressed
[18:34] <apw> ok, am looking at putting it in the binary package, but i guess its coming out of your CD size if i do that
[18:35] <cjwatson> consider my -doc suggestion
[18:35] <cjwatson> debconf does:
[18:35] <cjwatson>         # Changelog reduction hack for debconf. Only include top 100 entries.
[18:35] <cjwatson>         perl -ne '$$c++ if /^debconf /; last if $$c > 100 ; print $$_' \
[18:35] <cjwatson>                 < debian/changelog > debian/debconf.changelog
[18:35] <cjwatson>         dh_installchangelogs
[18:35] <cjwatson> obviously would need some modification
[18:35] <apw> well actually ... this is going in the binary either way ... as this is just the changelog back to 2.6.30
[18:36] <cjwatson> mdz: do you object to the full untrimmed changelog only going in the binary package?
[18:36] <cjwatson> apw: uh, I don't get it, that's what's in the package right now
[18:36] <cjwatson> 33KB uncompressed back to 2.6.30
[18:36] <cjwatson> what would be really valuable would be to restore the full Ubuntu history
[18:37] <cjwatson> which was truncated in the past, over objections ...
[18:37] <apw> cjwatson, there are two parts to the issue, 1) that all history back to older packages is not avalable at all
[18:37] <apw> and the second is that the upstream commits are not listed
[18:37] <mdz> cjwatson: that would be a distinct improvement on the status quo
[18:37] <apw> if i add upstream commits then it balloons
[18:37] <cjwatson> oh god, don't put every single upstream commit in
[18:37] <cjwatson> where did that idea come from? no other package does that
[18:38] <cjwatson> well, no, that's not quite true, some do have a ChangeLog where that's explicitly maintained by upstream
[18:38] <apw> that is the request as i got it
[18:38] <cjwatson> but we don't generally go out and create it, and it's pretty acceptable not to put it in binary packages when it's huge
[18:38] <cjwatson> mdz: surely restoring the old Ubuntu history is much more important than getting a full git log
[18:38] <apw> mdz, i think you were at the head of the request here, so perhaps i have miss interpreted
[18:39] <cjwatson> mdz: BTW, sorry, I misspoke above, I meant "do you object to the full untrimmed changelog only going in the source" package?
[18:39] <cjwatson> can't type today
[18:40] <kirkland> cjwatson: hmm, okay, reinstalled
[18:41] <kirkland> cjwatson: it dropped me back to the installation menu after the "Finish Installation" step
[18:41] <kirkland> cjwatson: no errors to tty1
[18:41] <kirkland> cjwatson: i'll check the logs now
[18:43] <kirkland> cjwatson: http://paste.ubuntu.com/284013/
[18:43] <kirkland> cjwatson: some missing modules
[18:44] <kirkland> cjwatson: maybe a grub-installer bug
[18:44] <kirkland> cjwatson: this isn't an md setup, but those changes might have regressed grub installation?
[18:45] <cjwatson> I only just uploaded that, I doubt it's on your CD yet
[18:45] <cjwatson> let's see
[18:45] <cjwatson> well, clearly an iscsi problem
[18:45] <cjwatson> Oct  2 17:40:23 finish-install: /usr/lib/finish-install.d/10open-iscsi backed up
[18:46] <cjwatson> ah, I see
[18:46] <cjwatson> I'll fix it
[18:46] <cjwatson> surprised that didn't break before, actually
[18:47] <kirkland> cjwatson: cheers, thanks
[18:48] <kirkland> cjwatson: any chance you could push a new server iso build thereafter?
[18:48] <kirkland> cjwatson: also, what can i do to finish this install by hand, and use it?
[18:49] <cjwatson> oh, it probably broke because partman-iscsi is now installed as standard
[18:49] <cjwatson> rm -f /usr/lib/finish-install.d/10open-iscsi, try the menu item again
[18:49] <cjwatson> I can't spin a new server ISO build afterwards, I'm afraid, I'm way over hours for this week and need a rest
[18:50] <kirkland> cjwatson: bingo
[18:50] <cjwatson> there should be some US-timezone people who can
[18:50] <kirkland> cjwatson: no problem, i'll poke slangasek
[18:50] <slangasek> cjwatson, kirkland: yo
[18:50] <kirkland> slangasek: can you push another iso build after cjwatson fixes partman-iscsi?
[18:50] <kirkland> slangasek: today's server iso build is broken until then
[18:51] <slangasek> yes
[18:51] <cjwatson> not partman-iscsi, open-iscsi
[18:51] <cjwatson> I fixed partman-iscsi earlier today ;-)
[18:51] <cjwatson> upload's in the queue, I'm sure it'll take a while to build at the moment though
[18:51] <cjwatson> well, "fixed", I realise now I broke this case, but before that iscsi installation was broken
[18:52] <kirkland> cjwatson: great, thanks
[18:55] <james_w> Keybuk: is dbus supposed to be native-package-with-dash-version?
[18:56] <slangasek> cjwatson: oh, "in the queue" - we still need to unfreeze, don't we
[18:57] <Keybuk> james_w: no, it was an accident, I'll fix it for the next version
[18:57] <james_w> ok
[18:57] <Keybuk> .orig.tar.gz repacking for the lose
[18:57] <cjwatson> slangasek: I thought we had; I meant the accepted queue
[18:57] <cjwatson> or build queue or whatever
[18:57] <ScottK> slangasek: It's unfrozen, but the backlog is long
[18:57] <slangasek> ok
[18:57] <slangasek> apparently still in the accepted queue, yes, doesn't show up on the LP page yet
[18:57] <slangasek> cjwatson: what version am I looking for? -0ubunutu12?
[18:58] <cjwatson> slangasek: aye
[18:58] <slangasek> ok, queued
[19:35] <hyperair> what's the upstart version of /etc/init.d/script reload?
[19:52] <cjwatson> hyperair: 'reload script'
[19:53] <cjwatson> hyperair: (or you can use the 'service' wrapper if you don't know which it i)
[19:53] <cjwatson> is
[19:53] <hyperair> cjwatson: and how do you write upstart jobs with a reload action?
[19:53] <hyperair> or does reload really just restart the job?
[19:55] <cjwatson> hyperair: it just sends SIGHUP to supervised processes
[19:56] <cjwatson> cf. bug 433544
[19:56] <hyperair> ah i see.
[20:20] <peol> Any devs for the gnome-control-center here?
[20:20] <peol> Or should I try in #gnome?
[20:22] <Mez> how do I disable encrypted swap?
[21:05] <kirkland> Keybuk: is the dbus-reconnect error thought to be fixed now?
[21:05] <Keybuk> yes
[21:05] <kirkland> ii  dbus                                     1.2.16-0ubuntu7                   simple interprocess messaging system ?
[21:06] <Keybuk> it's the upstart package you need to check
[21:06] <kirkland> Keybuk: i'm still seeing the problem where those registration jobs don't run
[21:06] <kirkland> ii  upstart                                  0.6.3-6                           event-based init daemon
[21:06] <Keybuk> that should have the patch
[21:06] <Keybuk> check that you don't have an /etc/init/dbus-reconnect.conf ?
[21:07] <kirkland> Keybuk: i most certainly do have that file
[21:07] <Lure> Keybuk: if mountall fails to mount all fs and drops me to shell, is there a way to continue boot when I manually mount missing FS - see bug 437801?
[21:07] <kirkland> Keybuk: should the package maintenance purge that file?
[21:07] <Keybuk> kirkland: yes
[21:08] <Keybuk> argh
[21:08] <Keybuk> I see the issue
[21:09] <Keybuk> kirkland: upstart -7 should fix that
[21:09] <kirkland> Keybuk: in the mean time, i should just rm -f /etc/init/dbus-reconnect.conf ?
[21:09] <Keybuk> if you updated from the PPA it may not have removed the file
[21:09] <Keybuk> yes
[21:11] <kirkland> Keybuk: okay, once i remove that file, things look much better
[21:11] <Keybuk> that doesn't break anything either - since reconnect is done elsewhere
[21:12] <Darxus> $ sudo do-release-upgrade
[21:12] <Darxus> Checking for a new ubuntu release
[21:12] <Darxus> No new release found
[21:12] <Keybuk> all that file was doing was forcing a reload - which is bad
[21:12] <Darxus> http://www.ubuntu.com/testing/karmic/alpha2 seems to indicate that should work.
[21:13] <Keybuk> Darxus: Alpha 2 was a very long time ago, read http://www.ubuntu.com/testing/karmic/beta
[21:13] <Darxus> Yeah I was just going to ask, why isn't the beta listed on http://www.ubuntu.com/testing/ ?
[21:14] <Keybuk> oversight I guess
[21:14] <slangasek> webmaster notified
[21:14] <Darxus> slangasek: That beta isn't listed on that page?
[21:14] <Darxus> Cool, the -d that the beta page said to use appears more functional.
[21:15] <Darxus> I backed up /home and /etc and I think I'm going to upgrade when I get home.
[21:20] <slangasek> Darxus: yes
[21:24] <jdong>
[21:31] <Darxus> slangasek: Cool, thanks.
[21:46] <Darxus> What will it take to sync a package from debian once lucid is open?
[21:46] <ScottK> Darxus: Nothing if the package is either not existing or not modified in Ubuntu
[21:47] <sistpoty> Darxus: otherwise a sync request, specifying for each ubuntu change why it can be dropped (there's a wiki page somewhere with details)
[21:47] <Darxus> Cool.
[21:47] <Darxus> How is a sync request done?
[21:48] <Darxus> (googling)
[21:48] <Darxus> Got it.
[21:48] <Darxus> https://wiki.ubuntu.com/SyncRequestProcess
[22:04] <sharms> is anyone aware that the archive.us.ubuntu.com is effectively down, atleast in the us?
[22:05] <sharms> it must be a problem with that address not routing requests, because the individual mirrors are working correctly
[22:06] <Darxus> $ host archive.us.ubuntu.com
[22:06] <Darxus> Host archive.us.ubuntu.com not found: 3(NXDOMAIN)
[22:07] <sharms> sorry us.archive.ubuntu.com
[22:08] <Darxus> I can load http://us.archive.ubuntu.com/ (in the US)
[22:08] <Darxus> But http://downforeveryoneorjustme.com/us.archive.ubuntu.com says it's down.
[22:08] <sharms> right I wouldnt have said anything without testing it
[22:09] <sharms> and its down both from my atlanta site, cincinnati site, and san jose site, and not 404 down but 2b/s or less down til timeout
[22:10] <nixternal> if you aren't using karmic in the us, the anl.gov mirror is the fastest (nice living 10 minutes from it too) :)
[22:10] <sharms> lol I have working mirrors
[22:10] <sharms> but I am assuming someone takes care of the load balancing, and would like to know
[22:10] <sharms> incase its geographically isolated and they may not be aware
[22:15] <nixternal> sharms: this happens all the time, I am used to it by now :)
[22:15] <sharms> nixternal: I have a bunch of Ubuntu converts in the office I told to upgrade to karmic, they tried and now its blowing up :)
[22:16] <nixternal> lol
[22:16] <nixternal> ya, same here
[22:16] <nixternal> people prepping for the Global Jam this weekend have been complaining today in #ubuntu-chicago
[22:16] <sharms> even help.ubuntu.com is intermittant at times
[22:17] <nixternal> jeesh, I just need to do 'apt-get update' to pick up my packages in a test repo..should have commented out the others
[22:18] <Darxus> sharms: You told recent converts to upgrade before release why?
[22:20] <sharms> Darxus: it's ready for beta testing, and I can overcome any problems they have.  Make sense?
[22:21] <Darxus> Yeah, I guess.  They understand what "beta" means?
[22:21] <sharms> right, but I am much more concerned about the mirror address on this channel :)
[22:22] <Darxus> sharms: whois for ubuntu.com lists<EMAIL_ADDRESS>+44.1624643643
[22:22] <Darxus> Try them.
[22:23] <ScottK> Or even #canonical-sysadmin
[22:34] <jdong> hmm any plans/milestoning magic / whatnot for bug 141494?
[22:34] <jdong> IMO it's quite serious if it does affect all x86-64 users...
[22:34] <jdong> flash applets on Karmic x86-64 do not accept mouseclicks at all
[22:38] <Guest45216> Hi Can anybody tell me how I can have a ubuntu usb with only browser?
[22:38] <Guest45216> Hello
[22:38] <Guest45216> Anybody here can help me with ubuntu usb stick?
[22:39] <Guest45216> anyone?
[22:40] <ScottK-desktop> Guest45216: Help in #ubuntu or #ubuntu+1 for Karmic
[22:41] <Guest45216> OK thanks scottK
[23:27] <WildBill> Hey, my network install of ubuntu seems to have a dependency early on (downloading additional kernel drivers) on security.ubuntu.com. I suppose that's buried in the initrd somewhere... is there a command-line override for that?
[23:29] <slangasek> Keybuk: I've uploaded my changes to portmap and nfs-utils to fix the /home-or-/usr-on-NFS problem, but we still have an issue on shutdown because sysvinit is still handling unmounting
[23:36] <slangasek> kirkland: hmm, open-iscsi still hasn't published on amd64?
[23:36] <kirkland> slangasek: i haven't been watching
[23:36] <slangasek> I just polled it now in response to your mail
[23:41] <kirkland> slangasek: my day is ending now
[23:41] <kirkland> slangasek: as long as it makes it onto an iso by Monday, I'm happy


[16:04] <pochu> @now
[16:04] <ubotu> Current time in Etc/UTC: April 04 2008, 15:04:20 - Next meeting: Server Team in 5 days


  Toch mooi derde geworden.
[12:04] <jink> Gefeliciteerd.
[12:05] <lotuspsychje> lol
[12:05] <lotuspsychje> tnx
[15:50] <oerheks> does this make format C: /u/q  work? https://news.softpedia.com/news/microsoft-s-powershell-available-on-ubuntu-as-a-snap-here-s-how-to-install-it-522050.shtml
[17:05] <lotuspsychje> good evening to all
[18:52] <lotuspsychje> hggdh: alive mate?
[19:26] <lotuspsychje> bloody trolls
[19:32] <oerheks> lonely people, on saturday support
[19:33] <oerheks> trolls help each other, despite real issues
[19:33]  * lotuspsychje systematic ignoring
[19:33] <oerheks> nooooooooooooooo.... dont ignore me
[19:33] <lotuspsychje> lol not you
[19:33] <oerheks> oh
[19:34] <oerheks> i am not with the happy few?
[19:34] <lotuspsychje> lucky no
[19:34] <lotuspsychje> the other side :p
[19:35] <lotuspsychje> the twilight zone of discuss
[19:35] <oerheks> https://www.youtube.com/watch?v=zENtEumtyBI
[19:35] <lotuspsychje> lets c
[19:36]  * oerheks banging walls & heads
[19:36] <lotuspsychje> :p
[19:37] <oerheks> Drabber sleeps before the woofer
[19:37] <lotuspsychje> its 21h37
[19:37] <lotuspsychje> sshhhh the neighbours
[19:38] <oerheks> WHAT??
[19:38] <lotuspsychje> lol shhh
[19:38] <lotuspsychje> crazy oerheks is doing it again behind the walls
[19:43] <ducasse> luna just got in a fight
[19:44] <lotuspsychje> ouch
[19:44] <ducasse> there's a black and white cat at a nearby farm that sometimes shows up in my backyard, luna hates it
[19:45] <lotuspsychje> oO
[19:45] <lotuspsychje> territory
[19:45] <ducasse> luckily no injuries
[19:45] <lotuspsychje> yeah that happens easy on cat fights
[19:46] <oerheks> maybe he got lucky
[19:46] <oerheks> half moon
[19:47] <lotuspsychje> how much life has she left ducasse ?
[19:48] <ducasse> dunno, i don't watch her when she's out - let's hope many :)
[19:48] <lotuspsychje> :p
[19:48] <ducasse> how was your day, lotuspsychje + oerheks?
[19:49] <lotuspsychje> great, pancakes at beach
[19:49] <lotuspsychje> customer fixxed w10 this morning
[19:50] <ducasse> mmmm, pancakes!
[19:51] <lotuspsychje> beach was crowded
[19:51] <lotuspsychje> and it was kinda rainy
[19:51] <ducasse> no such luck here, just hot
[19:51] <lotuspsychje> :p
[19:52] <lotuspsychje> had a good friend meeting today ducasse
[19:53] <ducasse> yup :)
[19:53] <ducasse> now soon time for late dinner
[19:54] <lotuspsychje> bon apetit
[19:54] <ducasse> thanks
[20:01] <oerheks> terrible .. parts are expensive
[20:01] <oerheks> :-D
[20:01] <lotuspsychje> markplaats :p
[20:01] <ducasse> oerheks: for the bike?
[20:02] <oerheks> jups
[20:04] <oerheks> i am collecting all parts before i start, make sure that i don't have to go back for one silly bolt or nipple
[20:05] <oerheks> exiting :-D
[20:05] <oerheks> c - exciting
[20:05] <oerheks> so i guess next friday i will have it all together, for one long build-movie
[20:05] <lotuspsychje> then gangsta style bike riding tru haarlem :p
[20:06] <oerheks> yay, with Drabber
[20:06] <ducasse> we'll be watching :)
[20:06] <oerheks> he is my personal bike-alarm
[20:06] <oerheks> and he found out how to jump out of the box, to follow me into a store
[20:06] <oerheks> so i have to put him on a leach :-(
[20:07] <oerheks> "ohhh cute dog" .. drabber, they say you are cute, hahahahhahah
[20:29] <lotuspsychje> nite nite, enough for me :p
[20:29] <lotuspsychje> troll nite :p
[20:30] <pragmaticenigma> So not right lotuspsychje
[20:30] <lotuspsychje> !mint | Vivit
[20:30] <lotuspsychje> what pragmaticenigma ?
[20:32] <pragmaticenigma> lotuspsychje: skipping out after an invitation
[20:32] <lotuspsychje> im still here :p
[20:32] <lotuspsychje> and got some good helper to back me lol
[20:35] <lotuspsychje> nite nite
[20:35] <Vivit> I understand this! All I'm asking is what, based on your experience with official Ubuntu flavors, you think the problem could possibly be. I've looked all over the place with no success. I'm not looking for a solution; I'm just looking for some possible leads!
[20:36] <nacc> Vivit: look in th enetwork manager logs
[20:36] <nacc> Vivit: look in syslog, dmesg
[20:37] <nacc> Vivit: none of this is ubuntu specific, just general debugging, which you can just google about
[20:39] <nacc> Vivit: understand, your question was not any different (even if it feels like it is) to "I'm running SLES, and NM stopped working, what do I do?" There is a line in the sand on what is and what is not "Ubuntu"
[21:21] <Vivit> Hmm it looks line apparmor is denying dhclient from reading something...
[22:32] <Bashing-om> !info linux-image-generic
[22:32] <Bashing-om> :)


[02:02] <ianorlin> meeting?
[02:02] <elky> i guess
[02:03] <DonkeyHotei> i believe the trigger is #startmeeting
[02:04] <elky> it is, yes
[02:05] <elky> #startmeeting
[02:05] <darthrobot> Meeting started Mon Mar 23 02:05:44 2015 UTC.  The chair is elky. Information about MeetBot at https://wiki.ubuntu.com/meetingology.
[02:05] <darthrobot> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[02:05] <elky> #chair ianorlin elky nhaines
[02:05] <darthrobot> Current chairs: elky ianorlin nhaines
[02:06] <pleia2> o/
[02:06] <elky> the agenda is https://wiki.ubuntu.com/CaliforniaTeam/Meetings/15March22
[02:06] <darthrobot> Title: [CaliforniaTeam/Meetings/15March22 - Ubuntu Wiki]
[02:06] <elky> which is empty
[02:06] <lrcaballero> 0/
[02:06] <elky> so i guess we got straight to any other business?
[02:07] <ianorlin> #topic any other business
[02:07] <pleia2> according to the release schedule https://wiki.ubuntu.com/VividVervet/ReleaseSchedule April 23rd is the release date for Vivid
[02:07] <darthrobot> Title: [VividVervet/ReleaseSchedule - Ubuntu Wiki]
[02:07] <pleia2> unfortunately I can't make the time right now to do anything for the bay area :\
[02:07] <pleia2> so if anyone else is interested in stepping up, please do
[02:08] <elky> last one was basically just crunched in to a monthly ubuntu hour wasn't it?
[02:08] <ianorlin> nhianes maybe try something for LA ara
[02:08] <pleia2> I'll likely also be canceling the Ubuntu Hour on April 8th because I'm getting back from a trip right before then, so if someone else wants to run it, that'd be great, I'll also reach out to Michael Paoli, who has subbed in the past
[02:08] <pleia2> re: San Francisco
[02:09] <lrcaballero> I will get a hold of Phil here in San Diego and see if do something at Starbucks...
[02:09] <lrcaballero> for the release that is....
[02:09] <pleia2> elky: there was a proper release party at Mozilla last cycle, but I wasn't around and it wasn't very well promoted :\
[02:09] <pleia2> lrcaballero: great :)
[02:10] <elky> pleia2: ah. actually i do recall that yes
[02:10] <pleia2> and there was also supposed to be a presented, but they pulled out last minute
[02:10] <pleia2> all kind of a mess really
[02:10] <pleia2> s/presented/presenter
[02:10] <pleia2> I don't remember the details about that
[02:11] <pleia2> anyway, it would be lovely to have a more successful one :)
[02:11] <pleia2> I think that's all I've got
[02:12] <elky> did you go to the eps memorial thing or were you out of town?
[02:12] <pleia2> I did, DonkeyHotei was also there
[02:12] <pleia2> it was very nice, good pizza, good company :)
[02:14] <DonkeyHotei> i just wish i hadn't been sick
[02:14] <ianorlin> I don't think anyone likes being sick
[02:15] <DonkeyHotei> hopefully no one caught it
[02:15]  * pleia2 feels good
[02:19] <pleia2> so... anything else?
[02:19] <elky> not from me
[02:20] <elky> looks like nhaines couldn't break away from his lucrative babysitting gig
[02:20] <lrcaballero> Thank you guys....I will see you next time :-D
[02:20] <lrcaballero> Good Night!
[02:21] <elky> thanks for coming along
[02:21] <pleia2> night all
[02:21] <elky> DonkeyHotei: ianorlin: nothing from either of you i assume?
[02:22] <DonkeyHotei> well, we could discuss meeting cancellation procedures, but that's best put on the next agenda
[02:23] <elky> indeed
[02:25] <elky> ok well i guess i'll close out
[02:25] <elky> #endmeeting
[02:25] <darthrobot> Meeting ended Mon Mar 23 02:25:18 2015 UTC.
[02:25] <darthrobot> Minutes:        http://ihas.5cat.com/~darthrobot/ubuntu-us-ca/2015/ubuntu-us-ca.2015-03-23-02.05.moin.txt
[04:53] <nhaines> elky: thanks for running the meeting tonight (and thanks for volunteering to help out if she couldn't make it, pleia2!).  I saw that the meeting log came in handy to someone interested in the Ubuntu Hour, so I'm glad it did go through.


 Has anyone else seen this?
[01:36] <marienz> that's firefox 4.0~b8~hg20101008r55


[13:27] <fish_> hrm, is this really a complete? https://help.ubuntu.com/12.04/installation-guide/example-preseed.txt
[13:27] <fish_> it also says 'squeeze' on top ;)
[19:19] <antarus> hrm
[19:19] <antarus> is Trusty going with new netowrk names
[19:19] <antarus> or keeping ethX naming?