[01:01] <jamesh> ijohnson: edge Snapcraft might let you create device files under LXD now: https://github.com/snapcore/snapcraft/pull/3218
[01:01] <mup> PR snapcraft#3218: lxd: enable security.syscalls.intercept.mknod if supported to allow snaps to create some device nodes <bug> <Created by jhenstridge> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3218>
[05:16] <mborzecki> morning
[06:32] <mborzecki> ayy store is down?
[06:48] <mborzecki> mvo: hey
[06:48] <mborzecki> mvo: snap downloads fail, store is down apparently https://status.snapcraft.io/
[06:50] <mborzecki> mvo: how does one add 2.45.3 milestone to lp?
[06:52] <mvo> mborzecki: there is a crate milestone button on "https://launchpad.net/snapd/trunk"
[06:52] <mvo> mborzecki: uh, store down not great
[06:53] <mborzecki> mvo: cool, added 2.45.3 now
[06:53] <mvo> mborzecki: thank you
[07:03] <pstolowski> morning
[07:03] <mvo> good morning pstolowski
[07:09] <mborzecki> pstolowski: hey
[07:12] <mup> Bug #1887760 opened: Installing snap app is not updating required content snap <Snappy:New> <https://launchpad.net/bugs/1887760>
[07:13] <mborzecki> mvo: interesting question in the forum https://forum.snapcraft.io/t/minimum-hw-requirements-for-running-ubuntu-core/18892/3
[07:15] <mborzecki> mvo: aiui storage requirements are higher due to recovery, but not sure about ram, guessing it's roughly the same
[07:15] <mvo> mborzecki: yeah, should be the same size for ram
[07:15] <mvo> mborzecki: we always wanted to create a nested spread test that runs with e.g. 256mb to see if it survives our testsuite
[07:16] <mborzecki> mvo:  hmm didn't claudio try that and then he hit the grub problem?
[07:16] <mborzecki> (for uc20)
[07:16] <mvo> mborzecki: yeah, I mean for uc16/uc18
[07:16] <mvo> mborzecki: would still be nice to have such a nested test to ensure we don't regress
[07:18] <mup> Bug #1887760 changed: Installing snap app is not updating required content snap <snapd> <Snappy:New> <https://launchpad.net/bugs/1887760>
[07:21] <mup> Bug #1887760 opened: Installing snap app is not updating required content snap <snapd> <Snappy:New> <https://launchpad.net/bugs/1887760>
[07:25] <mborzecki> mvo: we don't have an official ballpark number for storage though?
[07:27] <mup> Bug #1887760 changed: Installing snap app is not updating required content snap <snapd> <Snappy:New> <https://launchpad.net/bugs/1887760>
[07:27] <mborzecki> hmm wonder whether there is liek a reference gadget that's within the minimal requirements range
[07:30] <mup> Bug #1887760 opened: Installing snap app is not updating required content snap <snapd> <Snappy:New> <https://launchpad.net/bugs/1887760>
[07:33] <mvo> mborzecki: it depends a bit on the kernel size
[07:33] <mvo> mborzecki: like you can have custom kernels that are smaller
[07:33] <mborzecki> ehh, can't build an image, because snapd can't fetch any assertions :/
[07:35] <mvo> mborzecki: otherwise it's 2*(55Mb+31Mb+1Mb+kernel-size)
[07:35] <mvo> mborzecki: the reference kernel is very big (168mb)  but no real device is using that
[07:35] <mvo> mborzecki: well, not *no* but most have a custom optimized kernel
[07:36] <mborzecki> mhm
[07:37] <mborzecki> need to run an errand, back in 1h or so
[07:54] <pstolowski> hmm i store unhappy? even https://api.snapcraft.io times out
[07:57] <pstolowski> okay, it works but super slow here
[08:02] <mvo> pstolowski: yes, unhappy
[08:02] <pstolowski> mhm
[08:20] <mborzecki> re
[08:21] <mborzecki> the store is back, yay
[08:33] <pstolowski> good
[08:49] <mborzecki> is pedronis off today?
[10:10] <mup> PR snapd#9017 opened: o/snapstate: disk space check in Ensure (4/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9017>
[10:18] <pstolowski> pedronis: hi! can we discuss preseed debug after the standup today?
[10:40] <mup> PR snapd#9018 opened: cmd/snap-preseed: check that target path exists and is a directory on --reset <Preseeding 🍞> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9018>
[11:03] <pedronis> mvo: what is the fix-preseed branch for?
[11:05] <mvo> pedronis: this looks like a mistake
[11:05] <pstolowski> yes, was my mistake
[11:05] <pstolowski> sorry
[11:06] <pedronis> ah
[11:06] <mvo> no worries, I will just delete it
[11:06] <pstolowski> github confused me yesterday
[11:06] <mvo> removed
[11:06] <pstolowski> ty
[11:09] <pedronis> pstolowski: yes, I'll try to write something down beforehand as well
[11:11] <pstolowski> pedronis: ok, great, thank you
[11:57] <pedronis> pstolowski: I shared a doc
[11:59] <pstolowski> pedronis: yes, got it, thanks
[12:21] <mup> PR snapd#9019 opened: tests/nested/minimal/minimal-smoke: run core smoke tests in a VM meeting minimal requirements <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9019>
[12:44] <pedronis> pstolowski: I did a pass on #8960
[12:44] <mup> PR #8960: o/snapstate,servicestate: use service-control task for service actions (9/9) <Needs Samuele review> <Services ⚙> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8960>
[12:46] <pstolowski> pedronis: ty!
[13:01] <mup> PR snapd#9020 opened: cmd: add new "snap recovery" command <Created by mvo5> <https://github.com/snapcore/snapd/pull/9020>
[13:22] <mborzecki> cachio: switching to test/main/manual now, i'll push a patch soon
[13:22] <cachio> mborzecki, nice, thanks
[13:23] <ijohnson> mborzecki: do you mean tests/nested/manual ?
[13:23] <mborzecki> ijohnson: yeah, silly typo ;)
[14:05] <mborzecki> cachio: i've updated #9019
[14:05] <mup> PR #9019: tests/nested/minimal/minimal-smoke: run core smoke tests in a VM meeting minimal requirements <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9019>
[14:07] <cachio> mborzecki, nice, thanks, I'll take a look
[14:09] <ijohnson> cachio: I've run the core20-early-config nested spread test 3 times now and it hasn't failed yet, I'm running this on master:
[14:09] <ijohnson> spread -debug google-nested:ubuntu-20.04-64:tests/nested/manual/core20-early-config
[14:09] <ijohnson> is that the right test ?
[14:10] <mborzecki> ijohnson: so it booted then, hmm
[14:10] <ijohnson> mborzecki: I was trying to reproduce the issue cachio explained about the nested test with cloud-init users not being sudoers
[14:11] <mborzecki> ijohnson: can you try running google-nested:ubuntu-20.04-64:tests/nested/manual/minimal-smoke from 9019 too?
[14:11] <ijohnson> mborzecki: sure I can give it a try
[14:11] <mborzecki> ijohnson: thanks
[14:17] <mup> PR snapcraft#3219 opened: meta: detailed warnings for resolution of commands <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3219>
[14:22] <cachio> ijohnson, yes, it is ok
[14:23] <cachio> sometimes it works 5 times
[14:23] <cachio> and then fails
[14:23] <ijohnson> cachio: ack I'll keep trying then
[14:26] <mborzecki> ijohnson: cachio: ha, so i'm starting the vm manually with -serial stdio, and i'm getting `error: invalid signature` (probably coming from grub) and then it gets back to the prompt
[14:26] <ijohnson> mborzecki: are you using google-nested or qemu-nested ?
[14:26] <mborzecki> ijohnson: google-nested
[14:26] <ijohnson> ah then you start a uc20 nested vm right ?
[14:27] <mborzecki> yes
[14:27] <ijohnson> yeah that will need the special spread version with mvo's patches to support specifying the -bios option from an env var
[14:27] <ijohnson> I don't know if the spread that is downloaded from that s3 link has support for that env var or not
[14:27] <mborzecki> do we use that spread binry in any of the tests arleady?
[14:28] <ijohnson> good question, I don't know
[14:28] <ijohnson> I have a locally built version I use
[14:28] <mborzecki> cachio: ^^ do you know where i can get it from?
[14:28] <mborzecki> ijohnson: but.. the test is running qemu directly
[14:28] <cachio> mborzecki, I think you need to build it
[14:28] <mborzecki> ijohnson: as in calling qemu-system-x86_64 arg arg ..
[14:29] <ijohnson> mborzecki: ah hmm good point and you're using external backend
[14:29] <ijohnson> mborzecki: maybe you're missing some of the special nested env vars to make booting uc20 work
[14:29] <cachio> mborzecki, spread pr not merged yet
[14:30] <mborzecki> hmmm i think the test is doing something wrong, we're supposed to boot with efi always
[14:30] <cachio> spread2 does not included that yet
[14:30] <cachio> I could add that
[14:30] <mborzecki> i mean, start_nested_core_vm_unit, it's not setting -bios unless secure boot is enabled
[14:33] <mborzecki> yeah, now it's booting all right
[14:35] <mborzecki> need to run an errand, i'll push the fix when i get back
[14:36] <mborzecki> cachio: ijohnson: afaict we're always expecting efi for uc20, so we need to pass -bios /usr/share/ovmf/OVMF.fd even if secure boot is not enabled in the test
[14:36] <pedronis> mborzecki: should I review 9005 first or 9006 ?
[14:37] <mborzecki> pedronis: i 9005 probably first, then 9006 implements the bootloader bits for grub
[14:53] <cachio> mborzecki, I'll try that after lunch
[14:53]  * cachio lunch
[14:59] <pedronis> mborzecki: is 9006 ready for review, it doesn't seem to match our last discussion?
[15:03] <pedronis> I marked it blocked for now
[15:17] <pedronis> pstolowski: I think #9002 should be split (it's smallish now, but the install case likely needs more tests)
[15:17] <mup> PR #9002: o/snapstate: integrate free space checks with install/refresh and remove (3/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9002>
[15:19] <pstolowski> pedronis: sure, will do, thanks
[15:21] <mup> PR snapd#9014 closed: snapshotstate: move sizer to osutil.Sizer() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9014>
[15:23] <pedronis> pstolowski: thx
[15:29] <ijohnson> pedronis: I'm confused as I thought 9006 does implement what we agreed on
[15:30] <pedronis> ijohnson: is there a mapping between edition and command line?
[15:30] <pedronis> I undersand it has one element atm but there isn't
[15:30] <ijohnson> yes, see my comment it's through the assets registration
[15:30] <ijohnson> i.e.
[15:30] <ijohnson> 	registerInternal("grub.cfg:edition=1:static_cmdline", []byte(grubBootConfigStaticCmdline))
[15:32] <pedronis> heh
[15:32] <ijohnson> it's a little odd using the edition=1 in that, but I think it works fine
[15:33] <pedronis> it's fairly odd
[15:52] <pedronis> ijohnson: mborzecki: I made some more punctual comments
[15:55] <mborzecki> re
[15:57] <mup> PR snapd#9021 opened: snap: implement new `snap reboot` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/9021>
[15:59] <pedronis> ijohnson: I expect the command line and the cfg to change at different pace, hopefully cfg will change more often for a while
[16:04] <pedronis> mborzecki: sorry to have turned a bit more prescriptive in 9006, I'm happy to have a chat tomorrow but I think I explained what I think is a workable approach, that doesn't get annoying the first time we need to change one of the two things
[16:14] <mborzecki> pedronis: thanks for the comments, i see what you mean now, i'll tweak how per edition assets are stored internally the, the current string->[]byte would be cumbersome without coming up with a key like i did now
[16:15] <ijohnson> pedronis: yes that makes sense
[16:16] <pedronis> mborzecki: to be clear I think it fine to store the assets as we do now, and have a different storage
[16:16] <pedronis> for the snippets (as I called them)
[16:17] <mborzecki> pedronis: as for 9005, i think that having some code to consume the api would make it clear how SetExtraCommandLineArgs should work (i.e. reseal internally or not?), maybe i should split out the bits that fix the command line and just leave a PR with the setter?
[16:19] <pedronis> mborzecki: ijohnson: also about 9006, does it make sense to change the commandline without bumping the edition (this is not supported by my approach either) ?
[16:19] <pedronis> mborzecki: 9005, you mean *without* the setter?
[16:21] <mborzecki> pedronis: yes, without, there's bits that make it clear that the order is <mode> <static> <extra> and a tweak to bootloader.ManagedAssetsBootloader.CommandLine()
[16:21] <ijohnson> pedronis: mmm so in that case we would be changing the static portion of the kernel command line. tbh I don't think that will change much if at all for amd64/grub, so I don't think it's imperative we have that accounted for right now, what I think would change more likely over the lifetime of a device is the gadget defined extras
[16:22] <pedronis> mborzecki: sounds ok for now
[16:23] <pedronis> mborzecki: I meand 9005 without the setter
[16:23] <mborzecki> pedronis: yup, the chats interleave, but that's what i understood
[16:24] <pedronis> ijohnson: yea, anyway to support changing the commandline without bumping the edition, we would need both edition (that controls the updating) and some kind of version to track variation
[16:24] <pedronis> we can retrofit it in I suppose if we end up there
[16:25] <ijohnson> pedronis: you could synthetically create an edition from the asset version + kernel cmdline version
[16:25] <ijohnson> I think it is probably fine to retrofit something later on
[16:25] <pedronis> ijohnson: by definition edition is not synthetic, it's way to say I think old devices should get this
[16:26] <pedronis> it's a decision we make
[16:26] <pedronis> like for gadget asserts
[16:26] <pedronis> *assets
[16:26] <ijohnson> sorry all I meant is that the decision on whether devices get an update is a function of both edition + cmd line
[16:26] <pedronis> that's why we reused the term edition
[16:27] <pedronis> ijohnson: yea, but I don't see the static command line as separate from the asset
[16:27] <ijohnson> I think we are in agreement that it's probably fine to not support that right now internally
[16:27] <pedronis> anyway I think we can retrofit things if needed, as long as we are conscious if we stumble on trying to do that
[16:28] <mup> PR snapcraft#3220 opened: review tools: link or copy snap to snap common <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3220>
[16:28] <pedronis> anyway it's another reason why I don't like templating in the commandline
[16:28] <pedronis> it's prone to confusion
[16:28] <pedronis> it's a case were repetition is feature
[16:28] <pedronis> where
[16:29] <ijohnson> well repetition is also prone to bugs using different things in different places
[16:29] <pedronis> well that's why I said we need a test
[16:30] <pedronis> ijohnson: the risk here is doing a change without understanding the consequences
[16:30] <ijohnson> agreed on a test
[16:30] <ijohnson> I don't disagree that there are many risks in this area
[16:30] <pedronis> mborzecki: also one of my comments is that it's probably time to do use "go generate" or similar
[16:31] <mborzecki> pedronis: yeah, i'm not a fan of go generate, but perhaps it is the time indeed
[16:32] <mborzecki> pedronis: we'd still commit the artifacts to git right? otherwise the build process gets weird
[16:33] <pedronis> mborzecki: we can yes, I don't we do for other things though
[16:33] <pedronis> I mean I don't have a strong opinion either way, as long as it works
[16:33] <pedronis> with the packaging
[16:33] <pedronis> this shouldn't change that often (at least after a while)
[16:34] <mborzecki> pedronis: there's some strutil helpers that were committed, but the versiontool/version.go gets generated  iirc
[16:34] <pedronis> yea
[16:37] <mborzecki> hmm why does ssh start in install mode?
[16:37] <pedronis> we don't turn it off unless it's turned off in all modes I think
[16:37] <pedronis> (not saying we shouldn't change that)
[16:38] <mborzecki> ijohnson: cachio: pushed a tweak to #9019
[16:38] <mup> PR #9019: tests/nested/minimal/minimal-smoke: run core smoke tests in a VM meeting minimal requirements <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9019>
[16:39] <pedronis> mborzecki: for clarity: https://github.com/snapcore/snapd/pull/9006#discussion_r455922181
[16:39] <mup> PR #9006: bootloader: compose command line with mode and extra arguments <UC20> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9006>
[16:41] <mborzecki> ijohnson: hmm i see both /usr/share/ovmf/OVMF.fd and /usr/share/OVMF/OVMF_CODE.fd, i've always used the first one, so what's the difference? :)
[16:42] <ijohnson> ah I don't know what's the difference haha
[16:42] <mborzecki> ijohnson: to make it more interesting, botha re owned by ovmf package
[16:43] <ijohnson> they also are slightly different sizes with different hashes :-/
[16:45] <mborzecki> ijohnson: https://github.com/tianocore/edk2/commit/1c50db8adaf9d5ce071e27a518a46cd363ac5efe
[16:46] <ijohnson> ah so the lowercase dir one is the combined vars and code ?
[16:46] <mborzecki> ijohnson: that'd make OVMF.fd all-in-one package
[16:47] <mborzecki> ijohnson: probably makes sense given that you can use your own file to store vars?
[16:47] <ijohnson> yes so in this context it's probably fine for CI to use a single file
[16:54] <mborzecki> ijohnson: force pushed a little note
[18:37] <mup> PR snapd#9022 opened: usersession/userd: do not modify XDG_DATA_DIRS when calling xdg-open <Created by mvo5> <https://github.com/snapcore/snapd/pull/9022>
[18:42] <mup> PR snapd#9023 opened: sysconfig/cloudinit: add CloudInitStatus func + CloudInitState type <Created by mvo5> <https://github.com/snapcore/snapd/pull/9023>
[18:47] <mup> PR snapd#9024 opened: sysconfig/cloudinit: add RestrictCloudInit <Created by mvo5> <https://github.com/snapcore/snapd/pull/9024>
[18:47] <mup> PR snapd#9025 opened: overlord,o/devicestate: restrict cloud-init on Ubuntu Core <Created by mvo5> <https://github.com/snapcore/snapd/pull/9025>
[18:58] <mup> PR snapd#9026 opened: tests/nested/manual: add spread tests for cloud-init vuln <Created by mvo5> <https://github.com/snapcore/snapd/pull/9026>
[19:55] <cachio> ijohnson, I could reproduce the error also in another test
[19:55] <cachio> the cloud init one
[19:55] <cachio> and using an image downloaded from cdimage
[19:55] <cachio> so it is not related to that test
[19:56] <ijohnson> cachio: yeah that's what I kinda expected
[19:57] <ijohnson> cachio: I have now run that other test 6 times and couldn't reproduce it, if you get a debug shell let me know I would love to take a look at the system
[19:57] <cachio> ijohnson, yes, I'll try to reproduce it here
[19:57] <cachio> ijohnson, quick question
[19:57] <ijohnson> yeah sure
[19:57] <cachio> I refresh snapd snap from beta to edge and it reboots the systems
[19:58] <ijohnson> uhhh
[19:58] <cachio> then I revert and the reboot does not happen
[19:58] <cachio> is it expected?
[19:58] <cachio> on uc20
[19:58] <ijohnson> why does it reboot when you refresh the snapd snap ?
[19:58] <ijohnson> afaik we shouldn't reboot with snapd snap refreshes
[19:59] <cachio> well, I expected the same
[19:59] <ijohnson> cachio: was that just a one time thing or does it always happen ?
[19:59] <cachio> ijohnson, I am trying to finish the test to refresh/revert snandp
[19:59] <cachio> and this happened last time
[19:59] <cachio> now I am running again
[20:08] <cachio> ijohnson, so, the only which requires reboot is the kernel?
[20:08] <ijohnson> cachio: the kernel, the base snap (core20 for uc20, core18 for uc18, core for uc16), and the gadget snap if and only if there are gadget updates
[20:11] <cachio> ijohnson, ok
[20:11] <cachio> so I need to update the gadget scenario beause I am waiting the reboot
[20:16] <ijohnson> 👍


