[07:03] <mardy> jamesh: hi! I need some help from a Go expert... any idea why account polld builds are failing in some architectures here? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages
[07:04] <mardy> jamesh: is it because of go vs gcc-go?
[07:08] <jamesh> mardy: I'm not sure of the underlying cause, but it looks like it is having trouble finding the C++ compiler in the failing builds
[07:08] <jamesh> mardy: "go build launchpad.net/account-polld/qtcontact: /usr/bin/g++-5: fork/exec /usr/bin/g++-5: no such file or directory"
[07:09] <jamesh> mardy: that's in the failed vivid builds.  In the failed xenial build it says "go build launchpad.net/account-polld/qtcontact: /usr/bin/g++-5: fork/exec /usr/bin/g++-5: no such file or directory"
[07:09] <jamesh> oops.  wrong paste
[07:09] <jamesh> "go build launchpad.net/account-polld/qtcontact: /usr/bin/g++-6: fork/exec /usr/bin/g++-6: no such file or directory"
[07:10] <jamesh> so for some reason it is looking for GCC 5 on vivid (which ships with 4.9), and GCC 6 on Xenial (which ships with 5)
[07:10] <jamesh> I don't know why it would be doing this
[07:11] <mardy> jamesh: is it possible from the build log to tell whether it's building with go or gcc-go?
[07:11] <mardy> jamesh: I'm asking, because I suspect that it's using gcc-go in those failing logs
[07:13] <jamesh> mardy: the xenial/powerpc build seems to be installing gccgo
[07:13] <jamesh> interestingly, it is installing a "gccgo-6" package
[07:13] <mardy> jamesh: I wonder if the go shipped in those ubuntu releases did not support those archs, so gcc-go is being used instead
[07:13] <mardy> jamesh: ah, so it expects a g++-6
[07:14] <mardy> weird
[07:14] <jamesh> mardy: and the failing vivid builds are installing gccgo-5
[07:14] <mardy> right
[07:14] <mardy> jamesh: do you know where this logic resides? is it in the debhelper plugin for go?
[07:15] <jamesh> mardy: my guess is that they've included gccgo packages from a newer gcc due to the compiler being fairly new
[07:15] <jamesh> but it ends up looking for a matching C/C++ compiler if you use cgo, and fails
[07:16] <jamesh> mardy: I'm not sure what makes the decision
[07:18] <jamesh> mardy: on another topic, did you see this bug I filed? https://bugs.launchpad.net/online-accounts-api/+bug/1617180
[07:19] <mardy> jamesh: yes, I'll get to that, eventually
[07:19] <jamesh> I dug around a bit, but couldn't work out what was causing the leak
[07:19] <jamesh> I couldn't see anything obvious in the code that could explain the leak
[07:20] <mardy> jamesh: I wonder, could you try that in vivid or xenial, where qt 5.5 is being used?
[07:20] <jamesh> your code looked pretty much like every other piece of QtDBus code I've seen
[07:20] <mardy> jamesh: I wonder if the leak could be in Qt 5.6 itself, sincethe QtDbus part has been heavily modified in there
[07:21] <jamesh> mardy: that valgrind run was on Xenial
[07:21] <jamesh> so Qt 5.5
[07:21] <mardy> jamesh: ok
[07:22] <jamesh> If I've got time, I'll try repeating on vivid and yakkety
[07:22] <jamesh> to cover 5.4 and 5.6
[07:23] <mardy> jamesh: that might help, thanks
[07:25] <mardy> jamesh: back to the gccgo issue, I suspect that the problem is that the gccgo-5 (I'm looking at vivid only, for now) does not depend on g++-5 (or any gcc/g++, for that matter)
[07:25] <mardy> jamesh: while in yakkety I see that it has the proper dependency
[07:27] <jamesh> mardy: there probably isn't a g++-5 package on vivid
[07:29] <mardy> jamesh: and you are right...
[07:33] <mardy> jamesh: do you know how to solve this? maybe we could check modify the gccgo-5 package in vivid to use gcc-4 instead? Or would the generated objects be incompatible?
[07:39] <mardy> dbarth: do you have an arm64 device with ubuntu?
[07:39] <mardy> dbarth: and hi :-)
[07:43] <jamesh> mardy: I don't know.  If the package has never built on those platforms, then it probably isn't worth worrying about
[08:33] <dbarth_> mardy: nope, sorry, only having a cooler here
[08:33] <dbarth_> mardy: on maybe my rpi3 ?
[09:02] <pstolowski> pitti, hey, can you help with silo 21 and retry autopkg tests on xenial and yakkety there?
[09:10] <pitti> pstolowski: I need the full URLs to the excuses
[09:11] <pstolowski> pitti, https://requests.ci-train.ubuntu.com/static/britney/landing-021/xenial/excuses.html
[09:12] <pstolowski> pitti, and https://requests.ci-train.ubuntu.com/static/britney/landing-021/yakkety/excuses.html
[09:12] <pitti> pstolowski: retried the xneial ones; nothing to do on the yakkety one
[09:12] <pitti> (no tests at all)
[09:12] <pitti> this is a packaging bug instead, you need to stop building on s390x
[09:12] <pstolowski> pitti, ah oh, sorry, you're right
[09:13] <pitti> best to explicitly build-dep on the corresponding -dev packages so that it will fail to build
[09:13] <pitti> instead of being built and then uninstallable
[09:14] <pstolowski> pitti, i see, ok, will fix that, thanks
[09:17] <zzarr> OTA-13 today :D
[09:23] <duflu> zzarr: Web page says 19 September: https://launchpad.net/canonical-devices-system-image/+milestone/13
[09:24] <zzarr> ohh, the testing and bugfixing have been prolonged?
[09:29] <zzarr> duflu, do you know if mms:es will be fixed in OTA-13?
[09:29] <duflu> zzarr: I don't know. Check the above list
[09:30] <zzarr> I could not find anything about it
[09:33] <zzarr> receiving MMS have not worked since OTA-10 (I'm not alone experiencing this problem)
[09:34] <zzarr> should I report the problem?
[09:40] <popey> zzarr: if it's not been reported as a bug then it certainly won't get fixed
[09:41] <zzarr> popey, are the list duflu linked to the complete list of reported bugs?
[09:41] <popey> no
[09:41] <duflu> zzarr: No it's more an executive summary. If you think some bug is missing please tell someone here or in the bug
[09:42] <zzarr> is there a complete list?
[09:42] <duflu> zzarr: No it's launchpad. There are separate lists per project. Please check the appropriate project
[09:43] <zzarr> that list is only for OTA-13?
[09:43] <duflu> Yes, and it's not quite complete for OTA-13 even
[09:43] <duflu> If you know of a bug that's missing please point to it
[09:44] <zzarr> if I don't have the complete list I can't know if the problem with MMS is reported
[09:45] <zzarr> but I guess that the worst that could happen is that I report a bug again and my report and the original is merged
[09:45] <zzarr> or I'm pointed to the correct bug report
[09:49] <zzarr> can I somehow force the phone to send information to my service provider that the phone is capable of receiving MMS?
[09:55] <popey> zzarr: step one is file a bug, yes.
[09:55] <zzarr> okey, I'll do it
[09:55] <popey> https://bugs.launchpad.net/ubuntu/+source/messaging-app/+bugs
[09:55] <popey> thats where mms bugs lie
[09:55] <popey> so maybe scan that list
[09:56] <zzarr> okey, thanks
[10:45] <zzarr> I found a bug report regarding this issue and a technician at Tele2 the operator I use tells me after a few tests that the problem is with Ubuntu
[10:45] <zzarr> now some lunch
[10:56] <melvster> hi all i heard a rumor OTA13 was coming out this week, is that right?
[10:59] <Hourd> \q
[11:25] <jgdx> mardy, ping
[11:26] <mardy> jgdx: hi!
[11:26] <jgdx> mardy, hey, so I'm trying to solve a problem in System Settings I'd like your input on
[11:27] <jgdx> mardy, system settings will run on a snappy-based system, this means that every reference to /, will have to be prefixed with $SNAP. There are such refs everywhere.
[11:27] <mardy> right
[11:28] <jgdx> and this is a problem for libSystemSettings as well, as it refers to / multiple places
[11:28] <jgdx> we don't want six-ish calls to qgetenv at startup
[11:29] <mardy> jgdx: what are we using / for? is it for the plugin path, or for something else too?
[11:30] <jgdx> mardy, we refer to PLUGIN_QML_DIR, PLUGIN_PRIVATE_MODULE_DIR, PLUGIN_MANIFEST_DIR and PLUGIN_MODULE_DIR
[11:31] <jgdx> in main, plugin-manager and plugin
[11:31] <jgdx> which all point at /
[11:31] <jgdx> and we do not know $SNAP at build time, iuic
[11:33] <jgdx> one suggestion is to subclass qtapplication, add mountPoint as a property. Then add a header to libsystemsettings-dev that exposes this class, as well as rewrite the qApp macro.
[11:35] <mardy> jgdx: or, instead of hardcoding these paths, hardcode only the components on top of XDG dirs
[11:36] <mardy> jgdx: and use QStandardPaths in our code, then append the fixed components
[11:36] <jgdx> mardy, but why isn't it already relative to xdg dirs?
[11:37] <jgdx> i assumed there was some reason, but if not, why we'll do it that way
[11:38] <mardy> jgdx: no idea, I guess I didn't see a compelling reason to do so
[11:38] <mardy> jgdx: XDG-izing the app is a good idea anyway
[11:39] <jgdx> mardy, do you think it's trivially doable?
[11:39] <mardy> jgdx: ah, well, one reason *not* to do it is that XDG dirs is a list, while we use one directory only
[11:40] <mardy> jgdx: I guess it's fairly trivial if we pick only the first directory, but doing things properly would be a bit more complicated
[11:43] <jgdx> mardy, where in the xdg specification are library files mentioned?
[11:44] <mardy> jgdx: oh, right, this would apply to plugin manifest files, but not libraries
[11:45] <mardy> jgdx: but for QML modules it's not hard either, we just add a path to the QQmlEngine in src/main.cpp
[11:46] <mardy> jgdx: so I guess that you could read $SNAP from there, and add a couple of paths based on $SNAP
[11:47] <mardy> jgdx: or even, don't change the code at all and play with the QML2_IMPORT_PATH variable
[11:53] <jgdx> mardy, okay, so how do a plugin find its .so? Seems that's the last piece of the puzzle here
[11:54] <jgdx> that's not a qml import, nor is it covered by xdg
[11:55] <mardy> jgdx: I think it's relative to the QML module dir, so you shouldn't need to worry
[11:56] <jgdx> mardy, okay, let's do this then. Thanks
[11:57] <mardy> jgdx: yw, let me know how it goes :-)
[12:53] <jgdx> mardy, any reason why you only want to pick one dir when multiple are returned?
[12:54] <mardy> jgdx: no, no, feel free to iterate them all, that's better
[12:54] <jgdx> yeah
[14:04] <jgdx> mardy, I'm not sure your assumption on the .so's holds: e.g. /usr/lib/arm-linux-gnueabihf/ubuntu-system-settings/libonline-accounts.so
[14:04] <jgdx> that's what loaded
[14:14] <tedg> popey: Is ubuntu-terminal-app in the archive somewhere?
[14:14] <mardy> jgdx: you are right, the libs are in $$LIBDIR/ubuntu-system-settings/, and the QML plugins are in the "private" subdir
[14:15] <popey> tedg: no
[14:16] <tedg> popey: :-(
[14:21] <mardy> jgdx: it's non trivial... we could avoid specifying a path, given that we use QPluginLoader which uses QCoreApplication::libraryPaths(), but it's a bit risky
[14:21] <mardy> jgdx: because we risk loading some other unrelated plugin, if they happen to have the same name
[14:22] <jgdx> mardy, what about putting the mount point in a ctx prop?
[14:22] <mardy> jgdx: it's not clear to me what the solution should be. Plugins can also come from other snaps, so we don't want just to check our $SNAP dir
[14:22] <mardy> jgdx: unless other snaps can install stuff there too?
[14:23] <jgdx> mardy, yeah, I don't know about that scenario. The current approach breaks confinement
[14:23] <dobey> tedg: can't you install the click?
[14:24] <tedg> dobey: Wanting to include it in a snap.
[14:24] <mardy> jgdx: online-accounts for example is a plugin coming from another snap, unless we merge them
[14:24] <tedg> dobey: For debugging
[14:24] <mardy> jgdx: IMHO, we should have a single snap for the whole of unity8, TBH
[14:24] <jgdx> tedg, ^^
[14:24] <tedg> Heh, yes, I agree.
[14:24] <jgdx> ;)
[14:25] <dobey> mv system.img unity8.snap
[14:25] <jgdx> mardy, okay, so breaking confinement to load external plugins is a non-starter i guess.
[14:25] <jgdx> since what you want is highly probably
[14:25] <jgdx> probable
[14:26] <mardy> dobey: even better: for i in *.deb; mv $i ${i/deb/snap}; done ;-)
[14:27] <dobey> for (const auto& rum: rums) { drink(rum); }
[14:28] <jgdx> const ref rum??
[14:28] <jgdx> yeah that works
[15:29] <dobey> jgdx: well if you keep creating duplicates of the rum, things get weird
[15:35] <mancebeitor> When OTA13?
[15:57] <harirama> the glass screen of my bq4.5 broke, friend ordered a new one from china, had it installed:
[15:57] <harirama> thing doesn't work right, only lower part works as a keyboard.
[15:58] <harirama> http://www.ubuntu.com/phone/devices
[15:58] <harirama> all the phones there say:
[15:58] <harirama> "sold out"
[15:58] <harirama> now what do i do? aaargh help
[16:02] <popey> harirama: call bq?
[16:06] <harirama> popey, what hardware are u running on?
[16:10] <popey> harirama: I have a few phones :)
[16:18] <harirama> well, at the moment, i have 0 :(
[16:30] <mancebeitor> When OTA 13?
[17:47] <Perzival1312> is there anything about any of the one plus models?
[17:49] <dobey> no more than what ubuports has
[20:11] <jgdx> mardy, hey, when you got a chance, could you take a look at this [1] mp and see if it agrees with the approach we discussed? It's a bit eclectic, but should work. [1] https://code.launchpad.net/~jonas-drange/ubuntu-system-settings/snapd-paths2/+merge/305751
[20:16] <flohack> Good Eve
[20:17] <flohack> Can anyone tell me if it is possible to get screen console during touch boot so that stdout messages can be monitored?
[20:40] <Walex> flohack: probably in developer mode
[20:41] <flohack> How to get there ;)
[20:48] <dobey> flohack: well assuming it gets far enough to start some services, and usb works, you'd need adbd running, and to then adb in and read dmesg
[20:50] <flohack> No thats my problem... automatic reboot after 5 secs, no adb. Take a look:
[20:51] <flohack> [    5.699726] initrd: mounting system.img (user mode)
[20:51] <flohack> [    5.733970] initrd: mounting device image as ro
[20:51] <flohack> [    5.795786] EXT4-fs (loop1): mounted filesystem with ordered data mode. Opts: (null)
[20:51] <flohack> [    5.817083] initrd: device is endeavoru
[20:51] <flohack> [    8.790337] initrd: mounting /root/var/lib/lxc/android/system.img as /root/android/system
[20:51] <flohack> [    9.075972] Kernel panic - not syncing: Attempted to kill init!
[20:51] <flohack> [    9.108567] Rebooting in 5 seconds..
[20:51] <flohack> I took only the relevant things I hope
[20:51] <dobey> use pastebin please in future
[20:51] <flohack> Ok wait a sec
[20:52] <dobey> well i can't really help you, myself
[20:52] <dobey> other than to say a kernel panic seems obviously bad :)
[20:53] <flohack> http://pastebin.com/a2STZv71
[20:53] <flohack> :) thanks, but I need to know the reason somehow
[20:53] <flohack> And there is lots of things logged in scripts/touch to stdout, not to kmsg
[20:53] <flohack> And maybe I can get a clue from that
[21:01] <dobey> well, reboot to recovery, and check the syslog. i'm not 100% sure how to do it, but i presume you can adb into recovery
[21:08] <flohack> yes I can
[21:08] <flohack> its a littel bit tricky with those 100 mounts, remounts and loop mounts to find syslog :P
[21:21] <flohack> I would need framebuffer console I think
[21:21] <flohack> is this configurable at all?
[21:34] <flohack> I try with CONFIG_FRAMEBUFFER_CONSOLE=y
[21:34] <flohack> lets ee...
[22:11] <flohack> Ok fb console works but I got other issues... good night ;)
[22:22] <Acou_Bass> i know this isn't really the right channel, but figured you guys might have experience - has anyone replaced the screen on s nexus 4? i broke mine today like a dumbo


