[00:00] <raevol> there's been a lot of work done on it since it was pulled into maverick before release, and i'd like to take advantage of some of the new code :/
[00:02] <RAOF> There's always xorg-edgers.
[00:02] <raevol> yea i'm not that harcore :[
[00:02] <raevol> hardcore* god my typing is terrible today
[00:14] <cnd> RAOF, I have good news :)
[00:15] <cnd> I'm right now packaging all the stuff up to test and push to my ppa tonight
[00:15] <RAOF> cnd: Excellent.
[00:16] <RAOF> I'll try to have 1.10RC2 merged by the time you're ready, then :)
[00:20] <RAOF> cnd: You've been a-workin' on the weekend? :(
[00:21] <cnd> RAOF, umm, and last weekend too...
[00:21] <cnd> I haven't had a day off for two weeks now :(
[00:22] <cnd> RAOF, when will you be uploading xorg-server to ubuntu (or to git)?
[00:22] <cnd> when I'll be able to get the source, basically
[00:23] <RAOF> I'll probably be able to get it done today, so that would be in <6hrs time.
[00:24] <cnd> ok, so after I
[00:24] <cnd> I'm asleep :)
[00:24] <RAOF> I was thinking that we'd use this opportunity to also fold in the Xi 2.1 stuff; that'll just be a couple of patches, right?
[00:24] <cnd> yeah
[00:24] <cnd> so if you want, you can push to git
[00:24] <cnd> and then I can push my updates to git
[00:24] <cnd> and then you can upload
[00:24] <cnd> sound good?
[00:25] <RAOF> That'd work.
[00:25] <cnd> RAOF: when do you want to push by?
[00:26] <RAOF> If you've got stuff ready now you could just push to git and I'd just fold that in with the rest of the merge.\
[00:26] <cnd> it's not ready quite yet
[00:26] <RAOF> Or you can push after me, which would be tomorrow morning for you I guess ;)
[00:26] <cnd> I'm making packages right now
[00:26] <cnd> and then I need to test locally
[00:26] <RAOF> Soft!
[00:26] <cnd> and I was hoping to have one day tomorrow to have people bang on it
[00:27] <RAOF> Real men test in the archive :)
[00:27] <cnd> heh
[00:27] <RAOF> Ok.
[00:27] <RAOF> There's no OMGHUGE rush for the merge; a day's testing wouldn't hurt it, either.
[00:27] <cnd> k
[00:29] <cnd> I'm so excited :)
[00:29] <RAOF> Obviously FF is our deadline :)
[00:29] <RAOF> And you just can't hide it?
[00:29] <cnd> especially since it actually works :)
[00:29] <RAOF> :D
[00:29] <cnd> the one thing holding me back is that I'm still glossing over a few things
[00:30] <cnd> like what do you do for pointer emulation of a new touch when there's an active grab on the pointer?
[00:30] <cnd> corner cases like that
[00:30] <RAOF> Fiendish protocol-level corner cases.  Yay.
[00:30] <cnd> I think it won't fall over, but I'm not 100% sure it'll behave as one might assume
[00:30] <RAOF> And you'll also get to take a couple of days off once the FF deadline hits, right?
[00:31] <cnd> heh, I hope so :)
[00:31] <cnd> oubiwann is awesome, he'll probably make me take the time off :)
[00:31] <RAOF> :)
[01:03] <cnd> testing looks good, time to push to git repos and make source packages :)
[01:13] <cnd> tjaalton, it looks like you've uploaded a new libxi, but the git tree hasn't been updated
[01:13] <cnd> can you update it for me?
[01:31] <RAOF> Ooh, funky.  Damage bugs!
[01:56] <cnd> it takes waaaay too long to upload a qt package...
[01:56] <cnd> 207 MB source tarball...
[01:58] <RAOF> Xi2.1 Qt?
[06:40] <tjaalton> cnd: it's been synced from debian, there were no ubuntu changes
[06:58] <RAOF> Oh, no.  intel/nouveau switcheroo problems :(
[06:58] <RAOF> I suspect bug #718620 of being switcheroo related.
[06:58] <ubot4> Launchpad bug 718620 in xorg-server (Ubuntu) "Xorg assert failure: X: ../../dix/pixmap.c:118: AllocatePixmap: Assertion `pScreen->totalPixmapSize > 0' failed. (affects: 9) (dups: 11) (heat: 92)" [Medium,New] https://launchpad.net/bugs/718620
[07:45] <tjaalton> RAOF: regarding bug 718331, there's a newer upstream release which could help
[07:45] <ubot4> Launchpad bug 718331 in xf86-input-wacom (Ubuntu Natty) (and 1 other project) "Xorg crashes on wacom input moule (affects: 5) (dups: 1) (heat: 30)" [High,Incomplete] https://launchpad.net/bugs/718331
[07:45] <RAOF> tjaalton: Aah, quite possibly.
[07:45] <RAOF> Argh.  Why doesn't everyone have debugging symbols installed all the time? :(
[07:45] <tjaalton> 0.10.11, though .12 should be arriving too at some point
[07:45] <tjaalton> right :)
[07:46] <tjaalton> all the xorg-packages should imho also have a -dbg counterpart
[07:46] <tjaalton> but wacom is maintained by ron
[07:46] <RAOF> Nah; -dbgsym is easy.
[07:46] <tjaalton> it's not apt-get'able?
[07:46] <RAOF> *Debian* should have -dbgsym, and we should drop all the trivial -dbg packages.
[07:46] <RAOF> tjaalton: It totally is.
[07:46] <tjaalton> oh
[07:47] <RAOF> See https://wiki.ubuntu.com/DebuggingProgramCrash :)
[07:47] <tjaalton> i'm missing the source then
[07:48] <tjaalton> fixed
[07:48] <RAOF> I wonder whether we shouldn't have that in the default sources.
[07:49] <RAOF> At least during development.
[07:49] <tjaalton> right
[07:50] <tjaalton> huh, uses a different signing key
[07:54] <tjaalton> oh wacom 0.10.11 was released last week, so it's quite fresh
[08:02] <RAOF> cnd: xserver is in git, for your delectation.
[08:02] <RAOF> tjaalton: I don't suppose you have a switchable graphics system to confirm my suspicion that 718620 is switcheroo-based (and get a better backtrace at the same time ☺)?
[08:03] <tjaalton> RAOF: nope..
[08:03] <tjaalton> does switcheroo work on a desktop with embedded and discrete graphics, or is it laptop only? (not that I have such a desktop either)
[08:04] <RAOF> It requires ACPI support; it's likely that only laptop manufacturers bother.
[08:04] <tjaalton> ok
[08:57] <tjaalton> RAOF: i've a patch to fix mumble, will push soon
[08:57] <tjaalton> to xorg-server
[09:25] <RAOF> tjaalton: Sweet.  I'd also like to convince myself that 718620 isn't an xserver problem.
[09:27] <tjaalton> RAOF: yeah, nasty..
[09:28] <tjaalton> lunch->
[09:31] <RAOF> It's probably something in the plymouth integration patch that doesn't work when copy_from_fb fails.
[11:51] <tjaalton> eh, https://launchpad.net/xserver
[12:54] <cnd> tjaalton, true, but I still can't find it in git
[12:54] <cnd> I can push the changes to git though
[12:58] <tjaalton> cnd: the ubuntu-branch there is stale, last updated 21 months ago
[12:58] <tjaalton> cnd: so you can pretty much do whatever you like with it :)
[13:02] <cnd> yeah
[13:25] <apw> cnd, playing with mumble to try and work out why the PPT buttons don't work
[13:26] <apw> its looking like the xserver hasn't sent us the events we asked for ... is there any way to ask the Select extenstion whats goign on?
[13:26] <apw> or any small examples of asking for key events i can use for testing
[13:26] <jcristau> there's a fix for the mumble thing in git, aiui
[13:26] <apw> oh ... pthth ...
[13:27] <apw> jcristau, got a pointer to the git so i can look ?
[13:27] <jcristau> http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=commitdiff;h=74acb8b958a0e19beae993f0c1f4627ab2296ee0
[13:28] <apw> jcristau, oh so its an xserver issue ...
[13:28] <jcristau> (also at http://patchwork.freedesktop.org/patch/4200/)
[13:29] <apw> do we already have that fix coming?  and i am just behind or ?
[13:29] <jcristau> it's queued for whenever the next upload is, i think
[13:29] <apw> jcristau, heh then thank you i can go back to ignoring it for a bit :)
[13:33] <tjaalton> apw: you're subscribed to the bug, should've seen that it's "fix committed" :)
[13:35] <cnd> apw: the next upload should be tomorrow
[13:35] <cnd> with my multitouch stuff :)
[14:36] <apw> tjaalton, heh oops
[14:36] <apw> cnd, sounds good ... except i expect it'll be all broke :)
[14:37] <cnd> apw, of course it will!
[14:37] <cnd> I'm going to try my hardest to somehow cause a kernel panic from multitouch :)
[15:11] <ricotz> Sarvatt, hi, perhaps it is useful to propose the pixman update before FF while the notify-osd update seems to take longer
[15:17] <lilstevi> is there a way to get an onscreen keyboard to automatically launch with netbook launcher
[15:33] <tjaalton> ricotz: national holiday in US today ;)
[15:34] <ricotz> tjaalton, oh, ok ;)
[16:03] <Sarvatt> ricotz: yeah been 2 weeks now, sounds good to me :)
[16:16] <ricotz> Sarvatt, are you able to sponsor it?
[16:17] <Sarvatt> ricotz: nope I don't have permissions for it. tjaalton, would ya be willing to sponsor a pixman 0.20.2 update for ricotz? his update looked good to me when I reviewed it
[16:18] <ricotz> tjaalton, that would be great http://people.ubuntu.com/~ricotz/pixman/
[16:21] <Sarvatt> 0.21.x isn't appropriate for natty, 0.20.2 is the latest stable release, there is just an issue with notify-osd popups looking screwed up that has been waiting to have the fix uploaded since december but feature freeze and all, dont think we can wait anymore
[16:23] <seb128> it's easy enough to grab the notify-osd commit and upload to natty
[16:24] <seb128> don't bother about small breakages in unstable series
[16:24] <ricotz> seb128, yeah, macslow said he wanted to do it soon
[16:24] <seb128> usually having things broken motivate to get the fix in when that has been not really moving for a while
[16:24] <seb128> he was sick this weekend and has work to finish before feature freeze
[16:25] <seb128> so it's likely to not land before feature freeze
[16:25] <ricotz> right, but we wanted to prevent a bug flood ;)
[16:25] <ricotz> ok
[16:25] <Sarvatt> seb128: well I was getting a crazy amount of emails about the problem just from edgers and was worried about when it actually went in the distro
[16:26] <seb128> can't you just upload a notify-osd with the patch in natty?
[16:26] <Sarvatt> not sure the guy signed the contributor agreement
[16:27] <seb128> Sarvatt, no need to have a c-a for a distro patch
[16:28] <seb128> that's only an issue to merge in the upstream trunk
[16:44] <tjaalton> Sarvatt: sure, i'll upload it later when i'm back home
[16:53] <ari-tczew> shrugs, when we will get new nvidia driver?
[16:55] <ricotz> tjaalton, thanks
[16:57] <ricotz> ari-tczew, depends on when nvidia decides to release a working one
[16:58] <ari-tczew> ricotz: changing resolution and fan's speed every boot making me crazy
[17:00] <ricotz> ari-tczew, nouveau should work pretty fine detecting the right resolution, of course it doesnt take care of your fan speed
[17:01] <ari-tczew> ricotz: 1024x768 is not native resolution for my lcd
[17:01] <ari-tczew> so it's not prettty
[17:02] <ricotz> ok, if you are nouveau and nvidia blob is removed, it looks like a bug which might be reported
[17:02] <ricotz> probably an edid problem
[17:42] <alex_mayorga> on bug 553789 should I provide further peeks?
[17:43] <ubot4> Launchpad bug 553789 in xserver-xorg-video-nouveau (Ubuntu) (and 2 other projects) "X freeze/crash with nouveau driver (affects: 22) (dups: 5) (heat: 108)" [High,Confirmed] https://launchpad.net/bugs/553789
[17:43] <alex_mayorga> X keeps freezing every 2-4 hours or so
[17:44] <alex_mayorga> what else should I gather?
[17:44] <alex_mayorga> I have an ssh window to the frozen laptop
[17:47] <alex_mayorga> bryceh: ping
[17:50] <tjaalton> alex_mayorga: no
[17:52] <alex_mayorga> tjaalton: so for now is just patience and frequent reboot?
[17:52] <alex_mayorga> or should I try edgers or something?
[17:52] <alex_mayorga> or is there a way to restar X from an ssh window?
[17:53] <hyperair> restart gdm
[17:53] <hyperair> or rather, sudo restart gdm
[17:53] <alex_mayorga> hyperair: thanks! Let me try that
[17:55] <alex_mayorga> didn't do unfortunately
[17:58] <tjaalton> alex_mayorga: there is no known fix, nor is there one on the horizon
[17:58] <alex_mayorga> tjaalton: I see, this would bug me on every distro right?
[17:59] <tjaalton> a workaround is to disable acceleration, the upstream bug, at least, has th details
[17:59] <alex_mayorga> also I hear the nvidia blob is not much better anyway
[17:59] <tjaalton> yes
[17:59] <alex_mayorga> let me review, but I think accel is already off here
[18:08] <alex_mayorga> is there other driver that I can use other than nouveau
[18:08] <alex_mayorga> vesa perhaps?
[18:14] <tjaalton> not unless you disable kms
[18:15] <yofel> really? I did try vesa as a replacement for nouveau once, did work, but with rather low resolution
[18:16] <yofel> could be that I had nvidia installed and just nouvea blacklisted maybe
[18:17] <tjaalton> probably
[18:19] <yofel> I'll try nouveau.noaccel=1 later, I don't use it anyway
[18:21] <yofel> tjaalton: would my bug be a dup of that one too? I think so since I've an GT218 here
[18:23] <tjaalton> yofel: dunno, i'd have to check
[18:24] <yofel>  bug 711908
[18:24] <ubot4> Launchpad bug 711908 in xserver-xorg-video-nouveau (Ubuntu) "[natty] frequent nouveau freeze on GT218 [NVS 3100M] (rev a2) (affects: 2) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/711908
[18:27] <tjaalton> yofel: yeah looks like it
[18:28] <tjaalton> i can reproduce it when i _disable_ dri
[18:28] <tjaalton> though i have nv5x
[18:28] <tjaalton> and had to switch firefox to chromium
[18:29] <tjaalton> otherwise it would crash, though the bt looks different
[19:05] <tjaalton> ricotz: no _source.changes for pixman?
[19:09] <ricotz> tjaalton, sorry, should be there now
[19:15] <tjaalton> ricotz: thanks, uploaded
[20:08] <cnd> bryceh, or anyone else who's a core dev: can someone review the utouch-grail upload and push to ubuntu?
[20:08] <cnd> https://bugs.launchpad.net/ubuntu/+source/utouch-grail/+bug/722780
[20:08] <ubot4> Launchpad bug 722780 in utouch-grail (Ubuntu) "Upload utouch-grail 1.0.19 to Ubuntu (affects: 1) (heat: 8)" [Undecided,New]
[20:08] <cnd> it's a dependency of the new xi 2.1 work
[20:09] <tjaalton> cnd: i can check it out a bit later
[20:09] <cnd> tjaalton, that would be great!
[20:10] <cnd> let me know if you need anything
[20:10] <tjaalton> sure
[22:12] <tjaalton> cnd: ok, what exactly should I do to upload it?
[22:12] <cnd> usually didrocks helps out, but he seems unavailable
[22:13] <cnd> we give him a link to our packaging branch
[22:13] <cnd> he builds the package and signs it
[22:13] <cnd> and uploads it
[22:13] <cnd> I can build it for you instead
[22:13] <cnd> if you'd prefer that
[22:13] <tjaalton> the source, yeah
[22:13] <tjaalton> or wait
[22:13] <tjaalton> I'll try something first
[22:13] <cnd> sure
[22:14] <cnd> the packaging branch is linked in the bug, if you've got that handy
[22:14] <tjaalton> yep
[22:15] <tjaalton> hmm no, I'd need the tarball anyway etc. guess it's best if you prepare the source and I'll debsign&dput it to the archive
[22:16] <cnd> ok
[22:16] <tjaalton> I haven't used bzr for packaging, so :)
[22:16] <cnd> ahh
[22:16] <tjaalton> don't know what the workflow is
[22:17] <cnd> it's actually quite nice, especially if you are doing packaging of new upstream sources
[22:18] <cnd> there's a command that takes the upstream tarball and the current packaging branch, and does crazy commits and merges for you
[22:18] <cnd> and then gives you a new commit in your packaging branch that's all ready for you to upload
[22:18] <tjaalton> alrighty
[22:21] <cnd> tjaalton, it's up at people.canonical.com/~cndougla/utouch/
[22:21] <tjaalton> oh it was a native package
[22:22] <tjaalton> but thanks, will upload
[22:23] <cnd> wait
[22:23] <cnd> no, it's should be native
[22:23] <cnd> tjaalton, why do you think it's native?
[22:23] <tjaalton> cnd: normally the upstream tarball is a separate file
[22:23] <cnd> oh wait
[22:23] <cnd> I forgot to put it there
[22:23] <cnd> let me upload it too
[22:24] <tjaalton> that explains it then :)
[22:24] <tjaalton> hmm EPERM too
[22:24] <tjaalton> +NO
[22:24] <tjaalton> :)
[22:25] <cnd> ?
[22:25] <cnd> I just uploaded the tarball
[22:25] <tjaalton> can't access them
[22:25] <tjaalton> forbidden
[22:25] <tjaalton> chmod 755?
[22:25] <cnd> I'll try
[22:25] <tjaalton> or 644 at least
[22:26] <cnd> tjaalton, I did chmod a+x *
[22:26] <cnd> sorry a+r
[22:26] <cnd> so hopefully you can get them now
[22:26] <tjaalton> yep
[22:27] <tjaalton> forgot to finalize the release?-)
[22:27] <cnd> oh yeah...
[22:27] <cnd> grrr
[22:27] <cnd> sorry
[22:28] <tjaalton> heh
[22:28] <cnd> usually didrocks does that for us :)
[22:28] <tjaalton> indeed, since he'd have to sign it himself
[22:28] <tjaalton> um
[22:28] <cnd> well, if you mean putting your name in the changelog
[22:28] <tjaalton> i mean create the source package
[22:28] <cnd> you can sign without doing that
[22:28] <tjaalton> yes
[22:29] <cnd> anyways, I'll create a new package as released
[22:29] <cnd> and upload again
[22:29] <tjaalton> cool
[22:29] <cnd> sorry for the trouble
[22:29] <tjaalton> np
[22:36] <cnd> tjaalton, ok, the new package is ready for you
[22:37] <tjaalton> cnd: and uploaded
[22:37] <cnd> tjaalton, thanks!
[22:39] <cnd> we need to make a packaging group for utouch so I can upload them...
[22:39] <cnd> I just never got around to requesting it
[22:39] <tjaalton> heh, right
[22:42] <bryceh> cnd, yep
[22:46] <bryceh> cnd, or just get core-dev ;-)
[22:46] <cnd> bryceh, how high is the bar for that?
[22:47] <cnd> I've so far only touched linux-firmware, utouch*, and x stuff
[22:48] <bryceh> cnd, generally you'd get motu first, which that's probably enough.
[22:48] <bryceh> it's more about "do we trust him" than "does he have enough experience"
[22:49] <cnd> I don't touch much in universe :)
[22:49] <bryceh> again, it's not so much a point of having experience in the area as much as being trusted to upload stuff in that area
[22:49] <cnd> and most of the stuff I do need privs for are core packages
[22:49] <cnd> ok
[22:50] <cnd> maybe I should at least attempt motu now
[22:50] <bryceh> once you've gotten motu, spend a bit of time doing some random package sponsorship and stuff for a month or two, to gain some sponsor statements (which should be easy for you), then put in for core dev.
[22:51] <cnd> ok
[23:10] <cnd> bryceh, RAOF: got some questions for you about versioning
[23:10] <cnd> we're pushing xi 2.1 stuff
[23:10] <bryceh> ok
[23:10] <RAOF> cnd: Shoot.
[23:10] <cnd> but there's no official upstream input proto packages yet
[23:10] <cnd> nothing like inputproto <IP_ADDRESS>1
[23:11] <bryceh> cnd, so you need a git snapshot?
[23:11] <cnd> so I've been just adding them into ubuntu patches on top of what's already there
[23:11] <cnd> well, it's not even upstream git snapshot yet
[23:11] <cnd> not in the official repo
[23:12] <cnd> so I've just been incremening the ubuntu version suffix
[23:12] <cnd> and adding patches
[23:13] <RAOF> That seems reasonable to me.
[23:13] <cnd> one issue is that for libxi lintian complains because we're adding symbols with an ubuntu version
[23:13] <bryceh> that can probably be ignored in this case
[23:13] <cnd> it's actually a lintian error
[23:13] <RAOF> Lintian is wrong.  Feel free to silence that with an override if you want.
[23:13] <cnd> will that cause an issue?
[23:13] <bryceh> don't think so
[23:14] <cnd> I didn't think so either, since I remember xorg-server having lintian errors too :)
[23:14] <RAOF> It'd cause an issue in Debian because dak's started to reject packages with lintian errors; I don't believe soyuz does that :)
[23:14] <cnd> ahh
[23:14] <bryceh> cnd, yeah doing incrementing ubuntu versions is probably fine.  I think I'd probably do it that way myself
[23:15] <cnd> ok
[23:15] <cnd> I'm going to prepare packages right now
[23:20] <RAOF> There's probably no way we can stick an ubuntu string into the input ABI version, is there?
[23:22] <cnd> RAOF, that sounds really ugly :)
[23:23] <cnd> but it may be helpful
[23:31] <cnd> RAOF, the alternative is to leave the input abi at 12
[23:31] <cnd> and to assume the input abi includes the new mt stuff in evdev and synaptics
[23:31] <cnd> I'm almost tempted to say that's a better route
[23:31] <RAOF> We could also bump the minor version of the input abi?
[23:32] <cnd> because in reality, input abi 13 should be backwards compatible with 12, but whot likes to bump the major version for some reason
[23:32] <cnd> RAOF, even that could potentially be an issue if they bump the minor version upstream
[23:32] <cnd> though that's highly unlikely at this point
[23:32] <cnd> rc2 is a little late for that :)
[23:32] <cnd> RAOF, ok, I'm thinking that may be a good idea
[23:33] <cnd> bump the minor to 12.3
[23:33] <RAOF> I think aaronp has declared the ABI frozen.
[23:33] <cnd> and I can convince whot to bump the major to 13 when mt is added
[23:33] <cnd> leaving the major at 13 would also mean we don't have to rebuild all the input module packages
[23:34] <RAOF> Major at 12, you mean?
[23:34] <cnd> I'm glad someone has finally declared it frozen :)
[23:34] <cnd> yeah, leaving it at 12
[23:34] <cnd> :)
[23:34] <bryceh> seriously
[23:35] <cnd> bryceh, was that in response to my comment about abi frozen declarations?
[23:35] <bryceh> cnd, yep
[23:35] <cnd> heh, ok
[23:35] <cnd> it puzzled me for a moment, I thought you had better ideas about the input abi handling :)
[23:35] <bryceh> not seriously
[23:36] <cnd> heh
[23:36] <cnd> everyone should play with qt's fingerpaint demo
[23:36] <cnd> it makes me happy :)
[23:37] <cnd> and they have a pinch to zoom demo where there's a giant world of cheese with mice running on it
[23:37] <cnd> and you can pinch to zoom in and out
[23:38] <RAOF> Oh, bah.
[23:39] <cnd> RAOF, btw, thanks for fixing that doxygen issue :)
[23:39] <cnd> it was really getting on my nerves :)
[23:39] <RAOF> Debian's X server Provides: xorg-video-abi-9, we Provides: xorg-video-abi-9.0
[23:39] <RAOF> cnd: KiBi also fixed it :)
[23:39] <cnd> ahh
[23:41] <RAOF> bryceh: Do we want to go with Debian's packaging and incur another rebuild of the world, or diverge for now to include the minor version in those ABI virtual packages too?
[23:42] <cnd> tjaalton, I think your xi 1.x fix is causing warnings:
[23:43] <cnd> http://pastebin.ubuntu.com/570315/
[23:43] <cnd> just a guess since I think your patch touched that file
[23:44] <cnd> RAOF, so you think you'll be ready for uploads today?
[23:44] <RAOF> cnd: I think so, yes.
[23:44] <cnd> cool