[10:24] <wrst> good morning tenc
[15:06] <tenc> Good morning wrst, Unit193, twayneprice et. al. :)
[15:06] <wrst> morning tenc, all going well?
[15:07] <wrst> oh and Omnifrog you still healthy? :)
[15:09] <tenc> This week isn't great. Some mixup at the pharmacist and I'm out a prescription until today.
[15:09] <tenc> But otherwise things are OK. About to checkout Debian on my tour of distros after deciding Xubuntu was great on my laptop but not as good on my desktop.
[15:09] <tenc> How about you?
[15:21] <wrst> doing well, dbian is a great distro
[15:21] <wrst> *debian
[15:24] <tenc> Arch has quite a bit of intrigue for me too but I think I'll save that for another time.
[15:24] <wrst> tenc: I love arch, I use it exclusively on the desktop
[15:24] <wrst> but it isn't for everyone
[15:25] <tenc> That seemed to be the consensus from people I've talked to about it.
[15:25] <wrst> but once it is setup you are good to go for a really long time
[15:25] <wrst> well after you set it up a couple of times usually you will bork it a little then get in the groove
[15:26] <tenc> It seems like a kind of badge of honor among Linux users to run/successfully set up Arch.
[15:30] <tenc> I wish I had more time to play around with the different distributions. As it is I have to borrow time here and there to play with them.
[18:17] <Unit193> Good afternoon.
[18:20] <tenc> Hiya Unit193
[20:43] <wrst> wb chris4585
[20:44] <chris4585> thanks wrst
[20:44] <wrst> how are you doing?
[20:52] <chris4585> I'm alrright, off today, chillin
[20:53] <chris4585> I reinstalled manjaro wrst and its running smoothly
[20:53] <wrst> cool chris4585, why the reinstall?
[20:53] <chris4585> just needed a clean system
[20:53] <chris4585> mint was working, but I had a few issues
[20:54] <wrst> a clean system is a good feeling :)
[20:54] <chris4585> yes, a little bit snappier
[20:54] <chris4585> I'm using the xfce or main edition, and just installed cinnamon
[20:54] <wrst> I must say with my arch setup I really haven't had much in the line of performance decrease short of enable additional services
[20:55] <wrst> I havea  systemd cleanup day on occassion
[21:05] <chris4585> yeah
[21:05] <chris4585> the other day I noticed an instant performance increase
[21:05] <chris4585> my machine was running for a couple days though
[21:05] <chris4585> like two straight weeks
[21:05] <chris4585> lol
[21:17] <wrst> 2 weeks?  21:17:35 up 29 days,  1:45,  1 user,  load average: 0.00, 0.01, 0.05
[21:17] <wrst> :P


