[01:45] <psusi> anyone know how to get emacs to find the right source file when using gdb?  it doesn't seem to have the right search path for the file names gdb is emitting and the info page is useless.
[02:02] <YokoZar1> The Maverick Me Menu currently enforces one character tweets.  Because 140 is way too many ;)
[02:08] <ScottK> That's where it was bound to end up eventually anyway.
[03:00] <psusi> cjwatson, was it you that I talked with several months back about dropping the Ubuntu deviations to parted and dmraid that strip the 'p' character separating the base device from the partition number for dmraid devices?
[04:53] <mwhudson> hi, i have a package who's postinst is failing
[04:54] <mwhudson> is there some way i can lie to my system and say that it's configured ok, so that it doesn't fail every time i run apt?
[04:54] <ajmitch_> you can be evil & edit the postinst in /var/lib/dpkg/info/package.postinst, just start it off with an exit
[04:55] <ajmitch_> this won't stick around when you upgrade it, but will get you past the failing postinst
[04:55] <mwhudson> in the land of kernel bugs, evil is king
[04:55] <mwhudson> or something
[04:55] <mwhudson> thanks anyway :)
[05:03] <slangasek> what sort of kernel bug? :)
[05:04] <mwhudson> slangasek: one that causes partitions from the sd card to be mounted read only on beagle boards
[05:05] <slangasek> ah, fun
[05:05] <mwhudson> which specifically makes update-initramfs' postinst not happy
[05:05]  * slangasek nods
[06:02] <mwhudson> are there any mirrors of ports.ubuntu.com ?
[06:20] <oracle> featurefreeze?? why!?
[06:26] <mwhudson> oracle: because. https://wiki.ubuntu.com/MaverickReleaseSchedule
[06:30] <oracle> my battery was lasting a great deal shorter on fedora 11 than this ubuntu 10, did someone improve something?
[06:32] <pitti> Good morning
[06:46] <pitti> SpamapS: I just added you to the WI tracker team, so you can commit directly
[06:54] <SpamapS> pitti: thanks! :) Any way you can have the errors cc'd to the team mailing list?
[06:54] <SpamapS> pitti: btw, I don't do Tae Kwon Do, I do Kenpo Karate.. but they're very similar. :)
[06:55] <pitti> SpamapS: oh, right, I should set up a ML for that team
[07:05] <pitti> SpamapS: ML created, I need to wait for a few minutes until it works
[07:16] <SpamapS> pitti: how long have you been training in TKD?
[07:17] <pitti> SpamapS: since about 2001
[07:17] <pitti> SpamapS: with about 1.5 years of break in between
[07:18] <pitti> SpamapS: but I'm not that much of a fighter :) we don't do a lot of sparring
[07:18] <SpamapS> pitti: I've been doing Kenpo for 3 years now. Great fun.
[07:18] <pitti> SpamapS: we should exchange experiences over a beer in Orlando!
[07:18] <SpamapS> pitti: yes for sure. :)
[07:20] <lifeless> I can add some aikido yoshinkan in there
[07:20] <lifeless> (more talk -> longer discussion -> moah beer)
[07:21] <pitti> lifeless: sounds like a good plan
[07:21] <lifeless> pitti: hey how are the retracers
[07:21] <pitti> SpamapS: you should see it now on https://edge.launchpad.net/people/+me/+editemails
[07:21] <pitti> lifeless: haven't checked again yet
[07:21]  * pitti restarts them
[07:21] <lifeless> pitti: please do?
[07:22] <lifeless> thanks
[07:22] <pitti> SpamapS: cronjob updated to mail the ML
[07:23] <SpamapS> beer + martial arts + code == the beginnings of an awesome game engine? ;)
[07:23] <SpamapS> pitti: sweeeet
[07:24] <pitti> lifeless: seems the amd64 one is quite happy, it's been running since about midnight
[07:24] <SpamapS> lifeless: I'd like to echo the sentiments of whoever said "launchpad seems faster today" .. I feel a bit more productive in bug management in general lately. :)
[07:24] <lifeless> ok great
[07:24] <lifeless> SpamapS: thanks!
[07:24] <lifeless> SpamapS: (you could send it to the list, I'm sure the other devs would love to hear that)
[07:27] <SpamapS> lifeless: will do :)
[07:55] <pitti> argh, could LP please stop importing bug comments from 3 years old closed bugs which nobody ever looks at any more..
[07:55] <pitti> or at least, stop telling about them
[07:56] <bilalakhtar> pitti: does LP import bug comments from other trackers? really?
[07:57] <pitti> apparently so
[08:45] <apw> SpamapS, pitti,
[08:45] <apw> how is the tracker today
[08:53] <pitti> tkamppeter: is there a bug about smbd not waiting for cups?
[09:03] <apw> SpamapS, just did a local run of the generators and its not regenerating the older svgs
[09:04] <pitti> apw: you might need to run with -a for that
[09:04] <pitti> I think it's not regenerating older milestone charts by default
[09:04] <pitti> (to save cycles)
[09:04] <apw> pitti, would the installed version also be -a or not -a
[09:04] <pitti> not -a by default
[09:04] <apw> as i think we need an expensive run to fix the older graphs
[09:04] <pitti> due to the per-user charts, it currently takes aaages
[09:04] <pitti> yes, we can run it once with -a for taht
[09:05] <apw> i'll run it now to confirm they are fixed
[09:05] <pitti> cheers
[09:34] <apw> pitti, yeah that fixed the broken lines for me (-a)
[09:34] <apw> pitti, do we do one -a per day still ?
[09:41] <fargiolas> what is the better place to put gconf based customizations (let's say I want to build a custom ubuntu variant) so that they are kept over updates? is /usr/share/gconf/defaults dir meant for this kind of job?
[09:45] <pitti> apw: http://bazaar.launchpad.net/~work-items-tracker-hackers/launchpad-work-items-tracker/trunk/revision/225
[09:46] <apw> pitti, looks good
[09:50] <pitti> tkamppeter: I committed upstartification into cups trunk, if you want to test
[09:55] <tkamppeter> pitti, great. will try.
[09:56] <pitti> tkamppeter: it still causes smbd to hang if I stop/start it manually (will discuss with Keybuk), but on a normal boot, both are running
[10:01] <tkamppeter> pitti, some questions:
[10:02] <tkamppeter> pitti, is the "author" field really for the upstream author of the program to be started? Or is it for the author of the upstart script?
[10:03] <pitti> tkamppeter: not sure; gdm uses the upstream one, smbd has slangasek
[10:03] <tkamppeter> pitti, the "pre-start script" (I assume that this is a shell (sh) script) has
[10:03] <tkamppeter> [ -x /usr/sbin/cupsd ]
[10:03] <pitti> tkamppeter: right, it's a sh -e script
[10:03] <pitti> for preparing the environment, see man 5 init
[10:04] <tkamppeter> as first line. does this really make sense? Should it not be something like
[10:04] <pitti> tkamppeter: that'll fail the job if cupsd doesn't exist
[10:04] <pitti> tkamppeter: since the script is set -e
[10:04] <tkamppeter> [ -x /usr/sbin/cupsd ] || exit 1
[10:05] <ion> That’s just redundant
[10:05] <ion> OTOH, it documents itself better.
[10:05] <ion> OTOH, anyone editing the code should be familiar with the semantics of sh and set -e anyway. :-P
[10:06] <tkamppeter> OK.
[10:16] <tkamppeter> pitti, I have looked into the upstart script now and it looks much simpler than an init script. Looks like upstart takes a lot of repeated stuff away from the developer or admin.
[10:18] <pitti> right, I could drop all the pidfile and status handling
[10:35] <tkamppeter> pitti, in the init script there are code sections "Get the timezone set" and "restart xprint". They are not in the upstart script. Are they obsolete?
[10:35] <pitti> tkamppeter: I tested logs and jobs, and they have teh correct timezone without setting $TZ
[10:36] <pitti> tkamppeter: I dropped xprint because handling it there would also require upstartification of xprint, and we don't really support xprint in Ubuntu anyway
[10:37] <tkamppeter> pitti, the init script also contains
[10:37] <tkamppeter> chown root:lpadmin /usr/share/ppd/custom 2>/dev/null || true
[10:37] <tkamppeter>         chmod 3775 /usr/share/ppd/custom 2>/dev/null || true
[10:37] <tkamppeter> Is this not needed any more?
[10:37] <pitti> that should go into the postinst; no need to do it on every start
[10:39] <pitti> tkamppeter: (it's in bzr now)
[10:42] <tkamppeter> pitti, the debian/changelog has a small bug: The first item of my changes should start with debian/patches/default-ripcache-size-auto.dpatch. We had the patch before, we do not "Add" it.
[10:43] <pitti> tkamppeter: ah, thanks; fixed
[10:44] <pitti> tkamppeter: I merged the two maverick changelogs, since these aren't appropriate for a Debian upload
[10:55] <tkamppeter> pitti, upstartification of CUPS seems to work well for me. There is even a backward compatibility interface, to comply with the LSB (very important for LSB-based driver packages).
[10:56] <pitti> right
[10:57] <pitti> tkamppeter: I added some preinst code to clean up the old init script; you shouldn't have any /etc/rc*/*cups* any more, and /etc/init.d/cups should be a symlink
[11:14] <tkamppeter> pitti, clean-up works. Only thing to be done is now to coordinate with Keybuk so that the smbd script does not hang on manual operation.
[11:14] <pitti> right, I'm waiting for him
[11:22] <quadrispro> diwic_lunch, do you need help to push new fluidsynth release to git?
[11:23] <tkamppeter> pitti, are my Jockey patches OK?
[11:23] <pitti> still no time to look at them, sorry
[11:24] <diwic> quadrispro, hi there!
[11:24] <diwic> quadrispro, if you want to do something, be my guest :-)
[11:25] <quadrispro> diwic, well, you'll see my changes soon
[11:26] <diwic> quadrispro, should we try to get the LADSPA stuff up and working again?  Congratulations!
[11:27] <quadrispro> lucidfox, yep, get my new status on May, thanks! :)
[11:27] <lucidfox> May? o_O
[11:27] <quadrispro> diwic, well, having a look
[11:28] <lucidfox> and only just changed fluidsynth?
[11:29] <quadrispro> lucidfox, no, did a lot of stuff :)
[11:33] <cjwatson> mvo: could you have a look at bug 637517?
[11:37] <quadrispro> diwic, I've switched the packaging to the 3.0 (quilt) format, so remember to run quilt pop -a after git-build'ing the package
[11:39] <coolbhavi> hello archive admins, can you please sync https://bugs.launchpad.net/bugs/636822 as users like this package to be in sync with upstream as possible and personally I would like to see updated networks support in maverick
[11:42] <diwic> quadrispro, okay
[11:43] <diwic> quadrispro, thanks for your contribution :-)
[11:43] <Laney> cjwatson: I might sync f-spot manually in lieu of an immediate fix to that bug, if that's OK? Or would you rather use it as a test case?
[11:44] <quadrispro> diwic, we should move talking about fluidsynth in #debian-multimedia chan (on OFTC)
[11:47] <cjwatson> Laney: I have another test case, though was sort of hoping to build up pressure on that bug ;-)
[11:47] <Laney> cjwatson: final freeze is building up pressure on me ;)
[11:47] <cjwatson> coolbhavi: I've been doing sync runs daily; there's no need to ask
[11:47] <cjwatson> coolbhavi: get a sponsor to ack it and it will be done
[11:48] <coolbhavi> cjwatson, okay!
[12:06] <mvo> cjwatson: sure, will do
[12:17] <directhex> cjwatson, my proposed fix would work. all we need is for Mike Gemünde to legally change his name to an ascii-only one, then the problem goes away.
[12:18] <apw> cjwatson, when one boots the maverick beta image, let the burning man be, and then chose try ubuntu from the subsequent menu, the machine seems to hang for several minuts (about 3 on an atom) and apparently there is a large lzma running then, is this expected?
[12:19] <cjwatson> apw: I don't know really
[12:19] <cjwatson> apw: the initrd is lzma-compressed for space reasons
[12:19] <cjwatson> do you mean that early?
[12:19] <apw> i mean that early and for that long yeah
[12:19] <cjwatson> not really much I can do
[12:19] <apw> i have the try/install dialog for several minutes there
[12:20] <apw> seems to be new behaviour is all
[12:20] <cjwatson> it's been lzma-ed for a while
[12:20] <ogra> get a faster CPU :)
[12:20] <apw> ogra, you can talk!
[12:20] <ogra> use ARM !
[12:20] <apw> if an atom is struggling i don't see an arm finding it easy
[12:20] <cjwatson> I'm not going to have time to look into it, I'm afraid; if you do and find something untoward, I'd be happy to look at fixing it
[12:21] <ogra> apw, you havent used omap4 yet :)
[12:21] <cjwatson> but I have my hands full with EFI
[12:21] <apw> ogra, noone has :)
[12:21] <apw> cjwatson, fair enough, will see if i can determine what its doing it do and whether it is necessary
[13:58] <smoser> pitti, ping. https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/634102 is ready for sru review.  I don't think i've left anything un-done.  could you, or someone on the sru review team, please review ?
[14:02] <kristian014> hello
[14:03] <kristian014> does anyone speak english?
[14:03] <amitk> kristian014: that would be the default language
[14:03] <kristian014> i need somebody to translate for me
[14:03] <kristian014> isn't this a polish chat?
[14:03] <amitk> it isn't a polish channel
[14:04] <kristian014> ooohh ok
[14:04] <kristian014> sorry
[14:04] <kristian014> so does anyone speak polish??? lol
[14:05] <cjwatson> try #ubuntu-pl
[14:05] <kristian014> ok
[14:05] <kristian014> thanks
[14:16] <seb128> cjwatson, ev: hi, how is ubiquity installing translations?
[14:16] <seb128> does it use aptdaemon?
[14:16] <ev> seb128: langpacks?
[14:17] <seb128> yes
[14:17] <seb128> ev: bug #630924
[14:17] <ev> indeed, it's on my list
[14:17] <seb128> I'm wondering if you need a change similar to bug #612825
[14:18] <seb128> ev: ie http://bazaar.launchpad.net/~ubuntu-core-dev/language-selector/ubuntu/revision/380
[14:18] <seb128> dpm, ^
[14:19] <dpm> ah, thanks seb128, ev
[14:20] <seb128> ev: well I just wanted to point the language-selector change in case that was useful
[14:20] <pitti> hello smoser; I'll do an SRU round at some point this week, yes
[14:20] <ev> seb128: no, it doesn't use aptdaemon.  It uses python-apt with Dir set to /target.
[14:20] <seb128> ev: ok, ignore me then ;-)
[14:20] <ev> heh
[14:20] <ev> thanks for the pointer though
[14:20] <smoser> pitti, thanks.
[14:22] <sebner> bad seb128 uploaded b0rken nautilus :P
[14:22] <seb128> sebner, how broken?
[14:23] <sebner> seb128: pretty, https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/637704
[14:23] <seb128> sebner, it works for me at least
[14:23] <seb128> sebner, wfm
[14:23] <sebner> :\
[14:24] <seb128> we didn't get any complain on #ubuntu-desktop or other bugs
[14:24] <sebner> seb128: well, at least 5 people seem affected
[14:24] <sebner> 8 even
[14:25] <seb128> I guess one of those 8 people need to debug the issue
[14:26] <sebner> seb128: /me offers himself if you provide guidance
[14:26] <seb128> sorry but ENOCLUE about that
[14:26] <seb128> seems a libunique issue
[14:27] <sebner> meh
[14:27] <seb128> did you restart your session since the upgrade?*
[14:27] <seb128> or nautilus?
[14:28] <sebner> seb128: let me check
[14:29] <sebner> seb128: wuhhh, the magic of open source strikes again :D
[14:30] <mpt> cjwatson, doko: How can I find out whether a particular package has an archive override? (fonttools and fonttools-eexecop are the two packages I'm interested in)
[14:30] <seb128> sebner, works after restart?
[14:30] <sebner> seb128: yep, sorry for the noice
[14:30] <sebner> *noise
[14:31] <seb128> pedro_, ^
[14:31] <pedro_> cool!
[14:31] <Laney> can't nautilus arrange to bring that service up?
[14:31] <pedro_> thanks for the info sebner
[14:32] <seb128> Laney, it will be a non issue for upgrade from lucid
[14:32] <seb128> Laney, the port to gapplication was only during the unstable cycle and reverted
[14:32] <Laney> oh ok
[14:33] <sebner> Laney: :)
[14:39] <talat> hi i want to try develop a application that lets you uncharge and recharge the battery/ specify min. battery level on which to start charging.
[14:40] <talat> change show a road for development i dont now where i must start
[14:43] <talat> summury how can i control charing on ubuntu
[14:43] <talat> ?
[14:48] <talat> how can i control charging on ubuntu ?
[14:57] <cjwatson> mpt: all packages have overrides
[14:57] <cjwatson> mpt: you can look at what the overrides say by looking in the /ubuntu/indices/ directory on mirrors
[14:58] <pitti> talat: the upower daemon (talk to it via dbus) tracks the charge level of the laptop battery, and also from devices
[14:58] <pitti> talat: you can connect to it with the libupower-glib library, or via dbus directly, and listen to charge change signals
[14:58] <pitti> talat: check "upower --monitor-detail" whether it knows about your's
[14:59] <mpt> cjwatson, excellent, found just what I wanted, thanks. Now where do I report a bug that an override is incorrect? On the package itself, or somewhere else?
[15:00] <cjwatson> mpt: doesn't matter exactly where (on the package itself is as good as any), but the important thing is to subscribe ubuntu-archive to the bug
[15:00] <mpt> ok, thanks
[15:02] <talat> pitti, upower give me some information. But how can disable charing ?
[15:02] <pitti> you can't
[15:02] <pitti> talat: assuming that you mean "charging"
[15:02] <pitti> that's done by the hardware
[15:02] <pitti> well, and BIOS, I assume
[15:03] <pitti> there might be some machine specific tricks how to control it, but if there are, they aren't supported or known to me
[15:03] <superm1> some hardware will have a hotkey to do it, but when it does, generally the BIOS is responsible and only sends a notification to the OS that it did it
[15:06] <talat> superm1, pitti very interseting i dont think why i cant control my charger status. I guess electronical reponse.
[15:07] <psusi> cjwatson: got a moment to talk about grub2, dmraid, and the ubuntu specirfic patches to remove the 'p' character from the names to separate the partition number from the base name?
[15:12] <cjwatson> psusi: so, mostly I was just trying to avoid changing things, having only been reminded of this last week
[15:13] <cjwatson> seems a bit late for a transition
[15:13] <cjwatson> psusi: if you think it's actively important for some reason, we can do it, but I do know dmraid seems to be rather undertested just now
[15:13] <cjwatson> figuring out what's wrong with grub2 on dmraid is on my to-do, since I've had a number of reports of problems and I suspect some of them are upstream
[15:13] <psusi> cjwatson: I started looking at it again because ther was a post on the forums about grub failing to install now on dmraid.. so I started testing it last night, figuring it was because of the p... that grub-probe was getting confused by the device name when trying to identify the underlying device and partition number without the p
[15:14] <psusi> so I dropped the patch to dmraid, and modified a patch to parted that had the same effect, and got the p showing up in the device name again, and the install worked up until it tried to install grub, where grub-probe still fails
[15:15] <cjwatson> right, I can't offer specific advice there although I will be able to fix it once I have a chance to sit down and reproduce it ...
[15:15] <psusi> the purpose of grub-probe is what exactly?  to map the kernel device you are trying to install on to a bios disk, partition, abstraction module, and fs?
[15:15] <cjwatson> roughly yes
[15:16] <cjwatson> also determines whether the boot loader will be able to read a particular file
[15:16] <psusi> and how can it possibly do that with dmraid? ;)
[15:16] <psusi> other than just assuming a dmraid device is hd0?
[15:16] <cjwatson> grub has a certain amount of raid support
[15:16] <cjwatson> which can be extended to dmraid
[15:16] <cjwatson> but in any case it can probably just pick a disk and read off it
[15:17] <psusi> well that's the thing... with dmraid you DON'T use a raid abstraction module, since the bios takes care of it
[15:17] <cjwatson> well then, there should be little problem
[15:17] <cjwatson> it just needs to know that at the right time, that's all
[15:18] <psusi> yea, so I think grub-probe needs to notice it's a dmraid device, split the partition number off, and assume the base device is hd0... I think... hrm...
[15:18] <cjwatson> I don't expect that there's a particular boot-time problem - it'll just be a matter of tedious OS device manipulation
[15:19] <cjwatson> this is stuff I've done before
[15:19] <cjwatson> in fact I *did* get it working at one point
[15:19] <cjwatson> it has obviously bitrotted a bit
[15:19] <psusi> yea, it worked in lucid
[15:20] <cjwatson> but if you look at e.g. util/deviceiter.c you'll see a good deal of dmraid-specific code, written by me
[15:20] <cjwatson> it just needs to be debugged back into a working state, that's all
[15:20] <psusi> ahh
[15:20]  * psusi reads on
[15:20] <psusi> so did you just have it assume a dmraid device is hd0 or did you come up with some magic to figure it out?
[15:21] <cjwatson> forget about hd0
[15:21] <cjwatson> the drive ordering doesn't particularly matter these days anyway
[15:21] <cjwatson> it just sticks any dmraid arrays on the end of the enumeration
[15:21] <psusi> the mbr needs a bios disk number to read in the core doesn't it?
[15:21] <cjwatson> nope
[15:21] <psusi> how does it manage that?
[15:22] <cjwatson> in the Unix-land utilities, we need a drive number in order to have a consistent bidirectional mapping, and otherwise it's irrelevant nowadays
[15:22] <cjwatson> at boot-time, two things
[15:23] <cjwatson> firstly, the core image is normally embedded right after the MBR, on the same disk, so it can just use %dl which the BIOS gives it
[15:23] <cjwatson> secondly, the core image finds everything else using UUIDs
[15:23] <cjwatson> (actually, if /boot is on the same disk as the core image, that's optimised away, and we just store the partition number)
[15:23] <psusi> theoretically the bios is supposed to pass the mbr the bios disk number it was loaded from in the CL register, but I learned from working on the ReactOS boot loader that not all bioses do, which is why dos etc always hard code it to 80 in the mbr
[15:24] <cjwatson> what usually happens is that the disk you boot from magically becomes 0x80 for that boot
[15:24] <SpamapS> apw: add --all-milestones to generate the old milestones
[15:24] <psusi> was it dl?  hrm... thought it was cl... either way
[15:24] <cjwatson> but grub's mbr does have some sanity checks for things going wrong
[15:24] <cjwatson> it's dld
[15:24] <cjwatson> dl
[15:24] <cjwatson> anyway, none of that is dmraid-specific
[15:25] <psusi> yea, that's the other industry standard kludge... since does hard codes 80, the bios just makes whichever disk you boot from 80 ;)
[15:25] <cjwatson> we set dl to 0x80 if it looks wrong, and otherwise use what we're given
[15:25] <cjwatson> if it has the top bit set, it's generally right
[15:25] <Sarvatt> what's the process for requesting a binary only pocket change for a package? libgl1-mesa-dri-experimental (which contains nouveau dri) is completely unsupported by upstream and is in main currently
[15:25] <psusi> I see...
[15:26] <cjwatson> Sarvatt: file bug, subscribe ubuntu-archive, we'll figure it out from there and ask you for more if need be
[15:26] <Sarvatt> thanks!
[15:27] <cjwatson> there was a patch on grub-devel recently for some dmraid issue, I think, which I haven't reviewed yet
[15:27] <psusi> that's another oddity I've noticed... grub sets the device by name in the cfg, then uses the search command to search by uuid... seems redundant doesn't it?
[15:28] <psusi> but that's neither here nor there... I'll go read code
[15:28] <psusi> ohh, but you think it is too late then to drop the 'p' removal for mav?
[15:29] <cjwatson> the 'set root' + search --fs-uuid is really just insurance
[15:29] <cjwatson> yes, it's redundant, it's a just-in-case kind of thing.  occasionally it helps and it doesn't hurt
[15:29] <cjwatson> dropping 'p'> I'd say only if it's needed to fix installation
[15:30] <cjwatson> if it's needed, fine, we can do it
[15:30] <psusi> heh, actually I ran into a situation where it does hurt... if you have multiple devices with the same uuid... like if you have an lvm snapshot ;)
[15:30] <cjwatson> otherwise, sorry for forgetting it until now; I had incorrectly been thinking that it was bound up with lvm2, and it wasn't until I went to update lvm2 that I remembered that was wrong
[15:30] <cjwatson> psusi: what I mean is that the 'set root' doesn't hurt
[15:30] <cjwatson> LVM snapshots should be explicitly avoided in maverick
[15:31] <cjwatson> if you can demonstrate this not happening correctly, it is a bug
[15:31] <psusi> speaking of lvm2... when I installed it on the daily livecd last night, I got a bunch of errors... it seemed to be a result of it pulling in watershed and/or trying to rebuild the initrd
[15:31] <cjwatson> but GRUB's LVM code definitely tries to avoid snapshots
[15:31] <cjwatson> installing things that update the initramfs on the live CD is generally tricky
[15:32] <psusi> I thought the trigger noticed it was on livecd and just bailed out
[15:32] <cjwatson> FWIW, in general, anything that tries to use (hd0) or (hd0,1) type addressing at boot time in GRUB these days, without having a UUID search as well, is deprecated
[15:32] <cjwatson> it's still supported because there'll be user configuration using it
[15:33] <cjwatson> and it's easier to type at rescue mode or whatever
[15:33] <cjwatson> but long-term it isn't reliable and can't really be made reliable
[15:34] <cjwatson> there's somebody who sits spamming grub2 bugs on LP about how GRUB doesn't match BIOS drive ordering, missing the point that (a) there's no way for it to do so and (b) if it matters then it's a bug
[15:34] <psusi> heh
[15:34] <cjwatson> (yes, there's EDD.  it's supported on a subset of hardware, and the contortions required to get at it from userspace and do anything useful with it are moderately hideous)
[15:36] <psusi> yea, reminds me of floppy detection... technically the drives were supposed to respond to a detect command to find out their size and capacity... but nobody bothered implementing that part of the spec, which is why you had to go into the bios and tell it what kind you plugged in... and the os has to get that from the bios and trust it... leading to idiots complaining that Ubuntu shows them a...
[15:36] <psusi> ...floppy when they don't have one...
[15:37] <psusi> who then complain when told to stop telling their bios they have one
[16:11] <pitti> Keybuk: hello, how are you?
[16:11] <pitti> Keybuk: I have a question about cups upstartification; do you have a minute for that?
[16:11] <Keybuk> for you, I have ten
[16:13] <Keybuk> and I do apologise, my brain has a lot of "new upstart" in it, so I might have to think how the current version behaves
[16:20] <slangasek> pitti: FWIW, I understood that the chmod/chown in the cups init script was because admins might drop local files in this directory (ignoring the FHS); but maybe this was just wishful thinking on my part :)
[16:23] <pitti> Keybuk: I created an upstart script and added the necessary transition bits (http://bazaar.launchpad.net/~pitti/cups/debian-trunk/revision/893); starting/stopping cups works, and booting works as well (both smbd and cups are running)
[16:24] <pitti> Keybuk: but if I "stop cups; stop smbd", and "start smbd", (or even manually start cups), the start smbd keeps hanging forever, and "status smbd" says "smbd stop/starting"
[16:24] <pitti> Keybuk: do you have a hint how I can debug that?
[16:26] <Keybuk> right
[16:26] <Keybuk> you'd need to restart dbus too
[16:26] <Keybuk> and restart the filesystem ;-)
[16:27] <pitti> I don't understand
[16:28] <pitti> so smbd blocks on what exactly?
[16:28] <pitti> status cups says "started"
[16:28] <pitti> so smbd could just go?
[16:28] <Keybuk> ok
[16:28] <Keybuk> let me work it through with you
[16:28] <Keybuk> so you've just run stop cups; stop smbd
[16:28] <Keybuk> and everything looks fine
[16:28] <Keybuk> now you run
[16:28] <Keybuk> # start smbd
[16:28] <Keybuk> upstart will begin starting that job
[16:28] <Keybuk> the first thing it emits is the "starting smbd" event
[16:28] <Keybuk> and it will _WAIT_ for that event to complet
[16:28] <Keybuk> --
[16:29] <Keybuk> so upstart looks for jobs with "on starting smbd", in this case cups
[16:29] <Keybuk> cups isn't running (you stopped it), so cups will take the event
[16:29] <Keybuk> but cups needs (you used "and") started dbus and filesystem too
[16:29] <Keybuk> so cups isn't ready to start yet
[16:29] <Keybuk> but because cups is holding the event, smbd isn't ready to start yet either
[16:30] <Keybuk> it's a great example of bug #447654
[16:31] <pitti> Keybuk: hm, but that even happens if I start cups before
[16:31] <Keybuk> sure
[16:31] <Keybuk> let's work that one
[16:31] <Keybuk> --
[16:31] <Keybuk> back at stop cups; stop smbd and everything is ok
[16:32] <Keybuk> now you start cups, and cups *finishes starting*
[16:32] <Keybuk> once again, it's in a reset state (the start on bit has been cleared)
[16:32] <Keybuk> so start smbd, will cause "starting smbd", which will get picked up by the cups job for the next time it's started
[16:32] <pitti> right, we are at
[16:32] <pitti> $ status cups; status smbd
[16:32] <Keybuk> so it's still blocked
[16:32] <pitti> cups start/running, process 1751
[16:32] <pitti> smbd stop/starting
[16:32] <pitti> here
[16:32] <Keybuk> right
[16:32] <Keybuk> # initctl emit started dbus
[16:32] <Keybuk> # initctl emit filesystem
[16:32] <Keybuk> err
[16:32] <Keybuk> sorry
[16:32] <Keybuk> # initctl emit stopped udevtrigger
[16:32] <Keybuk> not filesystem
[16:33] <Keybuk> not sure why I had filesystem in my brain here
[16:33] <pitti> ah, because it literally is "start cups when smbd starts", not really "cups needs to be started in order for smbd to start"
[16:33] <Keybuk> yes
[16:33] <Keybuk> basically
[16:33] <Keybuk> what you've said there is
[16:34] <pitti> argh, meeting now, back in 20 mins or so (sorry)
[16:34] <Keybuk> "if smbd starts, wait for dbus and udevtrigger, then start cups"
[16:34] <Keybuk> (and let smbd start)
[16:34] <Keybuk> that can also work in the other order
[16:34] <Keybuk> "after dbus and udevtrigger, when smbd starts, start cups then let smbd start"
[16:34] <Keybuk> the problem is that once cups has started, it forgets that dbus and udevtrigger have been
[16:35] <Keybuk> so if you ever "stop cups" you'll have to restart all those other things
[16:36] <tkamppeter> Keybuk, is there no possibility for "make sure that the cupsd is running when smbd is started"?
[16:37] <Keybuk> not currently, Upstart doesn't work that way
[16:37] <Keybuk> in fact, if anything, it's designed to stop you doing that
[16:37] <Keybuk> because "what if the user doesn't *want* cups running?"
[16:37] <Keybuk> and "what if the user has disabled the init script?"
[16:37] <Keybuk> and "what if the init script is still there, but the package is uninstalled?"
[16:37] <Keybuk> etc.
[16:37] <cjwatson> this all became much easier for me to think about when I realised that upstart start* and stop* events are events which are emitted at certain times and which block until all the jobs hung off them have reached their desired state
[16:38] <cjwatson> rather than some kind of different abstraction
[16:38] <Keybuk> well, that's all they are :p
[16:38] <cjwatson> it was a bit like the epiphany where I realised that Verilog (a VHDL) was NOT NOT NOT procedural despite looking like it was
[16:38] <Keybuk> few people realise that's how Upstart works
[16:38] <cjwatson> and thereby managed not to fail my second year CS project ;-)
[16:38] <Keybuk> I like to explain it like this:
[16:39] <Keybuk> you have a conveyor belt
[16:39] <Keybuk> at one end you put things ("events)" on it
[16:39] <Keybuk> and at the other end is a great big masher that bond villains habitually fall into
[16:39] <Keybuk> (nobody knows why, they just do, it has to be factored into the janitorial budget)
[16:39] <Keybuk> emitting an event is making something and putting it on the conveyor
[16:40] <Keybuk> and you're allowed to attach a piece of string to it if you like
[16:40] <Keybuk> if you do, you know the event got mashed because the string went limp and you can do something else
[16:40] <Keybuk> if you don't, you don't care
[16:40] <cjwatson> ... I think I'll stick with my current mental model :-)
[16:40] <Keybuk> so you can put an event on, wait for it to get mashed (using the string), and then put another event on, or carry on with what you're doing
[16:40] <Keybuk> now, along the conveyor are the jobs
[16:40] <Keybuk> they're allowed to take events off
[16:40] <Keybuk> as long as they put them back when they're done
[16:41] <psusi> I like it... attach string to second object, and when first object gets mashed, it pulls the second onto the belt
[16:41] <Keybuk> psusi: exactly
[16:41] <cjwatson> the thing that doesn't quite help with is that more than one job can take an event off the conveyor at the same time (right?)
[16:41] <cjwatson> at which point the metaphor kind of breaks down a bit
[16:42] <Keybuk> well, I guess
[16:42] <Keybuk> but I like my metaphor
[16:42] <Keybuk> :p
[16:42] <cjwatson> well, not at the same time exactly, but concurrently anyway
[16:42] <psusi> I see jobs as just a part of the conveyor belt... more jobs = longer belt
[16:42] <Keybuk> maybe jobs get to put a kind of string on that stops things falling into the conveyor?
[16:42] <mohanohi> there is an ever long bug in ubuntu : http://brainstorm.ubuntu.com/idea/15648/
[16:42] <mohanohi> will it be solved?
[16:43] <Keybuk> anyway, the key point as psusi says is that jobs themselves make events
[16:43] <Keybuk> so jobs can line up waiting for other jobs
[16:43] <Keybuk> and things can get stuck because they're waiting for things that got mashed
[16:43] <mohanohi> eating lot of ram while copying to usb 2.0 drives files more than 1-2 gb
[16:43] <mohanohi> and slowing down the transfer rate
[16:45] <cjwatson> mohanohi: (not that this has anything to do with me, but) has somebody narrowed it down to the particular component of the OS that's causing a problem, and filed a proper bug?
[16:45] <psusi> but can't events be both level or edge triggered?  like the run level... it's level... it never gets mashed, it just is
[16:45] <mohanohi> cjwatson: donno
[16:45] <Keybuk> psusi: no, they're always edge in upstart
[16:46] <mohanohi> its around 2008
[16:46] <Keybuk> the "state" of the runlevel is handled in /var/run/utmp
[16:46] <Keybuk> when you run telinit, it reads this to get the PREVLEVEL and puts the argument in RUNLEVEL
[16:46] <Keybuk> otherwise it's just an event "runlevel $RUNLEVEL $PREVLEVEL" is treated no differently than "control-alt-delete"
[16:46] <Keybuk> it happens, if you missed it, go read utmp
[16:49] <tkamppeter> auto-closing bugs on uploads with the fix did not return to work yet?
[16:50] <psusi> so if you make a job start on runlevel 3, it will only start when you SWITCH to runlevel 3?  but if you're already at runlevel 3 and the job isn't running, it won't be started?
[16:50] <tyarusso> psusi: correct
[16:51] <psusi> bummer
[16:51] <tyarusso> psusi: Otherwise it would be impossible to stop a service.
[16:51] <psusi> good point
[16:52] <psusi> so how do you make sure a newly installed service is started?  if you manually start it, but it isn't supposed to be running in the current runlevel....
[16:53] <Keybuk> bug #307779
[16:53] <psusi> heh
[16:54] <ion> psusi: Native Upstart jobs probably shouldn’t care about runlevels if at all possible.
[16:54] <cjwatson> tkamppeter: I'm told it's on its way, but it's already later than it was promised to me
[16:58] <fta> sladen, yt?
[16:59] <sladen> fta: yo
[16:59] <sladen> fta: I spoke to agl yesterday.  See also https://wiki.ubuntu.com/Ubuntu_Font_Family#Howto for sign up details
[17:00] <fta> sladen, ok
[17:00] <sladen> fta: I couldn't replicate the issues with Chromium yesterday but apparently the errors are still arriving at your end
[17:01] <sladen> fta: really it needs one or more of those users to tell us what (font family) version they're using and hopefully to grab that historial version and try with that
[17:02] <fta> sladen, the reason i pointed to the ubuntu fonts is that all the crash reports i got were from people who have those fonts, the crashes started after they installed them, and disappeared as soon as they removed them
[17:02] <fta> sladen, there's a bug in the upstream bts, and another in lp
[17:02] <pitti> Keybuk: re (sorry, had a meeting)
[17:02] <fta> sladen, plenty in the forums, and even more in my mailbox
[17:03] <fta> sladen, but i'm not impacted, as i never installed those fonts
[17:03] <pitti> Keybuk: right, so I should stop thinking about states, and only think about "edge triggers"
[17:03] <Keybuk> absolutely
[17:04] <pitti> Keybuk: so, in other words, do you consider the current cups start on condition buggy, or is it "correct" within the boundaries of upstart's models?
[17:04] <pitti> i. e. "stop smbd" -> "just don't do that"?
[17:05] <pitti> after all, a normal boot works just fine
[17:06] <Keybuk> well, it's correct, you just can't stop/start manually
[17:06] <Keybuk> there's lots of cases that doesn't work out so well
[17:07] <pitti> ok, great; I was just worried about that bit
[17:07] <pitti> Keybuk: thanks a lot for the explanation! (I'm sure you already gave it like 20 times to people, sorry)
[17:08] <Keybuk> that's ok, I enjoy giving it :p
[17:08] <pitti> heh
[17:08] <psusi> why can't you stop smbd?
[17:09] <sladen> fta: me neither, and nobody who seems to be able to replicate it
[17:09] <psusi> sounds like you want cups to be stop on smbd stopping
[17:09] <pitti> ugh, final freeze already?
[17:09] <Keybuk> psusi: wouldn't help - see above
[17:10] <pitti> psusi: no, I don't want that actually
[17:10] <sladen> pitti: <IP_ADDRESS>.10 stole two weeks
[17:10] <pitti> psusi: the only point of that dependency is that samba can pick up cups printers to the windows network, but otherwise they are quite independent
[17:10] <tkamppeter> pitti, Thursday, and I would very much like CUPS/Samba to work then and Jockey to be uploaded.
[17:10] <psusi> ahh
[17:11] <psusi> so why does stop smbd cause a problem?
[17:12] <Keybuk> it doesn't
[17:12] <Keybuk> it's start smbd
[17:13] <psusi> why is that a problem?
[17:13] <maco> could a core dev sponsor this?  https://code.edge.launchpad.net/~ilidrissi.amine/ubuntu/maverick/language-support-fonts-zh-hans/fix-625163/+merge/33977  the patch looks fine to me
[17:13] <cjwatson> hm, language-support-fonts-* is generated by lp:langpack-o-matic
[17:13] <cjwatson> if that patch is sponsored, it'll be overwritten at the next autogeneration
[17:14] <pitti> tkamppeter: right, so I'll get that cups uploaded now, and will put jockey on my plate for tomorrow morning
[17:14] <cjwatson> (I've said that in the review)
[17:15] <Keybuk> psusi: go read above
[17:15] <Keybuk> I explain it pretty carefully
[17:16] <cjwatson> maco: (also there seems to be some subsequent? conversation in the bug)
[17:18] <maco> cjwatson: oh ok. hrm why do bugs link to matching branches but branches dont link to matching bugs? how silly...
[17:18] <psusi> ohh... so smbd is tied to cups, but cups is also tied to filesystem, so when smbd tries to pull cups onto the belt, it gets stuck because filesystem isn't also pulling
[17:18] <psusi> so no masher for smbd
[17:18] <maco> cjwatson: what about the part of the patch that adds an additional font to the metapackage's dependencies?
[17:19] <cjwatson> maco: extra dependencies are fine, but there's a special file in lp:langpack-o-matic listing that stuff
[17:19] <cjwatson> support-depends/maverick/zh-hans, I believe
[17:20] <maco> oh so both the symlinks /and/ depends are handled in there. magic.
[17:32] <didrocks> pitti: did you see my hilight on Quickly and FFe? (bug #638130)
[17:33] <pitti> didrocks: I didn't, no; probably got lost in the meeting marathon
[17:33] <didrocks> pitti: no hurry but as I won't be there then until Friday… :)
[17:35] <nigelb> james_w: can you package training session on 23rd? (currently its maco, but I'm wonder if you could switch with ther)
[17:44] <mathiaz> ScottK: hi!
[17:44] <mathiaz> ScottK: what is the next step for bug 638213?
[17:49] <lamont> ogra: NCommander: please don't change buildlive to email me.  I already get SMSed when the machine is down, as do others.  and then we have someone power cycle the machine when they're in the data center
[17:52] <lamont> ogra: NCommander: if you want a productive task, get me some machines that I can power cycle remotely
[17:52] <ogra> lamont, yeah, i thought so
[17:52] <ogra> lamont, you will get them in november or december
[17:53] <ogra> we're working on that
[17:53] <lamont> I mean, sadly, it's one of those "yep, this is gonna suck" SMSes that I get all to frequently
[17:53] <ogra> first we need stable HW and an OS running on it ;)
[17:53] <lamont> hey yeah, that'd be just dandy!
[17:53] <ogra> which will be there areoung maverick release date
[17:53] <ogra> *around
[17:54] <ogra> then we'll just wait for some mass production :)
[17:54] <lamont> if it requires maverick for stability, I can live with that.  Just as long as lucid still builds with maverick underneath, of course.
[17:54] <ogra> sure
[17:55] <ogra> the HW we currently work on builds a kernel in 2.5h
[17:55] <ogra> (current buildd time is 6h)
[17:55] <lamont> The following packages will be REMOVED:
[17:55] <ogra> and thats on a rotary disk ... with USB SSD that should speed up even more
[17:55] <lamont>   hplip
[17:55] <lamont> that's not very nice of it
[17:55] <ogra> sadly no SATA yet
[17:58] <didrocks> cjwatson: ok, so pitti got sidetrack about the Quickly FFe and Riddel is on vacation, can you have a look please? (bug #638130). I'll be back only on Friday and I would prefer pushing the new release before final freeze
[17:59] <didrocks> (or ScottK, if you are around)
[18:10] <james_w> nigelb: I'd be happy to if maco is
[18:10] <nigelb> james_w: she's inconvinienced on 23rd, hence the chance
[18:11] <james_w> nigelb: then I'm fine with it
[18:11] <nigelb> maco: you're okay with 30th?
[18:12] <maco> nigelb: yeah
[18:12] <nigelb> maco, james_w: thank you.  You both rock :)
[18:16] <nigelb> james_w and maco: er preferred time? (sorry!)
[18:17] <james_w> nigelb: are we still trying for the rotation of times, or just mixing it up/
[18:17] <nigelb> james_w: right now, the focus is filling it up according to nhandler :)
[18:17] <james_w> :-)
[18:18] <james_w> I would go for something like 20:00 UTC then
[18:18] <nigelb> ok!
[18:22] <SpamapS> james_w: http://package-import.ubuntu.com/status/memcached.html#2010-06-09 01:31:43.802534  .. any ideas whats up with that?
[18:24] <james_w> SpamapS: caused by LP downtime presumably, retried and marked as a spurious failure so that it will be auto-retried next time
[18:25] <SpamapS> james_w: ah, so sometimes things just get stuck as broken, and have to be manually un-stuck?
[18:27] <nigelb> james_w: do you have a name for your session?
[18:28] <james_w> SpamapS: yeah, the way it works is that if the job crashes for any reason it has to be reviewed to check for bugs/abuse of the other systems.
[18:28] <james_w> SpamapS: however there is a way to mark specific failures as probably-spurious and have them retried a number of times automatically without review
[18:29] <james_w> nigelb: not yet, I haven't decided what I am going to talk about
[18:29] <james_w> nigelb: suggestions welcome
[18:29] <nigelb> suggestions...hrm
[19:31] <papertigers> anyone know if those apple magic trackpad drivers in 10.10 work for the touchpad on the laptops?
[19:36] <shadeslayer> jono: free for a sec?
[19:36] <jono> shadeslayer, sure
[19:36] <shadeslayer> jono: i was wondering if theres a tentative date by which the participants for UDS are confirmed
[19:37] <shadeslayer> ( ive applied and it takes some time for visa's to be approved here )
[19:39] <jono> shadeslayer, over the next week or so
[19:39] <jono> hopefully this week
[19:40] <shadeslayer> oh great .. thanks alot :D
[19:40] <shadeslayer> night everyone :)
[19:47] <Intrusion> hey there... I have a question
[19:48] <Intrusion> I am wondering if there is a good place for a total newbie to learn development within the ubuntu community
[19:48] <Intrusion> is there a small project that I could tinker with?
[19:49] <Intrusion> something low priority, but helpful for someone who wants to hone my programming skills
[19:53] <Intrusion> I am wondering if there is a good place for a total newbie to learn development within the ubuntu community
[19:53] <Intrusion> something low priority, but helpful for someone who wants to hone my programming skills
[19:56] <sladen> Intrusion: in about 3 weeks there will be lots of development things to work on.  At the moment Ubuntu is solidly bug fixing until release
[19:56] <Intrusion> great
[19:56] <Intrusion> is there a good place to stay up to speed with what needs to be done
[19:57] <sladen> Intrusion: -> #ubuntu-motu
[19:58] <Intrusion> ok... I will go and check in there
[19:58] <Intrusion> thanks a lot for the help
[19:58] <hallyn> feh!  command history misfire.  is there a 'bzr undelete' ?
[20:01] <nigelb> hallyn: what are you trying to achieve/
[20:03] <hallyn> heh, i did a bunch of valid 'bzr removes', then an invalid one
[20:03] <hallyn> nm, i copied it back from elsewhere and re-'bzr add'ed it
[20:03] <shadeslayer> hallyn: have you pushed the changes ?
[20:04] <hallyn> no, but i hadn't committed and didn't want to re-do all the other uncommitted changes
[20:04] <shadeslayer> bzr revert ?
[20:04]  * hallyn would be more effective once he figured out how to do git-like cheap local branches followed by rebase -i
[20:05] <hallyn> can i revert one 'bzr remove'?
[20:05] <shadeslayer> or is that only after you commit changes?
[20:05] <shadeslayer> hallyn: dunno.. might be able to.. #bzr would know
[20:05] <hallyn> not sure
[20:05] <nigelb> hallyn: heh, can't revert bzr remove unless you've commited
[20:06] <nigelb> (I think so)
[20:06] <hallyn> ok, i might play around so i know for next time, and/or go ask there, thx
[20:06] <shadeslayer> git is the best for this sort of stuff :D
[20:07] <hallyn> well as i was typing that, it occurred to me i shoudl actually be able to do something close to that
[20:07] <hallyn> do a local 'bzr branch', commit after every little change, then do a merge -r1..20 in the main branch when i'm done
[20:07] <hallyn> not *quite* as convenient as git rebase -i, but doable
[20:07]  * hallyn goes to try
[20:08] <beuno> hallyn, bzr rm --keep
[20:08] <beuno> erm, ignore that
[20:08] <beuno> you can cat
[20:08] <beuno> so bzr cat FILENAME -r $revision
[20:11] <hallyn> buxy: so 'bzr cat FILENAME -r $revision > FILENAME' ? :)
[20:11] <hallyn> uh, huh
[20:11] <hallyn> beuno: ^
[20:11] <hallyn> apparently i shouldn't be allowed near a keyboard today
[20:12] <nigelb> heh
[20:12] <beuno> hallyn, yes, that should recover a file in your history
[20:12] <beuno> I jumped in an didn't read things carefully
[20:12] <beuno> so it may not be what you want  :)
[20:29] <bilalakhtar_> mvo: Should I go ahead with fixing bug #367287 ?
[20:29] <mvo> bilalakhtar_: yes
[20:30] <bilalakhtar_> mvo: I asked you, since you're maint :_
[20:31] <maco> bilalakhtar_: hint: before requesting anything of mvo, always offer tea
[20:31] <maco> ;)
[20:31]  * bilalakhtar_ offers mvo tea
[20:31]  * mvo is on the phone so a bit slow
[20:40] <cr3> marjo_: did you see my private messages to you, marjo (without trailing underscore)?
[21:44] <sladen> what was the name of the third-party installed that then installed lots of non-free codecs and stuff?
[21:45] <lifeless> mediabuntu or something?
[21:46] <nigelb> sladen: ubuntu-restricted-extras or mediaubuntu ones?
[21:47] <sladen> nigelb: no, no, the godforsaken piece of nightmare that even Michael Dell unfortunately recommended people use
[21:47] <nigelb> oh?
[21:47] <james_w> automatix?
[21:48] <ajmitch_>  I think that's the one
[21:48] <ajmitch_> it was quite popular & caused a lot of headaches
[21:49] <nigelb> sladen: james_w was right, http://www.getautomatix.com/
[21:49] <sladen> automatix, yup.  Thank you nigelb and james_w!
[21:49]  * nigelb only googled :D
[21:49] <nigelb> james did the work:)
[21:52] <dylan-m> sladen: Careful with that, you might trigger its rebirth.
[21:53] <nigelb> the site is out right now
[21:54] <nigelb> sladen: ultramatix is probably the one that works now
[21:54] <dylan-m> Its successor is actually ultamatix <http://ultamatix.com/>. I think automatix is gone at this point.
[21:56] <soren> slangasek: Got a sec? I'm looking at the stuff you did with bridge-utils for Lucid.
[21:58] <soren> slangasek: I'm curious what is meant to happen if "ifup br0" is called and br0 has a an interface listed in bridge_port that isn't around yet.
[21:59] <soren> slangasek: Perhaps I'm reading it wrong, but looking at /usr/share/bridge-utils/ifupdown.sh from line 58 and onwards, it seems it just assumes the interface is around and attempts to add it and doesn't handle failure to do so.
[22:00] <soren> slangasek: I'm asking because someone posted this and I got curious: https://lists.ubuntu.com/archives/ubuntu-server/2010-September/004619.html
[22:49] <nigelb> james_w & maco: http://people.ubuntu.com/~nhandler/classroom.html
[22:49] <nigelb> please do confirm that the time is suitable for you
[22:50] <james_w> yes
[22:50] <nigelb> :)
[22:50] <nigelb> err, when does daylight savings change? not yet right?
[22:52] <james_w> nigelb: I don't know actually
[22:53] <nigelb> October :)
[22:53] <soren> nigelb: Depends on wher eyou live.
[22:53] <maco> er i meant 1900 UTC, not GMT
[22:53] <nigelb> soren: We're smart enough not to have it :p
[22:54] <rickspencer3> hey all
[22:54] <maco> er hrmph confusing
[22:54] <maco> james_w: does GMT move with BST or stay one second off of UTC always?
[22:54] <maco> hiya rickspencer3
[22:54] <rickspencer3> I'm trying to log a bug, I think it should be against the package that contains the following file: /build/buildd/glib2.0-2.25.15/gobject/gtype.c
[22:54] <james_w> maco: GMT doesn't move
[22:55] <maco> james_w: oh ok then
[22:55] <rickspencer3> how do I find out what package this file is in?
[22:55] <maco> rickspencer3: dpkg -S <path>
[22:55] <rickspencer3> (doing my best based on Python output)
[22:55] <rickspencer3> sweet
[22:55] <maco> rickspencer3: if the package is installed that is. if not, apt-file search <file>
[22:55] <ajmitch> rickspencer3: it's in the filename there, should be glib2.0
[22:55] <maco> ajmitch: aw but my way he learns how to find things himself :P
[22:55] <rickspencer3> well, lot of packages seem to answer to the call of glib2.0
[22:56] <rickspencer3> so, just trying to narrow it down
[22:56] <kklimonda> rickspencer3: this is a part of libglib2.0-0
[22:56] <rickspencer3> sweet
[22:56] <rickspencer3> thanks maco, ajmitch, and kklimonda
[22:57] <kklimonda> rickspencer3: but I'm not sure if your crash isn't related to something higher - maybe pygtk would be a better guess? still a guess though
[22:57] <ajmitch> it's useful having the package name in the build path :)
[22:57] <rickspencer3> kklimonda, well, the warning looks glib(ish)
[22:57] <rickspencer3> but what the heck do I know
[22:58] <kklimonda> rickspencer3: sure, it's a warning from glib - but I wonder why did it show.
[22:58] <rickspencer3> kklimonda, something in PyGtk
[22:58] <rickspencer3> I'll upload a reproducer
[22:58] <rickspencer3> kklimonda, do you think PyGtk is a better bet?
[22:59] <rickspencer3> grid_filter.py:797: Warning: /build/buildd/glib2.0-2.25.15/gobject/gtype.c:4181: type id `0' is invalid
[22:59] <rickspencer3>   gtk.main()
[22:59] <rickspencer3> grid_filter.py:797: Warning: can't peek value table for type `<invalid>' which is not currently referenced
[22:59] <kklimonda> rickspencer3: oh, you have a small test case? then report it against glib and someone will triage it :)
[22:59] <rickspencer3> kklimonda, it's smallish ;)
[23:58] <slangasek> soren: so I don't know that 'ifup br0' is handled particularly well, honestly; I don't think manual bring-up of bridge interfaces was on my radar, the changes were focused on fixing the auto-start case
[23:58]  * slangasek pulls up the link


