[02:31] <riggs498> I have skolelinux installed on the main server. is there a way I can get edubuntu to see that server with openldap? none of the stations use thinclient to connect to the server. The workstation is configure and the lins back to the server.
[02:42] <riggs498> Does Edubuntu use ldap?
[03:14] <riggs498> Is there anyone that can help me?
[17:17] <Ahmuck> is musescore part of edubuntu?
[20:01] <Lns> Hi everyone
[20:02] <Lns> eww, chanserv welcome message is... intimidating. =p
[20:08] <alkisg> Why?
[20:08] <alkisg> Btw, is there a meeting today?
[20:09] <alkisg> highvoltage: ^^?
[20:12] <Lns> heh
[20:12] <Lns> alkisg: have you seen UNR / netbook-launcher UI?
[20:13] <alkisg> I've seen it, and I quickly removed it and installed the normal edition :D
[20:13] <Lns> alkisg: (re: welcome msg..just like seeing cameras in a department store..makes you feel...watched lol)
[20:13] <Lns> alkisg: haha!
[20:13] <Lns> But wouldn't you agree it could be a very simplified UI for children?
[20:13] <alkisg> I don't know, it makes me think that it's not a PC, it's just a mobile phone
[20:13] <dgroos> Hey! just got back--meeting right?
[20:14] <alkisg> Nope. My daughter, 9 years old then, didn't like it at all.
[20:14] <alkisg> She preferred the normal UI. I think that UI is for 60 y.o. people, not for kids.
[20:14] <Lns> alkisg: ok but its probably safe to say your daughter, at age 9, was also learning C++.. ;)
[20:14] <alkisg> Heh :)
[20:14] <Lns> dgroos: we haven't heard from highvoltage yet
[20:14] <alkisg> Nah, I try to keep my kids away from PCs... I'm not doing a very good job, but still, not C++. Just python :P
[20:15] <Lns> =p
[20:15] <Lns> I dunno, I think it's a beautiful way to present applications to kids/teachers. It's very simple, no menu-surfing, if it were modularized away from UNR I could see thin clients using it in schools (at least elementary schools)
[20:15] <Lns> For those who take 10 minutes to make sure their students are logging on with the right un/pw
[20:16] <Lns> it's hard to have them all navigate through menus and stuff..also, the "Favorites" section woudl be great for commonly used websites/applications
[20:16] <Lns> or directories
[20:16] <alkisg> Kids nowadays are very used to the standard windows interface, even from small ages. This new interface may be OK for small touch screens, but I wouldn't prefer it with a mouse.
[20:17] <alkisg> Directories are difficult, ok, but is that addressed by UNR?
[20:17] <alkisg> E.g. tuxpaint addresses this, it doesn't offer a standard save dialog
[20:19] <Lns> alkisg: the Favorites section is just like the other XDG menus (comes up at top) and is customizable for FF bookmarks, filesystem locations, and other stuff
[20:19] <Lns> And you're right about touch screens - imagine a thin client touch screen LCD.
[20:20] <Lns> Touch is "where things are going" and I think this kind of interface is going to integrate itself into desktops as well as notebooks/phones
[20:20] <alkisg> Well, gnome already has a favorites menu for locations. It works better than windows at that stage when we try to teach them about organizing their work.
[20:20] <alkisg> Touch is handy for *some* stuff. I wouldn't help *me* in my work though.
[20:20] <Lns> sure =) but "better than windows" isn't our primary goal is it?
[20:20] <Lns> alkisg: I'm not talking about you, i'm talking about young children ;)
[20:21] <alkisg> Sure. But young children might also be doing some of the things I do.
[20:21] <alkisg> I'm chatting now. My kids are also chatting in facebook. Why would they need a touch screen for that?
[20:21] <Lns> I dunno, I just excited at the potential of that type of interface. A lot of feedback I got from teachers was simply making the UI easier for kids to navigate
[20:22] <Lns> the apps would remain the same
[20:22] <Lns> obviously
[20:22] <alkisg> A touch screen would be nice to have for some activities, especially in very early ages (card matching etc).
[20:22] <Lns> alkisg: i'm simply talking about navigating the GUI, not having touch integrated into all the apps
[20:22] <Lns> mouse/touch combo
[20:22] <alkisg> Or in some games. Or in a restaurant. But I don't think it would affect most of my lessons...
[20:23] <alkisg> If you have to leave the mouse to touch the screen and vice versa, then this is a failed method
[20:23] <Lns> meh :)
[20:23] <Lns> I don't agree with that
[20:23] <Lns> they are both useful, just like you said, it's handy for *some* stuff
[20:24] <alkisg> It takes half a second to leave the mouse and touch the screen. It takes much less time to just move the mouse there.
[20:24] <Lns> and having the choice of using touch or the mouse would provide the best choice
[20:24] <alkisg> So, once I get in a touch screen enabled app, I shouldn't have to return to my mouse.
[20:24] <alkisg> I should be only touching the screen for as long as I use this app.
[20:24] <Lns> sure
[20:25] <Lns> would make sense for countless games for youngsters
[20:25] <alkisg> (except for some casual keyboard typing of course)
[20:25] <alkisg> Yes, games are a very good candidate. But as a teacher I don't care much about them ;)
[20:25] <Lns> my 21 month old son already tries to touch our LCD TV to do stuff on it...
[20:26] <Lns> it's a natural integration into technology - normal physical handling of real objects and touching a screen to manipulate things
[20:26] <Lns> but wouldn't you think that, as a teacher, you want the easiest method for launching and navigating an OS for kids?
[20:26] <alkisg> Sure. It'll be very good when apps are ready for that.
[20:27] <alkisg> But if OS navigation is touch-enabled, and the apps themselves aren't, I don't think it helps much
[20:28] <Lns> ok, but if you had the *choice* of using touch or not (obviously not many ppl have touch screen LCDs attached to their desktops..yet).. the end result in either case would be an easy interface to launch applications and navigate files
[20:29] <Lns> not only for kids, but if it were made to be easily customizable from the ground up, for many users, by teachers/etc (customizable themes, icons, categories).. that could seriously be a 'killer feature' of Edubuntu
[20:29] <Lns> it looks different than ubuntu and therefore people distinguish it more clearly and see a use case
[20:29] <alkisg> I believe the end result would be the same as working on a nintendo ds (except that our hands would tire more easily, as it's difficult to reach the screen all the time)
[20:30] <alkisg> So ok, it's a feature, but I don't see it as a big evolution for PCs
[20:30] <Lns> you don't think PCs are going to become more touch friendly in the future?
[20:31] <Lns> ok take this hypothetical example...organizing your photo collection by dragging/dropping. Much easier with 2 fingers!
[20:31] <alkisg> I think the capability will be there, but people will only use it in selected apps.
[20:31] <Lns> of course.
[20:31] <alkisg> The same as the new 3D screens.
[20:32] <Lns> I dunno, I feel compelled to take this UI and modularize it so it can be installed in not-just-netbook-OSes
[20:32] <dgroos> Have you seen the Croquet project?  It would provide a fascinating interface for both local files and external systems.
[20:32] <alkisg> I do hope I get to see a keyboard-less and mouse-less PC, where I'll be able to talk to it to do stuff. Until then, I don't think I'll switch my keyboard/mouse easily... :)
[20:33] <Lns> alkisg: not a 0 or 1 situation ;)
[20:33] <Lns> people said the same thing when the mouse was invented
[20:33] <Lns> and the car
[20:33] <Lns> "Get a horse!"
[20:33] <alkisg> The mouse has 2 dimentions. The keyboard doesn't.
[20:33] <alkisg> A touch screen has 2 dimentions. We already have that.
[20:34] <dgroos> it is kind of like a 3-d concept mapping software but is a way to navigate in a shared space across the internet with others.
[20:34] <dgroos> Check this out: http://en.wikipedia.org/wiki/Croquet_Project
[20:34] <Lns> dgroos: wasn't that some Java-based Sun project?
[20:34] <dgroos> That would provide a real reason to enable another way of interfacing with the computer.
[20:35] <dgroos> No, it is squeek-based and was created by the some big open source names--check towards the bottom of the wikipedia page.
[20:39] <dgroos> I haven't paid it much attention in the last few years as I've been busy learning other stuff--looks like it has come of age and is now part of the open Cobalt project: http://en.wikipedia.org/wiki/Open_Cobalt
[20:41] <dgroos> I really think that wisely scaffolded collaboration tools are going to be enabling a big change in what happens in science classes (and I'd guess in other disciplines) as well.
[20:41] <Lns> dgroos: that seems like a very radical change in how you interfact
[20:41] <Lns> interact*
[20:43] <dgroos> Yes, imagine going through some object on the screen and entering another view that is shared by another group of people--in real time and in 3-d.  That would be an interesting concept of chat room!
[20:47] <dgroos> Lns: Using an interface like this would provide new utility for a touch screen, I'd say.
[20:48] <Lns> sure
[20:48] <Lns> dgroos: what is this "object" you would speak of, though, that people would be interacting with? What's the benefit ?
[20:52] <dgroos> As I understand, one stands in a 3-d space, represented by an avatar.  There are 'objects' around one--like windows or screens-- these can be 2-d objects such as the example of the google analytics screen shown on the cobalt page.
[20:54] <dgroos> They can also be portals into another virtual world.  You can walk up to that object/portal, look through it into the other world, see others/object in that world.
[20:55] <dgroos> you can go through the object, enter the other world in a 3-d way and this could be another collaborative space with shared objects eg jpgs, videos, text etc.
[20:56] <Lns> hmmm..sounds like something that would probably catch on in another 5-10 years :)
[20:56] <dgroos> right :) another reason why I haven't been following it too closely.
[20:57] <Lns> I think that this type of interface would be more of what alkisg is talking about regarding requiring applications that support the type of interaction it provides
[20:57] <dgroos> But, it would make an awesome interface for concept mapping--being able to move about (such as swim) through a shared concept map would be inspiring!
[20:57] <Lns> seems kind of pointless to have a 3D space with a bunch of 2D apps
[20:58] <Lns> but i do see a lot of potential regarding apps that support that kind of stuff
[20:58] <Lns> and their integration with the OS UI
[20:58] <Lns> would make OS/applications much more integrated with each other
[20:59] <dgroos> Yes, it would be an interesting way to interact with taxonomies of knowledge.
[21:06] <Lns> so...no meeting i guess =)