[11:51] <wolfger> good morning
[12:42] <jrwren> good morning
[12:49] <cmaloney> morning
[12:49] <cmaloney> hey wolfger, how's the supplier life?
[12:51] <wolfger> still pretty sweet
[12:51] <cmaloney> awesome
[12:51] <wolfger> but the correct terminology is "purchased service". We don't supply anything except knowledge and labor.
[12:52] <wolfger> and it sounds like Chrysler wants to cut purchased services out of IT entirely...
[12:52] <cmaloney> ugh
[12:53] <wolfger> they think that AME (now simply called ME) can do the validation of the IT systems in-house, and all IT needs to do is the configuration
[12:53] <cmaloney> someone realized they're spending money again
[12:53] <wolfger> while it's not great news for us, we're laughing about the inevitable failure of that idea
[12:54] <wolfger> in the meantime, I'm pretty sure our Ford + Miscellaneous projects will support us
[12:54] <cmaloney> well, in a perfect world they might be correct
[12:54] <wolfger> but currently working on one or two FCA de Mexico projects
[12:54] <cmaloney> sweet
[12:54] <cmaloney> viva los FCA
[12:55] <wolfger> oh, undoubtedly the AME boys *could* do our job.
[12:55] <cmaloney> yes, mg spanish sucks
[12:55] <wolfger> but they currently lack the ability or desire
[12:55] <cmaloney> which is why your company was there in the first place
[12:56] <cmaloney> it's cyclic
[12:56] <cmaloney> they feel independent when someone realkzes they're spendimg too much money
[12:57] <cmaloney> and they get help when they realize they're losing money
[12:57] <cmaloney> it's all e perception du jour
[12:57] <jrwren> that reminds me of GM and their HP contract.
[12:57] <jrwren> wtf was it before HP? The Ross Perot company name?
[12:57] <cmaloney> eds
[12:57] <jrwren> EDS!
[12:58] <jrwren> ty cmaloney
[12:58] <jrwren> GM decides EDS is too much $$ so goes out to bid.
[12:58] <jrwren> HP wins the bid.
[12:58] <jrwren> HP buys EDS to provide the exact same service
[12:58] <jrwren> couple years later GM decides to do it all in house.
[12:58] <cmaloney> yep
[12:58] <jrwren> I'm actually a huge fan of all in house. Look at Quicken Loans
[12:59] <jrwren> or look at any company which claims to be a tech comany
[12:59] <wolfger> then Chrysler says "GM did this, so we're going to do it (even though GM stopped)
[12:59] <jrwren> I read a quote a copule days ago from CEO of Chevron. He said they are a technology company, not an oil company.
[12:59] <jrwren> Because the tech for drilling an deliver changes so fast.
[12:59] <jrwren> Its a good mentality to have.
[13:00] <cmaloney> yes, we have a cock-eyed auto indistry because they keep one eye on the competition
[13:00] <wolfger> the problem with in-house at FCA is that they are a car company and don't give a shit about computer programs (outside of in-vehicle systems)
[13:01] <wolfger> so when they do it in-house, they do it with virtually no budget or support
[13:01] <wolfger> or buy-in
[13:01] <cmaloney> nice
[13:01] <cmaloney> brb
[13:02] <wolfger> but when they go outside, then the people who do the work don't really care if FCA gets what they need, as long as they get what they asked for and was quoted.
[13:02] <wolfger> it's a total lose-lose for the company
[13:02] <jrwren> FCA?
[13:04] <brousch> https://www.forrester.com/Software+Must+Enrich+Your+Brand/fulltext/-/E-RES104924
[13:04] <wolfger> Fiat Chrysler Automobiles
[13:04] <wolfger> They stopped being Chrysler some time ago. It'll be 5 years before people stop calling them Chrysler though
[13:05] <wolfger> by then they'll probably change hands again.
[13:05] <wolfger> or just drop the Chrysler name entirely I think
[13:09] <jrwren> brousch: WAT?
[13:10] <brousch> It's a report from Forrester on this topic and costs $500, so even CEOs will believe it
[13:10] <jrwren> hahaha
[13:12] <wolfger> rofl
[13:13] <wolfger> I was wondering why it cost $500 or who would pay that much for it
[13:25] <cmaloney> wolfger: It's an old ploy
[13:25] <cmaloney> people feel more attachment to something they spend real money on
[13:26] <cmaloney> even if that information isn't terribly good
[13:26] <emodzhi> which is why FOSS has such trouble
[13:26] <emodzhi> it doesn't cost enough
[13:26] <cmaloney> precisely
[13:26] <emodzhi> it doesn't get any lines in budgets, and hence doesn't exist to decision makers
[13:27] <emodzhi> and technical influencers aren't put in the position of arguing for it, and so they spend less time convincing themselves of its utility
[13:27] <emodzhi> it's quite perverted, really.
[13:27] <cmaloney> Which is why Red Hat is brilliant for charging folks for FLOSS.
[13:27] <emodzhi> yup
[13:38] <jrwren> I was thinking IBM
[13:40] <cmaloney> IBM is one of those companies that I continue to boggle at how they can get something so right and over time manage to get it so wrong.
[13:41] <cmaloney> it's like they have this "suck" field (like Star Trek)
[13:41] <emodzhi> it's their very special niche
[14:02] <jrwren> IBM is huge, more employees than MSFT or GOOG last time I looked
[14:03] <jrwren> much like those companies, there are going to be much variation of suck, mediocrety, and good.
[14:03] <cmaloney> And a shining example of marketing and impllementation by committee
[14:03] <jrwren> definitely true of everything GOOG i've seen lately.
[14:03] <jrwren> and most things MSFT with very few exceptions.
[14:04] <cmaloney> Yeah, they're starting to get their big-company schitzophrenia
[14:04] <jrwren> yup
[14:04] <cmaloney> (likely sp)
[14:04] <cmaloney> MSFT is in a very strange place
[14:05] <cmaloney> They seem like they're back in embrace mode
[14:05] <cmaloney> But it's the first fime I've seen them actually embrace, not choke.
[14:07] <jrwren> cmaloney: it depends on the area.
[14:07] <jrwren> msft also has a lot of smoke and mirrors going on right now.
[14:07] <cmaloney> Developer area seems embracing
[14:08] <jrwren> like, ".net on linux"
[14:08] <jrwren> but then you look at what is actually there, and its nothing usable.
[14:08] <jrwren> or rather, its usable for dev and toy
[14:08] <cmaloney> Ah
[14:08] <jrwren> it is nothing production ready.
[14:08] <cmaloney> Well then I'll update back to "cautiously optimistic"
[14:09] <cmaloney> Apple is down to "Please figure out how to resurrect Steve Jobs"
[14:10] <jrwren> i'm optimistic about apple.
[14:10] <cmaloney> I think they need a seance.
[14:10] <jrwren> but they aren't open at all.
[14:10] <jrwren> in fact, they intentionally close things
[14:10] <cmaloney> No, and they're even more closed than before
[14:10] <jrwren> see LLVM and swift :(
[14:10] <cmaloney> if that's possible.
[14:10] <jrwren> I think they were only open before out of necessity
[14:10] <cmaloney> They pulled the old System 7 archives.
[14:15] <jrwren> wha?
[14:15] <cmaloney> http://www.earlymacintosh.org/disk_images.html
[14:15] <cmaloney> Check the System 6.0 area
[14:17] <brousch> wat? cmaloney wants to play Go?
[14:17] <cmaloney> brousch: Yeah, I'd like to get back into it
[14:17] <cmaloney> and I can't think of a better way than getting trounced.
[14:18] <brousch> Well I've been stuck at 25k for a long time
[14:20] <cmaloney> Apparently i'm not getting email notifications though.
[16:49] <cmaloney> http://pnacl-amiga-emulator.appspot.com/
[17:01] <jrwren> SO EVIL!!! https://plus.google.com/+gimp/posts/cxhB1PScFpe
[17:01] <jrwren> I din't htink pnacl was still a thing
[17:02] <jrwren> ha, its not, even teh link on that page is dead.
[17:02] <cmaloney> OK, if that's true then SF is pretty much dead to me.
[17:02] <jrwren> i wonder what they would sell SF for.
[17:02] <jrwren> maybe some devs should pool togethre and buy it, for the good of the world :)
[17:05] <cmaloney> Man, this is a bad week for historic me.
[17:14] <DrDaemonEye> cmaloney: what makes you say that?
[17:17] <cmaloney> https://plus.google.com/+CraigMaloney/posts/JTSZxpVPNCr
[17:17] <cmaloney> DrDaemonEye: ^^
[17:18] <DrDaemonEye> I'll have to look at it tonight
[17:19] <brousch> Ah geez
[17:20] <cmaloney> brousch: I know. this pisses me off on many levels, not the least of which are good people are getting the shaft because of short-sighted decisions.
[17:21] <cmaloney> Had this discussion with the (then) community manager when they started this bullshit.
[17:21] <cmaloney> He didn't last long there, sadly.
[17:22] <brousch> Hm, I have seen brondsema in a long time, but I think he still works there
[17:23] <cmaloney> Last I saw him he was still there, but that was over a year ago
[17:23] <brousch> He got busy getting married and a house and such and hasn't been to GRPUG in a while
[17:53] <jcastro> it is raining
[17:53] <jcastro> I just want like one day so I can grill
[17:54] <jrwren> its raining again?   Could get some decent mowing with the push mower without any problems.
[20:02] <jrwren> it never rained here :(
[20:03] <cmaloney> You wanted it too much
[20:18] <_stink_> haha
[23:31] <cmaloney> not sure what is going on at bean and leaf but it is packed
[23:31] <cmaloney> so i am bailing
[23:44] <cmaloney> "Birmingham Groves and Seaholm high schools “Live! In Concert: Charity Fashion Show” to benefit Birmingham Youth Assistance, 6:30-8:30 p.m. May 27 at Bean & Leaf Café in Royal Oak. Tickets are $5 for students and $8 for adults in advance at the main office of Groves High School, $10 at the door."
[23:45] <cmaloney> If anyone wants to have CHC at our place LMK and I'll PM you the address.


[20:25] <CoderEurope> popey, Is there an Ubuntu-podcast show today ? I've got the snackey-biscuits in this time :D


[00:00] <marienz> mind if I send bonny here from #freenode?
[00:06] <rww> o/
[00:06]  * rww takes a look
[00:09]  * rww beats up bantracker for taking so long
[06:52] <rww> yay network problems!
[07:27] <rww> ... what in the name of otters is happening in -offtopic?
[07:31] <topyli> kids going through the topics in the o4o factoid one by one after seeing it
[08:58] <ikonia> @mark #ubuntu zcat[1] offensive as he parts without the info he wants, not the first time he's done it either, forwarded
[09:22] <zcat[1]> ok been trying to follow https://help.ubuntu.com/10.04/serverguide/C/advanced-installation.html to the absolute letter step by step. created two partitions on each drive. make them all bootable. Go to create MD device and 1) it only ever offers me sda1 and sdb1 and 2) after making the SD device there's still no raid device, only the partitions. what might be going wrong here? again, simple 250G SATA drives on a simple 4-sata port mothe
[09:22] <zcat[1]> rboard not fakeraid or hardwareraid ....
[09:23] <zcat[1]> does anyone in this channel have a clue?
[09:34] <Tm_T> patience++
[09:35] <elky> hah, he didn't even notice he's in the wrong channel
[09:44] <ikonia> if he doesn't get what he "thinks" he wants straight away, he goes abusive and parts and thinks it's forgot about
[09:44] <ikonia> I've watched him do it before, hence the forward now
[09:49] <elky> ikonia, backup in #u please
[09:50] <elky> Tm_T, maybe you?
[10:06] <Tm_T> elky: what is it?
[10:06] <ikonia> huh
[10:06] <ikonia> sorry, I was away
[10:06] <ikonia> what's up
[10:06] <elky> oh just BaKeR trolling and insulting me directly
[10:07] <ikonia> sorry, I was away from desk
[10:07] <ikonia> as I am about to be now for 15 minutes
[10:08] <elky> go for it, he's stopped for now
[10:09] <elky> aand gone
[10:12] <Tm_T> my hilight list is becoming longer and longer
  serious troll in -ot
[15:42] <ikonia> tingtongtux = olit who has been a bit "odd" recently
[15:45] <ikonia> everytime he does an odd thing and gets asked to not do it, he makes a comment and logs out sulking then comes back complaining about it
[16:14] <mneptok> @bansearch 87.113
[16:14] <mneptok> @login
[16:14] <mneptok> @bansearch 87.113
 spamming blogspot urls again (as was anis_ before)
[17:38] <oCean> in #u
[17:39] <oCean> and quit
[17:43] <ikonia> this guy again
[18:27] <ikonia> Nillerz didn't respond to any pm's for the record
[21:39]  * Jordan_U hugs idoru
[23:28] <Jordan_U> Someone deal with iv4n I can't due to lag.
[23:29] <Jordan_U> Looks like it finally worked.


[23:43] <guiverc> my lunar isn't booting  :(  shim issue.  my box is dual boot; jammy & lunar; i only used jammy yesterday & it still boots, but I gather shim 15.7 update is reason that lunar fails to now boot; anyone got anywhere I can read up so I can learn more about issue & how to fix (noted shim 15.7 discussion yesterday on #ubuntu-devel ML, but I need more basic detail to learn more so I can fix it; i mostly use older hardware)


[20:37] <alekos_> Hi Guys. Hope you all had a good holiday. I am getting some interesting behavior from Juju when trying to bootstrap a MAAS node, hopefully someone here can help out.
[20:37] <alekos_> machine-0: 2014-12-27 20:36:10 ERROR juju.worker runner.go:218 exited "environ-provisioner": failed to process updated machines: broker failed to stop instances: gomaasapi: got error back from server: 503 SERVICE UNAVAILABLE (Unable to change power state to 'off' for node network: another action is already in progress for that node.) machine-0: 2014-12-27 20:36:12 ERROR juju.worker runner.go:218 exited "firewaller": machine 1 is not p
[20:38] <alekos_> while that message appears in the juju debug-log output, maas shows nodes deploying, then releasing a few seconds later


[00:02] <magcius> mgz, http://msdn.microsoft.com/en-us/library/aa363866%28v=vs.85%29.aspx
[00:02] <magcius> mgz, also, ctypes
[00:02] <mgz> also need to be running as an administrator
[00:03] <mgz> which is just what stopped happening by default in the release that api was made available.
[00:03] <magcius> in Windows 7, users have the "Create symbolic link" permission by default
[00:03] <magcius> but meh
[00:03] <magcius> not worth it
[00:03] <magcius> it would help if you guys just wouldn't *fail*
[00:04] <mgz> I agree.
[00:05] <mgz> what's your source on the symlink cap being for everyone under 7?
[00:05] <mgz> I thought I'd read the opposite.
[00:06] <magcius> personal experience
[00:06] <magcius> I don't have the permission, and mklink works for me
[00:12] <Jordan_U> How can i ignore mode changes? I'm working on a project locally (on my Ubuntu machine) and on a Windows machine accessed via CIFS and I don't want bzr diff or my commit history to be cluttered with mode changes.
[00:13] <mgz> good question.
[00:15] <mgz> Jordan_U: ask on the mailing list if no one pops up here with an answer.
[04:10] <KombuchaKip> I have a commit I'd like to make to a repository I don't have write access to. How can my commit be sent as an email to the project maintainer?
[04:17] <KombuchaKip> How can I generate a diff for my local working copy when it contains binary files that I added? Right now the binary data isn't generated in bzr diff output.
[04:25] <cody-somerville> KombuchaKip, bzr send
[04:25] <KombuchaKip> cody-somerville: I tried. I get a "ERROR: No submit branch known or specified"
[04:25] <cody-somerville> KombuchaKip, 'bzr help send' to see which arguments it expects and how to use it
[04:26] <KombuchaKip> cody-somerville: I used "bzr send -o ~/Desktop/Kip.diff" which is what the docs say.
[04:27] <cody-somerville> You need to pass as the second argument the branch you wish to submit your changes to
[04:27] <KombuchaKip> cody-somerville: How do I find that out?
[04:29] <cody-somerville> KombuchaKip, Not sure I understand your question.
[04:29] <KombuchaKip> cody-somerville: How do I know what the second argument is? I checked out my code from a URL at bzr://blah
[04:30] <cody-somerville> KombuchaKip, thats the second argument
[04:30] <KombuchaKip> cody-somerville: Right.  Doesn't that cause headaches at my end because now the repos are not in sync?
[04:32] <cody-somerville> KombuchaKip, You'd merge in any changes from them, make the changes they've requested of you, and then resubmit.
[04:32] <KombuchaKip> cody-somerville: Is there not simply a way I can generate a current diff, including the binary files as well?
[04:34] <cody-somerville> KombuchaKip, You could commit, then push your branch to somewhere they can access, and then ask them to merge your branch in
[04:34] <KombuchaKip> cody-somerville: I think I'd prefer to just generate a diff, like I am used to with svn. How do I get bzr diff to generate binary diffs also?
[04:38] <cody-somerville> KombuchaKip, You can't do that with svn. However, you can install bsdiff which is a program for generating and applying a patch between two binary files and tell bzr to use that via the --using argument to bzr diff.
[04:39] <KombuchaKip> cody-somerville: That's possible, but convoluted. I guess they call it bazaar for a reason.
[04:39] <cody-somerville> Just sharing your branch with them is much easier.
[04:40] <cody-somerville> KombuchaKip, It has nothing to do with bzr - patches aren't optimal for representing changes to binary files since binary files aren't human readable and patches are intended to be.
[04:41] <KombuchaKip> cody-somerville: Not quite. base64 is perfectly valid data for in a patch. Sometimes its necessary for non-plain text files that changed.
[16:40] <bialix> good evening dear #bzr
[16:40] <fullermd> Evening already?!  I've barely had lunch   :(
[16:41] <bialix> my evening is your lunch :-D
[16:41]  * bialix waves at fullermd
[16:59]  * mgz waves at bialix
[16:59] <bialix> hey Martin!
[17:02] <magcius> is there a way I can get 'git add' like semantics?
[17:02] <magcius> i made changes to a CSS file that I don't want to commit
[17:07] <bialix> magcius: bzr shelve allows you git stash your changes; bzr view allows you to specify subset of the tree you work on
[17:08] <magcius> bialix, bzr shelve doesn't allow me to pick out specific parts.
[17:08] <magcius> It says "yes or no", and I want half of it.
[17:09] <bialix> setup editor and then you'll be able to do so
[17:09] <magcius> just $EDITOR?
[17:09] <bialix> in bazaar.conf add to DEFAULT section:
[17:10] <bialix> change_editor = vimdiff -fo @new_path @old_path
[17:10] <bialix> or adjust the command line for your favorite editor
[17:10] <bialix> magcius: ^
[17:12] <magcius> emacsclient -e '(diff "@old_path" "@new_path")'
[17:12] <magcius> yay
[17:13] <bialix> in the shelve prompt press 'e' now
[17:13] <magcius> why doesn't ^C work?
[17:13] <magcius> now, when I press "y", I'm telling it to stash it?
[17:14] <magcius> put it away for later?
[17:17] <bialix> yep
[17:17] <magcius> and how can I get it back?
[17:19] <bialix> magcius: bzr unshelve
[17:20] <magcius> ok, thanks!
[17:20] <bialix> :-)
[18:25] <ablmf333> I've 2 branch, 'svn' is a bzr checkout of svn branch, 'bzr' is branched from 'svn' by `bzr branch'.  Now 'svn' switched to a new branch, And I got lots of conflict when I try to merge 'bzr' to 'svn'.
[18:25] <ablmf333>  I guess that's because the new svn branch is created later than those changes in 'bzr'
[18:25] <ablmf333> Is there nice way to handle this?