[08:03] <dholbach> good morning!
[13:01] <dholbach> nigelb, https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide?action=diff&rev2=36&rev1=35
[13:02] <nigelb> dholbach: +1  :)
[13:02] <dholbach> good
[13:02] <dholbach> now we need to recruit more people
[13:02] <nigelb> You want to talk about it tomorrow?
[13:02] <dholbach> sure
[13:02] <nigelb> I'll start writing more posts on hands down patching when I get back
[13:03] <dholbach> excellent


[17:24] <bazhang> thats banworthy
[17:25] <k1l_> told him to come in here to resolve that mute
[17:25] <bazhang> ok
[17:26] <bazhang> keithzg_, hi
[17:49] <bazhang> he gave it eight seconds in #freenode before quitting


[00:09] <micahg> chrisccoulson: what do you think about the flash packages?
[00:10] <chrisccoulson> micahg - which ones?
[00:10] <micahg> chrisccoulson: flashplugin-installer, gnash
[00:10] <chrisccoulson> yeah, we could try
[00:11] <micahg> chrisccoulson: I think it's appropriate
[00:11] <chrisccoulson> yeah, i think it makes sense
[00:11] <micahg> chrisccoulson: k, well, I'll file it after lightning is in
[00:11] <micahg> chrisccoulson: do you want me to look at the package tonight before you upload?
[00:12] <chrisccoulson> i think i'll just get it uploaded before i go to bed
[00:12] <chrisccoulson> we can fix any issues if we find them
[00:12] <micahg> chrisccoulson: k, I'm sure it's fine
[00:18] <fta> chromium-browser                 77893   4.56%     14901   48053   14925      14
[00:18] <fta> google-chrome-beta               77719   4.55%     12767   57963    6888     101
[00:18] <fta> \o/
[00:19] <micahg> fta: congrats
[00:20] <fta> next target is epiphany
[00:20] <fta> but it will take a while
[00:20] <micahg> fta: how close?
[00:20] <fta> epiphany-browser                165339   9.68%      6960  155851    2482      46
[00:20] <fta> epiphany-gecko                   86989   5.09%       482   86206     268      33
[00:21]  * micahg wonders why there's an epiphany-gecko package in maverick
[00:22] <fta> epiphany-webkit                   4980   0.29%         4    3521       0    1455
[00:22] <micahg> chrisccoulson: you see any reason why we can't drop the epiphany transitional packages?
[00:23] <fta> for the upgrades
[00:23] <micahg> fta: in maverick?  they were added in karmic
[00:24] <fta> oh, right. nm then
[00:24] <chrisccoulson> micahg - we probably could drop them, but i think epiphany is mostly in sync with debian
[00:24] <chrisccoulson> (with the exception of a bookmark change last time i checked)
[00:25] <micahg> chrisccoulson: we have Ubuntu changes
[00:25] <micahg> chrisccoulson: maybe I should do a merge?
[00:26] <micahg> chrisccoulson: we're 4 point releases behind
[00:26] <chrisccoulson> yeah, that might be worth doing
[00:26] <micahg> chrisccoulson: should I ask in -desktop or just propose it
[00:27]  * chrisccoulson wonders why we've not been tracking the unstable series for epiphany like the rest of gnome
[00:27] <micahg> chrisccoulson: doesn't exist from what I can tell
[00:27] <micahg> oh, nm
[00:27] <chrisccoulson> micahg - 2.31.5 is the current unstable version (for gnome 2.32)
[00:27] <micahg> it's very out of date, maybe that's why
[00:28] <micahg> last release was 2 months afo
[00:28] <micahg> *ago
[00:28] <chrisccoulson> we should probably update to 2.30.6 at least, anyway
[00:31] <micahg> chrisccoulson: k, I'll add it to my lis
[00:31] <micahg> *list
[00:31] <chrisccoulson> micahg - thanks. perhaps ask didrocks tomorrow if he thinks it's worth updating to 2.31.5
[00:32] <micahg> chrisccoulson: I'd personally think it's better to take the stable release unless there will be and we'll be updating to the 2.32.x release after release
[00:32] <chrisccoulson> yeah, there'll be a 2.32 release, as it tracks the gnome release schedule
[00:32] <micahg> chrisccoulson: k, does that mean I can SRU 2.30.6 to lucid?
[00:33] <chrisccoulson> possibly. i think we relaxed the SRU criteria in lucid to make it easier to get gnome stable updates in
[00:33] <chrisccoulson> but you'd need to have a look at what changed between the 2 versions
[00:34] <micahg> chrisccoulson: k
[00:34] <micahg> chrisccoulson: epiphany has a ton of bugs in Debian
[00:34] <chrisccoulson> heh :)
[00:35] <micahg> even more than we have
[03:51] <era> yo.
[03:52] <era> any chance that chromium will have an ambiance theme for maverick?
[04:19] <JanC> if it's not in the repositories yet, I doubt it will
[04:34] <micahg> era: http://www.omgubuntu.co.uk/2010/09/ubuntu-10-10-ambiance-radiance-themes-for-chrome-firefox-opera/
[08:57] <micahg> hi chrisccoulson
[08:58] <chrisccoulson> hi micahg
[08:58] <micahg> chrisccoulson: I took a look at the lightning package, I noticed that no mozclient is used to pull a tarball
[08:59] <chrisccoulson> micahg - yeah, that's ok for maverick. the old version didn't use it either
[08:59] <chrisccoulson> we can fix that once we've made it work with dh7
[08:59] <micahg> chrisccoulson: right, but there should at least be instructions on where to get the tarball
[08:59] <chrisccoulson> but, in the meantime, i just used thunderbird to create the tarball, but with the lightning release tag
[08:59] <micahg> chrisccoulson: can you add a README.source that says that
[09:00] <chrisccoulson> yeah, it should probably have instructions in there
[09:00] <chrisccoulson> i'll push the packaging to bzr and we can do it there
[09:01] <micahg> chrisccoulson: so, do you want to do away with building a source in a separate tree
[09:02] <chrisccoulson> micahg - you mean, like with the embedded tarball we use for everything else?
[09:03] <micahg> chrisccoulson: yes, and build-tree/mozilla for the source decompression/build
[09:04] <chrisccoulson> micahg - the only reason i did it like it is for now is that there doesn't seem to be any native support for embedded tarballs in dh7 (although, we could add the logic to debian/rules ourselves, but that just makes things more complicated)
[09:04] <chrisccoulson> and because we can use bzip compression for the tarballs anyway, it doesn't really matter too much
[09:04] <micahg> chrisccoulson: so you want to switch away from CDBS/dh mix to pure dh7?
[09:05] <chrisccoulson> micahg - we should eventually move to dh7 entirely if we can. now i've done lightning, i can see where some of the limitations might be ;)
[09:07] <micahg> chrisccoulson: k, I've seen some heated CDBS/dh discussions on some l.d.o lists
[09:07] <chrisccoulson> oh, i'd be interested to see those ;)
[09:07] <micahg> chrisccoulson: pkg-multimedia has had a few recently
[09:08] <chrisccoulson> thanks, i'll check them out
[09:08] <micahg> chrisccoulson: I tried gnash and it didn't work, but I think the issue was due to old build-deps, I'll try again with updated build-deps
[09:09] <chrisccoulson> oh, it didn't build?
[09:10] <micahg> chrisccoulson: no, it built and installed and even with the correct alternative, but ubufox didn't recognize it, I was thinking it might have to do with the new binary package name
[09:10] <chrisccoulson> hmmm, that seems a bit strange
[09:10] <chrisccoulson> have you hosted the merge anywhere?
[09:10] <micahg> when I set the alternative manually, it was recognized
[09:11] <micahg> chrisccoulson: no, but I can give you the debdiff from 0.8.8-5
[09:11] <chrisccoulson> yeah, i can take a look at that
[09:13] <micahg> http://paste.ubuntu.com/497567/, I dropped the translation timestamp updates
[09:13] <chrisccoulson> thanks
[09:14] <micahg> chrisccoulson: it was at least recognized before the package name change, it just didn't work
[09:14]  * micahg doesn't understand the pfs yet
[09:15] <micahg> chrisccoulson: I already have an FFe filed, but I needed to provide more info
[15:17] <fta> micahg, did you try my script for the wiki?
[16:51] <dpm> hey chrisccoulson, on bug 632760 is someone looking into merging your patch to po2xpi?
[16:51] <ubot2> Launchpad bug 632760 in language-pack-pt (Ubuntu) (and 2 other projects) "Language variants don't work in Firefox because the language codes are separated with an underscore rather than a hyphen in chrome.manifest (affects: 1) (heat: 437)" [High,Triaged] https://launchpad.net/bugs/632760
[17:22] <chrisccoulson> dpm - i think pitti did it already
[17:22] <chrisccoulson> you might want to check with him though
[17:22] <dpm> chrisccoulson, I'll do, thanks!
[17:30] <fta> dpm, did you try my script for the wiki? i still see the old page for firefox :(
[17:31] <dpm> fta, I had a look at the script but I haven't had the chance to update the pages, as I have to check which FF and TB translations have been merged.
[17:31] <dpm> let me try to do this in a few minutes
[18:01]  * chrisccoulson wonders what on earth the PPA builders are doing
[18:01] <chrisccoulson> long queue, but half of them are idle
[18:03] <chrisccoulson> oh, well, they were a minute ago :/
[18:05] <fta> chrisccoulson, it's because they are now doing the TranslationTemplatesBuildJobs
[18:06] <fta> and they're really bad at balancing the traffic, seems like they do it only once every 15min so if they get a build that take less time, they stay idle until the next cycle
[18:06] <fta> a real waste
[18:07] <micahg> chrisccoulson: fta: there a builder sprint ATM with 2 LP devs
[18:08] <micahg> fta: also, ch-dev/daily was scored down, I had them rescore
[18:09] <fta> micahg, did they say why they did it?
[18:09] <micahg> fta: yeah, there were limited build resources before for lpia, so they lowered it for that arch
[18:10] <fta> weird as that ppa has a low activity
[18:10] <fta> much lower than the other 4
[18:10] <micahg> daily has low activity?
[18:10] <fta> no, -dev
[18:11] <micahg> idk
[18:11] <fta> https://edge.launchpad.net/~kendalltweaver/+archive/peppermint/+build/1968710
[18:11] <fta> ??
[18:12] <micahg> fta: people do silly things :)
[18:13] <chrisccoulson> fta - yeah, i noticed that
[18:13] <micahg> This PPA contains some packages built with precompiled vanilla builds  directly from Mozilla.  For the full source code please visit: http://ftp.mozilla.org/pub/mozilla.org/
[18:13] <chrisccoulson> yet another person who's just bundling pre-compiled firefox binaries
[18:13] <micahg> I think that might violate the PPA TOS, no?
[18:13] <chrisccoulson> possibly, i'm not entirely sure about that tbh
[18:13] <chrisccoulson> if he breaks our installs, then i will poke him in the eyes with a blunt instrument
[18:13] <chrisccoulson> :)
[18:13] <micahg> heh
[18:14] <micahg> well, I should send out an announcement later to the team ML
[18:14] <micahg> I posted to identi.ca yesterday
[18:14] <micahg> k, I'm off to work...bbiab
[18:42] <dpm> fta, I've just updated https://wiki.ubuntu.com/Translations/Wanted/FirefoxDesktop - your script worked perfectly except for getting the Generic Name and Comment headers on the table swapped. I need to run now, but I'll take care of the TB page tomorrow. Thanks!
[18:42] <fta> great
[19:56] <micahg> chrisccoulson: can you have a look at mozilla 580970
[19:57] <ubot2> Mozilla bug 580970 in Theme "Tabs on top with Ubuntu Radiance and Ambiance looks less unified than it could" [Minor,New] http://bugzilla.mozilla.org/show_bug.cgi?id=580970
[20:11] <chrisccoulson> micahg - yeah, i've already tried to find somebody involved with theming to comment on that
[20:11] <chrisccoulson> no joy yet though
[20:11] <micahg> chrisccoulson: thanks
[21:19] <gnomefreak> i still cant get chromium to save passwords even with a new profile and having saved passwords and bookmarks imported
[21:36] <gnomefreak> and now thunderbird is back to being unable to connect to pop and smtp so now i cant get email nor send it.


