[11:00] <Kilos> pavlushka  ty so much, do  you have a link I can mail them to use. they were here on freenode before
[11:00] <Kilos> maybe add the link to the topic bar
[11:01] <Kilos> I cant remember if  we made a site for them back then


[07:29]  * scriptwarlock is away: I'm busy
[15:38]  * scriptwarlock is away: going to Mars...
[15:39]  * scriptwarlock is back (gone 00:00:52)
[15:39]  * scriptwarlock is away: standby mode.


[18:22] <jgornick> Hey guys, is it possible to setup my upstart script to do a core dump and automatically restart if a service faults?


[00:00] <asac_> fta: did you create xul/ffox branches yet?
[00:00] <fta> yes
[00:00] <asac_> maybe we want to start using the new approach: trunk is always trunk ;) ... and then when they spin of branches we do branches ;)?
[00:01] <asac_> dont think it matters much ;)
[00:01] <asac_> fta: how about renaming our ffox to 3.5/3.6 finally?
[00:01] <BUGabundo> fta: what do I need to make this vids play on chromium ? http://p.bugabundo.net/
[00:01] <asac_> at least we should get it done before we release 3.5 as stable ;)
[00:01] <asac_> (or even 3.6 ?;)
[00:02] <fta> BUGabundo, it plays fine for me
[00:02] <asac_> we have to manage to get to a point for karmic+1 where we can do major version upgrades for security i guess
[00:02] <BUGabundo> I mean, do I need to enable anything? like codecs?
[00:02] <asac_> otherwise we (I) will have endless pain
[00:03] <asac_> backporting stuff
[00:03] <fta> in /etc/chromium-browser/default i have CHROMIUM_FLAGS="--enable-plugins"
[00:03] <BUGabundo> fta: I prob don't
[00:14] <fta> $ bzr push --remember lp:~mozillateam/firefox/firefox-3.7.head
[00:14] <fta> Using default stacking branch /~mozillateam/firefox/firefox-3.2.head at lp-45207824:///~mozillateam/firefox
[00:14] <fta> Created new branch.
[00:14] <fta> asac, ^^ ??
[00:17] <BUGabundo> asac: any test for me on MM/NM ? I didn't manage to try the diff
[00:21] <asac> fta: whats the question. the stacked branch?
[00:22] <asac> thats because if you dont say anything, bzr will try to stack on top of the branch that is associated with current development focus series in launchpad
[00:22] <asac> stacked branch just meanst that you dont upload everything to launchpad. only those commits not in the stacked branch
[00:22] <asac> ment to make things like branching faster on first upload
[00:23] <fta> i know what a stacked branch is, but i don't know where it's getting that information from
[00:30] <asac> fta: it defaults to what i said. otherwise you can specify it on command line explicitly somehow
[00:30] <asac> but i didnt get that working when i tried
[00:31] <asac> but could be that it was just broken at that point as it was quite hot
[00:31] <asac> BUGabundo: thats ok. the patch wouldnt work anyway. it basically was the other way around
[00:31] <asac> BUGabundo: please sudo apt-get build-dep modemmanager ... then git clone the modemmanager upstream branch and run the following commands:
[00:31] <asac> sh autogen.sh --prefix=$HOME/local_mm
[00:32] <asac> make
[00:32] <asac> make install
[00:32] <asac> (if last command fails because of permissions, just run sudo make install, but ry without first)
[00:32] <asac> then i give you a patch that adds more debugging output
[00:32]  * BUGabundo awakes
[00:32] <asac> BUGabundo: cloning mm is: git clone git://anongit.freedesktop.org/ModemManager/ModemManager
[00:33] <asac> cd ModemManager
[00:33] <fta> http://paste.ubuntu.com/253405/
[00:33] <asac> ... then the autogen stuff and so on from above
[00:33] <BUGabundo> asac: calm down
[00:33] <asac> fta: looks good
[00:33] <BUGabundo> I'm still adding a source to my source.list
[00:33] <asac> BUGabundo: the whole procedure will take 3 minutes
[00:33] <asac> ;)
[00:33] <asac> (after installing build-deps)
[00:33] <fta> i mean, the bot is ready
[00:34] <asac> fta: kick it off ;) ... or does it have a --dry-run feature ;)
[00:34] <fta> nope
[00:34] <asac> was kidding
[00:34] <asac> fta: howa bout renaming our ffox branches?
[00:35] <asac> do we want to defer that until this is set up?
[00:36] <fta> yes, esp. that i'm not there this w-e
[00:36] <asac> ok lets defer it then
[00:39]  * BUGabundo waits for aptitude to finish updating
[00:43] <fta> #include "third_party/zlib/contrib/minizip/unzip.h"
[00:43] <fta> #include "third_party/zlib/contrib/minizip/zip.h"
[00:43] <asac> well done ;)
[00:43] <fta> grrr, we don't have that in our system zlib dev
[00:43] <asac> minizip sounds like a different project?
[00:44] <asac> apt-cache search minizip
[00:44] <asac> zlib-bin - compression library - sample programs
[00:44] <asac> odd
[00:44] <asac> ;)
[00:44] <asac> http://www.winimage.com/zLibDll/minizip.html
[00:44] <asac> winimage?
[00:44] <asac> Now, with version 1.23 and 1.14 of zLib, the Minizip library is inlucded in the contrib/minizip directory.
[00:44] <BUGabundo> step one done
[00:44] <asac> BUGabundo: my own step 1?
[00:44] <asac> the build-dep?
[00:44] <BUGabundo> yes
[00:44] <fta> !info zlib1g-dev
[00:45] <BUGabundo> now git
[00:45] <asac> so do we have 1.23?
[00:45] <BUGabundo> sudo apt-get install git-core
[00:45] <asac> You need the source code of Zlib (zlib123.zip  or zlib-1.2.3.tar.gz. Fo
[00:45] <BUGabundo> bash: git: command not found
[00:45] <BUGabundo> bah
[00:45] <asac> what a version mess ;)
[00:45] <fta> !info zlib-bin
[00:45] <fta> no idea
[00:45] <asac> i assume we have 123 aka 1.2.3 aka 1.23 ;)
[00:46] <asac> seems the 123 name is for old windows crap ;)
[00:46] <asac> guess no long names supported;)
[00:47] <fta> so i can't drop the zlib sources from the tarball :P
[00:47] <asac> zlib-<IP_ADDRESS>.dfsg$ ls contrib/minizip/
[00:47] <asac> ChangeLogUnzip	ioapi.c  iowin32.c  Makefile   minizip.c  mztools.h  unzip.h  zip.h
[00:47] <asac> crypt.h		ioapi.h  iowin32.h  miniunz.c  mztools.c  unzip.c    zip.c
[00:48] <asac> feels like we need to package the headers up somewhere
[00:48] <asac> let me check
[00:48] <fta> they are not shipped in -dev
[00:49] <asac> i see that ;)
[00:49] <asac> just want to check why
[00:50] <BUGabundo> step two brgan
[00:50] <asac> fta: they build it, but dont make install it for some reason in rules
[00:50] <BUGabundo> git complete
[00:51] <asac>        $(MAKE)
[00:51] <asac>         $(MAKE) CC=$(DEB_HOST_GNU_TYPE)-gcc OPT="$(CFLAGS)" -C contrib/minizip
[00:51] <asac> but
[00:51] <asac> just
[00:51] <asac>         $(MAKE) prefix=$(CURDIR)/debian/tmp/usr install
[00:51] <asac>         install -d debian/tmp/lib
[00:51] <asac> prefix?
[00:51] <asac> sounds bogus
[00:51] <asac> ;)
[00:51] <asac> DESTDIR
[00:51] <asac> folks dont use prefix for that ;)
[00:51] <fta> indeed
[00:51] <asac> might not matter, but for libtool and stuff it hurts
[00:52] <BUGabundo> making
[00:52] <asac> pfft
[00:52] <asac> cat contrib/minizip/Makefile | pastebinit
[00:52] <asac> http://paste.ubuntu.com/253416/
[00:52] <asac> its not ment to be installed as it seems ;)
[00:53] <asac> its not even a lib or something. just a binary.
[00:53] <BUGabundo>  /usr/bin/install -c -m 644 77-mm-ericsson-mbm.rules 77-mm-zte-port-types.rules '/lib/udev/rules.d'
[00:53] <BUGabundo> /usr/bin/install: cannot remove `/lib/udev/rules.d/77-mm-ericsson-mbm.rules': Permission denied
[00:53] <BUGabundo> /usr/bin/install: cannot remove `/lib/udev/rules.d/77-mm-zte-port-types.rules': Permission denied
[00:53] <BUGabundo> make[3]: *** [install-udevrulesDATA] Error 1
[00:54] <BUGabundo> guess I need sudo
[00:54] <asac> so chromium rips stuff out of existing binaries now
[00:54] <asac> BUGabundo: yeah
[00:54] <BUGabundo> done
[00:54] <asac> BUGabundo: ok after that you should be able to start the build modemmanager like sudo ./src/modem-manager --debug (after stopping NM, killing mm etc. as usually)
[00:55] <asac> so basically similar to how you did before ... just with ./src/modem-manager ... instead of just modem-manager
[00:55] <BUGabundo> ok
[00:55] <asac> BUGabundo: check that it works and then wait for 2-3 minutes ;)
[00:55] <asac> have to run somewhere first
[00:56] <BUGabundo> brb
[01:04] <asac> BUGabundo: so wget http://paste.ubuntu.com/253420/plain/
[01:04] <asac> and apply the file like: patch -p1 < FILENAME
[01:04] <asac> (in ModemManager dir)
[01:04] <asac> make; sudo make install
[01:11] <asac> BUGabundo: wait a sec
[01:12] <asac> http://paste.ubuntu.com/253422/plain/
[01:12] <asac> rather use that one
[01:12] <asac> the other fails to build ;) ... hackish me
[01:12] <asac> BUGabundo: still there ;)?
[01:26] <asac> fta: did anyone ever complain about our move to migrate daily users to 3.5?
[01:26] <asac> except the one who catched the temporary issue?
[01:28] <fta> nope
[01:28] <asac> odd
[01:29] <asac> maybe noone uses < jaunty
[01:29] <asac> or it was a perfect job ... what i cannot yet believe
[01:29] <fta> https://edge.launchpad.net/builders/
[01:29] <asac> too bad ... armel dead
[01:29] <asac> :/
[01:30] <asac> i guess we will never get tbird out
[01:30] <asac> but all dailies ;)
[01:30] <asac> makes me a bit happier
[01:30] <asac> the armel situation frightens me though for sure
[01:31] <asac> fta: hmm. actually i think we need to put 3.0 in the daily for the < karmic users to get fully migrated
[01:31] <asac> now i am not even sure what state they are in
[01:31] <asac> ;)
[01:33] <asac> i think we dont have enough distinct icons for dailies anymore
[01:33] <asac> shiretoko branding for 3.5 ... minefield for 3.6 ... 3.7
[01:33] <asac> granpardiso fo 3.0 ;)
[01:33] <asac> we need to put the version on it
[01:33] <asac> good that we can edit the icons ;)
[01:34] <asac> maybe we want to patch the number in during build by getting it automagically ?
[01:35] <fta> eh?
[01:36] <fta> gasp http://launchpadlibrarian.net/30345461/buildlog_ubuntu-karmic-i386.firefox-3.7_3.7~a1~hg20090814r31579%2Bnobinonly-0ubuntu1~umd1_FAILEDTOBUILD.txt.gz
[01:36] <fta> Applying patch awesome_browser_branding_install.patch
[01:36] <fta> patching file browser/installer/unix/packages-static
[01:36] <fta> Hunk #1 FAILED at 273.
[01:38] <asac> convert -font helvetica -fill black -pointsize 30 -draw 'text 70,25 "3.6"' firefox-3.6.png firefox-3.6-new.png
[01:38] <asac> guess thats not the best approach ;)
[01:39]  * asac wonders if one can teach quilt to dump the .rej files after failure so one can see how bad it is in the build log
[01:41]  * asac checks out the latest branches
[01:55] <asac> fta: 3.7 depends on 1.9.2-dev
[01:56]  * asac looks at the packages patch
[01:56] <fta> bad
[01:56] <fta> yep, missed that one
[01:56] <fta> fixing
[01:58] <fta> asac, ^^ fixed
[01:58] <fta> asac, #442
[01:59] <fta> woww, 442 commits for a single package :P
[01:59] <asac> ok let me update then before committing patch fix
[01:59] <asac> yeah. things getting old ;)
[02:00] <asac> now i cannot test build anymore ;)
[02:00] <asac> hehe
[02:01] <asac> fta: so do we stop documenting diverged patches in changelog for 3.7+ ?
[02:01] <asac> i mean unless for things that are getting released in to the archive
[02:01] <fta> we should, it's useless for the end users
[02:02] <fta> bzr log is enough
[02:02] <asac> ok i agree. thats why i am asking
[02:02] <fta> lol chromium, 284 commits in less than 280 days
[02:03] <fta> maybe i should give it a rest and stop improving it
[02:04] <asac> sometimes going slower, but bigger steps is more efficient. yes.
[02:04] <asac> especially to prevent burnout ;)
[02:05] <fta> xulrunner-1.9.3 amd64 is ready, if it's the one you need
[02:05] <asac> but there also is the risk, that you get distracted by all the new time and the fall behing ;)
[02:05] <asac> fta: no. i already committed stuff
[02:09] <asac> fta: ok 3.6 seems to build ... /me should have looked at the real state
[02:10] <asac> why dont they display the puzzle piece on frontpage ;)
[02:10] <fta> 3.6?
[02:10] <asac> fta: wanna kick 3.7 again=
[02:10] <asac> ?
[02:10] <asac> https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa
[02:10] <asac> i looked there and thought 3.6 had the same brokenness
[02:10] <asac> but it was wait depend
[02:10] <fta> yes, it's been like that for months
[02:10] <asac> i know
[02:11] <asac> i was just a bot and thought they probably landed stuff on both branches
[02:11] <asac> most likely we will see the same breakage in a few days there too
[02:13] <asac> so bugabundo probably failed ;)
[02:16] <fta> http://code.google.com/p/chromium/issues/detail?id=19157
[02:23] <pace_t_zulu> fta, you there?
[02:23] <fta> sort of
[02:24] <pace_t_zulu> fta: would you mind pastebining your ~/.dput.cf file?
[02:24] <asac> thx for rekicking 3.7 ;)
[02:24] <asac> hmmm. why did todays prism build just fail on karmic?
[02:25] <asac> run-mozilla.sh: Cannot execute ../../dist/bin/shlibsign.
[02:26] <asac> why is that in there?
[02:26] <asac> nss leftover?
[02:27] <fta> pace_t_zulu, http://paste.ubuntu.com/253445/
[02:27] <fta> old style probably
[02:29] <pace_t_zulu> fta, ty
[02:33] <fta> asac, Estimated repository size: 9.0 GiB (90.41%) of 10.0 GiB
[02:33] <asac> moz?
[02:33] <fta> yes
[02:33] <asac> yeah. we should bump it
[02:35] <asac> anyone ever complained ... yet?
[02:37] <fta> about what?
[02:37] <asac> resource consumption ;)
[02:42] <fta> no
[02:47] <Jazzva> fta: I think I fixed prism for karmic daily (couldn't sleep, so I got back to that)
[02:47] <asac> Jazzva: why did it fail ?
[02:47] <Jazzva> what does $(wildcard $(MOZ_XPI_FILE)) do?
[02:47] <asac> Jazzva: probably checks if a file exists
[02:47] <asac> if it doesnt exist it returns empty
[02:48] <asac> otherwise the filename
[02:48] <Jazzva> because of change in mozilla-devscripts "$(MOZ_XPI_FILE)" => "$(wildcard $(MOZ_XPI_FILE))"
[02:48] <asac> or a list of  filenames if the XPI_FILE would be a pttern
[02:48] <asac> let me check
[02:49] <Jazzva> well, I noticed prism build on jaunty (which has m-d 0.12), and failed in karmic, which has 0.14, and I looked into diff and played around a bit, and found that after returning to $(MOZ_XPI_FILE) it builds locally
[02:49] <Jazzva> s/prism build/prism built/
[02:50] <pace_t_zulu> :/
[02:50] <asac> Jazzva: maybe this would help too: http://paste.ubuntu.com/253451/ ?
[02:51] <Jazzva> asac: I'll try that now
[02:54] <fta> all my attempts to make the chromium tarball smaller are ruined after a few days.. http://www.sofaraway.org/ubuntu/tmp/chromium-tarballs-1.png
[02:54] <asac> fta: "all" is kind of an exaggeration
[02:55] <Jazzva> asac: not working...
[02:55] <asac> in nature nothing is a straight line
[02:55] <asac> Jazzva: same issue?
[02:55] <Jazzva> mhm
[02:57] <fta> asac, I drop more that 50% of the files now
[02:58] <asac> Jazzva: http://paste.ubuntu.com/253453/ that works for me (e.g. make echo)
[02:58] <fta> and i completely skip some huge deps (not counted in the 50%)
[02:58] <asac> Jazzva: o sorry. remove the $(..) from the calls
[02:59] <asac> e..g just $(call XPI_FILE)
[02:59] <asac> but shouldnt matter
[02:59] <asac> i mean the previous worked too
[02:59] <asac> http://paste.ubuntu.com/253454/
[02:59] <asac> Jazzva: what is MOZ_XPI_FILE in prism?
[02:59] <Jazzva> asac: http://paste.ubuntu.com/253455/ here's the output :)
[02:59] <asac> Jazzva: you need to put the file in the PWD named as Makefile
[03:00] <asac> or use make -f FILENAME echo
[03:00] <asac> hmm
[03:00] <asac> but you have 1.2.3. ;)
[03:00] <asac> odd
[03:00] <Jazzva> yes...
[03:00] <asac> make --version
[03:00] <asac> GNU Make 3.81
[03:00] <Jazzva> though, when I type "man sh", it shows me dash's man page...
[03:00] <Jazzva> but I thought dash is default
[03:00] <asac> oh
[03:01] <asac> works in dash too
[03:01] <asac> Jazzva: is that the output from the last thing i pasted?
[03:01] <Jazzva> now I'm confused...
[03:01] <Jazzva> asac: yes
[03:01] <asac> http://paste.ubuntu.com/253454/ ?
[03:02] <asac> http://paste.ubuntu.com/253454/plain/ ;)
[03:02] <asac> Jazzva: oh
[03:02] <Jazzva> asac: http://paste.ubuntu.com/
[03:02] <asac> Jazzva: you need a file called COPYING in the current dir ;)
[03:03]  * asac feels completely off ;)
[03:03] <Jazzva> hmm... ok, that was it :)
[03:03] <asac> wildcard COPYING doesnt give you anything if the file doesnt exist
[03:03] <asac> which is the principal idea
[03:03] <asac> Jazzva: so what is MOZ_XPI_FILE in prism?
[03:03] <Jazzva> refractor.xpi,
[03:04] <Jazzva> it's specifically named so in debian/rules, so xpi.mk should use that...
[03:04] <asac> and does that exist?
[03:04] <asac> Jazzva: maybe a typo?
[03:04] <Jazzva> asac: well, it should exist once it's build (which is before unzip)
[03:04] <Jazzva> *built
[03:04] <asac> but does it exist in top level dir?
[03:04] <Jazzva> asac: let me check
[03:05] <Jazzva> asac: no, it's in ./dist/xpi-stage/refractor.xpi
[03:06] <asac> http://paste.ubuntu.com/253458/
[03:06] <asac> Jazzva: we should do that
[03:06] <asac> hmm. so thats why its broken everywhere
[03:06] <asac> i thought we copy it to top level dir in some kind of post-build rule in rules
[03:06] <Jazzva> asac: well, at least now it's only broken in karmic :)
[03:07] <asac> Jazzva: but thats odd
[03:07] <asac> maybe < karmic it failed silently?
[03:07] <asac> and we just dont have refactor xpi packaged?
[03:07] <Jazzva> asac: prism built ok in PPA in < karmic
[03:08] <asac> yes. but it could just have failed silently somehow
[03:08] <asac> prism is more than the .xpi
[03:08] <asac> the .xpi is just a supplemental thing
[03:08] <asac> Jazzva: so refractor.xpi:: build/prism
[03:08] <asac> check that out
[03:09] <asac> that basically should take care that its copied to top level dir
[03:09] <asac> you sure its not in there?
[03:09] <asac> (in debian/rules)
[03:09] <Jazzva> asac: unzip -d temp-xpi-SeaQkIOD ./refractor.xpi ... that's from jaunty log...
[03:09] <asac> yes
[03:09] <asac> but does it exist in karmic too?
[03:10] <asac> it should
[03:10] <asac> i mean we copy it right there in the rules
[03:10] <asac> hmm
[03:10] <asac> maybe the dependency does not properly trigger
[03:10] <asac> oh yeah
[03:10] <Jazzva> asac: yeah, it was copied to top-level in jaunty
[03:11] <asac> i think i know whats going on
[03:11] <asac> the wildcard evaluates to NOTHING
[03:11] <asac> and hence the copy never happens
[03:12] <Jazzva> I see...
[03:12] <asac> stamp-unzip-%: $(XPI_FILE)
[03:12] <asac> that one does not trigger the copy from the prism rule because at that time the .xpi does not even exist
[03:14] <Jazzva> so, to remove wildcard from XPI_FILE, and to test if that file exists in stamp-unzip-%, and to give error if it doesn't?
[03:15] <asac> i think we should use a different hook in prism
[03:15] <asac> that will fix it
[03:15] <asac> and then also think about what to do with the $(XPI_FILE) requirement in xpi.mk
[03:15] <fta> http://www.flickr.com/photos/36015194@N00/2260529558
[03:16] <asac> Jazzva: try to hook that copy thing into common-post-build::
[03:17] <asac> instead of refractor.xpi::
[03:17] <asac> you dont need the build/prism part then
[03:17] <asac> nice fox
[03:18] <asac> must be cold there ;)
[03:19] <Jazzva> ok, trying that now
[03:41] <asac> Jazzva: ok i am off. we can check that tomorrow. but i think the common-post-build:: target is the way to go
[03:42] <Jazzva> asac: ok... i'm off too. at least we know why it fails :).
[03:42] <Jazzva> good night
[03:42] <asac> yeah
[03:42] <asac> 'night
[04:29] <pace_t_zulu> fta, still around?
[11:04] <bdrung> asac: do you have time to merge the new upstream release branch of adblock-plus?
[20:26] <andv> hi all
[20:26] <andv> asac, I've sent a mail for you
[20:26] <andv> asac, feel free to read it when you have some free time
[22:38] <BUGabundo> boas
[22:38] <BUGabundo> asac: I'm back to good old really old working version
[22:38] <BUGabundo> :)
[23:16] <asac> BUGabundo: did you get the log at least?
[23:16] <BUGabundo> yes
[23:17] <BUGabundo> forgot to upload it :)
[23:17] <asac> good
[23:17] <asac> where?
[23:17] <asac> pff
[23:17] <BUGabundo> well for my defence, I was networkless
[23:17] <BUGabundo> :)))
[23:17] <BUGabundo> to the bug report, of course
[23:17] <asac> id?
[23:17] <BUGabundo> no idea
[23:17] <BUGabundo> was going to ask you the same
[23:17]  * BUGabundo turns to FF awesome bar
[23:18] <asac> why do you think i remember your bug id more than you ;)
[23:18] <asac> bug 413333
[23:18] <asac> bug 412570
[23:18] <asac> luckily modemmanager bug list is short ;)
[23:18] <BUGabundo> https://bugs.edge.launchpad.net/ubuntu/+source/modemmanager/+bug/413333/
[23:18] <BUGabundo> correct
[23:18] <asac> BUGabundo: there is no new log
[23:18] <BUGabundo> I filed it on MM??
[23:19] <asac> yes
[23:19] <BUGabundo> wasn't it on NM?
[23:19] <asac> no
[23:19] <BUGabundo> asac: ill upload it NOW
[23:19] <asac> there is no new log BUGabundo
[23:19] <asac> ah ok
[23:19] <BUGabundo> asac: I had no network
[23:19] <BUGabundo> until now
[23:19] <BUGabundo> and was way all day
[23:19] <BUGabundo> driving karts
[23:19] <BUGabundo> and taking pics with my android
[23:19] <asac> just because of this modemmanager thing? cant believe it ;
[23:19] <asac> ah ;)
[23:19] <BUGabundo> asac: http://p.bugabundo.net/
[23:21] <asac> use ogg
[23:21] <BUGabundo> upload
[23:21] <BUGabundo> asac: I wish Android provided that codec
[23:21] <BUGabundo> not even PNG :(
[23:21] <asac> kart on sand?
[23:21] <asac> wow
[23:21] <asac> we only have tarmac things here ;)
[23:21] <asac> oh thats miniature ;)
[23:22] <BUGabundo> right
[23:22] <BUGabundo> remote controled cars
[23:22] <asac> BUGabundo: thats not a log with my patch
[23:22] <BUGabundo> some of those go as fast as 80KM/H
[23:23] <asac> yeah ... but wouldnt be a sport for me ;)
[23:23] <BUGabundo> -rw-r--r-- 1 bugabundo bugabundo 5.2K 2009-08-15 01:00 /home/bugabundo/Desktop/mm2.log.txt
[23:23] <BUGabundo> it must be
[23:23] <BUGabundo> its the one I ran last night before bad
[23:28] <BUGabundo> asac: is it not correct?
[23:28] <asac> doesnt feel correct
[23:28] <asac> BUGabundo: did you capture all output on console?
[23:28] <BUGabundo> no
[23:28] <BUGabundo> that's the log from MM
[23:29] <asac> BUGabundo: but how did you produce the log?
[23:29] <BUGabundo> asac: $ sudo killall modem-manager; sudo ./src/modem-manager --debug 2>&1 > /tmp/mm2.log.txt
[23:29] <asac> yeah
[23:30] <asac> you sure you did build it and ran sudo make install ?
[23:30] <asac> the log is crazy
[23:30] <asac> i mean it uses the same registration method it used in the successful log
[23:30] <asac> and there is no sign of any of my g_message additions
[23:31] <BUGabundo> *shrugs*
[23:31] <BUGabundo> asac: AFAIK and can remember from such a late hour, yes I run it all OK
[23:31] <BUGabundo> I even reported it, as I was doing it
[23:31] <asac> BUGabundo: in the build tree run git diff
[23:31] <asac> and paste what you get
[23:32] <BUGabundo> remember I said make install failed and that I used sudo make install??
[23:32] <asac> yes
[23:32] <asac> buzt that was the first build
[23:32] <asac> before applying the patch
[23:32] <asac> you most likely never applied the patch ;)
[23:32] <BUGabundo> asac: nothing out of git diff
[23:32] <asac> yes then you didnt even finish what i said ;)
[23:32] <asac> you tested the test build and not the one with the patch
[23:32] <asac> but letes do that later
[23:32] <asac> not today ;)
[23:33] <BUGabundo> okay
[23:33] <asac> enjoy your net
[23:33] <asac> (for now)
[23:33] <BUGabundo> but I would raise the priority
[23:33] <BUGabundo> anyone with NM from archive has no MM working
[23:33] <BUGabundo> another user on +1 just reporting it too
[23:33] <asac> not many complains yet ;)
[23:33] <asac> two bugs ... thjats it
[23:33] <asac> but most probably filed against NM
[23:34] <BUGabundo> prob
[23:34] <BUGabundo> ppl have no idea what MM is :)
[23:35]  * penguin42 wiggles
[23:36] <BUGabundo> hey penguin42
[23:36] <BUGabundo> asac: you have another extra 1 min?
[23:36] <BUGabundo> probs with 3.0 -> 3.5 migration
[23:36] <asac> most likely i cannot be helpful
[23:36] <penguin42> bug 414139
[23:36] <BUGabundo> seems it deletes existing 3.5 profiles :(
[23:37] <BUGabundo> asac: it is all fta handy work??
[23:39] <asac> thats bad luck for him then ;)
[23:40] <asac> i dont think its a problem. for now i think that he just is confused and actually wanted to use 3.0
[23:40]  * penguin42 has been running 3.5 for a few months
[23:40] <BUGabundo> asac: I _think_ I was affected too, and may have lost 3 one year old profiles :(
[23:40]  * BUGabundo checks
[23:41] <asac> we dont delete anything in that script
[23:41] <asac> so it cant be gone
[23:41] <penguin42> BUGabundo: That makes me feel a lot better, I'd been feeling guilty for not checking this earlier when you told me last week
[23:41] <penguin42> asac: I'm up for suggestions where to look
[23:41] <BUGabundo> right
[23:41] <asac> read the bug
[23:41] <BUGabundo> I have NO 3.5 otet
[23:42] <asac> if you disagree read the script and find the bug ;)
[23:42] <BUGabundo> other then the test migration one
[23:42] <asac> BUGabundo: thats because your 3.5 folder was renamed to firefox
[23:42] <asac> and the previous firefox renamed to somehting else
[23:42] <asac> so you are now using it
[23:42] <BUGabundo> asac: I'm cecking firefox
[23:42] <BUGabundo> only one profile there
[23:43] <BUGabundo> firefox.3.0-replaced/
[23:43] <penguin42> asac: firefox -ProfileManager only shows one profile
[23:43] <BUGabundo> not firefox.3.*5*-replaced/
[23:43] <BUGabundo> penguin42: that's expected
[23:43] <BUGabundo> asac: I'm using 3.6 :)
[23:44] <penguin42> asac: I grep'd for one of the terms that was in the old firefox 3.5 bookmarks and it wasn't there
[23:45] <asac> BUGabundo: thats all fine for you
[23:45] <penguin42> confusingly the firefox directory has two  blah.default directories, with one of them containing very little
[23:46] <asac> penguin42: yes ... that means you have two profiles
[23:46] <asac> that might be a bug indeed
[23:46] <penguin42> hmm time to give you a find .mozilla output
[23:46] <asac> :q
[23:46] <asac> penguin42: no need
[23:47] <penguin42> ok
[23:47] <asac> penguin42: whats in your firefox/profiles.ini ?
[23:47] <asac> actually its in the firefox folder, so there probably isnt really a bug in it
[23:48] <asac> penguin42: do you hav two profiles in there?
[23:48] <penguin42> asac: The profiles.ini points to my 6zz0n38z.default which is the only one
[23:48] <asac> do the names match the folders that are in firefox/ ?
[23:48] <asac> penguin42: kind of odd. add a new entry like
[23:48] <asac> [Profile1]
[23:48] <asac> Name=test
[23:48] <asac> IsRelative=1
[23:48] <asac> Path=le52tk7a.test
[23:48] <asac> with the other name in Path
[23:48] <asac> and start profile manager ... then select "test"
[23:48] <asac> most likely thats the profile you are missing?
[23:49] <asac> whatever you do also backup stuff ;)
[23:49] <penguin42> asac: No, the other directory, hxj2fgu2.default only has adblockplus and localstore.rdf in - no other contents
[23:50] <asac_> reconnect
[23:50] <asac_> 00:49 < penguin42> asac: No, the other directory, hxj2fgu2.default only has adblockplus and localstore.rdf in - no other contents
[23:50] <asac_> -> then i dont know.
[23:50] <asac_> check the copy script
[23:50] <penguin42> asac_: I'm fairly sure the old 3.5 stuff has gone
[23:51] <penguin42> where does the script live?
[23:51] <asac_> penguin42: sure you didnt use firefox-3.6?
[23:51] <asac_> often and add the bookmarks there?
[23:51] <penguin42> about says 3.5.2
[23:51] <asac_> penguin42: i mean before
[23:51] <asac_> do you have firefox-3.6 installed?
[23:52] <penguin42> no
[23:52] <asac_> maybe you used that rather than 3.5 and so your 3.5 profile was pretty empty still
[23:52] <asac_> the script is /usr/bin/firefox
[23:52] <asac_> there lives the code that does the migration
[23:52] <penguin42> never used it
[23:52] <asac_> but if you have firefox-3.0-replaced then it just copied the firefox-3.5 to firefox after moving that to the -replaced file
[23:53] <penguin42> ok, go back a few steps
[23:54] <penguin42> prior to this script, if I was running both firefox and firefox 3.5 where would they keep there stuff?
[23:54] <penguin42> sorry, firefox-3.0 and firefox-3.5
[23:54] <asac_> .mozilla/firefox-3.5 and firefox
[23:54] <asac_> the latter for 3.0
[23:54] <penguin42> ok
[23:54] <BUGabundo> asac firefox-3.0-replaced is a bad name for a 3.5 profile :)
[23:56] <asac_> BUGabundo: itst the old firefox 3.0 profile
[23:56] <asac_> if you would have said: "i want to keep using the stable firefox profile" then there would have been firefox-3.5-obsoleted
[23:57] <asac_> or -abandoned i think
[23:59]  * penguin42 reads script


