[17:57] <Tubu> Une partie de messagerie musicale a été demandée. Veuillez cliquer sur l'icône MM pour l'accepter.
[17:58] <maco> je ne vous comprends pas
[17:58] <maco> parle vous anglais?
[17:59] <maco> well i might kind of understand but it doesnt make sense... one part of the music message is demanded. please click the icon to accept?
[17:59] <maco> i dont get it
[18:00] <Deindre> maco: it seems to be spam message
[18:00] <pleia2> I think she just mis-typed :)
[18:00] <pleia2> #startmeeting
[18:00] <meetingology> Meeting started Tue Sep 11 18:00:44 2012 UTC.  The chair is pleia2. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[18:00] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[18:00] <pleia2> hi everyone!
[18:00] <Cheri703> hello
[18:01] <Deindre> hi all!
[18:01] <akk> hi!
[18:01] <Dolasilla> hello! :)
[18:01] <pleia2> #link http://wiki.ubuntu-women.org/Meetings/Agenda
[18:01] <Tubu> hello
[18:01] <pleia2> so all we really have is review of our blueprint
[18:02] <pleia2> #topic Congratulations new leaders!
[18:02]  * Cheri703 can go add it, but I do want to discuss CareerDays too
[18:02] <Cheri703> yay new leaders!
[18:02] <pleia2> #link https://lists.ubuntu.com/archives/ubuntu-women/2012-September/003615.html
[18:02] <Dolasilla> thaaanks :)
[18:02] <akk> Yay, congrats!
[18:02] <pleia2> welcome to the team Dolasilla and Deindre :)
[18:03] <Deindre> thanks a lot :)
[18:04] <pleia2> #topic Career Days
[18:05] <pleia2> Cheri703: all yours!
[18:05] <Cheri703> ah, ok!
[18:05] <Cheri703> Dolasilla has volunteered to do a session at some point in the near future, but we definitely want to get more volunteers!
[18:05] <Dolasilla> :)
[18:06] <Dolasilla> as I said, unfortunately I'm a bit busy these days but I will prepare a presentation for October
[18:06] <Cheri703> We are absolutely open to non-Ubuntu women doing the presentations, if people work in/around FOSS in some degree, they are welcome to present
[18:08] <Cheri703> so please harrass your friends to present for us. :)
[18:08] <pleia2> :)
[18:08] <Dolasilla> ;)
[18:08] <Deindre> I'll be pleased to tell how a journalist could support FOSS, if you like :)
[18:09] <Cheri703> absolutely, send me an email if you'd like, me @ubuntu.com
[18:09] <Deindre> well :)
[18:09] <akk> Journalism and FOSS sounds like a great topic.
[18:09] <pleia2> yeah!
[18:09] <Deindre> akk thank you
[18:10] <pleia2> thanks Cheri703 :)
[18:11] <Cheri703> yep, that's all I've got on the topic :)
[18:11] <Cheri703> and thanks Deindre
[18:11] <Deindre> :)
[18:11] <pleia2> #topic Quantal blueprint
[18:11] <pleia2> #link https://blueprints.launchpad.net/ubuntu-women.org/+spec/community-q-ubuntu-women-project-goals
[18:11] <pleia2> so I just updated it, thanks again to jledbetter and IdleOne for handling the election :)
[18:12] <pleia2> I don't really have updates on my items, they may end up postponed unfortunately
[18:13] <Cheri703> well gosh pleia2, with all of your spare time! you should have had them done months ago! (KIDDING KIDDING)
[18:13] <pleia2> haha
[18:13] <Cheri703> are there any that can be re-assigned?
[18:13] <pleia2> if anyone wants to take them, they are welcome
[18:14] <pleia2> one is working with paulproteus on openhatch awareness risign
[18:14] <pleia2> rising
[18:14] <Cheri703> Pendulum and I were going to share the FCM article task, but I haven't talked to her about it for a while, so...I'll do that :)
[18:14] <pleia2> great!
[18:15] <pleia2> let me know if you have any trouble logging on to the blog or anything
[18:15] <Cheri703> k. If anyone else wants to hop in on the others, definitely let us know
[18:15]  * pleia2 nods
[18:15] <pleia2> #topic Any other business
[18:16] <Deindre> I can report italian test team
[18:16] <pleia2> anything else anyone wants to talk about? :)
[18:16] <Cheri703> Do we have a headcount for UDS? I will be attending remotely
[18:17] <pleia2> I know czajkowski will be there, not sure about akgraner
[18:18] <Cheri703> Deindre: how are things with the italian testing team?
[18:19] <pleia2> (pretty sure akgraner is(
[18:20] <Deindre> Cheri703: I'm not following strictly their works, but I can ask :)
[18:20] <Cheri703> sounds good. :)
[18:21] <nigelb> Cheri703: if I can help re:FCM article, happy to.
[18:21] <pleia2> nigelb: thanks!
[18:21] <Cheri703> awesome!
[18:21] <nigelb> I'll probably need to schedule a slot into my calender so I actually do that :)
[18:22] <Deindre> unfortunately I will not attend UDS, but I can write a report, if it's usefull
[18:22] <pleia2> looks like our next meeting will be October 9th, we might want to create an -r blueprint prior to that so we can discuss it during that meeting
[18:22] <pleia2> or at least create a wiki page with ideas
[18:22] <pleia2> #action pleia2 to create an -R cycle wiki page to start collecting ideas for next cycle
[18:22] <meetingology> ACTION: pleia2 to create an -R cycle wiki page to start collecting ideas for next cycle
[18:22] <pleia2> I'll be around for that meeting, but will be out of the country pretty much until November after that (yay!)
[18:23] <Dolasilla> pleia2, good luck and congrats! :)
[18:23] <pleia2> thank you! (I'm going to Ghana for a couple weeks to deploy Edubuntu systems :))
[18:23] <akk> Wow, pleia2, too cool.
[18:24] <Deindre> pleia2: ghana??? wow
[18:25] <pleia2> yeah, I'm pretty excited
[18:25] <pleia2> ok, anything else before we wrap up? :)
[18:26] <Cheri703> I don't have anything
[18:27] <pleia2> great, thanks for joining us everyone!
[18:27] <pleia2> #endmeeting
[18:27] <meetingology> Meeting ended Tue Sep 11 18:27:40 2012 UTC.
[18:27] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-women-project/2012/ubuntu-women-project.2012-09-11-18.00.moin.txt
[18:27] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-women-project/2012/ubuntu-women-project.2012-09-11-18.00.html
[18:27] <Dolasilla> bye all! :)
[18:28] <Deindre> good bye!
[18:28] <Tubu> bye


[17:27] <OvenWerks> krytarik: done. I shold have added to the comment that this fixes lp: #1672412
[17:27] <OvenWerks> Or allows anyway.
[17:28] <OvenWerks> also lp: #1182604
[17:29] <OvenWerks> well not really, it fixes it for us though :)
[17:31] <OvenWerks> krytarik: the whole windows vst (as compared to lxvst) thing is a mess. There are at least 4 kinds of windows vsts floating around that are not mutually compatible
[17:32] <OvenWerks> So far as I know, lmms supports only 32 bit vst2s. The GPLed vst3 headers have just within the past month been released although vst3s have been around for a while.
[17:34] <OvenWerks> there are also 64bit win vsts which will not work already with lmms... I am not sure of the state of wine with 64bit binaries either. I do know some work has been done though.
[17:36] <OvenWerks> krytarik: so the end of this is that lmms at best only supports 1 kind of winvst out of 4. I don't expect lmms to include vst3 or 64bit code real soon now as the lead dev has left and there is some dissarry in the project. I do not think it will die, it seems those left are still well involved, but it may take some time to move forward again.
[17:37] <OvenWerks> there is also the deal of lmms including support for LV2 which I would think is more important right now.
[18:28] <OvenWerks> krytarik: something to look for next cycle is that in debian jack-tools has been renamed to jack-plumbing. Not in ubuntu ... yet, but we would want this package whatever the name.
[19:37] <krytarik> OvenWerks: 1.) Thanks for the commit, let's see if it works.  2.) Thanks for the verbose extra info. :)  3.) I only see an executable called jack-plumbing, in the jack-tools package; and that's at the same version in Debian and Ubuntu.
[19:46] <krytarik> OvenWerks: "I think the meta packages have to be regenerated to go with it" - luckily not in this case.
[19:56] <OvenWerks> cool. I have sent some emails as well, so that others can know why
[20:45] <krytarik> OvenWerks: Well, that didn't work.
[20:46] <OvenWerks> What did it do? I haven't seen failed emails yet.
[20:47] <krytarik> I mean it still pulls the Wine stuff.
[20:47] <OvenWerks> That is normally the effect of not rebuilding the metas
[20:48] <OvenWerks> did it pull in lmms-vst-server?
[20:49] <krytarik> Yes.
[20:49] <OvenWerks> So our understanding of how to do things is flawed.
[20:50] <krytarik> No, just blacklisting more often doesn't work than it does.
[20:53] <krytarik> OvenWerks: So I suggest for now you just ACK the Wine FFe, and then we'll have to see later.
[20:53] <OvenWerks> Hmm, I may have to try a 32 bit install
[20:53] <OvenWerks> Then I can lookup reverse deps
[21:06] <OvenWerks> I did I think
[21:06]  * OvenWerks hopes his comment was clear
[21:07] <OvenWerks> krytarik: maybe if we blacklist wine as well?
[21:07] <OvenWerks> (we may have to blacklist specific wine as well)
[21:09] <OvenWerks> krytarik: after looking at my last few lines of comment :P  I did leave a comment on https://bugs.launchpad.net/ubuntu/+source/wine-development/+bug/1672412
[21:16] <krytarik> OvenWerks: Yes, figured I'll just reload the bug report page and see if you added one there. :P  Also, one thing we could still try is to blacklist it the way Kubuntu did it just recently: http://bazaar.launchpad.net/~kubuntu-dev/ubuntu-seeds/kubuntu.zesty/revision/1358 - and in that context, we might blacklist that one right away too, even though the package doesn't exist in the repos ...
[21:16] <krytarik> ... yet.
[21:16] <krytarik> lol
[21:18] <OvenWerks> krytarik: I can do that, but I am pretty sure it would require a meta rebuild to work.
[21:19] <krytarik> Nope, that one neither.
[21:22] <OvenWerks> I am guessing it needs to come before lmms itself
[21:23] <OvenWerks> So the two lines are:
[21:23] <OvenWerks>  * !lmms-vst-server
[21:23] <OvenWerks>  * (lmms)
[21:24] <krytarik> Yup, that's sensible.
[21:25] <OvenWerks> commited please check
[21:27] <OvenWerks> http://bazaar.launchpad.net/~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.zesty/revision/1506
[21:29] <OvenWerks> krytarik: if that doesn't work we will put it just after. I am not sure of the logic, but programacically it would be easier to remove a program from the list after it has been added rather than saving the name to check each new adition against...
[21:33] <OvenWerks> krytarik: the network-manager-config-connectivity package is troublesome also because low latency audio operation is sensitive to network activity.
[21:35] <krytarik> Well, following the 'above' logic, you should have done the same for the NM one too - but as I was about to say, I'd have to look at the code of germinate again to confirm either way.
[21:36] <krytarik> Ah, good to know.
[23:23] <krytarik> OvenWerks: So looks like it doesn't really matter in what order they are - https://git.launchpad.net/germinate/tree/germinate/germinator.py   Also, I'd suggest we do a respin now, since it's RC day.