[12:21] <alefteris> could any of tha people that can edit the http://www.ubuntu.com/support/community/webforums page, update it?
[12:21] <pep> Greetings
[12:21] <alefteris> there are a couple of launchpad bugs about it for a log time..
[12:22] <alefteris> long*
[12:22] <Volans> alefteris can you put here bug numbers?
[12:23] <alefteris> Volans, sure: #231584, #244616, #237120
[12:23] <Volans> bug 231584 ;  bug 244616 ; bug 237120
[12:23] <ubot3> Malone bug 231584 in ubuntu-website "add ubuntu-gr forum" [Undecided,Confirmed] https://launchpad.net/bugs/231584
[12:23] <ubot3> Malone bug 244616 in ubuntu-website "Invalid Portuguese Ubuntu Forum link" [Undecided,Confirmed] https://launchpad.net/bugs/244616
[12:23] <ubot3> Malone bug 237120 in ubuntu-website "Update LoCo Team List for Japanese Team" [Undecided,Confirmed] https://launchpad.net/bugs/237120
[12:25] <Volans> alefteris: as you can see I have replied to all those three bugs and assigned them to newz2000 (Matthew Nuzum)
[12:25] <Volans> He have the right permissions to do that, so I think he have put them into the todo list and probably will fix them asap
[12:26] <Volans> you can ask him directly but I don't know he will be here today (sunday), surely you can found him here tomorrow
[12:27] <alefteris> Volans, ok, its just seems to be busy with a milion other stuff and has got time to do updates on the drupal site. Maybe it would be good another person to be able to do simple edits like those?
[12:27] <alefteris> hasn't*
[12:28] <alefteris> newz2000, ping
[12:28] <Volans> I don't know if the oher people of the Ubuntu Website Editors Team ( https://launchpad.net/~ubuntu-website ) have write access to drupal
[12:29] <Volans> it seems that they have those rights: "This team contacts people who have editor rights to the website."
[12:29] <alefteris> Or even better move pages that need frequent updating to the wiki, so that we can edit them our selfs?
[12:30] <Volans> can be a solution but take consideration that for example the LocoTeam list page on the wiki is not always up to date
[12:32] <alefteris> Volans, well it more up to date than the drupal page about the forums
[12:32] <alefteris> melat0nin, do you have edit rights in the drupal site?
[12:32] <Volans> just for example: https://bugs.launchpad.net/ubuntu-website/+bug/244616/comments/2
[12:32] <ubot3> Malone bug 244616 in ubuntu-website "Invalid Portuguese Ubuntu Forum link" [Undecided,Confirmed]
[12:34] <alefteris> Volans, yeap, but what can you do about it. All team contact should know about the locoteams page and make an efford to keep it up to date.
[12:36] <Volans> sure! as a suggestion I think is better if you retry here tomorrow because on sunday is more difficult to find people ;)  I think also that Matt will read the backlog of the channel
[12:37] <alefteris> Volans, ok, I'll ping people and tommorow, thanks
[12:46] <melat0nin> alefteris: no, i'm afraid not
[13:02]  * Volans lunch time... see you later