[05:29] <cpaelzer> bryyce: thanks, one more resolved \o/
[05:29] <cpaelzer> name mapping error ... too early, thanks sergiodj :-)
[07:39] <ExeciN> Is there a way to use cloud-init with a custom configuration without rebuilding the installation image? Can I somehow supply a url with the cloud-init configuration in the kernel command? (probably doing this through the installer's grub menu)
[10:56] <tomreyn> ExeciN: you can use kernel command line     autoinstall ds=nocloud-net;s=http://mywebserver.mytld:myport/     and have the web server serve your cloud-config at the http://mywebserver.mytld:myport/user-data (and an empty /meta-data). note i'm just another user, not a developer.
[12:27] <blackroot> tomreyn | ExeciN: you can use kernel command line     autoinstall ds=nocloud-net;s=http://mywebserver.mytld:myport/     and have the web server serve your cloud-config at the http://mywebserver.mytld:myport/user-data (and an empty /meta-data). note i'm just another user, not a developer.
[12:28] <blackroot> since you were disconnected when he wrote this :P
[15:09] <ExeciN> thanks tomreyn and blackroot
[20:12] <znf> If I want to run a single LXC Container, on a single host, should I even bother with "LXD"?
[20:13] <sarnold> as I understand it, lxd lets you do image-based container things; lxc lets you do recpie-based container things; I think I'd pick whichever one best matches your preferred working style
[20:14] <ravage> the quick answer is yes. its just more convenient
[20:15] <ravage> on my Pi4 i actually use LXC. it works too of course
[20:15] <ravage> but on my ubuntu desktop i run lxd
[20:16] <znf> Every time I want to do LXC/LXD I'm met with this issue being so unclear
[20:16] <znf> And most stuff on the web is a very hit & miss in regards to instructions on both
[20:16] <znf> It really mixes them up together
[20:16] <ravage> and what issue is that?
[20:16] <znf> If you google for "do stuff with lxc"
[20:17] <znf> you'll get instructions with the "lxc" command, but that actually is part of the lxd package
[20:17] <ravage> "lxd init" asks some basic questions and then you can start containers
[20:17] <ravage> after you setup lxd almost all commands start with lxc
[20:17] <ravage> https://linuxcontainers.org/lxd/try-it/
[20:18] <sarnold> znf: heh, yeah, the 'lxc' command to use lxd is *very* frustrating imho :(
[20:18] <znf> also, what about the lxc packages
[20:19] <znf> do I need to install any package separately, with apt, or should I just snap install lxd
[20:19] <ravage> the lxd snap is all your need
[20:19] <ravage> *you
[20:19] <znf> now, wonder if I can actually run lxd 5 with a 18.04 kernel
[20:20] <ravage> i guess you can run the stable version with 18.04
[20:20] <ravage> never tried it. i started using it on 20.04
[20:21] <znf> Name of the storage backend to use (zfs, btrfs, ceph, cephobject, dir, lvm) [default=zfs]:
[20:21] <znf> why the hell does this even default to zfs lol
[20:21] <ravage> it creates an image storage with zfs i think
[20:22] <ravage> to enable snapshots and so on
[20:22] <znf> and what does it actually use?
[20:22] <znf> ooooh
[20:22] <znf> it does a loop device
[20:22] <znf> that's crazy
[20:23] <ravage> i actually have a zfs pool on my system
[20:23] <ravage> but the loop device works just fine
[20:25] <sdeziel> znf: yes, no problem in using LXD 5.0 on 18.04 with whatever kernel
[20:25] <znf> oh, wtf
[20:25] <znf> lxc console attaches to the login console
[20:26] <znf> what's the equivalent of lxc-attach -n
[20:26] <sdeziel> znf: you probably want `lxc shell foo` to give you a bash login
[20:26] <ravage> znf, lxc exec yourcontainer -- bash
[20:26] <znf> ah, 'shell' is fine
[20:26] <ravage> shell exists too
[20:26] <ravage> ^^
[20:26] <sdeziel> both are very similar
[20:26] <znf> it doesn't list "shell" when you -h
[20:27] <sdeziel> znf: that's because `shell` is in fact an alias
[20:27] <znf> I see
[20:27] <sdeziel> znf: it invokes `su -l` inside the instance
[20:27] <znf> great!
[20:28] <ravage> i dont know how big that loop device is by default
[20:28] <znf> I went with 'dir'
[20:28] <ravage> ok
[20:28] <znf> I won't need snapshots on this
[20:28] <ravage> i love my snapshots :D
[20:28] <znf> I have LVM but someone assigned all the space to / already
[20:29] <sdeziel> znf: https://linuxcontainers.org/lxd/docs/master/reference/storage_drivers/
[20:29] <sdeziel> that table should give you a nice overview of what LXD supports in terms of storage
[20:30] <sdeziel> znf: another selling point in favor of LXD is that is supports VMs too ;)
[20:30] <sdeziel> s/that is/that it/
[20:30] <ravage> i never tried that before
[20:30] <ravage> i really should
[20:30] <znf> I'm familiar with them, but I feel dirty about using a loop device
[20:30] <ravage> but i usually only run them on my desktop and virt-manager does a good job atm
[20:30] <znf> and because it's just 1 single container, I'm meh about worrying about them
[20:31] <znf> now, where's that fancy volume mapping
[20:31] <sdeziel> znf: yeah, ideally you'd carve up some dedicated space but the loop device actually perform quite nicely
[20:32] <sdeziel> ravage: my main grip with virt-manager is the XML part
[20:32] <znf> if *someone* didn't allocate all VG space to a single LV... >_<
[20:32] <ravage> sdeziel, yes XML is always annoying :)
[20:32] <znf> k, now, how do I map the host /home/stuff to the guest /home/stuff ?
[20:32] <sdeziel> znf: ext4 supports shrinking if you use a liveusb
[20:32] <znf> I don't have IPMI access on it
[20:33] <znf> and it's located far far away
[20:33] <znf> too much of a hassle
[20:33] <znf> :)
[20:33] <sdeziel> granted
[20:33] <znf> lxc config device add c1 sharedwww disk source=/wwwdata/ path=/var/www/html/
[20:33] <znf> that much?
[20:33] <sdeziel> znf: sounds about right
[20:34] <ravage> ok. i know im just lazy. but how do i fix "LXD VM agent isn't currently running" ? :D
[20:34] <ahasenack> for a vm? Wait a bit
[20:34] <sdeziel> ravage: just wait till the VM finishes booting is usually what you need to do
[20:34] <ravage> oh ok. i was just too fast then :D
[20:34] <ravage> yep. thx
[20:34] <ahasenack> it's indeed slower than non-vms
[20:35] <ahasenack> and most of the time ssh is ready before the agent, so you can already ssh in if you have the creds in place
[20:35] <ravage> im usually fine with containers. but its nice to have the VM option
[20:35] <sdeziel> ravage: you can always do `lxc launch --console=vga --vm ...`
[20:35] <ravage> in case of some kernel related thing a VM is good to have
[20:37] <ahasenack> it's indeed a quick and very convenient way to launch one
[20:37] <ahasenack> not just ubuntu
[20:37] <ahasenack> basically any os out there (linux based)
[20:38] <ahasenack> just use the "images:" remote
[20:38] <sdeziel> yeah, for other OSes, you have to provide the ISO usually as we cannot distribute ready-made Windows VMs :/
[20:39] <ahasenack> just take a look at all that is available in "lxc image list images:"
[20:39] <znf> maybe that will finally change now that MS was forced to do the licensing-per-core modification
[20:39] <ahasenack> centos, alpine, fedora, gentoo (!), opensuse, etc
[20:39] <ahasenack> some I have never heard of even
[20:40] <znf> what's the tcp proxy thingie called
[20:40] <znf> so I can proxy ports on the host to the container
[20:41] <znf> lxc config device add mycontainer myport80 proxy listen=tcp:<IP_ADDRESS>:80 connect=tcp:<IP_ADDRESS>:80
[20:41] <znf> this sounds ok
[20:42] <ravage> You only need that if you need external Access
[20:42] <ahasenack> hah, I didn't know about that :)
[20:42] <znf> yes, I need to make a webserver public
[20:42] <znf> is the <IP_ADDRESS> correct?
[20:42] <znf> that sounds iffy
[20:42] <znf> would my internal nginx actually see the remote IP correctly?
[20:44] <ravage> I don't think it will
[20:45] <znf> hmm
[20:45] <znf> that's bad
[20:45] <znf> how to fix that
[20:46] <sdeziel> znf: you can use the PROXY protocol which NGINX supports, see https://linuxcontainers.org/lxd/docs/master/instances/?highlight=proxy#type-proxy
[20:46] <ravage> yep. with a proxy on the host you should be able to forward the remote IP
[20:48] <znf> very confused
[20:48] <ravage> traefik or varnish are popular here too
[20:48] <ahasenack> iptables DNAT might be an option, perhaps simpler
[20:48] <znf> I don't really want to setup haproxy/traefik etc.
[20:49] <znf> I'd like the stuff to be done via LXC/LXD stuff entirely
[20:49] <ravage> that is usually what you do with containers
[20:49] <ahasenack> you could perhaps launch the container in a network that is exposed already
[20:49] <ravage> or you add the containers to a bridge with your main network interface
[20:49] <ahasenack> yeah, that
[20:49] <znf> It's way too much trouble/effort when I only need 1 port and 1 container
[20:50] <znf> I'd agree if I run something much more complex
[20:50] <znf> but to setup everything just for 1 host and 1 port seems like an overkill
[20:50] <znf> (I also don't have a 2nd public IP address)
[20:51] <ravage> is this a dedicated server in a datacenter or whats the situation?
[20:51] <znf> Yes
[20:51] <ravage> with only one public IP a reverse proxy is the best way to go here really
[20:52] <ravage> the setup is not that difficult
[20:52] <sdeziel> znf: the LXD native proxy thing is what supports the PROXY protocol if you want that, a simpler way is the `nat=true` one but it requires a static IP on the container/VM side
[20:53] <znf> ravage, I know it's not, but I'm setting this up for someone else, I'll not handle it day by day, and I don't want to explain/amke it more complicated
[20:53] <sdeziel> znf: I mean, there is no need for any external components like traefik/haproxy
[20:54] <ravage> znf, did you test what IP your webserver actually logs with the lxc proxy command?
[20:54] <znf> ravage, yeah, <IP_ADDRESS>
[20:55] <znf> I'll try the nat=true stuff
[20:55] <ahasenack> isn't the real IP set in a header actually? You might just need to tweak the server log format string
[20:56] <znf> # lxc config device set container eth0 ipv4.address=<IP_ADDRESS>
[20:56] <znf> Error: Device from profile(s) cannot be modified for individual instance. Override device or modify profile instead
[20:57] <znf> ahasenack, no, there's no "header" being sent by the browser/device itself
[20:58] <ahasenack> the proxy usually injects such a header
[20:58] <ahasenack> a real proxy, I mean, I don't know what lxd is using
[20:58] <sdeziel> znf: try `device override` instead of `device set`
[20:59] <znf> ah, right
[20:59] <sdeziel> ahasenack: you seem to refer to the PROXY protocol header, something that won't be used with `nat=true`
[21:00] <sdeziel> the proxy device supports quite a few different things which can be confusing :/
[21:01] <sdeziel> znf: make sure the expected address shows up in the instance as I'm not sure that can be applied "live"
[21:01] <znf> it was already that IP address
[21:01] <znf> just made sure it was permanent
[21:02] <znf> ah, ok, proxy_protocol=true won't really work out, because there's no ssl certificate :P
[21:03] <znf> and with http:// I get a 400 bad request from the nginx running inside
[21:03] <znf> NAT time I guess
[21:04] <sdeziel> znf: `proxy_protocol=true` only cares about TCP stuff, no SSL involved IIRC
[21:05] <sdeziel> znf: if you use `proxy_protocol=true` you need to tell NGINX that it will receive this protocol instead of regular HTTP(S)
[21:05] <znf> yeah, screw that
[21:05] <znf> nat=true it is
[21:06] <sdeziel> should work and have one less moving part ;)
[21:06] <znf> yup
[21:06] <znf> that's my goal, less moving parts, less things to break
[21:10] <znf> (and less chances this guy will ask me for help in the future!)
[21:16] <sdeziel> engineering oneself out of a job, I like it ;)
[21:17] <znf> I like to NOT be bothered all the time :P
[21:22] <RoyK> There's no place like ::1
[21:23] <sarnold> :)
[21:35] <znf> I prefer <IP_ADDRESS>
[21:35] <znf> I'm old, get off my lawn with ipv6
[21:39] <sdeziel> surprisingly, ::1 is a much smaller home than <IP_ADDRESS> (/128 vs /8)
[21:42] <znf> why can't I nat=tcp:<IP_ADDRESS>
[21:42] <znf> damn it
[21:43] <znf> I mean listen on <IP_ADDRESS> with nat
[21:43] <sdeziel> znf: what if you add a port to it?
[21:43] <znf> nope
[21:44] <znf> (I already do that)
[21:44] <znf> # lxc config device add container port2082 proxy listen=tcp:<IP_ADDRESS>:2083 connect=tcp:<IP_ADDRESS>:2082 nat=true
[21:44] <znf> Error: Invalid devices: Device validation failed for "port2083": Cannot listen on wildcard address "<IP_ADDRESS>" when in nat mode
[21:44] <sdeziel> dang
[21:44] <znf> kinda weird
[21:49] <znf> hm
[21:49] <znf> are containers NOT set to auto-start?
[21:55] <sdeziel> znf: the state of the instances is preserved throughout hosts reboots (running instances will be restarted on boot)
[21:56] <znf> config ... get boot.autostart returns empty
[21:56] <znf> good to know then
[21:57] <znf> I'll still test by rebooting