[05:03] <pitti> Good morning
[06:37] <BigWhale> @#$#@!!! Morning.
[06:42] <didrocks> good morning
[06:43] <pitti> bonjour didrocks
[06:43] <pitti> BigWhale: what's up? :-)
[06:43] <didrocks> salut pitti, ça va?
[06:43] <pitti> ça va bien! et toi?
[06:43]  * pitti was watching you live yesterday
[06:43] <didrocks> ça va, ça va :)
[06:43] <pitti> UbunTv!
[06:43] <didrocks> pitti: oh, which session? :)
[06:44] <pitti> integrating the phablet apps into ubuntu
[06:44] <highvoltage> bonjour á tous
[06:44] <didrocks> ah ok :-)
[06:44] <didrocks> bonjour highvoltage ;)
[06:44] <pitti> bonjour highvoltage, comment vas-tu?
[06:44] <highvoltage> bien merci et toi?
[06:44] <didrocks> pitti: I find it a little bit difficult to lead a session, with all the tabs opened + the hangout window
[06:44] <didrocks> I guess it's a question of habit
[06:44] <pitti> yeah
[06:45] <pitti> following a session with video, irc, and etherpad works rather well I find
[06:45] <BigWhale> pitti, I'm up, that's what .. :/ six hours of sleep in two days and today will be the same and I have to make a new release of Kazam so it will get uploaded to Raring.
[06:45] <didrocks> but I found it way more tiring than leading a session at a non virtual UDS
[06:45] <didrocks> right
[06:45] <pitti> but not when having an "active" hangout
[06:45] <didrocks> exactly
[06:45] <didrocks> not sure what can be done for that though
[06:45] <pitti> BigWhale: trying sleep compression?
[06:46] <pitti> didrocks: not sure either, maybe hangout on the tablet/netbook/second screen?
[06:46] <pitti> with a bigger monitor, having two windows side by side ought to work, too
[06:46] <didrocks> pitti: yeah, I think that's a viable option
[06:46] <pitti> that gets quite crammed with my 1280 pixels, though
[06:46] <BigWhale> Two people should lead the sessions. One taking care of video and the other of IRC. And the second person would then pass the info from irc to the first person
[06:47] <BigWhale> it's hard to keep track of all the people chatting in irc
[06:47] <didrocks> BigWhale: yeah, that doesn't fix the "issue" with sessions where you have a ton of tabs
[06:47] <pitti> yeah, we need some kind of moderation there
[06:47]  * RAOF will get to see this in action when there's a vUDS that doesn't go from 1am to 6am.
[06:47] <didrocks> but agree that someone modering IRC is a first step :)
[06:48] <didrocks> moderating*
[06:48] <BigWhale> pitti, I'll just stuff myself with energy drinks and green smoothies :>
[06:52] <didrocks> BigWhale: green smoothies, what do you put in it? :)
[06:53] <BigWhale> didrocks, lots of stuff that tastes awful and that really wakes you up! ;>
[06:53] <didrocks> :)
[06:53] <BigWhale> everything from cabbage to broccoli
[06:54] <BigWhale> lettuce
[06:54] <BigWhale> mint ... and few more stuff that I'd have to google their English names  :)
[06:54] <didrocks> interesting, I drinked a lot of smoothies in Ireland, but never such ones :)
[06:54] <didrocks> ahah
[06:55] <mlankhorst> RAOF: not missing much
[06:56] <BigWhale> rolling release session was quite good, but inconclusive :)
[06:56] <BigWhale> ah well, have to run to the office.
[06:56] <BigWhale> later :)
[07:48] <czajkowski> morning folks
[08:02] <didrocks> hey czajkowski
[08:28] <seb128> hey desktopers
[08:38] <Sweetsha1k> seb128: ho
[08:38] <seb128> Sweetshark, hey, how are you?
[08:40] <Sweetshark> Mostly fine, except from the "arrgh fuuu LibreOffice on raring ate my data" mail from jono in the morning.
[08:40] <seb128> oh, it did?
[08:42] <Sweetshark> seb128: we should update away from that beta ASAP. 4.0.1 final is going to be released ... *cough* soon, so we should update along with that.
[08:43] <Sweetshark> I have a 4.0.1~rc2 at https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-nattytest2 to be copied over to the ppa when its done.
[08:43] <seb128> is there any other blocker since you fixed the libcmis issue?
[08:43] <Sweetshark> rc2 is expected to be final.
[08:43] <Sweetshark> no other blockers except DMB review ;)
[08:51] <seb128> Sweetshark, great, let's hope bdrung has time to review/sponsor it ;-)
[08:52] <Sweetshark> seb128: I see no trouble there, bdrung was very quick with the libcmis thing.
[08:53] <seb128> excellent
[09:10] <seb128> pitti, hey, I saw you assigned you the gvfs bug, do you plan to do the update as well? ;-)
[09:11] <Laney> howdy
[09:11] <seb128> Laney, hey, how are you?
[09:12] <Laney> good, but tired! We went to a comedy show last night which started/finished quite late
[09:12] <Laney> how about you?
[09:13] <seb128> I'm good thanks
[09:13] <seb128> I was too exhausted after vUDS to go anywhere though :p
[09:14] <Laney> yeah I'd have rather it was another day but we already booked it
[09:17] <seb128> I hope the show was good at least ;-)
[09:17] <Laney> yep :)
[09:45]  * seb128 uninstall a stack of kernels and gets back 1GB of disk space
[09:46]  * chrisccoulson should try that
[09:47] <Laney> http://paste.ubuntu.com/5589957/ !!!!!!!
[09:47] <seb128> Laney, see!
[09:48] <seb128> Laney, do you have a magical command or did you list them by hand? (I do list by hand)
[09:48] <seb128> using autoremove doesn't clean those for me
[09:48] <Laney> oh, that was just autoremove
[09:49] <didrocks> autoremove clearly does for me :)
[09:49] <didrocks> just cleaned 2.7 GB, I kept the old kernels for a long time due to the network issue
[09:52] <chrisccoulson> autoremove freed up nearly 1GB here, but it left most old kernels
[09:52] <chrisccoulson> i guess i'll clean those manually
[09:53] <Laney> perhaps it only notices ones which were installed after that feature got added
[09:54] <chrisccoulson> i've got 3.0 kernels installed here. how old are those?
[09:54] <Laney> oneiric ish
[09:56] <chrisccoulson> nice, another 3GB
[09:56] <chrisccoulson> quick, fill the space with another chromium build!
[09:57] <czajkowski> how to make chrisccoulson - free him up space
[09:57] <chrisccoulson> czajkowski, i literally fight over tens of MB here, so a few GB is quite welcome
[09:57]  * chrisccoulson wishes for a bigger SSD
[09:58] <seb128> same here
[09:58] <seb128> 80G ssd is short
[09:58] <chrisccoulson> yeah, i struggle with 120GB!
[09:59] <chrisccoulson> which reminds me. i'm sure that i'm due a laptop refresh ;)
[09:59] <czajkowski> yeah I'm thinking of investing in a desktop and throwing a lot of storage at it, having to do testing in Vms is driving me insane
[09:59] <czajkowski> I love this laptop but it's not built for testing
[10:00] <czajkowski> it does test my patience from time to time
[10:00] <czajkowski> or lack of...
[10:02] <Laney> do you have an SSD?
[10:02] <Laney> made such an amazing difference when I upgraded just that one thing on my laptop
[10:02] <seb128> yeah, same here
[10:02] <seb128> I wonder if I should format it though
[10:04] <seb128> https://plus.google.com/u/0/107564545827215425270/posts/V3UH5SUXJcT
[10:05] <chrisccoulson> i've got 4.5GB of free space now \o/
[10:06] <Sweetshark> chrisccoulson: I have a build tree that would just fit in there nicely ....
[10:06] <Sweetshark> bdrung: http://people.canonical.com/~bjoern/libreoffice4/ <- 4.0.1 proposal btw ...
[10:06] <chrisccoulson> Sweetshark, you can get a build tree in 4.5GB? lucky you ;)
[10:07] <Sweetshark> chrisccoulson: a developer build, not a release build.
[10:07] <chrisccoulson> ah :)
[10:19] <marga> Hi.  I've created a custom indicator.  To find out about the available icons, I used the icon library browser.  But now I'm finding out that they don't look the same in unity and cinnamon
[10:19] <seb128> marga, right, cinnamon uses a different icon theme
[10:19] <marga> For example, I'm using emblem-default-symbolic, and in cinnamon it looks awfully big
[10:20] <seb128> seems like a bug in their theme then?
[10:20] <marga> :-/
[10:21] <marga> Well, I'm not sure... It's the same icon, just bigger
[10:21] <marga> I think it's the indicator that somehow is screwing this up
[10:22] <seb128> marga, why?
[10:22] <marga> because the icon is available in multiple sizes, but it's showing the wrong size
[10:23] <seb128> maybe it's not available in the wanted size in the theme?
[10:23] <marga> Sorry, it's actually a scalable svg
[10:23] <marga> the icon library browser shows 3 sizes, by scaling
[10:24] <seb128> marga, where did you get the cinnamon icon theme?
[10:24] <seb128> it doesn't seem to be into the archive
[10:24] <marga> uhm... it's the gnome theme, I think
[10:25] <marga> the library browser says 'inherited from gnome'
[10:25] <marga> It's in the gnome-icon-them-symbolic
[10:26] <pitti> seb128: I don't think there's an "update" as such, it requires debugging why it doesn't work
[10:26] <pitti> oh, there's 1.15.4, indeed
[10:26] <seb128> pitti, versions disagrees with you
[10:26] <seb128> pitti, ;-)
[10:27] <pitti> ah, released on Monday, that was after I checked last
[10:29] <pitti> seb128: but still, support for powering off was in 1.15.1, so it's still not just the new version
[10:29] <seb128> pitti, well, it's build time enabled though, did you try rebuilding with the new udisk?
[10:29] <pitti> yes
[10:29] <seb128> ok
[10:29] <seb128> pitti, the "update" comment was orthogonal, I've "update gvfs" in my tomboy
[10:30] <seb128> but that tomboy note is endless, so I'm happy to let it to somebody else :p
[10:30] <Laney> ah /me was looking at that
[10:30] <Laney> happy to leave it to pitti though if you're debugging something else anyway
[10:30] <seb128> Laney, there is a bunch of other GNOME updates to do if you feel like doing those
[10:30] <pitti> Laney: ok, WFM; I'll do the update, and debug the poweroff thing
[10:30] <seb128> I was just going to do gtk3
[10:31] <pitti> seb128: is there a new 3.6.5? or are we going for 3.7.x at last?
[10:32] <seb128> Laney, gssdp and gupnp (sync the new version from debian?),  libpango/glib/gtk-perl, glibmm, gnome-keyring, gtkmm3, libsecret, etc
[10:32]  * pitti HUDs for "disks", gets totem, o_O, and tries again
[10:32] <seb128> pitti, still baking 3.7 in the ppa
[10:33] <seb128> pitti, we have some regressions still, theming issues
[10:33] <seb128> https://bugzilla.gnome.org/show_bug.cgi?id=694217
[10:33] <ubot2`> Gnome bug 694217 in general "drag&drop half-broken – items get stuck while dragging" [Normal,Unconfirmed]
[10:33] <seb128> gnome-screenshots turn your screen white
[10:33] <pitti> meh, and searching for d-feet doesn't work at all -- what the heck is wrong with hud search?
[10:33] <seb128> pitti, hud or dash?
[10:33] <didrocks> pitti: yeah, regression in the dash
[10:33] <seb128> hud is looking in menus only
[10:33] <pitti> sorry, dash
[10:33] <didrocks> pitti: the fix is merging
[10:34] <didrocks> with a test :p
[10:34]  * pitti hugs didrocks
[10:34] <seb128> regression from the new libcolumbus version
[10:34] <seb128> what didrocks said
[10:34]  * didrocks hugs pitti back
[10:35] <seb128> marga, I don't really have time to look at the issue atm, it's weird because that symbolic icon is only shipped in one package ... does the cinnamon theme inherit from GNOME?
[10:35] <marga> it does, yes
[10:35] <seb128> marga, in any case have a bug report with a small testcase would be useful
[10:35] <seb128> larsu can probably help you to figure out what's wrong when he's up in a few hours
[10:35] <pitti> at least calling PowerOff on udisks2's d-bus iface works, so gvfs' fault
[10:35] <marga> Ok, will look a bit deeper into this to try to find the culprit
[10:41] <Laney> bah, typing "spotif" into the dash gets me gedit instead of spotify
[10:42] <pitti> Laney: sounds like the same error I just complained about, where didrocks says it's being fixed?
[10:42] <Laney> oh, didn't read scrollback, sorry
[10:42] <Laney> ah
[10:42] <Laney> yes, thanks
[11:03] <tkamppeter> seb128, hi
[11:07] <xnox> pitti: so I used the g-doc parser against Gtk.gir to generate the docs. I see all the classes in the dot notation & hierarchy which is nice. But no functions/parameters/signals?!
[11:08] <ritz> cyphermox hi, wrt https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/965895
[11:08] <ubot2`> Launchpad bug 965895 in network-manager-applet "After boot, NetworkManager indicator menu only shows four entries" [High,In progress]
[11:10] <pitti> xnox: signals are in the per-class docs; I also see the arguments of methods and signals
[11:10] <xnox> pitti: hmm...
[11:10] <pitti> xnox: the functions seem to be there, but that part is buggy
[11:10] <pitti> Index.main
[11:10] <pitti> Runs the main loop until Index.main_quit is called.
[11:10] <pitti> that should say "Gtk", not "Index"
[11:11] <xnox> pitti: here is what I have: http://people.canonical.com/~xnox/yelp/doc/index.html
[11:11] <xnox> did I generate it wrong?
[11:11] <xnox> there are .pages as well...
[11:11] <pitti> hm, that looks incomplete indeed; I was checking in ylep
[11:11] <pitti> yelp, too
[11:12] <xnox> g-ir-doc-tool --language=Python -o /home/tdlk/build/doc /usr/share/gir-1.0/Gtk-3.0.gir
[11:12]  * pitti runs yelp-build
[11:12] <xnox> yelp index.page is same....
[11:12] <xnox> for me anyway.
[11:14] <xnox> i do have -dev -doc etc packages installed. Should I be doing this doc generation in the source package?
[11:14] <pitti> xnox: hm, in *.html I get the complete docs, too
[11:16] <pitti> xnox: so compare http://people.canonical.com/~xnox/yelp/doc/Gtk.FontChooser.html with http://people.canonical.com/~pitti/tmp/Gtk.FontChooser.html
[11:16] <pitti> xnox: (sorry, didn't copy the .js and css bits along)
[11:16] <pitti> done now
[11:16] <xnox> pitti: nice. So how come i'm not getting that?! =))))
[11:17] <pitti> xnox: did you not feed it enough cookies?
[11:17] <pitti> no off-hand idea, I'm afraid
[11:17] <xnox> gobject-introspection	1.35.8+git20130220-0ubuntu1
[11:17] <pitti> xnox: I have yelp-tools and yelp-xsl installed
[11:17] <xnox> libgtk-3-dev	3.6.4-0ubuntu6
[11:18] <xnox> pitti: yeah, same here.
[11:18] <pitti> xnox: but if the .page files are already missing the info, it's on the g-ir-doc-tool side
[11:19] <pitti> http://people.canonical.com/~xnox/yelp/doc/Gtk.FontChooser.page looks really poor
[11:20] <xnox> pitti: right, so the Notify.gir works here. So not sure what's wrong with Gtk3.
[11:20]  * xnox really needs/wants Gtk, GLib, Gdk.
[11:23] <xnox> GdkX11 worked, Gdk/gtk/glib didn't =(
[11:25] <xnox> pitti: i'm on raring, are you?
[11:25] <pitti> xnox: yes, raring du jour
[11:42] <tkamppeter> seb128, around?
[11:48] <pitti> seb128: ok, I demystified bug 1067876
[11:48] <ubot2`> Launchpad bug 1067876 in gvfs (Ubuntu) "Missing "Safely Remove Drive" option from Quicklists. Only have "Eject"." [Low,In progress] https://launchpad.net/bugs/1067876
[11:48] <pitti> seb128: it's again a "hardware lies, we have no information what's right" case, and really tricky to work around
[11:48] <pitti> seb128: but for now, showing "Eject" for USB sticks doesn't break the world IMHO
[12:02] <seb128> tkamppeter, hey, sorry I was away for a bit
[12:02] <seb128> pitti, oh, ok, thanks for figuring it out!
[12:03] <tkamppeter> seb128, I have a problem with GNOME's printer setup tool and do not know how to debug it.
[12:03] <seb128> tkamppeter, what sort of problem?
[12:03] <tkamppeter> seb128, I am on Raring and if I run system-config-printer from the command line (old UI) it detects all my printers, in the network and on USB.
[12:05] <tkamppeter> seb128, if I use the new tool on my laptop (real-iron Raring), I see only network printers and no USB printers, looks like the new tool only checks via Bonjour but does not ask CUPS.
[12:05] <tkamppeter> seb128, on a Raring VM no printers are found at all, probably also not asking CUPS and not finding anything via Bonjour as it has its own network inside my PC.
[12:06] <seb128> could be, did you look at the code? or maybe ask upstream (I think he's mkasik on the GNOME IRC)
[12:06] <seb128> need to be away a few minute, I will read the scrollback
[12:06] <seb128> brb
[12:06] <tkamppeter> seb128, so the problem seems that the new tool is not asking CUPS (via s-c-p D-Bus service) to detect printers.
[12:11] <bdrung> Sweetshark: libcmis is uploaded. thanks for your work on that. i will review 4.0.1
[12:12] <Sweetshark> bdrung: please hold back uploading 4.0.1 a bit still
[12:12] <bdrung> okay
[12:14] <Sweetshark> bdrung: some test have been proven to be flaky in general (as they failed on the backports builders too). So Ill disable them, so that we dont end up with a 24 hour armhf build that then fails to complete.
[12:14] <Sweetshark> bdrung: you can go ahead and review 4.0.1 already though as this will only be a minor change.
[12:14] <bdrung> Sweetshark: "new upstream release candidate" -> "new upstream release"
[12:26] <seb128> tkamppeter, have you looked at the GNOME tool's code to see what it's doing exactly?
[12:26] <tkamppeter> seb128, not yet.
[12:27] <seb128> tkamppeter, it seems like they use org.opensuse.CupsPkHelper.Mechanism DevicesGet method
[12:34] <tkamppeter> seb128, how do I fire up the printer tool from the command line, to see its warnings, and is there perhaps a debug mode for more verbose console logging?
[12:37] <seb128> tkamppeter, try "G_DEBUG_MESSAGES=all gnome-control-center printers"
[12:37] <seb128> but it doesn't seem like there are lot of debug code in the source
[12:40] <tkamppeter> seb128, thanks for the hint, there is no output at all.
[12:41] <Sweetshark> bdrung: fixed in http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=commit;h=36f27eb52d7c35b9a0ff59fb9298c11a3f64759a which also has the disabling of tests by ricotz. http://people.canonical.com/~bjoern/libreoffice4/ is updated too.
[12:43] <tkamppeter> seb128, I reported https://bugzilla.gnome.org/show_bug.cgi?id=695286 now.
[12:43] <ubot2`> Gnome bug 695286 in Printers "Printer tool of GNOME Control Center does not get info about available printer devices from CUPS" [Normal,Unconfirmed]
[12:43] <seb128> tkamppeter, did you figure out what is wrong or just reported the issue?
[12:45] <Sweetshark> bdrung: also, its official now: http://blog.documentfoundation.org/2013/03/06/the-document-foundation-announces-libreoffice-4-0-1/
[12:46] <seb128> tkamppeter, you might want to join irc.gnome.org #control-center and ping mkazik to discuss the issue
[12:50] <BigWhale> is it just me or bzr is acting a little bit strange?
[12:56] <bdrung> Sweetshark: for what reason does libreoffice-help-en-us conflict with all other help packages?
[12:57] <Sweetshark> bdrung: bug 957589
[12:57] <ubot2`> Launchpad bug 957589 in Ubuntu Translations "Localized LibreOffice Help files ignored when help for en-US is installed" [Medium,Triaged] https://launchpad.net/bugs/957589
[12:59] <bdrung> thanks
[13:02] <tkamppeter> seb, thanks for the hint, I am connecting now.
[13:07] <seb128> re
[13:08] <seb128> ogra_, what's the recommended way to put raring on the nexus7 nowadays? did you say usb-creator works for it?
[13:17] <ricotz> bdrung, hi, will you upload the new libreoffice within the next hours?
[13:37] <desrt> good morning, hax0rs
[13:38] <bdrung> ricotz: i will review it and upload, but i can't promise it to be in the next few hours
[13:38] <mterry> attente, https://apps.ubuntu.com/cat/applications/precise/super-hexagon/
[13:38] <desrt> mterry: nooooooo
[13:38] <seb128> hey desrt mterry
[13:39] <desrt> seb128: hey
[13:39] <mterry> seb128, desrt: Morning!
[13:39] <desrt> seb128: i took your advice
[13:39] <desrt> https://launchpad.net/~desrt/+archive/ppa
[13:39] <desrt> testing now
[13:39] <seb128> great
[13:39] <attente> mterry: oh cool
[13:40] <desrt> seb128: is there anyone we can talk to about PPAs effectively being overnight delivery now?
[13:40] <seb128> you mean?
[13:41] <seb128> build time issues?
[13:41] <desrt> yes
[13:41] <seb128> i386 backlog is down to 1h40
[13:41] <desrt> waiting 12 hours for a trivial build is not the best thing for productivity
[13:41] <seb128> I think that's going to solve itself in a bit
[13:41] <desrt> oh.  good.
[13:42] <seb128> we accumulated delays for some reasons
[13:42] <seb128> but builders are back and catching up
[13:43] <desrt> hm.  looks like i screwed something up.
[13:44] <desrt> oh.  dailies.
[13:45] <ricotz> bdrung, ok, thanks
[13:51] <mterry> So there was a session on rolling release yesterday.  I looked through its notes, but didn't see anything interesting.  Now an email to the ubuntu-desktop list says we decided to release 13.04 after all?  What happened at that session?
[13:52] <bdrung> Sweetshark: the changelog order is wrong. 1:4.0.0~beta2-0ubuntu2 should come before 1:4.0.0-1
[13:52] <seb128> mterry, you can watch the video on youtube, nothing was decided
[13:53] <mterry> seb128, that would take time  :)
[13:53] <seb128> mterry, basically there is a good part of the people who feel like we commited to have a 13.04 and it's late to bail out from that commitement
[13:53] <seb128> mterry, but there was no conclusion
[13:53] <seb128> mterry, it seems like middle ground was to do a release but only support it for security
[13:53] <seb128> e.g not do SRUs
[13:54] <seb128> suggest to people who want the fixes to just keep rolling on the rolling release from there
[13:54] <tkamppeter> seb128, you will participate in the printing session in 5 minutes?
[13:54] <tkamppeter> pitti, will you participate in the printing session in 5 minutes?
[13:55] <ogra_> seb128, well, it is supposed to, otherwise use the manual way via fastboot
[13:56] <ogra_> (usb-creator for flashing)
[13:56] <pitti> tkamppeter: yes, I'll listen in
[13:56] <seb128> ogra_, ok, let me try that ;-)
[13:56] <ogra_> unzip the .gz first
[13:57] <desrt> mterry: you wrote parts of the datetime panel, right?
[13:58] <desrt> particularly the part for turning datetimes into a number to stick into a spinbox and using that number to render the date/time values
[13:59] <desrt> anyway.. i was testing my recent changes there
[13:59] <desrt> so i changed the time manually... that worked OK
[13:59] <GeorgeTorwell> Unity sucks
[13:59] <desrt> then i tried changing the date
[14:00] <desrt> that didn't go so well
[14:00] <desrt> GeorgeTorwell: i know, eh?  seriously!
[14:00] <GeorgeTorwell> Yeah it sucks so hard bro. Cinnamon ftw
[14:00] <desrt> GeorgeTorwell: now that we've covered unity let's move on to why you don't like your science teacher
[14:00] <Sweetshark> bdrung: no, changes need to be ordered in the way they appeared in the ubuntu releases. thus if 1:4.0.0~beta2-0ubuntu2 already merged changes from 1:4.0.0-1 in packaging the order has to be as is.
[14:01] <GeorgeTorwell> desrt: I'm not a neckbeard like you.    You may have to wait a few seconds for the change to show up (not sure why on that off the top of my head)
[14:06] <kenvandine> hey jasoncwarner_!
[14:06] <pitti> hey jasoncwarner_
[14:06] <desrt> jasoncwarner_: hey.  how's your back?
[14:06] <pitti> jasoncwarner_, tkamppeter: is the session actually happening? IRC is quiet and video doesn't work
[14:07] <desrt> mterry: hm.  when i change it, i find myself in 1970 :)
[14:07] <desrt> even after ppa-purge and a reboot
[14:07] <Sweetshark> bdrung: a linear changelog cant handle branching and merging properly, but if you insist on keeping that futile illusion ...
[14:08] <mterry> desrt, not the worst place to be, but not expected, no
[14:08] <desrt> :)
[14:08] <mlankhorst> bdrung: dpkg-mergechangelog merges everything :X
[14:08] <desrt> lemme toss this guy under G_DBUS_DEBUG and see what's going on
[14:12] <bdrung> Sweetshark: doko took 1:4.0.0~beta2-0ubuntu1 and did one change and uploaded it as 1:4.0.0~beta2-0ubuntu2. after the 1:4.0.0~beta2-0ubuntu2, you merged the changes from Debian
[14:12] <desrt> hm... no D-Bus involvement.  quite odd!
[14:12] <bdrung> maybe this chronology didn't end up in the same way in git
[14:12] <desrt> kinda takes all of the parts i've spent the last day or two breaking out of the picture
[14:17] <Sweetshark> bdrung: http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=blobdiff;f=changelog;h=0ff1ae001f6e7c7d0e979f48e4dd0b7ef1ec6304;hp=0dd26df29d611f408a75c28f2d17742f5d49bb2c;hb=42dd5bc7d7fbd2b2ac410eb39fd114aab072ead0;hpb=574cc9f0fbaf8b1d7a4dc1bc287cda55403be432
[14:19] <Sweetshark> bdrung: yes, doko sponsored a changed libreoffice package to raring, without pushing his changes to DSCM or even notifying anyone about, leaving others to clean up the mess for his. :/
[14:19] <Sweetshark> s/his/him/
[14:22] <bdrung> Sweetshark: you can simplify "(LP: #785518) (LP: #949997)" to "(LP: #785518, #949997)"
[14:22] <ubot2`> Launchpad bug 785518 in libreoffice (Ubuntu) "[Upstream] soffice.bin crashed with SIGSEGV in SdrEndTextEdit()" [Medium,Fix committed] https://launchpad.net/bugs/785518
[14:22] <ubot2`> Launchpad bug 949997 in libreoffice (Ubuntu) "[Upstream] Ctrl + z and Enter soffice.bin crashed with SIGSEGV in SfxLinkUndoAction::~SfxLinkUndoAction()" [Medium,Confirmed] https://launchpad.net/bugs/949997
[14:28] <seb128> ls
[14:28] <seb128> ups
[14:40] <desrt> mterry: lol.
[14:41] <desrt> mterry: this is one of those "only in canada" bugs
[14:42] <desrt> mterry: in en_CA, %x (which is the format you use for printing the date) gives a 2-digit year
[14:43] <desrt> so when you parse it back again, we find ourselves in the year .... 13
[14:43] <desrt> that results in GDateTime giving a rather large negative value for the unix timestamp
[14:43] <desrt> which the spinbox then truncates to zero
[14:43] <desrt> and.... ta da!  1970
[14:44] <mterry> desrt, hrm
[14:44] <desrt> here's one thing i don't understand: you use %x for the date, which is locale-specific
[14:44] <desrt> so should be mm/dd/yyyy in US, right?
[14:44] <desrt> but you parse it back in again in the form "yyyy-mm-dd" always
[14:45] <mterry> desrt, let me look at code again
[14:45] <desrt> ya.... it fails to parse US-formatted times
[14:45] <desrt> and in canada it works but.... the result is not nice
[14:46] <mterry> desrt, it works here...
[14:46] <desrt> mterry: are you seeing a mm/dd/yyyy formatted date?
[14:46] <desrt> when i set LC_ALL=en_US that's what i get
[14:47] <desrt> and when i try to change it i get a g_warning to the effect of "WARNING **: Could not understand 03/07/2013"
[14:47] <mterry> desrt, yeah I do
[14:47] <desrt> and the date does not change
[14:48] <desrt> mterry: reading the code, there is really no way this can work....
[14:48] <desrt> 28.6.15 mike@mt |     scanned = sscanf (text, "%u-%u-%u", &year_in, &month_in, &day_in);
[14:49] <mterry> desrt, I am also confused on that line
[14:50] <desrt> so look here: http://bazaar.launchpad.net/~indicator-applet-developers/indicator-datetime/trunk.13.04/revision/120.1.1
[14:50] <desrt> jjardon: you broke it :)
[14:51] <mterry> desrt, I get those print warnings.  Then my system time changes...  Not sure why yet
[14:51] <desrt> used to be hardcoded to %Y-%m-%d
[14:51] <desrt> so full 4-digit year, month, day
[14:51] <desrt> which would work just fine, always
[14:51] <mterry> desrt, ah yes.   I hard coded it because I could not find a way to parse back a date in a generic locale format
[14:52]  * desrt would be annoyed to still be hunting down y2k bugs in 2013 if this was not actually a y0.1k bug
[14:52] <mterry> desrt, I blame Canada
[14:52] <desrt> mterry: i don't believe you that this works in the USA
[14:52] <desrt> it's not possible :)
[14:53] <desrt> mterry: to confirm: we are talking about manual text edit -- not using the buttons
[14:53] <mterry> desrt, this had been part of my subtle attempts to force ISO 8601 on the world
[14:53] <mterry> desrt, oh.  I was using button
[14:53] <desrt> ah
[14:53] <desrt> that one works
[14:53] <desrt> unless you're me
[14:53] <mterry> desrt, I still got the warning, but then it worked
[14:53] <desrt> because the button causes the formatted string to update which parses successfully as the year 0013
[14:53] <mterry> right
[14:54] <desrt> anyway.. there are two bugs here
[14:54] <desrt> we need to revert jjardon's commit
[14:54] <desrt> but then we probably also need to change the canadian preferred locale datetime to include a 4-digit year
[14:54] <mterry> desrt, good luck changing anything locale related
[14:54] <mterry> desrt, that is an uphill battle from what I've seen
[14:55] <desrt> sigh.
[14:55] <desrt> so revert jjardon's patch?
[14:55] <mterry> desrt, though I agree 4-digit years does seem better in this day and age
[14:55] <mterry> desrt, is there a bug yet?
[14:55] <desrt> nobody in canada writes a 2-digit year in ISO format
[14:55] <desrt> https://bugs.launchpad.net/indicator-datetime/+bug/729056
[14:55] <ubot2`> Launchpad bug 729056 in indicator-datetime "Date setting in the preferences should be not be shown in ISO format" [Low,Fix released]
[14:55] <desrt> if you're a fan of reusing the bug that was used to introduce the regression
[14:55] <desrt> otherwise, no
[15:00] <desrt> seb128: so i think we're ready to go
[15:00] <desrt> except for this (unrelated) issue, everything works as expected
[15:00] <seb128> desrt, ok, great, "just" need systemd MIRed and systemd-shim uploaded, NEWed and MIRed
[15:01] <desrt> lovely :)
[15:01]  * larsu just realized that MIR now means two things...
[15:01] <didrocks> larsu: we have Mir and MIR
[15:02] <larsu> fair enought
[15:02] <larsu> *enough
[15:02] <Laney> [MIR] mir will be my favourite bug
[15:05] <desrt> tedg: did you follow this conversation?  looks like you were the one to approve the merge?
[15:06] <desrt> tedg: probably the easiest fix right now is a revert, unless you want to do a lot of work
[15:06] <mterry> desrt, commented on that bug and filed a new one too
[15:06] <desrt> k
[15:06] <desrt> mterry: you gonna take care of it, then?
[15:06] <jjardon> desrt: A bug come from the past to bite me! ;)
[15:07] <mterry> Laney, now now now, it would be "[MIR] Mir".  All lower-case "mir" is still an available acronym!
[15:07] <Laney> I was thinking of the package name :P
[15:07] <desrt> mterry: you could get fancy...
[15:07] <mterry> desrt, I want to quickly poke mpt about it.  mpt: feel like looking at bug 1149696 ?
[15:07] <ubot2`> Launchpad bug 1149696 in indicator-datetime (Ubuntu) "Manually editing date field results in bogus date" [Undecided,New] https://launchpad.net/bugs/1149696
[15:08] <desrt> mterry: you could try for format january 2nd 2003
[15:08] <mterry> Laney, ah, yeah you're right
[15:08] <desrt> and see if it comes out like 01-02-03 or 01-02-2003 or 02/01/2003 or whatever
[15:08] <desrt> then decide what the format is based on that
[15:08] <mterry> desrt, but there are things like Canadians
[15:08] <desrt> i think it's also possible to query nl_langinfo for the format string corresponding to %x
[15:08] <desrt> so you could use that to scan with
[15:08] <mterry> desrt, oh really?  I don't recall that being the case
[15:09] <desrt> glib does this, i think
[15:09] <desrt> that's how g_date_time_format() works
[15:09] <mterry> desrt, I *believe* I looked into this in the past and couldn't find it.  But maybe I overlooked it
[15:09] <desrt> PREFERRED_DATE_FMT
[15:09] <mterry> Oh, in that case...
[15:09] <Sweetshark> bdrung: http://people.canonical.com/~bjoern/libreoffice4/ updated
[15:09] <desrt> #define PREFERRED_DATE_FMT nl_langinfo (D_FMT)
[15:09] <desrt> ding ding
[15:10] <desrt> it's still a lot of work to write a parser based on this
[15:10] <desrt> and note that you may not even be dealing with ascii digits
[15:10] <desrt> i think in a farsi locale you get the arabic arabic digits
[15:11] <mterry> desrt, wait, farsi doesn't use "western" arabic digits?  I always assumed we got those from them
[15:11] <desrt> mterry: we got the system from them, but not the glpyhs
[15:11] <mterry> desrt, cool
[15:11] <desrt> ٠ - ١ - ٢ - ٣ - ٤ - ٥ - ٦ - ٧ - ٨ - ٩
[15:12] <desrt> ironically, the arabs call these "hindi numbers"
[15:12] <larsu> because they came from india originally, no?
[15:13] <desrt> yes
[15:13] <desrt> but the indians write them like ०.१.२.३.४.५.६.७.८.९
[15:13] <mterry> desrt, hmm.  I don't want to write a generic date parser.  I vote ISO 8601
[15:13] <desrt> mterry: ya.  me too.  glad you agree. :)
[15:13]  * mterry wonders if that was the real reason I bailed way back when
[15:13] <desrt> mterry: this is a job that could easily consume a week of your time dealing with edgecases
[15:13] <desrt> i don't think having locale-specific date formats is worth a week of your time
[15:14] <mterry> desrt, also, are you sure there aren't differences between %x and D_FMT...?
[15:14] <desrt> mterry: well
[15:14] <bdrung> Sweetshark: some changelog comments: there is a typo in "diable help building on armel/armhf" -> it should be "disable"
[15:14] <desrt> mterry: you use g_date_time_format()
[15:14] <desrt> which implements %x using D_FMT
[15:14] <desrt> so.... no.
[15:14] <mterry> fair
[15:14] <desrt> no difference :)
[15:14] <bdrung> Sweetshark: you can drop the "tweak Maintainer field" changelog entry
[15:15] <seb128> desrt, mterry: what does ISO 8601 specify?
[15:15] <desrt> seb128: date and time formats
[15:16] <desrt> 2013-03-06T14:16:00
[15:16] <mterry> seb128, specifically, this is YYYY-MM-DD
[15:16] <desrt> among many many other things
[15:16] <seb128> that seems wrong
[15:16] <desrt> yyyy-mm-dd is the international standard
[15:16] <seb128> we would here DD-MM-YYYY here for example
[15:16] <mterry> seb128, it's the only thing that's right in a world of evil
[15:16] <desrt> because, you know, canada uses it
[15:16] <desrt> seb128: no.  you would not.
[15:16] <desrt> seb128: you would do dd/mm/yyyy
[15:16] <desrt> with /
[15:16] <seb128> works for me
[15:17] <desrt> - is reserved for people with sane systems
[15:17] <seb128> as long as days are first
[15:17] <desrt> ie: canadians
[15:17] <bdrung> seb128: YYYY-MM-DD is the only date format that cannot be mis-interpreted
[15:17] <larsu> if days come first, so should the time: 18:37 05/02/2000
[15:17] <desrt> larsu: you mean 37:18, right?
[15:17] <mpt> mterry, are you going to tell me that GTK still doesn't have a datepicker widgets?
[15:18] <larsu> desrt: :D
[15:18] <larsu> seb128: doing it the other way around (year first) makes it sortable, though
[15:18] <seb128> bdrung, there is no mis-interpretation in a specific locale
[15:18] <desrt> seb128: as much as i love little endian, you europeans have the date thing totally wrong :p
[15:18]  * larsu agrees
[15:18] <seb128> larsu, I'm not arguing in favor, I'm just saying that users expect it this wat
[15:18] <seb128> way
[15:18] <mpt> I'm surprised no-one has cited XKCD yet
[15:18] <desrt> the americans do too, of course
[15:19] <bdrung> seb128: okay. the mis-interpretation can only happen if you don't know the locale
[15:19] <mterry> mpt, I went to that comic to remember the ISO number  :)
[15:19] <seb128> larsu, you can claim that the europeans users are stupid and don't care but they are still our users
[15:19] <desrt> seb128: if users see 2013- out in front they know that they should alter their expectation
[15:19] <bdrung> Sweetshark: why where a build-conflict on gcc/g++ (>= 4:4.7~) [!i386 !amd64 !kfreebsd-i386 !kfreebsd-amd64] added?
[15:19] <desrt> seb128: and this is not some theoretical "this way or that, all the same" discussion
[15:19] <seb128> desrt, or they complain that the format is weird
[15:19] <desrt> this is a "mterry will have to spend a week fixing this for you to have it your way" discussion
[15:19] <larsu> seb128: yeah, sadly. I didn't say users were stupid, only that I prefer it the other way around
[15:19] <Sweetshark> bdrung: finished? if not, can you collect the needed changes when you have all of them so that I dont cycle around endlessly doing trivial changes.
[15:20] <mterry> desrt, yeah but then we fix it real nice for everyone forever  :)
[15:20] <bdrung> Sweetshark: nope. not finished with my review.
[15:20] <seb128> larsu, what we prefer doesn't really matter though...
[15:20] <desrt> mterry: if you write this code, i want it in GDateTime :)
[15:20] <seb128> desrt, mterry, larsu: doesn't seem like spending lot of time on though
[15:20] <Sweetshark> bdrung: because we had them before, I dont recheck the debian delta on each upload. usually I purge the delta as far as possible for the next libreoffice major
[15:21] <larsu> seb128: I know, but I want to state my opinion regardless :)
[15:21] <desrt> seb128: the problem is that we have a library function to format dates according to the current locale, but none to parse them back
[15:21] <mterry> mpt, no, I don't believe they do have a date picker.  Let me double check GTK hasn't added one since I last looked
[15:21] <bdrung> Sweetshark: have you done a testbuild on non-i386/amd64? i am not sure what this new build conflict means for non-i386/amd64
[15:22] <mterry> mpt, just their calendar widget
[15:22] <mpt> ffs
[15:22] <desrt> mterry: you want a calendar attached to a label or something?
[15:22] <desrt> like, airline booking site style?
[15:22] <desrt> i bet writing one of those is easier than writing a generic date parser :)
[15:22] <mterry> desrt, mpt: true, we could adjust the design so it isn't directly editable
[15:22] <mpt> Fifteen years and still no datepicker
[15:23] <desrt> also: wtf is the deal with the spin buttons
[15:23] <desrt> i press up and it changes *minutes*?
[15:23] <mterry> desrt, hold it down and it goes faster
[15:23] <desrt> heh
[15:23] <mterry> I think...
[15:23] <desrt> thank god for ntp
[15:23] <mpt> The spin buttons should increment/decrement the selected bit. Currently they increment/decrement ... something.
[15:23] <mpt> Minutes and days.
[15:24] <bdrung> Sweetshark: the build conflict on gcc/g++ (>= 4:4.7~) is new
[15:24] <mterry> mpt, hah, I missed that part of the spec (to increment the selected bit)
[15:24] <desrt> selected?  as in 'the one the cursor is inside of'?
[15:25] <mpt> mterry, I didn't specify it, because it's a standard part of a datepicker :-]
[15:25] <larsu> mpt: isn't a datepicker that lets you choose a date from a calendar much more helpful than a spin box?
[15:26] <desrt> larsu: that's kinda what we're bitching about just now
[15:26] <mpt> larsu, it's much slower, especially if the date is way off, e.g. 1970.
[15:26] <mpt> But other than that, yes. :-)
[15:27] <larsu> but that's an edge case. Who ever sets their time 40 years into the past?
[15:27] <desrt> larsu: happened to me today, quite a few times :)
[15:27] <mpt> larsu, it's one of the most likely wrong years, being Unix year zero
[15:27] <larsu> I knew someone would say that :D
[15:27] <Sweetshark> bdrung: checking ... somebody did suggest whitespace changes to debian, making merges a real pain ...
[15:27] <larsu> mpt: ah, good point
[15:27] <Sweetshark> ;)
[15:28] <larsu> in that case, a text field is probably best...
[15:28]  * larsu prefers NTP anyway
[15:28] <desrt> ya.  thank god for ntp.
[15:28] <mpt> mterry, so, how do you feel about implementing the datepicker if I specify it in detail?
[15:28] <bdrung> Sweetshark: these changes made reading debdiff more easily :)
[15:28]  * desrt is amazed that in all of the option-removing zeal, GNOME hasn't stripped away the option to disable network time
[15:28] <desrt> because, seriously... who actually wants their time to be wrong?
[15:28] <larsu> people who aren't connected to the internet
[15:29] <larsu> oh.  Nevermind.
[15:29] <desrt> actually... i know a lot of people who set their alarm clocks fast
[15:29] <mpt> mterry, basically a text field, where you can navigate between its segments with Left+Right keys, increment/decrement with Up/Down, and type a complete replacement date without having to tab or type separators.
[15:29] <mterry> mpt, I'm fine with it.  But the priority is a different question.  It's not mobile related, so...  :)
[15:29] <mpt> true
[15:29] <desrt> mterry: just commit the revert
[15:29] <mterry> mpt, also it'd be difficult to get right due to the variety of parsing back locale-specific formats, so it would take some time
[15:30] <seb128> it seems non trivial work for little benefit in the big picture
[15:30] <seb128> e.g very low priority
[15:30] <seb128> let's go with the easier fix
[15:30] <mterry> mpt, how much do you hate going back to ISO 8601?
[15:30] <seb128> e.g revert the commit?
[15:30] <desrt> seb128: yes
[15:30] <desrt> we can leave the old bug open in case some day someone wants to make the effort
[15:31] <mterry> This time I'm going to leave a comment, pointing at these bugs
[15:31] <desrt> mterry: good idea :)
[15:31] <Sweetshark> bdrung: sure, I hear you want to do the merges there now.
[15:31] <Sweetshark> ;)
[15:31] <mpt> mterry, I love ISO 8601 with a passion. I use ISO 8601 on all my design sketches. But I usually have to explain it if I dare use it with a non-geek.
[15:32] <desrt> mpt: you should move to canada
[15:32] <desrt> we live and breathe iso 8601 here
[15:32] <bdrung> Sweetshark: the whitespace change should have only created a one time merge complication
[15:33] <mpt> desrt, or Lithuania. The locale settings in Lithuania are awesome.
[15:34]  * desrt would have assumed they used the same as the rest of europe
[15:34] <mterry> desrt, your locale says otherwise, two-digit-year man
[15:34] <desrt> mterry: i told you this is another bug
[15:35] <Sweetshark> bdrung: yep, that is a merge error, moving the Build-Conflicts: from debian to us.
[15:35] <mterry> desrt, :)
[15:35] <mterry> desrt, in my opinion, it's a bug with all the locales that they aren't just iso8601
[15:35] <mterry> But that's the programmer in me talking
[15:36] <desrt> mterry: this is the kind of bug that would be closed 'Opinion' :)
[15:36] <desrt> mterry: let's next move on to how daylight savings time is only used by morons and how we should all be on UTC as well :)
[15:36] <mpt> mterry, perhaps a cheap way of improving the situation would be to add a calendar button next to the date field.
[15:37] <Sweetshark> bdrung: since gcc-4.6 is in universe that would likely result in a component mismatch. Ill remove that conflict again.
[15:37] <mterry> https://code.launchpad.net/~mterry/indicator-datetime/iso8601/+merge/151989 for review
[15:38] <mterry> desrt, pfft, UTC is so Earth-centric.  I bet there are all sorts of cool systems that work in space and at different velocities
[15:39] <mterry> Ubuntu could be a real leader here!  :)
[15:39] <mpt> mterry, I doubt it, because relativity
[15:39] <desrt> mterry: i cite our motto as an appropriate scope
[15:39] <desrt> linux for HUMAN BEINGS
[15:41] <mterry> mpt, stupid relativity making it hard to fix bugs
[15:42] <cyphermox> mterry: approving...
[15:43] <mterry> cyphermox, ooh thnks
[15:43] <cyphermox> desrt: if there's a lot of prospective martian users, we might want to include them too
[15:43] <cyphermox> but then we'll have to rename the distro
[15:43] <cyphermox> or at least change the tag line
[15:44] <mterry> Yeah, seems specist right now (specie-ist?)
[15:44] <cyphermox> haha
[15:44] <Sweetshark> bdrung: 99c0770a6c5033f39649716f353cdefdf55b9379 removed conflicts against 4.7 so we had quantal on 4.7, so it should be good.
[15:44] <cyphermox> my cat even tends to favor walking on my key
[15:44] <desrt> GNOME had a participant in the womens outreach programme who was offended by this
[15:44] <cyphermox> *keyboard rather than others
[15:44] <cyphermox> desrt: by what?
[15:44] <desrt> 'linux for human beings'
[15:45] <desrt> she was also offended by the term 'human rights'
[15:45] <cyphermox> ah
[15:45] <bdrung> Sweetshark: so this change got lost in the merge
[15:46] <cyphermox> would have loved to hear the reasons why, but this is *so* off topic for here
[15:47] <Sweetshark> bdrung: yep, I already removed the conflicts again, but wont push until you completed your review.
[15:49] <bdrung> Sweetshark: you seem to have lost the ttf-sil-gentium-basic -> fonts-sil-gentium-basic change in the merge
[15:55] <Sweetshark> bdrung: fixed
[16:02] <bdrung> Sweetshark: wrap-and-sort change: paste.debian.net/240140/
[16:02] <bdrung> http://paste.debian.net/240140/
[16:03] <bdrung> you can recreate it (on raring) with: wrap-and-sort  -d . -v && for i in control*.in; do echo >> $i; done
[16:10] <Sweetshark> bdrung: hmm, I did a wrap-and-sort bluntly on ./debian. It also touched ./debian/copyright ...
[16:10]  * Sweetshark checks if that is sane.
[16:10] <bdrung> Sweetshark: just revert the copyright change
[16:10] <bdrung> it trims of trailing spaces
[16:11] <bdrung> Sweetshark: the copyright file should be fixed in the experimental branch and then merged
[16:12] <bdrung> it follows an old format specification and it doesn't follow the guidelines
[16:13] <bdrung> it should use Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
[16:17] <bdrung> Sweetshark: control.in: libreofficeVER-writer has a trailing comma in Recommends
[16:17] <bdrung> Sweetshark: "integration  and a GConf backend" -> two spaces instead of one after "integration"
[16:18] <bdrung> Sweetshark: i finished the review of the debian/ diff. now i will check lintian and do an install+using test
[16:21] <Sweetshark> bdrung: fixed (trailing , was already fixed by wrap-and-sort)
[16:27] <Sweetshark> me wonders what happened to the builders -- 9 hours delay before amd64 starts building ...
[16:44] <micahg> amd64 	21 	277 jobs (7 hours 20 minutes)
[19:12] <seb128> desrt, http://youtu.be/VTlPLZfJDVc
[19:12] <seb128> desrt, migration to logind session if you want to listen in
[19:12] <seb128> desrt, #ubuntu-uds-client-1 on IRC
[19:48] <seb128> desrt, you missed it
[19:49] <bryce> Sweetshark, yeah amd64 has been getting swamped now and then for me
[19:57]  * didrocks waves good evening
[21:59] <attente> thomi: for autopilot, i can't type into gedit when launching it using launch_test_application, while doing start_app_window works fine
[22:01] <thomi> attente: Hi - I wonder if alesage can help you with this - I need to catch up on sleep :-/
[22:01]  * thomi quits IRC
[22:02] <attente> thomi: no worries, thanks
[22:02] <alesage> you're stuck with me attente :)
[22:02] <attente> aw drat :)
[22:05] <attente> alesage: maybe i should first ask what the difference between the two are
[22:06] <alesage> attente I believe one uses the Unity native bindings and the other the autopilot-gtk bindings
[22:06] <alesage> and I believe that typing is possible via autopilot-gtk, just trying to demonstrate to myself
[22:08] <alesage> attente, which tests are you working on?
[22:10] <attente> a test i haven't pushed yet
[22:17] <notgary> I'm attempting to install egg-list-box using jhbuild and am making it as far as the build phase before I get the error "/bin/bash: --pkg: command not found". The full output from that phase can be found at http://paste.ubuntu.com/5591640/. I can't find any package called 'pkg' (unless someone's misspelled dpkg). Can anyone help me out with this?
[23:21] <xnox> is there a desktop beer hangout? =)
[23:21] <jbicha> notgary: you should ask in a GNOME channel about that
[23:32] <notgary> jbicha, thanks. I've managed to figure it out anyway. I was missing the Vala build tools. I'll pester the gnome people next time about it :P