[01:21] <Lirodon> Just wondering, is that "OEM mode" still there?
[01:26] <slangasek> Lirodon: yes
[02:41] <bryceh> jcastro, mind adding https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-xorg to the schedule?  Sorry, I should have registered it earlier but it slipped my mind.
[03:08] <slangasek> bryceh: linked to the sprint; that should let it get scheduled by the autoscheduler
[03:08] <slangasek> (if you "propose for sprint", it goes in the queue fwiw)
[04:05] <pitti> Good morning
[04:07] <ajmitch> morning pitti
[04:14] <pitti> mdke: replied to your langpack mail; TL;DR there is still time to do an ubuntu-docs upload
[04:33] <Laibsch> tumbleweed: you asked me if things about getting patches applied regress.  Well, I just stumbled across bug 697788 again.  And I think that no reaction after three months is pretty bad.  Almost as bad as during the worst times.  I had already forgotten about this one.
[04:33] <Laibsch> I don't think I'm the only one with this problem, am I?
[04:36] <broder> Laibsch: why isn't ubuntu-sponsors subbed to that bug?
[04:37] <ajmitch> broder: even if they were, would it show on a list, since the main bug task is fix released & the nominations aren't marked as accepted yet?
[04:37] <broder> oh ugh. yeah, you're right
[04:38] <Laibsch> broder: dunno.  to be honest, processes change about every 6 months, so I have a hard time keeping up. Let me ask the other way round, what's the purpose of ubuntu-sru?
[04:38] <Laibsch> I know everyone is doing their best, I'm not necessary complaining.  But things can be pretty frustrating.
[04:38] <broder> Laibsch: for at least the last year, it's the list of people who approve SRUs after they've been uploaded by a sponsor
[04:38] <Laibsch> s/necessary/necessarily/
[04:39] <ajmitch> one major problem I see is a LP timeout when trying to review nominations - no wonder it got missed
[04:39] <Laibsch> so, I subscribe the sponsors team and they in turn subscribe the sru team? I don't even need to worry about ubuntu-sru?
[04:39] <broder> Laibsch: that's right
[04:40] <Laibsch> OK
[04:40] <Laibsch> I'll try to remember that (until the next time it's changed) ;)
[04:40] <broder> Laibsch: that's also the process that's documented on !sru (and has been, since we made this change)
[04:40] <broder> ahem
[04:40] <broder> !sru
[04:41] <Laibsch> I can't reread wiki pages every time I want to get a patch accepted ;-)
[04:41] <Laibsch> seriously, this changed so frequently, it's hard to keep up unless you hang around in IRC every day
[04:41] <Laibsch> maybe I'm too old and too long with Ubuntu ;-)
[04:42] <ajmitch> possibly, this changed ~15 months ago from what I can see
[04:42] <broder> most of the time, we change processes because we're trying to make it easier, and for people who don't already know the old way, i think the new approach is a definite improvement
[04:42] <Laibsch> yes
[04:43] <Laibsch> and I agree that many processes were improced recently
[04:43] <Laibsch> most notably the sponsorship process
[04:43] <Laibsch> that's why I noticed that recently things were taking their time again, maybe just bad luck.
[04:43] <broder> i'm fairly confident there was mail to...a mailing list at the time we made the change, but i can't remember which one it would have been
[04:47] <Laibsch> broder: you are overestimating the time I can spend with reading mailing lists, wiki, etc.  One can spend half the day doing that and then I'm sure one is up to date on most of the processes ;-)  I simply can't.
[04:47] <broder> yeah, i was hoping i'd find an e-mail to ubuntu-devel-announce, but it looks like it was just discussed on ubuntu-devel
[04:48] <Laibsch> I wouldn't have read either </sheepish admittance>
[04:48] <broder> (https://lists.ubuntu.com/archives/ubuntu-devel/2010-July/030999.html was the post, for reference)
[04:49] <Laibsch> thx
[04:51] <Laibsch> broder: that actually concerns only the second part of the process (the one that I don't deal with due to lack of privs)
[04:52] <broder> hmm...that's true. i think i was familiar enough with what jdong was proposing that i could read into the sponsorship process changes, but re-reading the e-mail, that's not obvious
[04:52] <Laibsch> it's not always clear to me what is and what isn't in the queue and at what position.  There was http://reports.qa.ubuntu.com/reports/sponsoring/ posted here, yet I'm not fully sure how to read that list.
[04:53] <broder> ah, sure. "queue" is referring to two different things
[04:53] <broder> there's the sponsorship queue - which is your link
[04:53] <broder> but for srus (and new packages and near-release freezes and such), LP puts the upload into a queue to be accepted by an archive admin
[04:53] <broder> (that's http://launchpad.net/ubuntu/precise/+queue or similar)
[04:54] <Laibsch> I guess what I'm saying that the process (and thus the content of the queue) are a bit opaque to people who don't do this stuff at least daily (I'm doing a fair bit)
[04:59] <Laibsch> I see. I don't think I'm concerned at all by the second queue you mentioned.
[05:00] <Laibsch> what priv is necessary to be able to approve series nominations?
[05:00] <micahg> Laibsch: upload rights or series driver
[05:01] <Laibsch> which one is more straightforward to get?
[05:01] <Laibsch> I'm an SRU type of guy, I fiddle too much with my computer already.  Can't have it break every 6 months on top of that ;-)
[05:01] <micahg> Laibsch: upload rights I think, you can ask for tasks here or in #ubuntu-motu as appropriate and someone can usually accept for you
[05:02] <Laibsch> would be nice to be able to do that on my own ;-)  I think I have pretty far-reaching privs in bug-control
[05:08] <ajmitch> micahg: so MOTU can approve nominations for universe packages?
[05:09] <micahg> ajmitch: indeed, and PPU for theirs as well
[05:25] <Laibsch> ah, the dreaded ubuntu-membership comes first
[05:26] <RAOF> Not necessarily.
[05:37] <Laibsch> Well, it seems that me working mostly behind the scenes has so far not helped me ever become anybody in terms of ubuntu-devel membership.  Becoming a DM OTOH was painless and a breeze.
[05:38] <Laibsch> ubuntu-devel as in "dev in ubuntu" not core-dev, but anything upload-related.  and as opposed to -bugs where I hardly ever run into something I cannot fix on my own.
[05:41] <pitti> @pilot in
[05:42] <RAOF> Laibsch: Have you applied for MOTU, or for upload rights to a packageset you work in?
[05:43] <Laibsch> I tried to apply for normal membership once and that was such a terrible experience that it put me off ever trying again.  It was a total insult (and I stayed up until 5 in the morning on top of it!)
[05:44] <Laibsch> Essentially, I was told the equivalent of "you are overqualified for simple membership, application rejected"
[05:44] <Laibsch> wtf
[05:44] <Laibsch> :-O
[05:45] <RAOF> The ubuntu-membership thing appears to be not well advertised.
[05:45] <Laibsch> maybe that's agood thing ;-)
[05:45] <RAOF> No, I mean that it's not something you (generally) apply for; it's something that is a bonus part of something more interesting.
[05:45] <Laibsch> may I ask that somebody accept the lucid task for bug 697788 to get the ball rolling?
[05:46] <RAOF> Or, at least, it's not something developers should ever need/want to apply for; it grants no development privilegdes.
[05:46] <RAOF> Hm, already been done?
[05:47] <Laibsch> ah nice, must have been done in the last 2 minutes or so
[05:48] <Laibsch> RAOF: even if there was no need for a dev to apply for membership only, it should not be rejected based on that ground. It pissed me off to NO end.
[05:49] <Laibsch> how am I to know whether I am already a dev or mere mortal member?
[05:49] <RAOF> Yeah, that seems a bit unnecessary.
[06:33] <mdke> pitti: thanks for the reply. The discussion in #ubuntu-translators appears to have been completely wrong...
[06:33] <mdke> pitti: I will try and do the upload today, and ping you to approve it (if you don't mind)
[06:33] <pitti> mdke: please
[06:33] <pitti> mdke: I have the langpack export, but I'll wait a bit for this to land
[06:34] <pitti> it's enough to have the package built
[06:46] <dholbach> good morning
[06:53] <pitti> hey dholbach
[06:53] <dholbach> hey pitti
[06:53] <mdke> no one happens to know off the top of their head what this build error means?
[06:53] <mdke> make[3]: execvp: /bin/bash: Argument list too long
[06:54] <mdke> I get it quite a lot and can work around it but if there is an easy fix...
[06:57] <geser> IIRC you get this when bash expansion of "*" (and similar) generates too many arguments (like "ls *" in a directory with many, many files)
[06:58] <mdke> yes, it is trying to install too many files
[07:01] <mdke> geser: so I take it from your answer that there is no easy work around?
[07:02] <geser> you'll need to split the calll into several somehow, either calling it first on "a*", then "b*", ... or with find and xargs
[07:02]  * mdke nods
[07:02] <mdke> that's comfortably beyond my skills :)
[07:02] <mdke> ok, thanks for the pointers
[07:03] <mdke> pitti: uploaded version 11.10.5
[07:05] <pitti> mdke: yay, thanks
[07:06] <mdke> pitti: I won't be able to test the -proposed built package until this evening after work, but the one I built worked fine. Anyway it should be enough to get the translations I guess. If there is anything please send me an email as I'll be out of irc contact
[07:06] <pitti> mdke: ok, will do
[07:06] <pitti> mdke: just waiting for the diff to appear on LP, then I'll review this
[07:07] <mdke> pitti: fine, I'll be around for about 30 mins. Please ignore the changes to the html/ directory, I have rebuilt the theme for the website and this isn't used in the package build process, but we keep it in the bzr branch
[07:08] <mdke> pitti: the diff will be huge anyhow because of all the new translations
[07:08] <mdke> when I added them to the bzr branch there was a diff of 120755 lines
[07:47] <pitti> mdke: accepted
[07:47] <TLE> pitti, mdke: Hey guys, sorry about the bumpy start :|
[07:48] <pitti> TLE: no harm done :) package is building now, once that's done I can prepare the langpacks
[07:48] <pitti> the LP export is ready
[07:49] <mdke> pitti: fantastic, thanks. TLE: no worries
[07:54] <TLE> pitti: so by all indications it looks like there will be new language packs ready by thursday I gather, in that case I will give the translators a heads up
[08:01] <pitti> ev: can you please do bug 606134? I can't push to the branch
[08:08] <ev> pitti: sure thing
[08:16] <jamespage> please could the NEW jenkins-htmlunit + osgi-* binary packages be accepted into precise - ta
[08:19] <micahg> dholbach: I thought we were waiting for libraries to mirgate to testing before ACKing syncs? (bug 881822)
[08:23] <dholbach> micahg, I'll bear that in mind for the next syncs I look at, but in this case I checked the upstream changelog and they consisted of almost only fixes and one of them was requested by the debian maintainer
[08:27] <ricotz> dholbach, micahg, hi, these are stable release updates for gnome 3.2 which eventually should get into oneiric-proposed too
[08:27] <micahg> dholbach: ok, but it's less about the package itself than its rdepends when it comes to libraries (AIUI)
[08:28] <micahg> ricotz: indeed, but oneiric-proposed also has a waiting period before migration :)
[08:29] <ricotz> micahg, right, but it seems better to have them in precise first :) to avoid diversions
[08:31] <dholbach> I understand the reasoning and agree that waiting in some cases might bring up problems in rdepends testing new code paths, etc - and as I said: I'll bear that in mind next time
[08:32] <micahg> ricotz: indeed, I appreciate you trying to do things properly, it wasn't so much about this case as in general
[08:32] <micahg> dholbach: thanks, I trust your judgment here :)
[08:33] <dholbach> still I checked the diff, no soname changes, there were memleak fixes in there, it came with a recommendation from the debian maintainer, so I felt sufficiently convinced that it was a good idea to sync - if we want to wait for things in testing no matter what, I must have misread the memo about it :)
[08:34] <ricotz> micahg, no problem, but isnt it reasonable to have libraries transitioned asap to avoid rebuilds of rdepends later
[08:35] <micahg> ricotz: yes, if there's a soname bump it makes sense to get it in early, but there's a tradeoff of making sure that the new version is adequately tested w/the rdepends, in this case there's no soname bump, so as dholbach said, it's less important
[08:36] <ricotz> micahg, alright, i will keep that in mind
[08:47] <micahg> ricotz: then again, syncing from Debian is usually better than a -0ubuntu1 upload as long as the changes are sane, so YMMV
[09:21] <pitti> Riddell: do you know which branch https://launchpad.net/ubuntu/+source/kubuntu-docs/+changelog was committed to?
[09:22] <pitti> Riddell: I checked lp:kubuntu-docs, ~ubuntu-core-doc/kubuntu-docs/natty (which is what Vcs-Bzr says), ~ubuntu-core-doc/kubuntu-docs/oneiric, ~ubuntu-core-doc/kubuntu-docs/precise, but they all stop at natty
[10:33] <Daviey> doko: Does a sync of libpam-krb5 from sid make sense?  Seems to include your multiarch changes, and other goodies.
[10:47] <doko> Daviey, sure
[10:49] <\sh> moins
[10:49] <\sh> micahg, you are sure that with latest dpkg -Werror=format-security was disabled?
[10:50] <cjwatson> sure or aware?
[10:50] <cjwatson> I'd talked to the security team previously, their main desire was to get it into dpkg-buildflags output, they weren't pushing for it to be in the environment by default
[10:50] <cjwatson> "disabled" is misleading
[10:51] <\sh> cjwatson, well...then I wonder why I get all those errors
[10:51] <\sh> xap_UnixDialogHelper.cpp:833:18: error: format not a string literal and no format arguments [-Werror=format-security]
[10:51] <\sh> cc1plus: some warnings being treated as errors
[10:51] <\sh> abiword as an example
[10:52] <\sh> using cdbs
[10:53] <cjwatson> \sh: cdbs fetches dpkg-buildflags output directly - that one would fail in unstable too
[10:53] <cjwatson> I'm only concerned about the ones that were failing just in Ubuntu
[10:54] <cjwatson> cdbs users have to fix their problems more quickly
[10:55] <\sh> cjwatson, looks like
[10:55] <cjwatson> fail in unstable> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=643344
[10:57] <pitti> TLE, mdke: new langpacks look good, have the latest ubuntu-docs translations, and also the missing deja-dup/games/etc. mallard help
[10:57]  * pitti sends builder-wards
[10:57] <\sh> cjwatson, that's it...and 2.9.1 is fixing that upstream, but this is development release and {x,l}ubuntu don't want a development version (which I can understand)
[10:57] <\sh> bah..I'll get back to my patch for fixing those buggers.
[10:59] <cjwatson> they're trivial to fix
[10:59] <cjwatson> the main reason I disabled the export-to-environment part in dpkg for that flag was that it was causing silent configure test failures, and I was worried about misbuilds if we were doing that differently from Debian
[11:00] <cjwatson> well, silent configure test failure anyway; I only noticed one, which happened to result in a build failure later - but I was more worried about the ones I wasn't noticing
[11:00] <cjwatson> now, the same may be happening for cdbs packages, but at least we're in sync with Debian on that part
[11:07] <cjwatson> All distro buildds appear to be dead.  I've raised it on #launchpad-dev.
[11:07] <ogra_> tkamppeter_, ping
[11:08] <tkamppeter> ogra, hi
[11:08] <tkamppeter> ogra_, hi
[11:08] <ogra_> tkamppeter, hey, i'm trying to get my hp laserjet 1018 wortking on my arm netbook
[11:09] <ogra_> tkamppeter, in natty it just worked to run hp-plugin or hp-plugin-ubuntu ... seems in oneiric i get a gpg erros for the file it downloads
[11:10] <tkamppeter> ogra_, this printer needs a firmware file and due to the Linux Foundation desaster the Official download from HP is not back working yet.
[11:10] <ogra_> tkamppeter, is there any way i could copy what it downloads from the natty install ? 8where does the .run file unpack its content)
[11:10] <ogra_> i have a working driver on another machine, but i dont know which files to copy
[11:11] <tkamppeter> ogra_, you can use an alternative download, run "sudo getweb 1018" on the command line.
[11:11]  * ogra_ tries
[11:11] <TLE> pitti: awesome
[11:11] <pitti> cjwatson: really? they look ok from here
[11:11] <ogra_> tkamppeter, that prints sihp1018.img, anything i need to do additionally now ?
[11:12] <pitti> cjwatson: a minute ago all five i386 builders built different packages than now
[11:12] <tomreyn> hi. is there a process to request removal of a package because it is not sufficiently maintained?
[11:12] <pitti> cjwatson: oh, you mean they fail to build everything?
[11:12] <pitti> tomreyn: yes; please file a bug against it with a rationale, and subscribe ubutnu-archive
[11:13] <cjwatson> pitti: all the builds just flip back to needs-building after a couple of minutes, failing to leave a log
[11:13] <tkamppeter> ogra_, it should have dropped the firmware file in /lib/firmware/hp, check whether it landed there.
[11:13] <cjwatson> pitti: I've been watching it for a while now
[11:13] <\sh> tomreyn, which package? :)
[11:13] <pitti> cjwatson: ah, right
[11:13] <ogra_> tkamppeter, yes, it did
[11:15] <tomreyn> \sh: https://bugs.launchpad.net/ubuntu/+source/indicator-weather
[11:15] <tomreyn> pitti: thanks
[11:15] <tkamppeter> ogra_, if you unplug and replug your printer or turn it off and on again, the firmware should get loaded into the printer (letting the printer make its startup noise twice).
[11:15] <ogra_> tkamppeter, oh, i forgot to mention, its a network (ipp) printer
[11:16] <TLE> pitti: if they are all good to copy to proposed, let me know when they land there
[11:16] <pitti> TLE: just followed up to the mail
[11:16] <pitti> TLE: I'm uploading to -proposed
[11:16] <tkamppeter> ogra_, the alternative mechanism only works with the printer connected via USB.
[11:16] <pitti> we just need the buildds back, cf. what cjwatson said a few monents ago
[11:16] <pitti> TLE: ^
[11:16] <ogra_> tkamppeter, ah, thats bad
[11:17] <ogra_> tkamppeter, and there is no way to get the driver from the other machine through just copying it ?
[11:17] <tkamppeter> ogra_, the printer itself has only an USB connector, did you connect it to a router? Does HP's software support this configuration?
[11:17] <cjwatson> pitti: wgrant appears to be looking into it
[11:17] <TLE> pitti: ok
[11:17] <pitti> wgrant: thanks muchly
[11:17] <\sh> tomreyn, did you encounter d0od@freenode and ask him about the bugs?
[11:17] <wgrant> Only because nobody else is :)
[11:17] <cjwatson> well, yes ...
[11:17] <ogra_> tkamppeter, it works fine from all other machines, it is a small printserver running cups it is attached to
[11:18] <tkamppeter> ogra_, so than it probably has its firmware, supplied by the CUPS server to which it is connected. Your ARM box does not need to supply firmware to the printer then.
[11:18] <ogra_> tkamppeter, ipp://printsrv.local:631/ipp is what i use on the other machines, the machine i have the issue with is just a new install that does not have the binary bits
[11:19] <ogra_> oh
[11:19] <ogra_> i needed it in the past
[11:21] <tkamppeter> ogra_, the server should also provide the driver for the printer. You can print through a raw queue from the client. If the server's queue is intentionally set up raw, you need a free-software-only (as there is no closed-source plug-in from HP for ARM) driver. This driver is foo2zjs. You have to switch the driver of the queue from hpcups or hpijs to foo2zjs.
[11:21] <ogra_> ok, i will try
[11:21] <tomreyn> \sh: no, can you explain how s/he relates to this package?
[11:22] <tomreyn> \sh: i looked at their mailing list archive and found this, though: https://lists.launchpad.net/weather-indicator-team/msg00096.html
[11:23] <\sh> tomreyn, https://launchpad.net/indicator-weather <- this is the main project page of indicator-weather and d0od is the maintainer ... so eventually he's not aware of the bugs reported on the package in ubuntu
[11:23] <tomreyn> \sh: nickserv tells me d0od: Last seen  : Sep 27 08:49:28 2011 (4 weeks, 1 day, 02:33:00 ago)
[11:25] <tomreyn> I assume he will be one of the "developers [who] either have lost the will to continue contributing or have lack of time".
[11:27] <\sh> tomreyn, yeah looks like...
[11:27] <\sh> tomreyn, just file the removal of this package
[11:32] <tomreyn> \sh: I still can't spot the reference to d0od on https://launchpad.net/indicator-weather - can you help me? I see "Vadim Rutkovsky" listed as "driver", whose IRC nickname would be roignac.
[11:36] <\sh> tomreyn, when you click on the maintainer on the project page
[11:36] <\sh> d0od
[11:36] <\sh> Driver:
[11:36] <\sh> libohso-maintainers
[11:38] <\sh> tomreyn, see privmsg
[11:47] <ogra_> tkamppeter, i got it working now, thanks for the help !
[12:05] <ogra_> GRRR
[12:06] <ogra_> so i spent 2h to get my printer working on my netbook for printing my eticket ... just to find out that us-airways does the checking through a flash based page !
[12:06] <ogra_> *checkin
[12:06] <ogra_> grmbl, silly world
[12:08] <ogra_> (which is indeed not helpful on arm where no flash plugin exists)
[12:09] <OdyX> .oO(lightspark ?)
[12:09] <ogra_> OdyX, doesnt help at all there is no accel for it for arm
[12:10] <ogra_> it runs but with 0.5fps or less
[12:10] <OdyX> ogra_: compiled against libgles though
[12:11] <ogra_> yes, its still 100% SW rendering
[12:22] <cjwatson> LP builders are gradually coming back online now
[13:17] <ogra_> oh, sweet, dexconf is finally dead !
[13:19] <highvoltage> that must be from before my time, I don't even know what dexconf is.
[13:20] <hyperair> debconf X frontend?
[13:20] <highvoltage> ah
[13:21] <hyperair> at least, i think.
[13:22] <hyperair> http://manpages.ubuntu.com/manpages/hardy/man1/dexconf.1.html
[13:22] <hyperair> highvoltage: generate Xorg.conf, apparently.
[13:22] <ogra_> right
[13:22] <ogra_> it used to be the connecting bit between xorg and debconf
[13:22] <Laney> it's been removed a few months
[13:22] <ogra_> one of the worst hacks debian ever had
[13:22] <Laney> but yeah, yay
[13:22] <pitti> @pilot out
[13:23] <ogra_> Laney, i only saw tjaalton's bug right now, i used to follow xorg, but not anymore
[13:23] <Laney> at least in debian it was ~february ish
[13:24]  * dholbach hugs pitti
[13:24]  * pitti hugs back dholbach
[14:37] <Daviey> mterry: heya, would you be able to look at bug 875818, please?
[14:37] <Daviey> it's dep-waiting dnsmasq
[14:37] <mterry> Daviey, sure!
[14:39] <Daviey> mterry: thanks!
[15:01] <slangasek> RoAkSoAx: you have redhat-cluster's merge marked as 'please do not touch', and people have been complying and not touched it since 2009... :)  Is that something that should get merged this cycle?
[15:04] <RoAkSoAx> slangasek: yes, we have a newer version in Ubuntu  3.0.12-2ubuntu5 and merges.u.c shows 3.0.2-5
[15:05] <RoAkSoAx> slangasek: so it might be a bug from merges.u.c?? on the other hand, this cycle we are planning a new upstream release that contains huge changes in comparison to the old rhcs source, and we are wroking with the debian maintainer
[15:09] <slangasek> RoAkSoAx: oh, interesting
[15:09] <slangasek> cjwatson: ^^ for some reason merges.u.c doesn't know we have a new upstream version of redhat-cluster in precise?
[15:09] <cjwatson> RoAkSoAx: yes, can you file that on bugs.launchpad.net/merge-o-matic?
[15:10] <RoAkSoAx> slangasek: that;'s not only bveen in precise but since oneiric
[15:10] <RoAkSoAx> cjwatson: sure
[15:10] <cjwatson> since maverick
[16:06] <jdstrand> it would be ideal to get ruby1.8 demoted
[16:06] <jdstrand> wrong window
[16:36] <apw> ev, just doing and install and tried the > next to teh current operation which opened a text panel, very small and 100% empty for then and forward; i presume that is not expected
[16:43] <slangasek> apw: hey, do you know if aufs implements inotify on the backend?
[16:43] <apw> slangasek, unsure why ?
[16:43] <slangasek> apw: because upstart doesn't manage to automatically reread /etc/init from a LiveCD
[16:43] <apw> slangasek, lets say "probabally" is most likely the answer
[16:44] <apw> slangasek, ahh well we know that overlayfs is not doing inotify quite right
[16:44] <apw> slangasek, and that is what is in use on the livecds
[16:44] <slangasek> this causes install failures if you want to configure a package in the livefs that adds an upstart job
[16:44] <slangasek> apw: oh, we're using overlayfs now, not aufs?  alrighty
[16:44] <slangasek> is that inotifilessness tracked anywhere?
[16:44] <apw> slangasek, awsome, so glad that we test things before release
[16:45] <slangasek> it's not a common scenario
[16:45] <apw> slangasek, ahhh probabally not actually, i was going to file a bug at release sprint and then went ill
[16:45] <Daviey> mterry: bug 875818, should i just removed the versioned shlibs?  That version predates Lucid.
[16:45] <slangasek> why are you installing a server into memory on a liveCD
[16:45] <slangasek> etc
[16:46] <apw> slangasek, will get the bug filed and let you know the number
[16:46] <slangasek> apw: ok.  I have a couple of prospective dupes once available :)
[16:46] <apw> slangasek, deep joy :/
[16:47] <mterry> Daviey, that could work.  Ideally whichever path is more palatable to the Debian maintainer so we can sync in future.  I'd suggest a .symbols file, but just having plain -V is quicker if you want to get something in now
[16:50] <apw> slangasek, that reminds me, if the disk is not persistant you can use a commandline override to select aufs for a CD boot
[16:51]  * apw forgets the exact incantation but its something like UNIONMOUNT=aufs
[16:51] <apw> perhaps UNION=
[16:51] <cjwatson> union=aufs
[16:52] <slangasek> apw: filing that for future reference... I'm not sure the people hitting this bug are even meaning to do this
[16:52] <slangasek> the bug reports are mostly pretty vague
[16:53] <slangasek> I just happen to have one follow-up from someone who self-diagnosed correctly, and it matched what I had seen when doing ubiquity debugging
[16:53] <apw> bug #882147
[16:56] <stgraber> that one kept us busy for a while at the release sprint ;)
[16:56] <slangasek> oh, did it?
[16:58] <slangasek> bdmurray: so there are bugs in launchpad that should be duped to bug #882147
[16:59] <stgraber> slangasek: yeah, we noticed it when trying to debug ubiquity with a "tail -f /var/log/installer/debug" and didn't get anything :)
[16:59] <slangasek> bdmurray: any "start: Unknown job:" error message received while running on the livefs
[16:59] <bdmurray> slangasek: including persistent usb?
[16:59] <slangasek> bug #857406 is an example of this... unfortunately there's no dpkg log, but the error message is in the bug description, and CasperVersion is set
[16:59] <slangasek> bdmurray: yes
[17:00] <stgraber> slangasek: then noticed "watch -n1 tail /var/log/installer/debug" worked fine, inode numbers were identical too and eventually tracked it down to a overlayfs issue, then the kernel guys noticed it was the missing inotify support in overlayfs (or broken inotify support, can't remember the details)
[17:00] <stgraber> slangasek: anyway, wasn't considered critical back then, just very annoying for debugers :)
[17:00] <slangasek> bdmurray: is it practical to find the matching bugs?
[17:01] <broder> ...huh, tail -f uses inotify now? i thought you had to pull inotail out to get that
[17:02] <slangasek> stgraber: what broder said - kinda weird that tail needs inotify
[17:02] <slangasek> but yeah
[17:02] <bdmurray> slangasek: would they generally be package install failures? those get tagged but livemediabuilds don't so that would be a bit more challenging
[17:03] <slangasek> bdmurray: I don't really know i they're package install failures; the one I know about was apparently filed by hand
[17:03] <stgraber> stgraber@castiana:~/Desktop$ strace tail -f /var/log/syslog 2>&1 | grep -i notify
[17:03] <stgraber> inotify_init()                          = 4
[17:03] <cjwatson> tail -f inotify> changed in coreutils 7.5
[17:03] <stgraber> inotify_add_watch(4, "/var/log/syslog", IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF) = 1
[17:03] <stgraber> broder, slangasek: ^ :)
[17:03] <cjwatson>   tail --follow now uses inotify when possible, to be more responsive
[17:03] <cjwatson>   to file changes and more efficient when monitoring many files.
[17:03] <bdmurray> slangasek: well I'll see what I can do
[17:04] <broder> fancy
[17:04] <slangasek> bdmurray: thanks
[17:04] <cjwatson> if inotify_init returns <= 0 it falls back to polling
[17:04] <cjwatson> I'm guessing that in this case support is present but brokene?
[17:04] <cjwatson> *broken
[17:04] <slangasek> cjwatson, stgraber: how future
[17:05] <apw> cjwatson, right present but not working as one might expect
[17:05] <slangasek> present because the kernel supports it, broken because the fs doesn't
[17:05] <stgraber> apw: do you remember if inotify_add_watch actually fails on overlayfs?
[17:05] <apw> stgraber, no i don't think so, the issue is that things get attached to the wrong versions i think
[17:06] <apw> stgraber, anyhow its on my list to investigate with upstream
[17:06] <cjwatson> slangasek: inotify_init only tells you if the kernel supports it; but it also calls inotify_add_watch and falls back to polling if *that* fails, and that should be able to tell whether the fs supports it
[17:06] <slangasek> cjwatson: ah, sure
[17:07] <stgraber> cjwatson: except that on this specific case, inotify_add_watch actually added a watch on the read-only branch instead of the copy-on-write one, so didn't fail, just wasn't doing anything useful :)
[17:07] <cjwatson> right, indeed
[17:07] <bdmurray> slangasek: so bug 8733358 seems like a likely duplicate - correct?
[17:07] <bdmurray> bug 873358
[17:25] <stokachu> vanhoof, yo s0n
[17:27] <slangasek> bdmurray: 873358> yep!
[17:28] <Sarvatt> stokachu: he's in st lucia for his honeymoon :)
[17:28] <stokachu> Sarvatt, ahh finally tied the knot
[17:31] <stokachu> is it normal for the builds in ppa to take anywhere from 1-2days to start?
[17:33] <slangasek> not "normal", but there was a dispatcher problem earlier today which I think explains the current backlog
[17:33] <stokachu> slangasek, ok thanks
[18:04] <bdmurray> slangasek: well, I only found a couple
[18:05] <slangasek> bdmurray: ah, alright
[18:05] <slangasek> duping them?
[18:05] <bdmurray> done
[18:05] <slangasek> is this representable as a bug pattern?
[18:06] <bdmurray> yes
[18:06] <slangasek> cool... will you take care of that as well?
[18:07] <slangasek> probably will only ever catch a small smattering of bugs... but they'll be among the more confusing for anyone to try to triage correctly :)
[18:10] <bdmurray> slangasek: what package would 'start: Unknown job' be translated in?
[18:11] <slangasek> translated?  I don't think we have any l10n for upstart messages
[18:11]  * slangasek checks
[18:11] <bdmurray> ah great
[18:12] <slangasek> well, there are upstart.mo files in the archive.. so I guess that bears checking...
[18:12] <Daviey> Can an AA promote libnetfilter-conntrack src and bin, based on bug 875818, please?  (-dbg package doesn't have anything holding it in main tho.)
[18:17] <barry> so, here's a packaging question i'm not sure how to handle.  i'm working on a new claws-mail-extra-plugins that re-enables gdata_plugin from upstream cvs.  the source branch itself has directories for each of the individual plugins (21 of them).  i `bzr rm` the old directory, `bzr add` the new cvs snapshot directory.  none of the d/* files really need to be changed.  the problem is getting a new orig.tar.gz with the new
[18:17] <barry> subdirectory. this will be a 2ubuntu2 package so the previous upload already got c-m-e-p_3.7.10.orig.tar.gz.  what's the right way to build the source package for this scenario?
[18:19] <Laibsch> Can somebody please confirm the lucid task for bug 881806 so it doesn't fall through the crack again?
[18:19] <slangasek> bdmurray: there are a few translations, it seems. http://paste.ubuntu.com/719918/
[18:19] <tumbleweed> Laibsch: approved
[18:19] <Laibsch> thanks
[18:20] <slangasek> Daviey: done
[18:21] <Daviey> slangasek: thanks!
[18:22] <slangasek> barry: why the 'bzr rm && bzr add'?
[18:22] <barry> slangasek: udd ;)
[18:22] <slangasek> barry: that sounds like a wrong turn to me, but maybe I don't understand what you're doing
[18:23] <barry> slangasek: but i'm not particularly wedded to using udd for this task, if `apt-get source` is a better route
[18:23] <slangasek> so you've bzr rm'ed the upstream directory, and bzr add'ed another one with the same name?
[18:23] <barry> slangasek: bzr rm gdata_plugin-0.2; bzr add gdata_plugin-20111026cvs
[18:23] <slangasek> to your root question, there are two ways to do this
[18:24] <slangasek> 1) use the -2ubuntu2 package version you already mentioned, and carry the cvs snapshot bits entirely in the .diff.gz
[18:25] <slangasek> 2) concoct a new upstream version number (following the rules embodied in dpkg --compare-versions, to avoid it interfering with future upstream releases), generate a "release" tarball for this version by whatever means you find appropriate, and import it with bzr merge-upstream
[18:25] <slangasek> and then use -0ubuntu2 as the revision number
[18:25] <slangasek> personally, given that it's CVS, I would go with option 1)
[18:25] <tumbleweed> as a variation on 1: it's a 3.0 (quilt) package, one can include the directory in debian and move them around in debian/rules
[18:26] <slangasek> tumbleweed: that's only a variation in that it's technically no longer a diff.gz :)
[18:26] <tumbleweed> slangasek: well, the question is, are the changes to that directory representable as a patch
[18:26] <barry> i think the one complication is that i can't have both directories when the build starts (the current rules don't support that, not that i couldn't change them)
[18:27] <barry> tumbleweed's suggestion sounds rather appealing actually :)
[18:27] <tumbleweed> yes, if you are going with 1, either you want to use the old version in the directory name rather than the new one, or you want modifications to rules
[18:27] <slangasek> oh, so the directory name changes and you can't have them both present? yuck
[18:27] <slangasek> barry: what happens if you just push the cvs snapshot into the directory named gdata_plugin-0.2?
[18:27] <barry> slangasek: right
[18:28] <barry> slangasek: hmm, that might work too actually.  it'd be a little white lie, but i can make that clear in d/changelog or in a readme
[18:28] <barry> and i think those changes *would* be representable as a diff
[18:29] <tumbleweed> think of it as bugfixes to 0.2 :)
[18:29] <barry> tumbleweed: yeah :)
[18:29] <barry> tumbleweed, slangasek thanks.  i'll try that and see how it goes
[18:29] <slangasek> barry: cool
[19:27] <GTRsdk> Where is the Ubuntu Unity Dash icon stored on the hard drive?
[19:44] <Ursinha> GTRsdk, maybe you can find that out by dpkg -L package
[19:48] <GTRsdk> It appears that the icon is not in the package
[19:48] <GTRsdk> I am guessing it is the distributor logo (Ubuntu logo) that is what is being used
[20:00] <stokachu> is /etc/default the equivalent to /etc/sysconfing on fedora/rhel?
[22:04] <slangasek> SpamapS: are you continuing to chase bug #859075?