[07:37] <elfy> #team - do we have any update on the session bugs in the live sessions ?
[10:00] <ochosi> brainwash: in case Noskcaj is around again and i'm not until then, the gtk3 indicator patch should be applied as a patch for now (although obviously the goal is a new panel release, but that might take too long, we need testing now rather than after the release)
[10:20] <slickymaster> morning all
[10:20] <slickymaster> jjfrv8: ping
[12:05] <amerigena> Checked the website - is anyone else having problems with mousepad?
[12:50] <slickymaster> bbl
[13:32] <elfy> ochosi: not sure I understand what you've said to brainwash - surely what we need is it released properly so that it can be tested, not rely on people fiddling with ppa's and patches
[15:46] <doko> any xfce upstream devs here?
[15:47] <doko> who do I need to bribe that upstream releases something which can be rebuilt using dh-autoreconf?
[15:47] <doko> currently, I need changes like this: http://launchpadlibrarian.net/160507329/xfconf_4.10.0-2_4.10.0-2ubuntu1.diff.gz
[15:52] <andrzejr> doko, that's a patch against configure script, can you post a patch against configure.ac/Makefile.am?
[15:53] <doko> andrzejr, no, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726404
[15:54] <andrzejr> and do you have problem only with xfconf?
[15:54] <doko> andrzejr, which autoconf and automake versions does xfce require to build the autofiles?
[15:54] <doko> andrzejr, no, with every package
[15:55] <doko> so I would prefer if you would use dh-autoreconf for the packaging
[15:55] <andrzejr> if so, go to #xfce-dev and ping NSchermer, or better drop him an email.
[15:55] <doko> provided that you can make it work
[16:07] <andrzejr> doko, this *may* be an issue with xfce4-dev-tools but I am not the person to help you with that
[16:10] <doko> ok
[16:36] <pmjdebruijn> hi guys
[16:36] <pmjdebruijn> https://bugzilla.xfce.org/show_bug.cgi?id=10566 that might be of interest
[17:05] <andrzejr> doko, what version of xfce4-dev-tools are you using?
[17:14] <andrzejr> doko, if you are using a released version (with configure script etc.) it means someone has already used xfce4-dev-tools+autotools. So the version of the latter does not matter.
[17:15] <andrzejr> I guess that part of the problem is that most of the releases were made quite some time ago, so whoever run "make distcheck" was likely using an old version of autotools.
[17:17] <andrzejr> It would be interesting if you could re-run autogen.sh and check if the output matches your expectations.
[17:22] <doko> andrzejr, do you do the ubuntu packaging?
[17:22] <doko> because dh-autoreconf is supposed to do that. but doesn't. could you give me a recipy what to do for every package?
[17:23] <andrzejr> no, don't know how dh-* stuff works
[17:24] <andrzejr> you said you are modifying ./configure script - this script is generated using autotools and xfce-dev-tools. So if it is wrong then something happened when a developer run "make distcheck" when releasing a package.
[17:25] <doko> andrzejr, sure, but it very depends on the versions of the autotools, not all of them available in ubuntu
[17:27] <andrzejr> autotools (from the distribution) are only used before making configure script. Once it is ready, the package includes its own copy of all scripts it needs. (which may be out of date if it was released long time ago)
[17:29] <doko> andrzejr, yes, that's the problem. what's the solution? ;p
[17:31] <andrzejr> I wonder if just recreating configure script would help. If so, the only thing needed would be another *.1 release.
[17:31] <andrzejr> Can you try running autogen.sh on your side and see if that helps?
[17:32] <andrzejr> or git clone the package and run "make distcheck" -> this should produce a ready to use tarball for you.
[17:35] <doko> hmm, I think I'll wait for one of the xfce packagers. it's not that urgent. let's pick it up later
[18:05] <xnox> andrzejr: the problem is with packaging, not the upstream. A new point upstream release will not help, as we need to update libtool with unreleased libtool-patch (as in not released libtool patch). Unless upstream uses libtool from trusty to generate the tarballs.
[19:00] <andrzejr> xnox, I see, thank you. Is libtool going to be released anytime soon? We could update dependencies to require it.
[22:54] <Noskcaj> lderan, Any chance you could help me with the gthumb testcase?
[22:54] <lderan> sure thing
[22:59] <Noskcaj> How can i find if an app is open, via app_proxy? There aren't any tests i can base this on
[23:05] <lderan> theres something for getting an app that isn't created by autopilot mmm
[23:12] <Noskcaj> http://paste.ubuntu.com/6626082/ is what i have so far (the fullscreen bit is broken, but that's for later)
[23:12] <Noskcaj> I'm slowly trying to fill in http://packages.qa.ubuntu.com/qatracker/testcases/1588/info
[23:15] <lderan> shall see what i can do :)
[23:16] <Noskcaj> thanks
[23:19] <Noskcaj> Also, how do i find the properties of a window, so i can actually test things?
[23:29] <lderan> mmm
[23:31] <lderan> i shall have to ask the autopilot guy some questions on that front, from the last we talked it he confirmed that we will be able to test it if opens
[23:37] <Noskcaj> lderan, i was talking to dan and elfy, We'll probably make a xubuntu autopilot branch eventually, but catfish, gthumb, and simple scan are what we should start on, since they introspect
[23:37] <lderan> aye
[23:58] <Noskcaj> lderan, Next time you make an autopilot test, could you use docstrings instead of comments to describe each function?
[23:59] <lderan> of course


[11:25] <pchoo> Hi, Anyone able to help me diagnose an issue I'm having?  I'm on 16.04.1, and recently did a dist-upgrade (a few weeks ago).  Since then when I log out or try to shut down, I end up with a blank screen which has an underscore in the top left, and I am unable to change TTY or interact in any way, the only thing I can do is hold the power button and reboot.
[11:25] <pchoo> I have since done another dist-upgrade to see if that resolves the issue, but I am not too familiar with trouble shooting linux
[11:34] <mgedmin> how long have you waited?
[11:38] <pchoo> I've left it for about 20 minutes before
[11:38] <pchoo> lately I've had less patience as I usually shut down before I have to leave work
[11:39] <pchoo> it only started after I ran dist-upgrade a short while ago.  I intend to do a fresh install with 16.10 at some point, but was going to wait until closer to christmas where we have some down time
[11:40] <pchoo> the only issues I can see on google are to do with booting up, and not with shutting down or logging out.
[11:41] <pchoo> mgedmin: If you've got any advice on what I can look at, or how I can help diagnose what is going on, or any requests for information, please let me know
[11:41] <mgedmin> ok, 20 minutes is overkill
[11:42] <mgedmin> altough... in 16.04 I had poweroffs/reboots taking 15-20 minutes with a black screen
[11:42] <mgedmin> turned out it was swapoff taking this much time
[11:42] <mgedmin> if I opened a terminal and did a 'sudo swapoff -a' before initiating the reboot, then I had to wait maybe 15 minutes for swapoff to do its job, and then the reboot was fast
[11:43] <pchoo> How can I check to see if that's what is causing the issue for me?
[11:43] <pchoo> just try running that in a terminal and see if I can do reboot after?
[11:43] <pchoo> I am using a laptop with optimus, however I am using the intel drivers only right now (I believe)
[11:43] <mgedmin> the way I diagnosed the issue was adding a bunch of debug prints to my init.d scripts (it was before 16.04 and systemd)
[11:44] <mgedmin> with 16.04 there's now /usr/share/doc/systemd/README.Debian.gz that tells you how to diagnose shutdown issues
[11:44] <mgedmin> but I suggest trying a manual sudo swapoff -a before you reboot, to see if it's maybe the same issue
[11:44] <mgedmin> alternatively, before you reboot, check how much swap is in use
[11:45] <pchoo> Ok, thank you, I'll have a quick look at the document, then give that a try
[11:45] <pchoo> ok
[11:45] <mgedmin> if nearly 0, no need to try this, it's a different issue
[11:45] <mgedmin> I used to have ~4 gigs of swap in use
[11:45] <pchoo> KiB Swap: 16658428 total, 16658428 free,        0 used. 13500772 avail Mem
[11:45] <pchoo> That's the line from top
[11:46] <mgedmin> there goes my guess
[11:48] <pchoo> mgedmin: thanks for trying.  I'll have a look at the debug shell
[11:53] <pchoo> mgedmin: well, that didn't work, or rather, I could enter the shell before I tried shutting down, but not after I got the screen with the underscore, and there was no keyboard response from the usb keyboard, nor the laptop keyboard
[11:54] <mgedmin> :(
[11:57] <pchoo> Any other suggestions? Thank you for your help so far
[20:06] <shubham> guys, i seek your help.
[20:06] <shubham> I can't understand the reason why my ubuntu boots sometimes into initramfs prompt.
[20:06] <shubham> then i have to use a manual fsck to /dev/sdaX and it consumes a lot of time
[20:09] <shubham> ?
[20:13] <shubham> @elky there?
[20:13] <meetingology> shubham: Error: "elky" is not a valid command.
[20:13] <shubham> elky: there?
[20:24] <elky> You'll get a better response from #ubuntu where there are more people. Some of them may even be out of bed.
[20:29] <shubham> i am from east so, its already 2:00 in the morning.
[21:09] <shubham> Mia: can you help?
[23:56] <CountryfiedLinux> howdy
[23:57] <CountryfiedLinux> What version of Gnome does 16.04 have?


[00:34] <RoguePointer> bad ^
[00:34] <RoguePointer> and then, if i switch back to terminal mode and scroll around, then switch back to normal mode again, it will duplicate this top part yet again: https://ptpb.pw/qk56
[00:35] <RoguePointer> TommyC: `pkg_info -Q ms | grep fonts` gives nothing ... :-)
[01:20] <StrangerVPNV> Sterile: how so
[01:20] <StrangerVPNV> KaffeeKatrin: Vagrant definitely works well too, for local VMs. What zer0_her0 is targetting is a dev server it seems, not a local dev environment.
[01:20] <StrangerVPNV> from that grep.
[01:32] <gildeanZU> time to get the boat out
[01:32] <gildeanZU> Ellenor / FlashCode: ok, so it wasn't csc_notices.py causing that issue... it's happened more overnight with that script unloaded :<
[02:34] <meglawdD> i randomly choose one
[02:34] <meglawdD> you gotta dab dem pods
[03:16] <habithLp> anything about min space requirements tho?
[03:16] <habithLp> just less headache
[06:04] <ajk_> simbalion: No, it's definitely not that.
[06:04] <ajk_> !info baobab | jdwee
[06:04] <ajk_> perl-libs ?
[06:04] <ajk_> TCCR1B |= (1<<ICES1);
[06:04] <ajk_> g://screeps
[06:05] <ajk_> or an intel one if you don't really give a damn, in which case getting software running will probably be easier :p
[06:17] <minorisEk> It was a laptop, and I got an inheritence
[06:17] <minorisEk> so this will be the flow (if u think there's something im missing, let me know pls)
[06:17] <minorisEk> if you absolutely must categorize it..it'd be a "cosmetic" issue
[07:07] <maczal> Mochi
[07:07] <maczal> That thing was a WAR CRIME
[08:01] <Telvanaye> the default binaries in Ubuntu do not come with symbols (they are stripped) so sometimes stuff crashes and Icannot get a clean stack trace. Is there a clean way to just get all of the in-box ubuntu binaries with symbols w/o manually recopiling them myself? (i am talking about things like /bin/ls, /bin/cat/, ...)
[08:01] <Telvanaye> zenix_2k2: eh well... of course you must be able to represent your greater-than number
[08:01] <Telvanaye> darkis8, watch it won't boot now.
[08:02] <Telvanaye> so looks like tracking and ignoring can be simultaneously interesting.
[08:46] <sanitypassingwi> Monero is #10/1988 @ 0.92% ~ $125.87 / 0.00794441É± ~ 1h/1d/7d: -0.8/2.23/8.14 ~ 24h vol. 268,068.73672705É± / $33,743,059.29
[08:46] <sanitypassingwi> you'll find one of these in most of the locations now
[08:46] <sanitypassingwi> Not necessarily. Nothing saying you cannot map some memory in userspace, and point the card's DMA to that
[09:23] <ozybE> i would like to make tap to click more sensitive on bionic touchpad: https://hastebin.com/qezotiware.sql whats the command for it?
[09:23] <ozybE> RussellB2814: You are here in #fedora-unregistered because you are not registered or identified with freenode. See https://freenode.net/kb/answer/registration or /msg nickserv help register for more information.
[09:23] <ozybE> oh it's the even older
[09:23] <ozybE> I prefer console access to anything anyway, even built my own powershell client for the damn windows crap
[09:48] <mrmoneyc_> slack1256: probably vinyl
[09:48] <mrmoneyc_> fÑ–lesá»¿stÐµâ…¿â€¯dÎ¿es notâ€…á´¡râ…°tá¥±â€ƒwÑ–tÒ»Î¿ut perâ…¿iÑ•sÑ–oá¥’ of É‘llÉ‘h
[09:48] <mrmoneyc_> so it actually works...
[09:59] <Guest83511> personx, so you remember this dkms.conf you need to change the kernel_version MAKE line to include this /usr/src/linux-3.16.7-42/
[09:59] <Guest83511> for what it's worth, I do geninely really like the whole male choir thing you guys do so well.
[09:59] <Guest83511> Coffee:
[09:59] <Guest83511> I get minus 41.79 degree's
[12:46] <glenfeOz> xterm also has an upstream, so it may be just to keep the diff smaller
[12:46] <glenfeOz> a few hours ago mentioned something about reflection at compile time and metaclasses in C++2a... is there any proposal/draft about that? the subject interests me because I'm working on something related
[12:46] <glenfeOz> Chester A Arthur linix
[12:46] <glenfeOz> what's the reason to elide the size?
[12:49] <globinVf> I'm not lol
[12:49] <globinVf> I'm having issues understanding the fundamental group at x
[12:49] <globinVf> if traccert hits your router, then the interface didn't make it up
[12:49] <globinVf> But I'm thinking that the temperature is 120C higher than it's supposed to be
[12:49] <globinVf> http://www.duckychannel.com.tw/page-en/Ducky-Pocket/
[12:55] <efdeeTO> ab9rf: a functor is a kind of semantics mapping between domains.
[12:56] <efdeeTO> zouhair: no output
[12:56] <efdeeTO> Bradipo: so strace things and find out what's going on.
[12:59] <nick1234ES> C18 draft's typesetting style makes it an excellent text book
[12:59] <nick1234ES> https://theconservativetreehouse.files.wordpress.com/2015/01/nothing-to-see-here.gif
[12:59] <nick1234ES> this has been plauging me for the past week
[12:59] <nick1234ES> my boss is black - do you think that would've been the case 50 years ago?
[12:59] <nick1234ES> hmm no change
[12:59] <nick1234ES> is there a list of things I have to check when taking the sqrt of both sides of an inequality?
[14:32] <shpaqkq> runjutsu: which part of IT?
[14:32] <shpaqkq> I also have nonretina and its nice :D
[14:32] <shpaqkq> well the plastic is all melted and burnng and it smells also of burning plastic
[14:32] <shpaqkq> But but but it has non-seeded machine learning! You don't have to train it first!
[14:32] <shpaqkq> so for some reason it is trying to open the first arg as a file
[14:32] <shpaqkq> don't wanna get banned!
[14:38] <fr0tzed> qwebirc66236: maybe some portable external ssd?
[14:38] <fr0tzed> bazhang: it's a toughbook cf19 running ubuntu 18.04
[16:35] <EchozQs> I don't honestly remember specifically how I did that
[16:35] <EchozQs> and don't IRC as root, you silly.
[16:35] <EchozQs> ok, I haven't seen "lifting" yet. lemme look that up.
[16:35] <EchozQs> it works pretty correctly
[16:35] <EchozQs> it appears that SoftwareSerial's print(int16_t) takes the var in dec form and sends ASCII for each digit
[16:53] <tobiasuKp> newbieG: Add the missing type.
[16:53] <tobiasuKp> Porkepix: I can't be sure it's a terminal issue though, but I don't know how weechat could be responsible anyway
[16:53] <tobiasuKp> which is a requirement but thats only for storing the private key and cert in the file
[16:53] <tobiasuKp> Ok I think I will give this a break and try in the morning
[16:53] <tobiasuKp> tomty89: No, the thread you linked was about a guy being a tool about his damaged system
[17:02] <rmkUx>  No.Å¾
[17:02] <rmkUx> foo() { PROGNAME=foo /your/script "$@"; }
[17:03] <rmkUx> so that memory isnt really for code, just for flash memory
[17:03] <syndikatewJ> > let d = (Data.Map.fromList [(1::Int, 2::Int)]) in (d ^. at 1)
[17:03] <syndikatewJ> lotuspsychje if u still wanna help me out i did the command u told me yesterday
[17:03] <syndikatewJ> EriC^^: I wonder, isn't the A12 actually kind of new? Maybe 18.04 with the newer kernel would help?
[17:03] <syndikatewJ> heh - oh well - if it fries itself - its dells problem ;p
[18:36] <aethjT> no it is not complete
[18:36] <aethjT> But how so
[18:36] <aethjT> paper compilers*
[18:36] <aethjT> kremator: B) Is not a strong argument, also cracking doesn't make much sense. One power of free software is that when somebody find a flaw, someone fixes it quite fast; so it's more like most exploits don't survive long
[18:36] <aethjT> open covers work fine in metric spaces, and rudin has a section on it (in the compactness part)
[19:41] <MiX-MaN> Which are autogenerated, but somewhat patched
[19:41] <MiX-MaN> -bash 4.4 >>> fc-cache -f
[20:11] <zed2k_> how can i set payment threshold pls?
[20:11] <zed2k_> just gettin' by
[20:11] <zed2k_> I never did use Lion
[20:22] <averageuh> lin_noob, ah, but dont they have a lot of business in Japan and China lately?
[20:22] <averageuh> Loetmichel: If your boss goes to prison, are you going to have to look for a new job?
[20:22] <averageuh> the equivalent GET request url would be http://<IP_ADDRESS>/ExTra/list.php?pgpid=#### where #### would be the room number
[23:51] <RamJettil> i also found this and it has different settings
[23:52] <RamJettil> one of my favorite thing in seeing PCBs is un- or partially populated areas


