[04:54] <pepee> hi. I'm copy/pasting my question:
[04:54] <pepee> in debian/ubuntu, if some package or group of packages is being built/uploaded, the inconsistencies can cause apt to report problems with dependencies. well, why isn't there a "temporary repo" or some kind of config file to indicates that packages are still being updated, so that those inconsistencies are minimized or totally avoided? even more... why don't ubuntu/debian upload packages at night? (I know night in the west means day in the east...
[04:54] <pepee> well, have some sort of control that uses timezone or something data)
[04:55] <pepee> not sure if this is the right channel, though
[05:00] <ScottK> Most people get packages through mirrors so there's no way to control exactly when things get updated.
[05:03] <pepee> and that's another thing, mirrors could be synchronized, and packages copied through bittorrent!
[05:04] <pepee> I wonder if that would work
[05:16] <RAOF> pepee: We actually do that now? Everything goes to foo-proposed, and when it's installable it gets migrated to foo. Likewise, Debian testing.
[05:17] <pepee> ahh, I didn't know. but I guess that's why I haven't had a broken update/upgrade lately :P
[05:18] <pepee> and by "lately" I mean, I can't even remember...
[06:17] <pitti> Good mo-hoorning!
[07:02] <dholbach> good morning
[07:14] <Noskcaj> kenvandine, Could you please fix bug 1194211 some time soon? It's the only reverse-depend of valc-0.18 now
[11:59] <Mirv> might I get a packaging changes ack from a core-dev for unity8-desktop-session changes? https://ci-train.ubuntu.com/job/landing-002-2-publish/28/artifact/packaging_changes_unity8-desktop-session_1.0.11+14.10.20140709-0ubuntu1.diff
[12:00] <Mirv> I digged about that added Conflicts, the commit message says "added Conflicts with ubuntu-desktop-mir because that package installs lightdm configs that cause Unity 8 to fail to start"
[12:05] <flexiondotorg> cjwatson, I've got a tiny merge proposal for ubiquity I'd like to submit. Having never gone through the process before can you check that I am about to proceed in the correct way?
[12:06] <cjwatson> flexiondotorg: maybe :)
[12:06] <cjwatson> Mirv: acked
[12:06] <cjwatson> Mirv: (and publishing)
[12:06] <Mirv> cjwatson: thanks
[12:07] <flexiondotorg> cjwatson, here is the diff - http://bazaar.launchpad.net/~ubuntu-mate-dev/ubiquity/ubiquity-marco/revision/6195?start_revid=6195
[12:07] <flexiondotorg> Should I just go ahead a create a merge proposal and describe why this is required in that proposal. I would you prefer I raise a bug first?
[12:08] <Eisbrecher_xnox> flexiondotorg: looks ok. Is it "marco" similar to metacity?
[12:08] <flexiondotorg> marco was forked from metacity.
[12:08] <Eisbrecher_xnox> flexiondotorg: in that case ubiquity-dm will need modifications to use marco, if present. Otherwise you would need to ship both metacity and marco.
[12:08] <flexiondotorg> It is compatible with metacity themes/settings etc.
[12:08] <cjwatson> flexiondotorg: should be fine for a merge proposal, but please do raise a bug so that we have tracking
[12:08] <Eisbrecher_xnox> flexiondotorg: bzr grep metacity
[12:08] <cjwatson> and yeah, what Eisbrecher_xnox said
[12:10] <flexiondotorg> Eisbrecher_xnox, Thanks. Taking a look now.
[12:10] <Eisbrecher_xnox> flexiondotorg: it should be a simple copy&paste of the metacity cases but "marco" and appropriate key settings. Are you using gnome-settings-daemon / gconf? if that's forked/renamed as well, further adjustments will be needed to accomodate those as well.
[12:11] <flexiondotorg> Eisbrecher_xnox, some background for you.
[12:11] <flexiondotorg> I'm working on Ubuntu MATE Remix.
[12:11] <flexiondotorg> MATE has been fully migrated to dconf/gsettings.
[12:12] <Eisbrecher_xnox> cool.
[12:13] <Eisbrecher_xnox> flexiondotorg: if marco is better than metacity, it might make sense to switch unity7 and openjdk to use that instead.
[12:13] <Eisbrecher_xnox> and finally drop metacity from the archive, cause, as far as I can see, it's not developed.
[12:13]  * Eisbrecher_xnox checks
[12:14] <flexiondotorg> Well, my opinion would be biased 😉
[12:14] <flexiondotorg> But yes. Marco is an evolution of metacity.
[12:15] <Eisbrecher_xnox> wait there is fresh release of metacity....
[12:18] <Eisbrecher_xnox> Laney: *blink* there was metacity release =) are we gonna take it
[12:20] <flexiondotorg> Eisbrecher_xnox, does ubiquity require a compositor? I see that ubiquity-dm set org.gnome.metacity compositing-manager to true. I can do the same for marco, but it is actually required?
[12:20] <Laney> no idea!
[12:21] <Eisbrecher_xnox> flexiondotorg: not required, but highly desired. please set it.
[12:21] <Eisbrecher_xnox> Laney: i'll try it out. release notes look harmless-ish https://mail.gnome.org/archives/ftp-release-list/2014-June/msg00019.html
[12:21] <flexiondotorg> Sure
[12:21] <Eisbrecher_xnox> mostly
[12:22] <Laney> Alberts is Ubuntu-ish AFAIK, he might have some plans there
[12:24] <flexiondotorg> Eisbrecher_xnox, most of what is new in metacity 3.12 is already implemented in marco.
[12:24] <flexiondotorg> They are pretty much equivalent now.
[12:24] <Eisbrecher_xnox> Laney: hm. looking at upstream release and our metacity packaging we have practically everything applied as patches by now.
[12:25] <Eisbrecher_xnox> flexiondotorg: yeah, it still feels weird to me that all components were forked and renamed, instead of keeping existing names and/or continue maintaining them.
[12:26] <flexiondotorg> Eisbrecher_xnox, The rename was required so that MATE and GNOME (applications and libraries) could be installed side by side.
[12:26] <flexiondotorg> That was done years ago by the original MATE developer.
[12:26] <flexiondotorg> The fork was massive, and in many cases, unnecessary.
[12:27] <flexiondotorg> The MATE Team (i'm a dev) have to aligning with GNOME libraries and in almost all case use the GNOME libraries now.
[12:28] <flexiondotorg> But, the application rename is still required so that user can have GNOME3 and MATE installed on the same system or just pick and mix the applications.
[12:48] <flexiondotorg> cjwatson, Eisbrecher_xnox Thanks for your help - I trust this is OK? https://code.launchpad.net/~ubuntu-mate-dev/ubiquity/ubiquity-marco/+merge/226114
[13:11] <kenvandine> Noskcaj, will do
[14:32] <hallyn> desrt: hey - so logind when sending the StartTransientUnit sends a "sd_bus_message_append(m, "a(sa(sv))", 0)", without which the sending fails bc of mismatched params.
[14:33] <hallyn> desrt: that fix (just adding that line) was added after drastic change in how the dbus msgs were formed, and i'm trying to figure out how to build it manually with things like opencontainer
[14:33] <hallyn> desrt: my quesiton is, what the heck is the point of that?  is it not supposed to be an array containing a string and another array, which in turn contains sv?  but it's not sending any actual values.
[14:34] <hallyn> anyway i'll go ahead and try just adding them as null values and assume i should ignore them in systemd
[14:34] <hallyn> oh, wait, i'm going about it wrong
[14:34] <desrt> dbus is strongly typed
[14:34] <desrt> even if you have an empty array you need to give an empty array of the correct type
[14:34] <hallyn> since systemd 208 is waht is in experimental, and it is NOT sending those, i should just not require them in systemd-shim
[14:35] <hallyn> desrt: ah, gotcha - thanks.  so it's opening the container but not adding any values, sending an empty array
[14:35] <desrt> yes.  it needs to open the container with the specific type to ensure the array has the correct type
[14:35] <hallyn> desrt: sorry for the noise, thanks :)
[14:35] <desrt> in fact, if it didn't do that, it wouldn't even be able to construct the array
[14:35] <desrt> since "empty array" doesn't exist without more information
[14:35] <desrt> must be "empty array of ...."
[14:35] <desrt> this is something that causes a lot of pain :)
[14:36] <desrt> consider binding to languages like python, for example.....
[14:36]  * hallyn grasps his side - "tell me about it"
[14:36] <desrt> pretty easy to guess what is the appropriate type for [1,2,3] or ['a', 'b', 'c']... but you see [] and it's like .... hmm... uhh...
[14:37] <desrt> (even [1,2,3] is a bit hard since those might be _unsigned_ ints, which is again a different type)
[14:37] <hallyn> desrt: but the "correct" set of paramaters, or the expected set - that comes from the .xml file in the server end?
[14:37] <desrt> yes
[14:37] <desrt> those files are also typically installed in /usr/share/dbus-1/interfaces, fyi
[14:38] <desrt> and you might find the 'gdbus introspect' command to be helpful
[14:38] <desrt> there is also a GUI tool called d-feet which is.... not excellent... but certainly very useful
[14:39] <hallyn> oh yeah i used that a few years ago.  all right, let's see if i can get another half step further this way :)  thx
[14:40] <desrt> keep poking as you need help... no sense in you spinning your wheels for an hour if i can answer more questions :)
[15:08] <hallyn> stgraber: slangasek: i'm not gonna like the answer, but i'll ask anyway - does systemd-shim need to also support non-cgmanager cgroup setup?
[15:08] <hallyn> heh, cgamanger isn't packaged for debian yet, is it, bc it relies on upstart
[15:09] <stgraber> hallyn: I'd be fine with just requiring cgmanager, cgmanager is in Debian, not sure about how usable it is though...
[15:09] <hallyn> if i write sysvinit scripts and package for debian can i skip the cgfs bit?
[15:09] <hallyn> yay
[15:10] <hallyn> all right i think i may be at the point where i can do something useful.
[15:10] <stgraber> but I think it'd be entirely fine to have systemd-shim work in Ubuntu with cgmanager, then just tell Debian to get cgmanager in working shape (if it's not)
[15:10] <slangasek> hallyn: I don't understand the question - are you asking whether systemd-shim needs to run on... systemd?
[15:10] <hallyn> slangasek: no, sysvinit
[15:11] <slangasek> ah
[15:11] <slangasek> no man, who cares about sysvinit :)
[15:11] <stgraber> slangasek: no, he's asking if systemd-shim should be able to work without cgmanager by doing direct fs callss
[15:11] <stgraber> *calls
[15:11] <hallyn> right
[15:12] <hallyn> smoser: digitalocean is very nice in some ways, but their archive mirrors/proxies seem to really mess things up sometimes.  pull-lp-source frequently does the wrong thing there.
[15:12]  * hallyn uses pull-debian-source tow ork around that :)
[15:21] <slangasek> hallyn: so in what sense does cgmanager rely on upstart, though?  Because actually, we do need systemd-shim to work in Debian on upgrade from wheezy to jessie
[15:21] <slangasek> but I would expect that to be systemd-shim + cgmanager + sysvinit, not systemd-shim + internal cgroup allocation + sysvinit
[15:28] <hallyn> slangasek: cgmanager doesn't depend on it, it's just that we only ever worked out the cgmanager-cgproxy interactions for upstart jobs
[15:28] <hallyn> really, the sysv should be easier, as we'll just do one script to run either/both, probably
[15:28] <stgraber> hallyn: sysvinit should be trivial, just use two pid files with a single init script launching both of them in the right conditions
[15:28] <slangasek> ok
[15:28] <stgraber> hallyn: systemd unit may be trickier but we don't have to care about that just yet
[15:29] <hallyn> stgraber: yup
[15:29] <hallyn> stgraber: all right well i guess i may have to talk to you about how to do the sysv after i get this bit done.  i'm just creating a clean git tree so i can properly track my changes now that i'm making progress
[15:31] <stgraber> hallyn: might also be worth checking if dba didn't make an init script already (and if he did, whether it's correct and covers all the crazy cases we do with upstart)
[15:36] <hallyn> stgraber: rmadison -u debian cgmanager doesnt' show any results
[15:46] <stgraber> hallyn: looks like it's still in new
[15:47] <stgraber> hallyn: no init script listed there so I guess he didn't write one
[16:31] <hjd> Looks like a package rebuild would fix bug 1247219. How would one request that, create a merge proposal where only the changelog has been edited?
[16:56] <dobey> hjd: yes
[17:02] <hjd> dobey: Ok, great :) Slightly busy right now, but will create one later. Thanks.
[17:06] <mdeslaur> cyphermox_: any idea why network-manager is failing the jenkins tests?
[17:33] <rbasak> If a package is removed from testing in Debian due to an RC bug/CVE, will we sync that removal in any way in Utopic?
[17:33] <rbasak> I presume not because I presume we're syncing from unstable?
[17:35] <rbasak> This is https://packages.qa.debian.org/p/percona-xtrabackup.html, Debian bug 751377.
[17:36] <rbasak> Upstream say that they will have a fix soon, but will miss the Debian autoremoval deadline.
[17:36] <rbasak> So I'd like to hold it in Utopic to give them time to give me a patch, if instead it would get removed.
[18:08] <hallyn> pitti: stgraber: do i understand correctly that user@1000.service refers to systemd user jobs, akin to upstart user jobs?
[18:08] <hallyn> (i.e. i should be able to ignore those)
[18:09] <stgraber> I'll let pitti answer that one as I've got unfortunately no clue
[18:11] <hallyn> ok . the three things i'm seeing are startunit for user-1000.slice, start-unit for user@1000.service, and starttransientunit for session-3.scope
[18:11] <hallyn> (not yet found a definitive way to tie a transient unit to a uid, unfortunately, though a pid is passed so i guess i can always deduce it myself)
[18:11] <infinity> rbasak: We don't follow testing autoremoval, no, as Debian may remove for reasons we don't need to (like incomplete transitions, etc).
[18:13] <hallyn> oh maybe i should get that from the slice string
[18:40] <cyphermox_> mdeslaur: no. it hasn't changed
[18:40] <mdeslaur> hrm
[18:40] <mdeslaur> weird...it's blocking dbus
[18:40] <mdeslaur> and modemmanager
[19:05] <barry> pitti: well, we might finally be making progress with the zope stack :)
[19:33] <cyphermox_> mdeslaur: could the settings for ipv6 privacy extension have changed?
[19:39] <mdeslaur> cyphermox_: oh, maybe...I seem to recall stgraber mentioning something about that
[19:40] <cyphermox_> ah?
[19:40] <cyphermox_> I know the way it displays in ip addr is different, but we already do account for that
[19:40] <mdeslaur> someone wanted the default changed on server only...not sure what came of that discussion though
[19:40] <cyphermox_> oh, right
[19:40] <cyphermox_> yes, I remember. We do this testing on server
[19:40] <rbasak> infinity: OK - thanks, that's useful for me in this case.
[19:41] <cyphermox_> I'll look into it
[19:46] <stgraber> I didn't do any change but it was indeed mentioned that maybe we would want to change that on servers
[19:48] <cyphermox_> nah I think it's just a timing issue
[19:49] <cyphermox_> the other test with IPv6 passed
[19:50] <robru> kenvandine, hey, I got libfriends built in silo 17, can you help me test it?
[19:50] <kenvandine> sure
[19:51] <kenvandine> if i can remember what we can do to test :)
[19:51] <kenvandine> oh, i guess friends-app is a good test
[19:51] <robru> kenvandine, yeah, basically, just make sure it doesn't break the phone or the desktop real quick. it built ok, so that's a good start ;-)
[19:52] <kenvandine> :)
[19:52] <kenvandine> sure
[19:54] <robru> kenvandine, thanks
[20:31] <cyphermox_> mdeslaur: stgraber: I'm tempted to just remove that check in the tests, privacy extensions might not be enabled in the test environment, I'd rather write a new test later to check only privacy extensions
[20:31] <cyphermox_> or you know, run stgraber's IPv6 tests, and get a clear picture of what's what
[20:31]  * mdeslaur shrugs
[20:35] <rbasak> cyphermox_: could you maybe have the test check the sysctl knob? Or have two tests, each with a skip if the sysctl knob is the wrong way?
[20:36] <cyphermox_> rbasak: well, that test is doing wpa and dhclient... I think it's a good idea, but I'll come up with a test for just the IPv6 settings
[20:36] <rbasak> cyphermox_: ah, OK
[20:37] <cyphermox_> right now there's testing and retesting of the same things again and again in slightly different ways, in many scripts
[20:38] <cyphermox_> we also check for the state of privacy extensions for the ipv6 tests with NM running, so it's still covered
[20:47] <kenvandine> robru, libfriends looks good
[20:47] <robru> kenvandine, sweet