[00:00] <vertago1> valorie: sorry I forgot to tag you in my previous responses. see above
[00:01] <valorie> I always read backscroll
[00:01] <valorie> :-)
[00:01] <valorie> vertago1: very good to see you
[00:02] <valorie> one thing we lack is up-to-date packaging documentation/tutorial
[00:02] <valorie> new packagers keep saying they'll do it, and presumably take notes, but so far, that's as far as it has gotten
[00:03] <wxl> valorie: et al. anyone need kubuntu tasks put into the google code-in queue?
[00:04] <vertago1> Is there an out of date wiki?
[00:04] <vertago1> https://wiki.kubuntu.org/Kubuntu/GettingInvolved/Development ?
[00:06] <valorie> wxl: KDE is doing GCi too
[00:06] <wxl> valorie: oh yeah duh, nevermind :)
[00:06] <valorie> so ....
[00:06] <wxl> i remember noticing that early on but i kind of forgot
[00:06] <valorie> we're rather short of mentor time this year
[00:06] <wxl> it's been a real whirlwind of activity for me the last few days
[00:07] <valorie> vertago1: that is a good page
[00:07] <valorie> but not detailed enough, right?
[00:07] <valorie> wxl: same here
[00:07] <wxl> valorie: i would suggest mentioning #ubuntu-google as a support option for students. there's a lot of questions that don't necessarily require the help of an expert, i've found
[00:08] <valorie> our KDE students aren't all using *ubuntu
[00:08] <valorie> but sure, I'll keep that in mind
[00:08] <valorie> we have #kde-soc
[00:09] <valorie> and #kde
[00:09] <wxl> well, for kubuntu things at least :/
[00:09] <valorie> etc.
[00:09] <valorie> right
[00:09] <valorie> haven't seen any students on #kubuntu yet
[00:09] <wxl> and honestly a lot of them just need help using the gci interface
[00:11] <valorie> we had one student abandon a task after asking a question FOUR MINUTES later
[00:11] <valorie> !
[00:11] <vertago1> valorie: yeah. I think some tutorials would be helpful. I am familiar with using apt source and adding a patch and rebuilding the package
[00:11] <valorie> but as I explained to the mentor -- this kid doesn't know that it's a world-wide community
[00:11] <valorie> or that it is a community at all
[00:12] <valorie> that there are real people involved, who work and sleep
[00:12] <tsimonq2> and:
[00:12] <tsimonq2> !patience
[00:12] <tsimonq2> THIS is why we need the bot in #uubntu-google
[00:12] <tsimonq2> *ubuntu
[00:13] <valorie> but to be fair: that's why there is such a contest
[00:13] <valorie> to introduce the students to the world of free software and the people who make it
[00:13] <tsimonq2> yep
[00:13] <valorie> and it takes some work on our part
[00:13] <tsimonq2> +1
[00:22] <vertago1> So if it fails because of a git exception don't troubleshoot it at the moment?
[00:26] <vertago1> From looking at the output of those recent failures it looks like there might be an issue with the merger and the backports branch
[00:28] <valorie> right, and scarlett had to leave to the deathbed of her aunt before she could troubleshoot/finish the merger
[00:28] <valorie> life and death happens
[00:31] <vertago1> If I were to look into it, where would I document what I find?
[00:37] <valorie> vertago1: I would either fix the doc you did find, or link new docs to it for specific topics, like : troubleshooting CI, Debian merges, Backporting
[00:37] <valorie> etc.
[00:37] <valorie> right there on teh wiki
[00:37] <valorie> also add missing links as you find them
[00:38] <valorie> hopefully at least the ones in the /topic of the chan are there.....
[00:40] <vertago1> ouch, the wiki just blew up
[00:40] <vertago1> openid.message.InvalidOpenIDNamespace
[00:42] <vertago1> do you know who maintains the wiki?
[00:42] <vertago1> or the server the wiki is on
[00:43] <vertago1> oh it looks like it was moved
[00:44] <vertago1> Here is probably the new location: https://community.kde.org/Kubuntu/Packaging
[00:44] <valorie> yeah
[00:45] <valorie> we stopped using the ubuntu wiki because it really sucks
[00:45] <valorie> oops, I should have looked at your URL more closely
[00:45] <valorie> sorry
[00:57] <vertago1> so L10n is localization?
[01:02] <vertago1> KCI supports 14.10 and later right? (Instead of just 14.10 and 15.04 dev)
[01:14] <vertago1> hmm it looks like there was a build of mgmt_merger that was aborted
[01:28] <xnox> hello, could you please re-build all of libkf5* in xenial-proposed?
[01:29] <xnox> (which is against qt5.5, all the way up to kubuntu-dev, to get libreoffice-kde installable on s390x?)
[01:29] <xnox> otherwise nothing will migrate until that is done, and I shall be doing binNMUs of all the kubuntu things, until they build on s390x and migrate.
[02:00] <xnox> however that is drastic
[11:57] <BluesKaj> 'Morning all
[12:01] <soee> hiho BluesKaj
[12:01] <BluesKaj> Hi soee
[14:33] <pursuivant> muon (master) v5.4.3-172-gbcc6f03 * Carlo Vanini: src/muonapt (2 files in 2 dirs)
[14:33] <pursuivant> Fix history dialog layout.
[14:33] <pursuivant> REVIEW: 126288
[14:33] <pursuivant> BUG: 343992
[14:33] <pursuivant> http://commits.kde.org/muon/bcc6f0334b9d3ffc6421571b758af5f84d90bb8c
[14:39] <soee> BluesKaj: do you tried maybe kos ?
[14:40] <soee> they have Plasma 5.5 in latest release i think
[14:40] <soee> *dev probably
[14:43] <BluesKaj> soee, where?
[14:44] <soee> http://kaosx.us/early-december-15-status/
[15:00]  * yofel needs a "Slow down" button for the world -.-
[15:24] <BluesKaj> soee, going to try kaos?
[15:25] <soee> maybe in a free time
[15:25] <soee> just for Plasma 5.5
[15:29] <BluesKaj> I have a spare partition, but I'll have a look at the live version first
[15:30] <BluesKaj> not rolling release fan
[15:31] <yofel> shadeslayer: would you be so kind to remove the stuff you and Scarlett got done from the card? https://trello.com/c/TCAk2U9J/71-debian-merges
[15:31] <yofel> most of the frameworks IIRC?
[15:31] <shadeslayer> all of them AFAIK
[15:31] <yofel> ah ok
[15:31] <yofel> then I'll just remove that checklist
[15:31] <yofel> thanks
[15:32] <shadeslayer> cheers
[15:34] <BluesKaj> any time line for Plasma 5.5 in the backports?
[15:37] <yofel> not really, though I hope I can say we have it in a ~week. From the order that's on the todo list, there's: apps 15.08.3 (WIP), frameworks 5.17 (releases on saturday), plasma 5.5
[15:39] <Mirv> as mentioned on #ubuntu-devel, two metric tons of packages are migrating to release pocket right now, so Qt 5.5 is finally done <- yofel, Riddell unping therefore regarding new big uploads
[15:39] <yofel> \o/
[15:39] <Mirv> I got a couple of plasma packages more to build on arm64 and that was one of the last things in addition to the multiple transitions in progress
[15:40] <yofel> Ok, perfect, thanks for your help with those.
[17:30] <ovidiu-florin> yofel: are you around?
[17:31] <yofel> ovidiu-florin: yes, for a bit
[17:32] <ovidiu-florin> yofel: 2 questions
[17:32] <ovidiu-florin> 1. these kubuntu-ci messages, are here for logging purposes, does someone actually read them?
[17:33] <ovidiu-florin> the status they present can be read from the CI itself, AFAIK
[17:34] <yofel> they are here for notification, and to remind people that there's stuff to fix (if $dev finds them so annyoing that he ends up fixing the failure, they serve their intended purpose)
[17:34] <ovidiu-florin> 2. is it written somewhere what needs to be done for the FW and Plasma that you told me needs to be done
[17:34] <ovidiu-florin> ?
[17:34] <ovidiu-florin> I think I have some time in the weekend, and I'd like to take a look at it
[17:35] <yofel> documentation of that is done on the ninja notepad, the workflow is heavily underdocumented though and the readme that exists is partly wrong.
[17:36] <yofel> That was supposed to be one of the tasks for automation-ng, but santa is MIA lately and his scripts are far from done, so for now we're stuck with the old scripts.
[17:37] <yofel> I started improving those, but after years of under-maintenance, getting things into shape again is non-trivial.
[17:37] <ovidiu-florin> bash or python scripts?
[17:37] <yofel> They do work though, as long as you know how to use them and what the pitfalls are (not documented)
[17:37] <sick_rimmit> Hi
[17:37] <yofel> Python mostly (some pieces require launchpadlib)
[17:37] <sick_rimmit> yofel: Did you get a resolution on the Server requirements from Michael ?
[17:38] <yofel> no
[17:38] <yofel> because I didn't do anything in that direction
[17:38] <sick_rimmit> Hmm, I see. Was a decision made.?
[17:39] <sick_rimmit> I understood that you and sgclark were discussing with mhall119 to make a decision whether to go with a JEnkins instance on Canonical
[17:39] <sick_rimmit> or to go with a Digital Ocean droplet ?
[17:39] <yofel> No. All I can still say is that sitter said that shell access is a requirement right now.
[17:41] <yofel> I'm honestly not sure how one would integrate our tooling into jenkins without shell access...
[17:41] <mhall119> AFAIK, we're waiting to know if the current CI setup needs shell access to work, of it a hosted Jenkins setup could be used
[17:41] <yofel> but I'm not jenkins expert and I didn't have time to read the ci-tooling yet either
[17:42] <mhall119> I've spoken to those who setup the jenkins-as-a-service in Canonical and have been told what we need to do in order to use it for Kubuntu
[17:42] <mhall119> so it all hinges on whether or not it can be run in that kind of setup or not
[17:42] <yofel> is that kind of setup documented somewhere?
[17:43] <mhall119> only our internal wiki I'm afraid
[17:43] <mhall119> but from what I understand, it's a vanilla Jenkins with the ability to include Jenkins plugins
[17:43] <mhall119> it actually uses one persistant control-node of Jenkins,and spins up build-nodes on demand
[17:46] <yofel> Ok. I probably won't have an answer for you this year. I want to replicate the CI in a VM over christmas so I actually know what I'm talking about
[17:46] <yofel> currently sgclark knows more about the CI than I do and she's on a trip
[17:46] <sick_rimmit> OK,
[17:47] <mhall119> yofel: ack, I'll be off the weeks of christmas and new year's anyway, so we can revisit this in January
[17:47] <sick_rimmit> I think the only stumbling block on Kubuntu side is the shell access.
[17:47]  * mhall119 notes that "off" doesn't mean "offline", just not normal hours :)
[17:47] <sick_rimmit> I believe that we can upload scripts for Jenkins to run, but that needs testing to be sure.
[17:48] <sick_rimmit> So, we'll revisit this in January..
[17:48] <yofel> probably. If we can integrate our ruby tooling using a jenkins plugin and figure whether/how docker is needed then the hosted instance would work
[17:49] <sick_rimmit> I add these notes to trello, and follow in the new year.. perfect thanks guys
[17:49]  * yofel spent some time reading "learn ruby the hard way" and still doesn't know why that's a language he wants to know....
[17:54]  * yofel makes his way home. bbl
[18:40]  * yofel found a fun thing from 4.8 times while cleaning up the disk https://kyofel.de/owncloud/index.php/s/KQL9vo8C24oVqKe
[18:40] <yofel> how nostalgic
[19:20] <Snowhog> apt complained about a missing plymouth plugin file this morning after my normal dist-upgrade. The missing file is kubuntu-text.so. Apt suggest fixing this by installing plymouth-themes. That package is installed, and reinstalling the plymouth packages results in the same complaint, that kubuntu-text.so is missing. A search of my system confirms that it does not exist. ubuntu-text.so does. Anyone aware of this issue? This is on my
[19:20] <Snowhog> 16.04 64-bit Kubuntu installation.
[19:22] <clivejo> I havent done an apt-get today
[19:22] <clivejo> so I havent seen that
[19:23] <clivejo> are you trying to run a Plymouth session?
[19:24] <clivejo> or is it a default boot?
[19:24] <Snowhog> No, not that I am aware of.
[19:25] <clivejo> like any customisations?
[19:25] <Snowhog> No customizations.
[19:26] <clivejo> sorry, doing other stuff here and getting ready to leave, but Ill take a look later.  Maybe yofel will be home soon and can shed some light on it
[19:26] <Snowhog> Appreciate that. Thank you.
[19:28] <yofel> I need to run as well, but please give a short step-by-step guide how you hit that error (or what commands one needs to enter to get the error message). I don't have an up-to-date xenial system around right now either
[19:28] <yofel> thanks
[19:28] <clivejo> http://packages.ubuntu.com/xenial/plymouth-theme-ubuntu-text
[19:28] <clivejo> apparently contains that file
[19:28] <yofel> the ubuntu one right, question is what requires the kubuntu one
[19:29] <yofel> could be that plymouth.hook that the changelog talks about
[19:29] <yofel> I'll look more into that later
[19:29] <clivejo> duh Im being stupid
[19:30] <clivejo> sorry, I better go!
[19:30] <clivejo> bye
[19:35] <Snowhog> Some, but not all, plymouth packages are installed by default -- as far as I know. At least, I didn't specifically install any when I installed 16.04. It was after running dist-upgrade this morning that I sas the complaint by apt. To reproduce, just update your package cache and then run a dist-upgrade. The warning appears at the end of the process.
[21:54] <valorie> yofel: I remember that!
[21:54] <valorie> fun times
[21:57] <clivejo> you hvae strange idea of fun :P
[22:05] <valorie> clivejo: yeah
[22:05] <valorie> lol
[23:11] <mparillo> It looks like Plasma 5.4.3 is landing in Xenial?
[23:13] <valorie> ? that seems rather old....
[23:24] <mparillo> I had 5.4.2 ever since the first ISO (no PPAs etc.)
[23:25] <soee_> and there is 5.5 already released :)
[23:27] <clivejo> :( Kmail is being a *beep*
[23:27] <clivejo> everyday now it stops working
[23:27] <clivejo> Unable to fetch item from backend (collection -1) : Unable to retrieve item from resource: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[23:27] <valorie> :(
[23:28] <valorie> restart akonadi?
[23:28] <wxl> yeah and now our it mgr is freaking out ready to blame kubuntu for some gpu hangs he's having
[23:28] <wxl> argh
[23:28]  * wxl facepalms
[23:28] <clivejo> I usually reboot and it fixes itself for a bit
[23:28] <valorie> rebooting seems a bit extreme
[23:28] <clivejo> but Im building calligra and cant reboot for a while
[23:28] <mparillo> Packagers are busy with other things. So I can save the time banging on 5.4.95 and just wait for 5.5.
[23:29] <valorie> but ya gotta do what ya gotta do
[23:29] <clivejo> akonadi restart doesnt seem to fix it
[23:29] <valorie> clivejo: if you use ccache, you can reboot and resume building
[23:30] <clivejo> its almost done
[23:30] <clivejo> at dh_strip
[23:40] <clivejo> famous last words
[23:51] <clivejo> its still building :/
[23:54] <clivejo> hi Snowhog
[23:54] <Snowhog> As to plymouth on my installs; I 'did' manually install plymouth, plymouth-label, plymouth-theme-kubuntu-logo, plymouth-theme-kubuntu-text, plymouth-theme-ubuntu-text, and plymouth-xll. libplymouth4 was installed automatically at some earlier point in time.
[23:55] <Snowhog> hi clivejo
[23:55] <clivejo> did you manage to fix the problem?
[23:56] <Snowhog> I installed those packages because I was noticing an inoccuous message during boot about plymouthd and something not being found. Didn't interfere with anything, but....
[23:58] <Snowhog> No, but if I remove the plymouth* installed packages except libplymouth4, I won't see that complaint. See above.


[14:29]  * cpaelzer lights a campfire for jamespage ddstreet sarnold doko and didrocks
[14:29] <sarnold> good morning
[14:30] <doko> hi
[14:30] <cpaelzer> #startmeeting Weekly Main Inclusion Requests status
[14:30] <meetingology> Meeting started Tue Oct 20 14:30:39 2020 UTC.  The chair is cpaelzer. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[14:30] <meetingology> Available commands: action commands idea info link nick
[14:30] <ddstreet> o/
[14:31] <cpaelzer> #topic Review of previous action items
[14:31] <cpaelzer> none but bug assignments, ... going on to the next agend entry
[14:31] <cpaelzer> #topic current component mismatches
[14:31] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[14:31] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[14:31] <cpaelzer> a lot things resolved
[14:31] <cpaelzer> and mismatches look rather well
[14:31] <cpaelzer> we have a few known false-positives
[14:31] <cpaelzer> octavia is ready for promotion
[14:32] <cpaelzer> btw does someone want to promote https://bugs.launchpad.net/ubuntu/+source/python-octavia-lib/+bug/1864666 ?
[14:32] <cpaelzer> it was completed this morning and IMHO can be pushed
[14:32] <doko> ok
[14:32] <sarnold> oh interesting, I was asked to do a security review of it yesterday, is that not needed?
[14:32] <cpaelzer> the rest is lintian (known and under doko's control), maas seed (known and ok that way) and raspi
[14:33] <cpaelzer> sarnold: sbeattie did the review
[14:33] <sarnold> ohho
[14:33] <doko> lintian is down to one package, pending security review
[14:33] <sarnold> thanks sbeattie :) I wonder when he got sleep.. if he got sleep..
[14:33] <doko> sarnold: discount
[14:33] <cpaelzer> \o/ sounds great doko
[14:34] <cpaelzer> btw a lot of the raspi things completed recently
[14:34] <cpaelzer> so overall - looking great
[14:35] <cpaelzer> #topic New MIRs
[14:35] <cpaelzer> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir
[14:35] <cpaelzer> the list is empty
[14:35] <cpaelzer> #topic Incomplete bugs / questions
[14:35] <cpaelzer> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.subscriber=ubuntu-mir
[14:36] <cpaelzer> the most recent touches are lintian and rpi things - both under control and not needing action from us right now
[14:36] <cpaelzer> #topic Any other business?
[14:36] <didrocks> nothing for me
[14:36] <cpaelzer> I need to pass soem thanks, I got two different positive feedbacks that the MIR process isn't as awkward or ugly as in the past
[14:36] <cpaelzer> so our regular syncs, direct assignment and efforts in general pay off
[14:36] <cpaelzer> thank you all for that!
[14:36] <didrocks> that’s nice to hear, but really thanks to the meeting and your effort :)
[14:37] <cpaelzer> I intend to bring up a new topci for discussion via mail soon (too mcuh text for IRC)
[14:37] <doko> thanks for swinging the whip ;p
[14:37] <cpaelzer> we have no list, so I'll start a mail thread with each of us on "TO"
[14:37] <cpaelzer> we will see how things work out from there
[14:37] <cpaelzer> just as a heads up :-)
[14:38] <cpaelzer> anything else  for the "misc" section of this meeting?
[14:38] <sarnold> cpaelzer: woo, thanks :) it's great to hear some positive feedback :)
[14:38] <cpaelzer> indeed
[14:39] <cpaelzer> ok - it seems this is the day we can be happy (for a minute or two) - and close the meeting early
[14:39] <cpaelzer> see you all ...
[14:39] <sarnold> thanks cpaelzer, all :)
[14:39] <didrocks> thanks everyone :)
[14:39] <ddstreet> thanks! o/
[14:39] <cpaelzer> #endmeeting
[14:39] <meetingology> Meeting ended Tue Oct 20 14:39:22 2020 UTC.
[14:39] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2020/ubuntu-meeting.2020-10-20-14.30.moin.txt