[07:34] <arraybolt3> Doing my first Ubuntu desktop QA test, and I've hit two bugs during the encrypted installation routine. One of the bugs was just discovered in passing, but the other one directly contradicted a testcase condition. However, the installation succeeded. Do I submit a passed or failed result on the QA tracker?
[07:50] <arraybolt3> Also, does anyone here know what package handles decrypting an encrypted disk when booting an encrypted Ubuntu installation?
[07:53] <rbasak> arraybolt3: the main package is cryptsetup, but there might be others involved
[07:54] <rbasak> arraybolt3: I'm not particularly familiar with the QA process, but it seems appropriate to submit a failed result if you think a testcase condition was directly contradicted. Since in the general case installation "succeeded" isn't the only desired result, and that's the point of the testcases being more specific I think.
[07:56] <arraybolt3> rbasak: Thank you! I hit a second, much more severe testcase contradiction at the very end of the test, so I think I'm definitely going to mark it as failed. Man, this is fun! Thank you guys for all the hard work you do!
[07:57] <rbasak> Thank you for testing!
[10:48] <rbasak> Did something change in dep8 infra recently? I'm seeing failures on arm64 that require "Internet" but is now getting a 403. AFAICT, these used to work.
[11:01] <jbicha> rbasak: https://irclogs.ubuntu.com/2022/05/09/%23ubuntu-release.html#t12:32
[11:03] <Unit193> jbicha: FYI, RC bug #1002237 still affecting gnome-packagekit.
[11:04] <jbicha> Unit193: wrong bug number?
[11:04] <Unit193> Debian #1002237
[11:09] <jbicha> Unit193: that bug was kinda low priority for me. Someone should report it to https://gitlab.gnome.org/GNOME/gnome-packagekit/-/issues though
[11:09] <Unit193> I mean, it's an RC bug, got it kicked out of testing already so it's been a time...
[11:11] <rbasak> jbicha: ah. I did see that message but failed to connect it today. Thanks!
[11:21] <mardy> bdmurray: hi! I just added a comment about the verification of https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1959375 ; do I also need to change the "verification-needed" tag into "verification-done", since I verified it on all releases?
[11:44] <jbicha> Eickmeyer: should we close LP: #1967020 now?
[11:49] <rbasak> mardy: if you consider the verification to be done for the entire bug (across all releases etc) then please do change verification-needed to verification-done
[11:50] <mardy> rbasak: ok, thanks, will do that now
[12:12] <ahasenack> morning
[12:28] <ahasenack> hi, can someone take a look at this ust armhf test which seems to be stuck? I don't find it in the /running page, and this upload is 6 days old: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ust
[12:36] <ahasenack> ok, I see the armhf dep8 queue is at over 13k tests :/
[13:52] <Eickmeyer> jbicha: Yeah, I got it.
[14:15] <rbasak> ginggs: o/ thank you for looking but I'm not sure you followed my icinga2 situation. I reproduced the situation locally. It occurs if I just call autopkgtest - no britney involved.
[14:17] <rbasak> And it isn't about test dependencies as such. It's that the proposed source tree is used even when testing a binary from the release pocket.
[14:17] <ginggs> rbasak: i believe that's because of the fallback "WARNING: Test dependencies are unsatisfiable with using apt pinning. Retrying with using all packages from kinetic-proposed"
[14:18] <rbasak> ginggs: it's still wrong though?
[14:18] <rbasak> If it's going to fall back, it should use the source tree from the thing it's falling back to.
[14:19] <ginggs> yes, the fallback is not perfect, but i think it's better than no fallback
[17:04] <bdmurray> seb128: Can you sort out canary builds for kinetic? 'E: The repository 'http://ppa.launchpad.net/ubuntu-desktop/canary-image/ubuntu kinetic Release' does not have a Release file.'
[17:28] <bdmurray> mardy: changing the non-release specific tag is not necessary for the SRU process. I saw a question about this earlier in the week too.
[17:29] <bdmurray> The idea behind the verification-needed tag is that people interested in doing sru-verification could subscribe to bugs tagged verification-needed or search for those.
[17:29] <bdmurray> Rather than searching for verification-focal-needed and verification-jammy-needed etc....
[17:30] <bdmurray> But the SRU team only cares about the per release tags.
[17:39] <dbungert> for a package that fails to build in the first place, and that I believe would build now, what's the procedure?  Ask a core-dev to trigger a new build in launchpad? (is that a thing?) https://launchpad.net/ubuntu/+source/lsvpd/1.7.14-1/+build/23585022
[17:40] <ginggs> dbungert: yes, and retried now
[17:41] <dbungert> ginggs: thanks!
[17:56] <seb128> bdmurray, I fixed the canary issue this morning I think, waiting for the next build to see if it works
[17:56] <seb128> bdmurray, could you maybe trigger a build so if there is another issue I might have a go to fix it before the weekend?
[18:03] <bdmurray> seb128: Sure, I'll kick one off now
[18:55] <sergiodj> mwhudson: hey, I'm working on https://bugs.launchpad.net/ubuntu/+source/golang-1.18/+bug/1973107 (which is affecting telegraf).  I'll likely have to do a two-stage upload to fix it, but I'll let you know when I have something ready
[18:55] <sergiodj> sarnold: ^ (re. the telegraf FTBFS)
[19:36] <mwhudson> sergiodj: ok cc jawn-smith
[19:36] <mwhudson> sergiodj: i don't really see why a two stage upload is needed but fine :)
[19:37] <jawn-smith> o/
[19:37] <sergiodj> mwhudson: golang depends on itself and fails to build on ppc64el when it tries to run its link tests
[19:37] <mwhudson> sergiodj: is it going into a point release? can you add PKG_NO_PNG_MANGLE (check spelling pls) while you're at it? for  https://bugs.launchpad.net/ubuntu/+source/golang-1.18/+bug/1972735
[19:38] <mwhudson> sergiodj: ugh, that sounds like pretty bad isolation in the test suite?
[19:38] <sergiodj> mwhudson: yeah, point release.  sure thing, I can address that as well
[19:38] <jawn-smith> sergiodj: I did a test build in this PPA with the PKG_NO_PNG_MANGLE
[19:38] <jawn-smith> https://launchpad.net/~jawn-smith/+archive/ubuntu/golang-latest
[19:39] <sergiodj> mwhudson: yeah, well, it's one of those corner cases...  very specific linking problem when dealing with PIE binaries
[19:39] <sergiodj> but I agree that the test suite could do a better job handling this
[19:40] <sergiodj> jawn-smith: ah, awesome.  thanks.  I'll use your patch then
[19:40] <sergiodj> for some reason I'm now seeing an armhf failure on my PPA (which I wasn't seeing before)
[19:40] <mwhudson> jawn-smith: you need to enable some other architectures apparently :)
[19:40] <jawn-smith> yeah, I do
[19:40] <mwhudson> sergiodj: the runtime tests are pretty flaky on arm
[19:40] <sergiodj> mwhudson: ah, that explains it.  do you just keep retriggering?
[19:41] <jawn-smith> yeah I usually have to retry armhf a couple of times
[19:41] <jawn-smith> Though when I went to submit an upstream bug I couldn't recreate it locally of course
[19:41] <sergiodj> jawn-smith: ACK, thanks.  I'll go ahead and prepare the upload, then
[19:42] <sergiodj> :)
[19:42] <jawn-smith> thanks!
[19:42] <sergiodj> just running a few more tests here; I'll let you know when I have an MP up
[19:48] <sarnold> sergiodj: woot, thanks! so, uh, brown-paper-bag moment here; a teammate noticed that the segfaulting test case was opening a listening socket without checking the error return .. my test build after moving squid-deb-proxy away from port 8000 just succeeded! :D
[19:49] <sergiodj> sarnold: ah, awesome!  I'm preparing an update to the telegraf package anyway, because that error shouldn't happen and it's been fixed upstream.  as soon as we have a fixed golang compiler, I'll go ahead with the telegraf version bump
[19:49] <sergiodj> and will let you know :)
[19:50] <sarnold> :D
[20:34] <sergiodj> jawn-smith: mwhudson: https://code.launchpad.net/~sergiodj/ubuntu/+source/golang-1.18/+git/golang-1.18/+merge/422246
[20:34] <jawn-smith> will take a look, thanks!
[20:38] <sergiodj> thanks!