[01:20] <xnox> infinity, ^ hopefully i did everything we have discussed =)
[02:41] <darkxst> can someone reject the above accountsservice, patch was incomplete
[02:43] <darkxst> infinity, ^
[02:44] <slangasek> darkxst: done
[02:45] <darkxst> slangasek, thanks
[08:32] <jamespage> the ceph upload ^^ I just made is the first RC for the Jewel stable release we're targetting for Xenial
[08:33] <jamespage> its had some good testing in PPA prior to upload...
[08:33] <jamespage> FFe bug is referenced in the changelog, but not closed...
[09:16] <jamespage> pitti, are you ok with me leaving the FFe bug open for ceph? I'd rather close that with the final release upload rather than the RC's
[09:16] <pitti> jamespage: ah, sure
[09:16] <jamespage> pitti, awesome
[10:10] <pitti> tjaalton: ^ seems the dep-wait resolved :)
[10:15] <apw> could a releasy birtney hint the tests for spl-linux <IP_ADDRESS>-0ubuntu1 on amd64 and ppc64el as "ok" as they have fallen foul of the kernel catching up with them before they could escape -proposed
[10:17] <infinity> apw: I'm reading that as "I'd love to fix the tests, Adam, just ask..."
[10:21] <apw> i would love to fix them, and i will, indeed
[10:30] <tjaalton> pitti: whee :)
[10:56] <doko> tjaalton, pitti: not yet: https://bugs.launchpad.net/ubuntu/+source/vdpau-video/+bug/1075783 https://bugs.launchpad.net/ubuntu/+source/intel-vaapi-driver/+bug/1075780
[10:56] <ubot5`> Launchpad bug 1075783 in vdpau-video (Ubuntu) "[MIR] vdpau-video" [Wishlist,Confirmed]
[10:56] <ubot5`> Launchpad bug 1075780 in intel-vaapi-driver (Ubuntu) "[MIR] intel-vaapi-driver" [Wishlist,Confirmed]
[10:57] <tjaalton> doko: yes, I'm asking for the new upload so it could be synced..
[10:57] <tjaalton> oh
[10:57] <tjaalton> well
[10:57] <tjaalton> I thought you meant the Brekas
[10:57] <tjaalton> -ks
[11:02] <tjaalton> doko: I'm not sure if those need to go in main for mesa?
[11:03] <doko> tjaalton, well, libva depends on those
[11:03] <tjaalton> oh
[11:03] <tjaalton> ah right
[11:03] <tjaalton> va-driver-all
[11:04] <tjaalton> sorry, overlooked this one :/
[11:04] <doko> tjaalton, I'm afk for a while. would be nice if you could look what to do
[11:04] <tjaalton> would s/Depends/Recommends/ fix it?
[11:04] <tjaalton> for now
[11:04] <doko> tjaalton, iirc, not good enough, but I can't remember
[11:05] <tjaalton> ok
[11:05] <tjaalton> I'll have a look
[11:22] <tjaalton> doko: quick review done on both
[12:10] <flexiondotorg> cyphermox, Can you help with this please?
[12:10] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-meta/+bug/1565709
[12:10] <ubot5`> Launchpad bug 1565709 in ubuntu-mate-meta (Ubuntu) "FFe: Please updated ubuntu-mate-meta to add ubuntu-snappy-cli" [Undecided,Confirmed]
[12:10] <flexiondotorg> I've got another ubuntu-mate-meta update coming to fix an a11y issue and the above will need processing first.
[12:11] <infinity> I feel like ubuntu-snappy-cli probably belongs in desktop-common, but we'd need all the flavours to agree that's sane.
[12:12] <infinity> flexiondotorg: FWIW, it's only a Recommends on ubuntu-desktop, and you made it a Depends for yours.    Ick.
[12:13] <flexiondotorg> infinity, Yes, there are good reasons for this.
[12:13] <flexiondotorg> I tried unpicking it for 16.04, but ran out of time.
[12:13] <flexiondotorg> It is on the work sheet for 16.10.
[12:13]  * infinity nods.
[12:13] <infinity> Running the update.
[12:14] <flexiondotorg> I've been discussing the snappy stuff with willcooke. Ubuntu MATE are fully supporting the initiative.
[12:14] <infinity> Well, given the way some leaf packages might go, I suspect we could reach a point where flavours kinda won't have a choice unless they want to maintain their own web browser or whatever.
[12:15] <infinity> But that didn't seem to happen for 16.04, so I guess people are safe for now.
[12:15] <flexiondotorg> infinity, Thanks for processing the update.
[12:16] <doko> infinity, are you still planning a glibc upload? want to do the cross-toolchain-base upload after that
[12:16] <infinity> doko: I'll be doing one or two more before release, I suspect, but I have no urgent reason to do one right now.
[12:16] <infinity> doko: Unless you know of an urgent reason. :P
[12:17] <doko> ok, then delaying ctb
[12:17] <infinity> doko: Is ctb current right now?
[12:17] <doko> somehow, ftbfs because of integrated patches
[12:18] <infinity> Oh, it's off by one revision.  Close enough.  We'll sort it for ubuntu3, which is definitely happening.
[12:18] <infinity> A few things in debian git I want to pick up, and a couple of small bugs to fix in the Ubuntu bits.
[12:18] <doko> and there's still the britney issue, not allowing gcc-5-cross-ports to migrate
[12:19] <infinity> ... it doesn't even show up in excuses.
[12:19] <flexiondotorg> infinity, I see you're in the calendar to pilot today.
[12:20] <infinity> Was it causing britney to crash or something?
[12:20] <infinity> flexiondotorg: Yeah.
[12:20] <flexiondotorg> Have you had your stint yet?
[12:20] <infinity> flexiondotorg: The long discussion with darkxst in #-devel was sort of piloty, though I only just not signed in. :P
[12:20] <doko> infinity, I don't know. if britney would crash, then we wouldn't see any migrations, I assume
[12:21]  * flexiondotorg goes to #-devel
[12:22] <infinity> doko: It doesn't seem to be lying about the Impossible dependency.
[12:23] <infinity> Or... Yes it is?
[12:23] <infinity> WAT.
[12:23] <doko> infinity, yes but it doesn't list gcc-5-cross-ports as being ready for migration either
[12:23] <infinity> I'll look at this a bit latrer.
[13:21] <teward> infinity: any chance I can add an nginx FFe review to your list of things for today?  https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1566392  If not, i'll poke again later this week, but this should probably get in before FinalFreeze
[13:22] <ubot5`> Launchpad bug 1566392 in nginx (Ubuntu) "[FFe Needed] Update nginx to 1.9.14" [Wishlist,New]
[13:25] <infinity> teward: Changelog looks sane to me, go for it.
[13:25] <teward> infinity: thank you kindly, upload will be done as soon as the apt-get upgrade that Landscape pushed to this system finishes heh
[13:27] <teward> infinity: just finished the upload, thanks again!
[13:33] <infinity> teward: Oh, do me a favour.  Once this builds, install the archive binaries, set up an SSL site, and double-check it seems to DTRT.
[13:33] <teward> infinity: coffee hasn't been fully metabolized, DTRT = ?
[13:33] <infinity> teward: On the off chance that the "OpenSSL 1.1.0 compat" commit accidentally broke 1.0.0 compat (which we're using).
[13:33] <teward> ah
[13:33] <infinity> teward: DTRT = Do/Does The Right Thing.
[13:34] <teward> right, thanks
[13:34] <teward> actually
[13:34]  * teward borrows one of his servers' site configs for testing
[13:34] <teward> if it fails to work with an existing 1.8.1 copy, it's a major regression I report upstream heh
[13:34] <teward> (the site is live, but i'll be spinning it somewhere not in production)
[13:34]  * teward has a fairly complexified SSL setup
[13:35] <infinity> Perfect.
[13:35] <infinity> From the diff, it looked like they were just switching from using deprecated OpenSSL 0.9.x symbols to using the new and shiny 1.x versions, but I don't track OpenSSL API/ABI well enough to recall when the new shiny was added.
[13:36] <teward> infinity: right, though given what sarnold gleaned with regards to testing from upstream, and the fact they spin their own versions of the packages, I'm fairly certain they do some compatibility tests
[13:36] <teward> at least, now that Chrome has fully dropped NPN HTTP/2 support, they have to thoroughly make sure existing ALPNs don't break
[13:36] <teward> s/ALPNs/ALPN support in SSL libs/
[13:39] <xnox> ^^ infinity,pitti - should fix autopkgtest for dbconfig-common 2.0.4 regression as currently blocking mysql-5.7
[13:39] <xnox> the dbconfig-common upload.
[13:39] <xnox> at least it does for me locally.
[13:39] <infinity> I thought Skuggen and rbasak were working on that.
[13:40] <infinity> Oh, if it's just a missing test dep, oops.
[13:41] <rbasak> I was, but have only just this moment reproduced the failure locally.
[13:41] <rbasak> If that fixes it, it's fine by me. Thanks!
[13:41] <rbasak> Ah, and it would make sense. MySQL 5.7 uses Perl for less things, so no longer pulls in libdbd-mysql-perl.
[13:41] <infinity> Huh.  Is listing the same test twice with different deps actually a legal thing to do?
[13:42] <infinity> That feels super weird.
[13:42] <rbasak> I can see why it would be useful.
[13:42] <rbasak> (in this case)
[13:42] <infinity> rbasak, xnox: Can one of you make sure that gets forwarded to Debian?
[13:43] <xnox> infinity, no idea if it is legal, it does work =)
[13:43] <xnox> (e.g. totally tests one and then the other)
[13:43] <infinity> If it works, it's legal.
[13:43] <infinity> (Isn't that the way of software development?"
[13:43] <infinity> )
[13:43] <rbasak> I'm trying required upstreaming in bug 1566364 as there are quite a few now.
[13:43] <ubot5`> bug 1566364 in mysql-5.7 (Ubuntu) "Upstreaming tracking bug" [Undecided,Triaged] https://launchpad.net/bugs/1566364
[13:43] <rbasak> tracking
[13:43] <xnox> infinity, if only that was the USA immigration policy....
[13:44] <infinity> Hah.
[13:44] <xnox> rbasak, have you looked into ruby-mysql?
[13:45] <rbasak> xnox: https://bugs.launchpad.net/ubuntu/+source/ruby-mysql2/+bug/1566798 from Skuggen but that results an FTBFS locally still.
[13:45] <ubot5`> Launchpad bug 1566798 in ruby-mysql2 (Ubuntu) "Fails to build with mysql-5.7" [Undecided,New]
[13:45] <rbasak> http://paste.ubuntu.com/15650523/
[13:46] <xnox> rbasak, ack. well, it indicates the tests are broken in setup against 5.7
[13:46] <xnox> not that 5.7 is borked, or ruby-mysql itself borked
[13:46] <rbasak> Yeah I'm working on it.
[13:47]  * xnox looks at strongswan on s390x....
[13:48] <rbasak> Looks like I just failed to apply the second patch.
[13:49]  * rbasak doesn't really know much about non-unified diffs
[13:54] <rbasak> Oh hang on. I've been looking at the ruby-mysql2 FTBFS. ruby-mysql dep8 failure is separate.
[13:58] <Skuggen> rbasak: ERROR 1698 (28000): Access denied for user 'root'@'localhost' (from the dep8 failure) <-- This is what the --insecure option to mysql_install_db should fix
[14:01] <rbasak> Skuggen: it doesn't call mysql_install_db. It just depends on mysql-server (the test that is)
[14:01] <rbasak> Skuggen: any suggestions? Can we use socket auth or something?
[14:01]  * rbasak isn't sure how that ever worked
[14:02] <rbasak> http://paste.ubuntu.com/15651042/ is where the failure is
[14:02] <rbasak> Possibly it worked due to MySQL ending up with an empty root password because the debconf prompt was skipped
[14:02] <rbasak> Which is bad if that was it.
[14:03] <Skuggen> Where's the source for the dep8 tests?
[14:04] <rbasak> In debian/tests
[14:06] <doko> rbasak, https://launchpad.net/ubuntu/+source/ruby-mysql2/0.4.3-2ubuntu1
[14:07] <infinity> That's an odd selection of arches to fail on.
[14:07] <Skuggen> Haven't seen that amd64 test failure before, and I've been testing it on amd64
[14:07] <rbasak> I think it's perhaps flaky
[14:07] <rbasak> It worked for me locally on amd64.
[14:07] <rbasak> I'll retry them.
[14:08] <rbasak> Skuggen: are you looking at the ruby-mysql dep8 failure or shall I?
[14:09] <Skuggen> I'm lost, because none of the sources I find have a tests/ in debian/
[14:09] <infinity> ruby stuff is "special".
[14:09] <infinity> There's some auto-dep8 magic.
[14:09] <infinity> pitti: How does that work? :P
[14:09] <Skuggen> So we're dealing with "special" magic?
[14:09] <rbasak> Skuggen: it's right there in the ruby-mysql source. Are you using pull-lp-source?
[14:10] <infinity> Like, short-bus special.
[14:10] <rbasak> Nothing special that I can see on this one.
[14:10] <Skuggen> rbasak: Ah, no. I just used apt-get source
[14:10] <rbasak> It's failing in shell before it even dives into Ruby.
[14:10] <infinity> Oh, indeed, the ruby-mysql one isn't special.
[14:10] <infinity> Or, is special because it's not.
[14:10] <infinity> Or something.
[14:10] <infinity> pitti: unping.
[14:10] <rbasak> apt-get source uses your own system's sources.list, which may not be the one you want.
[14:10] <rbasak> Use pull-lp-source :)
[14:12] <Skuggen> Do you need to specify a version. I'm still not getting a d/tests
[14:12] <rbasak> The amd64 retry for ruby-mysql2 worked so I'll do the others.
[14:12] <infinity> Skuggen: By default, you get the tip version.
[14:12] <infinity> Which is 2.9.1-1build6
[14:13] <rbasak> ruby-mysql, right? Not ruby-mysql2.
[14:13] <infinity> (base)adconrad@nosferatu:~/ruby-mysql-2.9.1$ ls -l debian/tests/
[14:13] <infinity> total 8
[14:13] <infinity> -rw-rw-r-- 1 adconrad adconrad  59 Oct  6  2014 control
[14:13] <infinity> -rwxrwxr-x 1 adconrad adconrad 117 Oct  6  2014 test-suite
[14:13] <rbasak> Check "head debian/changelog" to see if you have the right tree.
[14:14] <Skuggen> Blargh. I downloaded ruby-mysql2
[14:14] <pitti> Skuggen, infinity: right, for ruby-*, perl-* and a few others, run "autodep8" to get the control file that it uses (adt-run does that automatically); it's a way to run common tests for thousands of source packages without having to copy them a thousand times
[14:16] <Skuggen> :q
[14:16] <Skuggen> Whops
[14:16] <infinity> E37: No write since last change (add ! to override)                               1,1           Top
[14:17] <Skuggen> But yeah, that looks like a "just happened to work before" test
[14:18] <Skuggen> rbasak: Mysql's own smoketest sets the root password, then reconfigures the server
[14:18] <rbasak> Skuggen: ah, good point. We could just do that.
[14:18] <Skuggen> Could maybe do the same
[14:19] <rbasak> Skuggen: good idea. I'll just copy in the bits. No need for you to do it as I'll only need to replicate locally again.
[14:19] <Skuggen> and edit test/test_mysql.rb to use it
[14:20] <rbasak> Ah yes good point, thanks.
[14:22] <infinity> I wouldn't patch test/test_mysql.rb
[14:22] <infinity> I'd just write the password to /root/.my.cnf
[14:22] <Skuggen> The ruby file is also set to read some env variables, if they're available
[14:22] <infinity> Oh, assuming the ruby client cares at all about my.cnf
[14:23] <Skuggen> CONFIG.pass = ENV['MYSQL_PASS'] || ''
[14:23] <infinity> But yeah, whatever it can use, I'd do it externally instead of patching.
[14:23] <infinity> env it is.
[14:25] <rbasak> Trying env now.
[14:26] <infinity> stgraber: Wat.
[14:27] <rbasak> That's...possible?
[14:27] <infinity> rbasak: Which?  The lxd thing?
[14:28] <stgraber> infinity: hmm, looks like I uploaded the wrong thing :)
[14:28] <infinity> rbasak: unapproved happens before any sanity checks, so yes.  It wouldn't accept if I were to try, mind you.
[14:28] <rbasak> Same version in queue as in archive.
[14:28] <rbasak> I see, OK
[14:28] <infinity> stgraber: Y'think? :)
[14:29] <teward> infinity: is there typically a delay from it landing in proposed and being available to install from proposed?  (Not showing up in apt-cache on Xenial, even when I added xenial-proposed)
[14:29] <infinity> teward: Yeah, it needs to do thinks like build some binaries and the stick them on some disks and then mirror them to the mirrors you actually see on the interwebs.
[14:30] <infinity> s/thinks/things/
[14:30] <stgraber> infinity: ubuntu6 coming up now :) The machine I did that stuff on happens to have broken network to upload.ubuntu.com so had to scp the bits to another box to upload, I misremembered how many times I bumped the packaging already and obviously didn't scp the .upload file so dput didn't tell me as much :)
[14:30] <teward> infinity: including archive.ubuntu.com (main archive)?
[14:30] <teward> looks built and published according to LP
[14:30] <infinity> teward: archive.ubuntu.com is a bunch of mirror frontends, it's not the real archive.
[14:30] <teward> ah, ok
[14:30]  * teward will wait
[14:30] <infinity> teward: "published" according to LP is what happens when it starts stuffing it on ftpmaster's disk, there's still a delay from there to when you see it.
[14:31] <teward> ahhhh, okay, i remember cjwatson saying something about that :)
[14:31] <teward> guess i'll wait then
[14:33] <infinity> stgraber: If I were you, I'd count backward from 10.254 instead of using 10.0.$smallint, but that's just me.
[14:33] <infinity> stgraber: I'd think you're far more likely to conflict with humans and their existing setups using low values.
[14:35] <stgraber> infinity: yeah, I could use something weird like <IP_ADDRESS>/24 humans don't like 255 :)
[14:35] <stgraber> infinity: feel free to reject and I'll do that
[14:37] <rbasak> Well that's annoying dpkg-reconfigure needs root. So now the test needs root.
[14:37] <infinity> stgraber: Well, what's using that 10.0.4 subnet?  That should likely change too.  Or are those both you?
[14:38] <Skuggen> Ah, right, yes, the 5.7 smoketest is also tagged needs-root
[14:38] <infinity> stgraber: But, yes, human-ugly is the ideal, IMO, if you don't want people like me tearing my hair out about having to renumber my network to route to your automagic setup.
[14:38] <infinity> Well, either deciding between renumbering my network or preseeding yours.  But both suck.
[14:38] <Skuggen> Though I don't really see a way around it. We've explicitly changed the packaging for 5.7 so you either need to set a password during installation or be root when you try to log in :)
[14:39] <infinity> rbasak: Is there no way to "su - $USER" in an autopkgtest test?  So, you can needs-root, setup the DB, then drop privs and run a non-root test?
[14:40] <infinity> rbasak: That seems like what should be happening, if you have a variable to know what the test user is (or if the user is statically specced)
[14:40] <Skuggen> Well it's just a shell-script, so should be possible?
[14:40] <mhall119> hello release team, is anyone available to take a look at https://bugs.launchpad.net/ubuntu/+source/muon/+bug/1562406 and help the Kubuntu team out?
[14:40] <ubot5`> Launchpad bug 1562406 in muon (Ubuntu) "[FFe] Update to latest upstream version" [Undecided,Confirmed]
[14:41] <infinity> Skuggen: Oh, no, it's possible, obviously, what I meant was that it's awkward unless you know what $user is meant to be. :P
[14:41] <Skuggen> Is there a default user for dep8 tests?
[14:41] <infinity> That's sort of what I was asking.  I assume there's either a default static user that's specced to exist, of an envvar that expands to a user that exists.
[14:42] <rbasak> infinity: you can, and I had to do it for Juju. But it's not easy because $USER isn't known.
[14:42] <infinity> If neither is true, that sucks.
[14:42] <infinity> rbasak: Ugh.  Really?  Lame.
[14:42] <rbasak> IIRC
[14:42] <stgraber> infinity: what's currently using 10.0.4 is lxcbr0 which does have logic to find an unused subnet on the machine so that's fine
[14:43] <stgraber> infinity: now lxdbr0 only suggests a subnet but it turns out people use our suggestions without thinking about it (despite them having to type it in :))
[14:43] <rbasak> Skuggen: got a problem now. Running as root for now, http://paste.ubuntu.com/15651925/
[14:43] <rbasak> Skuggen: need a bit of your MySQL knowledge I think please.
[14:44] <infinity> stgraber: Oh!  I didn't notice those were literally all doc strings, not any template defaults.
[14:44] <infinity> stgraber: In that case, I'd stick with the "pretty" versions.  If I'm so stupid I don't know that I'm using that IP, I suck.
[14:44] <infinity> stgraber: My internal parser just assumed you were defaulting to those values.
[14:45] <rbasak> infinity: http://paste.ubuntu.com/15651969/ is what I had to do for Juju
[14:45] <Skuggen> rbasak: Looks a bit like tinyint has changed.
[14:45] <stgraber> infinity: haha, no, no default for lxdbr0, that's the whole idea behind the thing, no random picking of subnets because we'll always fail at that somehow (especially when we're installed by default in all cloud instances) :)
[14:45] <stgraber> infinity: okay, so then tha upload should be good to go
[14:46] <Skuggen> It's -128-127 or 0-255, so -255 looks like the culprit
[14:46] <Skuggen> Hm, according to docs it was the same for 5.6
[14:58] <Skuggen> rbasak: For the various integer tests I don't see them having worked before either. Datetime makes more sense, since 5.7 defaults to not allowing 0-dates
[14:59] <teward> infinity: confirmed: SSL works
[15:00] <teward> running one slightly more stringent test first though
[15:03] <rbasak> Skuggen: looks like the test needs significant alterations
[15:06] <Skuggen> Doesn't look like big changes for each test, but I don't really understand what they're trying to test
[15:07] <rbasak> Skuggen: http://paste.ubuntu.com/15652507/ is what I have to fix the test run and root password
[15:07] <Skuggen> By the way, mysql-workbench-6.3.6+dfsg looks ready to go from the ppa
[15:07] <rbasak> Just need to add test fixes to that.
[15:09] <Skuggen> I'll go through and try to get them sorted out. Might need to get som people to help me here, but everyone's gone home :)
[15:11] <xnox> infinity, so gnupg2.1 went in without fixing critical bugs in gpg-agent
[15:11] <xnox> and breaking mine and Laney's desktops?!
[15:11] <xnox> not good
[15:11] <teward> infinity: my thorough test (including HTTP/2) shows that it's working even with my complicated SSL cipher strings.  So it looks like nginx did not break 1.0.0 compat.
[15:11] <teward> (for openssl)
[15:12] <infinity> xnox: Should something have stopped that (did someone override some tests or force something?)
[15:12] <infinity> xnox: Or are you just complaining to me to have someone to complain to? :)
[15:12] <infinity> teward: Excellent, thanks.
[15:12] <teward> you're welcome.
[15:12] <rbasak> Skuggen: I created https://bugs.launchpad.net/ubuntu/+source/ruby-mysql/+bug/1566917 to track, thanks.
[15:12] <ubot5`> Launchpad bug 1566917 in ruby-mysql (Ubuntu) "dep8 test failures" [Undecided,Triaged]
[15:13] <xnox> infinity, Laney and I discussed it and it's RC buggy in debian which totally affects us too.
[15:14] <slangasek> infinity: the Feature Freeze should have stopped it, but did not
[15:14] <xnox> infinity, gnupg now uses $GNUPG_HOME for sockets, instead of $TMP. In practice it should use $XDG_RUNTIME_DIR/gpg/$escaped-path-to-GNUPGHOME as otherwise bind-mounting /home, nfs /home, read-only /home cannot use gpg at all
[15:14] <infinity> slangasek: Right, won't argue that, but I'm pretty sure I didn't approve it.  Did I?
[15:14] <xnox> and e.g. ssh enabled gpg
[15:15]  * infinity now wonders if he did.
[15:15] <Skuggen> rbasak: Did you have a chance to look at the dbconfig-common failure? It's giving a dependency error on libdbd-mysql-perl
[15:15] <slangasek> infinity: nope
[15:15] <rbasak> Skuggen: xnox fixed it
[15:15] <Skuggen> Ooh, great
[15:15] <slangasek> infinity: but you asked "should something have stopped that" and I'm letting you know what ;)
[15:15] <slangasek> infinity: as for whether xnox is complaining to you just to have someone to complain to, well
[15:15] <xnox> superm1, did you know that gpg-agent 2.1 is RC buggy in both debian and ubuntu and breaks the world? =)
[15:15] <rbasak> Skuggen: we dropped the libdbd-mysql-perl dependency so it needed adding as a test dependency (assuming it depended on it undeclared). The dep8 test run hasn't finished yet htough.
[15:17] <superm1> xnox: if it's absolutely something that can't be fixed, we can pull it back
[15:17] <superm1> but do you have some bugs filed?
[15:18] <xnox> looking
[15:18] <xnox> it used to be RC in debian
[15:18] <xnox> e.g. upstart session job is broken for those that enable ssh support, so that needs fixing
[15:18] <xnox> GPG_AGENT_INFO is no longer exported so e.g. debsign things there is no gpg-agent available.
[15:19] <superm1> what do you mean it used to be RC in debian?
[15:19] <xnox> we need
[15:19] <xnox>   * updated /etc/X11/Xsession.d/90gpg-agent to export $GPG_AGENT_INFO
[15:19] <xnox>     about the standard socket.
[15:20] <xnox> but updated for user session upstart
[15:20] <xnox> ditto
[15:20] <xnox>   * update gnupg-agent.xsession to export ssh-agent where
[15:20] <xnox>     configured. (Closes: #767341)
[15:23] <xnox> superm1, yeah the bug is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796931#77 and we are missing implementation on the desktop for all of that which we know absolutely must include.
[15:23] <ubot5`> Debian bug 796931 in gnupg-agent "gnupg-agent: no longer writes $GNUPGHOME/gpg-agent-info-$(hostname) file" [Normal,Open]
[15:23] <xnox> let me sync that into launchpad
[15:24] <superm1> ok thanks
[15:24] <cyphermox> xnox: I use gpg-agent with ssh and etc., lemme know if I can help testing with my weird setup
[15:24] <xnox> cyphermox, cool =)
[15:24] <xnox> cyphermox, for now i expect it to be broken =)
[15:24] <slangasek> xnox: just as a random point, reverting the socket behavior will cause scute to FTBFS again as its testsuite relies on the gnupg2.1 behavior
[15:25] <cyphermox> xnox: for now, it works for me, but I also always had to script around it to start it just the way I want it to be :/
[15:25] <slangasek> superm1: anyway, all the above is why I said this shouldn't have gone in without an FFe review
[15:25] <superm1> well it should still be a standard socket, but it sounds to me the variable needs to point to the socket
[15:26] <superm1> slangasek: understood, and i agree.  it would have been nicer to catch these things at that time.
[15:28] <xnox> cyphermox, well i got upstart user session jobs to the point that it looks at the $GNUPGHOME config files and does the right thing
[15:28] <cyphermox> xnox: ok
[15:28] <cyphermox> unreleased code?
[15:28] <xnox> and e.g. it can totally disable gnome-keyring (via startup programs) and the upstart job is sensitive to that and can do everything right
[15:28] <cyphermox> nice.
[15:28] <xnox> cyphermox, well it was all working until this 2.1 release landed =)
[15:29] <cyphermox> oh, then it wasn't working for me ;)
[15:29] <xnox> cyphermox, basically google use the same weird yubikey-sshkeys setup i do =)
[15:29] <cyphermox> right, so do I
[15:29] <xnox> and i fixed it for me.
[15:29] <xnox> ...
[15:29] <rick_h_> slangasek: ping, I wanted to make sure to reach out. The team's gotten all changes we talked about last week done and in the queue. Is there anything from here that I need to make sure my folks get done?
[15:30] <slangasek> rick_h_: hi, I saw the new uploads land in the queue, thanks very much - it's now waiting on me or another release team member to circle back around for review, I will try to get to that this afternoon
[15:31] <rick_h_> slangasek: <3 ty much. let me know if there's anything we can do.
[15:32] <xnox> superm1, infinity - gnupg bug tracker is at https://bugs.launchpad.net/ubuntu/+source/gnupg2/+bug/1566928 i shall fix things up, cause i doubt we have any other upstart-usersession-xsession-integration people =) or those willing to fix and test that with an ssh-gnupg-smartcard
[15:32] <ubot5`> Launchpad bug 1566928 in gnupg2 (Ubuntu Xenial) "gnupg-agent: no longer writes $GNUPGHOME/gpg-agent-info-$(hostname) file" [Critical,Triaged]
[15:32] <superm1> xnox: yes if you've got the cycle to do so, please do
[15:33] <infinity> xnox: If you have a handle on what needs fixing and slangasek doesn't tell you "no", please fix.
[15:34] <xnox> yeah i will
[15:34] <infinity> xnox: If Steve does tell you to keep your hands off, document the bug(s) well enough that we can spread the blame around? :)
[15:34] <xnox> once i get s390x back into installable state
[15:34] <xnox> infinity, i dunno =) we can't really blame superm1 - his people did renew and all that =)
[15:35] <xnox> and you know, superm1 is nice =)
[15:35] <infinity> xnox: That's never stopped me from blaming him.
[15:35] <xnox> hahahahah
[15:35] <superm1> haha
[15:38] <cyphermox> xnox: like I said, ping if you need a second pair of eyes to test your fix ;)
[15:58] <Skuggen> Almost all the ruby-mysql tests that fail are just testing that the server isn't running in strict mode (which became a default in 5.7)
[16:00] <rbasak> Would it be easier to modify the test so it switches the server out of strict mode for now?
[16:00] <rbasak> Then it'd be testing the same thing.
[16:00] <rbasak> Given that we're not testing what mode the server is in in the ruby-mysql tests.
[16:00] <Skuggen> Yeah, I did that and was left with 1 error and 2 failures, and the error is simple
[16:01] <Skuggen> Well, I just set sql_mode='' to test, so might be more than just strict mode
[16:01] <rbasak> I'm open to feedback but I think it's be acceptable this way. I'd object more if they were tests inside mysql or something, but ruby-mysql's tests can require whatever mode they want as far as I'm concerned.
[16:02] <rbasak> Given that the server can only be in one mode at once and that'll be a function of the eventual deployment under a sysadmin's control.
[16:02] <Skuggen> Yeah, it's testing the server configuration, not ruby-mysql or mysql itself
[16:02] <rbasak> It doesn't even depend on the server.
[16:02] <rbasak> So can't be a function of the package to assume a particular mode.
[16:07] <Skuggen> rbasak: If you add a «set global sql_mode='NO_ENGINE_SUBSTITUTION';» to the call that creates the test database, you should get the 5.6 default mode
[16:22] <lamont> When does distro-image change to claim xenial as the latest lts?
[16:22] <lamont> is that "once we throw the release switch", or?  (what triggers that change)
[16:23] <Laney> The date which is (hopefully) already defined
[16:26] <infinity> lamont: distro-info, you mean?
[16:26] <lamont> there is a desire for a --lts variant that includes an lts under development (as in, it would have started claiming xenial 5+ months ago..)
[16:26] <lamont> infinity: yeah,.. I suck at typing
[16:26] <infinity> lamont: /usr/share/distro-info/ubuntu.csv
[16:27] <lamont> so the csv already knows that xenial is --lts-including-devel, distro-info just needs to learn a new flag...
[16:27] <infinity> lamont: Patches welcome if you want --devel and --lts to work together.
[16:27] <lamont> or to allow --lts --devel
[16:27] <lamont> yeah
[16:37] <Skuggen> rbasak: Setting the above sql mode and applying this patch should fix it: http://paste.ubuntu.com/15655187/
[16:38] <Skuggen> Though I manually ran the tests, since my autopkgtest is borked
[16:39] <rbasak> Skuggen: thanks, I'll try it now.
[16:39] <cjwatson> xnox,infinity: FYI I'm doing that static analysis of build-deps in main that we talked about
[16:40] <cjwatson> It's not terribly quick but after a bit of work I have something that will spit out resolutions of everything in main for amd64 and i386 before the heat death of the universe
[16:40] <cjwatson> (Might do the rest later but this is a good start)
[16:42] <xnox> cjwatson, cool!
[16:44] <cjwatson> python-apt turns out to be fast enough with a bit of care
[16:47] <lamont> infinity: http://paste.ubuntu.com/15655520/ <-- thoughts?  still needs a test case or 2, but...
[16:48] <lamont> bah.  line 19 += unlikely()
[16:49]  * rbasak is surprised that distro-info-data needs to be so heavily optimised so as to use likely/unlikely.
[16:49] <lamont> rbasak: /me is just going with what it has everywhere else
[16:49] <rbasak> Fair enough!
[16:49] <lamont> but yeah, I suspect it's ignoring the fact that 90% of the run time is startup/exit processing
[17:05] <lamont> infinity: http://paste.ubuntu.com/15656045/ If you are +1, I'll upload 0.14ubuntu1
[17:06] <lamont> though, tbf, I suppose we should document that --lts and --devel can be used in conjunction, eh?
[17:12] <xnox> bareos vs mysql -> Unable to load any shared library for libbareoscats-mysql.so
[17:12] <xnox> on s390x
[17:17] <lamont> infinity: uploaded it to my ppa, with high hopes that you'll kick it around
[17:18] <lamont> also, I'd just like to say that I'm a fan of unit tests
[20:20] <stgraber> doko: do you have a FFe for that vim upload?
[20:32] <doko> stgraber, I filed https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1566579
[20:32] <ubot5`> Launchpad bug 1566579 in vim (Ubuntu) "FFe: merge with the current Debian package" [Undecided,New]
[20:35] <stgraber> doko: commented with questions
[20:36] <doko> stgraber, ugh, launchpad can't expand long comments anymore?
[20:37] <doko> seriously, I have to *download* this comment?
[20:37] <stgraber> hmm, that's special, I thought there used to be a link to see the whole thing
[20:40] <knome> doko, technically, if it's in the internet and you get a local copy to see it, you are downloading it any way :P
[20:40]  * knome hides
[20:41] <doko> stgraber, commented. I won't fight for it
[20:51] <stgraber> coreycb: can you give me a changelog for python-concurrent.futures?
[20:51] <stgraber> coreycb: the Debian changelog doesn't have one and I can't easily find one upstream
[20:51] <stgraber> (you're bumping us from 3.0.3 to 3.0.5 so I'd like to confirm that this is bugfix only)
[20:52] <coreycb> stgraber, it's part of the openstack FFE
[20:52] <coreycb> stgraber, upstream final release is this week so we should go quiet after this week
[20:53] <stgraber> coreycb: link to the FFe please
[20:54] <coreycb> stgraber, there's no bug, but there's this: https://lists.ubuntu.com/archives/ubuntu-release/2016-February/003572.html
[20:54] <stgraber> coreycb: where can I see that this package is part of upstream openstack?
[20:54] <coreycb> stgraber, https://github.com/openstack/requirements/blob/stable/mitaka/upper-constraints.txt
[20:54] <stgraber> I've approved the others because they clearly are, but this one I didn't find in any openstack repo
[20:55] <coreycb> stgraber, it's a dependency
[20:55] <stgraber> ok, right, then get an FFe please
[20:55] <stgraber> your exception is for OpenStack and its components itself, not for its dependencies
[20:55] <coreycb> stgraber, I don't think so, I think it's for deps no?
[20:55] <stgraber> otherwise you could upload a new qemu, linux, python3, libc, ... using the same reasoning
[20:56] <coreycb> stgraber, this would get really difficult if we had to open a bug for everything
[20:57] <stgraber> well, you don't need FFes for things that are specific to openstack and you don't need FFes for packages which are bugfix only
[20:57] <stgraber> but you sure do for the rest
[20:58] <coreycb> stgraber, looking at the email I linked above it includes direct dependencies for openstack
[20:59] <doko> stgraber, openstack re-releases every new bit of the python3 std library
[20:59] <doko> yes, it's wrong
[21:00] <stgraber> coreycb: "and direct dependencies managed under the OpenStack umbrella", from what you're telling me, this dependency is from outside of openstack so not "under the OpenStack umbrella"
[21:00] <coreycb> stgraber, I suppose there's a bit of a gray area but it's a direct dependency of openstack as noted in this: https://github.com/openstack/requirements/blob/stable/mitaka/upper-constraints.txt
[21:00] <stgraber> coreycb: note that FFe can be granted verbally which is why I asked you to give me a changelog and didn't just reject the upload, because I was quite willing to just look at a changelog and let it through
[21:01] <coreycb> stgraber, fair enough, I'm not trying to be difficult
[21:01] <stgraber> coreycb: but since you clearly prefer arguing over just providing that bit of information, I have now rejected the upload and would like a written FFe for this please
[21:02] <coreycb> stgraber, I'm really not trying to be difficult, I'm just trying to discuss what the feature freeze exception entails for openstack
[21:03] <stgraber> coreycb: "This includes core OpenStack packages and direct dependencies managed under the OpenStack umbrella.", so all the usual core packages (nova, neutron, ...) and any direct dependency of that stuff which is under the OpenStack umbrella (so all the python library crap from upstream)
[21:03] <stgraber> that doesn't say anything about direct dependencies outside of openstack
[21:04] <coreycb> stgraber, I think we are interpreting dependencies of openstack differently
[21:04] <stgraber> coreycb: unfortunately for you, my interpretation is the one that counts in this case :)
[21:05] <coreycb> stgraber, and I could be wrong, but I have been going by upstream openstack's global requirements as being the openstack dependencies: https://github.com/openstack/requirements/blob/stable/mitaka/upper-constraints.txt
[21:05] <coreycb> stgraber, that's fine
[21:05] <coreycb> stgraber, just to be clear, what is the definition to you?
[21:07] <stgraber> coreycb: to me "under the OpenStack umbrella" means that the upstream of those dependencies is some openstack person/project. That's been mostly the case for all the other stuff I approved (or were bugfix only releases which were fine), that is, trivial googling was showing either their code repository being hosted on openstack infrastructure or the package description itself making it clear that it was developed for use by openstack.
[21:08] <coreycb> stgraber, ok fair enough.  so basically stuff that's on github.com/openstack
[21:09] <stgraber> coreycb: yeah. For the others, it would help a lot if the Debian packager could describe the new features in the changelog or indicate that it's a bugfix release, because "New upstream release" without anything else isn't terribly useful when reviewing :)
[21:15] <stgraber> bdmurray: that diff is insanely long, can you confirm it's the same as before minus the weird log file?
[21:20] <stgraber> bdmurray: nevermind, just diffed the diffs, looks good
[21:25] <stgraber> slangasek: was that you? :) ^
[21:25] <slangasek> stgraber: no
[21:25] <stgraber> okay, I was just grabbing a diff for the golang-yaml.v2 thing, wonder who accepted it
[21:25] <coreycb> stgraber, thanks for the discussion.  it cleared up my thoughts on what is included in the ffe.  in the future if a dep is not limited to openstack I'll be sure to bring it up to the release team's attention.
[21:25] <coreycb> stgraber, here's the changelog for futures, it's just a few bug fixes: https://github.com/agronholm/pythonfutures/blob/master/CHANGES
[21:26] <stgraber> coreycb: thanks, I'll accept it
[21:26] <coreycb> stgraber, thansk
[21:27] <stgraber> coreycb: oh, or not, apparently we can't accept rejected syncs :)
[21:27] <stgraber> coreycb: can you sync it again please?
[21:27] <coreycb> stgraber, ok
[21:27] <coreycb> stgraber, on it's way
[21:27] <doko> stgraber, me, fixing a ftbfs
[21:30] <stgraber> doko: alright, diff looks good anyway. I'm just always worried about those go package updates as they are just new git snapshots of upstream and most go upstreams don't know what a feature is (or backward compatibility for that matter)
[21:31] <doko> stgraber, what we really need is some kind of automated autopkg tests ... I thought mwhudson wanted to work on this maybe
[21:31] <mwhudson> stgraber: in this case we were all being careful :-)
[21:35] <bdmurray> stgraber: thanks!
[21:36] <xnox> sigh
[21:36] <xnox> http://autopkgtest.ubuntu.com/running.shtml#pkg-redmine -> so redmin adt test expploaded as out of resources
[21:36] <xnox> could dbconfig-common=2.0.4ubuntu1 be hinted to go in?
[21:36] <xnox> it's all green across the board
[21:37] <xnox> and it's a step in the right directly to unwind mysql5.7
[21:37] <rbasak> dbconfig-common's dep8 tests are stupidly long :(
[21:37] <rbasak> I'm still trying to reproduce the failure locally.
[21:37] <xnox> rbasak, which failure? they are all good.
[21:37] <slangasek> xnox: it's not green across the board until the i386 test finishes; then it's green plus a little yellow :-)
[21:38] <xnox> slangasek, look at the http://autopkgtest.ubuntu.com/running.shtml#pkg-redmine it will not finish =)
[21:38] <rbasak> Oh
[21:38] <rbasak> It's fixed
[21:38] <xnox> because openstack is out of resources
[21:38] <xnox> rbasak, yes, i did.
[21:38] <rbasak> I was looking at the mysql-5.7 section and thought it was still stuck
[21:38] <rbasak> (after your upload)
[21:38]  * xnox can ship more clouds from london to whereever that is
[21:39] <xnox> rbasak, don't, mysql is testing against old dbconfig from -release, instead of from -proposed. Once dbconfig migrates, retriggers of dbconfig test on mysql package will turn green too.
[21:39] <xnox> rbasak, ruby-mysql[2] are outstanding, or are there uploads for them too now?
[21:40] <rbasak> ruby-mysql pending upload
[21:40] <xnox> and no clue about strongswan, let me try running that.
[21:40] <rbasak> (and fix)
[21:40] <rbasak> Mostly fixed, just one more piece to do
[21:40] <rbasak> ruby-mysql2 I uploaded earlier I thought.
[21:40] <xnox> ack.
[21:40] <slangasek> xnox: have you flagged this to pitti ?
[21:40] <xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ruby-mysql2 -> looks odd
[21:41] <rbasak> Indeed I did but it's claiming failure again.
[21:41] <rbasak> I only fixed the build earlier, not dep8
[21:41] <xnox> 2016-04-06 15:26:36 4753 [ERROR] /usr/sbin/mysqld: unknown option '--insecure'
[21:41] <xnox> looks like ruby-mysql2 is testing against old mysql =(
[21:41] <rbasak> I patched that for the build.
[21:42] <rbasak> Can't remember which way round
[21:42] <xnox> slangasek, he is playing basketball
[21:42]  * xnox goes out for a run =)
[21:42] <slangasek> xnox: he's not ;)
[21:42] <slangasek> unless he has courtside IRC
[21:42] <xnox> ha
[21:42] <xnox> slangasek, google glass for the win!
[21:43] <slangasek> nothin' but 4G
[21:43] <rbasak> Testsuite: autopkgtest-pkg-ruby
[21:43] <slangasek> oh wait, that reference is older than you are
[21:44] <xnox> slangasek, you lost me
[21:44] <slangasek> xnox: "Nothing but net"
[21:44] <xnox> yeah, no idea =)
[21:44]  * pitti only had a question about travel prep, I guess I quickly leave again (for bed) before I prolong my nightshift further :)
[21:45] <pitti> xnox: I can re-run ruby-mysql2 against the -proposed mysql
[21:45] <slangasek> xnox: so is there a reason to expect that retrying the redmine/i386 failure won't work?
[21:45] <xnox> pitti, yes please.
[21:45] <pitti> done
[21:46] <pitti> and off, good night!
[21:46] <xnox> slangasek, i cannot retry, if it is still running. i think bugs like that should autoclear. however the queue is really small, so surely the cores should be available
[21:46] <xnox> pitti, can you force rerun redmine/i386 for dbconfig-common?
[21:46] <xnox> it is stuck.
[21:46] <slangasek> xnox: I'm already doing
[21:46] <xnox> slangasek, ah cool.
[21:46] <xnox> pitti, night!
[21:46] <slangasek> and in parallel, I'm also rerunning dbconfig-common/proposed against mysql-5.7
[21:46] <rbasak> Ah I follow now. So we'll just wait for a test rerun against proposed for ruby-mysql2?
[21:47] <rbasak> dbconfig-common locally against proposed passed for me just now.
[21:47]  * doko thinks pitti only pretends playing basketball and instead fixing autopkg issues undisturbed during that time
[21:47] <rbasak> So just ruby-mysql needs an upload for dep8 from my perspective I think.
[21:48] <rbasak> I know of 26 FTBFS for no-change rebuilds for libmysqlclient rdeps that'll need fixing after we're through dep8 BTW.
[21:49] <xnox> slangasek, unless you want to simply hint mysql-5.7 through. all outstanding things are not bugs in mysql, nor other packages using mysql, only their tests.
[21:49] <xnox> rbasak, oh really? still? i thought that was all fixed....
[21:49] <slangasek> xnox: I feel somewhat strongly about getting clean test runs for packages so that the *next* failure is diagnosable
[21:49] <rbasak> xnox: so did I :(
[21:50] <xnox> i am very interested in mysql-5.7 migrating, because it's holding up s390-tools migration =)
[21:50] <slangasek> xnox: after all, "this failure is not a bug in this package" does not assure that "there is no bug in this package"
[21:50] <slangasek> yes, I would also like mysql-5.7 to migrate :)
[21:53] <rbasak> I'm working on a ruby-mysql dep8 fix
[21:53] <rbasak> slangasek: +1 :-)
[22:11] <rbasak> xnox: are you looking for something to tackle? I have a queue.
[22:36] <stgraber> would be nice if someone could review lxc and lxd, lxc is the 2.0 final release, delta with latest rc is pretty small (just a performance fix), lxd is another lxdbr0-related packaging only fix
[22:37] <stgraber> I will have a new lxd rc tagged upstream later today which will mean a pretty big diff, so I'm hoping to have this upload reviewed first for ease of review (keeping complex packaging changes uploads separate from big release uploads)
[22:39] <doko> looking ...
[22:46] <doko> stgraber, done
[22:52] <rbasak> xnox: AFAIK, that's all the dep8 test failures for mysql-5.7 fixed now, but not clear of the excuses page yet.
[22:52] <rbasak> Not sure about a strongswan s390x failure?
[22:52] <rbasak> ruby-mysql and ruby-mysql2 are red but have new uploads that should pass on retest.
[22:53] <stgraber> doko: thanks
[22:54] <rbasak> There are other FTBFS that affect installability on migration, I'll tackle those next.
[22:54] <rbasak> I have a fix for hhvm pending. It fixes the MySQL side, but isn't quite there yet with the isnan/isinf side.


[07:15] <micahg> mr_pouit: am I ok to upload a similar powerpc fix for exo to the one that doko did for libsfce4ui?
[07:33] <micahg> mr_pouit: oh, I guess you did it 5 minutes before I had it ready :-/
[09:07] <mr_pouit> micahg: eh sorry, I saw the ftbfs mail when I woke up, so I uploaded the fix immediately ;]
[12:56] <charlie-tca> Good morning
[14:26] <charlie-tca> mr_pouit: fresh install today, desktop does not start; live cd same - desktop does not start. It is installed. I can start it myself.
[14:32] <mr_pouit> not sure why, I tried the current i386 daily image this morning, and it started :]
[14:32] <charlie-tca> I just ran it on hardware, got panels without the desktop wallpaper.
[14:33] <charlie-tca> I can't get virtualbox to work in Natty now.
[14:34] <charlie-tca> Maybe it dislikes my ATI 9800 ?
[14:35] <charlie-tca> Oh, wait. This is yesterday's live cd
[14:35] <charlie-tca> Today's failed to build
[14:36] <mr_pouit> I don't know, I still need to disable "launch gnome services" in the default config, otherwise xfce4-session will try to start half of gnome (i.e. even desktop files with OnlyShowIn=GNOME;) afaik
[14:36] <mr_pouit> yeah, it failed
[14:36] <charlie-tca> great... I will wait for another build to file bugs
[14:39] <mr_pouit> but it won't affect existing configs
[14:40] <mr_pouit> so you should uncheck the box in xfce4-session settings ;)
[14:40] <charlie-tca> This is running the live cd
[14:40] <mr_pouit> and see if it's better
[14:40] <mr_pouit> mmh, ok
[14:40] <mr_pouit> anything in .xsession-errors ?
[14:40] <charlie-tca> My install is working
[14:41] <charlie-tca> forgot to look
[14:44] <charlie-tca> doesn't look like it
[14:44] <charlie-tca> We can wait and see next week
[14:51] <mr_pouit> charlie-tca: is apport following your gtk+ theme?
[14:52] <charlie-tca> I don't understand
[14:52] <mr_pouit> charlie-tca: the apport window that appears, is it correctly themed?
[14:52] <charlie-tca> I haven't seen an apport crash on natty in the panel
[14:52] <mr_pouit> when I tried this morning, it was "plain ugly grey"
[14:53] <charlie-tca> heh
[14:53] <mr_pouit> mmh, maybe you can make it appear with "apport-bug"
[14:53] <mr_pouit> (in a terminal)
[14:53] <charlie-tca> I haven't seen any crashes come up
[14:54] <mr_pouit> yeah yeah, I know, I had to provoke one to see apport ;>
[14:54] <charlie-tca> checking
[14:55] <charlie-tca> what package works?
[14:55] <charlie-tca> linux and thunar and vbox are not guenuine packages
[14:56] <charlie-tca> I can't force one
[14:56] <charlie-tca> apparently all my packages are "not a genuine Xubuntu package"
[14:57] <charlie-tca> lol; must have faked everything on here... ;-)
[15:29] <charlie-tca> I like greybird more than bluebird
[15:29] <charlie-tca> just my 2 cents
[15:29] <mr_pouit> hehe
[15:30] <mr_pouit> if you add xfce4-verve-plugin, can you see what you type in the tex area ?
[15:30] <mr_pouit> *text
[15:30] <mr_pouit> with bluebird it seems to be white on white ;)
[15:30] <charlie-tca> it worked with dictionary plugin, let me check
[15:31] <mr_pouit> no need to, if it works with dict-plugin, it's okay
[15:32] <charlie-tca> going to verify anyway, maybe I used a different theme when I tested it
[15:33] <charlie-tca> isn't white on white hard to see?
[15:34] <charlie-tca> very light gray on white
[15:34] <charlie-tca> very hard to see in greybird too
[15:35] <charlie-tca> I have to hilight the text to see it
[15:37] <mr_pouit> yeah, with bluebird it's invisible :p
[15:40] <charlie-tca> I will have to install a floppy drive in a test unit to check the bugs from that. My system with the working drive lost the motherboard
[15:42] <charlie-tca> mr_pouit: are we really going to try and support floppy drives in Natty?
[15:43] <mr_pouit> "[Build #2081503] powerpc build of xfce4-panel 4.7.6-0ubuntu1 in ubuntu natty RELEASE" <<< micahg, it's for you if you want :P (I will only be at home in 2~3h, so I'll do it if you haven't done it already ;)
[15:43] <mr_pouit> charlie-tca: if gio supports mounting floppy drives, yeah ;>
[15:43] <mr_pouit> otherwise, we don't care
[15:43] <charlie-tca> Okay, I will check it out then.
[15:47] <mr_pouit> micahg: oops, nvm, doko was faster :p
[16:24] <ochosi> hi everyone
[16:25] <ochosi> about the invisible text: i'll check it out in a few mins, have to reboot to natty
[16:25] <ochosi> haven't noticed that problem yet though
[16:25] <ochosi> maybe some new behaviour of murrine...
[16:26] <charlie-tca> It is only the panel apps, as far as I know
[16:26] <ochosi> aha
[16:26] <ochosi> interesting
[16:26] <ochosi> true
[16:26] <ochosi> it's the same in maverick
[16:26] <ochosi> thanks for reporting that
[16:27] <ochosi> is it problematic in any other plugin than verve?
[16:28] <charlie-tca> xfce4-dictionary
[16:28] <ochosi> mhm
[16:28] <ochosi> kay, i'll try to fix the panel code asap
[16:28] <charlie-tca> We seem to be a bit fussy now. Wanting to read the text that got typed! ;-)
[16:29] <ochosi> btw, i made a new gtk-scale style for greybird, will push that in a few mins
[16:29] <ochosi> would be interested what you say
[16:29] <ochosi> it should be more visible and better for accessibility now
[16:29] <charlie-tca> I like that idea
[16:30] <ochosi> i'll maybe also try to quickly fix the panel-text problem
[16:38] <ochosi> k, i fixed it
[16:38] <ochosi> i'll commit the stuff in a few mins
[16:38] <ochosi> can any of you test the fix on natty?
[16:38] <charlie-tca> yup
[16:38] <charlie-tca> let me know
[16:41] <ochosi> charlie-tca: just pushed the changes, should now be available in the hg-repo
[16:42] <charlie-tca> okay
[17:00] <charlie-tca> Looks the same
[17:00] <ochosi> really?
[17:00] <charlie-tca> yup
[17:00] <ochosi> k, will check myself quickly in natty
[17:00] <charlie-tca> I have to hilight the text to see that I typed it
[17:00] <ochosi> the fix worked in maverick
[17:00] <ochosi> brb
[17:02] <charlie-tca> ochosi: it works now in verve plugin but not in dictionary plugin
[17:02] <charlie-tca> Letters are very sharp in verve plugin
[17:04] <ochosi> charlie-tca: please specify the dict-problem
[17:04] <ochosi> dict is only a launcher button as far as i can see
[17:05] <ochosi> ah right
[17:05] <ochosi> now i see
[17:05] <charlie-tca> When you add it to the panel, you add a book and a blank
[17:05] <ochosi> well, not by default
[17:05] <charlie-tca> no? mine did
[17:05] <ochosi> by default it's without the textbox in the panel (at least here)
[17:05] <ochosi> but nevermind, i'll fix it
[17:06] <charlie-tca> Thanks
[17:06] <charlie-tca> sorry for the confusion
[17:06] <ochosi> no problem
[17:07] <ochosi> it's a pity that the systray is still broken
[17:08] <charlie-tca> +1
[17:09] <charlie-tca> But, they don't shrink all the way gone everyday :-)
[17:09] <ochosi> :)
[17:10] <ochosi> hm, strange that the fix doesn't apply for the dict-plugin, it's using the same widget as the verve plugin
[17:11] <charlie-tca> hm, before we couldn't type in either one, but that got fixed finally
[17:16] <ochosi> hm, i think i won't have enough time to fix xfce-dict for now, g2g
[17:16] <ochosi> i'll put it on the todo-list for greybird
[17:17] <charlie-tca> That works, too. Didn't expect you to jump right in
[17:18] <ochosi> well, it seemed easy to figure out ;)
[17:18] <ochosi> how do you like the new scale style?
[17:19] <ochosi> (it's that widget you can see as progressbar of a video/audio in parole)
[17:19] <ochosi> i guess you have to play a file to really see how it works/looks
[17:22] <ochosi> charlie-tca: in case i forget about the dict-bug please remind me
[17:22] <ochosi> g2g now
[17:22] <charlie-tca> Oh,
[17:22] <charlie-tca> I don't do well with that, but will check it out in a bit
[17:22] <charlie-tca> Thanks
[17:22] <ochosi> k, see you
[18:15] <charlie-tca> mr_pouit: I can not get Natty to recognize the floppy drive. I don't know if there is a udev rule for it even.
[18:16] <mr_pouit> I only have laptops here, so no more floppy disk for me :p
[18:16] <charlie-tca> Well, I get the drive in lucid, but not maverick or natty
[18:16] <charlie-tca> I can't force a mount even, because it isn't in /dev
[18:17] <mr_pouit> yeah, then probably a kernel or udev issue
[18:17] <charlie-tca> Want to kill the bug reports on floppies then?
[18:18] <mr_pouit> I don't think the original reporter still cares
[18:18] <charlie-tca> I will take care of it.
[20:49] <micahg> mr_pouit: the xdg applications list moving to /usr/share doesn't change anything WRT its purpose, right?
[20:56] <mr_pouit> micahg: it shouldn't
[20:57] <micahg> mr_pouit: ok, I'll update the firefox apparmor profile then
[20:57] <mr_pouit> putting it to /etc was probably a mistake in the first time ;[
[20:58] <micahg> mr_pouit: because it's not meant to be changed?
[20:59] <mr_pouit> yeah, and all desktop files added would be marked as conffiles, so not really usable
[20:59] <micahg> ok, cool
[21:00] <mr_pouit> (there will be already enough rm_conffile stuff because of the 4.6 -> 4.8 transition)


[02:09] <XiXaQ> hello everyone.
[02:09] <XiXaQ> when I install new programs, they often don't appear in the menus until the next time I login. Is this a common problem?
[02:09] <XiXaQ> and is it reported?
[02:10] <crimsun> on edgy?
[02:10] <crimsun> it's not normally a bug.
[06:56] <towsonu2003> hi
[08:10] <towsonu2003> hi
[08:10] <towsonu2003> is launchpad okay? it didn't send me any emails after I half-triaged a bunch of bugs...
[08:11] <crimsun> it's a known issue
[08:14] <towsonu2003> ok thanks :)
[08:15] <towsonu2003> oh, if I don't get emails, the security team doesn;t either... see https://bugs.launchpad.net/distros/ubuntu/+source/vnc4/+bug/77383 regarding a vnc security issue (already posted to the forums)
[08:15] <Ubugtu> Malone bug 77383 in vnc4 "vnc4 authentication bypass" [Critical,Unconfirmed]
[08:31] <anders__> hmm... I've just been bit by Debian Bug#347412 in Dapper (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=347412)
[08:31] <Ubugtu> Debian bug 347412 in linux-2.6 "using network (skge) and disk (SATA/promise) at same time = one breaks" [Grave,Open]
[08:32] <anders__> I am running latest released kernel, -27 something
[08:36] <towsonu2003> oh, star trek... bye
[10:08] <giskard> morning
[01:25] <gnomefreak> sfllaw: are you here? seems bugmail died.
[01:26] <Adri2000> gnomefreak: it's a know issue, also in #launchpad, but LP devs are on vacation, and it won't be fixed until they come back... :(
[01:26] <gnomefreak> ah so its not just the mail server for bug mail?
[01:28] <Adri2000> hmm, I don't know
[03:41] <bddebian> Boo
[03:42] <marnanel> boo
[03:42] <bddebian> :-)
[06:09] <tristanbob> what launchpad product is the "auto-play" portion of the CD?  (includes open source apps for windows)
[06:11] <Burgwork> tristanbob: are you talking about the Windows open source stuff? or the Ubuntu installer/
[06:11] <Burgwork> ?
[06:11] <tristanbob> also:  what product is the partitioner part of ubiquity?  (file under ubiquity?)
[06:11] <tristanbob> Burgwork: windows
[06:11] <Burgwork> just ubiquity for the installer, assuming you are talking the graphical part
[06:11] <tristanbob> Burgwork: did you notice that the version number says 6.06
[06:11] <Burgwork> as for the windows, no idea
[06:12] <tristanbob> Burgwork: yes, the graphical partioner to resize partitions (I would like to file a bug in the right product)
[06:20] <Burgwork> that would be ubiquity
[06:24] <tristanbob> "ubiquity does not use Malone as its bug tracker."
[06:25] <tristanbob> where is the right place?
[06:29] <nixternal> tristanbob: https://bugs.launchpad.net/distros/ubuntu/+source/ubiquity/+bugs
[06:29] <nixternal> holy smokes, 609 ubiquity bugs alone
[06:30] <tristanbob> that is wierd, I thought it was not in launchpad
[06:31] <tristanbob> nixternal: https://bugs.launchpad.net/products/ubiquity
[06:31] <nixternal> that is because we aren't the maintainers for ubiquity upstream that is debian i believe
[06:32] <nixternal> and i am wrong it seems
[06:53] <tristanbob> nixternal: :)  am I allowed to "confirm" a bug?  or only QA people?
[06:53] <nixternal> you can confirm i think
[06:53] <Shadow42> Anyone can confirm
[06:53] <nixternal> that's what i thought, wasn't 100% sure though, thanks Shadow42
[06:53] <tristanbob> I cannot find how...
[06:53] <Shadow42> np
[06:54] <Shadow42> tristanbob: You're on the bug's page?
[06:54] <tristanbob> oh click on the package name
[06:54] <Shadow42> Yep
[06:57] <tristanbob> does anyone know what happens if I try to resize a partition smaller than the data already on the drive? (Ubiquity partion resizing)
[06:57] <tristanbob> do I get a warning?
[06:57] <Shadow42> I would hope so
[06:57] <Shadow42> Hang on, I'll boot a spare machine and check
[06:58] <Shadow42> tristanbob: Dapper or Edgy?
[06:58] <tristanbob> Edgy
[06:58] <Shadow42> Good
[06:59] <Shadow42> Whoa
[06:59] <tristanbob> Shadow42: thanks for checking
[06:59] <Shadow42> I found a Breezy install CD in this machine's drive
[06:59] <Shadow42> tristanbob: No problem
[06:59] <tristanbob> here is a related bug that I have confirmed
[06:59] <tristanbob> https://bugs.launchpad.net/distros/ubuntu/+source/ubiquity/+bug/52830
[06:59] <Ubugtu> Malone bug 52830 in ubiquity "Installer doesn't comfirm resizing partitions" [Undecided,Confirmed]
[06:59] <Shadow42> Hmm
[07:01] <tristanbob> I am hoping it will not try to resize a partition smaller than the data on the drive
[07:01] <tristanbob> or am I wrong?
[07:01] <Shadow42> I would think that it wouldn't
[07:01] <Shadow42> could you link the bug's URL?
[07:04] <tristanbob> I don't think there is a bug for that yet, I would add a bug if there is no warning
[07:04] <Shadow42> Oh
[07:04] <tristanbob> becareful, the resizing happens IMMEDIATELY after hitting NEXT.  I thought it would all occur after the confirmation screen.
[07:06] <Shadow42> I did about 3 Edgy installs this past week, and I think it added the resize to the operation queue
[07:08] <tristanbob> I did 2 Egdy installs this week, and it "froze" when I hit next on the resize page
[07:08] <Shadow42> Hmm
[07:11] <tristanbob> it wasn't frozen, it was just resizing the partition
[07:13] <Shadow42> Sorry about that, my wireless froze up
[07:13] <tristanbob> it wasn't frozen, it was just resizing the partition
[07:14] <Shadow42> Hmm
[07:25] <Shadow42> tristanbob: Well, Ubiquity doesn't seem to like the machine I'm using
[07:26] <Shadow42> Let me try it on this machine, I'll be right back
[07:26] <tristanbob> thanks Shadow42
[07:26] <Shadow42> np
[07:27] <tristanbob> be careful about losing data
[07:27] <Shadow42> Bah, I'll resize the Windows partition, I can afford it ;)
[07:39] <Shadow42> tristanbob: Nope, it won't let you resize to a size smaller than the existing data
[07:39] <tristanbob> cool!  does it give an error?
[07:39] <tristanbob> does the slider bar stop moving?
[07:40] <Shadow42> Nope, it just won't let you do it
[07:40] <Shadow42> If you drag the slider, it stops at the limit
[07:40] <tristanbob> so the slider bar slides to the limit, cool that is a good design
[07:40] <Shadow42> If you try to type it in manually, it will only resize to the limit
[07:40] <tristanbob> also good
[07:40] <Shadow42> mm hmm
[07:40] <tristanbob> now it just needs a confirmation screen, or wait to resize until the end
[07:40] <tristanbob> hit next and see if it resizes.... ;)
[07:40] <Shadow42> :)
[07:41] <tristanbob> I think it does
[07:41] <Shadow42> That's a confirmed bug, right?
[07:41] <tristanbob> I confirmed it just this morning
[07:41] <Shadow42> Excellent