[00:53] -SwissBot:#xubuntu-devel- ATTN: Xubuntu Core 17.10 - i386 - i386 built.
[01:13] -SwissBot:#xubuntu-devel- ATTN: Xubuntu Core 17.10 - amd64 - amd64 built.
[10:56] <Spass> I'm planning to move Xubuntu testing to my main machine and I want to set it up similar to what flocculant was talking yesterday what he has
[10:57] <Spass> that way I'll be able to do exploratory testing more often
[10:59] <Spass> I have small questions regarding that, I have two drives in my machine 120GB for OS and 500GB for data, I want to install something stable on 120GB and use it as my main machine and I want to use some space from 500GB to create two partitions for Xubuntu daily installs
[10:59] <Spass> one with all PPAa enabled, and the other one "pure" daily
[11:00] <Spass> question 1) is it better to do testing on PPA enabled install with newest packages or on pure daily?
[11:02] <Spass> 2) how much space I'll need for these installs? I'm thinking 40GB for pure and 60GB for PPA enabled with some more stuff
[11:03] <Spass> 3) I assume when I'll install current AA daily I can just 'apt upgrade' it from time to time and I will be OK?
[11:40] <flocculant> 1 - that's the one I run as my daily
[11:41] <flocculant> 2 - if there's no data in the installs the answer is different :) my daily is probably too big - it has 17Gb of free space
[11:41] <flocculant> similar for my other artful install
[11:41] <flocculant> 3 - yes
[11:43] <flocculant> Spass: all my installs go on my 120Gb drive - the 2 artfuls and the 16.04
[11:45] <flocculant> as I said - probably all too big - and I have ~52Gb of free space there
[11:45] <flocculant> but - all of my real data is elsewhere on 3 other drives
[11:47] <Spass> ok, so I'll do something like - PPA 75GB, non-PPA 25GB, because I'll add some stuff on that bigger testing install, like Steam games, NVIDIA drivers from PPA etc.
[11:47] <Spass> I'll have a reason to boot to it from time to time, to do some gaming ;)
[11:48] <Spass> my plan is to keep my main OS on 120GB completely separate, without any unstable packages and non-free software even
[11:50] <flocculant> yep - that all sounds sensible
[11:50] <Spass> and I will install Xubuntu LTS on my laptop and occasionally do some Live Session testing from USB on it if needed
[11:55] <Spass> but before that I'll finish testing daily packages.qa.ubuntu.com/qatracker/ on that laptop
[11:57] <Spass> ok, so I guess that's a plan, yesterday's session was helpful, thanks
[11:59] <flocculant> thanks - makes it worthwhile for me :)
[12:00] <flocculant> bbl
[13:39] <bluesabre> morning all
[14:59] <bluesabre> interesting fact, video does not work in parole when running with CSD (probably because the X libraries were dropped with GTK3 in those areas)
[15:01] <bluesabre> and opengl seems to lock up intel graphics with a core 2 duo :D
[15:55] <stevehope> does 17.04 have https://bugzilla.xfce.org/buglist.cgi?bug_id=13541%2C13562 ?
[17:35] <Spass> I have a problem with today's daily ISO, it won't boot, tried creating USB with gnome-disks and Etcher
[17:36] <Spass> I see Plymouth screen with logo and spinning circle, it takes a while, then > https://drive.google.com/open?id=0B8qh4-wxxEZ7dGxtcmtVNEh6M0U
[17:37] <Spass> ISO downloaded twice, using Firefox and zsync
[17:52] <Spass> hmm, it boots in VirtualBox
[18:13] <Spass> tried again, legacy and uefi boot, pc and laptop, no success
[20:20] <flocculant> yup - not just ours though - checked 2 others:)