[14:52] <someone235> מישהו יכול לעזור לי עם vsftpd?
[17:33] <avihay> what's that?
[17:34] <avihay> oh, ok
[17:34] <Interruptus> oi there
[17:35] <avihay> what's the trouble? I'm guessing you didn't set the proper permissions for the ftp user over the files you want to serve, but that's a blind shot in the dark
[17:35] <avihay> Interruptus: Ahoy!
[17:36] <avihay> or in other words, MOAR details
[17:36] <avihay> !
[17:36] <Interruptus> MOAR sauce
[18:06] <yharrow> ohaydere
[18:07] <yharrow> wuts up guys
[18:30] <Interruptus> not too bad


[05:31] <halfie> does Ubuntu maintain a list of packages which must be hardened for security reasons?
[06:13] <kees> halfie: everything hardened by default in Ubuntu
[06:13] <kees> (though you may have a more specific definition of "hardened")
[06:30] <doko> kees!
[07:59] <halfie> kees, are you sure? by hardening I mean stuff like RELO / PIE being enabled.
[08:05] <halfie> it seems that the Ubuntu compiler doesn't enable hardening by default. so do you enable hardening for every packages on individual basis?
[08:15] <jtaylor> halfie: since ~quantal or precise yes
[08:15] <jtaylor> automatic hardening is not enabled anymore
[08:16] <halfie> but like kees says hardening is enabled for almost all packages? correct?
[08:16] <halfie> seems hard to believe
[08:16] <jtaylor> probably almost all in main
[08:16] <jtaylor> in universe coverage is probably less good
[08:16] <halfie> cool :)
[08:17] <halfie> I can use Ubuntu's example to drive hardening in Fedora then
[08:17] <jtaylor> I think some things may still be enabled by default, like FORTIFY_SOURCE_
[08:17] <halfie> and same rules apply on both x86 and AMD64, right? if a package is hardened then it is hardened on both?
[08:17] <jtaylor> yes, though pie is seldom enabled
[08:18] <jtaylor> on i386 it has a rather large performance impact
[08:18] <halfie> aha I see. yes on i383 PIE is crap.
[08:18] <halfie> so do you disable PIE on i386 then ?
[08:19] <halfie> but enable it for the same package when building for AMD64
[08:19] <jtaylor> its enabled on per package basis, so far I know its usually all off or all on
[08:19] <halfie> ok, makes less of a maintenance burden this way I guess.
[08:20] <jtaylor> you may want to read this: http://wiki.debian.org/Hardening
[08:20] <halfie> jtaylor, already been there :). I have scanned all Fedora packages using custom written script. Now I am planning to do the same for Ubuntu.
[08:20] <halfie> I will be using "python-debian" package for doing this
[08:20] <jtaylor> we already have scripts for checking if hardening is enabled
[08:21] <jtaylor> hardening-check
[08:21] <jtaylor> it does have some sisues though
[08:21] <halfie> jtaylor, does it work on any platform and does it run straight on .deb files without installing them?
[08:21] <jtaylor> it works on ELF files
[08:22] <halfie> my script doesn't need packages to be installed and it doesn't touch the disk except for reading. I have "checksec" for running on ELF files.
[08:23] <jtaylor> what does it do?
[08:23] <halfie> I will take a look at hardening-check though. Maybe it has some neat ideas :)
[08:23] <halfie> https://github.com/kholia/checksec <== it scans package repositories and figures out various bits
[08:24] <halfie> Now I am planning to add .deb support to it.
[08:24] <halfie> BTW is there a Python / Ruby library for parsing .deb files? "python-debian" is kind of broken.
[08:28] <jtaylor> broken in what way?
[08:28] <halfie> jtaylor, debian packages use "xz" compression now I believe? python-debian doesn't work for such files and python 2.x doesn't have lzma module
[08:29] <halfie> I am porting python-debian to Python 3
[08:31] <infinity> halfie: You may be interested in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506861
[08:32] <jtaylor> isn't pylzma support backported to py2?
[08:32] <halfie> infinity, awesome! :) you saved me hours of work :)
[08:32] <jtaylor> there is a python-lzmq module
[08:32] <jtaylor> ah thats also mentioned in the bug :)
[08:34] <halfie> also "xz" is the recommend scheme?
[08:34] <infinity> dpkg-deb defaults to gzip, but xz and bz2 are both widely used.
[08:35] <infinity> dpkg-deb (and python-debian) are meant to abstract that away, so you never need to care.
[08:35] <infinity> Well, python-debian would do so with the patch in that bug. :P
[08:36] <halfie> I am giving up porting to Python 3. It is hard :)
[08:37] <infinity> It's already ported in unstable, quantal, and raring.
[08:37] <halfie> to Python 3?
[08:37] <infinity> The patch in that bug applies to said ported version, if I recall.
[08:38] <infinity> Yes.  Binary package is python3-debian.
[08:38] <halfie> so the "python2-debian" has no support for "xz" ?
[08:38] <infinity> Neither one has support for xz, without that patch applied.
[08:38] <jtaylor> the changelog says it has support
[08:39] <jtaylor> as the mentioned bug in python is fixed
[08:39] <infinity> If you read the notes on the patch, it works with both py2 and py3, but cheats with py2 by just forking the xz binaries instead of using a module.
[08:41] <doko> you give up early ...
[08:52] <halfie> got disconnected. thanks infinity !
[08:56] <halfie> yay! success :)
[08:57] <halfie> now where exactly is metadata like packager's name, checksums stores? in the "control" section?
[09:19] <jtaylor> doko: I somehow managed to break python installation in a autopkgtest, see line 3429
[09:19] <jtaylor> doko: I can't seem to create a minimal testcase though :/ maybe you already see the cause
[09:19] <doko> jtaylor, which line/where?
[09:19] <jtaylor> the issue is python2.7-minimal is configured before libpython2.7-minimal
[09:20] <jtaylor> http://paste.ubuntu.com/5682267/
[09:28] <doko> maybe that should be a Pre-Depends ...
[10:04] <pjotr> Hello, I encountered a bug in Ubiquity that I've reported on Launchpad:
[10:04] <pjotr> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1165344
[10:05] <pjotr> cjwatson: maybe you could take a look at it (if you have the time, of course....)?
[10:06] <jtaylor> pjotr: probably a duplicate of bug 1080701
[10:08] <pjotr> jtaylor: yes, that looks like the same bug.... I'll tag mine as a duplicate. Thanks. :-)
[10:12] <cjwatson> halfie: Confused as to why you're porting python-debian to Python 3.  I did that port last year or so.
[10:12] <cjwatson> Oh, yeah, infinity already said that.
[10:42] <doko> jtaylor, please could you check https://launchpad.net/~doko/+archive/ppa ?
[10:52] <jtaylor> doko: seems to fix my problem
[10:54] <jtaylor> does it really need a pre-depends? isn't it the postinst that fails?
[10:58] <doko> jtaylor, please check it without it
[13:08] <halfie> cjohnston, thanks for porting python-debian to Python 3.
[13:15] <cjwatson> yw
[13:33] <halfie> I am running Fedora and trying to analyze Ubuntu packages. What would be a good way to get all the packages in "main" pool. It would be great if I could only get the latest versions of programs.
[13:36] <halfie> If there is no "bright" idea, then I will run rsync as the last option.
[13:39] <siretart> halfie: try 'debmirror'
[13:40] <siretart> halfie: http://manpages.ubuntu.com/manpages/precise/en/man1/debmirror.1.html
[13:40] <halfie> siretart, thanks, I am reading about it on https://help.ubuntu.com/community/Debmirror
[13:46] <halfie> how do I interpret this mode value "493" ? I found it in sudo 's .deb file.
[13:47] <cjwatson> halfie: on which file?
[13:48] <halfie> 493 ./usr/sbin/visudo
[13:48] <cjwatson> halfie: I think you would be less confused if you quoted modes in the conventional octal base, not decimal
[13:48] <cjwatson> 493 decimal == 755 octal
[13:48] <cjwatson> i.e. -rwxr-xr-x
[13:48] <halfie> oh, I could not guess the base earlier :) thanks!
[13:49] <cjwatson> The oct() builtin in Python may help
[13:49] <halfie> do you know a package which has a setuid file?
[13:49] <siretart> su?
[13:49] <cjwatson> /usr/bin/sudo
[13:49] <cjwatson> in the sudo package you're already looking at
[13:50] <halfie> oh right, its right in front of me
[13:50] <halfie> BTW PIE and  RELRO are disabled for sudo
[13:50] <cjwatson> Not in the current version
[13:50] <cjwatson> http://paste.ubuntu.com/5682875/
[13:51] <cjwatson> that's sudo 1.8.6p3-0ubuntu3 on amd64
[13:52] <halfie> now where did I get my package from then :S ?
[13:52] <cjwatson> I don't think that's a recent change either ...
[13:52] <cjwatson> Well, first you might like to cite which version you're looking at?
[13:52] <halfie> sudo_1.6.9p10-1ubuntu3.10_amd64.deb <== seems to be old
[13:53] <halfie> I got it from archive.ubuntu.com
[13:53] <cjwatson> That's the version in hardy, which is ancient
[13:53] <halfie> ah okay. I need to find a mirror which has latest packages.
[13:53] <cjwatson> Either use a mirroring tool to get raring, or parse raring's Packages files
[13:53] <cjwatson> Don't poke about in the pool directly unless you know exactly what you're doing
[13:54] <cjwatson> dists/raring/*/binary-*/Packages.gz are the indices
[13:54] <cjwatson> archive.ubuntu.com has all versions; it is not plausible that it doesn't have the latest ones
[13:54] <halfie> cjwatson, debmirror seems the way to go. does "python-debian" support parsing of those indices?
[13:54] <cjwatson> But it also has versions from every still-supported release
[13:54] <cjwatson> Yes
[13:55] <halfie> I see. Then I screwed up navigation of the archive.ubuntu.com tree :)
[13:55] <cjwatson> debian.deb822 specifically
[13:55] <cjwatson> Or just grep for the Filename fields
[13:56] <halfie> can I ask debmirror just to get latest "sudo" package? (I don't think so but is there an utility which can do this?). Maybe python-debian can help (parse indices and wget)
[13:56] <halfie> ahh okay, got it
[13:56] <cjwatson> That's not a sensible use of debmirror
[13:56] <halfie> true
[13:57] <cjwatson> Doesn't Fedora have an apt port?  You could set apt up with a local configuration file and use the apt-get download subcommand
[13:57] <cjwatson> Or as you say debian.deb822 + urllib or whatever can do it
[13:57] <cjwatson> Or you could set up an Ubuntu raring chroot with debootstrap and work in that
[13:58] <cjwatson> Several options :)
[13:58] <halfie> cjohnston, the first option is quite interesting, giving it a try :)
[13:59] <cjwatson> (Could you please remember to type more characters before hitting tab to avoid bugging poor cj ohnston all the time?)
[14:00] <halfie> ohh sorry, sure :)
[14:00] <halfie> I have gotten used to tabbing so much everywhere
[14:01] <cjohnston> halfie: 1 + 2 + 3 + tab
[14:01] <cjohnston> :-)
[14:01] <halfie> :D
[16:43] <mdeslaur> hrm, http://utcc.utoronto.ca/~cks/space/blog/linux/UbuntuAccountsServiceProblems


