[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? If so, you should pull changeset 360-363
[11:27] <lucidfox> quadrispro, so you're a DD now? 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: 10.10.10.10.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