[00:12] <OvenWerks> I know, just passing the info as I see it.
[00:33] <Eickmeyer> I'm actually surprised nobody in Fedora has started on it yet. They're usually on top of stuff.
[01:41] <Eickmeyer> OvenWerks: Added a slight white outer glow to studio-controls' icon to increase its visibility on dark themes
[17:34] <OvenWerks> Eickmeyer: happy Launch day...
[17:35] <OvenWerks> Eickmeyer: might be an idea to mention in one of the web pages to never use root to trouble shoot audio problems
[17:38] <RikMills> Eickmeyer: not sure if you saw on telegram, but https://i.imgur.com/NtKlsng.png
[18:58] <Eickmeyer> OvenWerks: Yeah, but which one?
[18:58] <Eickmeyer> RikMills: I saw, I've been considering it.
[18:59] <OvenWerks> release notes?
[18:59] <OvenWerks> something hard to miss
[18:59] <Eickmeyer> People miss the release notes like crazy.
[19:00] <OvenWerks>  :)
[19:01] <OvenWerks> maybe detect if controls is running as user root and put up a dialog that says we can't run this way yada yada
[19:03] <Eickmeyer> What on earth told him he needed to run controls a s root? *facepalm*
[19:05] <OvenWerks> controls, qjackctl, jack, autojack, dbus, etc.
[19:05] <OvenWerks> it is a pretty common trouble shooting technique in the linux (and windows) world to try things as root if problems occure
[19:06] <Eickmeyer> Well, yes, but my gosh.
[19:06] <Eickmeyer> What he said was he thought it *had* to be run as root.
[19:07] <OvenWerks> I have seen this enough, here and #ardour, to think setting a warning in -controls just makes sense
[19:07] <Eickmeyer> Agreed.


[12:30] <ubotu> New bug: #106647 in xcursor-themes (main) "Mouse pointer missing when using whiteglass" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106647
[12:35] <ubotu> New bug: #106648 in xcursor-themes (main) "Mouse cursor changes when over flash animation" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106648
[01:15] <ubotu> New bug: #106652 in xserver-xorg-video-ati (main) "glx problems with xserver-xorg-video-ati" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106652
[03:06] <tepsipakki> hm, xorg upload was rejected
[03:07] <tepsipakki> anyway, zzz ->
[03:08] <crimsun> was there a rationale posted in the changelog?
[06:15] <ubotu> New bug: #106679 in libx11 (main) "ENVI/IDL segmentation fault" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106679
[08:56] <Mithrandir> tepsipakki: yes, sorry, just too late even for those kinds of fixes.
[09:20] <tepsipakki> Mithrandir: ok, np
[10:00] <tepsipakki> Mithrandir: what if I dropped the new part of it, so that it only fixes the ATI vendor strings?
[10:10] <ubotu> New bug: #51874 in linux-restricted-modules-2.6.15 (restricted) "Nvidia legacy drivers doesn't work on newer kernel" [Undecided,Needs info]  https://launchpad.net/bugs/51874
[10:32] <ubotu> New bug: #105901 in xorg (main) "nvidia 7800gt live cd/ install issue" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105901
[10:37] <ubotu> New bug: #106217 in linux-restricted-modules-2.6.20 (restricted) "hidden file controlling NVIDIA driver does not get removed when switching from nvidia-glx-new back to nvidia-glx causing X not to start due to mismatch of versions" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106217
[01:21] <ubotu> New bug: #42478 in linux-restricted-modules-2.6.15 (restricted) "ppracer aborts after intro screen on NVidia Riva TNT2" [Medium,Confirmed]  https://launchpad.net/bugs/42478
[01:41] <ubotu> New bug: #40273 in linux-restricted-modules-2.6.15 (restricted) "Xorg fails to run using nvidia driver" [Medium,Needs info]  https://launchpad.net/bugs/40273
[01:53] <ubotu> New bug: #106705 in xkeyboard-config (main) "Keyboard layout is incorrect for some keys" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106705
[02:26] <ubotu> New bug: #92581 in linux-restricted-modules-2.6.20 (restricted) "nvidia-glx-legacy doesn't disable composite extension automatically on installation" [Undecided,Confirmed]  https://launchpad.net/bugs/92581
[04:20] <ubotu> New bug: #53569 in xorg-server (main) "Closing a window will often freeze X" [Undecided,Needs info]  https://launchpad.net/bugs/53569
[07:13] <ubotu> New bug: #106718 in xorg (main) "incorrect path to .Xmodmap" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106718
[07:25] <ubotu> New bug: #105309 in xorg (main) "Bad xorg config for 1440x900 monitor" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105309
[08:35] <ubotu> New bug: #103383 in xorg (main) "Multiple screens in Ubutu" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103383
[10:03] <ubotu> New bug: #21637 in gtk+2.0 "xkb greek polytonic: cannot write psili and dasia after upgrade to breezy" [Medium,Confirmed]  https://launchpad.net/bugs/21637
[10:46] <ubotu> New bug: #56376 in linux-source-2.6.17 (main) "[Dapper 6.06]  Laptop - PCI cannot allocate resource for region 7 8 and 9 (dup-of: 54294)" [Undecided,Needs info]  https://launchpad.net/bugs/56376