[08:52] <canaar> Hey guys
[09:11] <canaar> Anyone up
[15:48] <cimi> tsdgeos, something bad in your potfiles https://code.launchpad.net/~aacid/unity8/newCroppedImageMinimumSourceSize/+merge/269233
[15:48] <tsdgeos> cimi: yeah, fixing
[15:48] <tsdgeos> fixed already
[19:45] <josharenson> mterry: re https://code.launchpad.net/~josharenson/unity8/slim_greeter_real_lightdm/+merge/264191/comments/673632  Does this mean that the greeter backend would have to be determined at compile time?
[19:45] <mterry> josharenson, I'm saying we can build the code twice, with two different configs
[19:46] <josharenson> mterry: ah i see. So it would be 1 plugin, almost exactly like before, and a lot of cmake trickery?
[19:47] <mterry> josharenson, well a tiny amount of trickery  :)  like maybe a define or something
[19:47] <josharenson> mterry: ok ok, ill figure it out


 Tangentally related, did you ever file a bug about the Ubuntu Studio Calamares lack-of-swap-file bug?
[00:54] <arraybolt3[m]> Eickmeyer[m]: I don't remember. :P
[00:55]  * arraybolt3[m] finds out
[00:55] <Eickmeyer[m]> No worries.  Lunar can use the fix, too late for Kinetic since it would require a respin (fat chance) and Jammy would get it for 22.04.2.
[00:56] <arraybolt3[m]> Eickmeyer[m]: FWIW everything worked right until I did verbatim something Simon told me to do and it failed :P
[00:56] <Eickmeyer[m]> arraybolt3[m]: #SimonsFault
[00:57] <arraybolt3[m]> lol
[00:57] <arraybolt3[m]> Total off-topic, but I found out about r/SuggestALaptop earlier. Finding a system that works for people is pretty fun.
[00:58] <arraybolt3[m]> Still haven't found a good spot to advertise a KFocus, but maybe someone will come on with a decent budget looking for a Linux system. One can dream, right?
[00:58] <Eickmeyer[m]> I'm going to be bringing both my Kfocus systems to Summit.
[00:59] <arraybolt3[m]> Speaking of KFocus, quite some time ago I left my laptop upside-down overnight, thinking that would be perfectly fine. (I was originally leaving it upside-down during large compile jobs.) After that one night, every time the screen comes on after having been black for a long time, I have this very visible white haze around the outer edge that takes around an hour or two to fade away. It doesn't impair my usage of the system at
[00:59] <arraybolt3[m]> all, but I am wondering what's up with that and if maybe I accidentally messed up the screen.
[01:00] <Eickmeyer[m]> arraybolt3[m]: Very possibly. Those things aren't made to run upside-down.
[01:00] <arraybolt3[m]> :( Didn't know that, my other systems don't have any problem being upside down. Oh well. At any rate, it's still working fantastic.
[01:01] <Eickmeyer[m]> Awesome. Do yourself a favor.  Hey, you live and learn. Very happy that the screen still works at all, and works this good.)
[01:03] <Eickmeyer[m]> The XE is pretty awesome, tbh. Great little systems.
[01:03] <arraybolt3> Agreed.
[01:03] <Eickmeyer[m]> I'll be using mine for my presentation in Prague.
 "FWIW everything worked right..." <- weak sauce 💪 😆
