[00:00] <xnox> Chipaca: please use /etc/machine-id, anything else is broken.
[00:00] <slangasek> xnox: nack
[00:00] <slangasek> /etc/machine-id is *also* broken
[00:00] <slangasek> it's *the same on every device*
[00:00] <Chipaca> xnox: for what?
[00:00] <xnox> slangasek: WHAT?!
[00:00] <slangasek> you're jumping the gun slightly :P
[00:00] <slangasek> xnox: it's in the base image, how would it have been made unique?
[00:00] <xnox> slangasek: /etc/machine-id must not be the same =
[00:00] <slangasek> that's nice ;)
[00:01] <xnox> Chipaca: push & unique identification.....
[00:01] <xnox> slangasek: let me check livefs image to see if all /etc/machine-ids are the same on all ubuntus....
[00:01] <xnox> (ditto dbus ids)
[00:02] <slangasek> dbus ID is handled
[00:02] <slangasek> /etc/machine-id is a neologism
[00:02] <xnox> slangasek: /var/lib/dbus/machine-id should be a symlink to /etc/machine-id in the new world order....
[00:02] <slangasek> all these opinions
[00:02] <slangasek> fwiw mine are in sync, but it's not a symlink
[00:03] <slangasek> and I don't see what creates /etc/machine-id
[00:03] <xnox> slangasek: ok. i have one task to fix, i should focus on that =))))
[00:04] <xnox> *sigh* /etc/machine-id is on the livefs image....
[00:04] <slangasek> ok.  what creates it?
[00:04] <xnox> slangasek: looking at the source code systemd-ish something does it.
[00:05] <slangasek> just because systemd upstream has defined this as an interface for a unique ID in no way means we've started supporting it as such
[00:05] <xnox> systemd-machine-id-setup
[00:05] <slangasek> we still have /var/lib/dbus/machine-id as uniqueu
[00:06] <xnox> it uses dbus/machine-id as seed, if there was one.
[00:11] <slangasek> xnox: so in the long term, the installer / live-builder should be updated to handle /etc/machine-id specially, just as /var/lib/dbus/machine-id is currently handled.  In the near term, /etc/machine-id is an irrelevant and unsupported interface. :)
[00:11] <xnox> slangasek: bug against cdimage project?
[00:12] <slangasek> xnox: I still have no idea what is meant to be creating /etc/machine-id, 'systemd-machine-id-setup' isn't part of either the boot scripts or the maintainer scripts
[00:12] <slangasek> xnox: yes
[00:13] <xnox> slangasek: installer is suppose to call systemd-machine-id-setup, otherwise, i guess first caller triggers it's creation....
[00:13] <slangasek> what's the "first caller"?
[00:14] <slangasek> do you mean the first thing that queries the machine ID?
[00:14] <xnox> systemd-firstboot.service , but of course /me is friday trolling
[00:14] <xnox> i'm guessing logind session.
[00:15] <xnox> or same as dbus-uuigen. I'll trace that later. No clue yet, where/how it ends up generated on ubuntu.
[00:17] <juliank> I'd recommend to ask systemd guys or look at more recent systemd code. Given all that booting without /etc stuff they're doing, they probably have newer versions generate that if it is missing
[00:18] <juliank> Might make sense to copy that then
[00:23] <hallyn> xnox: uh oh, i notice that the 0.28-3ubuntu1 cgmanager upstart job has the post-start "initctl ... || true" in exec instead of inside script.  Needs an update?
[00:23] <xnox> hallyn: no, why?
[00:23] <hallyn> oh, i thought there was talk last week of || true not working in a exec
[00:24] <hallyn> if not, excellent
[00:24] <xnox> hallyn: exec -> single line; script / end-script -> multi-line
[00:24] <xnox> hallyn: if upstart spots any special / shell characters in the exec line it runs it through a shell.
[00:25] <xnox> hallyn: i'd like to see it to believe it =) we have extensive tests to make sure e.g. "exec daemond --bar $ARGS" ends up called through a shell.
[00:25] <xnox> to do all the shell variable expansions and magic.
[00:27] <hallyn> xnox: right, i thought in particular "exec somethingorother || true" was what wasn't going to work.  happy to learn i'm wrong.  (had not tested)
[00:29] <calebjosue> i was recommended to join this channel for purposes of knowing where to start with open source projects
[00:32] <xnox> hallyn: hm.... I'm scratching my head now.
[00:32] <xnox> slangasek: hallyn: This fails to start $ echo "pre-start exec false || true" > ~/.config/upstart/hallyn.conf; start hallyn
[00:32] <xnox> but it should.....
[00:45] <slangasek> xnox: eh? why should that successfully start instead of being a parse error?
[00:45] <slangasek> xnox: 'pre-start exec false || true' says "exec() false with the arguments '||' and 'true'"
[00:46] <slangasek> so technically not a parse error, but certainly returns non-zero and should fail
[00:46] <xnox> slangasek: "Any special  characters, e.g. quotes or `$' specified will result in the entire command being passed to a shell for expansion." imho || is special
[00:47] <slangasek> xnox: upstart does its own shell parsing of variables on the exec commandline; I don't see any reason '||' should be regarded as special
[00:48] <xnox> hallyn: i am wrong, and cgmanager jobs need fixing.
[00:58] <xnox> slangasek: about whoopsie id being different for non-root users -> Bug #1351519
[00:58] <ubottu> bug 1351519 in whoopsie (Ubuntu) "/sys/class/dmi/id/product_uuid is not world readable" [Undecided,New] https://launchpad.net/bugs/1351519
[00:59] <slangasek> xnox: ok; that's one reason why the generated id should be cached to the filesystem
[01:00] <xnox> slangasek: and then make whoopsie file recoverable errors upon itself when generated id doesn't match cached one?! =)
[01:00] <slangasek> ...
[01:00]  * xnox is still friday trolling
[01:00] <xnox> slangasek: e.g. tedg files recoverable errors against upstart, when something rather in url-dispatcher (tedg) can't read an sql database....
[01:00] <slangasek> yes, one wonders at your choice of leisure activities
[01:01] <xnox> slangasek: i'd rather tedg stop spaming us =)
[01:01] <slangasek> xnox: I've filed a bug against url-dispatcher for this
[01:01] <slangasek> bug #1350536
[01:01] <ubottu> bug 1350536 in url-dispatcher (Ubuntu) "url-dispatcher report_recoverable_problem() handler triggers reports filed against upstart" [Undecided,New] https://launchpad.net/bugs/1350536
[01:02] <xnox> slangasek: number? i'll fix it, cause i believe we shouldn't be generating errors on continues basis. All error reports must be exceptional, not a norm.
[01:02] <slangasek> well, my bug report was about the errors being misfiled
[01:02] <slangasek> which is separate from whether there's a bug in url-dispatcher /triggering/ the problem report
=== timrc is now known as timrc-afk
[01:45] <hallyn> xnox: ok, thx, i'll push a fix (but not right now, laptop overheating)
[01:47] <hallyn> xnox: slangasek: so how many upstartu sers do we think we have in debian?  should the upstart job fix for cgmanager go to debian or just to utopic?
[01:48] <slangasek> is there some reason to *not* fix it in Debian? to do otherwise means you get to maintain a delta
[01:48] <xnox> hallyn: all cgmanager updates should go to debain, and just sync to ubuntu.
[01:49] <xnox> (e.g. that's how a lot of core packages are maintained e.g. grub2 is synced from debian, all uploads go into debian)
[01:50] <hallyn> xnox: yeah pitti had made an ubuntu delta this morning, but i do think it can a go to debian
[01:51] <hallyn> i.e. it was a delta that was introduced while 0.28-3 was going into debian, and it failed ot make it into that package (i didn't track them all sufficiently)
[01:52] <hallyn> unfortunately going through debian adds a delay
[01:53] <slangasek> hallyn: yes, but it's not something that should be a delta between the two distros over the long term
[01:54] <hallyn> slangasek: no, not at all - it's just a delta bc i failed to put it into 0.28-3
[05:14] <xnox> Folks please tell me:
[05:14] <xnox> $ adb shell cat /sys/class/android_usb/android0/iSerial
[05:14] <xnox> Need some sample data, to validate a hypothesis =)
=== desrt|guadec is now known as desrt
=== timrc-afk is now known as timrc
=== timrc-afk is now known as timrc
[19:19] <ScottK> zul: Please use build1 not ubuntu1 when you're doing no change rebuilds of packages that don't have an Ubuntu diff already.
[20:54] <Noskcaj> Could someone please work on porting ubuntu-system-settings, powerd, and indicator-power to upower 0.99 soon?
[20:56] <Noskcaj> Laney, Since you show up in the changelogs a bit do you know if anyone's working on ^
[21:08] <slangasek> Noskcaj: why is porting required at all?  Shouldn't upower be a stable interface already?
[21:12] <Noskcaj> slangasek, The new (late last year) release of upower drops the suspend API, the SONAME, and changes part of the dbus interface, as well as a few other things.
[21:12] <slangasek> "drops the suspend API" in favor of what?
[21:12] <Noskcaj> gnome, and soon xfce and kde, needs upower 0.99 to function
[21:13] <Noskcaj> slangasek, systemd/logind
[21:13] <slangasek> ok
[21:13] <Noskcaj> bug 1330037
[21:13] <ubottu> bug 1330037 in xfce4-settings (Ubuntu) "upower 0.99 transition" [Undecided,In progress] https://launchpad.net/bugs/1330037
[21:13] <slangasek> and do you know that powerd actually requires porting for any of these changes, vs. a straight rebuild?
[21:14] <slangasek> (ditto u-s-s and indicator-power)
[21:15] <Noskcaj> powerd failed to build last i tried, i'll rebuild those three with their current versions today
[21:15] <Noskcaj> (ditto u-s-s and indicator-power)
[21:15] <Noskcaj> crap
[21:15] <Noskcaj> https://launchpadlibrarian.net/177594528/buildlog_ubuntu-utopic-amd64.powerd_0.15%2B14.10.20140612-0ubuntu1ppa1_FAILEDTOBUILD.txt.gz
[21:20] <slangasek> hmm, ok then
[21:21] <slangasek> I'm guessing that for powerd porting you might want sforshee
[21:30] <Noskcaj> powerd is still failing  porting you
[21:31] <Noskcaj> https://launchpad.net/~noskcaj/+archive/ubuntu/upower/+build/6235759/+files/buildlog_ubuntu-utopic-amd64.powerd_0.16%2B14.10.20140707-0ubuntu1ppa1_FAILEDTOBUILD.txt.gz
[21:31] <Noskcaj> Why does hexchat copy anything i select :(
[21:36] <Noskcaj> indicator-power does build fine, but it probable needs some testing, as it does depend on upower
[21:37]  * slangasek nods
[21:38] <Noskcaj> u-s-s https://launchpad.net/~noskcaj/+archive/ubuntu/upower/+build/6235765/+files/buildlog_ubuntu-utopic-amd64.ubuntu-system-settings_0.3%2B14.10.20140801.2-0ubuntu1ppa1_FAILEDTOBUILD.txt.gz
[21:39] <slangasek> note that, due to the upcoming release-to-manufacturer milestone for Ubuntu Phone, it's likely to at least be a week before anyone is willing to work on this for utopic (basically because we aren't going to want to pull upower 0.99 into the RTM archive)
[21:40] <Noskcaj> ok
[21:40] <Noskcaj> pitti, Any progress on python-dbusmock upower?
[21:41] <Noskcaj> And once this is done, we get the fun of bluez5