[00:06] <cyphermox> infinity: I know this isn't hard to verify or fix, but I want  to make sure it's actually doing something useful
[00:07] <infinity> cyphermox: It's definitely finding a bug.
[00:07] <cyphermox> tgtd's purpose is to find bugs?
[00:07] <infinity> cyphermox: The daemon should be starting on install (and, indeed, can start manually), but isn't.
[00:07] <cyphermox> I know
[00:07] <infinity> cyphermox: No, autopkgtest's purpose is to find bugs. :P
[00:08] <cyphermox> ;)
[00:08] <infinity> Might be a bug in init-system-helpers or something.
[00:08] <infinity> The postinst looks pretty boilerplate.
[00:08] <cyphermox> looks like it might be that, yes
[00:09] <infinity> Except we've had that same init-system-helpers code since vivid.
[00:09] <infinity> (The merge, after the fixups, was a no-op)
[00:10] <cyphermox> what changed is that now systemd
[00:10] <infinity> Doesn't finish its sentences?
[04:23] <pitti> Good morning
[04:24] <pitti> slangasek: thanks; seems she is still doing her job
[04:35] <gordon_> hmmm
[04:35] <gordon_> wanted to fix some bugs
[04:35] <gordon_> but seems like all of them are either not consistent
[04:35] <gordon_> or from old versions / translations
[05:54] <snkt> hiii
[05:55] <snkt> can anyone help me how to remove all the packages from ubuntu 10.04.3 or else from where I can download ubuntu-core 10.04.3
[05:59] <Noskcaj> snkt, The isos are at http://old-releases.ubuntu.com/releases/10.04.3/ if that's what you want
[05:59] <snkt> Noskcaj, i want a minimal ubuntu of 10.04.3 without any application installed
[06:00] <Noskcaj> I assume you could just mark everything for uninstallation in synaptic then unmark the stuff that comes with the ubuntu-desktop metapackage.
[06:00] <Noskcaj> You could also use the mini iso then just install what you want from that
[06:00] <TJ-> snkt: You can build such a configuration using deboostrap
[06:01] <snkt> Noskcaj, TJ- , Thanks for your response...
[07:01] <dholbach> good morning
[07:01] <seb128> hey dholbach
[07:44] <seb128> wgrant, hey, how is the wily translation opening going?
[07:44] <wgrant> seb128: Need to schedule exports with pitti.
[07:45] <seb128> pitti, ^
[07:46] <pitti> wgrant: I suppose we can stop utopic cronjobs
[07:46] <wgrant> pitti: Given that it dies in three weeks, quite possibly.
[07:46] <pitti> wgrant: disabled on my end
[07:46] <wgrant> pitti: Will switch them over on mine.
[07:46] <wgrant> pitti: Do you recall the wiki page?
[07:47] <pitti> wgrant: I curently run vivid on Tue, and trusty on Fri
[07:47] <pitti> wgrant: https://dev.launchpad.net/Translations/LanguagePackSchedule
[07:48] <pitti> oh dear, that's severely outdated
[07:48] <wgrant> Hm, well that looks totally out of date
[07:48] <wgrant> Yeha
[07:48] <pitti> wgrant: so, drop all but trusty and vivid, add wily, and then I'll adjust my cronjobs accordingly?
[07:49] <pitti> I need to do the first build manually, but I'll do that once it's on https://translations.launchpad.net/ubuntu/wily/+language-packs
[07:49] <wgrant> pitti: Are we considering 14.09 dead?
[07:49] <pitti> wgrant: AFAIK we completely updated to vivid+PPA
[07:49] <wgrant> Great.
[07:49] <pitti> and will probably move to rtm/15.04 for translations
[07:49] <wgrant> We may need to add the new 15.04 series later, but we can get there.
[07:49] <wgrant> Yep
[07:50] <wgrant> pitti: I might stick wily in the precise slot, to avoid the weekend.
[07:50] <pitti> wgrant: for releases, doing wily on Monday would be good
[07:50] <wgrant> Ah, true.
[07:50] <pitti> although..
[07:51] <pitti> last time infinity wanted the langpacks done the week before already, i. e. Thu/Fri export would be better indeed
[07:51] <pitti> and for the alphas it doesn't matter really
[07:51] <pitti> wgrant: sorry about the confusion -- so wily on Thu sounds better
[07:51] <pitti> (so that I can build on Fri)
[07:52] <wgrant> http://paste.ubuntu.com/11834712/ -> http://paste.ubuntu.com/11834720/
[07:53] <wgrant> diff: http://paste.ubuntu.com/11834721/
[07:53] <wgrant> Looks sane?
[07:53] <wgrant> trusty moves a day earlier.
[07:53] <pitti> wgrant: ITYM "wily" in teh last line
[07:53] <wgrant> Er yeah
[08:16] <mardy> pitti: I guess that python-dbusmock cannot be used to mock methods which are implemented in the dbus daemon itself, right? (like "GetConnectionAppArmorSecurityContext")
[08:16] <tjaalton> do trusty daily images get some sort of testing?
[08:17] <pitti> mardy: I've never tried that; my gut feeling is "no", but maybe dbus/python-dbus do allow it
[08:17] <pitti> wgrant: so, what's the final crontab now?
[08:17] <mardy> pitti: ok, I might try then, thanks
[08:26] <pitti> wgrant: nevermind, thanks for updating the wiki
[10:14] <ricotz> mdeslaur, hi, there are new releases of nss/nspr which could get in to wily
[11:11] <mdeslaur> ricotz: yes, there are
[11:35] <ogra_> xnox, yo ... you didnt answer my question on bug 1323732
[11:43] <Unit193> https://bugs.debian.org/791661
[11:44] <ogra_> Unit193, hah, thanks ... that crazy mvo guy
[11:45] <ogra_> (though that still doesnt answer my question if xnox' suggestion would work for us :) )
[11:46] <Unit193> :)
[12:10] <ChrisTownsend> pitti: Hey!  Any idea when the fix for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1470060 will land in Wily?
[12:15] <seb128> ChrisTownsend, is that the cause of your "can't start applications" issue?
[12:15] <pitti> ChrisTownsend: upstream said they were going to release 222 today
[12:15] <pitti> ChrisTownsend: I'm ready to package it (I have pkgs for current git snapshot)
[12:15] <pitti> ChrisTownsend: so, hopefully today
[12:16] <pitti> ChrisTownsend: if you need some working packages right now, please feel free to use https://launchpad.net/~pitti/+archive/ubuntu/systemd
[12:16] <ChrisTownsend> seb128: It *might* be the issue for that, but it's also blocking some work I'm doing for the Lagacy X app support project I'm working on.
[12:16] <ChrisTownsend> pitti: Cool, thanks!
[12:16] <seb128> ChrisTownsend, was your issue from yesterday under a system using the lxc contained version of unity8?
[12:17] <ChrisTownsend> seb128: No, it's the non LXC version on Wily.
[12:17] <seb128> k, that doesn't explain that issue then
[12:19] <ChrisTownsend> seb128: This is what is printed out in syslog when trying to start an app:
[12:19] <ChrisTownsend> Jul  6 08:54:07 Slave1 cgmanager[802]: cgmanager:do_create_main: pid 3150 (uid 1000 gid 1000) may not create under /run/cgmanager/fs/freezer/user.slice
[12:19] <ChrisTownsend> Jul  6 08:54:07 Slave1 cgmanager[802]: cgmanager:do_create_main: pid 3151 (uid 1000 gid 1000) may not create under /run/cgmanager/fs/freezer/user.slice
[12:20] <ChrisTownsend> seb128: It seems it might be related, but I don't know these things, so I'm just guessing.
[12:20] <seb128> yeah, unsure why other systems don't have the same issue
[12:20] <ChrisTownsend> seb128: Right.  I'll try pitti's package and see what happens.
[12:21] <pitti> ChrisTownsend: probably won't help; cgmanager is independent of sytsemd
[12:21] <pitti> ChrisTownsend: oh, maybe it will, nevermind
[12:21] <pitti> ChrisTownsend: if that's an unpriv LXC container that you are trying to trun
[12:21] <pitti> run
[12:21] <soee> can someone confirm if after (probably) kernel upgrade to 4.0 we can't now switch gpu on hybrid machine (intel + nvidia)?
[12:22] <ChrisTownsend> pitti: Yeah, was just taking a stab in the dark.  I'm not very hopeful:)
[12:25] <ChrisTownsend> seb128: \o/ It fixed my that issue!
[12:26] <seb128> weird
[12:26] <ChrisTownsend> seb128: It's weird that I'm the only one seeing that and that this fixes it.
[12:26] <seb128> right
[12:26]  * ChrisTownsend Shrugs
[12:27] <seb128> unsure what triggers the issue/what is different in your config
[12:27] <pitti> ChrisTownsend: "it" being the new version? or what?
[12:27] <ChrisTownsend> seb128: No clue.
[12:27] <ChrisTownsend> pitti: So the issue I had was that apps in Unity 8 dekstop wouldn't start due to the error I pasted above.
[12:27] <ChrisTownsend> pitti: You systemd PPA fixes this issue for me.
[12:28] <ChrisTownsend> pitti: No LXC's invlolved.
[12:28] <pitti> ChrisTownsend: nice! so it's the same cgroup issue then, cgmanager wants to create sub-cgroups for your session as your user
[12:28] <seb128> pitti, what is weird is that others don't hit that issue
[12:29] <pitti> yeah, it's a race condition
[12:29] <seb128> oh, ok
[12:29] <pitti> cat /proc/self/cgroup
[12:29] <ChrisTownsend> Oh...my computer is blazing fast I guess:)
[12:29] <pitti> if they all end with session-XX.scope, it's correct, but you might have some controllers which are just in the top-level (or some intermediate) hierarchy
[12:30] <ChrisTownsend> pitti: And to confirm, my unprivileged lxc's now start.
[12:30] <ChrisTownsend> pitti: Thanks!
[12:30] <pitti> yw!
[12:30] <pitti> I wrote an autopkgtest now, so hopefully we'll stop breaking the unpriv lxc support
[12:31] <pitti> it's a distro patch, so it needs to be adjusted to behaviour changes in upstream
[12:31] <ChrisTownsend> pitti: That will be a very welcome test:)
[12:58] <ChrisTownsend> pitti: Hey again.  Seems Reboot/Shutdown from the power indicator are no longer working w/ the systemd from your PPA.  Is this known?
[12:58] <ChrisTownsend> pitti: This is Unity7.
[12:59] <pitti> ChrisTownsend: not known, no; let me try
[12:59] <ChrisTownsend> pitti: Ok.
[13:02] <ChrisTownsend> pitti: Hmm, in my syslog, gnome-session is complaining about needing interactive authentication for those operations.
[13:02] <pitti> ChrisTownsend: works fine here
[13:02] <pitti> ChrisTownsend: so it probably means you don't have a "local" logind session
[13:03] <pitti> ChrisTownsend: do you mind filing a bug with "loginctl" and "loginctl show-session $XDG_SESSION_ID" outputs?
[13:03] <ChrisTownsend> pitti: Hmm, wonder how I got into that state.
[13:03] <ChrisTownsend> pitti: Sure, I can file the bug.
[13:06] <ChrisTownsend> pitti: That bug should be filed against the systemd package, right?
[13:07] <pitti> ChrisTownsend: yes
[13:07] <ChrisTownsend> pitti: ack
[13:13] <ChrisTownsend> pitti: Ok, filed bug #1472259.  Let me know if you need any other info.
[13:14] <pitti> ChrisTownsend: just to be sure, that's from a clean boot?
[13:14] <ChrisTownsend> pitti: Yes
[13:14] <pitti> State=closing
[13:14] <pitti> so, odd indeed
[13:14] <ChrisTownsend> pitti: Shall I purge your PPA just to be sure?
[13:14] <pitti> ChrisTownsend: oh, is that *after* you requested a shutdown?
[13:14] <ChrisTownsend> pitti: Oh, right, I requested it.
[13:14] <pitti> ChrisTownsend: that would explain the "closing"
[13:15] <pitti> ChrisTownsend: ok, so that part is right; it seems some process is hanging in your session then
[13:15] <pitti> ChrisTownsend: does it shut down after 90s?
[13:15] <ChrisTownsend> pitti: No, it doesn't.
[13:15] <pitti> ChrisTownsend: can you please attach the output of "journalctl" there too, for completeness?
[13:16] <ChrisTownsend> pitti: I can reboot and get those outputs before issuing any shutdown or reboot.
[13:16] <ChrisTownsend> pitti: Sure.
[13:16] <pitti> ChrisTownsend: after issuing shutdown is fine
[13:16] <pitti> ChrisTownsend: and even necessary -- as that's when the bug happens
[13:18] <ChrisTownsend> pitti: Ok, attached the output of journalctl.
[13:22] <pitti> ChrisTownsend: I suppose "loginctl terminate-session $XDG_SESSION_ID" also doesn't do anything?
[13:23] <ChrisTownsend> pitti: Says "Failed to issue method call: Access denied"
[13:23] <pitti> ChrisTownsend: right, sorry, with sudo
[13:23] <ChrisTownsend> pitti: I should have known that:)
[13:23] <ChrisTownsend> pitti: Nothing happens
[13:24] <pitti> ChrisTownsend: hm, no immediate idea yet, I'm afraid; could you reboot with "debug" in the kernel command line, (try to) shut down again, and again attach "journalctl"?
[13:25] <ChrisTownsend> pitti: Yep, will do.
[13:25] <pitti> ChrisTownsend: I'm assuming that you only upgraded systemd, nothing else?
[13:25] <pitti> ChrisTownsend: thanks
[13:27] <pitti> slangasek: will we have a TB today, or do we cancel it (as agreed last meeting, when there are no topics)?
[13:27] <ChrisTownsend> pitti: A couple of other packages that don't look relevant were upgraded too.  However, the new 4.0 kernel was installed, and the first reboot I tried after running the 4.0 kernel was after I installed systemd.  After I get this output, I'll purge your ppa and see what happens.
[13:28] <pitti> ChrisTownsend: cheers
[13:34] <ChrisTownsend> pitti: After purging your PPA, I can reboot/shutdown again.
[13:37] <pitti> ChrisTownsend: ok; let's see whether the debug log reveals anything
[13:37] <ChrisTownsend> pitti: Ok.  I attached it to the bug.
[13:37] <pitti> Jul 07 09:28:32 Slave1 gnome-session[1850]: gnome-session[1850]: WARNING: Shutdown failed: GDBus.Error:org.freedesktop.DBus.Error.InteractiveAuthorizationRequired: Interactive authentication required.
[13:37] <pitti> ok, that again
[13:38] <pitti> ChrisTownsend: err, wait, this looks *seriously* wrong:
[13:38] <pitti>         c1 110 lightdm seat0
[13:39] <pitti>          1 1000 townsend
[13:39] <ChrisTownsend> pitti: Yeah, I thought that didn't look right.
[13:39] <pitti> ChrisTownsend: that means lightdm has the "foreground" session, and your XDG_SESSION_ID is c1
[13:39] <pitti> and "your" session is a remote one "1"
[13:40] <pitti> ChrisTownsend: does that also look like that if you boot with wily's systemd?
[13:41] <ChrisTownsend> pitti: Nope, it only lists my user as c2 and seat0.
[13:41] <pitti> that sounds correct then
[13:41] <pitti> ChrisTownsend: hm, need to think about thsi
[13:42] <ChrisTownsend> pitti: Sure.  Let me know if I can gather any more data or anything else to try.
[13:42] <ChrisTownsend> pitti: Thanks!
[14:40] <seb128> stgraber, hey, http://iso.qa.ubuntu.com/ is down/503, known issue?
[14:43] <teward> seb128: there was a 'downtime' notice email earlier today
[14:44] <teward> it went out over the -quality mailing list
[14:44] <teward> https://lists.ubuntu.com/archives/ubuntu-quality/2015-July/006051.html
[14:45] <seb128> teward, thanks
[14:46] <teward> you're welcoem
[15:10] <smoser> cyphermox, https://bugs.launchpad.net/maas/+bug/1402042
[15:10] <smoser> will that be sru'd to trusty ?
[15:10] <smoser> if not, any suggestions on how maas should know which token to use (--- or --) would be appreciated.
[15:11] <smoser> also would have to sru to precise installers.
[15:11] <smoser> :-(
[15:13] <cyphermox> the token change is already in the releases it should be. do you need to completely rewrite a command-line or can you append to it?
[15:13] <cyphermox> appending should be safe, things *should* (but it would be best to verify) already have the trailing separator
[15:17] <smoser> cyphermox, well, the problem is that maas now needs to behave differently based on the release it is installing
[15:17] <smoser> which it previoulsy did not do.
[15:17] <smoser> so i'd like to be able to throw '---' at everything and have the installers dtrt
[15:18] <cyphermox> I think it will, but I'm not certain
[15:18] <cyphermox> ie. --- on a -- release, you'll just get an extra token that preseed doesn't understand, and it shouldn't make it give up
[15:19] <cjwatson> the worst case there is that it won't be appended to the boot config in the installed system
[15:19] <smoser> right. thats what i care about.
[15:19] <smoser> i need it copied over to the installed system. otherwise i'd not be putting a '--' there at all.
[15:19] <cjwatson> but actually, I don't think even that's a problem
[15:20] <cyphermox> t just depends what debconf key it is
[15:20] <smoser> i dont care about debconf keys
[15:20] <smoser> i care about kernel command line args
[15:20] <smoser> ie if i boot installer as:
[15:20] <cyphermox> hum, then I think you do need to have the separator
[15:20] <smoser>   somearg root=someplace arg2 -- foo=bar zee wark
[15:21] <cyphermox> yeah
[15:21] <smoser> i need 'foo=bar zee wark' copied over to install system
[15:21] <cyphermox> smoser: give me a minute I'll look at preseed and whatnot
[15:21] <cjwatson> ah, right, yeah, valid separator is required.  but it should be fine as long as you're definitely picking up SRUed installers
[15:21] <smoser> so the installars have been sru'd then ?
[15:21] <cjwatson> hm, checking
[15:22] <cjwatson> doesn't look like it, in fact.  they really ought to be, because kernel backports
[15:22] <smoser> right.
[15:23] <cjwatson> affects anything from 3.15 on
[15:23] <smoser> right.
[15:24] <cjwatson> so IMO we should SRU debian-installer-utils to precise/trusty/utopic, then that'd be picked up by the next d-i SRU
[15:24] <cjwatson> the patch accepts either separator so is safe
[15:24] <smoser> right.
[15:24] <smoser> so i'll just make bug 1402042 affects debian-installer-utils ?
[15:25] <smoser> maybe change the bug title.. or i can file another.
[15:45] <smoser> cjwatson, what package to affect ?
[15:46] <mdeslaur> stgraber: do we have a tech board meeting today?
[15:46] <smoser> got it. (was confused when apt-cache didn't know about debian-installer-utils)
[15:51] <stgraber> mdeslaur: not sure, I was planning on joining the channel and see if people were there :) according to the wiki it's slangasek's time to chair
[15:51] <mdeslaur> stgraber: oh! I misread the wiki and though it was you
[15:52] <slangasek> ah, well I'm planning to be there :)
[15:53] <slangasek> infinity kees pitti: TB meeting in 7 minutes :)
[15:53] <pitti> slangasek: ack
[15:56] <cjwatson> smoser: yeah, apt-cache show won't tell you about udebs, but apt-cache showsrc would have done
[15:56] <cjwatson> debian-installer-utils, indeed
[15:57] <hjd> Hm... sqlalchemy in Wily-proposed failed to build on amd64 because it didn't find python-zzzeeksphinx (https://launchpad.net/ubuntu/+source/sqlalchemy/1.0.6+ds1-1/+build/7577027). But sqlalchemy built successful on all other architectures (https://launchpad.net/ubuntu/+source/sqlalchemy) even though zzzeek-sphinx is only available on amd64 (https://launchpad.net/ubuntu/+source/zzzeeksphinx).
[15:59] <snow_ru> hi
[15:59] <hjd> I'm confused why it would fail on one architecture, but not the others. Am I missing something here?
[15:59] <snow_ru> hi all
[16:00] <snow_ru> i don't know if this bug is fixed
[16:00] <snow_ru> so I come here
[16:00] <cjwatson> hjd: your premises are wrong in two ways :-)
[16:00] <snow_ru> sudo apt-get install python-pip
[16:00] <snow_ru> The following packages have unmet dependencies:
[16:00] <snow_ru>  python-pip : Depends: python-pip-whl (= 1.5.4-1ubuntu3) but it is not going to be installed
[16:01] <snow_ru> Recommends: python-dev-all (>= 2.6) but it is not installable
[16:01] <cjwatson> hjd: firstly, python-zzzeeksphinx is available on all architectures - it's just only built on amd64, because it's architecture-independent
[16:01] <snow_ru> Recommends: python-wheel but it is not installable E: Unable to correct problems, you have held broken packages.
[16:01] <snow_ru> thanks !
[16:02] <cjwatson> hjd: secondly, the reason this only failed on amd64 is that it's listed in Build-Depends-Indep, which is only considered on amd64 (as of vivid)
[16:02] <snow_ru> I saw on lauchpad that htis bug has been fixed a couple of weeks ago, but it stll happens on my machine
[16:02] <cjwatson> hjd: finally, the reason it failed at all is that sqlalchemy is in main, but python-zzzeeksphinx is in universe
[16:03] <cjwatson> it requires a main inclusion report for zzzeeksphinx if that build-dep is going to stay there
[16:05] <pitti> . o O { can we reject MIRs on the grounds of "silly/unpronouncible package name"? }
[16:06] <hjd> cjwatson: Ah, ok. "python-zzzeeksphinx is available on all architectures" That makes sense, I should probably have guessed/checked that since it's a python package.
[16:06] <hjd> cjwatson: Didn't check main vs universe though.
[16:13] <hjd> cjwatson: I'm reading about Build-Depends-Indep, but I'm not sure if I understood it correctly. They are dependencies which are used to create architecture independent packages (https://wiki.debian.org/Build-Depends-Indep), but they are only fetched for a particular architecture? Is it simply that the architecture independent binary packages are built once (because once for each arch would simply create duplicates) and the architecture
[16:13] <hjd> where they are built happen to be amd64?
[16:14] <cjwatson> hjd: as you say.
[16:14] <hjd> ok :)
[16:14] <cjwatson> though not "happens", it's specifically configured that way.
[16:14] <cjwatson> used to be i386, but amd64 is a better default nowadays, so that's what's used from vivid on.
[16:23] <pitti> ChrisTownsend: ah, nice! http://lists.freedesktop.org/archives/systemd-devel/2015-July/033464.html
[16:23] <snow_ru> ok.
[16:27] <snow_ru> wgrant, ?
[16:29] <snow_ru> wgrant, https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1468155
[16:46] <arges> is there a bug for fixing /etc/network/interfaces to somehow match the interface name that systemd sets up in wily?
[16:46] <pitti> arges: no, and we don't plan on doing this on upgrades; upgrades won't use the new names
[16:47] <pitti> arges: it's not just /e/n/i, it's also firewall configs and an unknown amont of other places where admins might rely on the old names, so this is essentially not upgradeable automatically
[16:47] <arges> pitti: so here's my problem. I install wily using the daily iso. When I boot the machine /etc/network/interfaces doesn't match what ifconfig -a shows me
[16:47] <pitti> there's a manual procedure in /usr/share/doc/udev/README.Debian
[16:47] <arges> so i don't have networking until I type in the name manually into /etc/network/interfaces
[16:47] <arges> (this is server only obviously)
[16:48] <pitti> arges: ah, so apparently you found a case where the installer hardcodes eth0, or there's something wrong with the udev-udeb
[16:48] <pitti> arges: would you mind filing a bug with the details how you installed, your /e/n/i, and the installer logs?
[16:48] <arges> pitti: the testcase is: install wily ubuntu-server
[16:48] <arges> pitti: what does /e/n/i mean?
[16:48] <pitti> arges: against systemd should do for now, I can reassign it to d-i or wherever appropriate
[16:48] <pitti> arges: /etc/network/interfaces
[16:48] <arges> pitti: ah! make sense
[16:49] <arges> pitti: yup, I figured I'd check if this was a 'known issue' first
[16:49] <arges> i'Ll file the bug
[16:49] <pitti> arges: not that I know of
[16:49] <pitti> arges: cheers!
[16:55] <pitti> ChrisTownsend: I asked for another log in the bug, if you have time
[16:56] <teward> pitti: can I pick your brain for a moment?  NOt sure if I did before.
[16:56] <teward> when you have a minute :)
[17:15] <nemo> So we have pretty good maintainers of the ubuntu packages these days for Hedgewars.  Locutus is very diligent w/ backports
[17:15] <nemo> and even obscurish stuff like arm and testing our C cross-compile...
[17:16] <nemo> the issue is that ubuntu does not make upgrading to backports terribly discoverable for users
[17:16] <nemo> today 'cause I was a bit more attentive, I ran into 3 users over the course of 2 hours on our server using 0.9.20 - the version released in 2014
[17:17] <nemo> none of them could play other users, so were just a bit frustrated at the lack of rooms.
[17:17]  * ogra_ lols about "obscurish stuff like arm" ... 
[17:17] <nemo> ogra_: heh. well... if we actually had a functioning mobile port
[17:17] <ogra_> nemo, we sell phones with ubuntu on it
[17:17] <nemo> ogra_: there aren't a ton of arm desktops. chromebook, but unfortunately graphics accel on chromebook sucks
[17:17] <ogra_> what arch do you think they are ;)
[17:17] <nemo> ogra_: I know... I keep meaning to try ubuntu mobile on my nexus 5
[17:17] <nemo> ogra_: just noting our phone situation isn't great
[17:18] <ogra_> its young ...
[17:18] <nemo> ogra_: not totally sure the touch integration is even compiled in that package
[17:18] <nemo> so from our perspective, arm is kind of obscure ☺
[17:18] <nemo> anyway...
[17:18] <nemo> so.. I get why backports is not so discoverable for users. you don't want people accidentally breaking key system packages
[17:19] <nemo> but... hedgewars is pretty much the opposite of that. broken without upgrading, and not a key package, in fact, pretty isolated.
[17:19] <nemo> is there, by any chance, some flag to request "auto upgrade" for a package? that is, recommend upgrade if backports is enabled?
[17:19] <gordon_> Wish to try Ubuntu touch on nexus 6
[17:19] <nemo> gordon_: is that directed at me? don't have a nexus 6, don't plan to ever buy one
[17:20] <gordon_> No, not to you
[17:20] <nemo> seems barely worth the price now after the price cut, and pissed off at lack of replaceable battery or minisd
[17:20] <nemo> ok
[17:20] <gordon_> I have nexus 6 ;)
[17:20] <nemo> *microsd
[17:20] <gordon_> And can day that it's nice
[17:20] <nemo> if there is such a flag, I could ask locutus to enable it on our package, to cut down on this annoying fact that 6 months after latest release we still get a steady stream of confused ubuntu users
[17:21] <nemo> well. more like a trickle. windows *is* the dominant platform :-/
[17:21] <nemo> and OSX isn't a problem w/ upgrading
[17:34] <cjwatson> nemo: no such server-side flag for backports.  If it's broken without upgrading, though, then it should probably be updated as an SRU, in -updates; this fits the same kind of conditions as https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-March/000550.html
[17:34] <nemo> cjwatson: I'd be all for that
[17:34] <nemo> we had some success w/ that in the past I think
[17:34] <nemo> but it has been very hit or miss
[17:34] <cjwatson> backports isn't meant to be a way to deal with a package that's just outright broken in the release pocket due to external changes
[17:34] <nemo> cjwatson: the issue is that it isn't *broken* just online play won't work against the official release version
[17:34] <nemo> cjwatson: since we are using a similar approach to, oh, Spring
[17:34] <cjwatson> well, that's an important piece of broken functionality
[17:35] <nemo> that is deterministic lockstep gaming
[17:35] <slangasek> pitti: cyphermox just brought to my attention a previously unknown (to me) corner case in proposed-migration: multipath-tools is blocked in -proposed by a buggy test in lava-dispatcher, and it looks to me that this test is buggy in the version of l-d in -proposed but not in wily.  Could p-m somehow handle this case automatically?
[17:35] <nemo> cjwatson: alright. I'll talk to locutus to see if he can switch to that approach in the future
[17:35] <cjwatson> I appreciate that going through the SRU process can take a while, but it's the best thing to do here
[17:35] <nemo> cjwatson: definitely getting tired of explaining this to ubuntu users ☺
[17:35] <nemo> cjwatson: well. I wouldn't be the one doing it 😉
[17:36] <nemo> cjwatson: deterministic lockstep isn't unusual in open source gaming. helps cut down on cheating, nice lightweight network communication.. I wonder if other games have a similar issue
[17:36] <nemo> even if they aren't doing that, can be missing key resources and such
[17:36] <nemo> cjwatson: it'd be nice if you guys could carve out a category for games
[17:37] <nemo> they are almost always not system critical, and usually people want to be on the latest hotness
[17:37] <nemo> only issue is dependencies ofc.
[17:37] <cjwatson> You could reasonably bring that to the techboard (which no longer includes me) as a suggestion, I imagine
[17:37] <nemo> ah
[17:37] <cjwatson> hedgewars in particular may be non-trivial because it's Haskell, and Haskell updates can be exciting
[17:38] <nemo> well. if #ubuntu-devel has such folks, consider it brought up 😝
[17:38] <cjwatson> I don't know how much updates to hedgewars require updates to the libraries it uses
[17:38] <nemo> cjwatson: wellll you guys could drop the server piece for all I care ☺
[17:38] <cjwatson> I expect that would be a harder sell
[17:38] <cjwatson> Dropping functionality in SRUs usually involves a whole lot more discussion
[17:39] <cjwatson> Anyway, it doesn't seem to have particularly tightly versioned libghc-*-dev build-deps, so that part is probably not a problem
[17:39] <nemo> agreed on haskell thing tho.  but luckily unc0rr doesn't add new haskell dependencies as often anymore
[17:39] <nemo> he's been kinda burned out w/ being a dad, like me ☺
[17:39] <cjwatson> It's only a problem for things that like to force latest version of everything
[17:41] <nemo> ogra_: hm... do you have an ubuntu phone?
[17:42] <ogra_> nemo, several :)
[17:42] <ogra_> (i used to work on the phone team(
[17:42] <nemo> ogra_: are you guys by any chance building hedgewars for the phone w/ MOBILE enabled?
[17:42] <ogra_> nemo, the phone community hides in #ubuntu-touch btw
[17:42] <nemo> ogra_: I think we have the phone-friendly UI and touch events hidden behind that flag
[17:42] <nemo> ah
[17:43] <nemo> might have to drop by
[17:43] <nemo> ogra_: our android and iOS ports have languished
[17:43] <ogra_> well, we dont rebuild any packages usually ...
[17:43] <nemo> but the MOBILE stuff is still in the source, and I'm curious if it is turned on/functioning
[17:43] <nemo> could ask someone to test it
[17:43] <nemo> ogra_: ah... I guess no then
[17:43] <ogra_> so yeah, test it ... but it would likely need some packaging work to not break the desktop version of the package
[17:43] <nemo> ogra_: definitely mobile UI is totally different from desktop
[17:44] <ogra_> right ...
[17:44] <nemo> but the android/iOS guys put fair amount of effort into it years ago, and in a platform generic fashion
[17:44] <nemo> if someone over there was willing to try a test build of an ubuntu mobile package, we might finally have a functioning mobile port again ☺
[17:44] <nemo> might be as easy as taking existing ubuntu package and enabling that build flag. maybe.
[17:45] <nemo> well. the frontend would not be as mobile friendly, but that's less critical than gameplay
[18:07] <snow_ru> hi MasterPiece
[18:07] <snow_ru> how areyou ?