[01:27] <tsimonq2> Okay, no, seriously...
[01:27] <tsimonq2> Looking
 *obtains coffee then prepares for a round of evil*
[13:13]  * kc2bez[m] energizes his personal chaos shield.
[15:41] <tsimonq2> Looks like my packages were accepted and Lunar is now bootstrapped
[15:41] <tsimonq2> Autosync will be turned back on, probably shortly
[15:45] <kc2bez[m]> There has been some action in the Debian LXQt team so we will need to watch out for that.
[16:21] <arraybolt3> tsimonq2: What all happened with that package last night?
[16:21] <arraybolt3> The lubuntu-meta one?
 "Simon Quigley: What all happened..." <- ENOTATCOMPUTER
 "Simon Quigley: ^ diff containing..." <- Try this again within a Lunar (s)chroot(/LXD container) - all of the essential packages have been accepted
[21:12] <arraybolt3[m]> 👍 Will do soon!
[21:13] <tsimonq2> Thanks!
[21:14]  * tsimonq2 sent a code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/26324a39fe69c5bb704427605f54d09516aad29c
[21:15] <tsimonq2> I used the Git copy, that diff is from https://launchpad.net/ubuntu/lunar/+queue?queue_state=1&queue_text=
[21:15] <arraybolt3[m]> Building the Lunar schroot now.
[21:16] <Eickmeyer[m]> That's a weird diff.
[21:16] <arraybolt3[m]> Oh and I still forgot to sync with the archive in all my Lunar work. 🤦
[21:16] <arraybolt3[m]> OK so that will need done too.
[21:18] <arraybolt3[m]> Nothing git rebase -i can't handle.
[21:19] <arraybolt3[m]> Simon Quigley: Exact same error as before, on Lunar.
[21:20] <arraybolt3[m]> The parentheses seem to still be confusing it.
[21:20] <tsimonq2> arraybolt3[m]: Upgrade to -proposed. The only time I'll EVER say that for a development cycle, but I know what's gone in, you'll be cool
[21:21]  * arraybolt3[m] tries some apt-fu inside the schroot to do that
[21:22] <tsimonq2> echo "deb http://us.archive.ubuntu.com/ubuntu lunar-proposed main restricted universe multiverse" | sudo tee -a /etc/apt/sources.list && sudo apt update && sudo apt -y full-upgrade
[21:23] <arraybolt3[m]> Simon Quigley: Enabling -proposed did nothing. "apt update" tells me there's nothing to update.
[21:23] <arraybolt3[m]> And yes, it does access the -proposed archive during the update process.
[21:23] <tsimonq2> Here, let me just try messing around with this on my end; I have Lunar running on bare metal :P
[21:24] <tsimonq2> I don't know what the root problem would be here
[21:24] <arraybolt3[m]> I think we just have syntax wrong, did you check my diff?
[21:24] <tsimonq2> Yeah, I'll check again though :)
 "Oh and I still forgot to sync..." <- once CI is set up we really should script this heh