[05:31] <lotuspsychje> good morning mates
[05:32] <TJ-> Morning
[05:32] <lotuspsychje> TJ-: hey there
[05:32] <lotuspsychje> what you playin with today :p
[05:42] <TJ-> Well... fixed up the cryptsetup initramfs scripts to use a key-file, filed a bunch of bugs against lightdm, and currently trying to narrow down a regression in kernel bluetooth support  for some devices (since v3.2 ... so a lot to work back over)
[05:42] <lotuspsychje> cool
[05:42] <lotuspsychje> im testin out new enlightment :p
[05:44] <TJ-> I might take a look one of these days if I ever get chance. I'm really liking the improvements in KDE for 15.10
[05:45] <TJ-> Although I got really pissy at it requiring mysqld to be installed to support this Akonadi "search-everything-that-moves-with-thirty-plus-executables-loaded-at-session-start" mess!  I have Lubuntu/LXDE and Kubuntu desktops installed. Lubuntu pulls in Abiword. When the Plasma DE loads an instance of Abiword always started, with its Parent's PID = 1 (init). Been bugging me for 3/4 weeks
[05:48] <TJ-> It turns out abiword installs a DBus service for Telepathy Collaboration. When KDE session starts it launcheds kde-telepathy which somehow causes the abiword executable be launched and loading a blank document. Very annoying!
[05:49] <lotuspsychje> weird
[05:50] <lotuspsychje> i had some crashes on enlightment already too lol
[05:50] <lotuspsychje> after leftmouse opening applications
[05:51] <TJ-> Bug hunting can be fun; suffering bugs with no explanation can be very frustrating
[05:51] <TJ-> Especially if you can't easily run the process under control of the debugger
[05:52] <lotuspsychje> i find launchpad bugging bit confusing
[05:57] <TJ-> Do you? why is that?
[05:58] <lotuspsychje> all the info gathering and protocols i dont like very much
[05:59] <TJ-> I generally use common-sense with that. I usually report bugs directly rather than using ubuntu-bug/apport-bug
[06:00] <lotuspsychje> right
[06:00] <lotuspsychje> i like askbuntu solving better :p
[06:00] <lotuspsychje> simple and more specific
[06:01] <lotuspsychje> but for rough bugs, launchpad might be better
[09:06] <lotuspsychje> lol: http://news.softpedia.com/news/tutorial-for-microsoft-to-help-it-kill-linux-491638.shtml
[14:52] <lotuspsychje> SinisterDoor: welcome
[14:54] <lotuspsychje> emnz: welcome
[14:54] <emnz> ah nice
[14:54] <emnz> thx :)
[14:54] <lotuspsychje> emnz: ubuntu has grown big these days
[14:55] <emnz> how do u mean most popular? u mean linux in general?
[14:55] <lotuspsychje> so most user count worldwide is for ubuntu
[14:55] <lotuspsychje> no ubuntu
[14:55] <emnz> most popular linux desktop distro?
[14:55] <emnz> ok
[14:55] <lotuspsychje> no
[14:56] <lotuspsychje> most popular Os from all
[14:56] <emnz> O.O
[14:56] <emnz> how can that be, what about android and windows?
[14:56] <SinisterDoor> lol
[14:56] <emnz> enlighten me
[14:56] <emnz> im not up to speed these days xD
[14:56] <lotuspsychje> emnz: we also have phones now
[14:56] <SinisterDoor> yeah but they are android
[14:57] <lotuspsychje> SinisterDoor: no, ubuntu touch phones
[14:57] <lotuspsychje> !touch
[14:57] <SinisterDoor> -.-
[14:57] <lotuspsychje> i installed ubuntu touch on my nexus 7 also
[14:57] <lotuspsychje> running much safer then android
[14:58] <SinisterDoor> my nexus 6 doesn't support it.
[14:58] <SinisterDoor> ubuntu abandoned the project
[14:58] <lotuspsychje> read this guys
[14:58] <lotuspsychje> http://news.softpedia.com/news/top-five-reasons-why-ubuntu-is-the-most-used-linux-os-491064.shtml
[15:03] <emnz> wow hey
[15:03] <emnz> ** awesome
[15:04] <emnz> https://en.wikipedia.org/wiki/Usage_share_of_operating_systems#cite_ref-NetMarketShare_83-0
[15:05] <emnz> way to go on desktop still, but wow, so impressed man, im dumping windows for sure
[15:05] <emnz> cant believe how this has taken off since I last used a linux distro
[15:07] <lotuspsychje> emnz: yeah it improved alot
[15:07] <emnz> incredible
[15:08] <lotuspsychje> emnz: ive installed over more then 50 boxes with 14.04 LTS all work like a charm
[15:08] <emnz> software center is really legit now, had nothing but crappy free apps years ago
[15:08] <emnz> flash is solid now, not that we really need it with HTML5 anymore
[15:09] <TJ-> flash is a permanent can of worms!
[15:09] <emnz> firefox+all addons working
[15:09] <lotuspsychje> lol
[15:09] <emnz> haha shit, must I remove it?
[15:09] <lotuspsychje> TJ-: with a load of holes in it
[15:10] <emnz> this unity is fkn great
[15:10] <carlduke2> hi everyone, is there a channel for ubuntu app developers?
[15:10] <lotuspsychje> carlduke2: #ubuntu-devel
[15:10] <lotuspsychje> carlduke2: and #ubuntu-touch for the phones developing
[15:10] <carlduke2> isn't it for the os dev?
[15:10] <TJ-> emnz: Adobe stopped developing flash for Linux several years ago; there are some security fixes but rather like Windows it is full of exploit opportunities
[15:10] <lotuspsychje> TJ-: +1
[15:11] <emnz> do you guys like unity? seems it doesnt get much love lol
[15:12] <TJ-> I won't touch it; terrible on decent workstations or any large screen
[15:12] <lotuspsychje> once you get used it unity its very intuitive for work
[15:12] <emnz> im really liking it with unity tweak tool/compiz settings manager
[15:12] <carlduke2> it's not that bad actually ..not very customizable tough ..I switched to KDE and I'll stick with it. It has an impressive collection of apps and utilities (ie KDE Connect - mind blowing)
[15:13] <lotuspsychje> im a unity fan :p
[15:13] <emnz> yeah I set window buttons: right in unity tweak but doesnt seem to work :(
[15:13] <lotuspsychje> with wobbly windows and eyecandy
[15:13] <TJ-> Unity is small screen device (tablet) interface shoe-horned onto a workstation desktop
[15:13] <emnz> id like to have the launcher at the top, but seems this is impossible too?
[15:14] <emnz> TJ-: lol, metro start screen for linux? xD
[15:14] <TJ-> emnz: I run 6 1920x1200 monitors ... you cannot imagine the pain Unity causes.
[15:14] <lotuspsychje> lol
[15:15] <lotuspsychje> neo only uses 2 screens...
[15:15] <emnz> quite the power user hey sheesh haha, i got 2 x 1920x1080 only
[15:15] <TJ-> I's need an Olympic athelete just to move the mouse cursor back to the application and/or desktop launcher
[15:15] <lotuspsychje> roflol
[15:15] <lotuspsychje> follow the wabbit
[15:15] <TJ-> ;)
[15:16] <lotuspsychje> so 6 monitors with each 4 worskpaces lol?
[15:16] <lotuspsychje> alot of work can be done there
[15:16] <TJ-> no, I actually split them up into 4 X sessions now, to logically separate the different purposes they have
[15:16] <lotuspsychje> cool
[15:17] <lotuspsychje> if you got a pic somewhere of your desktop layout, show us lol
[15:17] <TJ-> I have 3 in portrait mode (document references, web pages, etc), 3 in landscape (terminals, ssh sessions, coding).
[15:17] <TJ-> its around somewhere
[15:17] <lotuspsychje> very nice
[15:17] <lotuspsychje> im always curious about linux desktops
[15:21] <emnz> thats great man, would also like to see
[15:21] <EriC^^> ditto
[15:22] <lotuspsychje> lolz
[15:22] <EriC^^> http://www.criticalcommons.org/Members/ccManager/clips/swordfishtechno3dhackingdrama.mp4/thumbnailImage
[15:22] <EriC^^> this is lotuspsychje setup
[15:23] <lotuspsychje> hahaha
[15:23] <emnz> u guy are amateurs, mine: http://p-fst1.pixstatic.com/5069f24a74c5b64b160007e5._w.540_h.359_s.fit_.jpg
[15:23] <emnz> jk ;D
[15:24] <lotuspsychje> wahaha
[15:24] <emnz> ok so what must I use instead of unity if I want a w7 style launcher?
[15:24] <lotuspsychje> lubuntu
[15:24] <lotuspsychje> !lubuntu
[15:24] <lordievader> emnz: That is a sweet monitor wall to have :D
[15:25] <lordievader> Or to want...
[15:25] <EriC^^> lol emnz
[15:26] <lotuspsychje> bbl dinner, someone save that atari pic from TJ- for me :p
[15:30] <emnz> hmm, XFCE looks nice, but I dont want to lose ubuntu, I'm just getting into it again, don't want to lose the software center and all the apps it comes with :/
[15:31] <emnz> I'd just like ubuntu as it is, but with a different launcher
[15:32] <emnz> is it a bad idea to install XFCE on ubuntu, always better to get a distro made around it from the start
[15:32] <lordievader> Lubuntu can use Ubuntu's Software center just fine.
[15:32] <emnz> ?
[15:35] <emnz> lordievader: ok cool, but my problem is all the different apps and configuration lubuntu comes with... im a noob at this stuff, the easiness of ubuntu has been great
[15:39] <emnz> am I making stupid comments here? im sry
[15:45] <lordievader> emnz: Not at all, but do know that the underlaying system is the same for all Ubuntu flavours.
[15:45] <carlduke2> if you need a launcher check out docky
[15:45] <carlduke2> its very cool
[15:51] <TJ-> hmmm, unexplained ecryptfs mount failure
[16:02] <emnz> lordievader: yeah I am aware of that. So Xubuntu or Lubuntu won't come with Compiz?
[16:05] <EriC^^> emnz: nope
[16:05] <emnz> the selection of included software between regular ubuntu and lubuntu look vastly different
[16:06] <EriC^^> lubuntu uses openbox
[16:06] <EriC^^> yeah lubuntu is kind of minimal
[16:08] <emnz> wish I could just change the unity launcher to make it more like XFCE/LXDE/windows7, I think changing to another version of ubuntu with different apps will put me off
[16:09] <EriC^^> you can download the apps on lubuntu and xubuntu too
[16:09] <emnz> yeah but then I'll have to configure them all myself
[16:09] <EriC^^> nah it's the same thing
[16:13] <emnz> hmm
[16:21] <emnz> ugh rain is killing my internet again :(
[16:21] <emnz> EriC^^: I typed this for you before it dc'd.... :
[16:22] <emnz> EriC^^: I'm looking at the ubuntu software center - installed apps, seems to be a lot of unity-related stuff, even things like "Keyboard (unity-control-center) - change keyboard settings" and "Network (unity-control-center) - network settings", so all those apps would be gone with xubuntu/lubuntu?
[16:23] <emnz> again, my apologies for another stupid question lol, getting my head around desktop managers/window managers and how they all work together etc.
[16:30] <EriC^^> emnz: xubuntu and lubuntu have their own settings manager and keyboard stuff
[16:31] <EriC^^> xubuntu is more functional than ubuntu, it has more stuff out of the box and is more functional oriented
[16:31] <EriC^^> ill brb
[18:32] <lotuspsychje> http://www.fiercecio.com/story/mozilla-quietly-adds-advertisements-firefox/2015-09-11
[18:32] <lotuspsychje> hmmmz
[18:32] <lotuspsychje> maybe they learned from w10
[18:42] <lotuspsychje> ioria: good evening mate
[18:43] <ioria> lotuspsychje, thanx ... you too
[18:43] <lotuspsychje> ioria: the idea of this channel is, we always do support in #ubuntu but never actually speak to each other
[18:43] <lotuspsychje> so here we are :p
[18:43] <ioria> great.... "human support"
[18:43] <lotuspsychje> yeah :p
[18:44] <OerHeks> hi ioria
[18:44] <ioria> OerHeks, hallo !!!!!
[18:44] <lotuspsychje> lol
[18:44] <OerHeks> it is handy to have backtalk, but this channel is originally for 'discussion'
[18:44] <OerHeks> so this channel is hijacked :-D
[18:44] <lotuspsychje> well mostly its quality ubuntu discussions anyway
[18:44] <lotuspsychje> loll
[18:45]  * lotuspsychje ==h4xxored d1scuss1on==
[18:48] <lotuspsychje> pauljw: good evening
[18:48] <ioria> pauljw, welcome
[18:48] <lotuspsychje> ioria: wich distro are you running mate?
[18:49] <ioria> lotuspsychje, Ubuntu 14.04.3 LTS \n \l     but i love Lubuntu :)
[18:49] <lotuspsychje> same here LTS
[18:49] <pauljw> hi lotuspsychje , thx
[18:54] <lotuspsychje> ive just tested new enlightment
[18:54] <lotuspsychje> pretty nice
[18:54] <pauljw> :)
[18:55] <lotuspsychje> http://linux.softpedia.com/blog/enlightenment-0-19-10-open-source-desktop-environment-out-now-with-10-bugfixes-491598.shtml
[18:55] <lotuspsychje> oldskool feeling
[18:56] <ioria> lotuspsychje, looks nice ...
[18:57] <lotuspsychje> yeah
[18:57] <lotuspsychje> EriC^^: wb eric
[18:57] <EriC^^> thx
[18:57] <lotuspsychje> EriC^^: did TJ- show his atari link?
[18:57] <EriC^^> lol no
[18:58] <lotuspsychje> :p
[18:58] <ioria> atari ?
[18:58] <lotuspsychje> ioria: yeah lil joke, he's got 6 monitors running on linux, we all wanted to see
[18:58] <ioria> wow
[18:59] <lotuspsychje> yeah thats what we tought also :p
[19:01] <lotuspsychje> funny :p http://news.softpedia.com/news/tutorial-for-microsoft-to-help-it-kill-linux-491638.shtml
[19:02] <TJ-> lotuspsychje: It's all YOUR fault!
[19:02] <lotuspsychje> TJ-: :p
[19:02]  * lotuspsychje hides
[19:03] <TJ-> The image is on an external drive, protected by ecryptfs. I mount it every day... today it failed!
[19:03] <lotuspsychje> TJ-: ouch :p
[19:03]  * daftykins wonders what he just walked in on
[19:03] <daftykins> :O
[19:04] <TJ-> I've just spent an intense debugging session with Ty Hicks on it; the ecryptfs-recover-private tool adds the key to the kernel's @us (user session) keyring. Then its 'mount' command fails, kernel reports unknown key, keyctl lists the key!
[19:04] <lotuspsychje> daftykins: <TJ-> emnz: I run 6 1920x1200 monitors ... you cannot imagine the pain Unity causes.
[19:04] <OerHeks> is that drive readonly?
[19:04] <TJ-> Turns out... I switched from lightdm to sddm (the KDE DM) last night... and SDDM separates the keyrings, causing this!
[19:05] <TJ-> So, if you see any questions about ecryptfs failing to open, with people on ssh sessions or similar, suspect the incorrect kernel keyring being used by the session
[19:06] <lotuspsychje> i never liked keyring
[19:09] <daftykins> TJ-: that's way too deep for me :D
[19:10] <daftykins> i spy encryption and go "nope nope nope!"
[19:12] <lotuspsychje> best way to hide data is on usb, under the ground
[19:12] <lotuspsychje> far away from the fb1
[19:18] <lotuspsychje> !info deluge
[19:23] <TJ-> lotuspsychje: got it finally :)  http://imgur.com/V6EBdJt
[19:24] <lotuspsychje> yessss lets c :p
[19:24] <ioria> TJ- Oh my ....
[19:24] <lotuspsychje> holy smokin
[19:24] <lotuspsychje> those 2 big ones left are also monitors?
[19:25] <TJ-> all 6 in the corner; 2 X portrait, 3 x landscape, 1 x portrait
[19:25] <lotuspsychje> like tv's upside down
[19:25] <lotuspsychje> dang
[19:25] <lotuspsychje> i bet you can only dream of that EriC^^ :p
[19:25] <TJ-> the far left of the photo is the reflections from the data cabinets
[19:26] <OerHeks> small printer on the left side :-D
[19:27] <lotuspsychje> loool
[19:27] <lotuspsychje> its like a plotter
[19:27] <TJ-> A3 printer/scanner inkjet on top of the 21U cabinet; A4 scanner/printer laser under the bench
[19:28] <lotuspsychje> TJ-: and wich distro running on those screenz?
[19:28] <TJ-> It's this one I'm using now. Kubuntu
[19:28] <ioria> TJ-  electric bill ?
[19:28] <lotuspsychje> lol
[19:29] <TJ-> All on the laptop in the middle
[19:29] <lotuspsychje> cool
[19:29] <TJ-> ioria: All runs on 12V DC
[19:29] <ioria> TJ- wow....
[19:29] <daftykins> 12V 0o
[19:29] <lotuspsychje> TJ-: does those screens work by default on kde or xrandr config?
[19:30] <TJ-> I have the server cabinet kit on dual UPSs, via 2 x 16-outlet 0U vertical CDUs on the wall
[19:31] <TJ-> lotuspsychje: I have them custom configured since it is using 3 GPUs. If it auto-configures it has no idea of where each monitor is in the layout
[19:31] <lotuspsychje> right
[19:32] <pauljw> TJ-: sweet!
[19:34] <lotuspsychje> feels like swordfish :p
[19:35] <ioria> lotuspsychje, the movie ?
[19:35] <lotuspsychje> yep :p
[19:36] <lotuspsychje> we just need the girl on her knees now for TJ-
[19:36] <ioria> lotuspsychje, it's a nice movie ...
[19:36] <lotuspsychje> yes it is :p
[19:37] <lotuspsychje> ioria: wich was your first computer ever?
[19:38] <emnz> hi guys
[19:38] <lotuspsychje> tandy calculators doesnt count :p
[19:38] <lotuspsychje> emnz: good evening
[19:39] <daftykins> moar screens = super hacker </Hollywood>
[19:39] <ioria> lotuspsychje, pentium3 ... it's still working ...
[19:39] <lotuspsychje> cool
[19:39] <TJ-> It's just a way to stay well organised when there's lots of different things going on. Avoids typing commands to remote systems into the wrong window by mistake, for example
[19:40] <TJ-> My first computer was ZX81... still working :)
[19:40] <ioria> lotuspsychje, i got it 4 years ago ... it was in a dumpster  ^_^
[19:41] <lotuspsychje> mine was a super 2000 or something, a kind of electrical mainboard to wire points togheter and make programs
[19:41] <lotuspsychje> after that comodore 64
[19:42] <TJ-> the '64 came after the vic 20 didn't it?
[19:42] <ioria> lotuspsychje, i know it
[19:42] <lotuspsychje> atari==amiga 500==486
[19:43] <lotuspsychje> TJ-: yep, never tested vic20 myself
[19:43] <lotuspsychje> but surely looks the same with cassete deck
[19:43] <lotuspsychje> 'press play on tape'
[19:43] <TJ-> I had all the popular home computers back then; writing cross-platform game engines for them
[19:44] <lotuspsychje> cool
[19:44] <lotuspsychje> me and my brother were fooling around in basic
[19:44] <emnz> you guys know anything about Cardapio?
[19:44] <emnz> http://cloud.addictivetips.com/wp-content/uploads/2011/06/Cardapio.jpg
[19:45] <lotuspsychje> whats that?
[19:45] <emnz> an app launcher for unity, but its very outdated :(
[19:45] <daftykins> looks like someone has glued the xfce menu beside unity
[19:45] <lotuspsychje> ah
[19:45] <EriC^^> emnz: there's a start menu for unity in the repos i think
[19:46] <lotuspsychje> !info classicmenu-indicator | emnz try this
[19:46] <lotuspsychje> daftykins: lol
[19:46] <emnz> YES!!! omg ty!!
[19:46] <EriC^^> yeah thats it ^
[19:47] <emnz> cant I make the unity button show that?
[19:47] <lotuspsychje> emnz: no, its an indicator
[19:47] <lotuspsychje> emnz: you can try docky also and autohide left sidebar
[19:47] <lotuspsychje> !info docky
[19:48] <lotuspsychje> emnz: all depends what you wish for?
[19:49] <lotuspsychje> emnz: check terminal: apt-cache show indicator for more cool indicators
[19:50] <ioria> TJ- it was this http://www.imarshall.karoo.net/zx81/zx81pfiles.htm ?
[19:50] <TJ-> ioria: correct
[19:50] <ioria> TJ- wow
[19:50] <lotuspsychje> ioria: never seen such a thing :p
[19:51] <ioria> lotuspsychje, no, i feel little ....
[19:51] <TJ-> I ordered it whilst still at school in February 1981... Sinclair had massive orders and it wasn't delivered until June 16th, in the week after I left school and before I started work on the farm :)
[19:52] <TJ-> We had a massive 4KB RAM!
[19:52] <lotuspsychje> loool
[19:52] <emnz> lotuspsychje: ok thanks I've just given them all a look, I'm looking mostly for a menu like XFCE, so I dont have to type every app i want to open (or click Installed - see all)
[19:52] <TJ-> and you could get a wobbly 16KB "RAM Pack" to plug on the back
[19:52] <lotuspsychje> and what could you do with that thing?
[19:52] <TJ-> Loads! It came with a BASIC interpreter but I found that limited so switched to Z80A machine code
[19:52] <emnz> and if I can edit the menu that would be nice, like how you can edit windows 7 shortcuts in the taskbar
[19:52] <lotuspsychje> emnz: you can create or lock icons to unity's left bard
[19:53] <lotuspsychje> bar
[19:53] <emnz> lotuspsychje: yeah I'm doing that, and I installed unity-folders
[19:53] <TJ-> There was an expander rather like today's RasPi GPIO expansion, where you could connect analog and digital inputs/ooutputs
[19:53] <emnz> lotuspsychje: but I'd still like a bigger menu that I can customize, that classicmenu indicator is awesome but I can't edit whats inside it
[19:54] <TJ-> the neat part was the 'adapters' that plugged onto the GPIO pins were just PCBs inside regular cassette tape boxes, glued shut :)
[19:55] <daftykins> emnz: or you could just run a different DE that does this properly instead of trying to hack it onto Unity *cough*
[19:55] <lotuspsychje> wileee: good evening mate
[19:55] <TJ-> lotuspsychje: weep at what you can do in a few bytes :)  http://www.users.waitrose.com/~thunor/mmcoyzx81/downloads.html
[19:55] <wileee> evening
[19:55] <ioria> bay bay
[19:56] <lotuspsychje> TJ-: lol breakout
[19:57] <emnz> daftykins: yeah I know I know lol... I've installed lubuntu and xubuntu but still much prefer ubuntu, I'll deal with unity's quirks either way, but trying to tweak it as much as I can
[19:57] <TJ-> It was more fun than the RasPi for learning to program; you were close to the metal all the time, learned to appreciate how to write code efficiently. We used to count the clock cycles of each instruction to figure out how much we could get done... saving a 'tick' in a loop could add up
[20:01] <emnz> Is there any way to add an XFCE-style menu to docky?
[20:02] <lotuspsychje> emnz: not sure
[20:03] <lotuspsychje> anyways off to sleep
[20:03] <lotuspsychje> nitenite guys
[20:03] <pauljw> gnit
[20:10] <pauljw> bbl
[23:23] <lotuspsychje> good early morning
[23:24] <Bashing-om> lotuspsychje: Uh Huh , Look at the day, let us rejoice and be glad in it .
[23:25] <lotuspsychje> insomnia here :p
[23:27] <Bashing-om> We keep ya company. I have been known to wake up at OH! Dark :30; and here I am .
[23:27] <lotuspsychje> lol
[23:28] <Bashing-om> besides, what are friends for .
[23:28] <lotuspsychje> !cookie | Bashing-om nice1
[23:29] <Bashing-om> cookies are good .
[23:29] <lotuspsychje> friendship too :p
[23:31] <Bashing-om> Aye, the Good things !
[23:42] <emnz> 3 hours sleep enough for you?
[23:42] <emnz> lol o.O
[23:43] <emnz> im going for a long sleep, thank you for the help, goodnight
[23:43] <lotuspsychje> lol