[19:14] <atrus> is there a way to get the new indicator-* stuff in karmic, via a ppa? the indicator-applet-developers ppa seems to have some broken dependancies
[19:14] <vish> atrus: qense has a ppa ,
[19:15] <qense> atrus, vish: but mine is bad, you don't want to use it
[19:15] <qense> there is some other, give me a sec
[19:17] <qense> atrus, vish: the PPA you want is at <https://launchpad.net/~indicator-applet-developers/+archive/indicator-core-ppa/?field.series_filter=karmic>
[19:17] <atrus> i think that's the one i'm using :)
[19:18] <atrus> let me see
[19:18] <qense> oh
[19:18] <qense> well, I'm afraid I can't help you then
[19:19] <atrus> yeah, the dependancies seem to be broken there. not sure if that's a known issue or not, or who to poke.
[19:20] <qense> atrus: this IRC channel would be the right place
[19:20] <qense> but I'm not sure if the right people are here
[21:31] <atrus> qense: in particular, it seems the problem is that indicator-me depends on libdbusmenu-glib0 and, libdbusmenu-gtk0 whereas the rest of the indicator stuff depends on s/0/1/, and 1 breaks 0.
[21:33] <qense> atrus: OK, but I'm afraid I can't help you with the PPA, I'm not maintaining it. Try one of the members of the indicator developers team.
[21:33] <atrus> yeah, just following up here. wondering if any of those people might be around.


[19:13] <ibeardslee> morning
[19:45] <chilts> morning
[20:33] <Atamira> morning
[20:39] <ajmitch> morning
[22:43] <ojwb> morning
[22:45] <hads> morning
[22:49] <thumper> morning
[23:39] <kcj> Morning.