[21:25] <arraybolt3[m]> Anyway, while you're doing that, I'll sync with the archive and try to worm that into the Git history hopefully without fouling up all of creation.
[21:25] <tsimonq2> just no force pushes unless you're 100% sure in what you're doing ;)
[21:26] <arraybolt3[m]> Eh, I've not even pushed anything to Git yet so we're good.
[21:26] <arraybolt3[m]> (Actually I did at one point way prematurely and then deleted it before anyone else (should have) used it.)
[21:28] <tsimonq2> Hey, as long as you're honest about your mistakes, I'm not going to yell :)
[21:31] <arraybolt3[m]> Feels like Git is starting to get a bit easier. Still brain-bending but not as bad as before.
[21:31] <tsimonq2> It's a lot to take in, but once you have the ropes down, it's hard to live a developer life without it :)
[21:31] <tsimonq2> Always happy to help if you aren't understanding something
[21:34] <arraybolt3[m]> Simon Quigley: Alright, scary question, but will `rm *` delete all hidden files in a directory too? I want to delete all the visible ones so I can just full-force clobber the current branch I'm on with the contents of the archive, but I don't want to accidentally nuke the .git folder either. (Caution for spectators - this command is destructive and very dangerous, don't use it unless you know what you're doing, which I don't, thus
[21:34] <arraybolt3[m]> why I'm asking Simon.)
[21:34] <arraybolt3[m]> I mean I could just make a copy and then try it but...
[21:35] <arraybolt3[m]> Actually I made a backup and then tried it, worked as intended.
[21:35] <tsimonq2> Nope, the wildcard only matches non-hidden files, at least in my experience. If you're looking to remove hidden files, while you *could* use something like `.*`, I would be very careful about what files are in your present and parent directory. `.*` tends to match `cwd` and `../` - at least in my usage
[21:36] <arraybolt3[m]> shudder that sounds about as bad as... what is the nickname for that command? Let's just call it Halt and Catch Fire to All Data.
[21:36] <tsimonq2> To be completely safe, if I need to clear an orig source from a packaging repo, I'll `rm -rf !(debian) && ls -lah && rm .foo .bar .baz` (explicitly)
[21:36] <tsimonq2> hah
[21:40] <arraybolt3[m]> Simon Quigley: Alright, I have one more question (hopefully last one for now). In the archive sync, I see there was one change to Jammy that was made as well, before it switched to Kinetic. However pull-lp-source, obviously, doesn't return a Git repo, meaning that the ubuntu/jammy branch is behind and I have no way of knowing exactly what changed so that I can move just the Jammy changes over. Thoughts? Do we leave ubuntu/jammy
[21:40] <arraybolt3[m]> forev... *lightbulb moment* nevermind, carry on
[21:40] <arraybolt3[m]> `pull-lp-source lubuntu-meta jammy`
[21:41] <tsimonq2> https://code.launchpad.net/ubuntu/+source/lubuntu-meta
[21:41] <arraybolt3[m]> Oh.
[21:41] <arraybolt3[m]> OK nevermind I'll just use that instead.
[21:46] <arraybolt3[m]> Shoot. I tried to do a git fetch from that repo and now have an entire slew of tags that I didn't have before that I can't get out easily.
[21:48] <arraybolt3[m]> I mean I guess I don't have to push tags so it's not really a big deal but :(
[21:48] <tsimonq2> 1) You can `git fetch` specific branches from remotes, sorry, should have told you that earlier :/
[21:48] <tsimonq2> 2) You can delete local tag references
[21:51] <arraybolt3[m]> Eh, it's OK, I wasn't making or pushing any tags anyway so no harm done.
[21:51] <tsimonq2> No worries :)
[21:52] <arraybolt3[m]> And... whew, got the Jammy part updated!
[21:52] <tsimonq2> Very nice!
[21:52] <arraybolt3[m]> I should be just a few cherry-picks away now.
[22:01] <arraybolt3[m]> Well Jammy and Kinetic were easy enough... and now because I did Lunar without syncing with the archive first, I have to redo the whole thing if I want to be sure I did it right akjnfi7yrtidugh9soe487tyzuyrghif
[22:04] <arraybolt3[m]> On the bright side, I just moved all my old work to a different branch, reset ubuntu/lunar to the beginning, and now can redo it easily enough with git cherry-pick and the update script.
[22:04] <arraybolt3[m]> (If my reporting is getting annoying, feel free to tell me, I just figure since I'm in training this is a good idea so someone can give me a quick redirection if I start flying toward a brick wall.)
 "(If my reporting is getting..." <- Don't take me leaving you on read as a sign it's not important - I have a lot of moving parts and every once in a while need a reminder :)