[04:18] <pitti> good morning
[04:19] <pitti> gema, slangasek: no, that bug (Chinese images not being Chinese) is quite some months old already
[04:19] <slangasek> so I wonder why the testers didn't agree
[04:19] <pitti> we introduced it in https://launchpad.net/ubuntu/+source/language-selector/0.66
[04:20] <pitti> cjwatson: no worries; it doesn't matter if we release them a day after, I guess
[04:20] <pitti> I tested a local build yesterday, downloading http://china-images.ubuntu.com/precise/daily-live/20120426/ now
[04:41] <pitti> stgraber, cjwatson: http://china-images.ubuntu.com/precise/daily-live/20120426/ is now actually chinese; stgraber, can you please add them to the tracker? I disabled the previous ones, but I still can't add new ones
[06:15] <skaet> pitti, slangasek, stgraber, cjwatson - http://localized-iso.qa.ubuntu.com/qatracker/milestones/217/builds has been created and chinese images added to it.
[06:17] <skaet> Since the images were based on a final version of 12.04,  rather than the pre-release ones,  it seemed a new milestone was appropriate.
[06:20] <skaet> stgraber,  we probably need to figure out some conventions for the transition between pre-release and after the Ubuntu release comes out, and get it documented.
[06:20] <skaet> I'll set up a blueprint on the subject for later today.
[06:30] <pitti> skaet: splendid, thanks
[06:31] <skaet> good morning pitti.
[06:31] <skaet> :)
[06:34] <pitti> hey skaet, how do you feel today?
[06:36] <skaet> pitti,  feeling good.   solid sleep helps wonderfully, as does knowing the release is out the door.  ;)
[06:36] <pitti> yay, didrocks-isms!
[06:36] <pitti> da man who never sleeps
[06:37] <skaet> :)
[06:37] <skaet> more goodness coming in,  SRU system ramps up for 12.04.  :)
[06:38] <skaet> re: didrocks,   +1!  :D
[06:38] <didrocks> \o/
[06:38] <didrocks> more goodness in the pipe :)
[06:40] <skaet> :)
[06:45] <didrocks> does anyone know what shold be the Multi-Arch tag for a -dbg package?
[06:45] <didrocks> as bamf-dbg is Multi-Arch: same and of course, I'm getting: E: bamf-dbg: arch-dependent-file-not-in-arch-specific-directory usr/lib/debug/usr/lib/bamf/bamfdaemon
[06:45] <slangasek> it "should" be whatever it is
[06:46] <slangasek> if the -dbg package ships files in a non-arch-qualified directory, it shouldn't be marked M-A: same
[06:47] <didrocks> slangasek: ok, as bzr annotate points you as doing this addition I didn't dare removing it without having a confirmation from someone with some clue on this :) thanks!
[06:48] <slangasek> ;)  I overlooked bamfdaemon when I added it
[06:48] <didrocks> slangasek: no worry, will use this upload to fix it, thanks for confirming :)
[07:10]  * skaet --> breakfast then shifting to the office.   biab
[07:35]  * apw notes that the archive is suitibly slow today
[07:40] <micahg> isn't it always like that right after release?
[07:40] <tumbleweed> it is closed, after all
[07:41] <jibel> Riddell, I reproduced bug 989249, attached the logs and updated the tracker.
[07:41] <tumbleweed> oh, you mean access
[07:41] <ubot2> Launchpad bug 989249 in ubiquity "kubuntu amd64+mac crash in manual partitioner" [High,Confirmed] https://launchpad.net/bugs/989249
[09:16] <Riddell> thanks jibel
[09:30] <cjwatson> doko_: so can we copy a bunch more stuff from your PPA now?
[09:31] <doko_> cjwatson, just copied gcc-4.6 and gdc-4.6
[09:31] <doko_> I'll upload gcj-4.6 and gnat-4.6 directly. did mess up the gcc-defaults in the ppa
[09:31] <cjwatson> OK
[09:38] <cjwatson> doko_: oh, I guess you're using copy-package.py, so it didn't show up in the queue?
[09:41] <doko_> cjwatson, yes, I did. sorry, should I use something else?
[09:41] <cjwatson> ideally, something that's based on Archive.copyPackage in the API
[09:42] <cjwatson> I don't think we actually have a proper general tool for it right now; you can either write one :-) or use lp-shell
[09:42] <pitti> note that copy-proposed-kernel in lp:u-a-t shoudl be fairly close to this
[09:42] <cjwatson> indeed
[09:43] <pitti> in fact, it doesn't really hardcode any package name, just the "canonical-kernel-team" PPA name
[09:43] <cjwatson> it's on the remove-archive-admin-shell-access list to write a general API tool to replace everything we do with copy-package.py
[09:43] <doko_> ok, noted
[09:43] <pitti> it'd be fairly simple to rename it to copy-ppa-ubuntu and add some options for PPA name and destination pocket
[09:43] <cjwatson> so maybe add an option to that script to select the PPA and rename it to copy-from-ppa
[09:43] <cjwatson> yeah
[09:44] <pitti> I'd still keep copy-proposed-kernel, but that can then become a tiny shell shim around that
[09:47] <doko> cjwatson, pitti: would you be ok with demoting gcc-4.5 from the start?
[09:47] <doko> even if it's still used by u-boot and mysql-5.1?
[09:47] <cjwatson> why?
[09:48] <pitti> we still carry mysql 5.1? I thought that was obsoleted by 5.5
[09:48] <cjwatson> mysql-5.5 actually
[09:48] <pitti> oh, 5.5
[09:48] <pitti> so, I'm generally for reducing duplication, just not sure how hard it is to fix u-boot-linaro
[09:48] <cjwatson> I'd rather those packages were fixed first
[09:48] <cjwatson> I guess I don't see the rush to demote it
[10:13] <cjwatson> doko: Any reason I shouldn't accept boost1.49 now?  AFAICS things that use the default compiler should be fine now
[10:14] <doko> cjwatson, sounds fine
[11:06] <infinity> doko: I'll push Linaro harder to get u-boot working with 4.6 (or 4.7, ideally), MySQL will take some testing.  We tried to switch it once and its world exploded.  Maybe 4.7 will treat it better, or maybe MySQL needs some love.
[11:06]  * Laney switches ben to precise
[11:06] <Laney> er, the other thing
[11:06] <ogra_> lots of maybes in that sentence
[11:07] <Laney> we should clean that out too
[11:08] <micahg> do we still need 4.4 for anything (texlive-bin and libusb++-dev seem to be the only things that require it in main)
[11:08] <infinity> ogra_: I only count two. :P
[11:08] <ogra_> enough though :)
[11:09] <micahg> well, and boost1.46, but that's going away :)
[11:11] <infinity> micahg: 4.4 demotion seems like a much more solvable issue, though examining WHY things still want it is always a sane first step.
[11:11] <micahg> after it's demoted I think I'll just kill it (only a handful of universe rdeps)
[11:12] <micahg> ok, 2 handfuls :)
[11:12] <infinity> That's, I suspect, the plan.
[11:17] <doko> infinity, it's mysql 5.1 only, which maybe should be dropped
[11:17] <infinity> -- precise/main build deps on g++-4.5:
[11:18] <infinity> mysql-5.5
[11:18] <infinity> doko: I can't see that that changed in the last day...
[11:27] <doko> hmm
[11:30] <micahg> doko: here's what I think you're looking for: https://launchpad.net/ubuntu/+source/mysql-5.5/5.5.20-0ubuntu2
[11:32] <infinity> SpamapS: Can you waste a bit of time on testing MySQL with g++-4.7 and see if maybe we can finally ditch 4.5 (or even blow some time on finding and fixing the issues?)
[11:32] <infinity> There.  Go, server team, go.
[12:00] <doko> cjwatson, infinity, pitti, micahg: I think we are ready for *ish uploads. toolchain is in place, but the -multilib packages are still broken on arm. I don't expect these to be available before tomorrow.
[12:01] <infinity> What's broken with multilib?
[12:01] <infinity> (Not that it matters greatly, except for a tiny subset of packages)
[12:02] <doko> config error, gcc-4.7 didn't build the -multilib packages
[12:02] <doko> so you'll just see unfulfilled b-d's, and can give back these later
[12:03] <cjwatson> doko: let's finish boost1.49 and boost-defaults first?
[12:03] <infinity> Please.
[12:03] <doko> ?
[12:03] <cjwatson> per ScottK on -devel
[12:03] <cjwatson> I wonder if we should merge debhelper
[12:03] <doko> ohh, I didn't mean to open now, but get uploads for dpkg, apt, etc ready
[12:03] <cjwatson> Oh, right.  dpkg is Hard this time.
[12:04] <doko> yes, and debhelper,. cdbs, ...
[12:04] <doko> should be independent from boost
[12:04] <cjwatson> I'd be inclined to leave it for a bit rather than rush it.  It'll need care to get multiarch config migration working properly.
[12:04] <cjwatson> And I don't think it's needed for opening.
[12:05] <infinity> Config migration should be fairly simple.  "should be". :/
[12:05] <micahg> Debian has started adding annoying deps on debhelper for various hardening features, so that would probably be good before the autosync
[12:05] <cjwatson> infinity: Be my guest. :-)
[12:05] <infinity> cjwatson: I don't mind doing the migration bit, I'm not sure I want to do the merge today.
[12:05] <cjwatson> I'll go and sort out debhelper now.
[12:05] <infinity> cjwatson: But I could do both next week.  I agree that we don't need it to open.
[12:06] <cjwatson> We don't have merge-o-matic yet, unfortunately.
[12:06] <infinity> MoM and I aren't often on speaking terms anyway.
[12:06] <cjwatson> Right, I wouldn't recommend it for dpkg in any case.  I meant in general.
[12:06] <infinity> apt 0.9.2 would be nice, not sure how large the delta there is.
[12:07]  * infinity has a look.
[12:12] <doko> infinity, are you tracking the upgrade of the arm buildds?
[12:12] <doko> when should that happen?
[12:12] <infinity> doko: Which upgrade?
[12:12] <doko> to precise
[12:12] <infinity> doko: To precise, you mean?  We want *all* buildds to do that, not just arm.
[12:12] <doko> I mean, there are more than 50% offline
[12:12] <infinity> doko: Timing on that, however, is out of my hands.
[12:13] <cjwatson> Hum
[12:13] <doko> is this an webops item?
[12:13] <infinity> It's an RT ticket, not sure who owns it currently.
[12:13] <cjwatson> The debhelper merge has a conflict in dh_installinit which is tied in with Steve's efforts to merge proper Upstart handling into Debian
[12:13] <infinity> But I'll make sure it comes up in calls and we get it done.
[12:14] <cjwatson> And the new dh_installinit has the effect of installing both Upstart jobs and init scripts, rather than our previous scheme
[12:14] <cjwatson> slangasek: ^- I'm not confident in my ability to do the debhelper merge accurately; do you think you could deal with it?
[12:14] <cjwatson> micahg: Build-deps aren't a problem, TBH, as they'll just dep-wait.
[12:14] <cjwatson> So I think we could open without debhelper, since it isn't trivial.
[12:15] <cjwatson> Though there are some flag handling features that might not have been build-depped on.
[12:17] <doko> pitti, cdbs merge?
[12:19] <infinity> +           // do not show ignoration warnings for directories
[12:19]  * infinity giggles at "ignoration".
[12:20] <micahg> automake?
[12:20] <doko> no new version
[12:21] <cjwatson> Yeah there is, just not in wheezy
[12:21] <doko> ahh
[12:22] <cjwatson> Shall I do that?  I have the last Ubuntu changes.
[12:22] <doko> sure
[12:22] <pitti> away -all
[12:22] <pitti> err
[12:23] <pitti> doko: can do
[12:26] <micahg> libreoffice ended up on sulfur, this should be interesting :)
[12:28] <pitti> why, I thought that one was faster than the older two?
[12:30] <micahg> yes, and with more cores, it should be interesting to see how fast it tears through it
[12:32] <cjwatson> ah, good, automake1.11 is a sync
[12:34] <micahg> is there any point in moving to lsb 4.1 before opening?
[12:35] <doko> micahg, I don't think so
[12:35] <cjwatson> Shouldn't be needed pre-opening
[12:36] <doko> I didn't track clang and fpc
[12:36] <doko> infinity, can you upload clang defaulting to armv5t on armel?
[12:37] <pitti> cjwatson, doko: is someone already handling the merging of debhelper?
 So I think we could open without debhelper, since it isn't trivial.