[12:58] <BluesKaj> Hi all
 24.04 = Noble Nanimal
 No animal yet
 FYI https://discourse.ubuntu.com/t/modern-communication-platforms-call-for-feedback/36763/25
[14:59] <mparillo> Is there a more recent post than ahoneybun's 22 hours or so ago?
[15:00] <mparillo> I am wondering if something is wrong with my neochat configuration.
[15:03] <mparillo> My userid seems to come from kde.org (I must have requested one ages ago), and :kde.org rooms have traffic, but this room seems to be :xentonix.net so I assume it is some kind of federation scheme.


[06:01] <Hue> heyy
[06:02] <Hue> i want to be a ubuntu user, teach me to setup!
[09:14] <Odd_Bloke> marcoceppi: I'm catching up on email from Friday; I have submitted a MP for the charm-helpers changes in https://code.launchpad.net/~daniel-thewatkins/charms/trusty/ubuntu-repository-cache/handle_mounted_ephemeral_disk/+merge/261356
[09:14] <Odd_Bloke> marcoceppi: You can find that MP at https://code.launchpad.net/~daniel-thewatkins/charm-helpers/lp1370053/+merge/260864
[09:15] <Odd_Bloke> marcoceppi: But I wasn't seeing any movement on that, so I was carrying the patch locally until it landed.
[09:28] <marcoceppi> Odd_Bloke: awesome, thanks, I'll talk a look today!
[09:28] <Odd_Bloke> marcoceppi: Thanks!
[09:28] <Odd_Bloke> marcoceppi: (Up early, or in a different TZ?)
[09:28] <marcoceppi> Odd_Bloke: up early, I've got a flight to catch
[09:28] <Odd_Bloke> Early flights. D:
[10:25] <bloodearnest> Does anyone know how to configure storage/block-storage-broker to work with local provider?
[10:26] <bloodearnest> I can set provider to be local on storage, block-storage-broker just doesn't like deploying on local at all afaics
[10:26] <lazyPower> bloodearnest: its only confirmed working on AWS and OpenStack
[10:27] <bloodearnest> lazyPower, right, I don't want to actually use it - I just want to have my services/relations work unchanged on local
[10:28] <bloodearnest> sounds like I need to conditionally add broker + relation if I detect we're using openstack
[10:28] <lazyPower> that or file a bug so BSB can determine if its running locally and noop
[10:29] <lazyPower> with the storage support juju has grown, i wonder how much shelf life of BSB will retain.
[10:30] <bloodearnest> lazyPower, indeed, but it will be a good while before we can use 1.24 in prod, and I need it *now*, so... :(
[10:30] <lazyPower> ah
[10:30] <lazyPower> fair counter point
[10:30] <bloodearnest> hence why I am not that motivated to fix the charm, too
[10:30] <bloodearnest> as its on life support
[10:31] <bloodearnest> lazyPower, so, about these docker juju images
[10:31] <lazyPower> that, i know something about ;)
[10:31] <lazyPower> whats up?
[10:32] <bloodearnest> I think this might be useful for the devs on our team, who have had bad experiences trying to get mojo/juju setup to run reliably and fast on local provider
[10:32] <lazyPower> charmbox does work with local provider, but it requires dancing of the jig to get it to work
[10:32] <lazyPower> you have to bootstrap the local provider, then fire up the docker image. its a bit of a strategic process, and can sometimes yield odd behavior
[10:33] <lazyPower> a lot of that should go away if we ever get a LXD based local provider.
[10:33] <bloodearnest> lazyPower, so does it do nested lxc's? Or deploy to local provider on the host?
[10:33] <lazyPower> you're in an isolated sandbox for dependencies, and leveraging juju-client effectively.  The local provider exists on the host
[10:34] <lazyPower> its not as native of an experience as the vagrant image provides, but its faster and lighter weight
[10:34] <bloodearnest> lazyPower, thumper said he was working on lxc provider as friday project, dunno if he's made progress
[10:34] <bloodearnest> lazyPower, so you still need juju on the host?
[10:34] <lazyPower> to leverage local provider, yes
[10:34] <bloodearnest> right
[10:34] <lazyPower> the AppArmor/CGROUP schenanigans in docker are wonky to say the least.
[10:34] <bloodearnest> indeed
[10:34] <lazyPower> i have yet to find the right brew to get a local provider running in the docker image
[10:35] <lazyPower> cory_fu is the one that actually pioneered that front and found success
[10:35] <lazyPower> bloodearnest: the instructions for running local provider w/ the docker image are outlined in the charmbox readme
[10:35] <bloodearnest> my attempts to find a usage that works with both dev and prod have been blocked by that issue. lxc's apparmor profiles are much simpler
[10:35] <bloodearnest> lazyPower, thanks, I will try it out
[10:35] <lazyPower> well, we're using it in Jenkins
[10:36] <lazyPower> any of the juju-ci results you see have been run through these images. That was our primary testing grounds for the images before pushing them out into the wild, getting them stable enough to run our CI Env
[10:36] <bloodearnest> lazyPower, to deploy production services?
[10:37] <lazyPower> http://juju-ci.vapour.ws/view/Juju%20Ecosystem/job/charm-bundle-test-aws/181/console
[10:37] <lazyPower> for example
[10:38] <lazyPower> as well as my Drone setup that's achieving the same results: http://drone.dasroot.net/github.com/chuckbutler/docker-charm/drone-juju-integration/4ce159d936f4a42ac910aa3ec7f4d498d209dcdb
[10:38] <bloodearnest> right
[10:39] <bloodearnest> so, I'm talking about using docker to deploy app payloads in a charm
[10:40] <lazyPower> That's completely do-able too, whats the application stack you're trying to deploy?
[10:41] <bloodearnest> many, but lets pick ubuntu sso, a django app
[10:41] <lazyPower> bloodearnest: actually, this may be of some interest to you. We built a docker/juju based ad-hoc PAAS for dockercon.
[10:42] <lazyPower> in the interest of saving time, i wrote a single compose charm that clones a git repo, and runs docker-compose pull && docker-compose up
[10:42] <bloodearnest> the thing is, I want to dev on the code base locally, using the charm deployed on local provider as the dev env
[10:42] <lazyPower> ah, that's going to be tricky
[10:42] <bloodearnest> but docker build doesn't work in an lxc
[10:42] <lazyPower> docker in lxc is notoriously painful
[10:42] <bloodearnest> right
[10:42] <lazyPower> I have a MAAS box sitting behind me i use for that
[10:42] <lazyPower> or i shell out the clams for cloud time
[10:43]  * bloodearnest think lxd is likely gonna work better for us than docker
[10:45] <lazyPower> thats entirely possible
[10:45] <lazyPower> if only the rest of the community felt that way, we wouldn't be investing as much effort in bridging the gap :)
[11:13] <g3naro> whats difference of lxd vs docker ?
[11:14] <g3naro> or got a good link to article on this
[11:19] <lazyPower> g3naro: http://www.zdnet.com/article/ubuntu-lxd-not-a-docker-replacement-a-docker-enhancement/
[11:21] <lazyPower> g3naro: to put it in my own words - LX[D|C] is focused on full OS containers, a very flexible solution that still gives you the full surroundings of your os, like an init system, multiple processes in the container. Its a lighter weight alternative to KVM without hardware layer isolation. Docker is intended to be immutable process containers, where you deliver a single application thread per container. Such as strictly a web serever, or
[11:21] <lazyPower> middleware, or a worker process, while LXC can handle the full stack in  a single container. There are some key differences such as the backend technology - docker moved to libcontainer in 2014, while LXC is still based on the LXC/Cgroups code being cranked out by stgrabers team.
[11:24] <g3naro> ahhh
[11:24] <g3naro> ok, yeah i have been u sing lxc and seems like a better solution to running a kvm machine
[11:24] <g3naro> i guess could you just build a cluster of boxes with MAAS and then lxc containers,, vs openstack+kvm ?
[11:25] <lazyPower> we actually have some openstack deployments that leverage lXC for density on a small number of machines
[11:25] <lazyPower> it co-locates services using LXC isolation to condense the requirement down for a devstack to ~ 2 machines.
[11:25] <g3naro> but what would you need to have lxc ontop of openstack then ?
[11:25] <lazyPower> basically run everything on one machine, then fire up nova-compute on a secondary machine dedicated to providing the vm images.
[11:25] <g3naro> interesting
[11:25] <lazyPower> There's a nova-lxd driver charm, which will allow you to consume LXD as your hypervisor.
[11:26] <g3naro> ahh
[11:26] <g3naro> so you're juju'ing it on there anyways
[11:26] <lazyPower> we're all over that stack with containers :)
[11:26] <lazyPower> hattip @ jamespage and company for exploring that
[11:26] <g3naro> interestng concepts
[12:16] <g3naro> so lxd is the hypervisor
[12:17] <g3naro> https://linuxcontainers.org/lxd/introduction/
[12:17] <coreycb> gnuoy, jamespage: hello, can I get a review of this from one of you?  https://code.launchpad.net/~corey.bryant/charm-helpers/install-warning/+merge/264340
[13:55] <jamey-uk> I'm trying to deploy my Rails apps using the Rails charm but it fails when it comes to building the json Gem: https://gist.github.com/anonymous/8271efd25a30732e12c4. This application has been deployed locally and to production Ubuntu servers with no issue. Does anyone know what could be causing this?
[14:55] <coreycb> niedbalski, would you be able to review this by any chance?  https://code.launchpad.net/~corey.bryant/charm-helpers/install-warning/+merge/264340
[15:07] <beisner> hi gnuoy, coreycb - this lil race is becoming more noticeable.  it's always been a bit racey, but it's pretty consistent with a few of the charms.  input on getting away from an arbitrary wait on this one?   bug 1474030
[15:07] <mup> Bug #1474030: amulet _get_proc_start_time has a race which causes service restart checks to fail <amulet> <openstack> <uosci> <Charm Helpers:New> <neutron-api (Juju
[15:07] <mup> Charms Collection):New> <neutron-gateway (Juju Charms Collection):New> <openstack-dashboard (Juju Charms Collection):New> <https://launchpad.net/bugs/1474030>
[15:09] <coreycb> beisner, basically it just expects the pid to change since the service is restarted so maybe the code could get the pid ahead of time then make the config change, then watch the pid until it changes
[15:10] <beisner> coreycb, yeah i think that would simplify things too.  check pid before.  change something.  watch with a timeout, to see if pid changes.
[15:13] <coreycb> beisner, sounds good
[15:14] <beisner> coreycb, gnuoy -  on a different race topic  :-/   the mojo-os approach of using  juju run on all units to determine if hooks and relation data have settled ... appears to no longer be reliable.
[15:14] <gnuoy> beisner, I think one of the charms has a fix
[15:14] <beisner> coreycb, it's baaaack - even with a double juju run check.  unexpected relation data in cinder cinder-ceph storage-backend - key 'broker_rsp' does not exist
[15:15] <beisner> gnuoy, coreycb - ^  juju-deployer says a-ok, ready.   the juju run x 2 against all units says a-ok.   yet a bit of relation data isn't always present.   if i run it manually, then wait who-knows-how-long, that relation data eventually arrives.  cannot for the life of me figure out how to know when.
[15:16] <beisner> gnuoy, re: pid race, do you know which?  i see a few variants on the pid check in c-h.
[15:27] <gnuoy> beisner, sorry, otp
[15:27] <beisner> np gnuoy
[15:27] <beisner> gnuoy, coreycb - i'm dealing with 2 separate races.  2 bugs to track:
[15:27] <beisner> bug 1474036
[15:27] <mup> Bug #1474036: amulet openstack tests have race - some tests start before relations/hooks have settled <amulet> <openstack> <uosci> <Charm Helpers:New> <cinder-ceph (Juju Charms Collection):New> <https://launchpad.net/bugs/1474036>
[15:28] <beisner> bug 1474030
[15:28] <mup> Bug #1474030: amulet _get_proc_start_time has a race which causes service restart checks to fail <amulet> <openstack> <uosci> <Charm Helpers:New> <neutron-api (Juju
[15:28] <mup> Charms Collection):New> <neutron-gateway (Juju Charms Collection):New> <openstack-dashboard (Juju Charms Collection):New> <https://launchpad.net/bugs/1474030>
[17:43] <mbruzek> marcoceppi: I need to run a grep in a set -e bash script that might fail, but I need the result of the grep 0 or 1.  I forget how to do that without exiting the script.  Can you enlighten me?
[17:43] <lazyPower> mbruzek: set +e
[17:44] <lazyPower> then check $?
[17:44] <mbruzek> lazyPower: Yeah I guess I can do that, but this is a charm script so the best practice is to use set -e
[17:44] <lazyPower> mbruzek: temporarily disable error checking then re-enable
[17:44] <lazyPower> thats acceptable in a charm
[17:44] <thedac> grep $SEARCH || true  also works IIRC
[17:44] <mbruzek> lazyPower: I know I can change it just for that command. ..
[17:45] <mbruzek> thanks to you both!
[21:51] <pmatulis> does a configuration change to environments.yaml always require a bootstrap, and thus the current env needs to be destroyed first?
[22:02] <thumper> pmatulis: changing something in environments.yaml does not impact any running environments
[22:02] <thumper> pmatulis: if you want to change a setting on a running environment, use 'juju set-env'
[22:02] <pmatulis> thumper: so i need to do everything run-time (juju set ...) right?
[22:03] <thumper> pmatulis: bootstrap uses the values in environments.yaml, but if you have a running environment that you are trying to change, then yes,
[22:03] <thumper> set-env
[22:03] <thumper> set is for service config
[22:04] <pmatulis> thumper: so easy to lose track of configuration changes i suppose?
[22:04] <pmatulis> ok re 'set-env vs set'
[22:16] <pmatulis> thumper: any idea -> http://paste.ubuntu.com/11874729/
[22:46] <thumper> pmatulis: yeah, some environment attributes are immutable after an environment has started
[22:48] <pmatulis> thumper: ok, time to restart. thanks


