[02:36] <TheMuso> Anybody seen this error with schroot on a recent fres precise install? E: Access not authorised
[02:41] <broder> TheMuso: is that the thing where you need to generate a key for the temporary local apt repositories?
[02:41] <TheMuso> broder: No.
[02:41] <TheMuso> Thats for sbuild, this is trying to use schroot.
[02:41] <broder> ok. no idea then :)
[02:47] <TheMuso> Ah right, seems in Oneiric and earlier I was a member of admin, which is listed in the valid groups for my schroots, but I am no longer in that group for precise, so adding myself to sbuild fixed it.
[02:49] <broder> are we changing the semantics of the admin group or something, or was that just a personal choice on your part?
[02:50]  * micahg things admin is no longer created in precise
[02:50] <TheMuso> I don't remember ever adding myself to admin, and I used a schroot.conf snippet from mk-sbuild a while back, so other than adding chroots/overlays to my schroot.conf, I have not changed groups etc.
[02:50] <TheMuso> micahg: I think you're right.
[02:50] <micahg> https://launchpad.net/ubuntu/precise/+source/user-setup/1.39ubuntu1
[02:52] <broder> cool, i had been wondering if we were going to do that at some point
[04:44] <CrazyThinker> Where can I find ubuntu source code?
[04:52] <pitti> Good morning
[07:19] <doko> bjsnider, ?
[07:51] <dholbach> good morning
[08:16] <janimo> pitti, morning this ARM kernel SRU has been tested, but I just recently (now) commented on it being validated https://bugs.launchpad.net/ubuntu/+source/linux-ac100/+bug/874264
[08:17] <janimo> can you please push it to updates when your time allows? thanks
[08:21] <pitti> janimo: done
[08:21] <janimo> \o/
[08:42] <CrazyThinker> What tool can display the inode structure of a system beautifully?
[11:16] <hrw> does someone know how to force udisks to refresh list of block devices?
[11:17] <hrw> bug 601351
[11:40] <pitti> ev: btw, you know that you can reconstruct .crash files pretty easily from LP bugs, using python-apport?
[11:41] <pitti> ev: we can even get .crash files with core dumps if you get the bugs tagged "apport-failed-retrace"
[11:41] <ev> ah brilliant, though I do think it would still be worthwhile to have some that are retraceable
[11:41] <ev> (as mentioned, whether these are manually constructed or come from that data set is up to you)
[11:44] <pitti> ev: for example, bug 754358 is not exactly bad for testing, it's just not considered good enough for automatic duplication (the way we do it right now)
[11:45]  * pitti checks the retracer logs whether they already picked up a dupe since yesterday
[11:46] <pitti> right, seems so; bug 891503 is one example
[11:48] <ev> pitti: ah, fair play.  I'll just work with that data then.
[11:51] <pitti> hmm, I looked at a few, and the addresses are differing a lot :(
[11:56] <pitti> ev: I changed the DC retracer to keep ProcMaps.txt as well; working with offsets in the libraries instead of with absolute addresses might be better after all
[11:56] <ev> hm, okay
[11:57] <pitti> I'll do some research, I have nothing urgent to do this afternoon
[12:08] <pitti> ev: ah, so it seems addresses in the actual executable remain stable, but libraries get relocated at each run; that's what misled me on my quick try at UDS
[12:09] <pitti> but it's not really a surprise indeed
[12:09] <ev> phew
[12:29] <pitti> ev: \o/ offsets FTW (http://paste.ubuntu.com/741116/)
[12:29]  * pitti goes to turn that into code
[12:29] <ev> YAY!
[12:29] <pitti> doing this stuff with a calculator is a bit tedious
[12:30] <ev> :D
[12:30]  * cjwatson attempts to construct a reproduction case for bug 891257 that's smaller than "upgrade Steve's laptop"
[12:31] <ev> lol
[12:33] <cjwatson> I guess if I C-z at a particular point ...
[12:50] <hyperair> pedro_: ping
[12:50] <pedro_> hyperair, hello
[12:50] <hyperair> pedro_: https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/744257 <-- please verify if the fix in oneiric-proposed works.
[12:50] <pedro_> hyperair, ok I'll check it in a minute
[12:50] <hyperair> thanks
[12:50] <pedro_> you're welcome
[13:05] <zul> can someone review python-keystoneclient for me please?
[13:06] <doko> jamespage, do you an idea about the java component mismatches?
[13:12] <Kalidarn> hi quick question, is thunderbird major releases maintained in between releases?
[13:13] <Kalidarn> ie 7.0.1 to 8.0 or would i need to wait till Precise Pangolin for support?
[13:13] <Kalidarn> it appears ppa:mozillateam/thunderbird-stable does not support oneric, and ppa:mozillateam/thunderbird-next as of this morning replaced 8.0 with 9.0b1
[13:14] <Kalidarn> according to the release notes for 8.0 a couple of security fixes occured
[13:14] <Kalidarn> Thunderbird 8 closes six security holes. Three of these were rated as critical issues: memory corruption while profiling using firebug, code execution via NoWaiveWrapper and miscellaneous memory hazards have been fixed. The remaining high-risk vulnerabilities include two cross-origin theft bugs and a potential cross-site scripting (XSS) hole.
[13:16] <jdstrand> Kalidarn: for 11.10, we are following the rapid release, so it will get tbird 8. updates are being prepared.
[13:16] <Kalidarn> I'd assumed so especially as the I don't like outstanding security issues with my system :)
[13:17] <jdstrand> indeed
[13:17] <Kalidarn> thanks for answering my question even though #ubuntu-devel may not have been the correct place nobody seemed to know in #ubuntu or in #thunderbird on irc.mozilla.org :P
[13:17] <jdstrand> Kalidarn: if you have questions about security, please visit #ubuntu-security (or #ubuntu-hardened, which is the same channel)
[13:18] <Kalidarn> hmm i might add that to my znc idle listing :)
[13:18] <Kalidarn> because that is of interest to me.
[13:55] <feldgendler> hello!
[13:55] <feldgendler> I'm Alexey Feldgendler from Opera Software
[13:56] <feldgendler> mvo: I was told I should talk to you about this issue
[13:56] <feldgendler> I'm responsible for packaging Opera for Debian and Ubuntu.
[13:56] <feldgendler> i'm currently struggling with the following problem: on every distribution upgrade done by the upgrade manager, our third-party package source that we add to /etc/apt/conf.d gets disabled
[13:56] <feldgendler> I know it's deliberate
[13:57] <feldgendler> if the rationale behind this problem is to prevent third-party packages from breaking the upgrade due to e.g. outdated dependencies, fair enough, but is there a way for us to bypass this mechanism?
[13:57] <feldgendler> we routinely test in all new Ubuntu releases and take care that our dependencies are correct
[13:57] <feldgendler> worse still, not only do upgrades of Opera get disabled, but also the existing Opera package gets removed as “obsolete”, in the worst case leaving the user without a browser
[13:58] <mvo> hey feldgendler, I'm on the phone right now, but I come back to you in some minutes (once the call is over). ok?
[13:58] <feldgendler> mvo: sure, thanks a lot!
[14:06] <jamespage> doko: libcommons-discovery-java switched build system from ant -> maven
[14:06] <jamespage> I'll fix it up next week - sprinting this week
[14:29] <Chipzz> feldgendler: if it gets disbaled deliberately, maybe you're simply not *meant* to work around it?
[14:31] <bjsnider> doko, still there?
[14:33] <rye> kenvandine, ping, re: bug #874501 - it looks like the SRU for Oneiric for that specific bug is blocked. What's the bug for "Return password results with the most recent result first"?
[14:36] <kenvandine> rye, ugh...
[14:38] <kenvandine> rye, there isn't a bug referenced in the upstream Changelog
[14:40] <kenvandine> however, I would imagine that returning the older entry should never been what is intended and if anything this fixes stuff
[14:41] <kenvandine> but i am not an expert on gnome-keyring
[14:41] <rye> kenvandine, mmm... is there atestcase? So that we could file it, test it, provide the test result and give the info on regression potential
[14:42] <kenvandine> rye, not sure if that would really help in this case... the problem would be determining if anything is actually expecting the older entry
[14:42] <kenvandine> i think the regression potential is the change in behavior, and maybe other apps depended on the broken behavior
[14:43] <kenvandine> i doubt that is the case, but it is hard to determine that
[14:46] <kenvandine> rye, all the other fixes in this release are clear wins... and i suspect this fix could be a good thing too... i doubt anyone expects to get the older result... if they even know that multiple entries are created
[14:47] <rye> kenvandine, true, I will file a separate bug which can be referenced to
[14:48] <kenvandine> rye, there was a test included in the upstream commit for it... but I am sure it is just to ensure the latest is returned
[14:48] <kenvandine> that doesn't help us measure risk of regression
[14:49] <seb128> you have two options there, revert the commit in the sru or do a "check that nothing you use get broken"
[14:50] <seb128> the number of keyring users is a reasonable set, the default desktop contains a good part of it
[14:51] <feldgendler> Chipzz: maybe I can take that as an answer, but not until I understand the rationale
[14:53] <feldgendler> Chipzz: still, something is wrong if the user installs Opera, then upgrades Ubuntu and loses Opera in the process. I fail to see how this benefits the user.
[14:58] <dobey> feldgendler: the updater doesn't know whether or not the new release is supported by those archives that were added; or that the packages in the archive for the previous release will necessarily install/work/notbreaktheworld on the new release
[14:58] <dobey> feldgendler: also, packages shouldn't be adding archives when they get installed
[14:58] <feldgendler> dobey: I see. so the updater doesn't know if our source is prepared for the new release. but is there a way for us to indicate that?
[14:59] <dobey> feldgendler: no there isn't
[14:59] <feldgendler> dobey: before we had automatic addiing of archives, we used to recommend the user a manual prodecure with the same result, and which would have the same problem
[15:00] <feldgendler> dobey: also, we ask a debconf question before we add our acrhive, so I don't believe we're violating anything
[15:00] <OdyX> .oO(Making Opera distributable by others would help…)
[15:01] <feldgendler> we're working on that
[15:01] <feldgendler> still, some Debian-based distributions never accept non-free software, so it's a non-option for them
[15:02] <OdyX> feldgendler: then make Opera DFSG-free. .-p
[15:03] <Laney> the user can set an environment variable or condifuration option to turn off the disabling
[15:03] <Laney> and from reading the source I just noticed that the env var has a typo(!)
[15:04] <Laney> "RELEASE_UPRADER_ALLOW_THIRD_PARTY" in os.environ
[15:04] <feldgendler> mvo: what can you say about it?
[15:05] <feldgendler> Laney: I know. that's equivalent to setting AllowThirdParty=True in the update manager config overrides
[15:05] <geser> feldgendler: have you tried to get opera into the Ubuntu partner archive? that could be one option to avoid getting opera deinstalled on upgraded
[15:05] <Laney> indeed
[15:05] <dobey> is the precise release schedule not final yet?
[15:06] <feldgendler> Laney: however, I tried it and it didn't work. looking at the code, I see that it only keeps the entries that mention the name of the current release as the distro name.
[15:06] <feldgendler> Laney: the name gets changed to the name of the new release
[15:06] <Laney> that is what i would expect, yes
[15:06] <feldgendler> Laney: the whole AllowThirdParty feature seems to be designed for local Ubuntu mirrors (that would use Ubuntu release names) rather than third-party software sources.
[15:08] <feldgendler> geser: yes, we're working on that. still, Opera would then only appear in multiverse, right? which means that by default, if you download and install Opera by clicking “download” on the official website, you'll end up with no updates
[15:08] <mvo> feldgendler: sorry for the delay, indeed, there is a global way to override it
[15:08] <feldgendler> geser: using a browser which doesn't get updated is risky because of the vulnerabilities that get fixed all the time
[15:09] <feldgendler> mvo: I'm currently considering the following as a workaround; enable AllowThirdParty=True and mention the current distro name in our source lines
[15:09] <feldgendler> mvo: that way, the updater will change the distro name to the new release name but otherwise keep our sources intact
[15:09] <mvo> feldgendler: so there is currently no really good answer, I would *love* to see opera in e.g. archive.canonical.com or integrated via the new developer.ubuntu.com archive so that it could become part of the "official" archive in some way, but I understand that this is not easy from your side
[15:10] <feldgendler> mvo: we're working on that
[15:10] <feldgendler> mvo: but see above about downloading Opera from the official website
[15:11] <geser> feldgendler: the partner repository (partner.ubuntu.com) is different from the multiverse component of the main repositories
[15:11] <mvo> feldgendler: indeed, that will work, but this will enable third party archives globally, let me have a look at the code to see if we can hve a more fine grained solution. I think the distro release name in the sources.list is a good step, essentially you need a way to tell update-manager that opera is a official mirror
[15:11] <feldgendler> mvo: I've exlored that possiblity
[15:12] <mvo> feldgendler: if opera would be in partner/multiverse for all users that have multiverse/partner enabled (that is the default) it would just work, when there is a update that is newer than the version downloaded from the web you would get it
[15:12] <feldgendler> mvo: but the list of mirrors comes in /usr/share/update-manager/mirrors.cfg which is not a conffile
[15:12] <mvo> feldgendler: indeed, but I can add you code for 12.04 to make it possible to have additional mirrors :)
[15:12] <feldgendler> mvo: I would love that!
[15:13] <feldgendler> mvo: while you're at it, maybe you could remove the disabling of those sources that don't mention an Ubuntu release?
[15:14] <mvo> feldgendler: do you have a example what your current deb line looks like for me?
[15:14] <feldgendler> mvo: things like Opera, Skype, Google Chrome don't usually make different builds for different Ubuntu releases. in fact, Chrome has its own releases, and uses “stable”, “testing” and “unstable” as the release name
[15:14] <feldgendler> mvo: deb http://deb.opera.com/opera/ stable non-free #Opera Browser (final releases)
[15:14] <feldgendler> the word “stable” we use there is arbitrary
[15:15] <feldgendler> we only have one Opera
[15:15] <mvo> thanks feldgendler
[15:16] <feldgendler> we also have this one:
[15:17] <feldgendler> deb http://deb.opera.com/opera-beta/ stable non-free #Opera Browser (beta releases)
[15:21] <mvo> feldgendler: thanks, I check the source in u-m now to see what I can do about this and get back to you, ok?
[15:22] <feldgendler> mvo: sure, thanks!
[15:35] <Chipzz> mvo: maybe the distro upgrade should output a question along these lines "Hi. You haz 3rd party repository enabled. We recommendz you to disable it in orde nt to break upgrades. Disable yes/no?"
[15:36] <Chipzz> with a default "Yes"
[15:36] <pitti> cjwatson, stgraber, mdz, kees, soren: TB is still at 1800 UTC today, i. e. an hour earlier now with winter time?
[15:38] <cjwatson> damn, I haven't had time to process the doodle output
[15:38] <cjwatson> yes, I guess so
[15:39] <stgraber> pitti: I assumed so. Hopefully we'll have a new meeting time after this meeting
[15:40] <stokachu> _jmp_, o/
[15:41] <soren> cjwatson: Are my e-mails to the mailing list not getting through? I sent one earlier today about this.
[15:48] <stgraber> soren: only e-mails I saw today were from Steve and Kate
[15:51] <pitti> I did a moderation run today
[15:52] <cjwatson> soren: I've approved your mail now
[16:08] <pitti> debfx: fontforge-extras> please note that we dno't need to keep a delta for Section: changes, we can fix that in our archive overrides
[16:18] <SpamapS> slangasek: seen the fervor around bug 856810 ? Seems like people aren't getting /run symlinks maybe?
[16:22] <debfx> pitti: so I should revert the diff, file a bug and subscribe ubuntu-archive?
[16:27] <pitti> debfx: I don't actually think that the section will change if you change it in an upload
[16:27] <pitti> sections are defined when binNEWing
[16:27] <pitti> (or changing manually)
[16:27] <pitti> not with every upload, AFAIK
[16:27] <pitti> at least that's how Debian works, and I'm 90% sure that LP works the same
[16:27] <pitti> debfx: it's not urgent, just wanted to point out that next time you can just sync :)
[16:37] <debfx> pitti: if it's not done automatically, who handles section/priority mismatches (especially for packages synced from Debian)?
[16:38] <cjwatson> nobody :-/
[16:38] <cjwatson> well, priority mismatches are handled by a script and synced up with seeds
[16:38] <cjwatson> section mismatches are regrettably unhandled right now
[16:38] <cjwatson> and pitti is correct AFAIK, changing the section in an upload achieves nothing
[16:39] <Laney> why isn't the package just used for sections?
[16:45] <cjwatson> more wrong than average, I think
[16:46]  * debfx wonders why there is a need to have a different section in the archive vs. package control file
[16:48] <cjwatson> I believe Debian ftpmasters wanted to be able to shift packages about between sections in bulk without having to wait ages for a load of uploads
[16:48] <cjwatson> it dates back well over a decade, what do you want of me ...
[16:49] <pitti> cjwatson: ah, Mon 21:00 UTC -- somehow I was afraid it would be during sleep time :)
[16:49] <pitti> but oh well, it's only biweekly, no biggie
[16:50] <slangasek> SpamapS: hadn't seen that one, but <sigh>
[16:50] <cjwatson> it's not ideal for me either, but it was the best available
[16:50] <pitti> cjwatson: thanks for doing the poll
[16:52] <SpamapS> slangasek: it looks like a grouping of dupes around the dbus problems (fixed right?) and a few upset about not being able to use /etc/network/interfaces for certain things
[16:53] <slangasek> SpamapS: which dbus problems?
[16:54] <SpamapS> slangasek: I thought there was a problem with dbus and the /run transition
[16:54] <SpamapS> slangasek: but I may be conflating things :-P
[16:54] <slangasek> sure, there are a number of things that fail miserably if /var/run isn't properly transitioned, dbus being the most obvious
[17:13] <infinity> cjwatson: Hrm.  So, debootstrap is still brain-dead in the face of multiple versions of a package, isn't it?
[17:14] <infinity> cjwatson: (the archive skew fix/workaround means multiples exist in indices, leading to, for instance, armel not being debootstrapable right now)
[17:16] <cjwatson> oh, hah
[17:16] <cjwatson> possibly.  although Debian has that same fix/workaround so I'm surprised it hasn't been noticed there ...
[17:16] <infinity> cjwatson: I'm testing on amd64 right now, cause you'd think it would have the same problem.
[17:17] <infinity> cjwatson: But basically, debootstrap is picking perl 5.14 and perl-modules 5.12 (despite both versions of perl-modules being in the index).
[17:17] <infinity> cjwatson: And yeah, amd64 just failed the same way.
[17:17] <infinity> cjwatson: Which makes sense.
[17:18] <infinity> cjwatson: (--variant=buildd required to pick up perl, I guess)
[17:18] <cjwatson> how come old perl-modules is still in the index anyway?
[17:19] <cjwatson> new perl has been built everywhere for some time
[17:19] <cjwatson> is it upset that armhf hasn't done it yet?
[17:19] <infinity> You'd think not, since there's no build record for armhf.
[17:19] <infinity> But Julian might be in a better position to answer that.
[17:20] <infinity> Either way, the cruft issue aside, this should probably work.
[17:20] <cjwatson> agreed ...
[17:20] <infinity> Or, since dependency resolution is hard at that stage, at least fail in the other direction (always pick the package with the higher sort order)
[17:21] <cjwatson> it should just pick the newest, yes
[17:21] <cjwatson> however we don't yet have dpkg --compare-versions ...
[17:21] <cjwatson> we could pick the last in Packages and trust that it's version-sorted
[17:21] <cjwatson> (which it apparently is, at least in this case)
[17:22] <infinity> It's LC_COLLATE=C sorted.
[17:22] <infinity> As in, it's the order they appear on the filesystem.
[17:22] <infinity> Which is wrong for certain version comparisons, but 99% right. :P
[17:22] <cjwatson> we could fix that in LP
[17:22] <cjwatson> or rather in apt-ftparchive
[17:22] <cjwatson> it's much better-placed to do version-sorting than debootstrap is
[17:23] <infinity> Oh, actually, yeah, I was thinking of a raw apt-ftparchive scan without a config and pre-gen indexes.  In LP, it might actually be correct.
[17:23] <dobey> cjwatson: is the precise release schedule supposed to still be a draft?
[17:23] <cjwatson> LP presumably gives it a file list
[17:23] <cjwatson> dobey: -> skaet
[17:23] <dobey> ah right
[17:23] <infinity> Yeah, LP gives file lists, so it might be doing the right order anyway.  Would have to dig.
[17:23] <dobey> skaet: is the precise release schedule supposed to still be a draft? :)
[17:23] <infinity> But "latest is highest" is normally true for Packages files, except for oddball corner cases anyway. :P
[17:24] <skaet> dobey, yes,  I still need to apply the changes discussed at UDS
[17:24]  * skaet getting blueprints wrangled first
[17:24] <cjwatson> infinity:         files.sort(key=package_name)
[17:24] <dobey> skaet: ah ok; do you know when that should be done by?
[17:24] <cjwatson> infinity: so any version sorting is either in apt-ftparchive or by luck
[17:25] <skaet> dobey:  will be done by planning freeze.   Is there a specific date or some info you need before then?
[17:25] <infinity> cjwatson: Assuming that maps back to a SQL lookup (and everything in LP does), it's going to end up with a FIFO of versions as they appeared in the tables.
[17:25] <infinity> cjwatson: But yeah, that's pure luck, not design.
[17:26] <SpamapS> slangasek: any chance you can upload mysql-5.5 5.5.17-3 to experimental today?
[17:26] <cjwatson> infinity: files is a python list
[17:26] <infinity> cjwatson: Yes, but the list came from a table.
[17:26] <infinity> cjwatson: And since it's only sorting on package name, the version order would remain intact, as retrieved from the DB.
[17:27] <infinity> cjwatson: I'd assume.
[17:27] <SpamapS> slangasek: I'd like for it to land there before I upload the merged version to precise and start the libmysqlclient transition.
[17:27] <infinity> cjwatson: (Still, pure luck)
[17:27] <cjwatson> infinity: ah, yes, since Python 2.3 list.sort() is guaranteed stable
[17:28] <infinity> cjwatson: I'm trying to decide if that was sarcasm, or quoting an API ref.  Or both. ;)
[17:28] <dobey> skaet: i need to set up milestones on all the u1 projects, for releases we're going to make for the cycle, and don't want the dates to change out from under me right after i finish doing it :)
[17:28] <cjwatson> infinity: the latter :)
[17:28] <cjwatson>         result_set.order_by(
[17:28] <cjwatson>             BinaryPackagePublishingHistory.id, BinaryPackageFile.id)
[17:29] <cjwatson> is what the file list is actually sorted on in the SQL lookup
[17:29] <cjwatson> (about five levels up)
[17:29] <cjwatson> so, uh, first published will be first in Packages?  I guess.
[17:29] <infinity> cjwatson: Yeah.
[17:29] <skaet> dobey, gotcha. :)  will ping you when I finish with the updates.
[17:29] <cjwatson> so that should in practice match version ordering
[17:29] <infinity> cjwatson: Which is more or less right.  But again, only accidentally.
[17:29] <cjwatson> well, guaranteed right because versions can't go backwards
[17:29] <cjwatson> although I'll grant you accidental
[17:29] <infinity> cjwatson: No, but IDs can.
[17:30] <cjwatson> oh
[17:30] <dobey> skaet: ok thanks. planning freeze == feature def freeze?
[17:30] <skaet> dobey, yup.  :)
[17:30] <infinity> cjwatson: Well, I don't know if they have.  But there's no reason they can't. :P
[17:30] <cjwatson> can or actually might?technically
[17:30] <cjwatson> bah
[17:30] <cjwatson> "technically can or actually might?"
[17:30] <infinity> Technically can.
[17:30] <infinity> Actually, dunno.
[17:30] <dobey> skaet: ok
[17:30] <infinity> Still, tiny corner case, not terribly concerned.
[17:31] <infinity> It's also probably possible to publish out of order.
[17:31] <infinity> But I don't really want to think about that right now.
[18:15] <slangasek> SpamapS: yeah, I can do that today - can you update the changelog in svn?
[18:16] <SpamapS> slangasek: done
[18:16] <SpamapS> wait
[18:17] <SpamapS> oops
[18:18] <SpamapS> slangasek: ok, committed now
[19:19] <mterry> doko, I'm going to merge pari if you don't shout
[20:59] <adam_g> is there some dh magic that takes care of creating link from /etc/init.d/$somejob -> /lib/init/upstart-job if it hasn't been created in postinst or rules?
[21:00] <hallyn> adam_g, I think if you just do dh_installinit --upstart-only it does it automatically yes
[21:01] <adam_g> hallyn: ahhh, will check that. thanks
[21:02] <hallyn> adam_g, and if you do 'dh_installinit --name xy -pz' I assume the same
[21:02] <hallyn> iow, I've never had to worry about it.  it's always done it for me
[21:02] <hallyn> np
[21:03] <roaksoax> adam_g: if you using dh7 and have the upstart job in debian/<package>.upstart should be done automatically
[21:04] <adam_g> im looking at a pkg that, via rules, installs both an upstart and a script to init.d.. was scratching my head how the /lib/init/upstart-job gets there
[21:04] <roaksoax> adam_g: its a symlink that gets handled by dh
[21:04] <adam_g> yup
[21:15] <slangasek> adam_g, hallyn: --upstart-only means "there was never an init script with the same name as this upstart job"; it has no effect on whether the symlink is created
[21:16] <hallyn> slangasek, thx, yeah, that's what i started to think after i spoke up
[22:25] <slangasek> SpamapS: <cough> test build done; now would you like to update the changelog to point to experimental instead of precise? ;)
[22:36] <SpamapS> slangasek: HAHAHHA ok ;)
[22:36] <slangasek> SpamapS: would be best if you also updated the uploader line to be you instead of nobse
[22:37] <SpamapS> slangasek: did that too
[22:37] <slangasek> ok cheers
[22:39] <SpamapS> slangasek: commit just finished
[22:39]  * SpamapS shakes svn... GO FASTER
[22:39]  * slangasek shakes svn... BE something else
[22:42] <SpamapS> slangasek: I will bring up migrating to bzr once the 5.5 dust has settled. :)
[22:42] <slangasek> :)
[23:13] <slangasek> SpamapS: OOI, why does libmysqlclient-dev ship /usr/lib/*/mysql/plugin/ha_*_plugin.a?  Is someone going to statically link these plugins?
[23:13] <SpamapS> slangasek: oh that may be a mistake
[23:13] <SpamapS> slangasek: I'm not entirely sure
[23:13] <slangasek> ok
[23:14] <slangasek> 5.5.17-3 uploaded now
[23:14] <SpamapS> slangasek: thanks, I'll take a look at the plugin bits
[23:16] <SpamapS> slangasek: I mean, THANKS!!! btw. ;)
[23:16] <slangasek> :)
[23:21] <SpamapS> slangasek: Hm, it seems all those plugin archive files are missing from 5.5 entirely...
[23:21] <slangasek> heh
[23:21] <SpamapS> slangasek: may have to ask to have them installed somehow.
[23:26] <slangasek> pitti: sorry for the procps breakage yesterday, btw... reuploaded now with a better fix


[00:23] <ardakc> there is a bug from ubuntu 22.10 can somebody help me?
[00:24] <guiverc> ardakc, you'll have to give details; such as the launchpad bug report ID
[00:25] <ardakc> guiverc: i think i cant do that but this bug is not giving me error
[00:26] <arraybolt3[m]> ardakc: Just describe what's gone wrong - if you know there's a bug, you can see something that's gone awry.
[00:26] <arraybolt3[m]> We can probe your system for log files later :)
[00:26] <ardakc> guiverc: this bug its i selecting yaru-red-dark theme from gnome-tweaks after opening gnome-control-center its selecting yaru-red theme for me
[00:26] <guiverc> If it's a bug, I assume it exists on a bug tracker where the ID will let us look at what's there.  If it's a problem you think is a bug, you need to describe the problem, and we can get details & help you to file a bug report if required
[00:26] <ardakc> or another white theme for legacy applications
[00:27] <guiverc> problems aren't bugs until reported on a bug tracker & thus have a BUG ID/report
[00:27] <arraybolt3[m]> So basically the dark theme isn't sticking and it just goes back to a light theme?
[00:27] <arraybolt3[m]> (Sounds like it should be easy to try and reproduce - I just downloaded a Kinetic ISO earlier today and should be able to give it a whirl.)
[00:27] <ardakc> no from gnome-control-center selected dark theme but from gnome-tweaks for legacy applications selecting white theme for me
[00:28] <ardakc> guiverc: how can i do that?
[00:28] <arraybolt3[m]> ardakc: OK, so what are the exact steps? You selected a dark theme in gnome-control-center? Or in gnome-tweaks?
[00:29] <ardakc> in gnome-control-center
[00:29] <guiverc> is a specific application that appears as 'white' when you want dark; if so what application.  By legacy I assume it means GTK3 (modern GNOME is GTK4)... but is the app Qt5? GTK2? or which app(s)? are light
[00:30]  * guiverc is not a GNOME user except occasionally, so I don't keep up with all gnome development/features
[00:31] <ardakc> Applications like nvidia-settings hexchat are also called legacy applications.
[00:32] <ardakc> there is no such option in pure gnome gnome-control-center also added by ubuntu developers i think
[00:33] <ardakc> Is it possible to edit the source code of gnome-control-center?
[00:33] <guiverc> hexchat is GTK2 & isn't legacy; it was legacy when GNOME was GTK3, it's deprecated in GTK4 so may ignore any settings made in GTK4 as it's unaware of them
[00:34] <ardakc> huiverc: but when I select dark theme from legacy applications option in gnome-tweaks, hexchat becomes dark theme?
[00:35] <guiverc> fyi:  I'm a hexchat myself; I just picked a theme I could live with .   I consider the problem to be GTK2 used by hexchat; I maybe wrong, but you'll find the issue in all GTK2 apps, not just hexchat
[00:35] <guiverc> i'm a hexchat user myself ^  (sorry for typos)
[00:35] <guiverc> I know nothing about nvidia-setting sorry so cannot commment there
[00:36] <ardakc> You are wrong because when I make this selection, it turns black, but when I open gnome-control-center, it makes the option white automatically. I guess you don't understand me because my english is bad.
[00:37] <guiverc> I could also have jumped to wrong conclusions & what I've seen (being a kinetic user, inc. hexchat as my IRC client; alas I'm not on it currently)
[00:38] <guiverc> If you provide 'exact steps' as arraybolt3[m] asked for, he maybe to have a look and give an opinion that's more helpful for your needs
[00:39] <ardakc> ok
[00:39] <ardakc> where is he?
[00:40] <guiverc> look up the thread; ~11 mins ago was last paste from arraybolt3
[00:42] <ardakc> i think his going to install ubuntu 22.10 :D
[00:59] <ardakc> i fixed my problem selecting adwaita-dark
[01:04] <guiverc> well done for solving it   .   If you believe it's a bug, please file a report.  If it's with yaru-theme-gtk (https://packages.ubuntu.com/kinetic/yaru-theme-gtk) you'd do that with `ubuntu-bug yaru-theme-gtk` on your current box & follow prompts. I see GTK2 engines in the paste I provided for that package so it has some GTK2 knowledge/capabilities; it maybe a bug
[01:04] <guiverc> ardakc, ^
[01:05]  * guiverc is sorry; my primary box failed to start yesterday so I'm not using kinetic I'm usually using; have more limited resources to look for package matches etc currently


[16:09] <akgraner> nhandler, ping
[16:10] <akgraner> nhandler, can you take a look at the Fridge and Forums stories  - I went to look for the link for the Interview dpm posted for translations so I could add it to the interview but not seeing it on the Forums Discussion...
[16:10] <akgraner> unless I am just blind today.. :-/  which is completely possible :-)
[16:13] <akgraner> I still don't see it.. hmmm
[16:29] <akgraner> nhandler, ok it showed up :-) that was weird
[18:28] <pleia2> akgraner: he's on vacation this week


[02:59] <jjesse> herm i think i scrwed up putting a ubuntu image on my nexus 7
[02:59] <jjesse> looks like i have a phone version of it some how
[03:00] <jjesse> plus it looks like there are some phone messages on it
[03:04] <jjesse> is there a good link for a fresh install of ubuntu for nexus 7?  it looks like the one i got from a ubuntu site has all kinds of personal information on it
[03:23] <jjesse> jcastro, might want to look at my G+ post i just made, seems like someone forgot to clean up some data before doing a build for Mobile World Congress
[04:02] <jjesse> rick_h_android, do you know a lola chang?  i think she works at Canonical on the phone stuff
[04:02] <jjesse> rick_h_android, see my G+ post
[04:07] <jjesse> never mind looks like it was sample data
[12:56] <snap-l> Good morning
[12:56] <brousch> So far
[12:56] <snap-l> we be jammin'
[12:58] <rick_h_> crappy morning...how do people live without middle click?
[12:59]  * rick_h_ is going to melt down and cry shortly
[13:01] <snap-l> rick_h_: Foreign machine?
[13:02] <rick_h_> snap-l: no, home docked laptop just no middle click this morning
[13:02] <rick_h_> don't know wtf I did
[13:02] <snap-l> oh that sucks
[13:04] <brousch> I don't use middle click
[13:05] <rick_h_> how do you live? I mean how do you open new tabs, paste content from terminals, open links from irc/terminals?
[13:05] <rick_h_> middle click is the glue of the desktop
[13:07] <brousch> Right-click, open in new tab; ctrl+shift+v
[13:07] <brousch> irc is just a click since I use pidgin
[13:14] <mathomastech> ctrl+t
[13:32] <snap-l> Reminder: we're jamming this weekend
[13:33] <snap-l> starting today, and going through Sunday evening
[13:59] <rick_h_> woot, jamming
[14:14] <snap-l> Blergh
[14:14] <snap-l> Apparently my keyboard has a problem with the left arrow key.
[14:14] <rick_h_> ruh roh
[14:15] <snap-l> Yeah, not looking forward to waiting for a replacement.
[14:16] <rick_h_> meh, arrow keys
[14:16] <rick_h_> who needs em
[14:16] <snap-l> I do
[14:16] <snap-l> sorry, it's the right arrow key.
[14:19] <snap-l> still a pain in the cock
[14:19] <snap-l> Well, we'll see how their RMA process is.
[14:20] <snap-l> Hoping it'll be "we ship you a new one, you ship yours back"
[14:20] <snap-l> and not "you ship yours, wait a week, and we'll ship you another one when we've determined what the problem is"
[14:22] <rick_h_> what you need to do is convince widox he wants the filco, then borrow his brown while you wait
[14:22] <snap-l> hahaha
[14:23] <widox> :o
[14:25] <widox> snap-l: I hope you aren't using the arrow keys in vim!
[14:25] <snap-l> 70 / 30 between hjkl and arrow keys
[14:25] <rick_h_> nop the arrows ftw
[14:26] <snap-l> They're there to be used. :)
[14:30] <rick_h_> just like the scroll lock and pause keys :P
[14:31] <snap-l> Just because you're not using the Pause key dowsn't mean I'm not. :)
[14:31] <snap-l> (actually, I'm not.)
[14:32] <jcastro> jjesse: link? I don't see a post about that
[14:33] <jjesse> i deleted it
[14:33] <jjesse> jcastro, the people in #ubuntu-touch delt w/ it
[14:33] <jcastro> k
[14:36] <snap-l> This Red Notebook looks interesting: http://rednotebook.sourceforge.net/downloads.html
[14:36] <snap-l> It's definitely active.
[14:56] <jcastro> rick_h_: man, colder today
[14:56] <jcastro> was hoping to finish up the slush fest in my driveway
[14:56] <rick_h_85> lol yeah hard to clean now
[14:56] <rick_h_85> I cleaned up the last slush when it was wet yesterday
[14:58] <rick_h_85> I do look forward to some windows down weather in ATL
[14:59] <snap-l> Yeah, I'm done with this snow stuff
[14:59] <snap-l> not looking forwad to the extreme heat, but would be nice to get some of the stink out of the house.
[15:07] <widox> spacex launch in a few minutes, http://www.spacex.com/webcast/
[15:08] <snap-l> unmanned rocket?
[15:08] <snap-l> Ah, it's a resupply mssion
[15:08] <widox> yeah, its a supply run
[15:08] <snap-l> that's cool
[15:09] <rick_h_> woot
[15:09] <widox> I think they scheduled to do like 12 of them
[15:09] <rick_h_> wish the boy was home, he loves counting down 'liftoff!' now
[15:10] <snap-l> OMG, there's a OFO on the pad!
[15:11] <snap-l> That's freaking amazing
[15:11] <rick_h_> man that's a lot of rockets on that thing
[15:12] <rick_h_> what's all this kilometer talk? :P
[15:13] <snap-l> <3 that this thing is sending a signal in real time back to earth
[15:13] <snap-l> Science is metric
[15:13] <snap-l> We'll have none of this king's foot nonsense.
[15:19] <rick_h_> I can't help but laugh at using the term 'down range' when the damn thing is heading to SPACE
[15:24] <snap-l> Oh boy.
[15:24] <widox> doh!
[15:25] <widox> alien interception
[15:26] <rick_h_> lol
[15:30] <snap-l> I think this forum is getting pummeled
[15:46] <jrwren_> I'm leaning toward riak - what are your thoughts?
[15:47] <rick_h_> jrwren_: because xxx and yyy?
[16:06] <snap-l> One thing about having a borked keyboard has taught me is to change over my default editing-modes to vi
[16:06] <snap-l> brb
[16:07] <snap-l> Let's see if this works.
[16:07] <snap-l> Hm, apparently weechat doesn't support vi keybindings from .inputrc
[16:12] <jrwren_> rick_h_: exactly, because XXX and YYY
[16:12] <jrwren_> :)
[16:12] <jrwren_> riak - because its built on lightning memory mapped db, and its distributed, replicated.
[16:13] <jrwren_> although my ideal is the same thing more sql like - like google's spanner.
[16:16] <jcastro> jrwren_: have you seen this yet
[16:16] <jcastro> http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
[16:16] <jcastro> gives you a nice overview of all of them
[16:22] <rick_h_>  escept riak :P
[16:22] <rick_h_> except
[16:40] <jrwren_> but I hate most of those.
[16:40] <jrwren_> cassandra is JVM, so its out
[16:40] <jrwren_> mongodb - because I want to lose all my data - the RAM limits are not what I want
[16:40] <jrwren_> couchdb - maybe I do want couch, I should look at it a lot more.
[16:40] <jrwren_> redis - same memory limits as mongo
[16:41] <greg-g> jrwren_: what kind of memory limits are you running / will run itnnto with redis mongo?
[16:41] <jrwren_> scalability, availability and fault-tolerance of riak is why I like
[16:41] <jrwren_> although I don't knwo why this guys docs say riak is moving to google's leveldb
[16:41] <jrwren_> AFAIK they are already on lightning
[16:42] <snap-l> Just use PostgreSQL. :)
[16:43] <jrwren_> no acceptable HA/fault tolerant solutions
[16:43] <snap-l> It's postgresql. It's infallible
[16:43] <snap-l> It's the pope of databases
[16:44] <jrwren_> couchbase looks good too
[16:44] <jrwren_> its postgresql, its old school, its old.
[16:44] <jrwren_> yes, I know it works, I love it.  No backups. Game over.
[16:53] <jrwren_> my understanding of ALL postgresql failover solutions is that lots of human work is required to bring up that slave
[16:54] <rick_h_> yea, pgsql failover isn't meant for cloud-levels of reliability
[16:54] <jrwren_> besides that if I am running from nukes I have other worries.
[16:54] <rick_h_> really, you put pgsql on the server that's old school rock solid failover galore
[16:54] <jrwren_> its just not true - I can put riak in each ec2 zone, my DC here, and azure, all same cluster
[16:55] <rick_h_> jrwren_: I know internally we've used cassandra and happy with it. I just don't know the use cases enough to compare vs riak.  It's an antique
[19:56] <snap-l> I'll have you know it's my main desktop at home. :)
[19:57] <snap-l> Never mind I can't remember when I built it. :)
[19:57] <brousch> I get slowness when a mounted (network) drive is not available
[19:57] <snap-l> Seems whenever I do heavy disk activity the whole thing just grinds down in a spiral of slow until things settle down
[19:58] <brousch> Could be a sign of a dying disk
[20:00] <snap-l> Yeah, i ran the smart surface test, but I might just toss SPINRITE in it just to be doubly sure
[20:01] <brousch> Or a nearly-full disk
[20:45] <snap-l> I think Elite Keryboards doesn't answer email on Fridays
[22:35] <jrwren_> snap-l: you haven't learned to deal with spaces in filenames yet?
[22:36] <jrwren_> given how long you've been using linux and unix, that is a bit sad really.
[22:36] <snap-l> jrwren_: I forget everytime I have to do a for loop
[22:36] <rick_h_> they're evil, that is all
[22:36] <snap-l> because it's not how you'd think it would handle it
[22:37] <snap-l> jrwren_: I know how to escape a space, thank you. :)
[22:37] <snap-l> I know how to get find to do -print0 | xargs -0
[22:38] <jrwren_> gnu find and exec + does it for you
[22:38] <snap-l> but the genius part was it was a bunch of zip files with the same filenames inside that i had to preserve the directory structure
[22:38] <jrwren_> xargs is obsolete with gnu find AFAIK
[22:38] <jrwren_> ugh, i hate zip files and directory structures :)
[22:39] <snap-l> so I was looking for  a way to create the directory name using basename and mkdir
[22:39] <snap-l> but it was easier to use sftp to my local machine and just right click on them
[22:39] <snap-l> created the directories just the way I like it
[22:39] <snap-l> does it mean I lose some UNIX cred?
[22:39] <snap-l> fuck off.
[22:39] <snap-l> ;)
[22:40] <jrwren_> nah, it doesn't.
[22:40] <jrwren_> i experienced similar issue with scp just doay.
[22:40] <jrwren_> just today
[22:40] <jrwren_> but I know the rules, so I both quoted and escaped and things worked
[22:41] <snap-l> Yeah, most of the time this stuff works
[22:41] <snap-l> but when I have to do things in bulk with spaces, that's when things get weird
[22:41] <snap-l> and it seems this company has spaces in spades
[23:24] <greg-g> rick_h_: eneloop has colors?!?!?! http://arstechnica.com/science/2013/03/sodium-air-battery-shows-potential/
[23:28] <rick_h_> greg-g: heh, when was the last time colors did anything on a battery. You just put the cover over it :P
[23:31] <greg-g> but! Pretty!
[23:40] <rick_h_> it's like having a pretty colored inner tube
[23:40] <rick_h_> ooh pretty, now put the tire on over it
[23:40] <rick_h_> http://www.airforums.com/ ... this can only end badly


[12:17] <rcombs> I've been getting this error on startup when I have libegl installed: Oct 28 08:41:58 rcombs-NUC org.gnome.Shell.desktop[875]: Window manager warning: Failed to create renderer: Failed to initialize renderer: Missing extension for GBM renderer: EGL_KHR_platform_gbm, Missing EGL extensions required for EGLDevice renderer: EGL_EXT_device_base
[12:17] <rcombs> this seems to be from mumble
[12:18] <rcombs> and appears to result in gnome-shell exiting and gdm falling back to x11 and disabling wayland sessions
[12:18] <rcombs> (guess it happens when trying to start the greeter)
[12:18] <rcombs> this is on an Intel NUC using its integrated graphics (i915 Kaby Lake)
[12:19] <rcombs> works fine (starts normally, presents Wayland sessions) with libegl and libglvnd0 removed
[12:20] <rcombs> so I'm guessing mumble's doing a runtime check for one of those libs, then trying to do something that doesn't work on this GPU if they're present, and then failing hard when it doesn't work, rather than falling back to what it would do with the lib absent
[23:33] <jbicha> robert_ancell: good afternoon
[23:33] <robert_ancell> jbicha: hi
[23:33] <jbicha> robert_ancell: I'm wondering if you were planning on a gnome-software/artful SRU soon, I'd like to see LP: #1722809 fixed there
[23:35] <robert_ancell> jbicha: I'm finalising the SRU, happy to have that there.
[23:36] <robert_ancell> jbicha: you can push to lp:~ubuntu-desktop/gnome-software/ubuntu-artful directly if you want
[23:36] <jbicha> 👍
[23:37] <robert_ancell> jbicha: I'm also pushing into ppa:ubuntu-desktop/gnome-software when I make changes on those branches, so you're welcome to do that too
[23:42] <jbicha> robert_ancell: I pushed to the ubuntu-artful bzr branch, I'll let you take care of uploading to ppa and/or SRU
[23:45] <robert_ancell> jbicha: ok, will do. Thanks!


[05:17] <mitya57> Trevinho: thank you!
[05:21] <mitya57> I am going to make a new official compiz release today or tomorrow, hope you don't mind. It would be useful for other distributions like Arch.
[07:29] <didrocks> good morning
[07:42] <oSoMoN> good morning desktoppers
[07:44] <didrocks> salut oSoMoN
[08:00] <oSoMoN> salut didrocks
[08:41] <ricotz> good morning :)
[08:41] <ricotz> oSoMoN, see pm
[08:50] <didrocks> hey ricotz
[09:01] <Laney> b0b0b0
[09:02] <didrocks> hey Laney
[09:09]  * Laney pats didrocks
[09:10] <Wimpress> Morning desktoppers o/
[09:14] <didrocks> hey Wimpress
[09:14]  * Laney nods gravely towards Wimpress
[09:14] <Wimpress> :-)
[09:14] <Laney> ("take him away")
[10:11] <seb128> good morning desktopers
[10:16] <didrocks> salut seb128
[10:16] <seb128> lut didrocks, en forme ?
[10:17] <talx> morning folks
[10:17] <talx> I'm looking for assitance with preseed installation
[10:17] <didrocks> seb128: ça va, et toi ?
[10:18] <talx> trying to figure out what I'm doing wrong for the third way in a raw
[10:18] <seb128> ça va :)
[12:57] <jbicha> seb128: do you want to try demoting notification-daemon again? I've added some alternate dependencies so maybe it will stick this time
[13:19] <jbicha> also, we already got the first review of the libhandy MIR LP: #1815483 (I wasn't expecting that so soon, thanks!). There's a question there about whether we want Glade in main
[13:36] <seb128> jbicha, can do for n-d
[13:39] <seb128> jbicha, @libhandy, we don't want glade in main no, the -dev can stay in universe, also I'm not sure we want that lib at all in main until it's somewhat stable
[13:40] <jbicha> they claim to be releasing a "stable" 0.1.0 next month: https://source.puri.sm/Librem5/libhandy/wikis/home
[13:40] <seb128> I'm still not sure why that lib exists/is needed, outside of being a playground with the goal to merge those widgets in gtk
[13:40] <jbicha> because it might not be practical to merge those improvement in until gtk4
[13:40] <seb128> other experimentals widget libs like egg are usually included as copies
[13:40] <seb128> and?
[13:41] <seb128> egg has been around for years
[13:41] <seb128> still it doesn't need to be an external lib
[13:41] <seb128> what's GNOME r-t position on libhandy?
[13:41] <seb128> do they plan to add it to the core set?
[13:43] <jbicha> it's already there (gnome-contacts is part of GNOME Core and uses libhandy without embedding it) https://gitlab.gnome.org/GNOME/gnome-build-meta/tree/master/elements/core-deps
[13:44] <jbicha> 🤷 some Fedora guys were saying the same thing that they want it to be an embedded library, but that's not really how it's being used right now
[13:44] <seb128> mclasen's comment on #gnome-hackers the other days suggested that he didn't think it should be a core lib for GNOME
[13:45] <seb128> I'm not sure how they decide to accept or not new depends as part of their platform though
[13:46] <seb128> anyway -1 from me to use as a lib until it's somewhat stable, sharing a moving target playground is just asking for problems imho
[15:23] <seb128> if some wonder why retracing are failing recently in disco, bug #1815774
[15:23] <seb128> (I was wondering why the recent report from the g-c-c segfaults failed to retraced and ended up chasing it down to binutils)
[15:23] <seb128> we are going to need to rebuild $things once binutils is fixed
[15:25] <Laney> good find
[15:25] <seb128> thx
[15:25] <seb128> doookooooo
[15:25] <Laney> binutils is crazy stuff
[15:26] <seb128> we should have some autopkgtest testing that dbg still work when a binutils lands
[15:26]  * seb128 adds to his would-be-nice-to-add part of his todolist
[15:28] <Laney> using libunwind or something?
[15:32] <seb128> good question, I didn't give it much thinking yet, I was thinking maybe building a small package with a buggy .c example, install it/the dbgsym, start the buggy example under gdb and get a bt/check that it's in a debug format
[15:33] <seb128> but looks like libunwind would be good in that scenario, thx for the hint!
[15:43] <Laney> :>
[15:45] <seb128> does anyone know an example of a package that rebuild itself in an autopkgtest?
[15:46] <seb128> d_idrocks suggests doing that for rygel as part of the MIR to ensure that vala updates don't break it
[15:48] <Laney> that's a weird requirement, autopkgtests usually test runtime breakage really and archive rebuilds are used to detect ftbfs
[15:48] <Laney> you can do it with Restrictions: build-needed and a no-op test but like I say I wouldn't advise that
[15:48] <seb128> well, I can see the value of blocking vala updates is they break things
[15:49] <Laney> why doesn't it apply to any library?
[15:49] <seb128> but maybe that should be done fromt he vala side
[15:49] <Laney> autopktest isn't meant to be a general keep-the-archive-buildable service
[15:49] <seb128> you have a point there
[15:50] <seb128> we also don't fully archive rebuild to validate gcc updates :p
[15:50] <Laney> right, and these almost always do introduce a few failures
[15:50] <seb128> that was an optional suggestion on the MIR, I'm going to skip that for now
[15:51] <Laney> now a test in vala itself which builds a few programs (Restrictions: superficial probably) would be a nice thing
[15:51] <Laney> same for all libraries/compliers
[15:52] <seb128> right
[15:52] <seb128> Laney, thx for the input
[15:52] <Laney> you're welcome
[17:16] <andyrock> jbicha: https://code.launchpad.net/~azzar1/ubuntu/+source/gnome-online-accounts/+git/gnome-online-accounts/+merge/363144
[18:42] <mdeslaur> seb128: do you have a curl merge planned?
[18:42] <seb128> mdeslaur, no, but I can look at it tomorrow
[18:42] <mdeslaur> seb128: awesome, thanks
[18:42] <seb128> yw!


[08:45] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » linode-01 build #2535: SUCCESS in 58 sec: https://kci.pangea.pub/job/mgmt_docker/label=linode-01/2535/
[08:46] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » master build #2535: SUCCESS in 1 min 19 sec: https://kci.pangea.pub/job/mgmt_docker/label=master/2535/
[08:49] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-01 build #2535: SUCCESS in 4 min 22 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-01/2535/
[09:40] <pereira_alex> acheronuk: may i ask, I am using cosmic with kubuntu-ci stable kde , and all is working very nicelly and pretty. seeing on reddit, lots of people miss the new and shiny kde like neon. Why not advertise kubuntu-ci stable more, which the advertising of "test and submit bugs" ? my testing, since bionic and now cosmic ( so +- 6 months ), it has been working perfectly more than not
[09:40] <acheronuk> pereira_alex: it's a development tool for build testing
[09:41] <acheronuk> not one that I would ever suggest installing from as a user. IF it works ok, that is a great side effect, but not the purpose
[09:43] <pereira_alex> acheronuk: hum... it would be awesome, and i think with lots of interest, to turn it into some bleeding edge kde delivery similar to neon
[09:43] <pereira_alex> acheronuk: would it be too much work for that ? or is there any interest in that from the kubuntu standpoint ?
[09:45] <acheronuk> probably more work that I can give it regularly. just doing a new Qt build for it is quite hit and miss
[09:47] <pereira_alex> i understand... I do see alot of ppl asking for something like new and shiny on kubuntu, and just go to neon
[09:47] <pereira_alex> issue with neon is it being based on LTS ... kubuntu being 6 months would fit nicelly
[09:50] <acheronuk> at the moment nightly builds are turned off, as one of the recent processor flaws (L1TF) means multithreading got disabled on most of the x86 builders
[09:51] <acheronuk> pereira_alex: I'll give it some thought anyway. it would only ever remain a development thing in my eyes. i.e. this is not supported in ANY way
[10:09] <pereira_alex> acheronuk: sure, it would be meant for "advanced users" and bug testers ... not normal ubuntu release quality
[10:10] <pereira_alex> btw , how does neon does it ? could something between kubuntu and neon be shared work ?
[10:22] <acheronuk> Neon does it by having 2+ full time paid developers
[10:24] <pereira_alex> ohhhhhhhhhhhhhhhhhhhhhh ! didn't knew
[10:24] <pereira_alex> that is great for them !
[10:32] <pereira_alex> acheronuk: well , if you are only doing kubuntu-ci for the sake of packaging .... them you are doing a freaking good job at making the desktop really tight !
[10:33] <pereira_alex> i am yet to catch a problem ... and i am using everything i usually do, which is a very customized kde desktop and apps
[10:34] <acheronuk> I do have a VM I update every so often to make sure things work sanely, more or less.
[10:36] <acheronuk> there is also **some** crossover with Neon. our packaging shares a common history, so often if I fix something in Kubuntu CI I can pop over and fix it in Neon packaging as well
[10:36] <acheronuk> and the other way, sometime things are already fixed in Neon, so I can take changes from there
[10:42] <BluesKaj> Hi folks
[11:09] <pereira_alex> heh acheronuk true, just checked on plasma-desktop git commits on neon, youre there :)
[12:13] <acheronuk> frameworks 5.51 now added to backports-landing with plasma 5.14.0 for cosmic
[12:13] <acheronuk> please test
[12:13] <acheronuk> 5.14.1 is tomorrow
[12:14] <acheronuk> ummmmmm. also please test RC ISO ;) lol
[12:16] <BluesKaj> acheronuk, I'm testing 5.14.0 for cosmic as we speak, so far some little crashes with sysinfo which I installed for aliasing on konversation, but it seems stable now after some updates
[12:16] <BluesKaj> otherwisw everything seems fine
[12:16] <acheronuk> kool
[12:20] <BluesKaj> I still have the staging ppa installed, but wondering whether I should keep it ?
[12:22] <acheronuk> up to you. I will be building 5.14.1 in plasma-staging tomorrow, so beware of that
[12:24] <BluesKaj> maybe I'lll chance it  :-)
[14:46] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » linode-01 build #2536: SUCCESS in 1 min 2 sec: https://kci.pangea.pub/job/mgmt_docker/label=linode-01/2536/
[14:46] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » master build #2536: SUCCESS in 1 min 22 sec: https://kci.pangea.pub/job/mgmt_docker/label=master/2536/
[14:49] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-01 build #2536: SUCCESS in 4 min 24 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-01/2536/
 5.51.0 landed safely- no dead kittens.
[21:53] <mparillo> backports-staging?
 yes
[21:54] <mparillo> TY
 Clarification: backports-landing (not staging....)