[13:18] <highvoltage> stgraber: do you happen to still have the password for https://lists.ubuntu.com/mailman/admin/edubuntu-council ?
[13:48] <mgariepy> good morning everyone
[13:55] <highvoltage> good morning
[14:09] <stgraber> highvoltage: yes
[14:10] <stgraber> highvoltage: look for an e-mail you sent me on the 1st of March 2011 (edubuntu-council list admin details)
[14:14] <stgraber> highvoltage: https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview feel free to improve (but quickly, we're about to release) :)
[14:19] <highvoltage> stgraber: ok, I'm technically in a meeting right now but will take a peek :)
[14:20] <stgraber> highvoltage: meetings are perfect time to do that kind of things :)
[14:25] <highvoltage> looks good
[17:10] <skaet> stgraber, highvoltage - edubuntu alpha 1 is released.
[17:16] <highvoltage> \o/
[17:16] <alkisg> :)
[17:33] <mhall119> highvoltage: any chance of me getting a few hours of your time this month to get your iso building working for Qimo?
[17:35] <highvoltage> mhall119: yep! the next week or so is a bit rough for me, but after that it should go better
[17:38] <mhall119> thanks highvoltage
[17:38] <mhall119> btw, if there's anything I can do to help edubuntu as Upstream Liason, let me know
[19:37] <highvoltage> mhall119: we'll most probably take you on on that :)
[19:38] <mhall119> Ill be happy to be of help again