[12:40] <doko> pitti, so I assume no
[12:42] <cjwatson> pitti: 13:13 <cjwatson> The debhelper merge has a conflict in dh_installinit which is tied in with Steve's efforts to merge proper Upstart handling into Debian
[12:42] <cjwatson> 13:14 <cjwatson> And the new dh_installinit has the effect of installing both Upstart jobs and init scripts, rather than our previous scheme
[12:43] <cjwatson> 13:14 <cjwatson> slangasek: ^- I'm not confident in my ability to do the debhelper merge accurately; do you think you could deal with it?
[12:43] <pitti> cjwatson: thanks
[12:43] <cjwatson> pitti: If you think you can deal with this accurately - that is, if you know authoritatively which way we should be handling init scripts - be my guest, but I don't
[12:44] <pitti> I have 45 minutes left before I leave for the train station, so I'd rather not attempt that today then
[12:44] <cjwatson> I'm on the fence about opening without debhelper.  It might be better to wait until we hear from slangasek (who's on holiday) rather than rushing.
[12:46] <pitti> there are quite a number of changed compiler flag handling, these do look significant
[12:46] <cjwatson> Yeah
[12:46] <pitti> my gut feeling is that we probably want to keep our version of dh_installinit instead of Debian's "install both", but I agree, let's wait for Steve for this
[12:47] <pitti> I don't think we ever want to support sysvinit in Ubuntu again
[12:47] <cjwatson> Sure; still, the merge wasn't obvious to me anyway
[12:49] <cjwatson> doko: Do the gcc-4.6 entries on http://people.canonical.com/~ubuntu-archive/nbs.html indicate a problem, or are those waiting for builds to finish?
[12:50] <doko> cjwatson, problems, working on that
 cjwatson, infinity, pitti, micahg: I think we are ready for *ish uploads. toolchain is in place, but the -multilib packages are still broken on arm. I don't expect these to be available before tomorrow.
