[03:59] <lamont> what does it mean when .xsession-errors has: upstart: at-spi2-registryd respawning too fast, stopped
[04:43] <pitti> Good morning
[04:43] <pitti> flexiondotorg: wow, congratulations!
[04:52] <pitti> infinity: seems your linux force-badtest isn't working? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[06:33] <mardy> seb128: Hi! A friend is affected by bug 1286779 in trusty
[06:34] <mardy> seb128: as seen from other comments, it seems that the bug was fixed in utopic, but the fix was not backported yet
[06:34] <mardy> seb128: do you know how one can mark the bug as still being in Confirmed state for a series?
[06:35] <mardy> seb128: because the problem is that users who look at this bug page, are led to think that the bug is fixed in all versions, and they get confused
[06:45] <mardy> Mirv: or do you know? ^
[06:56] <Mirv> mardy: you can propose it for a series
[06:56] <Mirv> mardy: use the "Nominate for series"
[06:57] <Mirv> which should be on the right of "Also affects distribution/package" unless it requires some rights
[06:58] <infinity> pitti: The linux badtest was superseded by a newer linux.
[06:58] <mardy> Mirv: I think it does, I don't see it
[06:58] <infinity> pitti: Which, I hope, also fixes the test...
[06:59] <Mirv> mardy: ok, nominated. since there's a patch and there's the impact/testcase/regressionpotential trio (as per https://wiki.ubuntu.com/StableReleaseUpdates), can you subscribe ubuntu-sponsors to the bug?
[06:59] <seb128> mardy, Mirv, what Mirv said, you should be able to propose it for nominations even if you can't approve those (or is that restricted to ubuntu bugsquad?)
[07:00] <Mirv> seb128: I think even nomination might be bugsquad only, "Ask the Ubuntu bug control team to nominate the bug"
[07:00] <mardy> seb128: there's just no "Nominate for series" link anywhere for me
[07:01] <seb128> mardy, I guess you are not in ubuntu bug control, I though you would be, sorry
[07:03] <Mirv> mardy: ok it should be all set and be visible at http://reqorts.qa.ubuntu.com/reports/sponsoring/ soonish
[07:03] <mardy> seb128: np. Should I be in that group?
[07:04] <seb128> mardy, well, apparently you are not missing not being in it? I though you were triaging the ubuntu bugs for the packages you maintain, and without that team memberships you don't have full triaging rights, do you?
[07:04] <mardy> Mirv: thanks
[07:06] <mardy> seb128: correct. I generally don't need these permissions, but sometimes I feel the need of editing the status of bugs for the software I maintain, when they are filed on the source package
[07:07] <seb128> mardy, yeah, other teams tend to ask for bugsquad memberships because most team standardize on using the ubuntu package buglist as their main buglist, since that's where most users are going to file bugs
[07:07] <seb128> mardy, anyway, if you want to be added just talk to bdmurray about it
[07:07] <mardy> seb128: OK, thanks!
[07:08] <seb128> yw!
[07:08] <mardy> seb128: just to be safe: if I get that membership, will I get notifications for all Ubuntu bugs, even those I don't care about?
[07:08] <seb128> mardy, no, bugsquad has a list, emails go to the list, if you don't subscribe to the list you don't get any email
[07:09] <mardy> seb128: cool, thanks
[07:09] <seb128> yw :-)
[07:13] <doko> pitti, autopkgtest for zope.session 3.9.5-0ubuntu2: Regression (Jenkins: public, private)
[07:13] <doko> but the link shows success ...
[07:21] <pitti> doko: erk, public jenkins fail, it's missing the log from #6; see http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-zope.session/lastBuild/?
[07:25] <doko> pitti, ahh, thanks
[07:31] <seb128> didrocks, pitti, slangasek: btw what's the status of the systemd transition? still looked at for vivid? do we have a bug/ffe recording the status, what's still needed, etc?
[07:32] <didrocks> seb128: IIRC, slangasek told to pitti the other day to go ahead on the NFS systemd porting
[07:32] <didrocks> as he didn't get the time to catch it
[07:32] <didrocks> and NFS upstream has a systemd unit
[07:32] <seb128> k
[07:32] <pitti> yeah, that's the status now -- we need to find someone to fix NFS
[07:33] <seb128> do we still plan to do it/have a ffe filed for it?
[07:33] <didrocks> that's all about my knowledge, getting back some butter to spread on bread (like my knowledge :p)
[07:33] <pitti> (and get familiar enough with it to test)
[07:33] <pitti> didrocks: so I guess you aren't interested in looking at it?
[07:34] <pitti> I need to work on some other urgent things today/Monday, but I'll try to find some time to set up a test system and get familiar with our split upstart jobs and the NFS components
[07:34] <didrocks> pitti: I don't have enough knowledge apart from having used it for a while (and not anymore), but it seems to be quite tricky, no, like /home or /usr on NFS…?
[07:34] <didrocks> I can give a look on Monday if needed
[07:34] <pitti> didrocks: let's not start /usr on NFS :)
[07:35] <didrocks> but I would clearly need double checking :)
[07:35] <pitti> /home or /srv or so are quite reasonable, though
[07:35] <pitti> didrocks: yeah, we can team up, to add our (so far) nonexistant knowledge :)
[07:35] <didrocks> pitti: let's do that, I'll start on Monday
[07:36] <pitti> didrocks: I propose we first figure out a bunch of scripts/VMs to test this under upstart, then port the server (NFS server should be really simple, compared to client), and then tackle the client bits
[07:36] <pitti> didrocks: nice, thanks! the two of us should figure this out hopefully
[07:37] <didrocks> pitti: let's cross fingers! (and sounds like a good plan)
[07:37] <pitti> didrocks: right, upstream git has systemd units, let's see how well they match up with our upstart job / existing config files
[07:37] <pitti> although I'd hope that we didn't change upstream's config files in Ubuntu
[07:38] <didrocks> yeah, I guess a new week with fresh brain will help :)
[07:38] <pitti> meh, systemd's tests take aaages now; but oh well, ++confidence
[07:39] <pitti> speaking of that, we don't have an fsck test yet
[07:39]  * didrocks always prefer long running tests (especially when you don't have to run on your machine itself) than no confidence :)
[07:39] <didrocks> yeah, I want to tackle this
[07:39] <didrocks> I think I would have to go to integration tests, not sure about units…
[07:40] <didrocks> and having a mock plymouth socket, listening to events
[07:40] <pitti> didrocks: nah, an integration autopkgtest
[07:40] <didrocks> that wouldn't do it for upstream though, right?
[07:40] <pitti> didrocks: like, plug in the mock fsck, check that the systemd still starts and that fsckd ran and finished, somethign like that?
[07:40] <didrocks> oh, no more fine-grained?
[07:41] <didrocks> maybe sending at least a Control+C and seeing it being intterupt?
[07:41] <didrocks> (if it's easy to do that in autopkgtests)
[07:41] <didrocks> interrupt*
[07:41] <pitti> didrocks: well, something that guards against boot failure is already valuable; verifying that it displays the expected stuff is harder, but also much easier to recover from if we screw that up
[07:42] <pitti> didrocks: upstream also has these VM tests; the same approach ought to work there, too
[07:42] <didrocks> yeah, I would still like that we check cancellations works
[07:42] <didrocks> oh nice
[07:42] <didrocks> just need to ensure it's easy to send key press to the vm
[07:42] <pitti> didrocks: hm, injecting ^C into plymouth in a VM without screen or keyboard, we have to think about that
[07:42] <didrocks> yeah
[07:42] <pitti> didrocks: we could talk to the monitor, but an autopkgtest doesn't have access to that
[07:43] <didrocks> right, as it's inside the vm…
[07:43] <pitti> didrocks: oh, perhaps via uinput
[07:43]  * didrocks doesn't know that, but noting down…
[07:43] <pitti> didrocks: http://thiemonge.org/getting-started-with-uinput
[07:43] <didrocks> pitti: first google result ;)
[07:43] <pitti> didrocks: it's what autopilot uses as well to fake keypresses and mouse moves
[07:44] <pitti> ah, /me pats firefox awesome bar :)
[07:44] <didrocks> heh :)
[07:44] <didrocks> pitti: ok, if it works, just need to ensure I can get the right timing (when checking for process)
[07:44] <didrocks> and having a flag in the mock fsck to tell "fsck ended properly"
[07:44] <didrocks> and just checking the flag file isn't prevent when cancelled and no more process
[07:44] <didrocks> sounds easy enough
[07:46] <pitti> didrocks: so you'd need to create a unit which runs on boot Before=systemd-fsck-root.service and then sets up uinput and polls for /sbin/fsck? (or just fsckd running)
[07:46] <pitti> didrocks: the autopkgtest will only resume after the boot finished, so you can't do it right there; but adding such a helper unit before reboot should work
[07:47] <didrocks> pitti: yeah, the unit approach for this sounds the easiest and putting flags
[07:53] <dholbach> good morning
[07:55]  * pitti waves to dholbach
[07:58] <dholbach> hi pitti
[08:03] <darkxst> hey pitti, didrocks
[08:04] <darkxst> is systemd init still happening this cycle?
[08:04] <didrocks> darkxst: hey! backlog here, we discussed about NFS ^ I guess once it's done, we can discuss the FFe
[08:04] <pitti> we still aim for it, yes
[08:05] <darkxst> ok we have a really bad bug (some sort of race) with upstart init atm and that will need to be fixed if systemd doesnt land
[08:07] <darkxst> bug 1424731
[08:28] <pitti> doko: ah, missing pkg_resources.component_re is indeed related to new setuptools, right? is that intended, and zope.session needs to be updated, or is that a setuptools bug?
[08:28] <infinity> pitti, jibel: Seeing tests for "glibc_2.19-10ubuntu2" on vivid's update_excuses, which is utopic's version.  I assume the same as the linux_3.16 thing I saw yesterday...
[08:28] <pitti> infinity: right
[08:29] <infinity> pitti: Any idea what's up with that? :P
[08:29] <pitti> infinity: not immediately, I'm afraid; this code is horrible, and I had hoped it would have died several months ago :/
[08:31] <pitti> so the version is correct in results.history
[08:39] <doko> pitti: van.pydeb fixed
[08:39] <pitti> doko: ah, that's what zope.session used? thanks
[08:39] <pitti> doko: if it doesn't re-trigger the test automatically, I'll kick it in about an hour
[08:40] <doko> pitti, van.pydeb is now in the release pocket
[08:41] <pitti> ah, great (doesn't even need to be, proposed is enough); zope.session test requeued
[08:41] <pitti> but the queue is full, will take a bit
[08:43] <jibel> infinity, I think it's the same thing than linux yesterday, but didn't find what it is yet.
[08:43] <jibel> +1 to make this code die quickly
[08:47] <doko> infinity, what is the status of the two disabled ppc64el buildds? besides being disabled
[09:03] <apw> doko, would the curent failure on the glibc test regarding relocs be related to the binutils fix you uploaded this hour ? (see pm for the errors)
[09:04] <doko> apw, that was updated on Tuesday, not now. it just migrated
[09:10] <apw> doko, ahh so it did, fooled me
[09:11] <doko> apw, but honestly, let's wait until infinity uploads glibc-2.21 built with GCC 4.9 ...
[09:12] <apw> doko, you think that will ever build :)
[09:13] <doko> the limiting factor is infinity, not GCC ;-P
[09:33] <infinity> doko: How does waiting for a new glibc change that the current binutils broke glibc's testsuite? :P
[09:35] <doko> infinity, is it binutils?
[09:35] <infinity> doko: It sure looks like it at a glance.
[09:36] <infinity> /usr/bin/ld: copy reloc against protected `protvaritcpt' is invalid
[09:36] <infinity> /usr/bin/ld: failed to set dynamic section sizes: Bad value
[09:36] <infinity> collect2: error: ld returned 1 exit status
[09:36] <doko> and you are sure that gcc-4.8 is still correct?
[09:37] <infinity> No code changes in glibc, hard to blame anyone else but binutils or gcc.
[09:37] <doko> I like makefiles like these:
[09:37] <doko> # Beautified output
[09:37] <doko> quiet_GEN = @echo "  GEN        $@"; $(GEN)
[09:37] <doko> quiet_CC  = @echo "  CC $@"; $(CC)
[09:37] <doko> quiet_LD  = @echo "  LD $@"; $(LD)
[09:37] <doko> quiet_INSTALL = @echo "  INSTALL        $?"; $(INSTALL)
[09:38] <infinity> doko: Erm, I'm sure we should move to 4.9 at some point, but "the toolchain we're using stopped working correctly" is the bug being reported here.
[09:38] <doko> infinity, what is the status of the two disabled ppc64el buildds? besides being disabled
[09:40] <infinity> doko: Non existant, except in the UI.  They will exist again some day.
[09:41] <doko> ugh
[09:43] <infinity> https://sourceware.org/bugzilla/show_bug.cgi?id=17709 <-- binutils regression that hjl is blaming on glibc, and no fix in either project.  Yay.
[09:47] <doko> he's blaming it on glibc ...
[09:47] <doko> apw, is there a build log in launchpad?
[09:49] <infinity> doko: Yes, I said he's blaming it on glibc. :P
[09:50] <infinity> doko: Still, bisecting the offending breakage in binutils (that was backported from 2.26 to 2.25, apparently, yay cowboys) shouldn't be too hard?  I don't think it's unreasonable to expect to be able to build current glibc with our binutils.
[09:50] <apw> doko, it is in the adt builders, i'll paste the log urls in pm for you
[09:53] <infinity> pitti: Can we revisit the concept of artificial rdeps for triggering tests that we want despite no direct dependencies?  (ie: glibc/binutils)
[09:54] <pitti> infinity: yes; that's somewhere in the big stack of things to do, create a Tests.gz index (like Packages.gz, but for all debian/tests/control)
[09:54] <pitti> with that we can do reverse test dependency triggering
[09:54] <pitti> infinity: binutils ought to trigger on glibc uploads already, though?
[09:55] <infinity> pitti: If it does, someone forced binutils in...
[09:55] <infinity> pitti: Err, no.  The other way around.
[09:55] <infinity> pitti: binutils needed to trigger a glibc test.
[09:55] <infinity> pitti: And glibc doesn't depend on binutils (why would it?)
[09:56] <pitti> right; I think that's the direction which isn't currently happening
[09:56] <pitti> actually it does
[09:56] <pitti> Build-Depends: ... binutils (>= 2.21)
[09:56] <infinity> pitti: Some of this would be caught if we were also testing rbuilddeps along with rdeps, but that doesn't really help for build-essential. :P
[09:56] <infinity> pitti: We don't test rbuilddeps, do we?
[09:56] <pitti> infinity: we do; at least the code makes an effort to
[09:57] <pitti> and we most certainly want to
[09:57] <infinity> pitti: Well, I'm going to go with "no, you really don't".
[09:57] <infinity> pitti: Cause the last glibc test was Feb 19, and binutils was uploaded way after that.
[09:57] <infinity> pitti: And it migrated without fuss.
[09:57] <pitti> infinity: maybe, but that's a bug then, and not intended
[09:58] <pitti> infinity: no, I have a "Jenkins Failure - vivid-adt-glibc 32" from this morning
[09:58] <pitti> http://d-jenkins.ubuntu-ci:8080/job/vivid-adt-glibc/32/? clearly failed
[09:58] <infinity> pitti: Is it really a bug, though?  The number of people who build-dep on build-essential packages when they shouldn't would blow up the reverse test map, I'd guess.
[09:58] <infinity> pitti: Yes, 32 was after binutils had migrated.
[09:59] <doko> infinity, there's a lot of the copy-relocs changes ... will need to do that manually
[10:02] <pitti> infinity: hm, digging through http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses/vivid/2015-02-27/ to see excuses; whee, we run it every 10 mins now?
[10:02] <pitti> er, what is that
[10:02] <pitti> are they double-gzip'ed?
[10:02] <pitti> so they are
[10:03] <jamespage> pitti, morning - the latest python2.7 update had a slightly bad effect on gobject-2 - see bug 1426294
[10:04] <pitti> infinity: confirmed, bintuils only triggered a handful of packages, not glibc
[10:05] <pitti> argh bug :/ /me piles on TODO to investigate
[10:05] <pitti> jibel: reverse build deps triggering not working doesn't happen to ring a bell, I figure?
[10:05] <jibel> pitti, no it's new.
[10:06] <jamespage> pitti, related to:
[10:06] <jamespage> Issue #22079: PyType_Ready() now checks that statically allocated type has
[10:06] <jamespage>       no dynamically allocated bases.
[10:06] <pitti> jibel: ack, so TODO it is
[10:06] <jibel> pitti, I can have a look in 1hour or so
[10:12] <infinity> pitti: I'm still not positive we *want* reverse build-deps to trigger.  You might want to build a map of what that would look like before doing it.
[10:16] <doko> jamespage, any update on the required gccgo-go changes?
[10:17] <jamespage> doko, switching to use the go stuff provided by gccgo right?
[10:17] <doko> yes
[10:17] <doko> if it works ...
[10:18] <doko> jamespage, I can add go and gofmt symlinks too in gccgo for those architectures where go and gofmt don't exist (arm64, powerpc, ppc64el?)
[10:19] <jamespage> doko, both golang-go and gccgo-go use alternatives for the various binary conflicts - maybe follow that approach? then we can switch between them for comparison
[10:19] <jamespage> if all is good then we can just drop gccgo-go
[10:19] <jamespage> I'm all up for that - it was a temporary hack I was never that happy with
[10:21] <doko> jamespage, so both go and gofmt are handled by alternatives?
[10:22] <jamespage> let me check
[10:22] <jamespage> I think it might just be go
[10:28] <flexiondotorg> Morning
[10:29] <flexiondotorg> pitti, dholbach Just wanted to say thanks for your help getting Ubuntu MATE official.
[10:29] <flexiondotorg> You went online last night when I thanked the others.
[10:29] <flexiondotorg> Oh, and didrocks. Thanks.
[10:29] <flexiondotorg> https://ubuntu-mate.org/blog/ubuntu-mate-vivid-beta1/
[10:29] <dholbach> thanks a lot for working on Ubuntu MATE :-)
[10:30] <dholbach> great work!
[10:30] <pitti> flexiondotorg: ^5s, great work!
[10:31] <didrocks> you're welcome flexiondotorg, nice work on Ubuntu MATE! ;)
[10:31] <darkxst> hey flexiondotorg
[10:31] <flexiondotorg> darkxst, 'sup?
[10:32] <darkxst> flexiondotorg, winding down for the night, built a deck today so a little sore
[10:34] <jamespage> doko, just go atm
[11:01] <doko> jamespage, can we do that for gofmt too, or isn't that installed by golang?
[11:18] <xnox> hallyn: where is shadow upstream?
[11:32] <Mirv> pitti: is that the bot of yours or are you manually rekicking autopkgtest jobs? thanks, regardless of which :)
[11:33] <pitti> Mirv: it's the jenkins -> imap -> mutt -> pitti -> jenkins pipeline :)
[11:33] <Mirv> oh, that automation :)
[11:33] <pitti> our CI machines are melting again, and we get the usual random fallout
[11:45] <mardy> pete-woods: hi! Do I understand correctly, that libqtdbusmock is something that makes it easier to use python-dbusmock from Qt apps?
[11:46] <mardy> pete-woods: I'm having a look at the code, but despite seeing python3-dbusmock in the deps, I don't find where it's using it
[12:21] <pete-woods> mardy: there are two related libraries. libqtdbusmock and libqtdbustest. the former makes talking to dbusmock easier, while the latter simplifies testing dbus stuff in Qt much easier
[12:23] <pitti> tseliot: hm, ubuntu-drivers-common's tests recently started to fail on the -304 versions; are you aware of any recent changes there?
[12:25] <pete-woods> mardy: each time you register a mock in qtdbusmock, it registers a binary, and associated dbus stuff to look for against libqtdbustest
[12:25] <pete-woods> so it's actually the test lib that starts dbusmock
[12:25] <pete-woods> but the mock lib that configures it
[12:27] <tseliot> pitti: maybe I forgot to patch it to work with linux 3.19. That would explain it (if you're talking about vivid)
[12:27] <pitti> tseliot: yes, vivid
[12:27] <pitti> tseliot: ah, could have been triggered by the new kernel, indeed
[12:27] <tseliot> pitti: I'm trying to install it in my chroot to see if I can reproduce the problem
[12:29] <pitti> tseliot: note the new kernel is still in vivid-proposed
[12:29] <pete-woods> mardy: http://bazaar.launchpad.net/~unity-api-team/indicator-network/integration-testing/view/head:/tests/integration/indicator/TestIndicatorNetworkService.cpp is a reasonably detailed example of usage
[12:29] <tseliot> pitti: is it possible that we are getting the failure from vivid-proposed?
[12:29] <pitti> tseliot: yes, we run all tests in -proposed
[12:30] <pitti> tseliot: we want to detect regressions in -proposed already after all, not only when they already landed
[12:30] <pitti> ... usually
[12:30]  * pitti waves at binutils and sighs
[12:31] <pete-woods> mardy: http://bazaar.launchpad.net/~indicator-applet-developers/hud/trunk.15.04/view/head:/tests/unit/service/TestVoice.cpp is a simpler example, with more usage of the dbusmock interface
[12:31] <tseliot> pitti: ok, good, that's what I remembered but I wasn't sure
[12:33]  * tseliot -> lunch
[13:10] <mardy> pete-woods: thanks a lot, that's very useful!
[13:14] <diwic> Hi. It seems PulseAudio 1:6.0-0ubuntu4 is stuck in proposed? I thought this was due to beta freeze, but the beta freeze should be over, and thus PA should migrate to the release pocket?
[13:15] <pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#pulseaudio
[13:15] <pitti> looks like another jenkins hiccup, I restarted fluidsynth
[13:15] <diwic> pitti, ok, thanks
[13:19] <infinity> pitti: While people are being whiney about autpkgtest, the public mirror sure seems to be laggy...
[13:20] <pitti> retoaded, psivaa_ ^ that's something I can't help with; can you?
[13:21] <pitti> publishing queue of public jenkins?
[13:23] <infinity> pitti: I assume (hope?) that in the magical jenkins-free debci future, this will all be real-time via a public interface, instead of the user-hostile private/public split?
[13:23] <pitti> infinity: yes, should be; the cloud will save us all (famous last words..)
[13:26] <psivaa_> pitti: i've resurrected publisher plugin, i'll also watch it for some time
[13:26] <pitti> psivaa_: thanks
[13:37] <hallyn> xnox: github.com/shadow-maint/shadow
[13:38]  * hallyn mostly afk today - \o
[13:38] <xnox> hallyn: why that history is disjoint from git://anonscm.debian.org/pkg-shadow/shadow.git ?
[13:39] <hallyn> bc that one is the packaging tree.  (used to be separate mercurial branches)
[13:41] <hallyn> xnox: i thought there was a new github.com/shadow-maint tree for that one, buti don't see it...  hm
[13:42] <xnox> hallyn: i'll send patches to both, and mailing list.... i guess....
[13:44] <hallyn> xnox: thx.  i'll be back in on monday;  we can discuss more then if you like, especially if you have time/inclination to help out :)
[13:44] <hallyn> (the maintainers are pretty busy)
[13:48] <xnox> hallyn: i have a bunch of patches....
[13:52] <hallyn> cool.  i can help review and push upsream, but i don't touch the packaging tree
[13:53] <hallyn> anyway, i'll be in on monday - ttyl
[13:54] <rbasak> cjwatson: I've just come across bug 669481 and 872244 and am concerned about the default server headless case. utlemming thinks that you had a concern about desktop so didn't want to change the default.
[13:55] <rbasak> (this is about GRUB_RECORDFAIL_TIMEOUT)
[13:55] <rbasak> cjwatson: do you remember what the concern was please? I can't find any record of it.
[14:11] <infinity> rbasak: I ran into that with my parents' firewall a coulpe of months ago and had a conversation with Colin about it where, I *think* we concluded that an infinite timeout is bad, *but* the proper solution should probably involve a loop counter.
[14:14] <rbasak> infinity: in the shorter time, how about 30 or 60 seconds or something? Definitely on headless servers. I don't mind about desktops.
[14:14] <rbasak> shorter term
[14:15] <rbasak> infinity: it this necessitates server being different from desktop, I'd like to sort that out. I feel quite strongly that this is a critical bug in server LTS releases.
[14:15] <infinity> rbasak: I think the conversation (and the right answer) applies to both, TBH.  I don't really want to see a forked config here based on some heuristic about what a "server" is.
[14:16] <infinity> rbasak: Check, say, Win7/8, where a failed boot or unclean shutdown will present you with a menu with a 30s timeout.  I suspect most people think this is reasonable.
[14:16] <rbasak> infinity: so we can just set GRUB_RECORDFAIL_TIMEOUT=30 by default, no?
[14:17] <infinity> rbasak: But, ideally, we also don't want people in an infinite reboot loop either, which could happen with the right sort of breakage.
[14:17] <infinity> rbasak: But yeah, I think catering to the edge "what if there's a loop" case is probably being obtuse, and setting the timeout to 30 is probably a good first step.
[14:18] <cjwatson> rbasak: I'm afraid I don't remember the details.  I may have been acting under instructions from design or something.
[14:19] <rbasak> cjwatson: OK, no worries. Any objection to setting the default to 30 in Vivid now?
[14:19] <cjwatson> rbasak: 30s doesn't seem unreasonable, but please don't change the default config file if you can possibly avoid it to avoid potential upgrade prompts; it can be changed in 00_header instead.
[14:19] <cjwatson> rbasak: My only objection would be if it were done in an Ubuntu patch, rather than changing it in Debian.
[14:19] <rbasak> OK
[14:19] <cjwatson> Since it took me literally years to get the packages back in sync ...
[14:20] <cjwatson> (I haven't been able to find any record of this past conversation in my IRC logs.)
[14:20] <cjwatson> rbasak: If somebody sends me a patch I'd be happy to integrate it into the packaging in unstable.
[14:21] <rbasak> cjwatson: OK thanks. I'll see what I can do.
[14:21] <cjwatson> Don't worry too much about it being in exactly the right form, since it'll need to be several items deep in a git-dpm stack anyhow.
[14:21] <infinity> cjwatson: The conversation that led to the current behaviour, or the conversation with a grumpy me when I ran into it? :P
[14:21] <cjwatson> I just want something tested to have the right kind of behaviour.
[14:21] <cjwatson> infinity: The one utlemming thinks I had with them.
[14:22] <infinity> Or that.
[14:22] <cjwatson> Could've been at a sprint, I guess.
[14:22] <rbasak> utlemming thinks there was a reason that the default wasn't set to something positive in the first place.
[14:22] <infinity> cjwatson: Anyhow, I vaguely recall you and I agreeing that the current default was crap, but I don't recall if we mapped out what we thought the Right Thing was.
[14:22] <cjwatson> The best guess I have would have been concerns about infinite reboot loops, or possibly something to do with picking an appropriate default.
[14:22] <infinity> But a 30s delay seems like an okay compromise for now.
[14:23] <cjwatson> (that people could react to in reasonable time, since most people read slower than geeks who've seen the boot screen a thousand times)
[14:23] <cjwatson> But, hey, if it's wrong for everyone, I don't have a problem with trying a change.
[14:24] <infinity> I don't think "infinite" or "long enough to read all the text on the screen" are appreciably different for desktop users, especially when most of them will hit <enter> without reading it anyway.
[14:25] <infinity> And infinite is clearly wrong for unattended rebooting.
[14:25] <infinity> cjwatson: Oh, I remember how I was bitten by this.  Brownouts.  Machine bounced twice in under a minute, and the second one killed it.
[14:25] <cjwatson> Yeah, that'd do it
[14:25] <infinity> cjwatson: Which seems like a not unlikely scenario for power loss in general.
[14:26] <rbasak> That fits my understanding. Second failure after grub but before /etc/init.d/grub-common runs.
[14:30] <infinity> rbasak: That exact scenario on a Windows machine (for instance) will land you at either a 30s or 60s (I think 30, but I'd have to bounce a machine to see) timeout that says "we failed to boot completely on the last attempt, how do you feel about maybe trying safe mode?"
[14:32] <infinity> Ahh, youtube to the rescue, it's 30s.
[14:33] <infinity> rbasak: https://www.youtube.com/watch?v=WcLDch_OO3k#t=110 <-- For reference.
[14:33] <infinity> rbasak: And they have a fair bit of text to read, so I think 30s would be fine for us.
[14:33] <infinity> cjwatson: ^
[14:35] <infinity> Now, the difference is that they default to "recovery mode", and I think that would still be wrong for us, since our recovery mode doesn't have networking.
[14:35] <infinity> Or startup repair, even.  Which we don't have.
[14:36] <rbasak> Our most likely failure mode is a kernel upgrade.
[14:37] <rbasak> So ideally maybe default to the last known working kernel? That sounds non-trivial though.
[14:48] <pitti> doko: FYI, http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-zope.session/8/ARCH=amd64,label=adt/console now fails because van.pydeb's module doesn't import "re"
[14:49] <doko> pitti, ouch!
[14:54] <xnox> pitti: nice catch =)
[14:56] <aeoril> I am trying to debug apport, so I have made a small application that just SIGSEGVs itself.  I have checked and apport seems to be fully enabled on trusty.  Why might this not bring up apport? https://gist.github.com/aeoril/7d2538d3db393d4b28a3
[14:56] <mardy> pitti: hi! About python-dbusmock: I'm adding a method which returns "a(ua{sv})", but I'm not sure how to code the return value ("ret = ...")
[14:56] <mardy> pitti: should I use GVariant, or just python types?
[15:01] <pitti> aeoril: probably because it's not a packaged application
[15:01] <pitti> aeoril: check /var/log/apport.log
[15:01] <pitti> aeoril: my favourite crash test is to call sh -c 'kill -SEGV $$'
[15:02] <pitti> aeoril: that'll create a report for dash
[15:02] <aeoril> pitti ok, thanks - what is dash?
[15:03] <pitti> aeoril: our default /bin/sh; you can also call bash -c ... of course, if you prefer
[15:03] <pitti> mardy: there is no automatic conversion, this is using dbus-python
[15:03] <aeoril> pitti ok, got it - thanks!  That will really help I am sure!
[15:04] <pitti> mardy: so you have to return something like dbus.Array([], signature='v')
[15:04] <aeoril> pitti just out of curiosity, what do the $$s do on that line?
[15:04] <pitti> aeoril: it's a magic variable whose value is the current pid
[15:05] <aeoril> pitti I figured, but was just checking - thanks!
[15:05] <pitti> aeoril: i. e. that starts a shell, and sends a SIGSEGV signal to itself
[15:05] <aeoril> gotcha! :)
[15:05] <mardy> pitti: ok, thanks
[15:06] <aeoril> pitti worked like a charm! :) thanks!
[15:26] <doko> pitti, van.pydeb in -release
[15:27] <pitti> doko: zope.session running
[15:29] <Laney> doko: do you know how to fix https://bugs.launchpad.net/ubuntu/+source/terminator/+bug/1426294 ?
[15:30] <doko> Laney, no, hoped for pitti ... in the worst case, we'll have to revert the upstream python fix
[15:30] <doko> but it's in the 3.4.3 release too
[15:31] <pitti> Laney: oh -- git-buildpackage screams the same thing at me now when it tries to notify me
[15:31] <pitti> python? that rather looked like "new glib" or so? but I haven't investigated it at all yet
[15:32] <pitti> doko: http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-zope.session/9/ green!
[15:32] <pitti> thanks
[15:32] <pitti> that shold clear setuptools
[15:33] <pitti> Laney, doko: btw, "gio" isn't introspection, it's the old static bindings
[15:33] <Laney> indeed
[15:34] <doko> hmm
[15:49] <lamont> why is it that my dist-upgrade today has cause ctl-alt-T to stop launching a terminal?
[15:49] <lamont> (yes, vivid)
[15:50] <Laney> what terminal emulator?
[15:52] <lamont> terminator, actually
[15:53] <Laney> see immediately above
[15:53] <lamont> interestingly, right-click, "open terminal" works just fine
[15:53] <pitti> hm, still works here
[15:53] <Laney> did you get new python?
[15:53] <pitti> but I dist-upgraded this morning (11 hours ago)
[15:54] <pitti> Laney: python2.7? or literally the metapackage?
[15:54] <pitti> Laney: I do have teh broken gio bits, if that's the same
[15:54] <Laney> I think 2.7, just trying to downgrade now to check
[15:54] <lamont> 2.7.9-1ubuntu1
[15:54] <pitti> also works in a guest session
[15:55] <pitti> lamont: got that
[15:55] <Laney> changelog mentions this identified upstream bug
[15:55] <lamont> I want to say that it's gtk2 vs 3 or some such ancient crack
[15:55] <attente_> hi, has anyone tried using Qt5LinguistTools in a cmake file? i'm encountering https://bugs.launchpad.net/ubuntu/+source/qttools-opensource-src/+bug/1292986, but it says that the fix was released
[15:55] <lamont> (handwavy half-recollection of a previous discussion about terminator not having migrated to some new rev of something, about a year ago)
[15:56] <lamont> and by "about" I mean give or take 6-12 months
[15:58] <Laney> http://paste.ubuntu.com/10450739/
[15:58] <Laney> (& happy terminator)
[16:04] <lamont> Laney: what all debs did you reinstall?
[16:05] <Laney> lamont: enough of these guys to please dpkg https://launchpad.net/ubuntu/+source/python2.7/2.7.9-1/+build/6635827
[16:05] <lamont> ok
[16:05] <Laney> libpython* python2.7 python-minimal
[16:06] <lamont> sadly, terminator became somewhat less useful to my workmodel when changing font size meant that it went bug-nutso if you created a new tile.
[16:06] <lamont> my remaining question is wtf happened to my window manager at the home machine
[16:06] <lamont> what passes for a top-bar is nothing but the nautilus menu
[16:07] <lamont> s/menu/topbar/
[16:07] <lamont> and none of the shortcuts seem to interest the computer anymore
[16:08] <lamont> current plan is to see if a reinstall makes it happier
[16:08] <lamont> (sving the old root, of course)
[16:16] <Odd_Bloke> How can I see what IP address apt-get is resolving archives to?
[16:22] <doko> Laney, pitti: should we revert this one bug fix for now? if yes, please do it. I'll have to leave soonish
[16:23] <Laney> doko: I have NFC about python modules so there's not much chance I can fix pygobject-2
[16:23] <doko> Laney, no, revert the fix that one issue in python2.7
[16:24] <Laney> Yeah, but I'm guessing that a real fix is preferable
[16:24] <Laney> Happy to revert in the meanwhile though
[16:24] <doko> sure
[16:26] <Laney> see if pitti has a bright idea, otherwise I'll do that before EODing
[16:55] <doko> Laney, leave me a message on irc, will be back very late tonight
[17:16] <flexiondotorg> Is there anyone here who would sponsor the update of a couple of package for Ubuntu MATE?
[17:16] <flexiondotorg> One is the meta package, the other is the settings.
[17:29] <flexiondotorg> infinity, Could you update a couple of packages for me?
[17:36] <aeoril> I am trying to figure out how to build apport from source (bzr branch lp:apport).  I saw "setup.py" and looked at it and it looked like a likely suspect.  I ran it, but got this error and am not sure where to go from here:  https://bugs.launchpad.net/ubuntu/+source/apport/+bug/348250 Google search unfortunately led me nowhere
[17:36] <aeoril> oh, I guess that is fixed now
[17:37] <aeoril> nm, i was confused by the ubottu message - it is not fixed yet
[17:37] <aeoril> pitti ^
[17:38] <aeoril> whoops, I meant to link to my gist:  https://gist.github.com/aeoril/4084dc205732a553044c not just the bug report
[17:39] <aeoril> (and that was the wrong bug report anyway)
[17:41] <flexiondotorg> Could someone please tell me what the correct merge target for indicator-sound is please?
[17:41] <flexiondotorg> Because I've just generate a massive MP from just a couple of lines change?
[17:41] <flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/indicator-sound/mate/+merge/251295
[17:42] <cjwatson> the correct merge target is typically whatever you branched from in the first place.
[17:42] <aeoril> flexiondotorg uggghh - that happened to me!
[17:42] <flexiondotorg> cjwatson, I branched from lp:indicator-sound and tried to merge back to it.
[17:42] <cjwatson> No, you didn't
[17:42] <cjwatson> You branched from lp:ubuntu/indicator-sound
[17:43] <flexiondotorg> Ooops.
[17:43] <cjwatson> But I'm pretty sure that's not used; I suggest rebranching from lp:indicator-sound and reapplying your change
[17:43] <flexiondotorg> I'm an idiot.
[17:43] <flexiondotorg> cjwatson, Thanks.
[17:43] <flexiondotorg> I need a drink.
[17:43] <aeoril> flexiondotorg you are not an idiot :)
[17:43] <cjwatson> lp:indicator-sound is AFAIK the usual merge target
[17:46] <Laney> doko: uploading it
[17:50] <alexbligh1> packaging question: I have a package X, that depended on a package foo-open-isci, which was an alternate build of open-iscsi. I now want to bring in stock open-iscsi instead. So I have made X' (new version of X) depend on a transitional package T, T depends on open-iscsi, and Conflicts, Provides, Replaces, Breaks foo-open-iscsi. However, as the two open-iscsi packages contain the same files, dpkg complains it c
[17:50] <alexbligh1> an't overwrite files in foo-open-iscsi with a file from open-iscsi of the same name. I thought Breaks: was meant to ensure foo-open-iscsi was removed first, but perhaps that only ensures it is removed before T is installed, not T's dependencies. Any ideas?
[18:01] <aeoril> oh, its python - I don't compile it, I guess
[18:12] <Noskcaj> xnox, Is there anything in particular i should be doing to get a +1 from you for MOTU?
[18:20] <aeoril> pitti you around?  I have been dinking all around the apport source from lp:apport and just cannot figure out how to test the gui.  I am trying to fix:  https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1422176 and beleive I already know how to fix it (seems simple) but have no idea how to test my changes.  Would you be willing to help me with this fix?
[18:25] <aeoril> pitti oh, I think I see how to test - change them live in the installed directory, then test them, then update the source branch ... does that sound reasonable?
[20:05] <smoser> slangasek, https://launchpadlibrarian.net/195014257/cloud-init_0.7.7%7Esnappy%7Ebzr1045-0ubuntu2_0.7.7%7Esnappy%7Ebzr1045-0ubuntu3.diff.gz
[20:05] <smoser> is that appropriate for cloud-init upstream ?
[20:07] <smoser> you had previously submitted systemd-user-sessions.service
[20:08] <smoser> ah. nevermind. i see that you fixed with systemd-user-sessions.service


[07:27] <Cimi> morning guys
[07:33] <tsdgeos_> Cimi: morning
[07:33] <tsdgeos_> fginther: did you have time to check why all qmluitests are failing?
[07:33] <tsdgeos_> Saviq: so was the code review i did for unsplit enough or are you guys expecting more?
[07:34] <Saviq> tsdgeos_, go for it
[07:34] <tsdgeos_> Saviq: also can we get a silo with paul's logout branch + all the things we need?
[07:34] <Saviq> tsdgeos_, yeah, will take care of that soon
[07:34] <tsdgeos_> Saviq: i already went for it yesterday :D Not sure if people blocked on me just because i didn't top approve or not though
[07:35] <Saviq> tsdgeos_, basically no one else reviewed it
[07:35] <Saviq> I tried, but couldn't focus...
[07:35] <tsdgeos_> well, i just diffed this one and the other one and made sure they were 1:1 changes
[07:36] <Saviq> tsdgeos_, good enough
[07:36] <tsdgeos_> also the regular packaging is failing for some reason in CI
[07:36] <tsdgeos_> works here
[07:37] <tsdgeos> Saviq: so i'll approve from my side, and if you want top approve too
[07:38] <Saviq> tsdgeos, yup, do that
[07:43] <Cimi> Saviq, tsdgeos I was thinking of working from 8-8:30 in summer... shifting a bit, you would prefer?
[07:44] <Saviq> Cimi, sounds kinda short ;)
[07:44] <Cimi> ahahah
[07:44] <Cimi> Saviq, basically CEST
[07:44] <Saviq> Cimi, yeah, I see no reason why not
[07:44] <Saviq> Cimi, but you have to check with Kevin
[07:44] <Cimi> Saviq, sure of course
[07:45] <Cimi> Saviq, ola wakes me up at 7ish... then instead lying in bed like a zombie for another hour I should start working earlier i thought
[07:47] <Saviq> Cimi, ;)
[07:48] <Cimi> Saviq, waiting your mail about qtcs :)
[07:48] <tsdgeos> easy one https://code.launchpad.net/~aacid/unity8/no_preview_in_preview_title/+merge/223027
[07:49] <Saviq> tsdgeos, + .pot
[07:49] <tsdgeos> damn
[07:49] <tsdgeos> there's never an easy one :D
[07:50] <tsdgeos> and we didn't ever get teh pot file generation to be stable
[07:50] <tsdgeos> grr
[07:50] <tsdgeos> zillions of unneeded changes
[07:51] <Saviq> tsdgeos, "stable"?
[07:51] <Saviq> tsdgeos, the unneeded changes are probably mostly line number changes?
[07:51] <tsdgeos> no
[07:51] <tsdgeos> the globbing in my hd is different than in yours
[07:51] <tsdgeos> so qml/Components/PassphraseLockscreen.qml gets repositioned in the file
[07:51] <tsdgeos> see http://paste.ubuntu.com/7637686/
[07:52] <Saviq> huh
[07:52] <Saviq> that's interesting...
[07:52] <tsdgeos> ah wait
[07:52] <tsdgeos> no
[07:52] <tsdgeos> it's a different file name
[07:52] <Saviq>  test.qml:7
[07:52] <tsdgeos> so it's the same string but the file was renamed
[07:52] <Cimi> tsdgeos, you got my message here? https://code.launchpad.net/~aacid/unity8/obeyArtShapeFixedSize/+merge/222294
[07:53] <Saviq> tsdgeos, maybe base on unsplit? the changes should be smaller there I think?
[07:53] <Cimi> I based on unsplit the infographics
[07:53] <tsdgeos> Saviq: probably, ok let me do that
[07:59] <tsdgeos> Saviq: ok, so it's smaller diff https://code.launchpad.net/~aacid/unity8/no_preview_in_preview_title/+merge/223029
[07:59] <tsdgeos> Cimi: ok, i see what you mean, will try to do that
[07:59] <Saviq> tsdgeos, kk
[08:18] <tsdgeos> Saviq: ok, approved the unsplit branch
[08:20] <Saviq> tsdgeos, tx
[08:35]  * Saviq needs to spend the day catching up on email :|
[08:35] <Cimi> Saviq, right click -> mark all as read
[08:35] <Saviq> Cimi, yeah, not gonna fly ;P
[09:18] <Cimi> Trevinho, I still have bad crashes with unity on my laptop
[09:18] <Cimi> is there a bugreport?
[09:35] <tsdgeos> Cimi: test added
[09:41] <Cimi> tsdgeos, tested test... indeed failing without your branch, good
[09:56] <Cimi> tsdgeos, would still prefer to have another look by Saviq
[09:57] <Cimi> tsdgeos, seems quite nested in terms of connections and variables
[09:57] <tsdgeos> +1
[09:58] <Cimi> tsdgeos, found mistake
[09:58] <Cimi> root.fixedArtShapeSize.height / root.fixedArtShapeSize.height
[09:59] <tsdgeos> wops
[10:01] <tsdgeos> Cimi: fixed
[10:02] <Cimi> tsdgeos, shall we also check it is not 0?
[10:02] <Cimi> root.fixedArtShapeSize.height
[10:02] <tsdgeos> i can change != -1 to >= 0
[10:02] <tsdgeos> if you want
[10:03] <tsdgeos> this is javascript so dividing by 0 won't crash anything
[10:03] <tsdgeos> but still will make things go weird
[10:03] <tsdgeos> otoh if we're setting fixedShapeArtSize to be 0
[10:03] <tsdgeos> something is wrong somewhere elese
[10:04] <Cimi> tsdgeos, so > 0
[10:04] <Cimi> not >+
[10:04] <Cimi> >=
[10:04] <tsdgeos> right
[10:04] <Cimi> in cardtool we have
[10:04] <Cimi> readonly property size artShapeSize: cardLoader.item ? cardLoader.item.artShapeSize : 0
[10:05] <Cimi> again code is quite nested so is confusing a bit
[10:05] <tsdgeos> yeah
[10:05] <tsdgeos> but it's a loader
[10:05] <tsdgeos> it will have stuff
[10:05] <tsdgeos> except in the startup
[10:05] <Cimi> okl
[10:05] <tsdgeos> but sure, will make it > 0
[10:05] <tsdgeos> noone will get hurt
[10:06] <tsdgeos> pfff
[10:06] <tsdgeos> or not
[10:06] <Cimi> hah
[10:06] <tsdgeos> we already had code that was using -1
[10:06] <tsdgeos> as condition
[10:06] <tsdgeos> now i either change it all
[10:07] <tsdgeos> and then i'm making changes not related to this bugfix
[10:07] <tsdgeos> or end up with code that sometimes checks for -1 and sometimes for >0
[10:07] <Cimi> talk to Saviq when he finished mails
[10:07] <Cimi> to me doing division and not checking for 0 is a mistake
[10:08] <Cimi> ok it's javascript, but we should handle those cases
[10:12] <Saviq> Cimi, I don't have to be a tie-breaker here, just use reason
[10:14] <Cimi> tsdgeos, can we change to > 0 then?
[10:16] <tsdgeos> done
[10:26] <Cimi> tsdgeos, tests too
[10:27] <tsdgeos> Cimi: right
[10:31] <Saviq> tsdgeos, Cimi, the mistake you found, do we have a test for that?
[10:32] <tsdgeos> Saviq: test_art_shape_fixed_size
[10:33] <Saviq> tsdgeos, so when you fixed that, you added more test?
[10:34] <tsdgeos> Saviq: i'm confused :D
[10:34] <tsdgeos> Saviq: what is exactly that in "test for that"?
[10:34] <Saviq> tsdgeos, "<Cimi> tsdgeos, found mistake
[10:34] <Saviq>  root.fixedArtShapeSize.height / root.fixedArtShapeSize.height"
[10:35] <tsdgeos> Saviq: no, we don't have a test except the test that make sure the output is verbatim correct
[10:36] <tsdgeos> Saviq: tbh i don't know how to create a test for that
[10:37] <Saviq> tsdgeos, mhm :|
[10:39] <Cimi> tsdgeos, you check the result of that property?
[10:40] <Cimi> fixedArtShapeSizeAspect
[10:41] <tsdgeos> yeah
[10:41] <tsdgeos> i guess i can
[11:31] <tsdgeos> aaaaaaaaaaand we are unsplit
[11:33] <Saviq> tsdgeos, ok, I'll prep silo, any reason to separate the logout?
[11:34] <Saviq> or should we just land our current queue + logout?
[11:35] <tsdgeos> Saviq: well, logout needs lots of other stuff to land at the same time
[11:35] <tsdgeos> Saviq: and i'm not even sure it works
[11:35] <Saviq> tsdgeos, mhm ok
[11:36] <tsdgeos> that's why i want a silo so it can be properly tested
[11:36] <tsdgeos> last time i did try didn't work again
[11:36] <tsdgeos> but i may have failed at compiling all the repos properly
[11:37] <Saviq> ok, I'll ask for two silos thne
[11:38] <seb128> Saviq, tsdgeos: there is only an indicator-session commit to include with it, maybe put it in the same silo?
[11:39] <tsdgeos> seb128: and  lp:~aacid/unity8-desktop-session/fix_logout  at least
[11:39] <seb128> tsdgeos, that's already in https://launchpad.net/~ci-train-ppa-service/+archive/landing-008/+packages
[11:40] <tsdgeos> ok
[11:40] <tsdgeos> it's a bit sad there's no way to know that
[11:40] <Saviq> tsdgeos, sure there is http://people.canonical.com/~rbpark/citrain/
[11:40] <tsdgeos> Saviq: but i need to go there and f5 stuff every second
[11:40] <Saviq> seb128, so maybe we should just add the logout to that silo instead?
[11:40] <Saviq> tsdgeos, it f5s for you automagically ;)
[11:41] <Saviq> tsdgeos, and then there's #ubuntu-ci-choo-choo
[11:41] <Saviq> tsdgeos, where you can talk to CI-SNCF
[11:41] <seb128> Saviq, we had the logout in a silo earlier in the week and had to clear it out because the unity8 side was not landed and we couldn't test it
[11:41] <tsdgeos> Saviq: it'd be much better imho if it could be a push method in which the MR gets a comment saying "this has been added to silo XYZ" than me having to listen to side channels
[11:41] <seb128> Saviq, oh, you mean adding unity8 in that silo? that would lock your other landing no?
[11:41] <Saviq> seb128, is fine, we should just land it then ;)
[11:41] <seb128> yeah
[11:42] <Saviq> seb128, nothing very pressing in my queue yet either
[11:42] <seb128> Saviq, and even if it's not fully working or tested, as long as it create no regression
[11:42] <seb128> I would just include it
[11:42] <Saviq> seb128, just get it in
[11:42] <Saviq> or I can for that matter
[11:42] <seb128> yeah, please include the unity8 change
[11:43] <tsdgeos> meh
[11:43] <tsdgeos> doesn't merge anymore
[11:43] <tsdgeos> paulliu: https://code.launchpad.net/~paulliu/unity8/logout/+merge/216373 needs remerging
[11:44] <Saviq> paulliu, you around to merge ↑?
[11:47]  * Saviq resubmits under unity-team then
[11:48] <paulliu> Saviq: ok.
[11:51] <Saviq> paulliu, oh you're here, please merge and let me know
[12:16] <paulliu> Saviq, done.
[13:03] <Saviq> paulliu, thanks
[13:04] <dandrader> paulliu, did you clean up the CMakeLists.txt there as well?
[13:07] <paulliu> dandrader: yes. cleaned
[13:08] <dandrader> paulliu, you missed plugins/Unity/Session/CMakeLists.txt
[13:10] <paulliu> dandrader: ok..wait
[13:14] <paulliu> dandrader: done.
[13:23] <Saviq> karni, you asked about depts (somewhere...), best to follow bug #1320847
[13:23] <karni> Saviq: aha. this bug is used to track progress on departments I gather? :D
[13:24] <Saviq> karni, it *can* be used for that, yes
[13:24] <karni> subscribed, thanks!
[13:25] <karni> mhr3: has ETA (for this week) changed for departments, or you guys still plan to wrap some work today? no rush, just asking.
[13:27] <mhr3> karni, definitely not today
[13:27] <mhr3> we're breaking abi, so it's all waiting for more changes
[13:28] <karni> mhr3: Is there a chance to have it next week? How's the work coming along?
[13:30] <mhr3> karni, yes, next week is the target
[13:30] <karni> thanks
[14:10] <Saviq> mhr3_, tsdgeos is of the opinion we shouldn't touch Scopes much, either
[14:10] <Saviq> mhr3_, here's what Albert wrote about the "needs" http://paste.ubuntu.com/7638985/
[14:11] <Saviq> mhr3_, tsdgeos, I'm just not sure of the "includes all, also invisible ones" is needed, though
[14:12] <Saviq> as long as we can get(QString name) (which we actually can already)
[14:13] <tsdgeos> Saviq: yeah i'm unsure on that, i thought it'd be easier "for the world" if Scopes would include all the Scope objects
[14:13] <Saviq> tsdgeos, I don't think it does, even now
[14:13] <tsdgeos> since it'd be weird doing a get("hardocdedNameForScopesScope")
[14:13] <Saviq> tsdgeos, waste of mem
[14:13] <tsdgeos> if Scopes doesn't have it
[14:13] <tsdgeos> but if it is not like that now
[14:13] <tsdgeos> i totally can live without that :D
[14:13] <Saviq> tsdgeos, that depends on the definition of what model Scopes is, really
[14:14] <tsdgeos> Saviq: sure, if it doesn't include visible scopes, we might as well remove that role and the proxymodel that makes sure only visible ones are shown :D
[14:14] <Saviq> you could say Scopes is an "entry-point" to the scopes system (which it kind of is), and a model of favourite scopes
[14:14] <Saviq> tsdgeos, I think we should, yes
[14:14] <Saviq> tsdgeos, this feels legacy (pre-new-scopes) actually
[14:14] <tsdgeos> maybe :)
[14:15] <tsdgeos> mhr3_: comments on ↑ ?
[14:30] <pdo_fn14> Okay, let me see. I know everything in here want to porting the biggest revolution Unity 8, but will it be only-default option to using that?.
[14:33] <pdo_fn14> It's totally unclear and confusing my head always.
[14:42] <mhr3_> tsdgeos, i like the idea of keeping Scopes and adding ScopesOverview
[14:43] <tsdgeos> mhr3_: oh, ScopesOverview in that document is something in my side :D, in you side it would just be ScopesScope
[14:43] <mhr3_> but seeing how special the scopes scope is, i'm not sure if regular cards is enough there
[14:43] <Saviq> mhr3_, they are built with the toolkit, they're regular cards
[14:43] <tsdgeos> but we can also make Scopes have a Scopes::getOverview instead of doing Scopess::get("harcodedName")
[14:44] <mhr3_> yea, detail
[14:44] <mhr3_> Saviq, hmm...
[14:44] <mhr3_> Saviq, it's more about the interactions though
[14:44] <mhr3_> Saviq, for example what happens when you tap on a scope in all?
[14:45] <Saviq> mhr3_, you tell me ;)
[14:45] <mhr3_> does that open new temp dash page and pan to it?
[14:45] <Saviq> mhr3_, but I believe we open that scope in the dash and zoom in again
[14:45] <mhr3_> when does it disappear?
[14:45] <Saviq> mhr3_, opening a scope always takes you back to the dash
[14:45] <mhr3_> when you do the zoom out?
[14:46] <Saviq> mhr3_, on bottom edge again
[14:46] <Saviq> mhr3_, but that's a question I did ask (what does the back button do in non-favourite scope)
[14:46] <mhr3_> should it even have a back button?
[14:47] <Saviq> mhr3_, please read/add comments under https://sites.google.com/a/canonical.com/unity8dash/dash-overview
[14:47] <mhr3_> yea, kinda didn't scroll all the way down :)
[14:51] <Saviq> mhr3_, but also, we'll be displaying smart scope results in the "all" category, so those need to be cards
[14:51] <Saviq> mhr3_, only real thing we don't have is the horizontal list in Favourites
[14:51] <mhr3_> indeed
[14:52] <Saviq> mhr3_, but that we can make custom no issue
[14:52] <mhr3_> i wonder where do the icons come from
[19:36] <lborda_> quit


[05:33] <micahg> mr_pouit: if/when you upload to ristretto to Debian, can you switch to xz compression?
[10:18] <knome> datetime shows sunday first and no way to change? :(
[11:37] <astraljava> datetime?
[11:37] <astraljava> You're already married, there's no place for dating for you anymore.
[12:26] <knome> :P
[12:28] <knome> i'm announcing a meeting for next week
[12:34] <knome> done
[16:09] <mr_pouit> micahg: I'm not a dd :P Anyway, I can switch things in svn, and ask Corsac to upload. Does ristretto greatly benefit from xz compression? (we can switch more packages before FF)
[16:15] <pleia2> updated calendar
[16:50] <knome> mr_pouit, xz compression? huhu?
[18:41]  * micahg tries compressing ristretto with xz
[18:47] <micahg> mr_pouit: ristretto saves ~60k which is about 25%
[18:48] <micahg> mr_pouit: can we recompress everything with xz (or at least anything we upload between now and release?
[18:49] <micahg> mr_pouit: although, this only affects the alternates mainly, we're still up a creek with the desktop image since it's all in squashfs
[18:50] <micahg> mr_pouit: maybe discuss with corsac first before changing though, it won't make much of a difference anyways (I think we can work around the alternates without changing the xfce packages)


[00:08] <geozach> Hello, im having issues installing stem. any help would be greatly accepted. ( im new to Linux)
[00:08] <geozach> *steam
[00:32] <sixwheeledbeast> what issues?
[00:53] <pedro_> solution to meltdown menace ?
[00:54] <pedro_> someone ?
[00:54] <pedro_> hello ?
[02:35] <jack_> Hi everyone, I'm new to Ubuntu Mate. Nice to meet you all.
[07:20] <ReichtangleAnsch> lol
[07:20] <ReichtangleAnsch> lol
[07:20] <ReichtangleAnsch> lol
[07:20] <ReichtangleAnsch> lol
[07:20] <ReichtangleAnsch> lol
[08:00] <def4l7> hi
[08:01] <diogenes_> hi
[08:02] <TaZeR> greetings my friends
[08:02] <TaZeR> welcome to ubuntu-mate the greatest distro on the planet!
[08:03] <diogenes_> TaZeR, same thing you said about manjaro.
[08:03] <def4l7> i wanna ask u few questions about distro
[08:03] <diogenes_> !ask
[08:03] <def4l7> is there some soft for sdr
[08:04] <def4l7> :D
[08:04] <TaZeR> well here ubuntu-mate is the best =)
[08:05] <def4l7> so i found nothing in ubuntu soft center
[08:05] <def4l7> i need software for rtl sdr :D
[08:06] <diogenes_> def4l7, look in synaptic
[08:09] <def4l7> diogenes_, +1 for karma
[08:09] <def4l7> :D
[08:10] <diogenes_> hehe and for stealth
[08:23] <def4l7> i use rpi 2 b, and it runs slow
[08:24] <def4l7> how i can boost it
[08:25] <diogenes_> what exactly runs slow?
[08:26] <def4l7> cant even run youtube, lagging in synaptic
[08:27] <def4l7> there is dream about overclocking........
[08:27] <def4l7> :D
[08:27] <diogenes_> run: ls $HOME/.config/autostart/ | nc termbin.com 9999
[08:27] <diogenes_> share the link here
[08:29] <def4l7> http://termbin.com/qaj9
[08:31] <diogenes_> def4l7, now: ls /etc/xdg/autostart | nc termbin.com 9999
[08:31] <def4l7> http://termbin.com/v3tga
[08:33] <def4l7> and how i can view t^0
[08:35] <def4l7> t of cpu
[08:36] <diogenes_> run: top
[08:36] <def4l7> a know about top, this util not 4 me
[08:37] <diogenes_> then run: sudo apt install gnome-system-monitor
[08:38] <def4l7> thx
[08:38] <diogenes_> yw
[20:38] <coronon> Hello
[21:04] <superuser> +1
[21:07] <zkjetix> Hello
[21:28] <mate|18633> Hello world!
[22:19] <Chinchin> After main installation VLC does not run Mp4-Videos. How / what do I need to do foe debugging
[22:21] <diogenes_> you need ffmpeg afaik
[22:21] <diogenes_> ubuntu restricted extras
[22:30] <Chinchin> I'm still here, just trying to give feedback ...
[22:30] <NI-Richard> hello everyone :) i want to intall ubuntu MATE on a amilo d7820, are the laptopdrivers compatible with ubuntu-MATE?
[22:31] <diogenes_> NI-Richard, try it live and see
[22:40] <Chinchin> No, not working, but I need to go to bed now (Germany). So thanks and I need to contact later. bye


[04:43] <ubuntu-studio> hi all
[05:29] <bigfluff> So, Kubuntu == Ubuntu under the hood?  Really not a whole lot of difference in terms of system perspective?
[06:38] <Unit193> Basically, yeah.
 How to fix this error?
 (Video, 5s)https://irc-attachments.kde.org/c1FD2d9Y/file_38892.mp4
 Snd_hda_intel 0000:08:00.1: no codecs found!
 https://askubuntu.com/questions/1204571/chromium-without-snap … Found this blog but … Should I add debian repo on ubuntu? … I read somewhere, doing that isn't a good idea … Idk
 Hello I have this issue, if I restart or shut down or the laptop go to stand by the screen just get frozen
 I just can move te mouse
 (Photo, 720x1280) https://irc-attachments.kde.org/NfC0C7B9/file_38896.jpg
 I have ubuntu cinnamon and kde Installed just happens when I choose kde desktop
 @diiegg, Install kubuntu rather than using kde environment on Ubuntu
 @SharGen19, If I install the full remix then I can uninstall cinnamon ?
 I remember I use to have ubuntu and I converted to ubuntu cinnamon remix with some commands the guys of cinnamon help me I wonder if the same case with Kubuntu ?
 @diiegg, Don't use another DE in default DE
 It will messed up
 @diiegg, Kubuntu lts is already rock stable to use
 I understand just have some configuration on my lap that don't want to configure again 😆
 @diiegg, Make an additional efi partition if you are using dual boot
 Ok thanks
[13:20] <fahad-M> i have installed like 3 DEs on my hard disk drive, ubuntu, dde ubuntu, kde etc
[13:20] <fahad-M> never had any problems as of now
[13:21] <fahad-M> in fact, if you wanna enjoy linux, it won't be fun without small issues so i prefer to install DEs over a base
[13:22] <fahad-M> but if you don't wanna run into any issues at all, which you will sooner or later anyway in linux lol, go clean install, if you don't mind banging your head into wall, come let's install another DE on your base haha
 I understand
 @fahad-M, Lol there is no base in ubuntu … Ubuntu comes with de
 I have a issue when I load kde environment and I shutdown the computer it get frozen any idea how can I fix that ?
 I install the kde standard
 @diiegg, What's your laptop specs?
 I have a asus Tachi core i5
 Instel HD graphics 4000
 64 bits
 @diiegg, Then there should be no issues … Intel is very compatible with Linux
 @Archxlover, It just happens when shutdown
 @diiegg, And which kernel u using?
 Give me a second
 Please
 @diiegg, Ol
 5.4.0-53 generic
 @diiegg, Lol
 @diiegg, Install xanmod kernel and then check again
 Ok
 @diiegg, Visit xanmod website and copy paste the process
 It's easy
 I used before
 @diiegg, Make sure use stable one
 @diiegg, 5.9.x have lots of issues
[14:29] <tomreyn> diegg: i didn't follow the chat and don't know which problem you're trying to solve, but note that this other kernel Archxlover recommended isn't supported here (it may or may not work for you, though).
[14:30] <BluesKaj> Hi all
[14:31] <tomreyn> hi BluesKaj.
[14:32] <tomreyn> diiegg: see above (i mistyped your nickname initially) and have a look at your system logs as well. acpi errors and hints on broken bios could well explain problems with shutting down properly, too.
[14:32] <BluesKaj> hey tomreyn
 @tomreyn, The problem is the following, if I restart it shutdown my lap, using kde environment the screen just get frozen
 Just can move the 🐁
 (Video, 7s)https://irc-attachments.kde.org/09uprFSH/file_38900.mp4
[14:35] <tomreyn> diiegg: is this s new installation, did it work previously?
[14:35] <tomreyn> *a new
 Not new i have cinamon and I installed kde environment standard, if I want to reboot it shutdown I need use the terminal, using cinamon no problem
[14:37] <tomreyn> diiegg: things you can try to shut down properly in this situation, thus preserving logs: press Ctrl-Alt-F3, which should give you a text console, press Ctrl-Alt-Del once (you can also log in to the text console and attempt to examine the situation further - using the shell)
[14:39] <tomreyn> so you're saying you initially install some version of Ubuntu Mate, then decided to install a kde environment, and since then, the desktop does not start up fine anymore?
[14:40] <tomreyn> or does kde actually work but the screen only freezes when you select the option to shut down from kde?
 @tomreyn, Desktop start fine all good, the problem is when I shutdown, reboot the computer it get frozen and no action
 @tomreyn, Yes
[14:40] <tomreyn> how did you install the kde desktop?
 Not action
 (Video, 20s)https://irc-attachments.kde.org/Gz3yWEvt/file_38901.mp4
[14:42] <tomreyn> thanks for the videos, it doesn't answer the latest question, though.
 @tomreyn, sudo apt install kde-standard
 @Archxlover, Is it really necessary?
[14:44] <tomreyn> i'm not sure whether that's the right package to install, or whether you can safely switch from Ubuntu Mate to a KDE desktop. But from what you say it seems to have succeeded for the most part. MAybe install kubuntu-desktop to be sure you have all components.
[14:44] <tomreyn> diiegg ^
 @binarymatter, Yes
[14:45] <tomreyn> diiegg: i suggest you share your logs, too. journalctl -b | nc termbin.com 9999
[14:46] <tomreyn> diiegg: also from the previous boot: journalctl -b -1 | nc termbin.com 9999
 @Archxlover, Actually I really need some knowledge in this.. I have been using it by mounting the windows efi partition..also some people mentioned that using 2 efi partitions can cause issues while we try to format windows. Is it true?
 @binarymatter, Bro depends on bios … My bios don't need another efi for linux … But in arch Linux it requires
 @Archxlover, Ooh likewise
 @binarymatter, Try with two partition … Root  … And swap
 @tomreyn, I just install kde desktop but 0 new installation
 If it not gives dual boot  … Then try with 3 partition … Root … Swap … And fat32-efi
 @Archxlover, @binarymatter
 Yaya
 (Video, 14s)https://irc-attachments.kde.org/Nkg8qVCc/file_38835.mp4
 Lol
 @Archxlover, Tf u always come up with this shit😂😂
 @binarymatter, Best
 Literally everywhere😂😂
 @binarymatter, Yes … Entertainment is necessary
 @Archxlover, 👍👍noizzz
[14:51] <tomreyn> let me know when you'll have logs to inspect. i'd recommend you do a full new installation when switching from Ubuntu Mate to Kubuntu, though.
[14:51] <tomreyn> those are very different flavours
 @tomreyn, Where I can get the logs from kde ?
[14:52] <tomreyn> you mean kde only logs?
[14:53] <tomreyn> i provided commands above to share complete system logs
 Ok
 I share already
[15:00] <tomreyn> you'd need to post the urls here
 Https://term in/zqlq
 https://termin.com/zqlq
[15:02] <tomreyn> https://termbin.com/zqlq is a 404
[15:02] <tomreyn> https://termbin.com/zq1q exists
[15:03] <tomreyn> you're running a kernel that's not supported here.
[15:03] <tomreyn> please produce a log with a supported kernel image
[15:07] <tomreyn> this laptop has 4 GB RAM installed, that's (just) the minimum requirement for kubuntu.
[15:12] <tomreyn> the root cuase of the logout 'freeze' is logged after the line containing this: file:///home/diego/.local/share/plasma/look-and-feel/Sweet/contents/logout/Logout.qml
[15:12] <tomreyn> it's a broken QML file
[15:13] <tomreyn> diiegg: ^
 I see
 It's any way to fix it ?
 Reinstalling the theme ?
[15:22] <tomreyn> diiegg:  if your custom theme is broken, you'll either need to fix it yourself, find a fixed copy, or revert to a standard theme.
 [..] Maybe install kubuntu-desktop to be sure you have all components.
 [..] i'd recommend you do a full new installation when switching from Ubuntu Mate to Kubuntu, though.
 @diiegg, Xanmod installed?
 @Archxlover, Yes
 @diiegg, Bro try endeavour os … it's really a good linux
 Based on arch
 It's my first choice
 @diiegg, Boot delay fixed?
[15:29] <tomreyn> Archxlover: Let's please focus on Kubuntu support here. There's also #kubuntu-offtopic for other topics (i'm not sure there is an irc<->telegram bridge for it, though)
 I fix the problem
 Thanks so much guys
 👍
 @diiegg, Xanmod fixed it?
 @Archxlover, No man, i fixed with the insights the guys give me
 I replaced the damage file
 @diiegg, Oh okay
 Fwd from Brown: Invest $1 today and make much profit of $200 every 30min, without spending money to anyone, or getting scammed  … Contact us  … 👇👇👇👇 … @AAERYfHUko7396


[19:35] <ibeardslee> morning
[19:55] <chilts> morning
[20:29] <ajmitch> morning
[22:01] <Atamira> morning
[22:01] <kcj> Morning.
[23:23] <hads> I was asked to look at an Exchange semi-replacement.  I think I might recommend a hosted solution.
[23:23] <ibeardslee> have you looked at zimbra ?
[23:24] <hads> A while back.
[23:24] <hads> I breifly looked at SoGo too. I was hoping (in vain probably) for something less complicated.


[01:35] <AmanicA> does anybody know if there is a way to determine weather a revid is between 2 other revid's in the revision history?
[01:36] <jelmer> AmanicA, there's no standard version
[01:37] <jelmer> s/verison/function/
[01:37] <jelmer> but you can of course iterate over the ancestors of revision 1 and look for your revision until you hit revision 2
[01:37] <AmanicA> is there a way though?
[01:38] <AmanicA> do you know of an example I can find somewhere
[01:38] <AmanicA> (eg. which command does something like this)
[01:38] <jelmer> not aware of anything of the top of my head, sorry
[01:38] <AmanicA> thx
[01:40] <jelmer> iterating over ancestors should be pretty easy with a Graph object though
[02:36] <AmanicA> jelmer: thanks a lot, I got it working! :)
[03:33] <lifeless> AmanicA: graph.heads() perhaps too
[03:40] <AmanicA> lifeless: thanks, I ended up using graph.is_ancestor which claims it uses graph.heads()
[03:41] <AmanicA> (its used for `bzr tags -r 1..2` which I submitted two seconds ago :)
[03:56] <cammoblammo> I'm running bzr 1.5 on Debian. I mainly use it for syncing a heap of text files between a few machines, although I also follow a couple of software projects with it as well. Is there anything to be gained by compiling and installing 1.10?
[04:02] <lifeless> cammoblammo: speed
[04:11] <cammoblammo> lifeless: Speed's not a huge factor, although it's always nice. I have had problems pulling from a project's server lately though---is that a possible cause?
[04:12] <lifeless> cammoblammo: anything is a possible cause. details needed to analyse
[04:13] <cammoblammo> lifeless: I knew you'd say that ;-) I'll try to replicate it when I get a chance. It's not a problem.
[14:57] <Enisseo> hi everyone!
[14:58] <Enisseo> Last time I came here, I've been suggested to use the bzr upload plugin, and it works perfectly
[14:58] <Enisseo> except one thing
[14:59] <Enisseo> the ftp upload makes all the uploaded files having a specific "chmod"
[14:59] <Enisseo> which prevent the server to execute them
[14:59] <Enisseo> so I need to use SSH to change the "chmod" of these files
[15:00] <Enisseo> Can the plugin (or bazaar) do this itself?
[15:01] <Enisseo> (info: I upload from Windows to an Unix ftp server)
[15:01] <LarstiQ> Enisseo: possibly, but I'm guessing this is going to be very ftp server dependant.
[15:03] <Enisseo> LarstiQ: you mean that this is a global option for all bzr branches?
[15:04] <LarstiQ> Enisseo: no, I mean that it may not always be possible to chmod files on an ftp server, since there are a lot of broken ftp servers out there.
[15:04] <LarstiQ> Enisseo: can you ftp manually to your server, and chmod them that way, instead of sshing in?
[15:05] <LarstiQ> Enisseo: if not, then there isn't much that can be done unfortunately.
[15:06] <Enisseo> LarstiQ: well, what I want is to use the bzr upload plugin, which is great but does not apply the expected rights to the file it uploads
[15:06]  * LarstiQ nods at Enisseo
[15:07] <LarstiQ> Enisseo: so could you tell me if it is possible to chmod using ftp?
[15:07] <LarstiQ> Enisseo: another option for you personally, would be to use sftp instead of ftp
[15:17] <duckx> Hy
[15:17] <duckx> I was wondering if there is any way to unsplit a tree ?
[15:18] <LarstiQ> duckx: if you did `bzr split` before, `bzr join`
[15:18] <duckx> Ok thx ;)
[15:18] <duckx> I have a try now
[15:26] <duckx> -> bzr: ERROR: Cannot join apache2/.  Trees have the same root
[15:27] <duckx> In my case bzr is used to store revision for the /etc of my servers
[15:27] <duckx> I initialised /etc (bzr init) & /etc/apache2 (Both contains a .bzr subdirectory)
[15:28] <duckx> -> I converted the /etc directory to the --dirstate-with-subtree format ...
[15:28] <jelmer> duckx: there should't be a need to use a -subtree format, -rich-root (e.g. 1.9-rich-root) should be sufficient
[15:28] <duckx> bzr version is 1.5
[15:28] <duckx> ok
[15:29] <jelmer> in that case, --rich-root-pack probably
[15:29] <duckx> ok
[15:29] <duckx> Let me retry
[15:30] <duckx> Well quite logicaly I hit this :
[15:30] <duckx> bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack4>.  Does not support nested trees
[15:32] <duckx> In both trees (/etc & /etc/apache2) Tree root is .
[15:32] <duckx> Which could explain the thing (bug) I hit, as the path are not expanded
[15:32]  * LarstiQ only knows how to change the treeroots via bzrlib
[15:33] <duckx> ;)
[15:34] <LarstiQ> duckx: I suppose you have multiple servers?
[15:34] <duckx> Indeed ;)
[15:35] <duckx> Changes on the servers are then send to mailing list through the mail plugin
[15:35] <jensen> Hi. Do I need to open up for any special port numbers, in order to access a remote bazaar repository, using the bzr+ssh protocol? (other than port 22)
[15:35] <duckx> Nop
[15:35] <duckx> I am on the server
[15:35] <LarstiQ> jensen: no, it's just ssh
[15:35] <jensen> LarstiQ: hum,
[15:35] <duckx> It is local commit
[15:35] <jelmer> duckx: you can't go back after you've upgraded to -subtree, unfortunately
[15:36] <duckx> That is quite logical
[15:36] <LarstiQ> duckx: how willing are you to experiment?
[15:37] <jelmer> duckx: What are you trying to do exactly though? A one-time join? Since it'll be problematic keeping "apache2" up-to-date afterwards
[15:37] <duckx> Well, that a kind of test server
[15:37] <duckx> History of revision are not so important
[15:37] <jensen> LarstiQ: I've made a ssh tunnel to the remote machine (which is not directly accesible from my current location), I am able to successfully connect to it with a standard ssh client, but for some reason, bzr fails, with an "ERROR: Connection close: ..."-message.
[15:37] <jelmer> duckx: you'd want "bzr join --reference" for that, which is still experimental
[15:37] <duckx> ok lets test
[15:38] <LarstiQ> jensen: the two tree roots are still the same then?
[15:39] <jensen> yeah, it should be.
[15:39] <duckx> Indeed bzr: ERROR: Cannot join apache2/.  Trees have the same root id.
[15:39] <LarstiQ> ehm
[15:39] <LarstiQ> s/jensen/jelmer/
[15:40] <LarstiQ> duckx: is it an option to `bzr init` and use a rich-root format from the start, so that it will set the tree root to something unique?
[15:41] <LarstiQ> duckx: if not, you could 'from bzrlib.workingtree import WorkingTree; WorkingTree.open(".").set_root_id("something-unique")'
[15:41] <jensen> LarstiQ: hehe,
[15:41] <LarstiQ> jensen: which client are you using to set up the tunnel?
[15:41] <jensen> i'm using putty.
[15:41] <duckx> Hmm, I thing I will get ride of the revision on my apache2 conf, and add them to the /etc root tree
[15:42] <jensen> LarstiQ: is that a problem?
[15:42] <LarstiQ> jensen: I've seen some problems in this area before, having to do with aliases of tunnels
[15:42] <jensen> aliases?
[15:42] <LarstiQ> duckx: or that :)
[15:42] <LarstiQ> jensen: doesn't ring a bell? good :)
[15:43] <jensen> Hum, I can see, that i get far enough, to get the servers key fingerprint...
[15:43] <jensen> LarstiQ: hehe
[15:43] <LarstiQ> jensen: did you check ~/.bzr.log for more information on the connection close?
[15:43] <LarstiQ> jensen: can it find bzr on the server?
[15:43] <jensen> LarstiQ: No, just a sec.
[15:44] <jensen> LarstiQ: I believe so, the exact same command works perfectly, when i remote desktop to a desktop on the internal network.
[15:45] <jensen> LarstiQ: hm, is the ~/.bzr.log located some place else on windows?
[15:45] <jensen> +file
[15:45] <LarstiQ> yes :)
[15:45] <jensen> :)
[15:46] <LarstiQ> iirc it says where if you run `bzr --version`?
[15:46] <jensen> 1.9
[15:46] <jensen> oh, sorry
[15:46] <jensen> misread that. :)
[15:46] <jensen> yes, it does, thanks.
[15:49] <jensen> hm, nothing but a Traceback, orginating in bzrlib/smart/message.pyo, L247, does'nt really ring a bell for me.
[15:49] <LarstiQ> could you pastebin me the traceback?
[15:49] <jensen> Of course, just a sec.
[15:51] <jensen> LarstiQ: http://pastebin.com/m257da06d
[15:52] <jensen> s/<username>/username/, s/<bzr-path>/full-path/ ...
[15:52] <LarstiQ> oh feh
[15:52] <LarstiQ> and not a bzrlib install with source
[15:52] <jensen> Those should be correct, again, same command works internally on the network.
[15:53] <jensen> LarstiQ: should I get that?
[15:53] <LarstiQ> jensen: hmm, first try if bzr gets to log something on the server
[15:57] <jensen> hm, doesn't seem like it..
[15:57] <duckx> Me again ...
[15:57] <duckx> I removed my .bzr in the subtree ...
[15:57] <duckx> Works fine now ;)
[15:58] <jensen> LarstiQ: No activity when I make a new attempt.
[15:59] <LarstiQ> jensen: I'm having my doubts it is finding a bzr to execute at the remote end
[15:59] <jensen> LarstiQ: it is possible, but it seems strange, that everything works fine from the other desktop.
[16:00] <LarstiQ> jensen: does that desktop have the same ssh tunnel?
[16:01] <jensen> No, it is on the same internal network, so it can connect directly to the server.
[16:24] <duckx> bzrlib.errors.InvalidURL: Invalid url supplied to transport: "file://hestia/etc/": local urls must start with file:///
[16:24] <duckx> hmmm, this is not rfc compliant dudes ;)
[16:26] <duckx> In my case it would be really nice if the host could appear in the base info of a branch
[16:30] <LarstiQ> duckx: interesting
[16:30] <LarstiQ> duckx: what would that do if the host is not the local host as well?
[16:35] <duckx> LarstiQ: I have got no idea ...
[16:35] <duckx> May be the best test would be to use urllib2 & have a try
[16:36] <LarstiQ> duckx: sounds fair
[16:39] <duckx> http://pastebin.com/d65b05eb1
[16:39] <duckx> Here is the trace I have for an unknown host lookup
[16:39] <duckx> Works fine with the right hosts
[16:41] <LarstiQ> duckx: will you submit a patch?
[16:42] <duckx> Hmm, first I would like to determine the best to implement it
[16:42] <duckx> Because putting it by default would break one workflow
[16:42] <duckx> scp your tree to another host
[16:43] <LarstiQ> it is only used in bzrlib.urlutils.local_path_from_url
[16:43] <LarstiQ> (the posix and win32 variants)
[16:43] <LarstiQ> duckx: right
[16:43] <duckx> bzr will break if the host could not be lookup
[16:44] <duckx> I am more thinking to a switch to init ....
[16:44] <duckx> Like add hostname
[16:44] <duckx> sorry --add-hostname or something
[16:44] <LarstiQ> maybe we should take a step back
[16:44] <LarstiQ> what is it you want to accomplish?
[16:45] <duckx> Well, when I commit my modification on my server (Still on the /etc tree) the branch.base is append to the mail subject
[16:45] <LarstiQ> right
[16:45] <duckx> that is on my case file:///etc
[16:46] <duckx> Each time I commit on a server I should specify on what server I was working on
[16:46] <duckx> eg: Subject: MY_HOST I did some stuff on it
[16:47] <duckx> So I tried to find out a way to add the server automaticaly
[16:47] <duckx> That has a sense only if you work locally
[16:47] <LarstiQ> maybe it is a better idea to add an option to the emailing hook?
[16:47] <duckx> Yeah, but options are parsed from the bazaar.conf configfile
[16:47] <duckx> Where you only have static information
[16:48] <LarstiQ> 'include hostname in email subjects'
[16:48] <duckx> lol ;) That is what I was trying to say ;)
[16:48] <duckx> So best way is to patch email plugin right
[16:48] <LarstiQ> I think so
[16:48] <duckx> K
[16:48] <fullermd> At one time, I think lifeless discussed adding templating capability to the email thingy...   I don't know how far that ever got.
[16:49] <fullermd> But if it were completeish, adding a %h escape or something wouldn't be much work I'd think.
[16:49] <LarstiQ> that would the more general step
[16:50] <duckx> Well, I am ready to hack a bit on email module ...
[16:50] <duckx> But I prefer to follow your instructions/point of view ;)
[16:51] <LarstiQ> duckx: if you have enough time, see if there has been work done on templating, if not, ask lifeless about his plans. And then implement them :)
[16:52] <duckx> Short term could be a commit_include_host option in the config file  ?
[16:52] <LarstiQ> something like that, yes
[16:52] <duckx> ok
[16:53] <LarstiQ> I'd say subject_include_host
[16:53] <duckx> Ok I am on it ;)
[16:53] <LarstiQ> duckx: you'll be at fosdem I assume?
[16:53] <duckx> lol, I don't even know where it takes place ;)
[16:54] <LarstiQ> Brussels!
[16:54] <duckx> Well, it is not far away ...
[16:54] <duckx> May be it will be a good time to find a job @ canonical ... ;)
[16:54] <duckx> -> my current job breaks my xxx
[16:57] <duckx> I am currently working @ a banck doing some wired Unix Admin tasks ...
[16:58] <fullermd> Better than wireless admin tasks  ;>
[17:16] <duckx> Ok patch ready ;)
[17:18] <duckx> LarstiQ: What the best way to submit it ?
[17:19] <LarstiQ> duckx: the email plugin README doesn't mention anything?
[17:20] <duckx> Let me check
[17:20] <duckx> This should be send to the mailing list ;)
[17:30] <LarstiQ> pl
[17:30] <LarstiQ> ok
[17:30] <LarstiQ> make sure to include in the subject that it is for the email plugin
[17:37] <duckx> ok
[17:38] <LarstiQ> duckx: bzr/doc/developers/HACKING.txt on the code review process might be helpful too
[17:46] <duckx> Ok let me have a look at it
[17:56] <duckx> Time to go see my parents
[17:56] <duckx> Thx for your help dudes !
[17:56] <duckx> See you
[18:02] <LarstiQ> duckx: have fun!
[19:07] <dilema> hi
[19:11] <dilema> i have a problem to get a connection via ftp to my webspace
[19:12] <dilema> i have no chance to init my webspace as a branch
[19:38] <dilema> any idea
[20:06] <thumper> dilema: so how do you get access?
[20:06] <dilema> per ftp
[20:07] <thumper> dilema: can't you just go bzr init ftp://whatever?
[20:10] <dilema> matthias@matthias-laptop:/var/www/mydomain.de$ bzr init<EMAIL_ADDRESS>[20:10] <dilema> thumper, he required a pw
[20:11] <dilema> thumper, he gets it
[20:11] <dilema> thumper, then nothing happen
[20:11] <thumper> dilema: when you say nothing happens, does it hang?
[20:11] <dilema> thumper, i mean no feedback
[20:12] <thumper> dilema: I'm not sure if you normally get feedback...
[20:12] <dilema> thumper, ok
[20:12] <thumper> what if you then go `bzr info<EMAIL_ADDRESS>[20:14] <dilema> thumper, wait ..
[20:14] <dilema> thumper, ok it looks nice, or? -> branch root<EMAIL_ADDRESS>[20:15] <dilema> thumper, and sthing like Standalone branch (format: pack-0.92)
[20:15] <garyvdm> Hi. What work around are there for bug 302698?
[20:15] <thumper> dilema: yes you have a branch there
[20:15] <dilema> thumper, so i can work with
[20:15] <thumper> garyvdm: not sure, but when you find it, I'd like to know
[20:16] <thumper> dilema: yes
[20:16] <dilema> thumper, thx ;)
[20:16] <thumper> garyvdm: I'd ask jam when he arrives, or poolie
[20:17] <garyvdm> thumper: I actualy know 2, but they are both pain full. 1. Delete branch and start again. 2. Install old version of bzr (1.9).
[20:21] <garyvdm> I'm trying to find a deb for 1.9 intrepid. I'm only able to find 1.10.
[21:55] <spiv> garyvdm: installing 1.9 isn't a good workaround; 1.9 has the same problem, but doesn't notice it.  i.e. it appears to succeed, but makes a repo with missing data that will cause problems later on.
[21:57] <spiv> garyvdm: although the traceback in that bug involves autopack, which suggests the repo already had this problem in it.
[21:57] <spiv> garyvdm: if there's a more recent traceback, could you pastebin it/
[21:57] <spiv> ?
[22:02] <garyvdm> Hi spiv.
[22:03] <spiv> garyvdm: hi
[22:03] <garyvdm> Which repo would have the problem? The repo that I'm pushing from, or the repo that I'm pushing to, or the repo that I'm skated on?
[22:04] <garyvdm> *stacked
[22:04] <spiv> The one you are pushing to.
[22:05] <garyvdm> I can reproduce the bug as follows:
[22:05] <garyvdm> Delete the branch that I'm pushing to (lp:~qbzr-dev/qbzr/threadless-throbber/)
[22:06] <garyvdm> push -r -1 (gets stacked on lp:qbzr)
[22:06] <garyvdm> push - get error
[22:06] <spiv> Can you pastebin the traceback for that error?
[22:06] <garyvdm> ok
[22:07] <spiv> The one in the bug involves autopacking, but a fresh push shouldn't.
[22:10] <garyvdm> http://pastebin.com/m2284da73
[22:13] <spiv> garyvdm: and that's with 1.10?
[22:13] <spiv> (final?)
[22:13] <garyvdm> Yes - deb from ppa
[22:15] <spiv> Huh, interesting, it hasn't taken the code path that it's supposed to if the target repo is stacked on another.
[22:15] <spiv> i.e. it's taken the code path for unstacked repos.
[22:16] <garyvdm> Sorry - that went over my head.
[22:16] <spiv> That's ok :)
[22:17] <spiv> Basically, it looks like that part of the code thinks the target is not stacked.
[22:17] <garyvdm> ok
[22:18] <spiv> Hmm, lp:qbzr is in pack-0.92 format, which means that's probably correct.
[22:18] <spiv> What does info -v report in your local branch?  (pastebin again)
[22:20] <garyvdm> Ah - I've recently changed the format on my local. When that stack happend - the repo was using 1.9
[22:20] <spiv> Ok, that's interesting.
[22:21] <garyvdm> http://pastebin.com/d2d1ed0f6
[22:21] <spiv> Can you tar up the local repo and put it somewhere?  (maybe chinstrap?)
[22:21] <garyvdm> ok
[22:23] <spiv> (I'm thinking that perhaps I was wrong, that this might actually be an issue in your local repo after all)
[22:23] <garyvdm> Sorry - whats the url for chinstrap
[22:24] <spiv> garyvdm: ah, nevermind, just mail it to me at<EMAIL_ADDRESS>[22:24] <garyvdm> ok
[22:26] <garyvdm> Ok - I've sent it. I'm in South Africa - so it will get to you in Telkom time.
[22:26] <garyvdm> 3.4mb
[22:28] <spiv> Ok.  Thanks!
[22:32] <spiv> garyvdm: got it
[22:34] <garyvdm> I'm busy trying the following: I've done an upgrade --1.6 on both repo and branch, and now trying to see if I can reproduce.
[22:34] <garyvdm> Thats local branch and repo.
[22:37] <garyvdm> Ok - That worked
[22:40] <spiv> garyvdm: interesting.  I haven't been able to reproduce so far.
[22:40] <garyvdm> I upgraded to --1.9 and then pushed a new rev and it also worked. I'm confused now.
[22:40] <garyvdm> Ok - let me try one more thing - going afk
[22:50] <garyvdm> spiv: Revised steps to reproduce:
[22:50] <garyvdm> 1 - delete remote branch
[22:51] <garyvdm> 2 - *use bzr 1.11dev rev 3409*
[22:51] <garyvdm> 3. push -r -1
[22:51] <garyvdm> 4. push - get erro
[22:51] <garyvdm> step 4 can be with 1.11 dev or 1.10
[22:52] <garyvdm> but step 3 must be with 1.11dev
[22:53] <spiv> garyvdm: I'll try that
[22:54] <garyvdm> *rev 3904
[23:04] <spiv> garyvdm: I have r3904, but I can't seem to reproduce :(
[23:05] <garyvdm> Ok - I did step 3 on my windows box (cause I'm running 1.11dev on it)
[23:06] <garyvdm> I don't know what's different there.
[23:07] <garyvdm> I'm going busy branching bzr.dev to my ubuntu box to see if I can reproduce it.
[23:08] <spiv> garyvdm: hmm.  so from a different source repo?
[23:08] <garyvdm> Yes
[23:10] <spiv> garyvdm: try running "bzr check" on that repo or branch, just in case.
[23:11] <garyvdm> Someone else suggestive that when I first had the problem. It came up clean
[23:12] <spiv> Yeah, I thought it probably would.  It was worth checking :)
[23:23] <garyvdm> I was not able to reproduce on my ubuntu box. I'll sign in to irc from my windows box.
[23:31] <GaryvdM> spiv: I was not able to reproduce on ubuntu, but I was able to reproduce on windows. Here is another pastebin: http://pastebin.com/mc2183f1
[23:36] <spiv> GaryvdM: it seems likely that there's something different about that repository.
[23:36] <GaryvdM> I ran bzr check again, and noticed something I didnot notice before: 4 inconsistent parents (http://pastebin.com/m79361e1)
[23:37] <spiv> GaryvdM: likely it has delta records at different points than the other one?
[23:37] <GaryvdM> Can I send you another tar?
[23:37] <spiv> Sure.
[23:38] <spiv> You can correct the inconsistent parents with bzr reconcile IIRC.
[23:38] <spiv> My guess is that that isn't the issue, but I'm not very confident about that.
[23:55] <GaryvdM> spiv: reconcile did not fix.
[23:55] <GaryvdM> Did you get my tar?
[23:56] <spiv> GaryvdM: ah, yes


[16:52] <myrtlebeachbums> Does anyone have the announcement for the three new members added to the America Regional Membership Board?
[16:52] <myrtlebeachbums> We need it for UWN if you've got it.
[17:02] <nhandler> myrtlebeachbums: I just gave it to tyche: https://wiki.ubuntu.com/Membership/RegionalBoards/Americas
[17:02] <nhandler> Wrong link: http://www.mikesplanet.net/2009/06/expanding-the-ranks/
[17:02] <myrtlebeachbums> Thanks Nick
[17:02] <nhandler> ???
[17:02] <myrtlebeachbums> Uh, Nathan.
[17:02] <myrtlebeachbums> I *THOUGHT* I had enough coffee today. I guess I was wrong.
[17:02] <nhandler> :)
[17:03] <tyche> Too much blood in his coffee-stream
[17:03] <myrtlebeachbums> Bingo!
[17:16] <nhandler> As a note about team reports, depending on how things go, I hope to either include them in next week or the following week's UWN
[17:18] <tyche> nhandler: Well, boredandblogging just got his in.
[17:20] <nhandler> tyche: For what team?
[17:22] <tyche> I don't know.  ask in #ununtu-locoteams
[17:23] <tyche> After all, he doesn't tell me anything.  He just expects me to trust him.  TRUST him????  REALLY???  BTW, thanks for the link.


[02:18] <aconbere> hey, I'm having an issue running a java service under upstart, that runs fine from the shell
[02:19] <aconbere> I can run it in the shell with the same privs
[02:19] <aconbere> and it takes no options
[02:19] <aconbere> and doesn't inspect any environmental variables
[02:19] <aconbere> I don't know how to debug this
[02:19] <aconbere> wondering if anyone here can help
[02:21] <aconbere> (the error for reference is reading a datafile out of a jar, i get a MalformedInputException, but only in upstart)
[02:21] <aconbere> my theories run the gambit of some strange forking going on
[02:21] <aconbere> or maybe just running in a different environment
[02:37] <SpamapS> aconbere: java shouldn't be forking
[11:08] <dan2003> Hi, im trying to make a script to run a task when mysql is stopped. But im having the problem that it takes a while it doesnt get to copmlete before reboot or halt, so I tried setting the kill timeout to a value greater than the default (5). But it doesnt help. I have realised that this is probably because I did not have a stop in statement. But I am not able to find a suitable event for my stop on statement, an ideas?
[11:08] <dan2003> stop in/stop on
[11:10] <dan2003> I was just about to add i have tried the obvious runlevel [06] and found it dodnt work presumeably becasue that happens before my process is even started, but am trying it again as think i may have had a syntax error
[11:14] <jodh> dan2003: currently, having a job start on shutdown is going to be challenging. You may need to look at /etc/init.d/sendsigs and /etc/init.d/umountroot since those are invoked just before shutdown and you may need to modify them to ensure they wait for your job(s) to complete.
[11:15] <dan2003> jodh, ok, I am jut trying a bit of a hack with a seperate job that starts on runlevel [06] and has kil timeout 60, and stops on stop stopped my_other_job, which will be omitted when the other job is done
[11:16] <dan2003> but if this fails I will look at that
[11:17] <jodh> dan2003: the problem is that the final shutdown stages on Ubuntu are not currently handled directly by Upstart - we're looking to change that behaviour in the Raring cycle.
[11:17] <dan2003> oh ok
[11:34] <dan2003> jodh, thanks a bunch, a simple check in  /etc/init.d/sendsigs seems to have resolved my problem
[11:34] <jodh> dan2003: np :)
[14:55] <aconbere> hey, I've got a little project I'm using that makes use of scalate. To deploy my app, I package a jar and ship it off to servers. I'm unclear how to make use of scalate templates once they're packaged though...
[14:56] <aconbere> I think my best bet is precompiling them, but then there's not really any discussion in the docs of accessing precompiled templates
[14:56] <aconbere> anyway, if anyone knows anything about that (or a better place to look)
[15:50] <aconbere> bah, wrong channel
[15:50] <aconbere> :-/


[09:58] <sub526> I'm having an Ubuntu 18.04 PC and in my PC kernel auto updates. I disabled the kernel auto update in my PC by configuring linux-image-generic in held state.. Is there a way to verify kernel auto update is disabled or not?