[10:19] <frathgeber> jelmer: i found this answer from 3 years ago saying there is an option `bzr diff --format=git-am`: https://answers.launchpad.net/bzr/+question/106814
[10:19] <frathgeber> has that since been removed?
[10:20] <frathgeber> i'm using bzr 2.6.0~bzr6573.6287~ppa4050~precise1 and bzr-git 0.6.9+bzr1613~ppa131.1471~precise1
[10:20] <frathgeber> another more recent answer from you (https://answers.launchpad.net/bzr/+question/204262) seems to suggest it has
[12:10] <jelmer> frathgeber: Hi
[12:10] <jelmer> frathgeber: you need the bzr-git plugin
[12:35] <frathgeber> jelmer: i have bzr-git 0.6.9, but it complains about not knowing --format=git-am (--format=git works)
[13:17] <jelmer> frathgeber: ah, I think you want 'bzr send --format=git-am'
[13:56] <frathgeber> jelmer: send doesn't seem to like that format either: bzr: ERROR: Bad value "git-am" for option "format"
[13:57] <frathgeber> jelmer: my real question is acutally this, wondering if you might have an idea? http://stackoverflow.com/q/15660467/396967
[13:57] <frathgeber> i was just thinking we might be able to circumvent the problem with exporting a patch series
[13:59] <frathgeber> jelmer: according to `git help send` the valid format options are 2 and 4
[14:18] <jelmer> frathgeber: bzr send --format=git perhaps?
[14:18] <jelmer> frathgeber: if that doesn't work either, then you are probably running a version of bzr or bzr-git that is too old
[14:19] <jelmer> frathgeber: for general imports from bzr to git, you can also use "bzr dpush" to create the git branch
[14:24] <frathgeber> jelmer: jep, bzr send --format=git seems to be supported but crashes: i suspect in the version of bzr-git the send command is not compatible to bzr 2.6.0dev3
[14:26] <frathgeber> jelmer: re dpush: this will first convert the bzr branch to a bzr-git repository via dulwich i assume? and then push to a git remote?
[14:30] <frathgeber> presumably this will require using dpush to initially populate the git repository? what about dpushing multiple bzr branches? will they maintain the correct ancestry relationships also over on the git side?
[14:39] <jelmer> frathgeber: dpush is easiest when you are pushing to a local git repository
[14:39] <jelmer> frathgeber: dpushing multiple bzr branches will have related ancestry
[14:40] <jelmer> frathgeber: you'll have to create a local git repository and an (empty) branch in it before you can dpush to it
[14:42] <frathgeber> jelmer: ok, thanks. so the result is equivalent to using bzr fast-export | git fast-import?
[14:42] <jelmer> frathgeber: no, it's a different history from what fast-export/fast-import would create
[14:42] <frathgeber> in what way?
[14:43] <jelmer> frathgeber: there are likely subtle differences in the way the git commits are created
[14:44] <frathgeber> ah, ok. so the revision DAG will be the same but the SHA1s?
[14:45] <jelmer> frathgeber: yeah, the SHA1s will be different
[14:45] <frathgeber> can i dpush to a bare git repo?
[14:45] <jelmer> the ancestry graph should have the same shape; bzr dpush preserves the shape that it had in bzr, I'm not entirely sure about fastexport/fastimport
[14:46] <jelmer> frathgeber: yes, though there needs to be an empty branch in that repo
[14:46] <frathgeber> how do i create an empty branch?
[14:49] <frathgeber> jelmer: wouldn't the branch normally only be created when i push to the bare repo for the first time?
[14:52] <jelmer> frathgeber: "bzr init /path/to/git/repo" should do it, assuming the git repo already exists
[14:53] <jelmer> frathgeber: "bzr dpush" was designed mostly to contribute to existing git projects from bzr
[14:53] <jelmer> ideally it would indeed create new branches too, but I never got around to implementing that
[14:53] <frathgeber> ok
[14:55] <frathgeber> so if our base is the bzr repo, we export to git and then make changes on the git side, we should be able to sync them back to bzr, but only if we have *the same* bzr-git repo that was created for the conversion. is that approximately correct?
[14:57] <frathgeber> jelmer: created by dpush i mean. and this repo will have different bzr commit ids than the "original" bzr branches, so the original bzr repo and the bzr-git repo will appear (to bzr) to not share any history, right?
[14:58] <jelmer> frathgeber: basically, yes
[14:58] <jelmer> frathgeber: "bzr dpush" will update your local bzr repository to only have data that can be represented in git
[14:59] <jelmer> frathgeber: and will basically have the same contents as the result of "bzr branch /path/to/your/git/repo /clone/in/bzr"
[15:00] <frathgeber> jelmer: yep, that makes sense and was what i assumed it would do
[15:00] <jelmer> frathgeber: you can use --no-rebase to preserve the original bzr repository. in that case, "bzr pull /path/to/new/git/repo" will give a "diverged branches" error
[15:02] <frathgeber> ok
[15:02] <frathgeber> jelmer: unfortunately that means that it probably won't help in our use case: the main problem i'm describing in http://stackoverflow.com/q/15660467/396967 is that we 1) export bzr -> git 2) filter the git repo (strip some files from history)
[15:03] <jelmer> frathgeber: dpush takes care of step 1, filtering the git repository can be done independent of that
[15:03] <jelmer> frathgeber: do you care about working in git and bzr?
[15:03] <jelmer> I thought you just wanted to do a one-off migration to git?
[15:03] <frathgeber> jelmer: yes, so far there's no problem. but now we want to be able to migrate further branches over to the filtered git repo while preserving their ancestry
[15:04] <frathgeber> jelmer: yes, it's a one-off migration
[15:04] <jelmer> frathgeber: that should work fine, as long as you do the filtering in a way that's consistent
[15:04] <jelmer> (i.e. so the same filter command on the same commit generates the same result commit with the same sha1)
[15:07] <frathgeber> jelmer: i *think* that's the case. however i'm still not sure how that would work in practice: would whoever wants to import another branch have to repeat steps 1) and 2) on their branch and then push?
[15:14] <jelmer> frathgeber: yes
[15:15] <jelmer> frathgeber: another option is to just do the import and then just have a commit on trunk that removes the problematic directory
[15:16] <jelmer> you could always rewrite the repository history in the future to strip out those large files
[15:17] <frathgeber> jelmer: yes, but that would require every contributor to get a fresh clone of the rewritten history, pay attention to not accidentally push from an "old" clone etc. that's why we rather do it in the conversion process
[15:18] <frathgeber> jelmer: the bzr -> git migration will require that anyway, so we'd rather do it now and be done with it
[15:19] <frathgeber> jelmer: however we don't necessarily want to import *everyone's* branches because some of them might well be dead/dormant. so we'd rather have a safe and easy to use migration path for our collaborators/contributors and their branches
[15:19] <jelmer> frathgeber: I would argue that that's mostly a git question; if you have multiple related branches, can you run a filter command that will keep consistent identity for the commits they have in common
[15:21] <frathgeber> jelmer: yes, git filter-branch can do that. i'm starting to think that maybe we can't get round importing everyone's branches all at once and run the filtering afterwards
[15:22] <frathgeber> that seems to me to be the only safe option
[15:26] <frathgeber> jelmer: would the git smart server help? bzr serve --git?
[15:27] <jelmer> frathgeber: I don't see how it would. whatever you do, the filtering is the issue - not the importing from bzr
[15:27] <jelmer> frathgeber: bzr can create consistent git commits for a particular bzr repo
[15:28] <jelmer> s/particular bzr repo/bzr repo with the same history/
[15:28] <jelmer> if two people run bzr dpush on seperate branches of your project and they each have revision X in bzr then they will both end up with revision X' (with the same SHA1) in git
[15:29] <frathgeber> ok, i think the same is true with fast-export
[15:30] <frathgeber> jelmer: yes, i agree the filtering is the issue. i was hoping i could maybe integrate the filtering in the export pipeline i.e. bzr fast-export | filter | git fast-import
[15:31] <frathgeber> and ideally combine that with writing marks files on both end to save having to redo the work for every branch (but only ex/import missing commits)
[15:32] <frathgeber> i was looking at git_fast_filter which appears to be designed for that purpose: https://github.com/maxandersen/jbosstools-gitmigration/tree/master/git_fast_filter
[15:32] <frathgeber> but it can only deal with git fast-export streams, it chokes on bzr fast-export streams
[15:33] <jelmer> frathgeber: even with --plain?
[15:33] <frathgeber> seems so, yes
[15:34] <jelmer> frathgeber: how does it fail?
[15:34] <frathgeber> it dies on this line: https://github.com/maxandersen/jbosstools-gitmigration/blob/master/git_fast_filter/git_fast_filter.py#L720
[15:35] <jelmer> I doubt you can reuse marks files in this case btw, because the marks file was generated for a slightly different stream than the resulting stream after the filter
[15:36] <frathgeber> jelmer: yes, i was thinking about that: there might be revisions disappearing because they only touch stripped files
[15:38] <frathgeber> jelmer: it chokes on this line in the fast-export stream: "M 644 inline .hgignore" (which doesn't match the regex pattern)
[15:40] <frathgeber> jelmer: but as you say, it's potentially unsafe anyway even if i could get it to work. i'm more and more leaning towards importing all branches before filtering
[16:32] <clyon> Hi. I have a problem with bzr on the gcc repo in launchpad.
[16:32] <clyon> bzr revno lp:~christophe-lyon/gcc/4.8-disable-peeling2
[16:32] <clyon> bzr: ERROR: Server sent an unexpected error: ('error', 'GhostRevisionsHaveNoRevno', 'Could not determine revno for {svn-v4:138bc75d-0d04-0410-961f-82ee72b054a4:trunk:196812} because its ancestry shows a ghost at {svn-v4:138bc75d-0d04-0410-961f-82ee72b054a4:trunk:196812}')
[16:32] <clyon> bzr --version
[16:32] <clyon> Bazaar (bzr) 2.5.1
[16:32] <clyon>   Python interpreter: /usr/bin/python 2.7.3
[16:33] <clyon> The host is running Ubuntu 12.04 (x86_64)
[16:34] <clyon> How can I fix this?
[16:35] <fullermd> Is it just a remote issue?
[16:36] <clyon> Sorry, what do you mean by remote?
[16:36] <fullermd> I mean, does it happen only when you try to revno the branch on lp, or does it happen when you have the branch locally too?
[16:37] <clyon> Only remotely.
[16:37] <fullermd> Ghosts have always been a fruitful source of bugs.  So I wouldn't be surprised if there were one hiding in the twisty details of whatever RPC calls revno makes on remotes.
[16:37] <clyon> From another host running bzr 2.1.4/python 2.6.5, it works
[16:38] <fullermd> Probably that version is old enough that it's really "dumb" about how it goes about doing a remote revno.
[16:38] <clyon> Too bad. What can I do? (I don't know how that mirroring of GCC works, from svn to bzr)
[16:39] <fullermd> Probably not much; it sucks having a history with ghosts, so if that's avoidable it would be good.  But it's often not.
[16:40] <fullermd> It IS a bug in bzr that revno fails in that way (I mean, it would be a bug blowing up all over the place, but it's _definitely_ a bug that it blows up in remote but works locally)
[16:40] <fullermd> So it's worth filing a bug on.  Or fixing yourself, but that'll take time and knowledge of what are probably some of the uglier bits of bzrlib.
[16:41] <fullermd> Since it's fairly well localized, it's probably a relatively tractable bug at least.
[16:41] <clyon> How can I workaround it? It's used in our validation script, which monitors the bzr database...
[16:42] <fullermd> Mmm.  Well, you can try decorating things to not use the smart methods.  Calling directly to the HTTP URL would work, or I think a nosmart+bzr+ssh (or is it bzr+ssh+nosmart?).  Have to bypass the lp: directory service, but that's easy enough.
[16:42] <fullermd> If it fits, better would be to have a local branch mirror and revno against it.
[16:43] <clyon> OK. I have to read the doc about nosmart :-)
[16:43] <fullermd> Looks like it's nosmart+b+s:
[16:43] <fullermd> % bzr info bzr+ssh+nosmart://localhost/nonexistent
[16:43] <fullermd> bzr: ERROR: Unsupported protocol for url "bzr+ssh+nosmart://localhost/nonexistent"
[16:43] <fullermd> % bzr info nosmart+bzr+ssh://localhost/nonexistent
[16:43] <fullermd> bzr: ERROR: Not a branch: "nosmart+bzr+ssh://localhost/nonexistent/".
[16:44] <LarstiQ> that revno error happens with bzr.dev too
[16:46] <clyon> bzr revno nosmart+bzr+ssh://launchpad.net/~christophe-lyon/gcc/4.8-disable-peeling2
[16:46] <clyon> ssh: connect to host launchpad.net port 22: Connection refused
[16:47] <fullermd> Nah, the branch URL is a little different.
[16:48] <fullermd> If you've got a local mirror of the branch, you can just grab the URL from it.
[16:48] <fullermd> Or I think...
[16:48] <fullermd> Yeah, you can do a "bzr info lp:whatever" and get the full URL from that.
[16:48] <clyon> Indeed.
[16:48] <clyon> bzr revno nosmart+bzr+ssh://bazaar.launchpad.net/~christophe-lyon/gcc/4.8-disable-peeling2
[16:48] <clyon> 122393
[16:49] <clyon> Thanks!
[16:50] <fullermd> Actually, now that I think about it, I think you can 'nosmart+lp' even.  That's simpler.
[16:51] <clyon> Confirmed!
[16:51] <fullermd> Worth filing a bug en passant anyway, just for doc purposes.
[16:51] <clyon> OK, I will do it.
[16:54] <clyon> Just reported as #1161018
[16:55] <fullermd> bug 1161018
[20:50]  * fullermd waves at vila.


 :P
[12:43]  * canthus13 just moved into a new house.
[12:43] <thafreak> same burg?
[12:43] <thafreak> toledo-ville?
[12:45] <canthus13> Yup.
[12:47] <canthus13> Still at the same job, still looking for a way out of tech support hell. :P
[12:50] <thafreak> I hear you...
[12:50] <thafreak> I hate getting recruiter emails anymore, because they're all for sysadmin jobs
[12:51] <thafreak> and I just don't want to do it anymore
[12:51] <thafreak> but, honestly, I just don't want to work for anyone really...
[12:54] <canthus13> Heh. I'd love a sysadmin job. :)
[12:55] <thafreak> You sure? even if it's a lone sysadmin job?
[12:55] <thafreak> Where you get to maintain EVERYTHING with no help?
[12:55] <thafreak> Cause, it seems most of the gigs around are like that
[12:55] <canthus13> Sounds like a fun challenge.
[12:55] <thafreak> hahaha...you must hate your job more than i do
[12:56] <canthus13> It's gotta be better than struggling to get people to do things a trained armadillo could do.
[12:56] <thafreak> Oh, then don't get a sysadmin job in academia
[12:56] <canthus13> ...and it's gotta pay better, too.
[12:56] <thafreak> trained armadillo's do laps around phd's
[12:56] <canthus13> heh.
[12:56] <thafreak> right dr. dzho ?
[13:40] <dzho> wut
[13:40] <dzho> oh, right.
[13:40] <dzho> yes, yes they do.
[13:41] <dzho> in fact, I have one circling me now.
[13:41] <dzho> my only concern is that they carry Hansen's disease.
[13:41] <dzho> aka leprosy
[13:41] <dzho> thafreak: we must thank fsm for canthus13 who serves as a reminder that it can always be worse
[13:41] <thafreak> which is better than hanson's disease
[13:42] <dzho> different kind of wasting away, but yes
[13:42] <thafreak> mmmm bop
[14:40] <skellat> Hmm: http://www.newsnet5.com/dpp/news/local_news/water_cooler/Princeton-Review-releases-lists-of-top-party-sober-schools
[14:40] <jenni> [ Princeton Review releases lists of top party, sober schools ] - https://j.mp/15FjzTm
[14:41] <skellat> At least thafreak's institution didn't make the list this year
[16:27] <canthus13> Huh. I'm surprised University of Toledo didn't make the list.


[07:52] -queuebot:#ubuntu-release- Unapproved: fwupd-signed (focal-proposed/main) [1.27.1ubuntu4 => 1.27.1ubuntu5] (core)
[07:52] -queuebot:#ubuntu-release- New: accepted binutils-or1k-elf [amd64] (impish-proposed) [1]
[07:52] -queuebot:#ubuntu-release- New: accepted binutils-or1k-elf [armhf] (impish-proposed) [1]
[07:52] -queuebot:#ubuntu-release- New: accepted binutils-or1k-elf [riscv64] (impish-proposed) [1]
[07:52] -queuebot:#ubuntu-release- New: accepted binutils-or1k-elf [arm64] (impish-proposed) [1]
[07:52] -queuebot:#ubuntu-release- New: accepted binutils-or1k-elf [s390x] (impish-proposed) [1]
[07:52] -queuebot:#ubuntu-release- New: accepted binutils-or1k-elf [ppc64el] (impish-proposed) [1]
[07:53] <juliank> sil2100: ^^ a fixed up fwupd-signed in focal
[07:53] <juliank> sil2100: I forgot to change the build-depends last time :/
[07:54] <sil2100> o/
[07:54] <sil2100> Yeah, saw the ping from ycheng
[07:54] <sil2100> Looking now
[07:57] <schopin> xnox: I guess I did that (couldn't build the package without the patches anyway). Thanks for the explanation!
[08:26] -queuebot:#ubuntu-release- Unapproved: accepted fwupd-signed [source] (focal-proposed) [1.27.1ubuntu5]
[09:14] -queuebot:#ubuntu-release- New: accepted wlroots [amd64] (impish-proposed) [0.13.0-1]
[09:14] -queuebot:#ubuntu-release- New: accepted wlroots [armhf] (impish-proposed) [0.13.0-1]
[09:14] -queuebot:#ubuntu-release- New: accepted wlroots [riscv64] (impish-proposed) [0.13.0-1]
[09:14] -queuebot:#ubuntu-release- New: accepted wlroots [arm64] (impish-proposed) [0.13.0-1]
[09:14] -queuebot:#ubuntu-release- New: accepted wlroots [s390x] (impish-proposed) [0.13.0-1]
[09:14] -queuebot:#ubuntu-release- New: accepted wlroots [ppc64el] (impish-proposed) [0.13.0-1]
[09:15] <sil2100> slyon: hey! Accepted the new binaries ^ But yeah, I see libwlroots7 had some reverse-depends, so yeah, those might need rebuilding/handling
[09:17] <slyon> sil2100: thanks! Yes, I triggered a sync for the sway reverse-dependency that resolves this. There is a new phoc upstream release in Debian/experimental as well, I need to look into that too
[09:36] -queuebot:#ubuntu-release- New binary: gcc-or1k-elf [amd64] (impish-proposed/universe) [1] (no packageset)
[09:46] <sil2100> \o/
[09:49] <sil2100> huh, a lot of image build failures I see
[09:49] <sil2100> Most of the livefs builds failed with no logs though
[10:22] <xnox> something must have happened, as the gcc-or1k-elf builds also all failed without logs. restarted them now.
[10:24] <laney> eek
[10:27] -queuebot:#ubuntu-release- Unapproved: ceph (focal-proposed/main) [15.2.13-0ubuntu<IP_ADDRESS> => 15.2.13-0ubuntu<IP_ADDRESS>] (desktop-core, ubuntu-server)
[10:31] <mwhudson> sil2100: i asked in #launchpad and got this
 mwhudson: we had a network outage this morning, can you retry them and see what happens?
[10:31] <mwhudson> sil2100: so it might be worth trying again?
[10:38] <laney> I'm trying ubuntu desktop again
[10:38] <laney> see if that works
[11:06] -queuebot:#ubuntu-release- New binary: gcc-or1k-elf [riscv64] (impish-proposed/universe) [1] (no packageset)
[11:19] <laney> arm64 failed again
[11:22]  * laney has asked LP
[11:54] <LocutusOfBorg> juliank, cjwatson I tried to build virtualbox locally
[11:54] <LocutusOfBorg> with DH_VERBOSE=1
[11:54] <LocutusOfBorg> and r^3:no
[11:55] <LocutusOfBorg> I did "fakeroot debian/rules clean build install binary"
[11:55] <LocutusOfBorg> and I can confirm the bug if I run from unprivileged user, and no bug if I run as root
[11:55] <LocutusOfBorg> (in a chroot)
[11:56] <LocutusOfBorg> fakeroot chmod -s debian/virtualbox/usr/lib/virtualbox/VBoxSDL
[11:56] <LocutusOfBorg> this fails
[11:56] <LocutusOfBorg> and this doesn't chmod -s debian/virtualbox/usr/lib/virtualbox/VBoxSDL
[11:58] <LocutusOfBorg> forget the last sentence, I was doing -s instead of +s
[12:32] <xnox> LocutusOfBorg:  Rules-Requires-Root: binary-targets i've not seen such stanza before.
[12:32] <xnox> i've see no-stanza, and Rules-Requires-Root: no.
[12:33] <xnox> LocutusOfBorg:  i wonder if Rules-Require-Root: binary-targets is not well supported.
[12:33] <xnox> LocutusOfBorg:  i wonder if it worth a try to drop that line altogether, and build again.
[12:38] <LocutusOfBorg> xnox, it stopped working when I added Rules-Requires-Root: no
[12:38] <LocutusOfBorg> if I removed, or I add binary-target it works again
[12:39] <LocutusOfBorg> vbox is already busted in impish and hirsute-proposed
[12:46] <xnox> LocutusOfBorg:  one cannot use RRR:no with chmod +s.... it is contradictory.
[12:46] <xnox> LocutusOfBorg:  why did you add RRR:no?
[12:47]  * xnox expects virtualbox to build _without_ RRR stanza in control.
[12:51] <LocutusOfBorg> xnox, it works also with RRR: binary-targets
[12:52] <LocutusOfBorg> The builder may set DEB_RULES_REQUIRES_ROOT environment variable when calling any of the mandatory targets as defined in Rules-Requires-Root. If the variable is not set, the package must behave as if it was set to binary-targets.
[12:52] <LocutusOfBorg> and that variable is documented
[12:52] <LocutusOfBorg> my issue is: why R^3: no works on Debian but not in Ubuntu?
[12:52] <LocutusOfBorg> how many packages (wrongly) added R^3: no and then failed to run in Ubuntu?
[12:56] <xnox> LocutusOfBorg:  builders can choose to ignore RRR:no.... so i guess the question is if debian builders are honoring it, and are not missbuilt there too.
[12:56] <xnox> one is supposed to test packages before building them with RRR:no
[12:56] <xnox> some also try to do chmod +s in maintainer scripts, rather than packaging it.
[13:00] <xnox> also not sure if i care about package that incorrectly uses RRR:no and gets missbuilt to still be working.
[13:05] <xnox> LocutusOfBorg:  i am confused about your assertion that in Debian in works. In debian i see correct permissions and RRR:binary-targets.
[13:05] <xnox> LocutusOfBorg:  i don't see "correct permissions and RRR:no"
[13:05] <xnox> was that in some previous upload?
[13:06] <xnox> ah i see you did that in -4
 one is supposed to test packages before building them with RRR:no.
[13:08] <LocutusOfBorg> yes, you test on Debian, everything works, you upload, the package is broken in Ubuntu
[13:08] <LocutusOfBorg> or even, you build with pbuilder, you test, you upload, its broken
[13:08] <xnox> LocutusOfBorg: i am perplexed how did -3 build with correct permissions in debian.
 LocutusOfBorg: i am perplexed how did -3 build with correct permissions in debian.
[13:08] <LocutusOfBorg> that is the main point
[13:09] <LocutusOfBorg> the mismatch between Debian and Ubuntu behaviour
[13:09] <xnox> LocutusOfBorg:  either builder is ignoring RRR:no; or there is a buggy kernel; or there are some brand new fixes somehwere in debian that allow doing chmod +s; then chown root; and keep the +s ..... which is quite a violation of priviledge escalation.....
[13:09] <xnox> LocutusOfBorg:  there are lots of differences between debian & ubuntu. in sbuild, dpkg, toolchain, kernel behaviour.
[13:09] <xnox> so i'm not surprised that are discrepancies.
[13:10] <xnox> it would be nice to get them explained.
[13:10] <lucasmoura> Hi sil2100 we have already performed the verification for ubuntu-advantage-tools and the new package is sitting in proposed for more than a week now
[13:10] <LocutusOfBorg> but if Debian is "ignore R^3", how are people supposed to check/test it?
[13:10] <LocutusOfBorg> looks more an experimental feature
[13:10] <lucasmoura> I think we can upload it to updates
[13:10] <lucasmoura> https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1934902
[13:10] <LocutusOfBorg> I already set to binary-target and looks working, so meh
[13:13] <xnox> LocutusOfBorg:  normally one tests with local build by hand. aka dpkg-buildpackage -b => as non-root user; instead of like -rfakeroot or some such.
[13:13] <xnox> as per documentation RRR:no means may invoke any target with an unprivileged user.
[13:13] <xnox> => meaning some builders can choose to ignore that.
[13:13] <LocutusOfBorg> nobody ever told anywhere to not use pbuilder to build something, specially w.r.t. R^3
[13:14] <LocutusOfBorg> anyway, probably just virtualbox is broken
[13:14] <LocutusOfBorg> so meh
[13:14] <LocutusOfBorg> I might even change to do chmod in postinst
[14:01] -queuebot:#ubuntu-release- Unapproved: shim-signed (focal-updates/main) [1.40.6 => 1.40.6] (core) (sync)
[14:01] -queuebot:#ubuntu-release- Unapproved: shim (focal-updates/main) [15.4-0ubuntu7 => 15.4-0ubuntu7] (core) (sync)
[14:06] <bdmurray> vorlon: where are we at with the NBS removal for Groovy?
[14:19] <sil2100> lucasmoura: hey! Will look at releasing it later today!
[14:20] <lucasmoura> Thanks sil2100
[14:21] <sil2100> xnox: hey, did you chat with William about why they didn't backport the new opensbi for the u-boot backport?
[14:22] <sil2100> Would like to know if that's still needed for .3
[14:34] -queuebot:#ubuntu-release- Unapproved: wireless-regdb (bionic-proposed/main) [2020.11.20-0ubuntu1~18.04.1 => 2021.07.14-0ubuntu1~18.04.1] (core) (sync)
[14:34] -queuebot:#ubuntu-release- Unapproved: wireless-regdb (focal-proposed/main) [2020.11.20-0ubuntu1~20.04.1 => 2021.07.14-0ubuntu1~20.04.1] (core) (sync)
[14:34] -queuebot:#ubuntu-release- Unapproved: wireless-regdb (hirsute-proposed/main) [2020.11.20-0ubuntu1 => 2021.07.14-0ubuntu1~21.04.1] (core) (sync)
[14:43] -queuebot:#ubuntu-release- New binary: gcc-or1k-elf [s390x] (impish-proposed/universe) [1] (no packageset)
[14:57] <xnox> sil2100:  i did, he said him and/or xypron will be preparing it.
[14:57] <xnox> sil2100:  i believe that yes we do need it for .3
[14:57] <xnox> u-boot-sifive postinst + opensbi
[14:58] <xnox> i could make it too, but don't want to duplicate work if it already started by jawn-smith & xypron
[15:00] <jawn-smith> That's correct, xypron and I have started on that, and the plan is for xypron to be the main force behind that
[15:02] <sil2100> didrocks999: helloooooooo! I have a request: could you reupload ubiquity with the new shim refreshed?
[15:02] <sil2100> didrocks999: for focal that is
[15:02] <sil2100> \o/
[15:03] <didrocks999> sil2100: hey! I just need to basically dget <IP_ADDRESS> and reupload it, or is there anything else needed?
[15:04] -queuebot:#ubuntu-release- New binary: gcc-or1k-elf [arm64] (impish-proposed/universe) [1] (no packageset)
[15:09] <vorlon> bdmurray: NBS removal has finished
[15:09] -queuebot:#ubuntu-release- New binary: gcc-or1k-elf [armhf] (impish-proposed/universe) [1] (no packageset)
[15:10] <jawn-smith> xnox: is there anything else besides the loader1/loader2 issue missing from u-boot for 20.04.3? Someone mentioned it may have a problem
[15:10] <sil2100> didrocks999: yeah, just refreshing the in-source deps is enough :)
[15:11] <xnox> jawn-smith:  1) add postinst 2) make that build of u-boot be built against the new opensbi. I.e. u-boot sru must have build-depends: opensbi => (the sru version of opensbi with errata fix)
[15:11] <didrocks999> sil2100: shouldn’t you accept the shim packages first (they are still in unapproved)?
[15:12] <didrocks999> or it’s independent and will be pick up when refreshing the in-source deps?
[15:12] <jawn-smith> right those are the two things that xypron has included in his latest ppa build that just needs sponsorship
[15:14] <didrocks999> ack, seems it’s picking  1.40.6
[15:18] -queuebot:#ubuntu-release- Unapproved: ubiquity (focal-proposed/main) [<IP_ADDRESS> => <IP_ADDRESS>] (core)
[15:18] <didrocks999> sil2100: done ^
[15:20] <sil2100> \o/
[15:20] <sil2100> REVIEWING!
[15:22] <sil2100> didrocks999: yeah, it pick up stuff from -proposed, no problem
[15:22] <Eickmeyer> ubuntu-archive: Does anybody have a cycle or two to review plasma-optimus? It's a neat little plasmoid I forked for KDE Plasma. :)
[15:27] -queuebot:#ubuntu-release- Unapproved: rejected ubiquity [source] (focal-proposed) [<IP_ADDRESS>]
[15:33] <sil2100> didrocks999: eeek, sorry to poke you again, the SRU is all good and all, but since I hope you have the branch still on your PC and such - there's a debian/.changelog.swp in the diff
[15:33] <sil2100> didrocks999: could you just re-upload with that removed? If you're busy I guess I could also tweak it though
[15:34] <didrocks999> sil2100: argh, I thought debuild was skipping them, weird, anyway, let me rebuild the source package and upload
[15:34] <jawn-smith> sil2100: do we ever plan to SRU the golang ubuntu-image to focal?
[15:34] <sil2100> didrocks999: thanks, this will be an insta-accept then o/
[15:35] <sil2100> jawn-smith: I would say yes! So the python ubuntu-image we actually supported on every supported release, and I think we'd still want to do something similar, especially for LTS users
[15:36] -queuebot:#ubuntu-release- Unapproved: ubiquity (focal-proposed/main) [<IP_ADDRESS> => <IP_ADDRESS>] (core)
[15:36] <didrocks999> sil2100: \o/ this one should be good ^ sorry for this
[15:37] <sil2100> If, let's say, we see there's some issue in supporting it in bionic, so LTS-1, then I'd say let's at least let's support it in focal
[15:37] <sil2100> didrocks999: thank you!
[15:38] <didrocks999> yw :)
[15:38] -queuebot:#ubuntu-release- Unapproved: rejected ubiquity [source] (focal-proposed) [<IP_ADDRESS>]
[15:39] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (focal-proposed) [<IP_ADDRESS>]
[15:44] -queuebot:#ubuntu-release- Packageset: Removed debian-installer from i386-whitelist in impish
[15:44] -queuebot:#ubuntu-release- Packageset: Added eglexternalplatform to i386-whitelist in impish
[15:44] -queuebot:#ubuntu-release- Packageset: Added gtk4 to i386-whitelist in impish
[15:44] -queuebot:#ubuntu-release- Packageset: Added nvidia-graphics-drivers-470-server to i386-whitelist in impish
[15:53] <xnox> bdmurray:  can i please request early sru-release of bug #1932173 , bug #1932169 , bug #1932160 , bug #1932159 ? these are verified, no adt regressions, but we need them out to flip hwe kernels from v5.8 to v5.11
[15:54] <bdmurray> xnox: You can always request things.
[15:55] <bdmurray> Seriously though I'll look at those today.
[15:56] <xnox> bdmurray:  =)))))))
[15:56] <xnox> bdmurray:  i feel like at this point my karma quota of that "one standard bottle of white wine" as declared on the customs forms is running out though.
[15:57] <sil2100> I'll be still doing a sweep through -proposed packages to release, so let me ping you bdmurray when I'm done with that
[15:57] <sil2100> Since I don't know if I'll manage to go through all of them
[15:57] <xnox> bdmurray:  sil2100: from kernel team, we will need two more sru-accept; verify; sru-release.
[15:58] <xnox> added targets for 20.04.3 & set importance to critical https://launchpad.net/ubuntu/+milestone/ubuntu-20.04.3 as without them, we are not going to get hwe changed from v5.8 to v5.11 it will regress peoples wifi => those people will not be happy about wifi-less kernel upgrades.
[15:59] -queuebot:#ubuntu-release- Packageset: Added pipewire to i386-whitelist in impish
[15:59] -queuebot:#ubuntu-release- Packageset: Added weston to i386-whitelist in impish
[16:02] <bdmurray> sil2100: why don't you review my livecd-rootfs MP and I'll do the SRU stuff
[16:04] -queuebot:#ubuntu-release- Unapproved: evdi (focal-proposed/universe) [1.9.1-1ubuntu3~20.04.1 => 1.9.1-1ubuntu4~20.04.1] (kernel-dkms) (sync)
[16:05] <xnox> bdmurray:  in terms of sru-accepts kernel team really wants the evdi above https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=evdi
[16:05] <bdmurray> xnox: I've heard that
[16:05] <xnox> and https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=lttng-modules
[16:06] <xnox> bdmurray:  yeah, i bet you have. sorry. We just came out of sync meeting. and let's just say, nobody was happy that we can't flip to v5.11 already.
[16:07] <sil2100> bdmurray: I already did that!
[16:07] <sil2100> Anyway, I'm doing a sweep of proposed now, will do some queue reviews tomorrow
[16:08] <bdmurray> sil2100: I'm out tomorrow so will do some of my SRU work today
[16:11] <sil2100> bdmurray: oh, ok, so maybe let's switch in that case, I'll do part of my shift tomorrow then - I only managed to release ubuntu-advantage-tools into -updates if anything
[16:11] <bdmurray> sil2100: that sounds like a solid plan to me
[16:13] <sil2100> I'll also look into the release of shim in a bit, if not I'll do that tomorrow - so leave those to me for now
[16:13] -queuebot:#ubuntu-release- New binary: gcc-or1k-elf [ppc64el] (impish-proposed/universe) [1] (no packageset)
[16:13] <bdmurray> sil2100: will do
[16:13] <sil2100> Since it's a mess with the fwupd entangled
[16:13] <bdmurray> or not do in this case
[16:14] -queuebot:#ubuntu-release- Packageset: Added libopenaptx to i386-whitelist in impish
[16:41] -queuebot:#ubuntu-release- New sync: cockpit-machines (impish-proposed/primary) [243-1]
[16:43] -queuebot:#ubuntu-release- New: accepted cockpit-machines [sync] (impish-proposed) [243-1]
[16:49] <bdmurray> vorlon: Given the NBS removal has finished AIUI I can mark Groovy as obsolete. Is that correct?
[16:51] -queuebot:#ubuntu-release- New binary: cockpit-machines [amd64] (impish-proposed/none) [243-1] (no packageset)
[16:52] -queuebot:#ubuntu-release- New: accepted cockpit-machines [amd64] (impish-proposed) [243-1]
[16:58] -queuebot:#ubuntu-release- Unapproved: xtables-addons (focal-security/universe) [3.9-1ubuntu0.2~20.04.3 => 3.9-1ubuntu0.2~20.04.3] (kernel-dkms) (sync)
[16:59] -queuebot:#ubuntu-release- Packageset: Added libldac to i386-whitelist in impish
[17:02] -queuebot:#ubuntu-release- Unapproved: broadcom-sta (focal-security/multiverse) [<IP_ADDRESS>1-12ubuntu0.1 => <IP_ADDRESS>1-12ubuntu0.1] (kernel-dkms) (sync)
[17:03] <vorlon> bdmurray: I believe so yes
[17:04] -queuebot:#ubuntu-release- Unapproved: rtl8812au (focal-security/universe) [<IP_ADDRESS>75.20140902+dfsg-0ubuntu13~20.04.3 => <IP_ADDRESS>75.20140902+dfsg-0ubuntu13~20.04.3] (kernel-dkms) (sync)
[17:04] <bdmurray> vorlon: okay, let's find out
[17:06] <bdmurray> vorlon: also there should be 4 packages for the security pocket in the Focal unapproved queue - bcmwl will be the 4th
[17:07] -queuebot:#ubuntu-release- Unapproved: bcmwl (focal-security/restricted) [<IP_ADDRESS>1+bdcom-0ubuntu7~20.04.3 => <IP_ADDRESS>1+bdcom-0ubuntu7~20.04.3] (kernel-dkms, ubuntu-desktop) (sync)
[17:29] -queuebot:#ubuntu-release- Packageset: 7772 entries have been added or removed
[17:37] <krytarik> xnox: You can simply separate multiple bug numbers by commas or "and" btw (other languages too) for the bot to parse them properly.
[17:38] <krytarik> Also, for anybody who is used to write "LP: #num", you don't need the colon here either.
[17:39] <bdmurray> krytarik: but you need LP: # for terminator!
[17:40] <krytarik> I'll be baaack!
[17:42] <krytarik> Fwiw, the '#' is entirely optional either.
[17:49] <vorlon> bdmurray: state of the art on checking syncs to -security is still to manually review the build log?
[17:50] -queuebot:#ubuntu-release- Unapproved: accepted xtables-addons [sync] (focal-security) [3.9-1ubuntu0.2~20.04.3]
[17:52] <bdmurray> vorlon: yes, although now that the PPA has been deleted...
[17:52] <vorlon> bdmurray: build logs seem to still be there
[17:53] <bdmurray> ack I found it
[17:54] -queuebot:#ubuntu-release- Unapproved: accepted broadcom-sta [sync] (focal-security) [<IP_ADDRESS>1-12ubuntu0.1]
[17:56] -queuebot:#ubuntu-release- Unapproved: accepted rtl8812au [sync] (focal-security) [<IP_ADDRESS>75.20140902+dfsg-0ubuntu13~20.04.3]
[17:57] -queuebot:#ubuntu-release- Unapproved: accepted bcmwl [sync] (focal-security) [<IP_ADDRESS>1+bdcom-0ubuntu7~20.04.3]
[19:09] <bdmurray> xnox: If you want to earn more good will you could tell me if bug 1914075 is fixed.
[19:10] <bdmurray> vorlon: bcmwl and rtl8812au still could use accepting for focal-security
[19:29] <bdmurray> Oh maybe I hadn't refreshed
[19:32] -queuebot:#ubuntu-release- New source: python-oslo.limit (impish-proposed/primary) [1.4.0-0ubuntu1]
[19:54] <bdmurray> xnox: Is there reason why evdi and lttng-modules are in the same PPA? I ask because sru-review will get the diff from the PPA description but bileto only adds the diff for one package so its only easy to review lttng-modules which is a big SAD.
[20:34] -queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (hirsute-proposed/main) [1:21.04.14 => 1:21.04.16] (core)
[20:43] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-release-upgrader [source] (hirsute-proposed) [1:21.04.15]
[21:03] -queuebot:#ubuntu-release- Unapproved: accepted evdi [sync] (hirsute-proposed) [1.9.1-1ubuntu4~21.04.1]
[21:12] -queuebot:#ubuntu-release- Unapproved: accepted evdi [sync] (focal-proposed) [1.9.1-1ubuntu4~20.04.1]
[21:55] -queuebot:#ubuntu-release- Unapproved: lttng-modules (focal-proposed/universe) [2.12.2-1ubuntu1~20.04.2 => 2.12.5-1ubuntu2~20.04.1] (kernel-dkms)
[22:24] <jawn-smith> There are automatic daily tests of Unleashed images running in Testflinger or something similar, correct?
[22:25] <vorlon> xnox, plars__: ^^ is this the case? cdimage.production doesn't show riscv in current-triggers, so we at least don't block image promotion on any tests
[22:25] <sarnold> "unleashed"? this book from 1996? :) https://books.google.com/books/about/Linux_Unleashed.html?id=IZ5kQgAACAAJ
[22:25] <vorlon> sarnold: aaaaahhhh
[22:26] <vorlon> "Readers will turn to this second edition for even more in-depth coverage of hot Linux topics -- PPP's" aaaaaaahhhhhhh
[22:27] <jawn-smith> If nothing is automatic, is there documentation someone can point me to for how I would test the daily images on the Unleashed?
[22:27] <vorlon> I'll stick with trumpet winsock thank you very much
[22:59] -queuebot:#ubuntu-release- Unapproved: rejected lttng-modules [source] (focal-proposed) [2.12.5-1ubuntu2~20.04.1]
[23:30] <bdmurray> blackboxsw: It seems like bug 1920836 is verified in that you are fine w/ its current state. Do you know anything about it being slow to launch though?
[23:36] <jawn-smith> okay bdmurray: u-boot for focal has been SRU verified
[23:38] <bdmurray> jawn-smith: cool
[23:47] -queuebot:#ubuntu-release- Unapproved: lttng-modules (focal-proposed/universe) [2.12.2-1ubuntu1~20.04.2 => 2.12.5-1ubuntu2~20.04.1] (kernel-dkms) (sync)
[23:53] -queuebot:#ubuntu-release- Unapproved: rejected lttng-modules [sync] (focal-proposed) [2.12.5-1ubuntu1~20.04.2]