[16:43] <Code_Bleu> Anyone here familiar with getting cloud-init to work on OpenBSD?  I keep having issues running the build-on-openbsd.
[17:54] <Code_Bleu> :(
[19:24] <meena> Code_Bleu: hi
[19:24] <meena> I'm working on getting better BSD support
[19:25] <meena> primarily FreeBSD, since it's FreeBSD Foundation sponsored, but I'm trying to lift all the BSDs
[19:58] <Code_Bleu> meena: Hey there! Is this something you can help me with getting cloud-init installed on OpenBDS 7.4?  The build-on-openbsd script doesn't seem to work for me.  I've been trying several different combonations of cloud-init versions, python version, installing of python packages...etc.  Each one gets me so far, but then breaks :(
[20:00] <meena> Code_Bleu: can you pastebin where each is failing?
[20:01] <meena> i need to get a fresh OpenBSD vm installed… after kiddo is asleep
[20:02] <meena> Code_Bleu: you can also check out Goneri's VM images and build scripts
[20:04] <Code_Bleu> meena: let me work on getting back to square one of getting minmal OpenBSD installed and the attempt to run the build from the cloud-init repo and I'll let you know.
[20:05] <Code_Bleu> meena: currently I was trying to install the needed python dependencies via pip instead of py3-xxxx in the script dependencies...but am having this issue with one of the packages it tries to install. - dpaste.com/4BP89Q5UP
[20:06] <Code_Bleu> http://dpaste.com/4BP89Q5UP
[20:09] <Code_Bleu> meena: FYI - I've been using this to create/spin up images ( minus Vagrant... im running the Make file directly on my Linux box that has the software already on it to spin up the qemu instances.) - https://github.com/sarnowski/openbsd-cloud-images
[20:31] <Code_Bleu> meena: Here is what I get with a basic install of OpenBSD minimal, clone the cloud-init repo and run the 'build-on-openbsd' script. - https://dpaste.com/44JAJCKYC
[20:44] <Code_Bleu> meena: well, I can't believe it...I was able to finally get it to install.  After looking at the error more ( up further ), it was erroring out on the python netifaces part.  I searched in the files locally for 'netifaces' and notices that the build-on-netbsd had a py3-netifaces as a dependency, but the build-on-openbsd did not. I added the py3-netifaces to that list and re-ran and it
[20:44] <Code_Bleu> installed!!.
[20:46] <Code_Bleu> meena: if this is part of your clean up for BSD, it would be nice if there was consistency on how those scripts work between BSDs.  OpenBSD one doesn't detect python version running, but others do. Maybe it doesn't matter, but would be nice to have support to detect Python version and install things needed based on that.
[20:59] <meena> 👍
[20:59] <meena> Code_Bleu: it would be nice if someone made a port
[21:34] <Code_Bleu> meena: how on BSD do i get cloud-init to run on first boot now?  I don't see a service.  Would i have to manually put something in /etc/rc.firsttime to do the 'cloud-init init' ?
[21:56] <meena> Code_Bleu: I think that's what Goneri does. On FreeBSD, we have rc scripts
[21:58] <meena> Would be nice to port them to OpenBSD (i reckon the existing NetBSD scripts might be closer to what you have on OpenBSD)
[22:16] <holmanb> hi @Code_Bleu
[22:17] <holmanb> @Code_Bleu: fyi it's more than just a `cloud-init init` that needs to happen
[22:20] <holmanb> @Code_Bleu: there are multiple stages - there are five different stages run during boot
[22:29] <holmanb> @Code_Bleu: the order that these are run is `ds-identify`, `cloud-init init --local`, `cloud-init init`, `cloud-init modules --mode=config`, `cloud-init modules --mode=final`
[22:29] <holmanb> for more details: https://cloudinit.readthedocs.io/en/latest/explanation/boot.html
[22:33] <holmanb> Code_Bleu: and some glue code is probably needed -> ds-identify is expected to identify which "cloud" the instance is running on. If no cloud is detected, cloud-init is expected to be disabled (this is the glue code I mentioned, on systemd this happens in a systemd-generator). Also this glue code should honor the cloud-init disablement methods
[22:33] <holmanb> Code_Bleu: the generator: https://github.com/canonical/cloud-init/blob/main/systemd/cloud-init-generator.tmpl
[22:34] <holmanb> Code_Bleu: the disablement methods: https://cloudinit.readthedocs.io/en/latest/howto/disable_cloud_init.html
[22:35] <holmanb> Code_Bleu: but if you get that ported to OpenBSD, happy to add the service scripts to upstream (here, I assume -> https://github.com/canonical/cloud-init/tree/main/sysvinit)
[22:45] <Code_Bleu> holmanb: thanks for info. That's a lot to digest.  I'm a total n00b for BSD, and have basic understanding of cloud-init on linux systems...so what should I do to make it to where cloud-init on OpenBSD will do what it needs to do at boot up?  I need to create an OpenBSD image to use on Cloudstack.
[22:46] <holmanb> Code_Bleu: sounds like you might want to start with one of Goneri's images?
[22:48] <Code_Bleu> holmanb: I did, and it never got me to a login screen in console.  Also, the latest version i see is 7.3 and I'm trying to install 7.4.  With installing this manually in QEMU I discovered the issue with not showing login screen in console of Cloudstack had to do with "switch to com0" set to "yes".  I had to set to "no" in my image and then it would work.
[22:48] <Code_Bleu> holmanb: my prefernce would be to be able to install OpenBSD 7.4 and get cloud-init to work :)
[22:49] <meena> Code_Bleu: Goneri has scripts for building images, so do take a look at those. You might be able to use them to build 7.4 image for cloudstack
[22:50] <Code_Bleu> I only found the website..and a github for his website...but didn't find any scripts that I remember.
[22:50] <Code_Bleu> holmanb: this is what im currently using to create image locally - https://github.com/sarnowski/openbsd-cloud-images
[22:51] <Code_Bleu> meena: you have a link to Goneri scripts you're talking about?
[22:51] <meena> gimme a sec
[22:51] <holmanb> Code_Bleu: Build from source on a not-so-frequently used OS that you're also not super familiar with sounds like an..... opportunity to learn lots ;)
[22:52] <holmanb> Code_Bleu: I'd follow meena's advice
[22:52] <Code_Bleu> holmanb: meena: yeh, this is def missing the OpenBSD :) I would assume to say cloud-init supports BSD now...it should prob have openbsd in there, right? - https://github.com/canonical/cloud-init/tree/main/sysvinit
[22:52] <meena> holmanb: that's how i learned all about Linux and Solaris :O
[22:52] <meena> In  my first year at work.
[22:53] <Code_Bleu> I like learning..so..
[22:53] <meena> now, 322093 years later…
[22:53] <holmanb> Code_Bleu:  good luck :-) let us know what bugs you shake out of cloud-init
[22:53] <Code_Bleu> I've built LFS and run Gentoo personally..so  :)
[22:53] <holmanb> Code_Bleu: same on the LFS and Gentoo -> great learning experiences
[22:54] <meena> Code_Bleu: here's the scripts Goneri uses to build his images: https://github.com/goneri/pcib
[22:57] <meena> Code_Bleu: if you're not in #OpenBSD, you should be. Ask someone to (help you) create a cloud-init net port. They only have this thing, which isn't fully fledged: https://github.com/openbsd/ports/blob/master/sysutils/cloud-agent/Makefile
[22:57] <meena> Pretty sure it won't work on CloudStack.
[22:57] <meena> in FreeBSD we have https://github.com/freebsd/freebsd-ports/tree/main/net/cloud-init and https://github.com/freebsd/freebsd-ports/tree/main/net/cloud-init-devel
[22:58] <Code_Bleu> meena: Yeh, I started in #openbsd.  Been talking in there for past few days....but just posted in there to see if anyone can help with the cloud-init service file stuff.
[22:59] <meena> As I mentioned earlier, I believe that the NetBSD rc scripts we have are probably closer to OpenBSD's rc script style than what we have in FreeBSD
[22:59] <meena> The ones in FreeBSD are pretty well fleshed out tho, as far as functionality goes
[22:59] <Code_Bleu> meena: i remember that Goneri repo now.. I remember it was old and saw old examples of openbsd..and when i read on cloud-init site that BSD is supported natively now...I went that path.
[23:00] <Code_Bleu> apparently BSD in cloud-init isn't fully baked either?  Is there a main contributor/maintainer that originally created the BSD stuff that is currently out there?
[23:00] <meena> Well, I think BSD is overselling it. That's like saying, Linux works, and expecting everything from Alpine to Debian to Gentoo to CoreOS to Android to just work :P
[23:01] <meena> Maybe we should specify FreeBSD (and DragonFly), with some solid foundations for NetBSD and OpenBSD
[23:01] <Code_Bleu> yeh. makes sense.
[23:02] <meena> I had a branch somewhere lying around where I actually started working on OpenBSD rc scripts, lemme see what I got there (if anything)
[23:03] <meena> yeah, that doesn't look useful. just a copy
[23:04]  * meena joins #OpenBSD again
[23:04] <Code_Bleu> https://cloudinit.readthedocs.io/en/latest/reference/distros.html