[02:18] -queuebot:#ubuntu-quality- Builds: Xubuntu Desktop amd64 [Mantic Daily] has been updated (20230521)
[02:19] -queuebot:#ubuntu-quality- Builds: Edubuntu Desktop amd64 [Mantic Daily] has been updated (20230521)
[02:36] -queuebot:#ubuntu-quality- Builds: Xubuntu Minimal amd64 [Mantic Daily] has been updated (20230521)
[03:01] -queuebot:#ubuntu-quality- Builds: Ubuntu MATE Desktop amd64 [Mantic Daily] has been updated (20230521)
[05:13] -queuebot:#ubuntu-quality- Builds: Ubuntu Server arm64+raspi [Mantic Daily] has been updated (20230521)
[05:13] -queuebot:#ubuntu-quality- Builds: Ubuntu Server armhf+raspi [Mantic Daily] has been updated (20230521)
[06:26] -queuebot:#ubuntu-quality- Builds: Ubuntu Base amd64 [Mantic Daily] has been updated (20230521)
[06:26] -queuebot:#ubuntu-quality- Builds: Ubuntu Base armhf [Mantic Daily] has been updated (20230521)
[06:26] -queuebot:#ubuntu-quality- Builds: Ubuntu Base riscv64 [Mantic Daily] has been updated (20230521)
[06:26] -queuebot:#ubuntu-quality- Builds: Ubuntu Base arm64 [Mantic Daily] has been updated (20230521)
[06:26] -queuebot:#ubuntu-quality- Builds: Ubuntu Base s390x [Mantic Daily] has been updated (20230521)
[06:26] -queuebot:#ubuntu-quality- Builds: Ubuntu Base ppc64el [Mantic Daily] has been updated (20230521)
[06:49] -queuebot:#ubuntu-quality- Builds: Ubuntu Desktop amd64 [Mantic Daily] has been updated (20230521)
[06:49] -queuebot:#ubuntu-quality- Builds: Ubuntu Desktop arm64 [Mantic Daily] has been updated (20230521)
[07:10] -queuebot:#ubuntu-quality- Builds: Ubuntu Desktop arm64+raspi [Mantic Daily] has been updated (20230521)
[08:13] -queuebot:#ubuntu-quality- Builds: Kubuntu Desktop amd64 [Mantic Daily] has been updated (20230521)
[08:44] -queuebot:#ubuntu-quality- Builds: Ubuntu Core amd64 edge [Mantic Daily] has been updated (20230521)
[09:09] -queuebot:#ubuntu-quality- Builds: Ubuntu Desktop (Legacy) amd64 [Mantic Daily] has been updated (20230521)
[10:23] -queuebot:#ubuntu-quality- Builds: Ubuntu Server Subiquity amd64 [Mantic Daily] has been updated (20230521)
[10:24] -queuebot:#ubuntu-quality- Builds: Ubuntu Server Subiquity ppc64el [Mantic Daily] has been updated (20230521)
[10:24] -queuebot:#ubuntu-quality- Builds: Ubuntu Server Subiquity arm64 [Mantic Daily] has been updated (20230521)
[10:24] -queuebot:#ubuntu-quality- Builds: Ubuntu Server Subiquity s390x [Mantic Daily] has been updated (20230521)
[13:48] -queuebot:#ubuntu-quality- Builds: Ubuntu Unity Desktop amd64 [Mantic Daily] has been updated (20230521)
[15:39] -queuebot:#ubuntu-quality- Builds: Ubuntu Budgie Desktop amd64 [Mantic Daily] has been updated (20230521)
[17:05] -queuebot:#ubuntu-quality- Builds: Lubuntu Desktop amd64 [Mantic Daily] has been updated (20230521)
[19:03] -queuebot:#ubuntu-quality- Builds: Ubuntu Studio DVD amd64 [Mantic Daily] has been updated (20230521)
[23:01] -queuebot:#ubuntu-quality- Builds: Ubuntu Kylin Desktop amd64 [Mantic Daily] has been updated (20230521)


[16:45] <kklimonda> chrisccoulson: are there any known regressions in the new gnome-keyring? :)
[16:45] <chrisccoulson> possibly. what sort of regressions?
[16:46] <kklimonda> chrisccoulson: I've written this small program: http://pastebin.com/Mzc72KWw and it works fine when the keyring is unlocked
[16:46] <kklimonda> chrisccoulson: but when it's locked the prompt to unlock shows up but the password_stored_cb isn't called
[16:46] <kklimonda> and it probably doesn't save the password
[16:46]  * kklimonda is going to check
[16:46] <chrisccoulson> hmmm, i'm not too sure
[16:47] <chrisccoulson> i'm not that familiar with gnome-keyring, but i could probably take a look
[16:47] <kklimonda> ya, no password
[16:47] <kklimonda> chrisccoulson: I've checked it on 9.04 and worked as expected
[16:48] <chrisccoulson> kklimonda, could you report that on the bugzilla then please?
[16:48] <kklimonda> ok
[16:48] <chrisccoulson> thanks