[12:51] <cjwatson> Oh, that
[12:51] <cjwatson> NP
[12:58] <infinity> doko: Sure.  Does llvm need a sane default target too?
[13:00] <infinity> doko: Actually, we should probably snag llvm-3.1 and clang_3.1 from experimental...
[13:01] <doko> sure, why not
[13:01]  * infinity nods.
[13:01] <infinity> I'll look at merging and/or syncing those, then.
[13:01] <infinity> After I smoke. ;)
[13:01] <doko> I'm currently not using llvm for shark/openjdk
[13:17] <pitti> "The Unapproved queue is empty. "
[13:17] <pitti> take that, didrocks!
[13:17] <pitti> *hug*
[13:17]  * didrocks hugs pitti
[13:18] <didrocks> pitti: you were fast! ;)
[13:18] <didrocks> pitti: if only my laptop didn't burn, I would be doing zg now and you would be in a worse shape! :)
[13:18] <pitti> I've become pretty acquainted with /^--- and skipping over autoconf noise :)
[13:19] <didrocks> héhé ;)
[13:21] <pitti> skaet, cjwatson: FYI, I'll be on holiday on Monday, and there is a national holiday on Tuesday
[13:21] <infinity> doko: Oh, and I wouldn't worry too much about fpc, I probably need to do an fpc transition first thing next week anyway, so it'll sort itself.
[13:21] <pitti> so be back on Wed
[13:22] <cjwatson> Righto
[13:22] <cjwatson> Have fun :)
[13:22] <skaet> pitti, cjwatson,   I'll be flying on monday,  then taking a couple of days off.   Will send out email when I know which ones.
[13:22] <skaet> enjoy your long weekend pitti.
[13:31] <infinity> doko: Oh, ocaml might need love too...
[13:31] <pitti> doko: cdbs uploaded
[13:32] <cjwatson> syncing perl - our only outstanding changes are Conflicts on pre-12.04 versions
[13:32] <pitti> train time, see you next Wed! You can call my mobile for emergencies
[13:34] <infinity> doko: Or maybe ocaml will just magically fix itself on rebuild.  Handy.
[13:36] <ogra_> bah, quantal only just opened and we already have the first 3 ftbfs
[13:36] <ogra_> (on arm that is)
[13:37] <infinity> ogra_: ?
[13:37] <infinity> ogra_: If it's toolchain packages failing due to multilib, ignore it.
[13:38] <infinity> And indeed, it is.
[13:38] <ogra_> yeah, i wasnt seriously complianing a day after opening :)
[13:41] <cjwatson> Is ocaml pre-opening?
[13:41] <infinity> Yes.
[13:41] <cjwatson> Bam.
[13:53] <infinity> cjwatson: I think it's probably safe to assume that anything that looks kinda like a compiler is pre-opening.
[13:54] <cjwatson> Heh
[13:54] <cjwatson> Just like to check
[14:31] <infinity> doko: I assume you've noticed, but your gcc-4.7 in the PPA seems sad.
[14:47] <ev> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/989779 - skaet
[14:47] <ubot2> Launchpad bug 989779 in apport ""Problem already known" alert and Launchpad page still open post-release" [Undecided,New]
[14:49] <skaet> pitti,  can you look into ^
[14:49] <skaet> ?
[14:49] <seb128> skaet, he's not online
[14:49] <ogra_> skaet, he is gone until wed.
[14:50] <seb128> skaet, and off until wednesday
[14:57] <skaet> seb128, ogra_ thanks.  didn't realize he'd eod.
[14:57] <skaet> ev or cjwatson,  can either of you handle?
[15:00] <cjwatson> I don't know apport or the error tracker design well enough to be comfortable with doing that in a rush
[15:01] <skaet> cjwatson, ack.    ev just said he'll tackle.   Thanks.
[15:01] <cjwatson> cool
[15:04] <infinity> cjwatson: Going to be uploading/syncing some llvm* stuff, not to be accepted until the current publisher run is done.
[15:04] <cjwatson> OK
[15:04] <cjwatson> Oh, boost-defaults can go now, can't it
[15:05] <doko> infinity, yes, known
[15:24] <cjwatson> infinity: llvm* ready to go now?  The publisher's in cron.germinate, so should be enough for buildds.
[15:25] <infinity> cjwatson: Yep.
[15:26]  * cjwatson accepts
[15:26]  * infinity grabs the one in new.
[15:26] <cjwatson> Go for it.
[15:27] <cjwatson> Oh, I think I'll let distro-info-data in too.
[15:27] <infinity> cjwatson: The kernel sync from -updates would be fine too.
[15:27] <cjwatson> Good point.
[15:29] <cjwatson> In fact all the syncs from -updates are fine.
[15:30] <stgraber> skaet: any objection to marking both pre-release and final milestones as released on the tracker?
[15:31] <skaet> stgraber,  no objection.   Thanks!  :)
[15:32] <stgraber> skaet: done. I'll keep all the precise ones as released until we get the first quantal daily. I'll then archive them all
[15:32] <SpamapS> infinity: I'll definitely give it a shot.
[15:33] <skaet> stgraber,  sounds good.   Thanks.   I'll add it as a task to the checklist for day+1 tasks.
[15:35] <ev> fix for bug 989799 uploaded to precise-proposed
[15:35] <ubot2> Launchpad bug 989799 in nova "create instance min/max count defaulting logic is reversed in EC2 and native OS APIs " [Undecided,New] https://launchpad.net/bugs/989799
[15:36] <ev> err bug 989779
[15:36] <ubot2> Launchpad bug 989779 in apport ""Problem already known" alert and Launchpad page still open post-release" [Undecided,New] https://launchpad.net/bugs/989779
[15:36] <skaet> thanks ev
[15:37] <skaet> gema, jibel - are either of you online now?    we need to figure out a plan for quickly testing this apport fix.
[15:38] <ev> please reject
[15:38] <ev> need to rework that
[15:38]  * skaet doing
[15:38] <jibel> skaet, pong
[15:43] <skaet> hiya jibel
[15:43] <skaet> when ev gets the apport package uploaded,  would you be able to do some checking that its doing the right thing now, and not causing side effects?
[15:43] <skaet> (next version ;))
[15:44] <jibel> skaet, sure. do you have an ETA ? my plan was not to stay late tonight
[15:45] <skaet> jibel, ev's working on the revised version now.
[15:45] <skaet> hopefully within the hour,  but if not,  could you hand off to hggdh?
[15:45] <skaet> we'd like to get this fix out there, ASAP.
[15:46] <jibel> skaet, ack. within the hour is fine.
[15:46] <jibel> I'll ask hggdh if it's unverified when I'll leave.
[15:46]  * hggdh is aware, and waits
[15:47]  * jibel leaves now then ;)
[15:47]  * hggdh runs
[15:54] <skaet> Thanks hggdh, jibel   :)
[15:57] <ev> ^ skaet please accept that one. The additional changes weren't actually needed in the end, but make the check it's doing more consistent (not assuming certain things are set in /etc/apport/crashdb.conf).
[15:58] <skaet> ev,  will do,  waiting for the diff.
[15:58] <infinity> doko: The clang merge might not happen until I get home, it's a bit entertaining.  clang's rdep list is tiny, I'll just rebuild it later when I'm happy with my local builds.  (want to fix some armhf stuff at the same time anyway)
[15:58] <infinity> cjwatson: ^
[15:58] <skaet> hggdh,  version you're going to need to wait to be built in -proposed, and test with is apport 2.0.1-0ubuntu7
[15:59] <hggdh> skaet: ack
[15:59] <cjwatson> infinity: *nod*
[15:59] <infinity> cjwatson: And I'll be doing an fpc porting/transition bit earlier next week too so, for me, I'm done with toolchain bits until Monday.
[16:00] <cjwatson> Anything else you care about pre-opening?
[16:00] <infinity> cjwatson: When do you plan to mass-sync universe?  I'd like it to happen after I land fpc, so I don't have to transition twice.
[16:00] <cjwatson> The only thing on my list right now is (?)debhelper.
[16:00] <cjwatson> infinity: Right after opening.
[16:00] <seb128> ev, you made apport native in that upload
[16:00] <infinity> cjwatson: Oh well.  I'll transition fpc twice if I have to, not world-ending. ;)
[16:00] <seb128> ev, i.e not diff.gz, but a plan tarball
[16:01] <infinity> cjwatson: Might have to anyway, if the build-deps aren't all sane, since we may end up syncing in a weird order that breaks it all, so meh.  I'll wait for the world to settle and then fix fpc properly.
[16:01] <cjwatson> infinity: Might take us until early next week before we open anyway
[16:02] <cjwatson> fpc doesn't have many rdeps, does it?
[16:02] <infinity> (Ideally, I'd get a new fpc in right now, but that requires a bootstrap...)
[16:02] <infinity> Actually, wait.  No, I can fudge it.
[16:02] <infinity> I can sync Debian's fpc now, and then do the armhf bootstrap later.
[16:02] <seb128> skaet, ev: not sure if apport should be reuploaded with a diff.gz?
[16:02] <infinity> I'll do that.
[16:02] <cjwatson> In fact, it seems to be just lazarus?
[16:03] <infinity> fp-compiler
[16:03] <infinity> Should be a lot more than lazarus.
[16:04] <ev> seb128: eep, sorry about that
[16:04] <cjwatson> Ah, yes
[16:04] <infinity> Anyhow, synced fpc as a pre-open thing.
[16:04] <cjwatson> ev: Rejected that one then
[16:05] <cjwatson> accepted fpc
[16:05] <infinity> There.  That should be happy for everything but clang, and I'll deal with clang on Monday.
[16:05] <infinity> Their beautiful misunderstanding of multiarch makes me want to be a bit more careful with it.
[16:06] <infinity> (testing for /lib/triplet/ as a way to determine the host arch is *brilliant*)
[16:06]  * cjwatson blinks
[16:06] <infinity> I shit you not.
[16:09] <infinity> cjwatson: Also, I don't want to alarm you, but no one's done the inaugural vim merge yet.  Are we slipping in our old age?
[16:09] <ev> cjwatson: cheers
[16:11] <infinity> Oh, not even a merge in this case, just a bump to add quantal.
[16:11]  * infinity does that.
[16:13] <cjwatson> infinity: heh, go for it ...
[16:22] <cjwatson> ev: Looks good to me.
[16:22] <ev> yay
[16:30] <infinity> And, of course, the no-change rebuild of llvm-2.8 fails.
[16:30] <infinity> Tempted to just remove it.
[16:30]  * infinity goes rdep hunting.
[16:30] <infinity> Hah, and 2.9 also fails, and we use that one.
[16:31] <infinity> Thanks, gcc-4.7.
[16:31] <infinity> Might be time to just switch to 3.0 or even 3.1 and drop all the old ones, but I don't have the time tonight to look into that pain.
[16:31] <infinity> (Have to be out of here in ~30m)
[16:38] <slangasek> cjwatson: on vacation, but not staying away from the archive ;) I'm happy to do that merge today
[16:38] <slangasek> cjwatson: btw, do we have dpkg flags behavior restored to match Debian's now?
[16:41] <infinity> cjwatson: Right.  New plan.  llvm-2.x sucks, I'm going to move llvm-py and llvm-defaults to 3.0 and bounce out 2.x completely.
[16:42] <infinity> cjwatson: But I have about 15 minutes left to do that, so... That's a "when I get home" thing, to make sure I test it a bit before I do it.
[16:43] <cjwatson> slangasek: No, I was thinking about that but have been too scared :-)
[16:43] <infinity> Scared, or scarred?
[16:43] <cjwatson> Yes.
[16:43] <infinity> ;)
[16:43] <cjwatson> That would be an easy change in advance of the merge, I suppose.  Are we sure we'll have enough effort to restore hardening flags everywhere for 12.10?
[16:43] <slangasek> :)
[16:43] <infinity> Anyhow, as above, don't worry too much about all things llvm/clang, I'll sort it all when I land.
[16:43] <cjwatson> Noted
[16:44] <slangasek> we did say we were going to revert that after 12.04
[16:44] <cjwatson> We did
[16:44] <slangasek> how much effort do we expect it to be to restore the flags?
[16:44] <cjwatson> I can imagine about half an hour per package + whatever it takes to set up something to scan for the problem
[16:45] <cjwatson> Which I suppose can be a lintian check on lintian.ubuntuwire.org
[16:45] <slangasek> so we don't really have a package count at this point
[16:45] <cjwatson> Not AFAIK
[16:45] <slangasek> ok
[16:45] <slangasek> well, IIRC from the first time around it was a fairly small percentage of packages
[16:45] <slangasek> and should be smaller now due to Debian uptake
[16:45] <cjwatson> In fact, to find out how many we *would* have to change, we'd have to test-rebuild everything and then run hardening-check against them
[16:47] <cjwatson> Um, isn't it everything that doesn't use dpkg-buildflags?
[16:47] <slangasek> I thought it was only things that explicitly overrode flags in debian/rules without checking dpkg-buildflags?
[16:48] <slangasek> maybe that was a subset of the problem
[16:48] <cjwatson> Those were the ones that broke due to the earlier iteration of our workaround, I think
[16:48] <ScottK> cjwatson: boost1.49 binaries got accepted into Universe.  They need to be in Main or boost-defaults won't build.
[16:49] <cjwatson> ScottK: boost1.48 was in universe, though
[16:49] <ScottK> cjwatson: Yes, but this is replacing 1.46
[16:49] <cjwatson> Oh, I missed that
[16:50] <cjwatson> Promoted, thanks - I expect some of the binaries will want to fall back to universe later, but this will do for now
[16:50] <ScottK> It's a bit of an odd situation where we got 1.48 and an updated defaults via autosync after we decided to stick with 1.46 for oneiric.
[16:51] <slangasek> cjwatson: hmm, there are some unpleasant trade-offs with this apport change
[16:51] <ScottK> That should do it.  We'll want to give main users a chance to convert before dropping stuff back.
[16:51] <slangasek> (skaet just tagged me to follow through on it)
[16:51] <cjwatson> Oh?  It looked roughly in line with previous code
[16:52] <slangasek> cjwatson: it may indeed have been... but does this affect bug patterns?
[16:52] <cjwatson> That I'm not sure
[16:52] <cjwatson> Has ev already left?  I don't know this code as well as I should.
[16:52] <slangasek> because we explicitly put in some bug patterns pointing to pages with documentation to help users fix their upgrade issues
[16:52] <cjwatson> (And I have to finish up soon)
[16:53] <cjwatson> It's in -proposed, I guess v-failed will do for now if it's breaking stuff ...
[16:53] <slangasek> in the short term I'm happy to err in the direction of less interaction, but would like to follow through on the bug patterns question
[16:57] <slangasek> cjwatson, pitti: btw, as far as the debhelper merge is concerned, over the longer term I do want to get us back in sync with debian on dh_installinit so we *would* have the init scripts installed and lying dormant; but a prereq for this would be LSB header fixes so we could use insserv as intended
[16:57] <slangasek> so that's pretty low priority
[16:57]  * cjwatson looks for a package he can test against new dpkg
[16:57] <slangasek> (the only real benefit is further reducing delta with Debian, in terms of both packaging and behavior)
[16:57] <cjwatson> Or I mean the proposed dpkg change
[16:58] <cjwatson> I think I need something that (a) doesn't set CFLAGS/LDFLAGS itself and (b) doesn't use dpkg-buildflags
[16:59] <cjwatson> And (c) doesn't use hardening-includes or similar
[16:59] <cjwatson> Perhaps man-db 2.5.7-4 is close enough
[17:03] <cjwatson> Annoyingly, lintian.uw.org isn't running a new enough version of lintian for the hardening checks yet
[17:04] <cjwatson> Ah, because it isn't released yet
[17:05] <cjwatson> Oh and (d) actually still builds, bah
[17:13] <debfx> aren't the hardening flags enabled in gcc anyway?
[17:13] <jibel> ev, I verified apport 2.0.1-0ubuntu7, it fixes 989779. I also created 2 crashes that don't exist in the crashdb (a syntax error and an import error in update-manager) Is there a way to verify that the reports have been uploaded ?
[17:14] <skaet> jibel, ev's left the building right now.    slangasek,  thoughts?
[17:15] <slangasek> sorry, I don't know
[17:15] <slangasek> debfx: some, not all; I don't remember the precise details of what blew up last time we tried to stop force-setting dpkg-buildflags
[17:20] <jibel> skaet, I'll update the report with my verification but will set to verified once there is a confirmation that reports are still uploaded.
[17:21] <gema> skaet: what is this change about?
[17:21] <gema> why is it going in so late?
[17:21] <gema> or is this for 12.04.1?
[17:22] <gema> slangasek: I thought you were off!
[17:22] <gema> in fact, I thought I was off too :/
[17:22] <slangasek> jibel: if you have a .upload stamp file in /var/crash, that should be sufficient verification
[17:23] <slangasek> gema: "off" is a funny concept ;)
[17:23] <slangasek> it just means I'm not answerable to my manager for anything I do today ;)
[17:24] <gema> uhmmmm... I am watching you, slangasek  :P
[17:24] <jibel> slangasek, it's there. verification-done :) thanks
[17:26] <slangasek> jibel: great, thanks - yeah, that's sufficient because whoopsie does the actual uploading and is an entirely separate package
[17:36] <slangasek> hggdh: jibel already tested apport, so I've copied it to -updates now
[17:36] <slangasek> hggdh: so you're off the hook :)
[17:36] <hggdh> slangasek: roj, thank you
[17:37] <skaet> thanks slangasek
[17:38]  * skaet --> out of millbank
[17:53] <claydoh> torrent for Kubuntu i386 desktop gives an error:
[17:53] <claydoh> rejected by tracker - Requested download is not authorized for
[17:53] <claydoh> use with this tracker.
[17:54] <claydoh> file downloads but doesn't seed
[17:54]  * ScottK pointed ^^^ since he recalled issues with the Ubuntu torrents yesterday.
[17:54] <claydoh> where would the best place to report that? All other torrents seem fine
[17:55] <cjwatson> here - I'll have a look shortly
[17:55] <claydoh> Ok thanks!
[17:58] <cjwatson> claydoh: should be fixed soon, sorry about that
[17:59] <cjwatson> I need to scan for these properly when I'm not supervising kids
[18:00] <claydoh> cjwatson: thanks!
[18:36] <ScottK> Would someone please de-New boost-defaults?
[19:01] <cjwatson> ScottK: done
[19:02] <cjwatson> three nested screen levels wasn't at all confusing there.  took me two goes to detach the right one afterwards.
[19:03] <ScottK> Thanks.
[19:28] <slangasek> ^a aa ^a ^a a
[19:30] <slangasek> cjwatson: wrt dpkg-buildflags: http://outflux.net/ubuntu/hardening/
[19:33] <cjwatson> maybe I should learn how to use canonistack so I can do comparison test rebuilds in it
[19:45] <slangasek> cjwatson: I'm having difficulty actually working out why we needed dpkg-buildflags to do the exports at all in Ubuntu... is there a specific subset of these flags that aren't being set by default in gcc?
[19:45] <slangasek> I found the rationale for the debhelper compat hack, but not for the dpkg-buildflags part itself
[20:05] <micahg> slangasek: since the packaging might modify the output?
[20:06] <slangasek> micahg: I don't follow
[20:07] <micahg> don't some packages now expect dpkg-buildflags output and then add modifications on top of it?
[20:07] <slangasek> what if they do?  if those flags are already part of the gcc defaults, how does that hurt anything?
[20:07] <cjwatson> micahg: I think that's mostly unrelated, although there are perhaps some packages that will misbehave if *FLAGS isn't set in the environment, but I'd expect rather few since Debian doesn't do that
[20:07] <micahg> or would they get the same modifications if dpkg-buildflags did nothing since they're our default compiler
[20:07] <slangasek> yeah, that's what I would expect
[20:07] <cjwatson> How about -Wl,-Bsymbolic-functions?  I don't think the linker sets that by default
[20:08] <cjwatson> -fstack-protector is default; is --param=ssp-buffer-size=4?
[20:08] <slangasek> I'm not at all sure
[20:08] <cjwatson> -D_FORTIFY_SOURCE=2 is default
[20:09] <slangasek> kees thought only -Werror=format-security was affected
[20:09] <cjwatson> -Wformat and -Wformat-security are default; -Werror=format-security is not documented as such
[20:09] <cjwatson> -Wl,-z,relro is not documented as default
[20:10] <cjwatson> DEB_BUILD_OPTIONS handling would change a bit in the absence of exporting, but that doesn't affect our default builds
[20:10] <slangasek> where are you finding the documentation of the defaults?
[20:11] <cjwatson> info gcc-4.6
[20:11] <cjwatson> and looking in info ld for the -Wl,* ones
[20:11] <cjwatson>      NOTE: In Ubuntu 8.10 and later versions, for LDFLAGS, the option
[20:11] <cjwatson>      `-Wl,-z,relro' is used.  To disable, use `-Wl,-z,norelro'.
[20:12] <cjwatson> aha, that's in gcc-4.6
[20:12] <cjwatson> still need to figure out how to check for -Wl,-Bsymbolic-functions, though
[20:14] <ScottK> cjwatson: On a different topic (when you have some spare context) - Since I won't be at UDS, would you be willing to lead a session on changing build priority bases on seeded/packagesets as I proposed on ubuntu-devel a few weeks ago?  I can draft up a spec, but I think someone who'll be at UDS ought to lead the discussion.
[20:14] <cjwatson> Yes, I guess so; you think it needs a UDS session and not just a bug?
[20:15] <ScottK> If you think a bug is enough, I'm happy with that.
[20:15] <ScottK> There's plenty to do at UDS without inventing sessions that aren't needed.
[20:15] <cjwatson> Let me have a quick hunt for where this is implemented
[20:16]  * cjwatson doesn't know the buildmaster code that well
[20:17] <kees> hrm, did I push --param=ssp-buffer-size=4 into Ubuntu's gcc? I thought I did...
[20:18] <cjwatson> Ah, here we go, lib/lp/soyuz/model/buildpackagejob.py:BuildPackageJob.score()
[20:18] <cjwatson> That's actually relatively readable
[20:18] <kees> hrm, looks like I didn't. So --param=ssp-buffer-size=4 is only in dpkg-buildflags
[20:19] <kees> (as is -Werror=format-security). relro, as you found, has been in Ubuntu gcc for a while.
[20:19] <kees> https://wiki.ubuntu.com/ToolChain/CompilerFlags <- so I don't think this is lying
[20:19] <cjwatson> ScottK: Did we think it should be different for different packagesets, or just a bonus for being in a packageset at all?  (The latter is a lot easier since I don't have to figure out where to put the scores.)
[20:20] <ScottK> I think it's got to be specific packagesets get a bonus.
[20:20] <cjwatson> Drat.
[20:21] <ScottK> There are pakcagesets like mono that are completely unrelated to this question.
[20:21] <cjwatson> In that case it probably needs a session, but only if at least one Launchpad developer who knows anything at all about buildmaster can be there.
[20:21] <cjwatson> Or soyuz.
[20:21] <ScottK> That would be wgrant or who?
[20:21] <cjwatson> Maybe StevenK or bigjools or jtv.
[20:21] <ScottK> OK.  I'll ask around and see who's going to be there.
[20:21]  * cjwatson peers at the attendance list.
[20:22] <ScottK> Oh.  Good point.  Forgot there was one of those.
[20:22] <slangasek> kees: what does the ssp-buffer-size=4 mean?  That one's always been opaque to me
[20:22] <slangasek> if some packages start building without it, is that a big deal?
[20:22] <cjwatson> No sign of any of those people.  Maybe we'd be better off figuring it out on IRC.
[20:22] <cjwatson> kees: Do you happen to know if there's a way to tell if a given library has been built with -Wl,-Bsymbolic-functions?
[20:23] <cjwatson> I seem to remember that that was a performance improvement and I'd hate for it to gradually drift away.
[20:23] <cjwatson> ScottK: It might be as simple as adding a score column to Packageset, defaulting to zero, and adding an API method to set it.
[20:24] <cjwatson> That wouldn't be desperately hard.
[20:24] <ScottK> OK.  Maybe wgrant will pop up and some point and we can discuss.  He'll at least have the backscroll.
[20:25] <cjwatson> Then we could tweak the scores fairly freely and it wouldn't have to be analysed all that carefully in advance.
[20:26] <Laney> why packagesets and not seeded?
[20:26] <cjwatson> Launchpad knows about packagesets.  It doesn't know about seeds.
[20:26] <Laney> but it knows about packages and we know about packages in seeds
[20:26] <cjwatson> And I really don't want to put weeks or months of effort into the latteer.
[20:26] <cjwatson> *latter
[20:26] <cjwatson> It's irrelevant what we know.  It needs to be something in the Launchpad database.
[20:27] <cjwatson> I think packagesets would be good enough most of the time.  This doesn't need to be perfect (and probably can't be).
[20:27] <Laney> I am suggesting that the new priority column could be per-package.
[20:27] <cjwatson> It's not impossible, but I think it'd be overkill.
[20:28] <ScottK> Would it be simpler to make a need packageset called 'seeded' and bonus that one alone?
[20:28] <cjwatson> I don't want to hardcode any more Ubuntu-specific naming into Launchpad.
[20:29] <cjwatson> I'd rather it were entirely agnostic about packageset names.
[20:29] <cjwatson> (And I don't think it'd be particularly simpler, no)
[20:31] <cjwatson> I'd also rather change a relatively little-used table like Packageset than a table that gets hit all the time like DistributionSourcePackage ...
[20:31] <ScottK> OK.
[20:31] <cjwatson> But maybe wgrant will tell me that's unnecessary paranoia
[20:32] <ScottK> Is there such a thing as unnecessary paranioa with respect to Soyuz?
[20:32] <kees> slangasek: when gcc decided whether or not to add the ssp prefix/suffix to a function, it looks for any function with a character array of ssp-buffer-size bytes or more. The default is 8, but there are some things that are still a bit in danger, so gentoo had initially suggested the change, and RH and SuSE followed, and I tended to agree so I added it to Debian with the hopes of getting it into Ubuntu as well.
[20:33] <kees> slangasek: it's not a big deal to build without it. just marginally less "safe", though those numbers are, I'm sure, just hand-waving.
[20:33] <kees> cjwatson: -Wl,-Bsymbolic-functions I don't know about, unfortunately. that was all doko :)
[20:34] <cjwatson> It's impossible to google for since the results are full of build logs :-(
[20:35] <ScottK> There should be some special character sequence that is in all build logs that you could use to exclude them from results.
[20:35] <cjwatson> kees: So, I don't know, it's an odd trade-off.  Removing our band-aid would probably encourage us to push dpkg-buildflags patches up to Debian faster, but there's a risk of some regressions in the meantime.
[20:36] <cjwatson> And, from this discussion, regressions that aren't actually terribly easy to detect.
[20:37] <cjwatson> We'd lose ssp-buffer-size=4, some format-security errors would stop failing builds, and we might have changes to symbol binding in shared libraries.
[20:38] <cjwatson> The hardening options in DEB_BUILD_OPTIONS would probably start behaving differently by default, and I'm not sure how much you care.
[20:38] <cjwatson> And there'd be subtle changes due to *FLAGS being no longer set in the environment by default, which has some non-obvious effects on make's behaviour (although on the whole it would probably result in fewer annoying failures).
[20:41] <cjwatson> Maybe this is worth it; it doesn't sound immediately perilous.  I'd like to have some notion that we'll be able to scan for the differences, though.
[20:41] <kees> cjwatson: I don't feel strongly about it. I'd like to move ssp-buffer-size into the gcc patch regardless.
[20:42] <cjwatson> We can't be failing that many builds due to format-security right now anyway, since there aren't that many failures.
[20:42] <kees> when I added -Werror=format-security in Debian, I did so under the impression that Ubuntu wasn't force-exporting that into all builds. :P
[20:42] <cjwatson> Heh, the whole thing is confusing and perhaps reducing confusion is a bigger benefit that anything else.
[20:42] <kees> so, really, I'd prefer not having that explicit export. but that breaks stuff doko was wanting to have exported.
[20:42] <cjwatson> And our current dpkg-buildpackage patch is certainly awful.
[20:43] <cjwatson> Well, only really -Wl,-Bsymbolic-functions, unless there's stuff that needed CFLAGS='-g -O2' in order to behave correctly.
[20:43] <cjwatson> But FFS it's 2012.
[20:43] <kees> hah
[20:44] <kees> my stance on the ubuntu compiler-hardening has always been about making sure even non-package-builds get the options enabled.
[20:44] <kees> I continue not to be able to make time to get the option upstreamed to gcc as a configure option, though. Zorry (gentoo dev) has been working on it, though.
[20:47]  * jdstrand would add that this is a differentiating security feature for Ubuntu that we would like to maintain
[20:48] <jdstrand> hi kees! :)
[20:48] <cjwatson> jdstrand: The compiler changes or the dpkg-buildpackage export change?
[20:48] <jdstrand> to be clear, we want our non-package-builds to have the options enabled. where that happens or whether that happens in Debian or Ubuntu doesn't matter to me
[20:49] <cjwatson> Right, AFAIK nobody is talking about backing out the compiler changes
[20:49] <jdstrand> cool
[20:49] <cjwatson> Just trying to evaluate the effect of backing out the awful dpkg-buildpackage change
[20:51] <kees> hi jdstrand ! :)
[20:52] <kees> cjwatson: fwiw, from my compiler-hardening perspective, I am in favor of dropping the dpkg-buildpackage change.
[20:53] <cjwatson> Because it obscures compiler behaviour?
[20:55] <kees> cjwatson: well, because it creates, for me, unexpected behaviors (packages not expecting -Werror=format-security are getting those options)
[20:56] <cjwatson> Hm, I thought you were generally in favour of stuff failing rather than building insecurely
[20:57] <cjwatson> Aha, I just remembered that we don't automatically export -Werror=format-security anyway
[20:57] <cjwatson> So that's moot
[20:58] <cjwatson>         # While -Werror=format-security does catch many real bugs, it also
[20:58] <cjwatson>         # causes many build failures and causes a number of configure tests
[20:58] <cjwatson>         # to silently fail.  It was not exported to the environment in any
[20:58] <cjwatson>         # released version of Ubuntu.
[20:58] <cjwatson>         $build_flags->strip($flag, '-Werror=format-security', undef);
[21:05] <kees> yeah
[21:06] <micahg> should we revert that change for quantal?
[21:15] <cjwatson> micahg: Well, that's what we were discussing for the last hundred lines or so :-)  But not just that bit, the whole export block around it
[21:16]  * micahg needs to stop trying to help on 4 hours of sleep :)
[21:49] <kees> cjwatson: correction -> ubuntu _is_ already running with ssp-buffer-size=4. I missed where I'd patched it.
[22:05]  * ScottK would appreciate it if a "C" archive admin would do the backport in Bug #990140.
[22:05] <ubot2> Launchpad bug 990140 in precise-backports "Please backport debootstrap 1.0.40 from quantal to precise" [Wishlist,In progress] https://launchpad.net/bugs/990140
[22:06] <slangasek> kees, cjwatson: right, I think it's better to reduce the confusion... if we're wrong about having the resources to fix things up this cycle, it's not grave
[22:06]  * kees nods
[22:07] <ScottK> Ah.  slangasek: Would you please take care of the debootstrap backport? ^^^
[22:07] <kees> I've just opened 990141 with a patch to document the ssp-buffer-size change, btw (first done in 10.10)
[22:07] <slangasek> ScottK: looking
[22:07] <ScottK> Thanks.
[22:14] <slangasek> ScottK: done
[22:14] <ScottK> slangasek: Thanks.
[23:11] <slangasek> hmm, failure trying to submit a merge proposal for quantal: bzr: ERROR: File exists: '/srv/bazaar.launchpad.net/mirrors/00/09/60/5f'
[23:12] <slangasek> oh, possibly a wrong branch state
[23:13] <slangasek> yeah
[23:20] <cjwatson> OK, I'm building everything in main in a canonistack instance with a chroot with the flags export hack deleted from dpkg-buildpackage; may not need to complete that run, but I'll see how it does over the weekend
[23:20] <cjwatson> least sophisticated buildd ever, it's a for loop around sbuild ;-)
[23:22]  * slangasek grins
[23:29] <Daviey> rebuildd, whilst not that cleanly written.. is great for this.. i had it running across 3 different machines before, sharing the same dispatcher.
[23:29] <Daviey> took some changes to make it work with sbuild.. and a seperate *.py for adding jobs.. but that along with lpapi worked really nicely.
[23:31] <cjwatson> yeah, I might try something a bit more packaged when I have a bit more time.  mini-buildd looked promising too.
[23:32] <Daviey> ISTR mini-buildd was single host?  you couldn't dispatch the jobs to multi-hosts?
[23:32] <cjwatson> It looks smarter than that to me, but I didn't look very hard
[23:33] <cjwatson> Its package description talks about an autobuilder network
[23:33] <cjwatson> And judging by its dependencies it already works with sbuild
[23:34] <Daviey> Ah, groovy.. I must have been thinking of another tool.
[23:46] <Daviey> cjwatson: The thing i liked about rebuildd was that i could use the sqlalchemy orm to produce reports on pass/fail/dep-wait.. doesn't seem mini-buildd is db backed.
[23:47] <cjwatson> heh, I'm just doing grep ^Status: ;-)
[23:47] <cjwatson> (sure, I suspect the second go-around I'll do something more sophisticated)
[23:48] <Daviey> heh
[23:52] <wgrant> ScottK, cjwatson: There's going to be a Launchpad dev at UDS, but nobody who knows anything about Soyuz. I'd go with the priority on packageset.
[23:52] <wgrant> Pretty simple.
[23:53] <ScottK> wgrant: Is a bug enough for this?
[23:53] <wgrant> Yes, particularly if cjwatson does the work, otherwise it won't be done for 2 years
[23:53] <ScottK> Sigh.
[23:55] <cjwatson> I can do the work, that's fine
[23:55] <wgrant> It's not a particularly big piece of work
[23:56] <cjwatson> You reckon my assessment above (add column on packageset, export on webservice, add in .score) is about right?
[23:56] <cjwatson> Aha, -Wl,-Bsymbolic-functions is detectable in the output of 'objdump -R'
[23:57] <cjwatson> So I think I'll build main, extract libraries, objdump -R, compare with real archive
[23:59] <wgrant> cjwatson: Yeah


[00:00] <vorlon> $ ls -ld ubuntu/dists/hirsute/main/binary-amd64/Packages.gz
[00:00] <vorlon> -rw-rw-r-- 1 cdimage cdimage 1799322 Feb 15 02:44 ubuntu/dists/hirsute/main/binary-amd64/Packages.gz
[00:00] <cjwatson> I think this may be a stuck anonftpsync lock
[00:00] <vorlon> $
[00:00]  * vorlon nods
[00:00] <cjwatson> There's an oldish cron.daily-live process running
[00:01] <teward> oh well wxl didn't poke me
[00:01] <teward> *shoves wxl out the window*
[00:01] <cjwatson> Probably just needs killing and then let everything settle?
[00:01] <vorlon> cjwatson: the oldest I saw was from Feb 28 which doesn't account for things being stuck since the 15th?
[00:02] <cjwatson> IDK, maybe there were image build issues then or something
[00:02] <cjwatson> Or multiple overlapping stuck builds
[00:02] <cjwatson> Probably less interesting to track down the precise sequence of events than to just mash it into working again
[00:02] <cjwatson> There should be indications of held locks in CD build logs if people really want to go looking
[00:03] <wxl> it's an irritating thing that i would hope would have been caught somehow in the iso build process, but tbh i've never once seen something similar so i don't know if we need to sweat it too much
[00:03] <wxl> cjwatson: what sort of strings should i be looking for? "lock" something or other?
[00:03] <cjwatson> IIRC it's a hard-to-resolve requirements clash between (a) that and (b) supporting parallel image builds during release preparation
[00:04] <cjwatson> "unable to start rsync; lock file exists" IIRC
[00:04] <cjwatson> or maybe "Parallel build; waiting"
[00:04] <cjwatson> I think the latter actually
[00:05] <vorlon> I'm running a manual sync now
[00:05] <vorlon> seems to be doing its thing
[00:05] <cjwatson> I suspect the easiest fix would be some kind of timeout so that processes can't sit around for days like this
[00:05] <teward> cjwatson: you mean like a watchdog that has an overarching timer on it, and when it sits for eternity past $LIMIT it hardkills and errors?
[00:05] <wxl> Parallel build; waiting for Lubuntu mirror to sync
[00:05] <teward> overarching watchdog daemon*
[00:05] <teward> *goes to fetch more caffeine*
[00:06] <wxl> that's right at the head of https://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/hirsute/daily-live-20210301.1.log
[00:06] <cjwatson> though nowadays nie mój cyrk, nie moje malpy
[00:06] <wxl> cjwatson: i couldn't agree more
[00:06] <cjwatson> (s/malpy/małpy/, bah)
[00:06] <wxl> eh that parallel build thing seems to be in every log so meh
[00:07] <cjwatson> It will be in a fair few of them but shouldn't be in all
[00:07] <cjwatson> Though I suppose it may depend on crontab timing
[00:07] <wxl> well ok, i did it rather quickly
[00:07] <wxl> well our crontab is always the same so XD
[00:08] <cjwatson> The general idea is that the first in a set of parallel builds syncs the local archive mirror, and all the others wait for it to sync and use the same version
[00:08] <cjwatson> Since having one of them sync the mirror while some other build is running could be bad news
[00:08] <wxl> here's one that doesn't have it https://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/hirsute/daily-live-20210104.1.log
[00:08] <wxl> took me a long while to find one that didn't
[00:09] <cjwatson> And that one was probably started by hand off the usual cron schedule
[00:09] <cjwatson> Given the .1
[00:09] <wxl> yep but not all .1's are like that
[00:09] <wxl> including last night's
[00:09] <cjwatson> Sure, no particular reason they should be
[00:09] <vorlon> cjwatson: my Polish isn't strong but lol at that being understandable
[00:10] <cjwatson> You might have to correlate builds of multiple projects with reference to the cdimage source to properly track it down :-/
[00:12] <wxl> so am i going to need to manually rebuild or what's the deal?
[00:13] <cjwatson> Or wait for the next automatic build.  But I'd recommend waiting for vorlon to say that his manual mirror sync has finished before starting a rebuild
[00:13] <cjwatson> This problem has existed since 2005 in one form or another.  It's only actually noticeable when a build gets stuck though
[00:15] <cjwatson> teward: watchdog> well I mean if you want to overengineer it sure, but I was thinking of timeout(1) :-)
[00:15] <teward> :P
[00:15] <teward> that makes sense
[00:16] <cjwatson> May need a bit of care to ensure that locks get properly cleared etc.
[00:16] <cjwatson> (Though I think cdimage deals with that since generally it's possible to kill stuck builds to clear locks and this would be no different)
[00:17] <teward> cjwatson: well, that sounds like then you need a script to handle it, something simple that makes sure that, whether killed by timeout, etc. cleans up the scripts, unless cdimage does that anyways.  The core part would be setting the hard timeout limit (i.e. timeout -k 6h 12h ...)
[00:18] <teward> (where 6h after the initial SIGTERM is issued a SIGKILL comes back if it hasn't died)
[00:18] <teward> or w/e times are preferable
[00:18] <teward> (just thinking outloud)
[00:18] <teward> but makes sense
[00:18] <cjwatson> I think cdimage does that anyway so no need to make it complicated
[00:18] <teward> *writes notes about 'timeout' command so he can decomplicate his scripts*
[00:19] <cjwatson> It might be better to do it in Python though, so it can go in the build_image_set function and automatically work for everything
[00:20] <cjwatson> That just amounts to something involving https://docs.python.org/3/library/signal.html#signal.alarm though
[00:30] <kanashiro> vorlon, thanks for the info about testbed. Regarding puma, I filed bugs upstream and I am helping one of the maintainers with debugging. For now I am preparing an upload to skip the problematic tests and allow its migration.
[01:04] <vorlon> teward, wxl[m]: ftp mirror is updated as of Mar 2 00:01 UTC
[01:06] <teward> awesome
[01:06] <teward> so do we need to kick off a manual rebuild or wait for an autobuild?
[01:06] <teward> for the Lubuntu ISOs
[01:23] -queuebot:#ubuntu-release- New binary: rustc [amd64] (hirsute-proposed/universe) [1.49.0+dfsg1+llvm-0ubuntu1] (i386-whitelist)
[01:26] <wxl[m]> Next auto is tomorrow so probably best today
[04:01] -queuebot:#ubuntu-release- New: accepted rustc [amd64] (hirsute-proposed) [1.49.0+dfsg1+llvm-0ubuntu1]
[04:01] -queuebot:#ubuntu-release- New: accepted rustc [armhf] (hirsute-proposed) [1.49.0+dfsg1+llvm-0ubuntu1]
[04:01] -queuebot:#ubuntu-release- New: accepted rustc [ppc64el] (hirsute-proposed) [1.49.0+dfsg1+llvm-0ubuntu1]
[04:01] -queuebot:#ubuntu-release- New: accepted rustc [s390x] (hirsute-proposed) [1.49.0+dfsg1+llvm-0ubuntu1]
[04:01] -queuebot:#ubuntu-release- New: accepted rustc [arm64] (hirsute-proposed) [1.49.0+dfsg1+llvm-0ubuntu1]
[04:01] -queuebot:#ubuntu-release- New: accepted rustc [riscv64] (hirsute-proposed) [1.49.0+dfsg1+llvm-0ubuntu1]
[04:01] -queuebot:#ubuntu-release- New: accepted rustc [i386] (hirsute-proposed) [1.49.0+dfsg1+llvm-0ubuntu1]
[06:49] <tjaalton> RAOF: hey, I uploaded new directx-headers to ubuntu anyway, as a new ftpmaster review could take time.. if you have a chance of having a look, that would be great :)
[08:57] <LocutusOfBorg> hello Release Team, since we know libreoffice test failure is not related to poppler and its already being worked on...
[08:57] <LocutusOfBorg> what about hinting poppler to go in?
[09:16] <Laney> LocutusOfBorg: feels bad, then we get failing libreoffice tests and have no idea if there is a further regression or not in future
[09:24] <seb128> Laney, the tests are fixed in the vcs and there is an upload planned for 7.1.1 this week, it's just going to delay a few days if we wait for that one
[09:25] <seb128> it's a packaging error which leads to have java things not installed, doesn't impact the desktop
[09:26] <Laney> seb128: next question, why do we test these things if the argument when they fail is that the failures don't matter?
[09:30] <Laney> or maybe said in a different way, if these missing java parts aren't relevant, could they not be shipped?
[09:34] <juliank> macsyfinder tests fail with autopkgtest [11:52:36]: ERROR: erroneous package: rules extract failed with exit code 1
[09:35] <juliank> I think that's because it's Architecture: all in release pocket, but amd64 only in proposed
[09:36] <juliank> So they work on amd64, but can't find the source package on other archs
[09:36] <juliank> There's only one reverse-recommends, from med-bio, so I guess we can just drop macsyfinder from the release pocket?
[09:37] <juliank> That will then make the new macsyfinder run its tests correctly
[09:37] <Laney> that's weird
[09:37] <Laney> we can hint the /unknowns though
[09:37] <juliank> Laney: I know, but it's not unprecedented
[09:38] <Laney> which part?
[09:39] <juliank> Laney: I think I read a bug in Debian that had the same cause and effect
[09:40] <juliank> Laney: I think the best approach is to force-skiptest the macsyfinder/2.0~rc1-3 upload, then that migrates, and autopkgtest for other packages should work again
[09:40] <Laney> juliank: sure, that works, can you file a mp?
[09:40] <juliank> That one passed on amd64, the failures are on dropped architectures
[09:40] <Laney> on a call atm
[09:42] <Laney> or just give me a commit, doesn't need a merge proposal
[09:43] <juliank> Laney: git pull  git+ssh://git.launchpad.net/~juliank/britney/+git/hints-ubuntu
[09:44] <Laney> cannot find remote ref HEAD
[09:44] <juliank> Laney: git pull  git+ssh://git.launchpad.net/~juliank/britney/+git/hints-ubuntu devel
[09:44] <juliank> extra devel
[09:44] <juliank> :D
[09:45] <Laney> :>
[09:45] <Laney> merci
[09:45] <Laney> done
[09:46] <juliank> Hmm do I still need to force-badtest the other unknown/$port ones? I just realized britney will still expect those to succeed for other uploads
[09:50] <juliank> Laney: I pushed force-badtest for all port arches to the same branch now
[09:50] <doko> Laney, juliank: macsyfinder is only built for amd64 (arch dependent). why is britney even trying to run them?
[09:50] <juliank> doko: It's Architecture: all in release pocket
[09:51] <juliank> doko: So both britney and autopkgtest get confused
[09:51] <juliank> doko: britney tries to run the new one on architectures it does not exist for; and autopkgtest fails to find the old source package
[09:52] <seb128> Laney, it's worth asking how useful those tests are, I just see it as a tradeoff to accept a test regression for a few days to unblock a transition if we are confident that's not going to have a visible impact for users. At the same time I don't feel strongly enough to argue if people disagree, I was just providing some context I know about on the issue (the fact that it's pending upload and not impacting desktop users)
[10:14] -queuebot:#ubuntu-release- Unapproved: accepted gnutls28 [source] (groovy-proposed) [3.6.15-4ubuntu2.1]
[10:16] <Laney> it should be requesting the set in the source archive (proposed), there must just be a bug there
[10:18] -queuebot:#ubuntu-release- Unapproved: accepted gnutls28 [source] (focal-proposed) [3.6.13-2ubuntu1.4]
[10:58] <LocutusOfBorg> Laney, can we please hint golang-github-coreos-gexpect? regressed in release?
[10:58] <LocutusOfBorg> https://autopkgtest.ubuntu.com/packages/golang-github-coreos-gexpect/hirsute/amd64
[10:58] <LocutusOfBorg> only on amd64
[10:59] <LocutusOfBorg> passed only two times in the history
[11:01] <Laney> LocutusOfBorg: probably, be nice to file a bug in debian too
[11:01] <Laney> but what's wrong with ubuntu that it doesn't look like https://ci.debian.net/packages/g/golang-github-coreos-gexpect/unstable/amd64/ ?
[11:01] <Laney> can you file a merge request to the hints?
[11:03] <LocutusOfBorg> probably it regressed with default golang-any pointing to 16
[11:03] <LocutusOfBorg> looks like some sort of timeouts
[11:03] <LocutusOfBorg> I think an hint reset might be good
[11:10] <LocutusOfBorg> https://code.launchpad.net/~costamagnagianfranco/britney/+git/hints-ubuntu/+merge/398965
[11:10] <LocutusOfBorg> does this sound good Laney ^^ ?
[11:11] <LocutusOfBorg> this makes etcd migrate and fixes patroni autopkgtests "forever"
[11:11] <LocutusOfBorg> and with macsyfinder fixed sphinx migrates too
[11:12] <LocutusOfBorg> thanks juliank for looking at it
[11:12] <juliank> We still need the force-badtest merged I think
[11:20] <Laney> what force-badtest?
[11:20] <Laney> you people are confusing
[11:20] <LocutusOfBorg> I did force-test-reset
[11:21] <LocutusOfBorg> not sure what force-badtest is
[11:21] <LocutusOfBorg> my goal is to make etcd migrate and I need golang-github-coreos-gexpect stop complaining
[11:22] <Laney> fine, but I dunno what juliank is talking about (or why you invoked him)
[11:23] <Laney> ah I see for the latter, you were talking about mac thing
[11:23] <juliank> Laney: I pushed force-badtest/macsyfinder/!amd64 (expanded) to my branch, because I don't believe that the !amd64 tests will suddenly disappear once it's amd64 only in release
[11:23] <juliank> But I don't know for sure
[11:23] <Laney> I think they will
[11:24] <Laney> the required tests for a migration are essentially recomputed each time
[11:24] <juliank> ah
[11:24] <juliank> we'll see then :D
[11:51] <LocutusOfBorg> thanks lets see
[11:51] <LocutusOfBorg> I invoked him because his attempt makes sphinx migrate together with my hint
[11:53] <LocutusOfBorg> and also setuptools, python-packaging, macsyfinder, etcd, golang-github-creack-pty
[12:22] -queuebot:#ubuntu-release- New binary: linux-signed-oracle-5.4 [amd64] (bionic-proposed/main) [5.4.0-1039.42~18.04.1] (no packageset)
[12:23] -queuebot:#ubuntu-release- New binary: linux-signed-gkeop-5.4 [amd64] (bionic-proposed/main) [5.4.0-1011.12~18.04.2] (no packageset)
[12:24] -queuebot:#ubuntu-release- New binary: linux-signed-oem-5.10 [amd64] (focal-proposed/main) [5.10.0-1016.17] (no packageset)
[12:57] <lucasmoura> hello bdmurray, I just want to verify if there is any update on this Xenial unattended-upgrades SRU:
[12:57] <lucasmoura> https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1915547
[13:09] -queuebot:#ubuntu-release- New: accepted linux-signed-gkeop-5.4 [amd64] (bionic-proposed) [5.4.0-1011.12~18.04.2]
[13:09] -queuebot:#ubuntu-release- New: accepted linux-signed-oem-5.10 [amd64] (focal-proposed) [5.10.0-1016.17]
[13:09] -queuebot:#ubuntu-release- New: accepted linux-signed-oracle-5.4 [amd64] (bionic-proposed) [5.4.0-1039.42~18.04.1]
[13:42] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (hirsute-proposed/main) [5.8.0-1024.26+21.04.1] (core, kernel)
[13:42] -queuebot:#ubuntu-release- New binary: linux-signed-kvm [amd64] (groovy-proposed/main) [5.8.0-1020.22] (core)
[13:53] <LocutusOfBorg> Should wait for tests relating to macsyfinder 2.0~rc1-3, but forced by ubuntu-release
[13:53] <LocutusOfBorg> got it Laney ^^
[13:53] <LocutusOfBorg> so now retrying the tests will work?
[13:53] -queuebot:#ubuntu-release- New: accepted linux-signed-kvm [amd64] (groovy-proposed) [5.8.0-1020.22]
[14:58] <doko> xnox: debian-installer doesn't have any rdeps anymore. can we remove it, or is it still used in obscure places?
[15:00] <Laney> LocutusOfBorg: just wait for the next run, see if it clears off
[15:04] <LocutusOfBorg> ok
[17:04] <klebers> rbasak, hi! thanks for uploading the fixes for west-chamber-dkms. They are still in the unapproved queue though, should I ping someone else to approve it? (sorry, I'm still trying to figure out how the SRU process work :))
[17:08] <rbasak> klebers: it was blocked on https://bugs.launchpad.net/ubuntu/+source/xtables-addons/+bug/1915177/comments/9 but I see you responded to that just now
[17:08] <rbasak> I'll take a proper look in my SRU shift for you tomorrow if nobody gets to it today
[17:09] <klebers> rbasak, ok, that makes sense. thanks!
[17:14] <juliank> britney is soo slooow
[18:05] <xnox> doko:  do not remove debian-installer, it is an html placeholder page only which directs users where to find the installer.
[18:06] <xnox> doko:  thank you!
[18:24] -queuebot:#ubuntu-release- New binary: freedict [amd64] (hirsute-proposed/universe) [2021.01.05-2ubuntu1] (no packageset)
[18:26] -queuebot:#ubuntu-release- New: accepted freedict [amd64] (hirsute-proposed) [2021.01.05-2ubuntu1]
[18:27] -queuebot:#ubuntu-release- New: accepted git-filter-repo [sync] (hirsute-proposed) [2.29.0-1]
[18:30] -queuebot:#ubuntu-release- New binary: git-filter-repo [amd64] (hirsute-proposed/none) [2.29.0-1] (no packageset)
[18:32] -queuebot:#ubuntu-release- New: accepted git-filter-repo [amd64] (hirsute-proposed) [2.29.0-1]
[19:08] -queuebot:#ubuntu-release- New sync: grub2-unsigned (xenial-proposed/primary) [2.04-1ubuntu42]
[19:09] -queuebot:#ubuntu-release- New: accepted grub2-unsigned [sync] (xenial-proposed) [2.04-1ubuntu42]
[20:16] <doko> vorlon: please can you ignore the autopkgtest failure for android-sdk-meta/i386? not built anymore
[20:29] -queuebot:#ubuntu-release- Unapproved: linux-firmware (focal-proposed/main) [1.187.9 => 1.187.10] (core, kernel)
[20:37] <vorlon> doko: done
[20:41] -queuebot:#ubuntu-release- Unapproved: linux-firmware (bionic-proposed/main) [1.173.19 => 1.173.20] (core, kernel)
[21:13] <vorlon> KeyError: 'autopkg_fails'
[21:14] <vorlon> that's a new error from sru report generation
[21:42] -queuebot:#ubuntu-release- Packageset: Removed boost1.74 from i386-whitelist in focal
[21:43] -queuebot:#ubuntu-release- Packageset: Removed libpadwalker-perl from i386-whitelist in focal
[21:43] -queuebot:#ubuntu-release- Packageset: Removed llvm-toolchain-11 from i386-whitelist in focal
[21:43] -queuebot:#ubuntu-release- Packageset: Removed postgresql-13 from i386-whitelist in focal
[21:43] -queuebot:#ubuntu-release- Packageset: Removed python3.10 from i386-whitelist in focal
[21:43] -queuebot:#ubuntu-release- Packageset: Removed boost1.74 from i386-whitelist in groovy
[21:43] -queuebot:#ubuntu-release- Packageset: Removed libpadwalker-perl from i386-whitelist in groovy
[21:43] -queuebot:#ubuntu-release- Packageset: Removed postgresql-13 from i386-whitelist in groovy
[21:43] -queuebot:#ubuntu-release- Packageset: Removed python3.10 from i386-whitelist in groovy
[21:43] -queuebot:#ubuntu-release- Packageset: Removed dpatch from i386-whitelist in hirsute
[21:43] -queuebot:#ubuntu-release- Packageset: Removed gnome-icon-theme from i386-whitelist in hirsute
[21:43] -queuebot:#ubuntu-release- Packageset: Removed libprelude from i386-whitelist in hirsute
[21:43] -queuebot:#ubuntu-release- Packageset: Removed lowdown from i386-whitelist in hirsute
[21:43] -queuebot:#ubuntu-release- Packageset: Removed qtnetworkauth-everywhere-src from i386-whitelist in hirsute
[21:43] -queuebot:#ubuntu-release- Packageset: Removed readline5 from i386-whitelist in hirsute
[21:43] -queuebot:#ubuntu-release- Packageset: Removed xcftools from i386-whitelist in hirsute
[21:43] -queuebot:#ubuntu-release- Packageset: Added egl-wayland to i386-whitelist in focal
[21:43] -queuebot:#ubuntu-release- Packageset: Added gcc-11 to i386-whitelist in focal
[21:43] -queuebot:#ubuntu-release- Packageset: Added gcc-11-cross to i386-whitelist in focal
[21:43] -queuebot:#ubuntu-release- Packageset: Added gcc-11-cross-ports to i386-whitelist in focal
[21:43] -queuebot:#ubuntu-release- Packageset: Added gcc-8 to i386-whitelist in focal
[21:43] -queuebot:#ubuntu-release- Packageset: Added libdeflate to i386-whitelist in focal
[21:43] -queuebot:#ubuntu-release- Packageset: Added libffi7 to i386-whitelist in focal
[21:43] -queuebot:#ubuntu-release- Packageset: Added libmd to i386-whitelist in focal
[21:43] -queuebot:#ubuntu-release- Packageset: Added llvm-toolchain-12 to i386-whitelist in focal
[21:43] -queuebot:#ubuntu-release- Packageset: Added lowdown to i386-whitelist in focal
[21:43] -queuebot:#ubuntu-release- Packageset: Added nvidia-graphics-drivers-460-server to i386-whitelist in focal
[21:43] -queuebot:#ubuntu-release- Packageset: Added openjdk-17 to i386-whitelist in focal
[21:43] -queuebot:#ubuntu-release- Packageset: Added egl-wayland to i386-whitelist in groovy
[21:43] -queuebot:#ubuntu-release- Packageset: Added gcc-11 to i386-whitelist in groovy
[21:43] -queuebot:#ubuntu-release- Packageset: Added gcc-11-cross to i386-whitelist in groovy
[21:43] -queuebot:#ubuntu-release- Packageset: Added gcc-11-cross-ports to i386-whitelist in groovy
[21:43] -queuebot:#ubuntu-release- Packageset: Added gcc-8 to i386-whitelist in groovy
[21:43] -queuebot:#ubuntu-release- Packageset: Added libdeflate to i386-whitelist in groovy
[21:43] -queuebot:#ubuntu-release- Packageset: Added libffi7 to i386-whitelist in groovy
[21:43] -queuebot:#ubuntu-release- Packageset: Added libmd to i386-whitelist in groovy
[21:43] -queuebot:#ubuntu-release- Packageset: Added llvm-toolchain-12 to i386-whitelist in groovy
[21:43] -queuebot:#ubuntu-release- Packageset: Added lowdown to i386-whitelist in groovy
[21:43] -queuebot:#ubuntu-release- Packageset: Added nvidia-graphics-drivers-460-server to i386-whitelist in groovy
[21:43] -queuebot:#ubuntu-release- Packageset: Added openjdk-17 to i386-whitelist in groovy
[22:16] <vorlon> there are an awful lot of packages still in hirsute that build-depend on dh-systemd which is NBS; is anyone working on this?  Are these all Ubuntu-specific?
[22:29] <LocutusOfBorg> vorlon, not all of them I think
[22:29] <LocutusOfBorg> I looked at them some days ago
[22:29] <LocutusOfBorg> reverse-depends -r sid -b dh-systemd
[22:29] <LocutusOfBorg> 11 comes from debian too
[22:30] <LocutusOfBorg> but probably the debian ones are all out from testing
[22:32] <vorlon> and some of the debian ones seem to be alternative deps
[22:32] <vorlon> (apt-cacher-ng)
[22:38] -queuebot:#ubuntu-release- Unapproved: gnutls28 (focal-proposed/main) [3.6.13-2ubuntu1.4 => 3.6.13-2ubuntu1.5] (core, i386-whitelist)
[22:43] -queuebot:#ubuntu-release- Unapproved: gnutls28 (focal-proposed/main) [3.6.13-2ubuntu1.4 => 3.6.13-2ubuntu1.5] (core, i386-whitelist)
[22:52] -queuebot:#ubuntu-release- Unapproved: rejected gnutls28 [source] (focal-proposed) [3.6.13-2ubuntu1.5]
[22:59] <vorlon> juliank, xnox: ^^ fyi please make grub2 build-depend on debhelper (>= 9.20160709) | dh-systemd, so that build-deps are satisfied back as far as xenial and also we can drop dh-systemd from hirsute
[23:02] <vorlon> rbalint, smb: hmm, does one of you want to merge kerneloops? :)
[23:34] -queuebot:#ubuntu-release- Unapproved: rejected neutron [source] (groovy-proposed) [2:17.1.0-0ubuntu1]
[23:42] -queuebot:#ubuntu-release- Unapproved: accepted west-chamber [source] (groovy-proposed) [20100405+svn20111107.r124-12ubuntu0.2]
[23:51] -queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (groovy-proposed) [3.38.3-2ubuntu<IP_ADDRESS>]
[23:55] -queuebot:#ubuntu-release- Unapproved: zfs-linux (groovy-proposed/main) [0.8.4-1ubuntu11.1 => 0.8.4-1ubuntu11.2] (core, kernel-dkms)
[23:56] -queuebot:#ubuntu-release- Unapproved: zfs-linux (bionic-proposed/main) [0.7.5-1ubuntu16.10 => 0.7.5-1ubuntu16.11] (core, kernel-dkms)
[23:56] -queuebot:#ubuntu-release- Unapproved: zfs-linux (focal-proposed/main) [0.8.3-1ubuntu12.6 => 0.8.3-1ubuntu12.7] (core, kernel-dkms)
[23:57] -queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [<IP_ADDRESS>-0ubuntu28 => <IP_ADDRESS>-0ubuntu29] (kernel-dkms)