[23:50] <tsimonq2> pleia2: can the Ubuntu Release Calendar please be added back? http://ubuntu-news.org/calendars/
[23:51] <tsimonq2> pleia2: also, are you okay with me posting the Alpha 2 release announcement on the Fridge tomorrow? (I'm the one writing/publishing it)
[23:53] <pleia2> tsimonq2: have a link to the release calendar? I think we removed it because it was defunct
[23:53] <pleia2> and sure re: a2 announcement, just let us know in here when you're working on it so no one else grabs it :)
[23:54] <tsimonq2> pleia2: https://calendar.google.com/calendar/embed?src=ab54tjqqlaol3rdnksieju8mcc%40group.calendar.google.com
[23:55] <tsimonq2> pleia2: re: a2 will do :)
[23:55] <tsimonq2> pleia2: also, I'm updating the calendar \o./
[23:55] <tsimonq2> *\o/


[00:08] -queuebot:#ubuntu-release- Unapproved: accepted glib-networking [source] (focal-proposed) [2.64.2-1build1]
[00:20] -queuebot:#ubuntu-release- Unapproved: rejected apport [source] (focal-proposed) [2.20.11-0ubuntu28]
[02:31] -queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (focal-proposed) [3.36.1-5ubuntu2]
[02:46] -queuebot:#ubuntu-release- Unapproved: rejected desktop-file-utils [source] (focal-proposed) [0.24-1ubuntu3]
[02:52] -queuebot:#ubuntu-release- Unapproved: accepted xz-utils [source] (focal-proposed) [5.2.4-1ubuntu1]
[05:41] -queuebot:#ubuntu-release- Unapproved: accepted vala [source] (focal-proposed) [0.48.5-0ubuntu1]
[06:35] -queuebot:#ubuntu-release- Unapproved: accepted file-roller [source] (focal-proposed) [3.36.2-0ubuntu1]
[06:43] -queuebot:#ubuntu-release- Unapproved: accepted gedit [source] (focal-proposed) [3.36.2-0ubuntu1]
[07:50] -queuebot:#ubuntu-release- New binary: mshr [riscv64] (groovy-proposed/universe) [2019.2.0~git20200213.8895485+dfsg1-1] (no packageset)
[08:21] <tsimonq2> Is there a specific set of bug tags we can use when filing Debian bugs to track p-m blockage?
[08:22] <tsimonq2> I've seen something along those lines before.
[08:22] -queuebot:#ubuntu-release- New: accepted python-parasail [amd64] (groovy-proposed) [1.2-3]
[08:22] -queuebot:#ubuntu-release- New: accepted rust-protobuf-codegen-pure [amd64] (groovy-proposed) [2.8.1-2]
[08:22] -queuebot:#ubuntu-release- New: accepted rust-protobuf-codegen-pure [armhf] (groovy-proposed) [2.8.1-2]
[08:22] -queuebot:#ubuntu-release- New: accepted rust-protobuf-codegen-pure [s390x] (groovy-proposed) [2.8.1-2]
[08:22] -queuebot:#ubuntu-release- New: accepted r-cran-survminer [amd64] (groovy-proposed) [0.4.6+dfsg-2]
[08:22] -queuebot:#ubuntu-release- New: accepted rust-protobuf-codegen-pure [ppc64el] (groovy-proposed) [2.8.1-2]
[08:22] -queuebot:#ubuntu-release- New: accepted rust-protobuf-codegen-pure [arm64] (groovy-proposed) [2.8.1-2]
[08:23] -queuebot:#ubuntu-release- New: accepted dolfinx [amd64] (groovy-proposed) [2019.2.0~git20200420.6043d6d-4]
[08:23] -queuebot:#ubuntu-release- New: accepted dolfinx [armhf] (groovy-proposed) [2019.2.0~git20200420.6043d6d-4]
[08:23] -queuebot:#ubuntu-release- New: accepted dolfinx [s390x] (groovy-proposed) [2019.2.0~git20200420.6043d6d-4]
[08:23] -queuebot:#ubuntu-release- New: accepted mshr [arm64] (groovy-proposed) [2019.2.0~git20200213.8895485+dfsg1-1]
[08:23] -queuebot:#ubuntu-release- New: accepted mshr [ppc64el] (groovy-proposed) [2019.2.0~git20200213.8895485+dfsg1-1]
[08:23] -queuebot:#ubuntu-release- New: accepted mshr [s390x] (groovy-proposed) [2019.2.0~git20200213.8895485+dfsg1-1]
[08:23] -queuebot:#ubuntu-release- New: accepted dolfinx [arm64] (groovy-proposed) [2019.2.0~git20200420.6043d6d-4]
[08:23] -queuebot:#ubuntu-release- New: accepted mshr [amd64] (groovy-proposed) [2019.2.0~git20200213.8895485+dfsg1-1]
[08:23] -queuebot:#ubuntu-release- New: accepted mshr [riscv64] (groovy-proposed) [2019.2.0~git20200213.8895485+dfsg1-1]
[08:23] -queuebot:#ubuntu-release- New: accepted dolfinx [ppc64el] (groovy-proposed) [2019.2.0~git20200420.6043d6d-4]
[08:23] -queuebot:#ubuntu-release- New: accepted mshr [armhf] (groovy-proposed) [2019.2.0~git20200213.8895485+dfsg1-1]
[08:24] -queuebot:#ubuntu-release- New: accepted sugar [source] (groovy-proposed) [0.117-2~build2]
[08:26] -queuebot:#ubuntu-release- New binary: sugar [amd64] (groovy-proposed/universe) [0.117-2~build2] (no packageset)
[08:42] -queuebot:#ubuntu-release- New binary: qcat [amd64] (groovy-proposed/universe) [1.1.0-2] (no packageset)
[08:43] -queuebot:#ubuntu-release- New binary: r-bioc-tcgabiolinks [amd64] (groovy-proposed/universe) [2.14.1+dfsg-2] (no packageset)
[08:44] <tsimonq2> Laney, popey, Wimpress: Hi, how would I be able to edit https://discourse.ubuntu.com/t/groovy-gorilla-release-schedule/15531 ?
[08:44] <tsimonq2> I would like to add a transition on there but it seems I don't have edit access.
[08:46] <Laney> One of the second two can add you
[08:46] <Laney> We've got a request outstanding with IS to get that synced automatically with ~ubuntu-dev
[08:47] <tsimonq2> Awesome, thanks.
[08:49] <LocutusOfBorg> are autopkgtests running? the running page seems to be dead...
[08:50] <Laney> Yes
[08:50] <Laney> It's just unable to cope with the number of requests
[08:50] <tsimonq2> That's been a standing problem for a while, I'm curious where the bottleneck is there.
[08:51] <Laney> It hits rabbitmq synchronously
[08:51] <Laney> That needs to be moved out to a job or something, with /running just rendering something from the disk
[08:52] <Laney> https://pastebin.ubuntu.com/p/2c485xXY2y/
[08:52] <Laney> big queues are big
[08:53] <LocutusOfBorg> thanks, I was trying to figure out the queue size...
[08:53] <Laney> "big"
[08:53] <Laney> think that for the next many days :-)
[08:54] <LocutusOfBorg> I hope to see the page by the weekend :)
[09:05] <popey> tsimonq2 done
[09:05] <tsimonq2> popey: Thanks!
[09:06] <popey> np
[09:10] <tsimonq2> Laney: If someone were to cache the rabbitmq data to disk in prod, what might be the best place to put it?
[09:10] <tsimonq2> I remember hearing/reading somewhere that we have some things stored in /tmp, is that where such a file could be created?
[09:12] <tsimonq2> Otherwise, might it be part of the SQLite table? hm
[09:13] <tsimonq2> https://git.launchpad.net/autopkgtest-cloud/tree/webcontrol/browse.cgi#n321 answers my question.
[09:16] <Laney> Yeah, probably alongside that
[09:16] <Laney> You can get the *size* of the queue pretty fast actually
[09:16] -queuebot:#ubuntu-release- New: accepted qcat [amd64] (groovy-proposed) [1.1.0-2]
[09:16] -queuebot:#ubuntu-release- New: accepted sugar [amd64] (groovy-proposed) [0.117-2~build2]
[09:16] -queuebot:#ubuntu-release- New: accepted r-bioc-tcgabiolinks [amd64] (groovy-proposed) [2.14.1+dfsg-2]
[09:17] <Laney> Let me try something there
[09:17] <tsimonq2> What I'm looking at right now is splitting queue_info() ( https://git.launchpad.net/autopkgtest-cloud/tree/webcontrol/browse.cgi#n149 ) off into https://git.launchpad.net/autopkgtest-cloud/tree/webcontrol/download-results and repurposing the function to read from the cache.
[09:17] <tsimonq2> Would that be sane?
[09:36] <Laney> Ok I've pushed out a quick fix bandaid for this: https://git.launchpad.net/autopkgtest-cloud/commit/?id=fe9be4bb4ab4bf0e9aa44a97c2dd79d17f41f4a2
[09:37] <Laney> tsimonq2: Something like that
[09:37] <Laney> Probably not into download-results itself though, that is also a slow thing
[09:37] <Laney> but a new script
[09:38] <tsimonq2> Thanks.
[09:38] <tsimonq2> And makes sense.
[09:39] <Laney> I wonder how long it takes to run when the queues are this big
[09:39] <seb128> whoever keeps retrying nautilus builds please stop
[09:39] <seb128> I got like 6 rounds of failures since yesterday, a test is failing consistently hammering the retry button is just wasting builders resrouces
[09:43] -queuebot:#ubuntu-release- New binary: rust-librespot-protocol [amd64] (groovy-proposed/universe) [0.1.0-2] (no packageset)
[09:43] -queuebot:#ubuntu-release- New binary: rust-librespot-protocol [s390x] (groovy-proposed/universe) [0.1.0-2] (no packageset)
[09:43] -queuebot:#ubuntu-release- New binary: rust-librespot-protocol [ppc64el] (groovy-proposed/universe) [0.1.0-2] (no packageset)
[09:54] -queuebot:#ubuntu-release- New binary: rust-librespot-protocol [arm64] (groovy-proposed/universe) [0.1.0-2] (no packageset)
[09:54] -queuebot:#ubuntu-release- New binary: rust-librespot-protocol [armhf] (groovy-proposed/universe) [0.1.0-2] (no packageset)
[09:55] <wgrant> Upgrading the riscv64 buildds, will be offline for a few minutes
[09:57] <Laney> Hmm I've changed the format of queues.json, probably should fix that
[10:09] <Laney> http://autopkgtest.ubuntu.com/queue_size.json now exists
[10:10] <tsimonq2> Laney: Do you plan on making any additional changes?
[10:10] <tsimonq2> Otherwise I'll submit my MP.
[10:10] <tsimonq2> (After I adjust it for your changes of course.)
[10:11] <Laney> Not right now
[10:11] <tsimonq2> Sounds good.,
[10:13] <Laney> Probably all of that stuff I just touched should come from the external file
[10:14] <tsimonq2> Right, that's what I'm working on. :)
[10:14] <Laney> basically comes down to get_queue_info() and get_queue_requests() I guess
[10:14] <Laney> nice one
[10:15] <tsimonq2> My local copy has those two functions in a separate file.
[10:18] <locutus_> thanks wgrant!
[10:26] <locutus_> Laney, awesome fix!
[10:30] <tsimonq2> Laney: Take a peek at this and tell me what you think: https://code.launchpad.net/~tsimonq2/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/383129
[10:31] <tsimonq2> Wait, I forgot something, sec...
[10:33] <tsimonq2> There, now it should look slightly more accurate.
[10:33] <Laney> ok thanks, I'll look in a bit
[10:34] <tsimonq2> Sounds good.
[11:18] -queuebot:#ubuntu-release- New binary: fp16 [s390x] (groovy-proposed/none) [0.0~git20200412.3c54eac-2] (no packageset)
[11:19] <juliank> dpkg: error processing archive /tmp/apt-dpkg-install-0qoMnB/65-sqv_0.16.0-1_amd64.deb (--unpack):
[11:19] <juliank>  trying to overwrite '/usr/.crates2.json', which is also in package ripgrep 12.0.1-1
[11:19] <juliank> ugh
[11:19] <juliank> that sounds rusty
[11:20] -queuebot:#ubuntu-release- New binary: fp16 [ppc64el] (groovy-proposed/universe) [0.0~git20200412.3c54eac-2] (no packageset)
[11:21] -queuebot:#ubuntu-release- New binary: fp16 [armhf] (groovy-proposed/universe) [0.0~git20200412.3c54eac-2] (no packageset)
[11:21] -queuebot:#ubuntu-release- New binary: pthreadpool [armhf] (groovy-proposed/universe) [0.0~git20200423.6acde9c-2] (no packageset)
[11:23] -queuebot:#ubuntu-release- New binary: fp16 [arm64] (groovy-proposed/universe) [0.0~git20200412.3c54eac-2] (no packageset)
[11:23] -queuebot:#ubuntu-release- New binary: pthreadpool [arm64] (groovy-proposed/universe) [0.0~git20200423.6acde9c-2] (no packageset)
[11:24] <doko> wgrant: is that the qemu update?
[11:26] <wgrant> doko: qemu, kernel, firmware, bootloader
[11:26] <wgrant> But yes, mostly reverting the qemu downgrade
[11:32] -queuebot:#ubuntu-release- New binary: pthreadpool [amd64] (groovy-proposed/universe) [0.0~git20200423.6acde9c-2] (no packageset)
[11:33] -queuebot:#ubuntu-release- New binary: fp16 [amd64] (groovy-proposed/universe) [0.0~git20200412.3c54eac-2] (no packageset)
[11:35] -queuebot:#ubuntu-release- New binary: onnx [amd64] (groovy-proposed/universe) [1.6.0+dfsg-2] (no packageset)
[11:54] -queuebot:#ubuntu-release- New binary: fp16 [riscv64] (groovy-proposed/universe) [0.0~git20200412.3c54eac-2] (no packageset)
[12:22] -queuebot:#ubuntu-release- New: accepted fp16 [amd64] (groovy-proposed) [0.0~git20200412.3c54eac-2]
[12:22] -queuebot:#ubuntu-release- New: accepted fp16 [armhf] (groovy-proposed) [0.0~git20200412.3c54eac-2]
[12:22] -queuebot:#ubuntu-release- New: accepted fp16 [riscv64] (groovy-proposed) [0.0~git20200412.3c54eac-2]
[12:22] -queuebot:#ubuntu-release- New: accepted fp16 [arm64] (groovy-proposed) [0.0~git20200412.3c54eac-2]
[12:22] -queuebot:#ubuntu-release- New: accepted fp16 [s390x] (groovy-proposed) [0.0~git20200412.3c54eac-2]
[12:22] -queuebot:#ubuntu-release- New: accepted fp16 [ppc64el] (groovy-proposed) [0.0~git20200412.3c54eac-2]
[12:22] -queuebot:#ubuntu-release- New: accepted rust-librespot-protocol [amd64] (groovy-proposed) [0.1.0-2]
[12:22] -queuebot:#ubuntu-release- New: accepted rust-librespot-protocol [armhf] (groovy-proposed) [0.1.0-2]
[12:22] -queuebot:#ubuntu-release- New: accepted rust-librespot-protocol [s390x] (groovy-proposed) [0.1.0-2]
[12:23] -queuebot:#ubuntu-release- New: accepted rust-librespot-protocol [arm64] (groovy-proposed) [0.1.0-2]
[12:23] -queuebot:#ubuntu-release- New: accepted rust-librespot-protocol [ppc64el] (groovy-proposed) [0.1.0-2]
[12:23] -queuebot:#ubuntu-release- New: accepted onnx [amd64] (groovy-proposed) [1.6.0+dfsg-2]
[12:23] -queuebot:#ubuntu-release- New: accepted pthreadpool [arm64] (groovy-proposed) [0.0~git20200423.6acde9c-2]
[12:23] -queuebot:#ubuntu-release- New: accepted pthreadpool [amd64] (groovy-proposed) [0.0~git20200423.6acde9c-2]
[12:23] -queuebot:#ubuntu-release- New: accepted pthreadpool [armhf] (groovy-proposed) [0.0~git20200423.6acde9c-2]
[13:13] <xnox> Laney: sil2100: vorlon: how come I don't see groovy daily builds on cdimage?
[13:13] <xnox> are they off on purpose?
[13:14] <Laney> not on yet, I think sil2100 was waiting to hear back from snap people that they did the branch thing
[13:15] <Laney> but basically not me guv
[13:15] <sil2100> xnox, Laney: let me take a look if everyone answered
[13:17] <sil2100> Ok, looks like it should be safe
[13:17] <sil2100> A while ago I also enabled daily focal builds
[13:20] <sil2100> xnox: oh, one thing I forgot to ask: does subiquity have the stable/ubuntu-20.10 track created?
[13:21] <sil2100> Since I poked about seeded snaps, so I think I missed poking about subiquity
[13:26] <xnox> sil2100:  i believe we have them through to 22
[13:26] <xnox> sil2100:  let me double check
[13:26] <xnox> sil2100:  also it shouldn't matter if builds are failing, cause then people like me will see cd-build-logs and will fix things
[13:27] <sil2100> rbalint: hey! Could you re-upload strace for focal with a bug number in the debian/changelog?
[13:28] <xnox> sil2100: released stable/ubuntu-20.04 subiquity into stable/ubuntu-21.04 such that subiquity in groovy does not regress
[13:29] <sil2100> xnox: awesome, thanks!
[13:32] <xnox> bah
[13:33] <xnox> i meant to type into "stable/ubuntu-20.10" obviously
[13:44] -queuebot:#ubuntu-release- Unapproved: sosreport (focal-proposed/main) [3.9-1ubuntu2 => 3.9-1ubuntu2.1] (ubuntu-desktop, ubuntu-server)
[13:45] <rbalint> sil2100, sure, do you drop the current strace from focal-proposed and i append ~20.04.0, or i should bump groovy's version first and upload ubuntu<IP_ADDRESS>?
[13:52] <sil2100> rbalint: let's drop the one that's in -proposed, I guess this will be less of a hassle - upload to the queue when you ahve a moment and I'll delete the package then
[13:56] -queuebot:#ubuntu-release- Unapproved: sosreport (eoan-proposed/main) [3.9-1ubuntu<IP_ADDRESS> => 3.9-1ubuntu<IP_ADDRESS>] (ubuntu-desktop, ubuntu-server)
[14:01] <Laney> tsimonq2: I went wild and made a whole ton of changes to your stuff
[14:01] <Laney> but it's basically what you did
[14:01] <Laney> going to deploy it now, weeeeee
[14:06] <Laney> so /running should be working now and faster since it's not actually fetching the content synchronously
[14:08] -queuebot:#ubuntu-release- Unapproved: sosreport (bionic-proposed/main) [3.9-1ubuntu<IP_ADDRESS> => 3.9-1ubuntu<IP_ADDRESS>] (ubuntu-desktop, ubuntu-server)
[14:10] -queuebot:#ubuntu-release- Unapproved: sosreport (eoan-proposed/main) [3.9-1ubuntu<IP_ADDRESS> => 3.9-1ubuntu<IP_ADDRESS>] (ubuntu-desktop, ubuntu-server)
[14:26] -queuebot:#ubuntu-release- New source: cvise (groovy-proposed/primary) [1.0.0-1]
[14:26] -queuebot:#ubuntu-release- New source: python-pebble (groovy-proposed/primary) [4.5.1-1]
[14:35] -queuebot:#ubuntu-release- New binary: xnnpack [amd64] (groovy-proposed/universe) [0.0~git20200425.54f5917-2] (no packageset)
[15:08] -queuebot:#ubuntu-release- Unapproved: strace (focal-proposed/main) [4.26-0.2ubuntu3 => 5.5-3ubuntu1~20.04.0] (core)
[15:12] <rbalint> sil2100, ^
[15:16] -queuebot:#ubuntu-release- Unapproved: accepted strace [source] (focal-proposed) [5.5-3ubuntu1~20.04.0]
[15:16] <sil2100> rbalint: accepted, let's now work on some test case - I guess of course one test is what we already know is good: it builds on focal. I'd also add some smoke-testing, playing around with it to ensure it didn't break completely
[15:17] <sil2100> I'd be fine with this kind of validation
[15:17] <rbalint> sil2100, ok thanks, will add that a bit later
[15:41] -queuebot:#ubuntu-release- Unapproved: ubuntustudio-controls (focal-proposed/universe) [1.12.4 => 1.12.5~20.04.1] (ubuntustudio)
[15:41] <Eickmeyer> ^ SRU incoming
[16:50] <rbalint> sil2100, strace ftbfs again in focal and i guess in groovy, too
[16:50] <rbalint> sil2100, i suggest dropping it from focal-proposed and maybe revisiting the sru later, when users are asking for it
[16:51] <rbalint> sil2100, i can set up a ppa with the backport for the meantime
[17:20] <Eickmeyer> rbasak: I have bug 1872187 for you. :)
[17:23] -queuebot:#ubuntu-release- New binary: qhull [s390x] (groovy-proposed/universe) [2019.1-5] (kubuntu)
[17:40] -queuebot:#ubuntu-release- New binary: qhull [riscv64] (groovy-proposed/universe) [2019.1-5] (kubuntu)
[17:57] -queuebot:#ubuntu-release- New binary: qhull [arm64] (groovy-proposed/universe) [2019.1-5] (kubuntu)
[17:57] -queuebot:#ubuntu-release- New binary: qhull [armhf] (groovy-proposed/universe) [2019.1-5] (kubuntu)
[20:40] -queuebot:#ubuntu-release- New binary: qhull [amd64] (groovy-proposed/universe) [2019.1-5] (kubuntu)
[20:40] -queuebot:#ubuntu-release- New binary: qhull [ppc64el] (groovy-proposed/universe) [2019.1-5] (kubuntu)
[21:56] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-179.209] (core, kernel)
[22:07] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-179.209]
[22:23] -queuebot:#ubuntu-release- Unapproved: clevis (bionic-proposed/universe) [8-1 => 8-1ubuntu0.1] (no packageset)
[22:23] -queuebot:#ubuntu-release- Unapproved: clevis (eoan-proposed/universe) [11-2 => 11-2ubuntu0.1] (no packageset)