[22:13] <tsimonq2> (I was just signing some documents)
[22:14] <arraybolt3[m]> Ah, it wasn't that. I just thought maybe seeing tons of reports might be getting annoying. I don't need or expect you to always answer or even see everything I type.
[22:17] <arraybolt3[m]> Lovely. So now that I'm doing it right, I need to use a Kinetic VM or similar.
[22:17] <arraybolt3[m]> `[info] Initialising lubuntu-* package lists update...
[22:17] <arraybolt3[m]> /usr/bin/germinate-update-metapackage: Installed debootstrap is older than in the previous version! (1.0.126+nmu1ubuntu0.1 < 1.0.126+nmu1ubuntu1)`
[22:17] <tsimonq2> HAHAHAHAHAHA
[22:18] <tsimonq2> I love that
[22:18] <arraybolt3[m]> Me, not so much so!
[22:18] <tsimonq2> Well, it's cached somewhere
[22:18] <tsimonq2> `grep -R "1.0.126+nmu1ubuntu0.1"` (you may have to escape some special characters
[22:19] <arraybolt3[m]> No that's the debootstrap I have installed I think.
[22:19] <arraybolt3[m]> Yep.
[22:19] <tsimonq2> er then do the `ubuntu1` version with grep :)
[22:19] <arraybolt3[m]> (I'm on Jammy.)
[22:20] <arraybolt3[m]> Simon Quigley: It's in debootstrap-version.
[22:20] <arraybolt3[m]> Which I think is as it should be, though maybe I need to update it to Lunar's version, in which case I need a Lunar VM.
[22:21] <arraybolt3[m]> (Does the update script automatically update that file too?)
 "(Does the update script automati..." <- Yeah, it does
[22:28] <arraybolt3[m]> K, then Lunar VM it is.
[22:31] <tsimonq2> Trying this locally myself to see what I can come up with. Sec
[22:35] <tsimonq2> > <@arraybolt3:matrix.org> ```... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/98c4e2b9cb49c843a736e0e13fa726de5eaa0123>)
[22:35] <tsimonq2> Did you run ./update before building the package with `debuild`?
[22:35] <arraybolt3[m]> After making the change? No.
[22:35] <arraybolt3[m]> Like, I ran update, I did the work, I made the change, then tried sbuild. I didn't run update a second time.
[22:36] <tsimonq2> Ahhhhhhhh, bingo
[22:36] <tsimonq2> You run `update` every time you update `update.cfg`
[22:36] <tsimonq2> Let me make sure this completely works locally before I jump the gun, then I'll walk you through :)
[22:37] <arraybolt3[m]> Simon Quigley: I didn't edit update.cfg though, I edited the seed files because I thought you said to do that.
[22:37] <tsimonq2> oHHHHHHHHHH
[22:37] <tsimonq2> okay let'
[22:38] <tsimonq2>  * okay let's slow down for just a quick sec
[22:39] <arraybolt3[m]> Meanwhile I'm going to accidentally enable -proposed whilst trying to upgrade to Lunar in a VM.
[22:40] <tsimonq2> All I had to do to make this work on a lunar system was this:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/73004495ecf3a1baef0ce7a714dd4162d471bbc1>)
[22:41] <arraybolt3[m]> Yes, all of that makes sense... but then where exactly is the file where I surround "xfonts-efont-unicode" in parentheses?
[22:41] <arraybolt3[m]> Everything built perfectly right up until I modified the seed files manually.
[22:42] <arraybolt3[m]> Also how on earth do I upgrade to Lubuntu Lunar?... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/9ed1e59d1e2ce86c37bcc63feafe2323d9ff05cd>)
[22:42] <tsimonq2> Clone the seed repo in a separate dir, https://git.launchpad.net/~lubuntu-dev/ubuntu-seeds/+git/lubuntu - make an MP on Launchpad, I'll accept it, then it'll magically be fixed as soon as it's merged
[22:42] <arraybolt3[m]> (From a Kinetic VM, full updated.)
[22:42] <tsimonq2> > <@arraybolt3:matrix.org> Also how on earth do I upgrade to Lubuntu Lunar?... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/ed5601707c883eec29db10e4f3e95202c009dd35>)
[22:42] <arraybolt3[m]> Simon Quigley: Oh. That's easy, OK.
[22:42] <tsimonq2> DO NOT RUN THIS, LOG-READING USERS:
[22:42] <tsimonq2> ```
[22:42] <tsimonq2> sudo sed -i "s/kinetic/lunar/" /etc/apt/sources.list
[22:42] <tsimonq2> ```
[22:43] <tsimonq2> arraybolt3[m]: All `do-release-upgrade` is, is a wrapper around running that command ^^^ and any manual workarounds required
[22:43] <arraybolt3[m]> Oh seriously? Cool, didn't know that.
[22:43] <tsimonq2> Yeah :)
[22:44] <tsimonq2> I've always been told... a fresh install is much cleaner than an upgraded install, simply because yes, there are some occasional manual workarounds needed :/
 "Meanwhile I'm going to accidenta..." <- Looks like they changed this recently (good, I'm glad); to update to -proposed you should use the following:
[22:50] <tsimonq2> ```
[22:50] <tsimonq2> $ sudo apt -t lunar-proposed full-upgrade
[22:50] <tsimonq2> ```
[22:52] <tsimonq2> https://autopkgtest.ubuntu.com/running <- looks like that's blocking the migration of debootstrap et al.
[22:59] <tsimonq2> arraybolt3: I have to come back to the office tonight anyway - I'm off to the gym but if you could send me the seed MP at some point, as time allows, I'd appreciate it
[22:59] <arraybolt3[m]> Will do hopefully, if I can figure it out.
[23:00] <tsimonq2> Happy to answer questions, let me know :) have fun!
 "All `do-release-upgrade` is..." <- At this point in the cycle there isn't much going on so this is pretty safe really.
[23:12] <kc2bez[m]> The substitution is safe is what I was implying.
[23:14] <kc2bez[m]> Personally I copy my current development VM and then run the substitution magic early on.
[23:14] <kc2bez[m]> That way I can fall back to my old VM if I need it and I can have it for a SRU or something.
[23:15]  * arraybolt3[m] wishes I had a development machine to clone
[23:15] <arraybolt3[m]> I just spun up a new machine just now, since I usually just do all development work straight on my laptop.
[23:17] <kc2bez[m]> I try to not pollute my host machine with development builds.
[23:18] <kc2bez[m]> A LXD container works nicely instead of a VM if you want to keep things light and minimal.
[23:21] <arraybolt3[m]> I use sbuild for everything so I figured that would keep me mostly clean.
[23:22] <arraybolt3[m]> Everything except PPA builds that is.
[23:23] <arraybolt3[m]> But anyway, I'll just use a VM for now. I should learn LXD at some point but it was a nightmare the first time I played with it so I've not used it in a while.
[23:23] <arraybolt3[m]> (That was back with Ubuntu 16.04 and 20.04.)
[23:24] <kc2bez[m]> The docs are much better now.
[23:25] <arraybolt3[m]> And I'm not using an official Ubuntu derivative.
[23:25] <arraybolt3[m]> And I know to not find info from random blogs on the Net.
[23:25] <arraybolt3[m]> s/official/unofficial/
[23:25] <arraybolt3[m]> (Wow there's a typo for you... not using an official Ubuntu derivative?)
[23:27] <kc2bez[m]> Anyway, having all my build stuff in my VM keeps all the git clone, pull-lp-source etc. contained away from my normal stuff along with built packages. To boot they get done on the same release that I am building for.
[23:28] <arraybolt3[m]> Nice.
[23:28] <arraybolt3[m]> My usual stuff is building on bare metal and then testing on a VM, and I have a ~/Projects/ubuntu dir that holds all my packaging work.
[23:28] <arraybolt3[m]> But using a dedicated VM sounds a lot smarter.
[23:30] <kc2bez[m]> It works well for me. You will find your groove too.
[23:30] <arraybolt3[m]> Mine has been working for me right up until this moment 🥴
[23:31] <kc2bez[m]> That's the way it always goes.
[23:31] <kc2bez[m]> XD