[00:55] <nacc> tarpman: the debian package is done by upstream, afaict
[00:55] <nacc> but not sure, i've not looked at the changes
[00:56] <nacc> https://sourceforge.net/p/postfixadmin/code/HEAD/tree/branches/postfixadmin-2.3/debian/control
[00:56] <nacc> Belldandu: tarpman: --^
[00:56] <nacc> as explicit mariadb-* alternatives
[00:56] <nacc> i'd expect tht's what unstable will pick up when a new release happens
[00:57] <nacc> Belldandu: so you might just consider pinging the debian maintainers and asking if they'd package the new release
[03:42] <timmy> hi anyne around to help me with a apache problem?
[03:44] <sarnold> Guest98043: people come and go.. best to just ask and hope :)
[03:46] <Guest98043> hi..i just installed apache and php 7
[03:46] <Guest98043> everything seems to work fine when serviing html files
[03:46] <Guest98043> when i am serving a json file
[03:46] <Guest98043> i realised the content repeats
[03:47] <Guest98043> this is what my content looks like as rendered by the browser
 HTTP/1.0 200 OK Cache-Control: no-cache Content-Type:  application/json Date:          Wed, 08 Jun 2016 03:40:50 GMT <content>
[03:47] <Guest98043> so the content to be served is displayed..followed by HTTP/1.0 200 OK Cache-Control: no-cache Content-Type:  application/json Date:          Wed, 08 Jun 2016 03:40:50 GMT
[03:47] <Guest98043> then the content repeats again
[03:50] <sarnold> o_O
[05:12] <frickler> EmilienM: the error that you were seeing is the same that blocked the neutron gate yesterday. tempest update broke neutron-fwaas tests. fixed by https://review.openstack.org/326150
[06:13] <ronator> hi there. I have some ubuntu 16.04 servers with Kernel 4.4. Can I disable "mounting" of debugfs? On Ubuntu 14.04 with kernel 4.4 the debugs entry would go away after a reboot. But not with ubuntu 16.04. Any idea?
[06:13] <ronator> debugfs
[06:13] <sarnold> is it in your /etc/fstab?
[06:14] <ronator> noope
[06:14] <ronator> only disk-by-uuid and swap
[06:14] <ronator> example: mount
[06:14] <ronator> mqueue /dev/mqueue mqueue rw,relatime 0 0
[06:14] <ronator> debugfs /sys/kernel/debug debugfs rw,relatime 0 0
[06:15] <ronator> hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0
[06:15] <ronator> I don't have such entries with ubuntu 14.04
[06:15] <ronator> (this is not the full mount of course)
[06:15] <sarnold> well now
[06:15] <sarnold> I've got it mounted on two of my systems too.
[06:15] <sarnold> harupmh.
[06:16] <ronator> yes, and if you use icinga/nagios and check disks, you have to adjust stuff so that it won't conmplain about debugfs. SInce I won't use it actively I wonder if I can make it go away.
[06:17] <ronator> There was an issue request for this at icinga2 so they "fixed" it, but I just do not understand if I can just disable it and where ...
[06:17] <sarnold> ronator: aha. I think I've got it:  systemctl cat sys-kernel-debug.mount
[06:17] <ronator> let me see ...
[06:18] <ronator> wow, how did you come up with this so fast ...
[06:18] <sarnold> probably you could symlink /etc/systemd/system/sys-kernel-debug.mount to /dev/null to forbid it from happening. maybe systemctl mask can do that for you? maybe you'd need to stop the service first to get it to umount...
[06:18] <sarnold> ronator: just a hunch to check systemd when I didn't see it in my fstab either. I got lucky.
[06:18] <ronator> What about commenting out all below [Mount] ? Or is this not a true file?
[06:19] <sarnold> it is, but the version in /lib is owned by the package -- if you want ot make changes, they should go into a file in /etc/ instead
[06:19] <ronator> but yeah, awesome tip sarnold, thx I was searching the net and only fin ding boring descriptions of debugfs ;-)
[06:20] <sarnold> and indeed it feels like a mistake for it to be loaded by default..
[06:21] <ronator> fun fact is: I have ubuntu 14.04 with kernel 4.4. first bott, it shows debugfs. reboot and it is gone! with ubuntu 16.04 and kernel 4.4 it won't just disappear.
[06:21] <ronator> so thx for your hint, this way I can check the other systems that don't have it and compare them
[06:23] <sarnold> heh, I'm surprised debugfs shows up in the first boot of 4.4 on a 14.04 -- in this case it's the systemd unit that causes it to be mounted
[06:30] <ronator> yes, I saw it happening. and monitoring plugins where failing because no permissions on that "device" ...
[06:30] <ronator> -h
[06:31] <sarnold> it'd be worth poking upstreams on those plugins to try to get them to blacklist the in-kernel filesystems
[06:31] <sarnold> I mean, it's handy, it reported this issue :) but it's also probably more annoying than useful
[06:32] <ronator> true. and yes, icinga2 e.g. did change the defaults for check_disks especially for ubuntu 16.04 ;-) I wonder if this hapens with Debian 8 ...
[06:36] <ronator> and I also wonder why the heck ubuntu 16.04 ships lxcd by default ... this also leads to stuff like "Additional Info: DISK CRITICAL - /run/lxcfs/controllers/freezer is not accessible: No permission"
[06:37] <sarnold> ah, that's an easy one :) lxd is pretty neat and we wanted a low barrier to entry for folks to try it out :)
[06:38] <ronator> hrrhrr
[08:14] <Mc_uli> hi, wnat to setup some nodes with conjure-up. How many servers and storage do i need ? is there any kind of reference and explained where the e.g. cephs is installed or where the horizon dashboard goes?
[08:14] <Mc_uli> its for openstack
[08:27] <guzzlefry> Is there a recommended PPA for installing PHP7 on 14.04?
[08:55] <frickler> coreycb: regarding debian/patches/skip-ryu-tests.patch for neutron, there are two uses of ryu, the second one is as the reference implementation for the bgp-dragent. I'm a bit sceptical about dropping tests for that part completely, because we are actively using it in our deployments
[09:41] <rbasak> stokachu: see conjure-up question above please.
[09:41] <rbasak> Mc_uli: stokachu won't be in for a few hours at least, assuming he's not away.
[11:02] <Lunar_Lamp> w/in 1
[11:41] <coreycb> frickler, I've dropped the skip-ryu-tests.patch and no longer skip those tests in the newton b1 release
[11:42] <coreycb> frickler, build-depends no longer need to be in main so we were able to drop that patch
[11:42] <frickler> coreycb: ah, great, that answers my follow-up question already ;)
[11:43] <coreycb> frickler, :)
[12:29] <EmilienM> frickler: can you backport https://review.openstack.org/#/c/326150/ to Mitaka?
[12:36] <frickler> EmilienM: I can try, it probably would help if you can add a note to https://bugs.launchpad.net/neutron/+bug/1589521 stating how this affects you for Mitaka still
[12:40] <stokachu> rbasak: i've got this channel highlighted on conjure-up keywords, unfortunately i just got online
[12:51] <EmilienM> frickler: well, I have the same trace so I'm not sure what can I add
[12:57] <frickler> EmilienM: hmm, right, looks like it is a clean cherry-pick anyway, so lets wait what the neutrinos have to say on this (https://review.openstack.org/327068)
[12:57] <EmilienM> ok
[12:57] <EmilienM> in the meantime, I unblocked our CI in disabling fwaas on ubuntu
[13:01] <rbasak> stokachu: np. The guy asking left anyway.
[13:02] <stokachu> rbasak: is there like an info bot in here? so we could do like !conjure-up and it'll point them to askubuntu.com?
[13:03] <rbasak> !
[13:03] <rbasak> !info
[13:03] <rbasak> I thought there was once, but evidently not.
[13:04] <rbasak> stokachu: ah, you watch askubuntu.com for conjure-up stuff? I can just point people there then. That's probably easier even if no bot.
[13:04] <stokachu> rbasak: yea that would be awesome
[13:05] <rbasak> Cool, I'll do that - thanks.
[13:18] <frickler> !yum
[13:19] <frickler> its still there it seems ;)
[13:34] <Xin> howdy all
[13:46] <rbasak> caribou: around? I'm looking at your updated kexec-tools MP.
[13:47] <rbasak> caribou: I'm quite happy for you to just upload without a second review, but I'm going through as if you're not an uploader in order to try out the process.
[13:48] <rbasak> I don't have my old git repo around, and I'd like to diff from before your rebase to after your rebase, but I can't find the old branch. Usefully LP remembers, so it's apparently de45e23.
[13:50] <rbasak> caribou: would you mind tagging de45e23 as merge.v1 and pushing that please? I'm not sure this is actually documented anywhere but I intended that to be the process when asking for a re-review (or when you want to keep an older merge branch around before rebasing for any other reason) so the reviewer can get to both branches.
[13:56] <prince> hello
[13:56] <prince> This is for ubuntu servers aka vpses right?
[13:56] <teward> can anyone think of any valid sane reason that when someone issues a 'ping' from 14.04 server that it would send the ping out over both the MAC address on that NIC port, but also a MAC address that doesn't even exist on the system (but isn't a broadcast MAC address)?
[13:57] <teward> prince: this is a support channel for Ubuntu Server, not necessarily just VPSes
[13:57] <prince> teward: obviously not just vpses, but for vps support as well I assume?
[13:58] <teward> prince: again, it depends - from the Ubuntu OS on the VPS, we can assist, for the actual VPS itself, go to your provider
[13:58] <prince> Oh no, ubuntu server related.
[13:58] <teward> and in many cases what may be an "OS" issue is not, and is actually a provider issue
[13:58] <teward> prince: you're free to ask your question, but you can get pointed to elsewhere if it's not actually an Ubuntu issue
[13:58] <teward> that said, next time just ask your question
[13:58] <prince> God!
[13:58] <teward> rather than asking the premise of the channel
[13:58] <prince> Do you need me to leave or something?
[13:58] <teward> uh, what?
[13:58] <prince> I said it's ubuntu related
[13:58] <teward> prince: so ask your REAL QUESTION
[14:00] <coreycb> jamespage, ddellav: I just uploaded cinder b1 for real this time.  Looks like just heat and nova are stuck in proposed for the known MIRs we have.
[14:00] <jamespage> coreycb, \o/
[14:01] <Xin> hey guys, im looking for some kind of product to automate sync'ing the current dev server over to a backup server, starting the backup servers required, and to update my DNS record to have the backup as the primary server
[14:01] <Xin> and then signal me when the backup server has replicated globally type thing
[14:01] <Xin> aka its ok for me to take the production server offline
[14:01] <Xin> and do whatever
[14:01] <Xin> I figure something for this must exist
[14:01] <Xin> though its not terrible to do by hand
[14:01] <ddellav> coreycb awesome. I'm working on the monasclient mir now
[14:02] <coreycb> ddellav, ok cool
[14:02] <coreycb> jamespage, suppose we can start backporting all the clients/oslos and core packages that are missing from the newton UCA?
[14:03] <jamespage> coreycb, please do!
[14:03] <coreycb> jamespage, ok
[14:03] <jamespage> coreycb, branch PPA for newton is almost deployable
[14:03] <coreycb> jamespage, awesome
[14:03] <jamespage> coreycb, https://review.openstack.org/#/c/326597/ that needs landing and then we are all good
[14:04] <Xin> no ideas folks?
[14:04] <Xin> ;(
[14:04] <jamespage> Xin, you might need that question to bake for a bit more that 3 mins :-)
[14:04] <Xin> lol nah its what I do currently
[14:05] <Xin> If theres a better way im all ears!
[14:05] <coreycb> jamespage, why not use the package config for apache?
[14:05] <jamespage> coreycb, well its a bit of a nuance of the charm
[14:05] <jamespage> having two files named kesytone.conf confused the crap out of the ostemplategenerator
[14:05] <coreycb> jamespage, ok
[14:15] <teward> prince: i didn't say you couldn't ask about your issue, by the way - did you still want to ask your question?
[14:26] <prince> teward: It's fine besides feeling offended, I'll probably ask later.
[14:27] <teward> well, sorry, it wasn't *meant* that way
[14:35] <jscar> HI, ubuntu newbie question.... how can I tell if apparmor utilties is installed?
[14:37] <jscar> hello anyone?
[14:38] <nacc> jscar: do you mean apparmor itself or some specific tooling?
[14:38] <nacc> jscar: for apparmor itself `apt-cache policy apparmor`
[14:40] <jscar> I'm trying to put mysqld into complain mode but aa-complain returns 'command not found' so I think apparmor utilties might not be installed but I want to know how to check
[14:40] <jscar> apparmor itself is running
[14:41] <\9> find out what the package name is, using apt-cache search
[14:41] <nacc> apt-cache search aa-complain
[14:41] <\9> and then use apt-cache policy, to find out whether it's installed or not
[14:41] <nacc> apt-cache policy <pkgname>
[14:41] <nacc> \9: :)
[14:43] <jscar> thank you - so much learning! :)
[14:45] <jscar> apt-cache policy apparmor-utils returns Installed: (none)
[14:45] <jscar> Guess it's not installed :)
[14:46] <nacc> yep ;)
[14:46] <jscar> many thanks for the pointers
[14:57] <coreycb> ddellav, I think we both have package ci duties today so just to let you know I'm working on cinder
[14:57] <ddellav> coreycb ok. I actually put myself down for tuesday and friday but i'll do one tandem with you a couple times
[14:58] <coreycb> ddellav, oh ok I thought jamespage had tues/thurs.  fix up the table then if you can.
[14:58] <ddellav> coreycb when i looked only monday and thursday were selected by you guys heh
[14:59] <coreycb> ddellav, oh package ci, not bugs
[14:59] <ddellav> coreycb ahhhh, yes, ok. I haven't looked at CI yet
[15:29] <John[Lisbeth]> Term mode is eh
[15:29] <John[Lisbeth]> but maybe I am just butthurt because I always forget to use c-c c-k and c-c c-j
[15:29] <John[Lisbeth]> I also feel like those two keybinds could be a toggle
[15:29] <John[Lisbeth]> so just one keybind
[15:30] <John[Lisbeth]> I mainly run into trouble when I do fancy rendering things like resizing terminals
[15:30] <John[Lisbeth]> but every now and then a curses application will just bug out
[15:30] <John[Lisbeth]> runs x smoothly
[15:31] <John[Lisbeth]> oops
[15:31] <John[Lisbeth]> wrong channel
[15:38] <jackdpeterson> Odd_Bloke -- following up today on https://bugs.launchpad.net/cloud-images/+bug/1569237  Solution is to get the base image to have the default user be vagrant and not ubuntu.
[15:39] <jackdpeterson> I was able to connect after a while -- timing was a factor; however, that's still broken from the vagrant workflow because the 16.04 vagrant box image doesn't follow vagrant conventions. I referenced the docs in my latest comment.
[15:43] <Odd_Bloke> jackdpeterson: o/
[15:44] <jackdpeterson> 14.04, on the other hand does.
[15:47] <jackdpeterson> UID/GID for vagrant:vagrant would be 1000/1000, respectively.
[15:47] <Odd_Bloke> jackdpeterson: Right; Vagrant does allow boxes to configure what username they use (which is why `vagrant ssh` works), and using the `ubuntu` user is consistent with other Ubuntu images.
[15:47] <Odd_Bloke> jackdpeterson: So is it just that people everywhere don't know this and assume the vagrant user will exist?
[15:49] <jackdpeterson> That's correct -- the assumption is that the vagrant user always exists and is the 'default'. Then people stack on provisioners to sync up code between their host machine's FS and internal VM configuration. this assumption is generally safe since that is the convention.
[15:50] <Odd_Bloke> OK, fair enough.
[15:53] <jackdpeterson> and that uid/gid is based on my pulling up the 14.04 image and comparing.
[15:54] <Odd_Bloke> jackdpeterson: I've updated the bug description, does that look reasonable to you?
[15:55] <jackdpeterson> Yep, that's very close to what my title was on the other cross-referenced bug was -- so I'm happy with the accuracy of that :-)
[15:55] <Odd_Bloke> jackdpeterson: Cool; now did you mention that you were interested in fixing it? ^_^
[15:55] <jackdpeterson> I added some confusion with the SSH-related nonsense (my apologies)
[15:55] <jackdpeterson> Yeah, If I can, I'm more than happy to!
[15:57] <Odd_Bloke> jackdpeterson: So the relevant file is http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-cpc/hooks/042-vagrant.binary
[15:57] <Odd_Bloke> jackdpeterson: It's pretty crufty, unfortunately, but the way it works is basically to set up a cloud-init metadata source which is used at box boot to do configuration.
[15:59] <Odd_Bloke> jackdpeterson: So I would suggest pulling down the latest yakkety Vagrant box (http://cloud-images.ubuntu.com/yakkety/current/yakkety-server-cloudimg-amd64-vagrant.box), unpacking that, modifying the contents and repacking it until you get something that works.
[15:59] <Odd_Bloke> jackdpeterson: And then work out what will need to change in that hook.
[16:00] <jackdpeterson> Sure, then reply with a Github Gist?
[16:01] <Odd_Bloke> jackdpeterson: Sure. :)
[17:55] <coreycb> ddellav, cinder should be fixed up for newton CI, looking at neutron now
[18:27] <jackdpeterson> Odd_Bloke -- I have a gist -- but to be honest, I'm not sure if these changes will __work__ I'm not seeing documentation on how to spin up an environment for creating images from those hooks. https://gist.github.com/jackdpeterson/64c1f8a517087e07f7e40a1ace76ada0  Lines 70-72, and 115 are the changes
[18:28] <jackdpeterson> and when I manually execute these scripts it complains about missing files (and stepping through this and manually fixing the references to other paths) is tedious and feels wrong
[18:29] <jackdpeterson> oh, and the password doesn't need to be random ... it can just be 'vagrant'
[18:51] <coreycb> ddellav, neutron should be fixed up for CI.  I'll leave designate liberty and nova newton for you.
[18:52] <ddellav> coreycb: ok, sounds good.
[21:39] <blizzow> I just wanted to come in here and reiterate that it is a moronic idea to install lxc and lxcfs by default in the server distribution and whoever is responsible for that decision should have their hard disks formatted. May an rm -rf /* come upon their root session.
[21:47] <jrwren> when an upstart service runs and writes output, its stdout and stderr are written to /var/log/upstart/NAMEOFSERVICE.log   where does stdout and stderr go in the systemd case?
[21:55] <rharper> jrwren: depends on the unit file but typically, systemctl status -l $service.service shows output from the daemon
[21:56] <jrwren> rharper: thanks. I dug some more and found that what I expecte to be on stderr wasn't there because starting the process wasn't getting that far.
[21:56] <rharper> ah
[23:54] <caliculk> What does everyone here use for a combination of DCIM and Asset/Inventory Management for their hardware devices in a server room?


[20:10] -SwissBot:#xubuntu-devel- ::xubuntu-seed:: Move ZFS from core to live. @ http://git.launchpad.net/~xubuntu-dev/ubuntu-seeds/+git/xubuntu/commit/?id=73dc1d4c754d58c03acf8f5f6734206219a10cb5 (by Adam Conrad)
[20:12] <bluesabre> Cool
[20:47] <ochosi> heya bluesabre
[20:48] <bluesabre> Hey ochosi
[20:48] <ochosi> way to go sneaking in zfs support last minute :)
[20:51] <bluesabre> The flavors all figured it out in the last week, just tagging along
[20:51] <ochosi> sure, still, nice of you to take the time
[20:51] <ochosi> i know you're busy
[20:54] <bluesabre> Yeah, largely getting back in the Linux groove, just had a few more things the last few days
[20:55] <bluesabre> Planning a meeting Monday around my time
[20:55] <bluesabre> Can you stay up late? :)
[20:56] <ochosi> uh, monday may be the only bad night...
[20:56] <ochosi> have an interview on tuesday
[20:58] <ochosi> even today/now would be better :)
[20:58] <ochosi> Unit193 - you around? :)
[21:08] <bluesabre> :)
[21:09] <ochosi> dang
[21:09] <ochosi> that usually works
[21:10] <bluesabre> :D
[21:13] <ochosi> bluesabre: got any recommendations for a good screen capturing app?
[21:14] <bluesabre> ochosi: kazam is good for video
[21:15] <bluesabre> ochosi: Peek captures an animated gif
[21:16] <ochosi> that latter one i tried, but it segfaults (doublefree) when it tries to save the gif
[21:16] <ochosi> an animated gif would have been ideal
[21:16] <bluesabre> bummer
[21:18] <bluesabre> I think there's a few fullscreen recording extensions for chrome
[21:19] <ochosi> i'll see if i can get any of the others to work, maybe kazaam
[21:19] <ochosi> simplescreenrecorder oddly also failed
[21:19] <ochosi> "something went wrong during the initialization"
[21:19] <ochosi> quite the error message :)
[21:20] <bluesabre> That sounds like a gst error
[21:20] <ochosi> possible, yeah
[21:20] <ochosi> i wanted to set up everything from scratch with 19.10 anyway
[21:21] <ochosi> i've produced quite the franken-system here, with lots of xfce compiled from git master while working on 4.14
[21:21] <bluesabre> I just got a new computer and have been setting it up today with 19.10
[21:21] <ochosi> noice
[21:23] <ochosi> haha, so kazaam worked
[21:24] <ochosi> i mean it produced a 150mb avi for a few secs, but who cares
[21:24] <ochosi> but the cool part is: it included part of the red rectangle it uses to show where it's recording, just somewhere in the middle of the recording :'D
[21:26] <ochosi> and the video capturing doesn't seem to be very smooth
[21:32] <bluesabre> :D
[21:53] <Unit193> ochosi: Howdy.
[21:53] <ochosi> oh there you go ::)
[21:56] <ochosi> bluesabre: so, wanna do it now..?
[21:57] <bluesabre> oh, I've got time for a quick one, sure :)
[21:58] <bluesabre> #startmeeting Xubuntu Community Meeting
[21:58] <meetingology> Meeting started Sat Oct 12 21:58:35 2019 UTC.  The chair is bluesabre. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[21:58] <meetingology> Available commands: action commands idea info link nick
[21:58] <bluesabre> Surprise!
[21:58] <bluesabre> !team | anybody around for a quick meeting?
[22:00] <bluesabre> #chair ochosi
[22:00] <meetingology> Current chairs: bluesabre ochosi
[22:00] <bluesabre> #chair Unit193
[22:00] <meetingology> Current chairs: Unit193 bluesabre ochosi
[22:01] <ochosi> new motto: "better to have an impromptu meeting with a few people than no meetings at all"
[22:01] <bluesabre> :D
[22:01] <bluesabre> Works for me
[22:01] <bluesabre> #topic Open action items
[22:01] <bluesabre> #done bluesabre to replace light-locker with xfce4-screensaver in eoan
[22:01] <ochosi> noice
[22:01] <bluesabre> #done bluesabre to mail the mailing list to discuss additional keyboard shortcuts
[22:02] <bluesabre> #done bluesabre to mail the team regarding the GTK styles in GIMP (noting GTK used to be default)
[22:02] <bluesabre> #done bluesabre to email a team vote for color emoji support in Xubuntu
[22:02] <bluesabre> never got to it: bluesabre to work on improving "starting point" documentation for dev/QA
[22:02] <bluesabre> never got to it: bluesabre to reach out to other flavors to improve shared documentation
[22:03] <ochosi> i guess dev docs could be an upstream topic
[22:03] <ochosi> at least i wouldn't duplicate the effort
[22:03] <ochosi> and upstream could really use some time spent on that, and then we could simply link to it
[22:03] <bluesabre> Yeah
[22:03] <bluesabre> GIMP: GTK theme, got +4 / -0
[22:04] <bluesabre> Color emoji: +3 / -1
[22:05] <bluesabre> Keyboard shortcuts: Added Super+L for locking, Super+D for show desktop
[22:05] <bluesabre> #topic Updates and announcements
[22:06] <bluesabre> ochosi: Definitely in favor for upstream docs
[22:06] <ochosi> i guess we got both 4.14 patch releases (settings, panel) into eoan?
[22:06] <bluesabre> ochosi: yeah, pretty sure
[22:06] <bluesabre> !info xfce4-settings eoan
[22:06] <ochosi> that's pretty neat
[22:06] <bluesabre> !info xfce4-panel eoan
[22:07] <ochosi> i think i was the only one doing patch releases so far
[22:07] <ochosi> so that should be it
[22:07] <bluesabre> #info Xfce 4.14 released, available in 19.10
[22:07] <bluesabre> #info Root ZFS installation now available with the 19.10 daily image
[22:08] <bluesabre> I don't think I have any other announcements
[22:08] <ochosi> me neither
[22:08] <ochosi> i guess we won't push any further patch releases of 4.14 into eoan
[22:09] <bluesabre> #info 19.10 to be released this coming Thursday (10/17), let's test it this week!
[22:09] <bluesabre> Yeah, at least without them being SRU
[22:09] <ochosi> unless they fix something critical which has yet to be discovered (4.14 is going suprisingly smooth in terms of critical bug reports)
[22:10] <bluesabre> Indeed, we did a good job with our years of slower-pace development and 6 months of rapid development ;)
[22:10] <ochosi> haha
[22:10] <bluesabre> So with no other announcements...
[22:10] <ochosi> that may be the new methodology to supersede "agile" :D
[22:10] <bluesabre> #topic Discussion
[22:11] <bluesabre> It's been a pretty quiet development cycle on the Xubuntu side of things
[22:11] <ochosi> yeah, as long as you ignore upstream efforts
[22:11] <ochosi> my time was pretty bound by that
[22:12] <bluesabre> Same, was pretty on it with Xfce up until September, then I was on personal stuff for a month
[22:13] <bluesabre> knome: for the record, I am a fan of the new wallpaper (as usual). Dig the colors!
[22:14] <bluesabre> I think we'll need to dig in and do a good round of planning in the next couple weeks, 20.04 is an LTS
[22:14] <ochosi> indeed
[22:14] <ochosi> although tbh i wouldn't change much about the 4.14 stuff
[22:14] <bluesabre> There's probably a few upstream changes we should bring down, like the pathbar
[22:14] <ochosi> pathbar?
[22:15] <bluesabre> in thunar
[22:15] <bluesabre> Instead of text entry
[22:16] <ochosi> oh dear
[22:16] <bluesabre> Not sure what other goodies there were yet :D
[22:16] <ochosi> i thought there was only that one now
[22:16] <ochosi> doesn't make much sense to me to keep both around tbh
[22:17] <bluesabre> Yeah
[22:17] <bluesabre> This is the default, https://imgur.com/itmSy7N.png
[22:17] <ochosi> meh
[22:17] <ochosi> ok, yeah, we should for sure switch
[22:18] <bluesabre> Otherwise, probably lots of papercut bugs to fix
[22:18] <ochosi> yeah
[22:18] <ochosi> tbh we could review some apps again
[22:19] <ochosi> i'd still like to get rid of gnome software for the fact that it keeps running in the background
[22:19] <ochosi> but i guess there is still no alternative to it
[22:20] <bluesabre> It gets a little bit better each cycle, but yeah... it's still not particularly great (and not up to where software-center was)
[22:20] <Unit193> Still can't really find things, isn't so good in general.
[22:21] <ochosi> yeah, i also have to agree with that
[22:21] <ochosi> i've just gotten better at using apt since then
[22:21] <bluesabre> :D
[22:21] <Unit193> Oh, I don't have it installed, I just get to see "I removed 'mail' in software center and now Xubuntu doesn't start, what happened?" in #xubuntu.
[22:22] <ochosi> lol
[22:22] <bluesabre> That should be fixed now, but not for some of the active releases
[22:23] <bluesabre> Exo 0.12.3
[22:23] <bluesabre> !info exo-utils bionic
[22:23] <bluesabre> !info exo-utils cosmic
[22:23] <bluesabre> !info exo-utils disco
[22:23] <bluesabre> well
[22:23] <bluesabre> So, disco users are happy
[22:24] <ochosi> disco dancers too
[22:25] <bluesabre> So, anything more to discuss for now?
[22:25] <ochosi> upstream we don't care enough about application metadata, that's also an area to improve...
[22:25] <ochosi> but not much we can do downstream imo
[22:25] <ochosi> no, i think for eoan we're fine
[22:25] <ochosi> we should probably schedule a meeting for e+1 soonish
[22:26] <bluesabre> Yeah, was thinking about getting one set up the following week
[22:26] <bluesabre> So it begins...
[22:26] <bluesabre> > Builds: Xubuntu Desktop amd64 [Eoan Final] (20191012) has been added
[22:27] <ochosi> i'll be afk the last week of october
[22:27] <ochosi> just fyi
[22:27] <bluesabre> alrighty
[22:28] <bluesabre> #topic Schedule next meeting
[22:28] <bluesabre> ochosi: want to take it, or should I just run with it :)
[22:29] <ochosi> i
[22:29] <ochosi> i'd say run with it
[22:29] <ochosi> since i almost scheduled the meeting tonight ;)
[22:29] <bluesabre> lol
[22:29] -SwissBot:#xubuntu-devel- ATTN: Xubuntu Core 19.10 - amd64 - amd64 built.
[22:29] <bluesabre> #action bluesabre to schedule next meeting
[22:29] <meetingology> ACTION: bluesabre to schedule next meeting
[22:29] <bluesabre> #endmeeting
[22:29] <meetingology> Meeting ended Sat Oct 12 22:29:41 2019 UTC.
[22:29] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/xubuntu-devel/2019/xubuntu-devel.2019-10-12-21.58.moin.txt
[22:29] <ochosi> domo arigato
[22:29] <bluesabre> thanks ochosi Unit193
[22:30] <Unit193> Heh, I was hardly here. \o/
[22:31] <ochosi> yeah, but what would we have done without you?
[22:31] <bluesabre> Not had a meeting
[22:31] <bluesabre> ;)
[22:33] <ochosi> indeed
[22:34] <Unit193> Dang, that zfs stuff bumped the size by 40M.
[22:34] <ochosi> ouch
[22:37] <Unit193> 'Core' is now 800M
[22:40] <Unit193> As compared to Disco, at 736M.