[13:43] <Iamthehuman12> I've been having a problem on the Jammy pre-release for a longer time that I can't start JACK. I looked up and looked at ~/.log/jack/jackdbus.log an the problem is probably a missing conf file which should be at ~/.config/jack/conf.xml. Studio Controls gets stuck at "Adding Bridges" and no audio. Do you figure the conf file should be there, but for some reason isn't?
[15:12] <ZombyWoof> In Ubuntu Studio my monitor keeps blanking and put to sleep. I tried disabling it at the pawer manager - display, but no luck so far. Sugestions are welcome.
[16:20] <Eickmeyer> Iamthehuman12: Studio Controls doesn't use the .config/jack/conf.xml. Try deleting your ~/.config/autojack folder, reboot, and try again.
[16:20] <Eickmeyer> ZombyWoof: Sounds like a hardware issue.
[18:05] <ZombyWoof> Eickmeyer: Maybe so. I can try boot with noacpi, but I think the cpu fan will run on max, which gives lots of noice.
[18:05] <Eickmeyer[m]> ZombyWoof: Maybe so, but we can't do hardware support here sadly.
[18:06] <ZombyWoof> ok np
[18:06] <ZombyWoof> thanks anyway
[18:34] <ZombyWoof> The screensaver was the problem here. Just wanted to tell here.