[04:00] <calc> anyone around who has dual head setup that can try to reproduce a bug for me?
[04:54] <pace_t_zulu> hey guys, i'd like to take a shot at bug #332253 in the epiphany-browser
[04:55] <pace_t_zulu> can someone point to the repo for epiphany-browser? right now i am using "apt-get source epiphany-browser"
[06:37] <pitti> Good morning
[07:15] <lool> hey pitti
[07:15] <lool> pitti: I think you said the UNR image didn't fit on your 1 GB USB stick, how large is it exactly?
[07:16] <pitti> lool: the current one does now (the 947 MB one)
[07:16] <lool> pitti: Could you recheck with the image we rerolled yesterday; it's 992837632 bytes
[07:16] <lool> Ah good
[07:16] <lool> pitti: I'm still curious about your dev size :)
[07:16] <pitti> lool:   storage.removable.media_size =<PHONE_NUMBER>  (0x3d500000)  (uint64)
[07:17] <lool> Thanks
[07:17] <pitti> but don't take that as an assumption that all 1 GB sticks are exactly that large :)
[07:17] <pitti> I think we can expect 1,000,000,000 bytes, not more
[07:17] <lool> I don't, but plars says the image is too big for him
[07:18] <lool> And it's less than 1 billion bytes so I wonder what's happening
[07:18]  * pitti -> breakfast, back in 10
[07:18] <lool> Will check with him when he comes up
[07:18] <lool> guten Appetit!
[07:30] <pitti> danke :)
[08:11] <huats> hi everyone
[08:24] <pitti> hey huats
[08:24] <huats> hello pitti
[08:24] <huats> how are you ?
[08:25] <seb128> hey pitti huats
[08:25] <huats> seb128: o/
[08:43] <seb128> slomo: hi
[08:43] <chrisccoulson> hey pitti - you merged my tracker branch in to ubuntu-desktop last week for a SRU (installing the evolution plugin). Could you hold fire on uploading that (tomorrow?), as I'm working on some other fixes at the moment
[08:44] <pitti> chrisccoulson: sure, thanks
[08:44] <chrisccoulson> thanks:)
[08:44] <slomo> seb128: hi :)
[08:44] <seb128> slomo: could you have a look to bug #358426 when you have some time? it seems similar to this crash when gst-ffmpeg and ffmpeg were not in sync but seems to be different (ie the versions are in sync and the crash is still there withou gst-ffmpeg)
[08:45] <seb128> slomo: the bug has a gst_debug log, stacktrace, etc ... I'm not sure what to ask next
[08:47] <slomo> seb128: might be the other one... which version of gst-plugins-bad is in ubuntu, does it link to liblrdf0?
[08:48] <seb128> slomo: the dpkg -l | grep gstreamer log is in the bug
[08:49] <seb128> slomo: gst-plugins-bad is not installed by looking at the log
[08:49] <slomo> ok
[08:50] <seb128> slomo: the bug is an intrepid one, not jaunty too (ie 6 month old versions)
[08:50] <seb128> slomo: http://launchpadlibrarian.net/25174573/log is the gst_debug log
[08:50] <slomo> seb128: well, unless i miss anything there's no backtrace because g-s-d seems to run fine in gdb... hm, two things might be useful
[08:50] <slomo> seb128: a) GST_REGISTRY_FORK=no gdb --args g-s-d ...... might give a backtrace of the crash
[08:51] <slomo> b) GST_REGISTRY_FORK=no valgrind g-s-d .... might give something useful
[08:51] <slomo> that's a crash i've never seen before :)
[08:51] <seb128> ok thanks
[08:52] <seb128> slomo: I've asked for those now, thank you
[08:52] <slomo> np :)
[09:02] <didrocks> hey everybody o/
[09:02] <pitti> hey didrocks, bonjour
[09:02]  * pitti hugs slomo, long time no see
[09:03] <didrocks> Guten Tag pitti :)
[09:03] <seb128> lut didrocks
[09:04] <didrocks> hey seb128, quieter time just before the release?
[09:04] <seb128> didrocks: yes, using it to catch up on bug triage ;-)
[09:05] <didrocks> seb128: huge work :-)
[09:05] <seb128> indeed
[09:05] <seb128> and you? enjoying some non busy time before karmic opening and uds? ;-)
[09:07] <didrocks> seb128: not really, framasoft volonteers are rereading my book so that I can catch my french grammar mistakes and I am preparing Orsys lesson :-)
[09:07] <seb128> orsys?
[09:07] <didrocks> so, it's a continuing flow of work, no rest ;)
[09:08] <didrocks> orsys (http://www.orsys.fr/) is training company specialized in computer science firm audience
[09:09] <seb128> ah ok
[09:09] <seb128> you know how to keep busy apparently ;-)
[09:10] <didrocks> seb128: yes, and still reading the GNOME documentation :-) I also gave a shot to kde since I didn't boot it since approximately 5 years... What a change :)
[09:10] <seb128> still using it?
[09:10] <seb128> how did you like it?
[09:11] <didrocks> seb128: very pleasant to the eye, but I don't like having too many configuration options and lack of "coherence"
[09:11] <didrocks> it was just for testing :-)
[09:12] <seb128> good ;-)
[09:42] <rickspencer3> asac: seb128 pitti Riddell
[09:42] <rickspencer3> what's the word on the street?
[09:42] <pitti> hey rickspencer3
[09:42] <seb128> hey rickspencer3
[09:42] <rickspencer3> hi pitti
[09:42] <rickspencer3> hi seb128
[09:42] <seb128> things look good from here
[09:42] <pitti> All systems operate within normal parameters, Captain!
[09:42] <rickspencer3> lol
[09:42] <pitti> nothing on my radar
[09:42] <rickspencer3> bryce would be saying "she can't take much more"
[09:43] <pitti> argh, except that launchpadlib broke my shiny retracers again
[09:43] <rickspencer3> http://www.reddit.com/r/Ubuntu/comments/8ebbu/any_others_running_jaunty_on_intel_gm965gl960_try/
[09:44] <rickspencer3> pitti: arg
[09:44] <rickspencer3> the launchpad team is in the next room here, should I ask them to help?
[09:45] <pitti> nah, that's fine
[09:45] <pitti> rickspencer3: let me track it down first, produce a test case, and then you can drop that test case on their feet :)
[09:45] <pitti> launchpadlib.errors.HTTPError: HTTP Error 412: Precondition Failed
[09:45] <pitti> who could imagine to have _even better_ error messages?
[09:48] <pitti> rickspencer3: how's the war room today?
[09:54] <rickspencer3> pitti: so far so good
[09:56] <cassidy> mpt: hi. I use to add you in CC in Empathy bugs proposing a controversial UI/usuability change. Don't hesitate to tell me if that annoys you and I'll stop :)
[10:21] <asac> rickspencer3: all good in jaunty ;)
[10:26] <asac> rickspencer3: btw, i didnt get a freeze yesterday :/
[10:29] <rickspencer3> asac: you mean with the script?
[10:30] <asac> rickspencer3: i didnt run the script. just did normal use.
[10:30] <asac> rickspencer3: you have a URL to the script at hand so i can fire it up?
[10:30]  * rickspencer3 gets bug
[10:31] <rickspencer3> https://bugs.edge.launchpad.net/bugs/359392
[10:31] <rickspencer3> asac: it's repro.sh in there ^^
[10:34] <rickspencer3> asac: here's a direct link:
[10:35] <rickspencer3> http://launchpadlibrarian.net/25683477/repro.sh
[10:35] <rickspencer3> note that you need to install wmcntrl to make it work
[10:35] <rickspencer3> also, compiz needs to be enabled
[10:36] <asac> ok let me check wmcntrl
[10:41] <asac> rickspencer3: i assume that in the while loop using workspace 3 would also work (instead of 4). i only have 4 workspaces
[10:41] <rickspencer3> oh
[10:41] <rickspencer3> asac: you need to have 6 workspace, I should have mentioned
[10:42] <rickspencer3> also, your computer will be totally unusable, and it's an infinite loop
[10:42] <rickspencer3> I stop the script by logging out
[10:44] <asac> rickspencer3: so if i change the workspace it changes to to 3 its known to not work?
[10:44] <asac> let me use 6 workspaces
[10:44] <asac> atm its flipping workspaces happily
[10:44] <asac> and no freeze
[10:45] <rickspencer3> then it's working
[10:45] <rickspencer3> it usually take 2-4 minutes to freeze
[10:47] <asac> k i let it running with 6 workspaces now
[10:47] <asac> lets see
[10:50] <asac> still action ;)
[10:50] <asac> produces massive amount of heat. had to put my laptop somewhere else
[10:56] <asac> rickspencer3: still running ;)
[10:57] <asac> so no. thats probably "made for germany" ;)
[11:02] <asac> ENOTREPRODUCIBLE
[11:02] <asac> stoped this experiemtn now ;)
[11:51] <mpt> asac, https://wiki.ubuntu.com/NotifyOSD#Firefox
[11:51] <mpt> cassidy, that's fine
[11:53] <asac> mpt: isnt that the status-quo?
[11:53] <asac> ah there is instead and alternatively
[11:54] <asac> mpt: so assuming that mozilla didnt like that; do you have other approaches how we can use native notifications somehow?
[11:55] <asac> mpt: what about using indicators for downloads/updates-available, etc.
[11:55] <mpt> asac, no, I think using notification bubbles for that would be a bit worse than having no notification at all.
[11:56] <asac> but our answer can't be: just drop notifications completely
[11:56] <asac> downloads completed must be a common use-case we should unify
[11:56] <asac> what do we do with other downloaders (like transmission, etc.)
[11:57] <asac> do those display notifications?
[11:57] <mpt> That's why in <https://wiki.ubuntu.com/NotifyOSD#Transmission> I make exactly the same recommendation as for Firefox. :-)
[11:57] <asac> ah i see ;)
[11:57] <asac> found it right after saying that
[11:57] <mpt> I don't know how they've actually done it, though
[11:57] <asac> mpt: ok. but hwo about different approaches. what about indicators instead of jumping the full dialog in your face?
[11:58] <mpt> asac, what do you mean by "indicators"?
[11:58] <asac> a download indicator?
[11:58] <asac> ;)
[11:58] <asac> similar to message-indicator ;)
[11:58] <mpt> oh, a menu for downloads?
[11:59] <asac> mpt: why not. a menu where the folders that have finished downloads are indicated
[12:00] <mpt> I think that wouldn't be appropriate, because they're things you sometimes want to keep an eye on the progress of, but while a menu was open you couldn't really do anything else.
[12:00] <mpt> That's basically the Mathusalem idea.
[12:01] <mpt> A unified file copying/moving window would be nifty, and Firefox/Transmission downloads could hook into that, but that wouldn't be a menu.
[12:01] <asac> mpt: err
[12:01] <asac> currently the notification is only done when downloads have finished
[12:01] <asac> i dont want to display the progress of the downloads in the indicator
[12:01] <asac> just indicate folders with finished (but unseen) downloads
[12:02] <asac> mpt: i agree that having a unified download progress display would be something - but for the future
[12:02] <asac> for now i want to find a solution so download finished can be done in a notification bubble (because if we say that has to stop mozilla will never adapt our thing)
[12:03] <mpt> As I said, I think using a notification bubble would be worse than no notification at all.
[12:03] <asac> mpt: you said an "actionless notification bubble"
[12:03] <asac> thats why i suggested: "actionless notification bubble + indicator"
[12:03] <asac> ;)
[12:03] <mpt> Where did I say that?
[12:04] <asac> well. thats what i understood. if you didnt say that then i disagree
[12:04] <asac> getting a notification when on download finished is imporant
[12:04] <asac> popping up dialogs cant be the answer for that
[12:04] <asac> getting a notification without a way to also open those download folders with new content is worse, yes.
[12:08] <mpt> So, in order of preference (from my POV):
[12:08] <asac> personally i want to get notified when downloads finished
[12:08] <mpt> 1. have Downloads window request attention (good)
[12:08] <asac> k
[12:08] <mpt> 2. nothing (adequate)
[12:08] <mpt> 3. notification bubble (bad)
[12:08] <mpt> 4. fallback alert box (terrible)
[12:10] <asac> how can nothing be better than notification?
[12:11] <mpt> what?
[12:11] <mpt> You mean, how can it be better than a fallback alert box?
[12:12] <asac> no why is 2 better than 3 (or 3 worse than 2)
[12:12] <mpt> oh, right
[12:12] <asac> i want to be notified when download finished
[12:12] <asac> whether i can click on it or not is just secondary
[12:12] <mpt> Because a notification bubble shows you that the download has finished but does not let you respond, which would be frustrating.
[12:13] <asac> combined with making a single place on the desktop where you can access finished downloads (read: indicator) i would say that 3 is even better than 1
[12:14] <mpt> Maybe so, but I'm 90% sure there won't be such a menu, because it's not a common enough case
[12:14] <asac> preferring 2 over three really sounds like sticking your head in the ground because we couldn't get 1 :)
[12:15] <mpt> Not at all, there are quite a few browsers that do #2, even including previous versions of Firefox.
[12:15] <asac> mpt: the menu would only show if there are finished downloads.
[12:17] <mpt> Other examples include Safari, IE/Mac, and Opera.
[12:18] <asac> mpt: so as it stands now if we don't suggest anything different from 1. we will get either 4 or the old XUL notifications
[12:19] <mpt> asac, ok, so the XUL ones are about at the same level as #2
[12:19] <asac> mpt: yeah. but i wouldnt bet on it
[12:20] <asac> we might really end up that firefox starts doing 4
[12:21] <asac> also i think that downloading is almost as a similar important use case as messaging
[12:21] <asac> i know a bunch of users that download all the time, but never touched any IM client
[12:21] <asac> and frequently they have issues to find the download they just did
[12:22] <mpt> So, I'm sorry that you're stuck in the middle of this
[12:23] <mpt> But really, you're complaining to the wrong person
[12:23] <mpt> We've offered one recommended behavior, and two acceptable alternatives
[12:23] <asac> mpt: ok. who is the right one to talk about this then ;)?
[12:24] <mpt> If Mozilla doesn't like any three of those and they want a nasty experience on Ubuntu, that reflects poorly on them.
[12:27] <mpt> I'll write up the three in more detail on the wiki page
[12:27] <asac> thanks.
[12:28] <asac> fwiw, i think its unlikely we will get 4. its just discussed. in the end we will stick with ugly XUL notifications forever ... i am currently fighting to get the native actions at least in toolkit supported in a way that wont lead to 4
[12:28] <asac> native notifications
[12:28] <asac> because we need them for tbird later
[12:28] <asac> together with indicator support
[12:30] <asac> mpt: since it always pops-up it would make sense to also tell why our approach is better than growl for instance
[12:30] <asac> they always say thats how it should be done properly
[12:30] <mpt> asac, sorry, since what always pops up?
[12:30] <asac> i have no arguments because i have absolutely no idea how growl feels
[12:31] <asac> mpt: growl is always raised (pops-up) in discussions
[12:31] <asac> as an example how to do it right
[12:31] <mpt> oh, I see
[12:32] <mpt> Growl causes mis-clicking that Notify OSD avoids.
[12:33] <mpt> I.e. a Growl bubble can appear possibly on top of where you're about to click on another window.
[12:33] <mpt> and if you click the bubble, it does something else (e.g. opens a window).
[12:33] <asac> mpt: can you write that somewhere down?
[12:34] <asac> or even capture a video that shows the problem?
[12:34] <asac> did you tell that to mconnor?
[12:34] <mpt> I did tell him
[12:35] <mpt> he thinks it's a worthwhile tradeoff
[12:35] <mpt> https://wiki.ubuntu.com/NotifyOSD?action=diff&rev2=141&rev1=140
[12:36] <mpt> asac, our rationale for non-clickability is at <https://wiki.ubuntu.com/NotificationDevelopmentGuidelines#Avoiding%20actions>
[12:36] <mpt> I'll add a mention of Growl there
[12:37] <asac> ok
[12:37] <asac> mpt: one thing left you didnt answer: why do you consider downloads a less common use-case than messages?
[12:40] <seb128> why do you need to be notified about downloads at all?
[12:41] <seb128> you are not notified about local copies
[12:42] <mpt> asac, well, I don't have statistics on it, but I'm fairly sure that most people receive e-mail + IMs (even if they don't use IM at all) more often than they download stuff
[12:44] <asac> most users use web mail
[12:44] <asac> desktop email is a dying thing and most likely only used by power-users
[12:44] <mpt> seb128, that's a good point, though I guess it's a bit easier to resume a local move/copy after hibernation than it is to resume a download
[12:44] <seb128> mpt: download should inhibit hibernation then?
[12:45] <asac> seb128: downloads take longer and copying files has its own progress dialog open
[12:45] <asac> that you dont close
[12:45] <asac> while its copying
[12:45] <seb128> asac: firefox doesn't have a download indicator?
[12:45] <seb128> I should try something else than epiphany every now and then ;-)
[12:46] <asac> seb128: i am not sure about default behaviour, but i definitly dont have the download window open during downloads
[12:46] <asac> seb128: also think about transmission
[12:46] <asac> seb128: takes long to download a huge file and its nice to be notified that its finished
[12:46] <seb128> right
[12:46] <asac> unifying how users can access finished downloads in an indicator sounds right to me
[12:46] <seb128> I think bubble are nice for those
[12:46] <seb128> I'm not sure I agree with " 1. have Downloads window request attention (good)"
[12:47] <asac> seb128: but mpt disagrees ;) ... he says that bubble is worse than nothing
[12:47] <seb128> but I hate things claiming for attention when they are not urgent
[12:47] <asac> me too
[12:47] <seb128> and I hate having dialogs opening on my screen why I don't do the action
[12:48] <seb128> bubbles seem really adapted to notify of "your download is done" now in a non intrusive way
[12:48] <asac> the more i think about it the more i think that we should have a common place on the desktop where users can click on to open finished downloads (or at least folders where te finished downloads are)
[12:48] <seb128> don't we download to the desktop by default?
[12:48] <asac> seb128: desktop is usually hidden
[12:48] <asac> seb128: by windows
[12:48] <seb128> well it's your background, it's not hard to access
[12:48] <asac> its the wrong place imo
[12:48] <seb128> it's in the places menu too
[12:49] <seb128> and you have this "show desktop" applet
[12:49] <asac> seb128: well. then there should be indication in the places menui ;)
[12:49] <asac> thats ok for me too
[12:49] <mpt> That would be nifty
[12:49] <asac> cool mpt adapts a new idea ;)
[12:49] <mpt> a Downloads place that glows or something when a download completes
[12:49] <asac> ok. lets make the places menu the downoad indiateor
[12:49] <asac> ;)
[12:49] <seb128> asac: microsoft users seem to have no difficulty to find their desktop background and abuse it a lot to me
[12:50] <asac> seb128: oh sure they have
[12:50] <asac> seb128: they have no problems to change the background
[12:50] <asac> but they have problems to see that a new file was jsut added there
[12:50] <seb128> that's because they have too much crap there ;-)
[12:51] <asac> lol
[12:51] <seb128> you would have the same issue in a download directory after some zillions downloads if you don't clean
[12:51] <asac> right
[12:51] <seb128> or you need what GNOME is discussing, a journal browsing sort of thing
[12:51] <asac> yeah. still the desktop is the wrong place to access files
[12:51] <asac> you have to close all windows and so on
[12:51] <seb128> ie have files not listed by directories but by recent changes, new documentes, etc
[12:51] <asac> accessing that through places is good
[12:51] <asac> even if its just the Desktop folder
[12:52] <seb128> I don't agree with that
[12:52] <seb128> just switch to an empty workspace or click on the show desktop button
[12:52] <asac> i dont see my mother doing that without getting personal training
[12:52] <seb128> well, note that we decided to download to desktop by default
[12:52] <mpt> hey andreasn, are you going to the Desktop Summit?
[12:52] <seb128> upstream has a Download directory in xdg-user-dirs
[12:52] <asac> seb128: right because we had not better way
[12:53] <seb128> and it's in the places menu
[12:53] <seb128> translated
[12:53] <andreasn> mpt, then one in the warm place?
[12:53] <andreasn> mpt, yes
[12:53] <seb128> asac: well, upstream has desktop/download by default...
[12:53] <mpt> andreasn, neat, are you giving a talk at all?
[12:53] <asac> seb128: dont get me wrong: i dont say that desktop is the wrong place in general
[12:53] <andreasn> mpt, and possibly UDS, I'll see if I get some cash over
[12:53] <seb128> asac: and they have a download bookmark
[12:54] <seb128> asac: we just decided to overwritte than by using the desktop for downloads
[12:54] <asac> seb128: yeah. personally i think we can either use desktop or download if we indicate finished downloads in places
[12:54] <andreasn> mpt, probably not, I think the submission for talks has passed already. Not sure what I would talk about.
[12:54] <mpt> andreasn, I realized too late that it would be a good time to talk about reducing the use of icons in Gnome
[12:54] <mpt> I saw you mentioned that in the Gnome roadmap
[12:54] <asac> seb128: sure. my suggestion is to indicate downloads in places menu somehow and if that works well we can switch to Downloads folder ... but for now we can keep Desktop as its in places too
[12:55] <andreasn> mpt, maybe it can be done as a lightning talk, but yeah, that
[12:55] <seb128> asac: alright, we just need a good idea to indicate it then ;-)
[12:55] <asac> seb128: yeah. but thats just ground work ;)
[12:55] <andreasn> 's defenitly a good goal, and we need to figure out a good way to motivate and communicate it
[12:55] <asac> for the monkeys ;)
[12:55] <seb128> bah, dropping icons, no everything is as ugly and hard to use than the fusa menu applet ;-)
[12:56] <seb128> no -> so
[12:56] <seb128> pedro__: olla
[12:57] <pedro__> salut seb128
[12:58] <andreasn> is it? I haven't used it much, I'm just attacking it from a visual design perspective and thinks it looks cleaner without the blobs of color
[12:59] <andreasn> and part of our problem right now is if a menu item gets a icon or not depend fully on if someone got around drawing it or not, and that feels a bit odd
[12:59] <seb128> pitti: I'm not convinced that bug #349948 is a gtk issue, I've seen no such issues in other dialogs
[12:59] <andreasn> garrett managed to fill all the menu items on his old industrial firefox theme though. A quite interesting experience
[13:00] <pitti> seb128: hm, it works for most labels, just not for some with particular lengths
[13:00] <pitti> seb128: but I don't mind if you reassign it back
[13:00] <seb128> andreasn: icons are easy to spot, parsing text is taking a while
[13:00] <seb128> pitti: no, it just seems weird to me, we usually have the opposite bug, it wraps too easily
[13:01] <pitti> I know :/
[13:01] <seb128> pitti: ie doesn't adapt to the dialog changes and looks ugly because the lines are wrapped too much
[13:01] <pitti> (bug 20096)
[13:01] <seb128> right
[13:02] <seb128> would be nice to get a testcase for #349948
[13:02] <seb128> andreasn: I pick the wrong items in fusa often, there is 7-8 entries without icons there, it's just too easy to be wrong from 1 line with muscle memory in the menu when you use it
[13:03] <seb128> andreasn: icons makes much easier to pick the right one
[13:09] <maxb> What happens when you unlock (by entering your password) the GNOME screenlock? Something incredibly CPU intensive seems to be occurring on Jaunty
[13:10] <chrisccoulson> does anyone know off the top of their head if g_unlink blocks until the file is removed?
[13:12] <james_w> chrisccoulson: by removed to you mean considered removed by the OS, or gone from disk?
[13:12] <james_w> I doubt very much it does the latter, but it may do the former
[13:15] <seb128> pitti: ok, I've looked at this gtk bug
[13:15] <seb128> pitti: you have code to "prevent window from being auto-resized in finish_unmount_flush_window()"
[13:16] <seb128> pitti: the issue seems that the "is now safe" label can be longer than the first one
[13:16] <pitti> right, since that looks ugly
[13:16] <pitti> can I tell the label "please go rewrap yourself"?
[13:16] <seb128> pitti: and since you prevent the dialog change, you get what you asked for
[13:17] <seb128> pitti: no, I think we are back to #20096 then
[13:17] <pitti> well, no, I want the label to wrap in its current bounds
[13:17] <pitti> and indeed it does that most of the time
[13:17] <pitti> just not with some drive labels/translations, i. e. with particular strings
[13:18] <seb128> hum ok
[13:18] <seb128> I will try to get a testcase
[13:19] <chrisccoulson> james_w - considered removed by the OS. i was just wondering at which point the function returns. say, if i call g_unlink on a file that is 2GB, is it likely to take some time to return?
[13:19] <chrisccoulson> if it takes some time, then it might explain a tracker bug i'm looking at
[13:20] <james_w> chrisccoulson: as I understand it unlink removes the pointer from the directory to the file, so it shouldn't depend on the size of the file
[13:20] <james_w> though there may be some walking the indirect blocks to mark then as uneeded
[13:21] <chrisccoulson> thanks. i might have to do some more debugging later:)
[13:22] <seb128> pitti: are you sure you have cases where the "is safe now" actually wraps?
[13:23] <james_w> chrisccoulson: what's the bug?
[13:24] <seb128> pitti: I've added a small testcase to the bug, which is basically a copy of the buggy function
[13:24] <pitti> seb128: yes, of course
[13:24] <chrisccoulson> james_w - when you force a reindex (or a reindex is forced because the index became corrupt), the existing indexes aren't removed properly on shutdown
[13:24] <pitti> seb128: thank you
[13:24] <chrisccoulson> james_w - the indexes are all g_unlink'd
[13:24] <seb128> bratsche: hello
[13:25] <BugMaN> hy seb128! :)
[13:25] <seb128> bratsche: do you think you could have a look to bug #349948 and tell us if you see something wrong there?
[13:25] <bratsche> seb128: Hey
[13:25] <bratsche> Sure.
[13:25] <seb128> hi BugMaN
[13:25] <chrisccoulson> but i noticed in the tracker code that if it doesn't shutdown within 500ms of the shutdown being requested, it just exits immediately with an error. i was wondering if it might actually be exiting before all the indexes were removed
[13:26] <chrisccoulson> james_w - i can't test that though until i get home from work
[13:28] <bratsche> seb128: Yeah I see it with your example.c.  Give me a few mins to finish something up and I'll look into this.
[13:28] <seb128> bratsche: thanks
[13:31] <james_w> chrisccoulson: ah, I was wrong
[13:31] <james_w> chrisccoulson: unlinking a 100M file with g_unlink takes over 2 seconds here
[13:32] <chrisccoulson> james_w - thanks. so that confirms my theory then - trackerd probably exits long before the indexes are deleted
[13:32] <chrisccoulson> which might explain why reindexing doesn't resolve index corruption
[13:32] <james_w> the new indexes and the old indexes are in the same directory?
[13:33] <james_w> and just being present in that directory makes them considered valid?
[13:34] <chrisccoulson> james_w - i think so. i don't know the tracker code all that well. i just have to keep reading it to try and fix bugs that people are seeing
[13:34] <chrisccoulson> when you force a reindex, the daemon shuts down, but should remove the old indexes on shutdown
[13:34] <chrisccoulson> then when it restarts, it recreates them. that doesn't seem to be what actually happens though
[13:35] <james_w> ah
[13:35] <chrisccoulson> j\ames_w - fyi - bug 361205
[13:35] <james_w> perhaps it should just mark them all invalid somehow on shutdown, then remove any invalid ones on startup
[13:37] <chrisccoulson> perhaps, but i'm not sure how to do that. the intention upstream is that they get deleted on shutdown, but that bit seems to be broken
[13:40] <james_w> yeah, but they also seem to intend the daemon to shutdown quickly, which seems to be incompatible
[13:41] <james_w> deleting on startup allows you to do potentially long-running operation when you are presumably going to be running for a while
[13:43] <james_w> it's quite worrying that it seems to corrupt its index so often, or is there something I am missing?
[13:44] <james_w> ah, they are replacing qdbm
[13:44] <james_w> still worrying though
[13:44] <chrisccoulson> james_w - yeah, upstream suspect a lot of these issues are qdbm related, and they think they will go away as it is replaced for 0.7
[13:45] <chrisccoulson> but that's never going to happen for jaunty. the corruption issues occur more frequently for some people than others. i haven't seen the issue for ages now
[13:46] <chrisccoulson> in the meantime, we just have to live with the workaround, which is to detect the corruption and then do a reindex
[14:19] <bratsche> seb128: I posted a fixed example.c to that bug.
[14:21] <seb128> bratsche: looking
[14:21] <seb128> bratsche: thanks, you rock
[14:21] <seb128> pitti: ^ reassigning the gnome-mount bug your way
[14:21] <pitti> seb128: thanks
[14:22] <seb128> pitti: thanks to bratsche for fixing it ;-)
[14:22] <bratsche> Sure, np :)
[14:22]  * pitti hugs bratsche
[14:48] <mvo> hey glatzor - do you have a opinion about my workaround for #257739 ?
[14:50] <seb128> bratsche: I'm not sure how busy you are, feel free to ignore me, but have you already read bugs about url being opened twice from about boxes in GTK or GNOME applications?
[14:50] <glatzor> hello mvo, sorry but I am not a kernel developer :)
[14:50] <glatzor> mvo, are you sure about the bug number=
[14:50] <glatzor> ?
[14:50] <mvo> not anymore ;)
[14:51] <seb128> bratsche: it's weird, that happens with most applications, ie gedit but not in gtk-demo, I don't see anything specially those do though
[14:51] <seb128> hi glatzor
[14:51] <glatzor> hello seb128 !
[14:51] <mvo> https://bugs.edge.launchpad.net/ubuntu/+source/packagekit/+bug/257639
[14:51] <mvo> glatzor: ^-- this one :)
[14:53] <Ampelbein> seb128, bratsche bug 334378
[14:53] <seb128> Ampelbein: thanks but I'm triaging gtk bugs that's why I ask about it ;-)
[14:54] <Ampelbein> oh, ok
[14:54] <seb128> Ampelbein: I'm not convinced that it's a gtk bug though since gtk-demo doesn't have it so I was not sure where to send it to GNOME
[14:55]  * bratsche pulls down the transmission source to take a peek
[14:56] <bratsche> Yeah, I just reproduced it in transmission.
[14:57] <seb128> bratsche: well, you can try in gedit or most desktop applications
[14:57] <seb128> they just use gtk_about though
[14:57] <seb128> it's a bit puzzling
[14:57] <bratsche> Yeah, weird.
[14:59] <seb128> ok, it's a gtk bug
[14:59] <seb128> or at least a gtk behaviour change
[15:00] <bratsche> Did you find a difference between gtk-demo and the other apps?
[15:00] <seb128> ld preloading the intrepid libgtk-x11 makes it work correctly
[15:00] <bratsche> Interesting.
[15:00] <tadeu_> guys, any known problem about upgrading 8.10 to 9.04 ?
[15:00] <seb128> tadeu_: hi, user questions are better placed on #ubuntu or #ubuntu+1
[15:00] <bratsche> seb128: I have a call now, but after that I can try to look into this some more probably.
[15:01] <tadeu_> seb128, ok, sorry
[15:01] <seb128> bratsche: ok thanks, no hurry I will try to figure what gtk-demo does differently
[15:01] <bratsche> Cool, thanks.
[15:01] <seb128> tadeu_: but no, no major known issue apparently
[15:22] <seb128> bratsche: ok, I figured what is the difference
[15:23] <bratsche> What is it?
[15:24] <seb128>   gtk_about_dialog_set_url_hook (activate_url, NULL, NULL);
[15:24] <seb128> activate_url does a g_print in the gtk case
[15:24] <seb128> but gtk calls the webbrowser anyway
[15:24] <bratsche> If you remove that hook then it gets called twice?
[15:24] <bratsche> Ah, I see.
[15:24] <seb128> those applications do a gtk_show_uri
[15:24] <seb128> the documentation doesn't seem clear to me
[15:25] <seb128> why do you need a gtk_about_dialog_set_url_hook() call if gtk hooks it by default to gtk_show_uri
[15:25] <seb128> and why if you set a custom handler you still get the gtk one?
[15:25] <seb128> is that supposed to be this way or a bug?
[15:25] <bratsche> This may have changed.  I'll poke around in gtk+ history after this call.
[15:25] <seb128> thanks
[15:25] <seb128> mclasen might know
[15:26] <seb128> gnome bug #566391
[15:26] <seb128> hum, no, that seems a different bug
[15:27] <mclasen> seb128: sounds like a bug
[15:27] <mclasen> two handlers at the same time, I mean
[15:27] <seb128> mclasen: ok thanks, I will open that on bugzilla then
[15:27] <mclasen> chpe recently added a default handler, so that may have messed things up
[15:28] <seb128> right, it seems that the gtk handler is called which opens a browser and those applications do that manually too
[15:28] <seb128> so you get 2 browser started
[15:32] <james_w> http://git.gnome.org/cgit/gtk+/commit/?id=405955749103dcfdf582b6ae4f053c66837a6281
[15:32] <james_w> +If you want provide your own hooks overriding the default ones, it is important
[15:32] <james_w> +to do so before setting the website and email URL properties, like this:
[15:33] <seb128> james_w: hum right, still confusing to have both hooks used
[15:33] <james_w> indeed
[15:34] <seb128> I've opened gnome bug #579838
[15:35] <seb128> james_w: the ubuntu bug has been opened 2 month before this change so that seems not due to it
[15:35] <james_w> ah, ok
[15:44] <glatzor> mvo, actually post update hook of packagekit just results in emitting an "update-changed" signal and invalidating the internal updates cache of the daemon (not the backend)
[15:44] <mvo> glatzor: does that not reopen the apt cache immediately too?
[15:47] <glatzor> mvo, depends on the running client apps. gpk-update-icon will queue a get-updates transaction when it recieves the "updates-changed" signal of packagekit
[15:47] <glatzor> so actually you should apply your patch to python-apt
[15:48] <mvo> glatzor: well, its pretty clear that the patch is just a woraround until the real problem is isolted (I suspect its in libapt itself even)
[15:49] <glatzor> mvo, but we will only see a slow down of the cache opening in the case of a lock?
[15:50] <mvo> glatzor: I think its a race, both synaptic/update-manager and PK try to open it at about the same time
[15:50] <mvo> glatzor: my theory is that PK is slightly faster and has half-rebuild the binary cache when synpatic opens it and notices that its "broken" (because its not fully generated yet)
[15:51] <mvo> glatzor: obvisouly the bug is in libapt then, but the workaround would still work because the opening would be at different times
[16:20]  * kenvandine_wk heads out for a bit of a long lunch... back in 1.5 hours :)
[16:37] <proppy> seb128: giving a try to bug #334378 http://pastebin.com/f4467e3aa
[16:38] <seb128> proppy: cool
[16:38] <proppy> seb128: recompiling gtk+ package, hope it is not duplicated work
[16:39] <seb128> not with me at least
[16:50] <asac> seb128: ffox source package is firefox-3.0 ;) firefox is the old one
[16:50] <seb128> asac: ok
[16:50] <seb128> asac: I'm surprised that you read bug emails ;-)
[16:50] <asac> seb128: hell i am reading 24/7 atm
[16:51] <asac> ;)
[16:51] <asac> my body already shivers
[16:56]  * pitti has 'nuff of them for today, too
[16:58] <proppy> seb128: rebuilt  libgtk2.0-0_2.16.1-0ubuntu3_i386.deb package and tested with gedit that it fixes the pb.
[16:59] <proppy> attached the diff to bug 334378
[16:59] <proppy> let me know if it needs more love :)
[16:59] <asac> is g_hash_table_foreach a macro or something?
[17:00] <asac> seems not. odd that it gets optimized away in a backtrace
[17:00] <proppy> maybe I should also attach the patch to the upstream (gnome) bug report ?
[17:00] <mvo> asac: I guess if the compiler knows its a empty set or something beforehand (or a single invocation)
[17:00] <seb128> proppy: could you add the diff upstream too?
[17:01] <asac> mvo: http://launchpadlibrarian.net/25841787/gdb-nm-connection-editor.txt
[17:01] <proppy> seb128: not the debdiff but the quilt patch, right ?
[17:01] <seb128> proppy: I doubt that will be sru-ed or worth an early karmic upload, having it in the next tarball will do
[17:01] <asac> look at #4
[17:01] <seb128> proppy: yes
[17:01] <asac> thats hash_table_foreach
[17:01] <seb128> gdb and -O2 builds suck
[17:02] <asac> yeah
[17:02] <mvo> asac: hrm, inlined
[17:02] <asac> mvo: hash_table_for_each is not a inline function
[17:02] <asac> i looked in the header
[17:03] <mvo> asac: the compiler probably thought differently in O2 :)
[17:03] <asac> inlining binary stuff from a .so?
[17:03] <asac> that would be neat ;)
[17:03] <asac> and its definitly _foreach because its an break because of
[17:04] <asac> GLib-CRITICAL **: g_hash_table_foreach: assertion `hash_table != NULL' failed
[17:05] <asac> anyway. i gues its just O2
[17:07] <proppy> seb128: http://bugzilla.gnome.org/show_bug.cgi?id=579838 updated
[17:07] <seb128> proppy: thanks
[17:08] <proppy> woot this "Matthias Clasen" is lighting fast
[17:10] <proppy> oops he is here ( mclasen )
[17:17] <asac> so now all gnome has moved to git ... is there any bzr-git in sight?
[17:17] <asac> guess better ask in #bzr
[17:19] <calc> git is nice once you get used to it
[17:19] <calc> works a bit differently the than other SCMs i've used though
[17:21] <asac> calc: i know how to use git
[17:22] <asac> calc: just hoped i could use my bzr-buildpackage auto export feature still somehow
[17:22] <asac> for which i need a bzr upstream branch
[17:28] <calc> asac: ah
[17:29] <calc> asac: there is a git-buildpackage but i'm not sure if it would work in your setup
[17:29] <asac> that would mean migrating the packaging branches to git too
[17:29] <calc> oh :\
[18:17] <calc> rickspencer3: i should have an OOo 3.1.0rc2 build ready for when the karmic archive opens mid next week
[18:17] <calc> it comes out this friday then karmic opens somewhere between apr 27-30 most likely
[18:18] <rickspencer3> calc: cool
[18:18] <rickspencer3> what ppa is it in now?
[18:20] <calc> its not available yet due to some issues with the orig tarball i am working from
[18:20] <calc> it exploded in size due to a bug
[18:20] <calc> eg the debian orig.tar.gz is ~ 700MB currently :\
[18:20] <calc> i suppose i could go ahead and upload it anyway and just request LP to give me a couple extra GB of space in the ppa, heh
[18:21] <calc> it should be about half that size
[18:23] <calc> hmm actually i might have enough room currently, i'll have to see how it goes
[18:29] <kenvandine_wk> rickspencer3: the i965 wiki page... model means system model or video card model?
[18:32] <rickspencer3> kenvandine_wk: output of lspci -vvnn | grep -A2 "VGA "
[18:32] <kenvandine_wk> great
[18:32] <kenvandine_wk> which part of that?
[18:33] <rickspencer3> dunno
[18:33] <rickspencer3> that's what bryce asked for, so I guess all of it
[18:33] <rickspencer3> bryce? ^^
[18:34] <kenvandine_wk> that is to much to put in the table :)
[18:35] <lauris> hi
[18:35] <kenvandine_wk> [8086:29a2] (rev 02)
[18:35] <kenvandine_wk> i assume that
[18:35] <lauris> is there some kind of ubuntu archive with 7.10 packages available online ?
[18:37] <pitti> good night everyone, Taekwondo time
[18:38] <kenvandine_wk> good night pitti
[18:38] <kenvandine_wk> pitti: no web surfing during taekwondo :)
[18:40] <lauris> found it.
[21:43] <seb128> re
[21:44] <seb128> asac: gwibber is not really nice for beginner ;-)
[22:31] <asac> seb128: why?
[22:31] <asac> ;)
[22:32] <seb128> asac: I think I'm just too stupid to use it
[22:32] <seb128> I use the "create account", selected twitter, entered an username and password and I just get an error displayed
[22:32] <seb128> nothing in the UI, I'm not sure what is supposed to happen
[22:32] <asac> seb128: it doesnt have many features ;) ... just sending dents/tweets and reading
[22:33] <seb128> I though it was supposed to display something
[22:33] <seb128> similar to a planet with blog post or something ;-)
[22:33] <asac> seb128: if you are not subscribed anywhere, you dont see anything except your own tweet
[22:33] <seb128> I tried to do an ubuntu query which added a tab but nothing else
[22:33] <asac> seb128: try to follow me (asacasa)
[22:33] <asac> hmm
[22:33] <seb128> "HTTPError: HTTP Error 401: Unauthorized" I get too
[22:34] <seb128> is "create account" really create?
[22:34] <asac> seb128: is that latest gwibber?
[22:34] <asac> seb128: no.
[22:34] <seb128> or is it "add account" rather?
[22:34] <asac> seb128: its add account
[22:34] <asac> yeah
[22:34] <seb128> grrrr
[22:34] <seb128> sucky software
[22:34] <asac> seb128: go to http://identi.ca and setup an account ;)
[22:34] <asac> seb128: well. its new
[22:34] <seb128> why do they call create account something which is adding an existing account
[22:34] <asac> most users have accounts ;)
[22:34] <asac> thats a bug
[22:35] <seb128> what protocol do you recommend as interesting?
[22:35] <seb128> ie where should I read what users say about ubuntu?
[22:35] <seb128> identica? twitter?
[22:35] <seb128> I've no clue about all those new fancy websites
[22:37]  * seb128 kicks launchpad
[22:37] <seb128> when you enter a wrong component or something and go back it deletes what you typed
[22:38] <seb128> or is that my webbrowser?
[22:41] <dobey> seb128: there's an ubuntu group on identi.ca you can watch, that's pretty active. though it seems to be mostly people asking questions about various hardware support and features
[22:42] <jcastro> http://identi.ca/group/ubuntu
[22:42] <jcastro> there's an rss feed there seb128
[22:42] <seb128> why do I need an account to read those things?
[22:43] <jcastro> you don't on the web
[22:43] <seb128> in gwibber I mean
[22:43] <jcastro> but with a client app like gwibber you need to set it up that way
[22:43] <jcastro> there's like a million ways gwibber can improve with that stuff
[22:44] <dobey> doesn't gwibber do rss now too?
[22:44] <jcastro> yeah
[22:45] <dobey> so you can just subscribe to the rss feed in gwibber
[22:45] <dobey> instead of setting up an account and going through the identi.ca api to get it
[22:46] <jcastro> seb128: just sign up for an account so bugabundo can message you directly
[22:46]  * jcastro runs
[22:46] <dobey> haha
[22:46] <james_w> heh
[22:46] <seb128> jcastro: be careful, I might break banshee by mistake in karmic and be too busy to fix it later
[22:47] <jcastro> you can't stop the awesome
[22:48] <seb128> jcastro: I can stop the troll about CD space win though
[22:48] <seb128> jcastro: those blog post just made me have a look and see than banshee has NO USER DOCUMENTATION
[22:49] <seb128> jcastro: which is why it wins some megabytes over rhythmbox which has a manual translated in 11 languages
[22:49] <jcastro> wow
[22:49] <jcastro> I never noticed that for years until just now
[22:50] <seb128> banshee hates users apparently or something ;-)
[22:50] <jcastro> no, just freedom remember
[22:52] <seb128> jcastro: joke aside I was surprised too, but that sort of defeat the CD space argument some people have raised for banshee
[22:53] <asac> seb128: identi.ca
[22:53] <asac> seb128: you should read and write ;)
[22:54] <seb128> asac: let's see, I will start by reading, but that seems a high traffic media
[22:54] <seb128> small posts but a lot of those
[22:55] <asac> seb128: you can keep the group you follow small. also its not a problem if you miss dents. important stuff will be repeated
[22:55] <jcastro> seb128: think of yourself as a producer instead, for things like "Can someone confirm this bug?" or "looking for volunteers to test foo"
[22:55] <seb128> asac: I've been reading the backlog for the ubuntu group and it's not small ;-)
[22:56] <seb128> jcastro: I've #ubuntu-desktop for those ;-)
[22:56] <seb128> but good point
[22:56] <seb128> there might be other users which are not on IRC there ;-)
[22:56] <jcastro> it's just another medium, right
[23:06] <seb128> enough for today, see you tomorrow
[23:06] <seb128> good night eveybody
[23:06] <seb128> everybody