[01:10] <daftykins> lol i took a wiki thing to #fedora
[01:10] <daftykins> "yeah that's been wrong for years..."
[01:10] <daftykins> neat
[01:10] <daftykins> pretty much being on exactly the other side of the fence from my time in #ubuntu ...
[03:39] <daftykins> diddledan: http://i.imgur.com/2EWEwUe.gif
[05:59] <mapps> helloL:D morning
[09:13] <brobostigon> morning boys and girls
[10:20] <popey> pip pip
[10:51] <brobostigon> meep meep
[11:23] <zmoylan-pi> *pew* *pew*
[11:29] <SebthreeBQM10HD> hi woo
[11:29] <SebthreeBQM10HD> just read it :)
[11:29] <SebthreeBQM10HD> about time as well, Fedora 25 going Wayland by default
[11:45] <popey> believe it when I see it
[11:47] <ali1234> wayland by default as long as you don't use amd or nvidia?
[11:47] <ali1234> or certain intel chipsets
[11:48] <ali1234> or a DE that isn't gnome
[11:48] <ali1234> or a login manager that isn't gdm
[11:48] <zmoylan-pi> or a computer that uses 0's AND 1's... :-)
[11:49] <ali1234> and no mir doesn't work any better
[11:49] <zmoylan-pi> x all the way down...
[11:54] <penguin42> hmm does look like this Virgin media upgrade worked; apt showing 7345kB/s
[11:56] <SebthreeBQM10HD> popey, ali1234  zmoylan-pi  I think it's really going to happen with Fedora 25 goig by wht I read, as long as htey got certin bugs etc documented or whatever it said, plus thre's a way to get xorg still if wanting it as well
[11:57] <SebthreeBQM10HD> now I could have otherwise copied in a link, but that doesn't work with Ubuntu touch devices yet!
[12:05]  * penguin42 is trying to train himself to type apt instead of apt-get - it's hard work
[12:08] <penguin42> especially while I'm waiting for the paracetamol to fully kick in and make this cold bearable
[12:15] <popey> yeah, i still use apt-get sometimes
[12:16] <popey> also often use apt-cache search rather than apt search
[12:16] <popey> muscle memory is powerful
[12:19] <penguin42> (and don't get me started on dnf - I always just type yum)
[14:01] <diddledan> penguin42: yummy!
[14:01] <diddledan> oh, major late to the party on my part there
[14:03] <penguin42> :-)
[19:11] <daftykins> penguin42: haha it's just symlinked though ;) but i was thinking about this earlier, it's easy for me to adapt since i'm new to it - but on ubuntu i still run apt dist-upgrade even though it's apt full-upgrade now (from what i gather)
[19:14] <penguin42> daftykins: Is it? Oh I didn't know about full-upgrade
[19:15] <daftykins> that's because of the newer 'apt' instead of 'apt-get' of course
[19:15] <daftykins> at least i assume it's something newer being worked on, that's where my limitations come in - i have no idea how to find things out
[19:16] <penguin42> daftykins: Why I wait for messages from people like you to tell me about things
[19:17] <daftykins> XD
[19:21] <daftykins> hmm i thought edx.org had some other interesting Linux courses but it seems to have gone
[22:30] <blint> hello?
[22:30] <popey> hi
[22:31] <blint> oh hi :
[22:31] <blint> i thought my net was off
[22:32] <daftykins> seems not
[22:32] <popey> !ping
[22:50]  * zmoylan-pi scribbles ping times on a post-it and fecks it through blint's window... :-P