[11:50] <KGB-0> gnome-browser-connector pipeline Jeremy Bicha 567211 * pending (extract-source: pending; build: created; build i386: created; build source: created; test-build-any: created; test-build-all: created; test-crossbuild-arm64: created; reprotest: created; lintian: created; autopkgtest: created; blhc: created; piuparts: created)
[11:50] <KGB-0> gnome-browser-connector pipeline Jeremy Bicha 567211 * running (extract-source: running; build: created; build i386: created; build source: created; test-build-any: created; test-build-all: created; test-crossbuild-arm64: created; reprotest: created; lintian: created; autopkgtest: created; blhc: created; piuparts: created)
[13:36] <KGB-2> vala tags 3277669 Rico Tzschichholz upstream/0.56.12 * Upstream version 0.56.12 * https://deb.li/NGbF
[13:36] <KGB-2> vala upstream/latest fd71824 Rico Tzschichholz tests/Makefile.am vala/valamethodcall.vala tests/generics/parameter-typeof.c-expected tests/generics/parameter-typeof.vala * vala: Only transform default initializers of parameters * https://deb.li/i3kk1
[13:37] <KGB-2> vala upstream/latest a7753a0 Rico Tzschichholz vapi/ gtk4.vapi metadata/Gtk-4.0.metadata * gtk4: Preserve compatibility with <= 4.8.x * https://deb.li/2GVj
[13:37] <KGB-2> vala upstream/latest 2a0ae43 Rico Tzschichholz (5 files in 2 dirs) * Release 0.56.12 * https://deb.li/3HklR
[13:37] <KGB-2> vala upstream/latest 3f5b76d Rico Tzschichholz (18 files in 6 dirs) * New upstream version 0.56.12 * https://deb.li/8TgD
[13:37] <KGB-2> vala pristine-tar bd06005 Rico Tzschichholz vala_0.56.12.orig.tar.xz.delta vala_0.56.12.orig.tar.xz.id * pristine-tar data for vala_0.56.12.orig.tar.xz * https://deb.li/3NKIz
[14:37] <KGB-2> gnome-browser-connector pipeline Jeremy Bicha 567333 * pending (extract-source: pending; build: created; build i386: created; build source: created; test-build-any: created; test-build-all: created; test-crossbuild-arm64: created; reprotest: created; lintian: created; autopkgtest: created; blhc: created; piuparts: created)
[14:37] <KGB-0> gnome-browser-connector pipeline Jeremy Bicha 567333 * running (extract-source: running; build: created; build i386: created; build source: created; test-build-any: created; test-build-all: created; test-crossbuild-arm64: created; reprotest: created; lintian: created; autopkgtest: created; blhc: created; piuparts: created)
[14:47] <KGB-2> gnome-browser-connector pipeline Jeremy Bicha 567333 * [9 minutes and 39 seconds] success (extract-source: success; build: success; build i386: success; build source: success; test-build-any: success; test-build-all: success; test-crossbuild-arm64: success; reprotest: success; lintian: success; autopkgtest: success; blhc: success; piuparts: success)


[00:48] <leuzly> help
[14:35] <veter> ghjghj
[14:35] <veter> гаджара-гуджу!
 Hi, does anybody know how to disable/change the function that pastes whatever text is selected when you click middle mouse button? (this happens in any program)
 nevermind, it's just paste from Clipboard (not selection - any selection is automatically added to the clipboard, apparently)
[20:28] <TBotNik> All:  Having apache issues.  Writeup at: https://www.linuxquestions.org/questions/showthread.php?p=6203112#post6203112 Got part of it working but still confused!  No answers from ##linux nor #httpd!
[21:40] <Maik> TBotNik: well... this channel is for support with Kubuntu not apache
[21:42] <Maik> going on and asking in every channel won't get you further either :)
[21:43] <TBotNik> Maik: You are the only one that has ansered at all
[21:45] <Maik> TBotNik: it's still the holidays and most are spending time with their family. Activity is low everywhere, even on forums.
[21:46] <TBotNik> Maik: Right but just time for me to catch up on things unresloved! He HE!
[21:47] <TBotNik> Maik: Did you look at my writeup on this on LinuxQuestions?
[21:48] <Maik> TBotNik: again, support for apache is elsewhere and i lack experience on the matter
[22:45] <pinbot22> how does one install the adobe apps runing kubuntu 20.04
[22:57] <cfaber> suddenly the meta/win key is no longer launching the application launcher menu, can anyone give me hints as to where to look to fix this?