[02:02] <Unit193> LocutusOfBorg: Thanks.
[06:11] <LocutusOfBorg> yw
[20:01] <EleanorEllis> Why are the download links for ubuntu and all the other flavours http, rather than https? I know you provide additional information to verify the downloads but not everybody who downloads ubuntu would know to look for that information. I understand that https is probably not enough on it's own, but it would be a step in the right direction and would give users more confidence. The current situation also means that users of th
[20:01] <EleanorEllis> results" can't connect to the downloads.
[20:02] <tgm4883> EleanorEllis: https would be up to the cd mirror provider I would think, some of which do provide https links
[20:03] <EleanorEllis> tgm4883: But the main one, http://cdimage.ubuntu.com is not https
[20:05] <tgm4883> EleanorEllis: TBF, the main one would be https://www.ubuntu.com/download but I see what you mean
[20:05] <EleanorEllis> tgm4883: I imagine some users ,ogj
[20:06] <EleanorEllis> might think they were safe, simply because the iso they receive has been verified by their bittorrent client, but they would be incorrect since there is no secure way, even to download the torrent file
[20:09] <tgm4883> HTTPS shouldn't be used as confidence that you're getting the correct ISO, however you're correct that there doesn't seem to be an HTTPS way to get either the SHA or bittorrent files
[20:11] <EleanorEllis> tgm4883: I realise that, but surely we ought to provide this basic minimum, especially to inexperienced users
[20:13] <tgm4883> EleanorEllis: for cdimages.u.c and releases.u.c yes, but I supposed it can give a false sense of confidence for any of the mirrors. I'll defer to someone else that can control the websites, I tried finding where bug reports are for those sites but neither are listed on https://github.com/canonical-websites
[20:14] <maswan> we provide https for almost all vhosts for our releases mirror, except the se.releases.u.c name
[20:14] <maswan> due to u.c policy
[20:14] <maswan> but then, there is no hard vetting on mirrors other than volunteers that seem to be serving the right content most of the time
[20:15] <tgm4883> maswan: what about releases.ubuntu.com and cdimage.ubuntu.com ?
[20:15] <tgm4883> neither appear to work with https
[20:16] <tgm4883> Both of which I think are the main concern, since both the torrents and sha sums are found there
[20:24] <Unit193> maswan: If you get the hashes from the main host, but the iso from the mirror you should be pretty set.  Using gpg to verify the hashes is another layer.
[20:25] <EleanorEllis> maswan: tgm4883: I am just looking for the SHA files for Ubuntu Budgie and going about it how a new user might do it. There is nothing in the installation guide about verifying the download, it just goes straight into making a bootable medium. https://ubuntubudgie.org/downloads
[20:25] <maswan> yeah, tbh, I'd like to see a rework of cdimage.u.c
[20:26] <Unit193> Currently, the only way I see to download the hashes over a TLS connection is using the wiki, which "anyone" can edit.
[20:26] <maswan> but I guess it is only live daily builds these days, so it's pretty much mirrorable these days
[20:26] <cjwatson> actually that page is locked much more than usual wiki pages, though I agree it's past time for cdimage to be https really
[20:27] <cjwatson> (of course it's easy for me to agree since I don't really work on it any more ...)
[20:27] <maswan> yeah, even our computer club could cough up the new cpus to handle https, 55xx -> 56xx series. :)
[20:27] <maswan> I think they cost 3 or 5 eur each
[20:29] <maswan> I've always hesitated to do a full mirror of it due to directories named -daily with a few gigs of isos, but if it is just one a blacklist (or just suck it up and mirror it anyway) is doable
[20:32] <maswan> a download page for all the other ubuntus that live on cdimage.u.c, on https, with a mirrorbits to redirect to cdimage.u.c or mirrors as appropriate would be neat though?
[20:34] <EleanorEllis> Should I raise this as a bug somewhere so it doesn't get forgotten about?
[20:54] <tomreyn> EleanorEllis: did you actually chek the link i posted (which explains in 5 steps how to verify the download in a cryptographically secure manner) when you asked this question in #ubuntu ?
 EleanorEllis: https://tutorials.ubuntu.com/tutorial/tutorial-how-to-verify-ubuntu#0
[20:54] <EleanorEllis> tomreyn: Yes I did, but someone else in #ubuntu asked me to raise this with ubuntu-devs
[20:55] <tomreyn> well, it's not a bug
[20:55] <tomreyn> a link to the above page is available at https://www.ubuntu.com/download/desktop/thank-you?country=DE&version=16.04.2&architecture=amd64 (the page you would start an LTS download from)
[20:56] <tomreyn> it's not obvious enough IMO, but it's not exactly wrong.
[20:56] <EleanorEllis> OK. I will rephrase the question. Since several people seem interested in this topic, should I ask this question on a web-page somewhere so that it doesn't get forgotten about? If so, where?
[20:56] <tomreyn> surely, https transfers would be a nice addition, but i agree one needs to prevent a false sense of security.
[20:57] <EleanorEllis> tomreyn: I think the main issue is that someone downloading ubuntu for the first time might be an inexperienced user, and naive about security, like I was and still am.
[20:58] <tomreyn> that's what this guide is for. but maybe that's still too complex?
[20:58] <tomreyn> you could raise your concerns in #canonical-sysadmin, i assume they'll be able to tell where this should be discussed further.
[20:59] <tomreyn> they also have a request tracker there (address on topic) but i'd check with them first (handler on duty is on topic as well)
[20:59] <tomreyn> ...not during the weeknd though
[21:00] <tomreyn> (and i'm not affiliated with canonical)
[21:00] <EleanorEllis> tomreyn: OK. Put yourself in the shoes of an inexperienced user and go to ubuntu.com and follow through the links to download and install. If you go for Ubuntu Budgie for example, there is no mention of verification on the Downloads page, and I only managed to find the SHA files by copying, pasting and editing one of the links on the download button
[21:04] <tomreyn> EleanorEllis: you mean downloading it from here? https://ubuntubudgie.org/downloads (i ended up there by searching "ubuntu budgie download" on google) - then i have to agree, information on how to access and verify the checksums and the gpg signature over that need to be added to the ubuntu budgie website.
[21:05] <tomreyn> this issue is not present for ubuntu proper IMO, or not as much. but then, too, i agree it would be good to make it as easy as possible for new users to verify authenticity of downloads.
[21:07] <EleanorEllis> tomreyn: Yes, that is the page. How is a new user not to know that Budgie is not ubuntu proper since it is linked from https://www.ubuntu.com/download/ubuntu-flavours
[21:07] <EleanorEllis> ?
[21:09] <tomreyn> EleanorEllis: by 'ubuntu proper' i mean ubuntu with unity, the primary ubuntu blend. but budgie is actually an official blend these days, IIRC.
[21:09] <tomreyn> so there's no need to know anything there.
[21:09] <tomreyn> (but the website wshould be improved)
[21:13] <EleanorEllis> tomreyn: So my point is that there is nothing there about verification, and if you follow the trail of webpages from a download link, it is not obvious that this needs to be done. On http://lubuntu.me/downloads/ for example there is a small note about verification but it is in very small type, much smaller than the download buttons. Surely it is worth making this stuff very clear indeed, or impossible to miss in the interest
[21:15] <tomreyn> EleanorEllis: what you wrote was probably cut off after "in the interest". with the rest, i agree.
[21:16] <EleanorEllis> in the interest of new users.
[21:16] <tomreyn> i do not know what's the best way to pass this on to the maintainers of these websites.
[21:17] <tomreyn> maybe if you join the blend specific channels you'll find out.
[21:18] <tomreyn> it's also someting you could discuss with the security team in #ubuntu-hardened to see whether they want to start a concerted effort to handle this.
[23:35] <mwhudson> whoa http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html#pytest looks super unhappy


[14:13] <gantrixx> I'm having trouble troubleshooting a mounting problem
[18:58] <iheartubuntu> i would lile to introduce maksim (makushimu) to the california team chat. he found us through the pasadena ubuntu hour. woohoo!
[18:58] <makushimu> Hello!
[18:59] <pleia2> welcome makushimu :)
[19:00] <makushimu> Thank you =)
[19:00] <iheartubuntu> had a great yard sale yesterday and gave out 10 ubuntu discs. i cant believe i slept 12 hours last night :) so tired
[19:02] <iheartubuntu> hi seidos how are you
[19:04] <iheartubuntu> i started up a linkedin acct. if anyone is interested in connecting there, i am at: http://www.linkedin.com/in/iheartubuntu
[19:05] <iheartubuntu> has anyone heard of fiverr.com ? you can find a ton of projects and services people will do for $5. some interesting things there :)
[19:26]  * pleia2 remembers to send out meeting reminders \o/
[19:26] <pleia2> some days are harder than others :)
[20:25] <bkerensa> =o
[21:11]  * grantbow waves from berkeleylug.com meeting
[21:13]  * seidos waves back
[21:14] <grantbow> jdeslip is here with 11 of our closest LUG friends.
[21:17] <seidos> word
[21:21] <iheartubuntu> sweet


[18:09] <stgraber> highvoltage: almost done implementing an unpack/repacker for the dnsRecord field in edubuntu-server, after that adding DNS management support should be quite easy
[18:10] <stgraber> (that dnsRecord struct is ridiculously complex and finding the MS documentation for it was a real pain...)


[15:27] <shadeslayer> wait
[15:27] <shadeslayer> why am I here
[15:28] <shadeslayer> 0.o
[15:28]  * genii slides shadeslayer a fresh coffee
[15:28] <shadeslayer> mmm coffee
[15:28] <genii> shadeslayer: Shouldn't you be in #kubuntu-devel instead? ;)
[15:28]  * shadeslayer ignores the doctors note about not taking too much caffeine
[15:28] <shadeslayer> genii: I've replaced myself with a machine :P
[15:29] <shadeslayer> Jenkins takes care of everything now
[15:29] <genii> Hah
[15:29] <shadeslayer> I just feed more code into Jenkins everytime I have to change packaging now :P
[15:29] <shadeslayer> anywho, shouldn't be idling here, lets continue in -devel :P
 Ubuntu customer support
[16:18] <bazhang> thats the same franceso_cevello from yesterday
[16:19] <Pici>  /70
[19:23] <tgm4883> genii: So it would appear that banning that user in #ubuntu made it so I can't send to channel :/
[19:23] <Unit193> genii: I think you missed on that banmask.
[19:23] <genii> @comment 69250 spambot triggering on !paste factoid
[19:23] <tgm4883> "genii banned *!*@* (+b)"
[19:23] <tgm4883> that seems like a lot
[19:23] <Unit193> Yep, that's everyone.
[19:24] <tgm4883> whoops
[19:24] <genii> wth?
[19:24]  * genii smacks Quassel
[19:26] <genii> Will the system actually enforCE A +B ON THAT?
[19:27] <tgm4883> genii: I guess so, I can't send to the channel currently (and nobody else is either)
[19:28]  * rww chuckles
[19:28] <rww> looks fixed now
[19:28] <tgm4883> thanks
[19:29] <phunyguy> quassel got me with that too a couple times.
[19:29] <rww> and this is why ops should have +r chanserv flags
[19:29] <disputin> can someone enlightenment on why I was banned from #ubuntu?
[19:30] <Unit193> rww: Should still be able to OP up still and remove it if you're in there though.
[19:30] <rww> Unit193: I wasn't :P
[19:30] <badbodh> so bot very ban much wildcard such typo
[19:30] <Unit193> disputin: Was a mistake by an OPs client, everyone was.
[19:30] <phunyguy> disputin: should be resolved.
[19:30] <disputin> ok, thanks
[19:30] <phunyguy> welcome.
[19:31] <badbodh> think of the children in africa who wanna join the channel for help. have some humanity!
[19:31] <badbodh> butterfly effect
[19:31] <rww> badbodh: anything else we can help you with today?
[19:31] <badbodh> nah just playing
[19:31] <badbodh> peace out
[20:21] <GPenguin> rww: since you have umode +g: i am glad you dont change either :)
[20:21] <GPenguin> always been an intriguing pussy
[20:21] <GPenguin> will always be
[20:21] <rww> oh, but see, i do. you're still insane, and i don't care
[20:21] <GPenguin> haha
[20:21] <GPenguin> i saw how much you care: <3
[20:22] <hggdh> ok. I have to confess I got lost on the dialog above :-)
[20:22] <rww> he's being stroppy because he was trolling in ##linux and i pointed out he's a known issue
[20:22] <rww> and he can't PM me, so he joined a channel he figured I'd be in
[20:22] <hggdh> oh. K, makes sense now
[20:23] <k1l_> he was a big desaster some years ago in the german ubuntu channels. and he already had a lot of issues with some freenode admins back then.
[22:32] <rww> dealt with ^
[22:33] <Unit193> Thanks, rww.


[09:06] -queuebot:#ubuntu-release- New: accepted gsequencer [amd64] (focal-proposed) [3.0.0~alpha3-1~build1]
[09:06] -queuebot:#ubuntu-release- New: accepted gsequencer [armhf] (focal-proposed) [3.0.0~alpha3-1~build1]
[09:06] -queuebot:#ubuntu-release- New: accepted gsequencer [s390x] (focal-proposed) [3.0.0~alpha3-1~build1]
[09:06] -queuebot:#ubuntu-release- New: accepted gsequencer [arm64] (focal-proposed) [3.0.0~alpha3-1~build1]
[09:06] -queuebot:#ubuntu-release- New: accepted python-gmusicapi [amd64] (focal-proposed) [12.1.1-1]
[09:06] -queuebot:#ubuntu-release- New: accepted gsequencer [ppc64el] (focal-proposed) [3.0.0~alpha3-1~build1]
[11:14] -queuebot:#ubuntu-release- New binary: volk [amd64] (focal-proposed/universe) [2.1.0-2] (no packageset)
[11:14] -queuebot:#ubuntu-release- New binary: volk [s390x] (focal-proposed/universe) [2.1.0-2] (no packageset)
[11:17] -queuebot:#ubuntu-release- New binary: volk [ppc64el] (focal-proposed/universe) [2.1.0-2] (no packageset)
[11:23] -queuebot:#ubuntu-release- New binary: volk [arm64] (focal-proposed/universe) [2.1.0-2] (no packageset)
[11:23] -queuebot:#ubuntu-release- New binary: volk [armhf] (focal-proposed/universe) [2.1.0-2] (no packageset)
[11:41] -queuebot:#ubuntu-release- New binary: uhd [s390x] (focal-proposed/universe) [<IP_ADDRESS>-2] (no packageset)
[11:48] -queuebot:#ubuntu-release- New binary: uhd [ppc64el] (focal-proposed/universe) [<IP_ADDRESS>-2] (no packageset)
[11:50] -queuebot:#ubuntu-release- New binary: uhd [amd64] (focal-proposed/universe) [<IP_ADDRESS>-2] (no packageset)
[11:55] <cjwatson> ginggs: Thanks for https://launchpad.net/ubuntu/+source/file/1:5.37-6ubuntu1 (we could have done it with a sync blacklist too, but this will do well enough).  I noticed it on #debian-ftp but you were apparently 40min ahead of me ...
[11:56] <ginggs> cjwatson: np
[12:13] -queuebot:#ubuntu-release- New: accepted uhd [amd64] (focal-proposed) [<IP_ADDRESS>-2]
[12:13] -queuebot:#ubuntu-release- New: accepted uhd [s390x] (focal-proposed) [<IP_ADDRESS>-2]
[12:13] -queuebot:#ubuntu-release- New: accepted volk [arm64] (focal-proposed) [2.1.0-2]
[12:13] -queuebot:#ubuntu-release- New: accepted volk [ppc64el] (focal-proposed) [2.1.0-2]
[12:13] -queuebot:#ubuntu-release- New: accepted uhd [ppc64el] (focal-proposed) [<IP_ADDRESS>-2]
[12:13] -queuebot:#ubuntu-release- New: accepted volk [armhf] (focal-proposed) [2.1.0-2]
[12:13] -queuebot:#ubuntu-release- New: accepted volk [amd64] (focal-proposed) [2.1.0-2]
[12:13] -queuebot:#ubuntu-release- New: accepted volk [s390x] (focal-proposed) [2.1.0-2]
[13:18] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [5.0.0-1028.29~18.04.1] (kernel)
[13:52] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [5.0.0-1028.29~18.04.1]
[15:33] -queuebot:#ubuntu-release- New source: kquickcharts (focal-proposed/primary) [5.65.0a-0ubuntu1]
[15:34] <RikMills> santa_: ^^
[17:23] <vorlon> doko: thanks for calling out the i386 dep-waits in the test rebuild email, I knew earlier versions of the germinate code had had bugs which resulted in overpruning of build-deps but I hadn't tracked down the fallout.  As I fix these in the main archive, how do you want these fixed for the rebuild test archive so that we can verify the failures have cleared?
[17:24] <vorlon> xnox: boost1.67, you're still going to give me that without the python-numpy build-dep on i386?
[17:26] <xnox> vorlon:  arr yeah
[17:52] -queuebot:#ubuntu-release- Packageset: Added uhttpmock to i386-whitelist in focal
[17:54] <doko> vorlon: these are dep-waits, so should be run automatically once fixed packages migrate to the release pocket
[17:54] <vorlon> doko: ok; that should happen in the next publisher run
[17:55] <vorlon> doko: anyway I sent you mail with some notes about this, and about the ones where I haven't fixed them up
[17:57] <vorlon> and this also takes care of two of the uninsts for i386, so here's hoping we're converging
[18:08] -queuebot:#ubuntu-release- Unapproved: python-oslo.policy (bionic-proposed/main) [1.33.1-0ubuntu1 => 1.33.1-0ubuntu2] (openstack, ubuntu-server)
[18:15] -queuebot:#ubuntu-release- Unapproved: sbuild-launchpad-chroot (disco-proposed/universe) [0.14 => 0.14ubuntu<IP_ADDRESS>] (no packageset)
[18:16] -queuebot:#ubuntu-release- Unapproved: sbuild-launchpad-chroot (bionic-proposed/universe) [0.14 => 0.14ubuntu<IP_ADDRESS>] (no packageset)
[18:23] -queuebot:#ubuntu-release- Unapproved: mutter (eoan-proposed/main) [3.34.1+git20191107-1ubuntu1~19.10.1 => 3.34.3-1ubuntu1~19.10.1] (desktop-core, desktop-extra)
[19:37] -queuebot:#ubuntu-release- Packageset: Added appstream-glib to i386-whitelist in focal
[19:37] -queuebot:#ubuntu-release- Packageset: Added glade to i386-whitelist in focal
[19:37] -queuebot:#ubuntu-release- Packageset: Added gnome-icon-theme to i386-whitelist in focal
[19:37] -queuebot:#ubuntu-release- Packageset: Added libdbd-sqlite3-perl to i386-whitelist in focal
[19:37] -queuebot:#ubuntu-release- Packageset: Added libdmx to i386-whitelist in focal
[19:37] -queuebot:#ubuntu-release- Packageset: Added lua5.1 to i386-whitelist in focal
[19:37] -queuebot:#ubuntu-release- Packageset: Added tclap to i386-whitelist in focal
[19:37] -queuebot:#ubuntu-release- Packageset: Added uthash to i386-whitelist in focal
[19:37] -queuebot:#ubuntu-release- Packageset: Added yelp-tools to i386-whitelist in focal
[19:37] -queuebot:#ubuntu-release- Packageset: Added yelp-xsl to i386-whitelist in focal
[21:31] <vorlon> doko: if you were to regenerate it, https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191220-focal-focal.html#i386-whitelist should look nicer now
[21:37] -queuebot:#ubuntu-release- Packageset: Added libdbi-perl to i386-whitelist in focal
[21:37] -queuebot:#ubuntu-release- Packageset: Added snowball to i386-whitelist in focal
[22:20] <bdmurray> vorlon, infinity: could something be missing in the fix for bug 1845529? I've been unable to verify the fix.
[22:31] <vorlon> bdmurray: huh I had been trying to remember because I knew I had touched this bug over the holiday; apparently I have the mount from -proposed installed as part of doing the verification
[22:32] <vorlon> bdmurray: did you install Ubuntu MATE 19.10 as indicated in the test case?
[23:24] <bdmurray> vorlon: No, I used an Ubuntu Desktop install and the test case failed w/ the previous version of util-linux.
[23:41] <vorlon> bdmurray: right; MATE was specified to sidestep the question of whether gawk was installed or not
[23:45] <bdmurray> vorlon: well gawk wasn't installed
[23:45] <vorlon> hmm ok
[23:45] <vorlon> bdmurray: I was able to reproduce the problem and verify the fix here
[23:59] <bdmurray> vorlon: hmm, /usr/share/bash-completion/completions/umount wasn't updated fwiw


[11:57] <Saviq> wiki.u.c down?
[23:24] <MikeRL> Bad news. Black screen literally every other boot. I can't even CTRL+ALT+Function to a virtual terminal when this happens.
[23:25] <MikeRL> What I'm asking is are there any logs that may help when I cannot even get Ubuntu to boot half the time? Only happens on my laptop.
[23:26] <TheMuso> MikeRL: Xorg logs perhaps?
[23:27] <MikeRL> TheMuso: Thanks. Would you mind helping me look at the?
[23:27] <MikeRL> TheMuso: *them.
[23:29] <TheMuso> I am no xorg expert sorry.
[23:30] <TheMuso> I am no xorg expert sorry, you might want to ask in #ubuntu-x./t #ubuntu-x
[23:30] <MikeRL> Any other logs that might be worth looking at?
[23:30] <TheMuso> gah
[23:30] <MikeRL> Like what?
[23:30] <MikeRL> I can look at them myself, too. And wait for other to help.
[23:30] <TheMuso> I mucked up that last line. Added a command at the end of the text I wrote, which was meant to be on its own line.
[23:32] <MikeRL> So, what are the channels?
[23:32] <MikeRL> Ubuntu-X or what?
[23:33] <MikeRL> I don't see an #ubuntu-x...
[23:33] <MikeRL> All I see is a Mir channel.
[23:36] <MikeRL> Well, according to the Ubuntu Wiki, it exists.
[23:36] <MikeRL> So I'll try /j #ubuntu-x


[18:18] <flocculant> cyphermox: am I right in assuming that ubiquity " Redesign the prepare screen for less clutter." is lose the internet warning and the disk size warning? note - I saw the disk size warning when it was too small :)
[19:08] <slangasek> unblocked getting the new phpunit unstuck from -proposed, so it's now compatible with php7; there may be various test failures in update_excuses that now want retried
[20:35] <flexiondotorg_> Is infinity about yet?
[20:35] <flexiondotorg_> He definitely said I should annoy him ;-)
[20:43] <infinity> flexiondotorg_: I forget what you were annoying me about.  Minimal cdimage merges for xu/mate?
[20:44] <Ukikie> ...Alive on a weekend? :3
[20:44] <flexiondotorg_> infinity, Yes please :-)
[20:45] <flexiondotorg_> infinity, Would be good for testing in Beta 1.
[20:46] <flexiondotorg_> https://code.launchpad.net/~ubuntu-mate-dev/debian-cd/ubuntu-mate-base/+merge/284435
[20:46] <flexiondotorg_> https://code.launchpad.net/~ubuntu-mate-dev/livecd-rootfs/ubuntu-mate-base/+merge/284432
[20:46] <flexiondotorg_> https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-cdimage/ubuntu-mate-base/+merge/284433
[23:25] <doko> so gnutls is coupled with bind9 and linux; removed netexpect, trying to get filezilla done


[02:36] <bjsnider> if i send a control file with multiarch in it to lucid/mav/natty ppa will the build system reject it?
[02:36] <bjsnider> or ignore it?
[03:02] <Prf_Jakob> bryce, Sarvatt, RAOF: Branch made
[08:03] <RAOF> Prf_Jakob: Sweet!
[09:13] <RAOF> Sarvatt: Hey dude.  Is there a nice package of the new dri2 protocol anywhere?
[09:13] <RAOF> Sarvatt: Oh, presumably it's in edgers.  Sorry :)
[09:15] <Sarvatt> RAOF: what exactly are you looking for?
[09:16] <Sarvatt> dri2proto is up to date in the distro
[09:16] <RAOF> I'm looking to build libxcb against the newer xcb-proto
[09:16] <Sarvatt> oh no havent done xcb-proto yet
[09:16] <RAOF> Oh, *I've* done xcb-proto.
[09:16] <RAOF> But it's failing to build, and I thought that would be the problem.  Maybe not.  Boo.
[09:17] <RAOF> (And by "done", I mean "have uupdated the package")
[09:17] <Sarvatt> so you probably need xcb-util updated
[09:17] <Sarvatt> oh nope
[09:18] <Sarvatt> how's it failing? is_switch failure?
[09:18] <RAOF> http://paste2.org/p/1863662
[09:21] <RAOF> Any ideas?
[09:21] <Sarvatt> nope haven't seen that one, going to grab it all and check it out
[09:21] <Sarvatt> thats building libxcb 1.8?
[09:22] <RAOF> That's building libxcb 1.7.
[09:22] <jcristau> with the new xcb-proto installed?
[09:23] <RAOF> With the new xcb-proto installed, yes.
[09:23] <RAOF> Is there tight coupling between libxcb and xcb-proto?
[09:24] <RAOF> Heh.  libxcb1.8 *does* die in is_switch :)
[09:25] <jcristau> new xcb-proto isn't supposed to break old libxcb afaik
[09:25] <jcristau> but, maybe it does...
[09:26] <RAOF> jcristau: Incidentally, why does xcb-proto declare a VCS-Git on freedesktop.org?  That's not where the packaging is.
[09:27] <jcristau> initially it was there
[09:28] <RAOF> Yeah; it's got the packaging for up to 1.1.
[09:29] <RAOF> It's no longer maintained in git?
[09:29] <RAOF> Bah.  I missed installing python-xcbgen.  Now it's breaking in my stuff :)
[09:31] <jcristau> should be in collab-maint
[09:31] <jcristau> i thought i'd fixed the vcs-* stuff
[09:32] <jcristau> apparently not.
[09:32] <RAOF> Unless the Ubuntu packages are behind, no :)
[09:32] <jcristau> ah, libxcb has updated vcs-*, xcb-proto not.
[09:32] <jcristau> fail
[09:33] <RAOF> :)
[09:34] <tjaalton> soo happy to see new xcb releases.. hope they fix the nasty threading issues that cause all sorts of crashes for some people
[09:34] <tjaalton> can't link the bug since lp will timeout..
[09:35] <Sarvatt> yeep AttributeError: 'Struct' object has no attribute 'is_switch', wish i could remember how we worked around that
[09:35]  * Sarvatt digs through old PPAs
[09:35] <RAOF> Sarvatt: I think the new python-xcbgen fixes that.
[09:35] <tjaalton> oh, bug 905686 is a newer one with less dupes
[09:35] <ubot4> Launchpad bug 905686 in nautilus (Ubuntu) (and 1 other project) "nautilus assert failure: nautilus: ../../src/xcb_io.c:528: _XAllocID: Assertion `ret != inval_id' failed. (affects: 19) (dups: 16) (heat: 140)" [Medium,Triaged] https://launchpad.net/bugs/905686
[09:36] <tjaalton> this was apparently fixed upstream over a year ago, but near impossible to backport
[09:36] <tjaalton> think i looked into that, could be wrong..
[09:36] <Sarvatt> oh helps if i install that deb
[09:37] <RAOF> :)
[09:38] <jcristau> tjaalton: this stuff is nasty, each fix breaks something else
[09:39] <tjaalton> jcristau: yeah, hoping it's sorted out by now..
[09:48] <jcristau> RAOF: so, http://anonscm.debian.org/gitweb/?p=collab-maint/xcb-proto.git and http://anonscm.debian.org/gitweb/?p=collab-maint/libxcb.git are where the packaging lives now, if you want to update that
[09:48] <RAOF> Why not!
[09:49] <Sarvatt> libxcb symbol updates are always fun
[09:49]  * RAOF has just passed -C0 for the moment.
[09:49] <jcristau> if you don't have write access to collab-maint you can push the update somewhere else and let me/kibi/jd_ know where we can pull from
[09:50] <RAOF> I think I've got collab-maint access.
[09:50] <tjaalton> and me
[09:58] <Sarvatt> http://sarvatt.com/downloads/patches/libxcb-1.8-symbols.patch thats what i've got so far on to build #9
[09:59] <RAOF> Yeah, well, I'm adding protocol so it's changing for me anyway.
[09:59] <RAOF> Clearly there are no pointer-barriers clients using XCB. :)
[10:34] <Sarvatt> phew finally http://sarvatt.com/downloads/patches/libxcb-1.8-symbols.patch
[10:39] <jcristau> are these sizeof things really meant to be exported?
[10:45] <tjaalton> also, what does one lose if the symbols file just had "*@Base 0\n*@Base 1.8"?
[10:45] <tjaalton> i've seen wildcards used like that
[10:45] <tjaalton> like nss & nspr
[10:47] <tjaalton> at least it would be much easier to maintain the file..
[10:50] <jcristau> that works if you version your symbols
[10:50] <jcristau> xcb doesn't do that
[10:51] <tjaalton> right, nss does
[10:51] <tjaalton> i'll get me coat :)
[11:15] <inetpro> hi
[11:15] <inetpro> has anyone had a chance to look at bug 897436 yet? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/897436
[11:15] <ubot4> Launchpad bug 897436 in xserver-xorg-video-nouveau (Ubuntu) "Screen corrupted without nomodeset on nVidia Corporation GT215 [GeForce GTS 360M] (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/897436
[11:15] <ubot4> inetpro: Error: Bug #897436 is private.
[11:16]  * inetpro wonders what that means
[11:17] <tjaalton> inetpro: just try with a newer kernel http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-precise/
[11:17] <inetpro> tjaalton: I'll try again asap, thanks
[11:18] <inetpro> but how do I know when to try?
[11:21] <tjaalton> hm?
[11:21] <tjaalton> nouveau is a kms-only driver, if it doesn't work you need to test a newer kernel
[11:21] <tjaalton> that's the first step before wasting time on anything else
[11:22] <tjaalton> now, I hope lp had a way to tell the bugreporter about that..
[11:22] <inetpro> how often is the kernel updated in the daily builds?
[11:23] <tjaalton> what daily builds?
[11:23] <tjaalton> you can test a daily livecd, yes
[11:23] <tjaalton> precise
[11:23] <inetpro> I mean the daily livecd
[11:23] <tjaalton> it has whatever kernel is the current one on the archive
[11:24] <tjaalton> so precise has 3.2, while oneiric had 3.0
[11:24] <tjaalton> which means there's a chance it's fixed in precise..
[11:25] <inetpro> the last time I tried the daily livecd was on 2011-12-14 and there were no changes
[11:26] <tjaalton> oh, missed that part of the bug
[11:28] <tjaalton> ah, there's a kernel with drm-next
[11:28] <inetpro> when do I know whether it is worth testing a livecd again?
[11:28] <tjaalton> http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/current/
[11:28] <tjaalton> try that on oneiric
[11:29] <tjaalton> precise has what it will ship with, there won't be big changes to the kernel anymore
[11:29] <tjaalton> unless a fix ends up in 3.2.x
[11:29] <inetpro> hmm
[11:29] <tjaalton> but could be that you need to poke upstream devs about this..
[11:29] <inetpro> I got it working perfectly as it is on oneiric but I just want to make sure that things will work out of the box on the next release
[11:30] <tjaalton> right, so test that kernel to see if it's broken on current upstream code..
[11:30] <tjaalton> if it works with it, we can bisect the fix
[11:31] <inetpro> tjaalton: I'm not sure I get what you mean with test that kernel, how do I go about testing it
[11:31] <inetpro> ?
[11:31] <tjaalton> install it
[11:31] <tjaalton> ?
[11:32] <tjaalton> pick the image deb for your arch, dpkg -i $foo.deb
[11:33] <inetpro> tjaalton: I do this after installing the livecd with nomodeset?
[11:34] <tjaalton> inetpro: no, you have oneiric installed, right? just remove nvidia-current, install the deb and boot your machine...
[11:34] <tjaalton> well, whatever is easiest for you..
[11:36] <inetpro> ahh, I'll try that asap
[11:36] <Sarvatt> ricotz: anything "special" about wayland updates before i do a new one in edgers? mesa needs latest git wayland again
[11:37] <ricotz> Sarvatt, i think wayland should be fine
[11:38] <ricotz> weston/wayland-demos might make problem if there were further renames and movings
[11:38] <ricotz> Sarvatt, let me push wayland
[11:42] <ricotz> Sarvatt, uploaded
[12:04] <cnd> RAOF, bryce: new synaptics uploaded to x-staging and pushed to git branch ubuntu+1
[20:45] <tormod> is cnd's utouch-geis fix in a PPA somewhere? I am getting used to using gnome-terminal as "Launcher" but I miss evince!
[20:47] <tormod> I tried to  hand-apply and build myself, but building breaks in xcb dir. missing build dep?
[20:53] <tormod> Had to remove -Werror in configure.ac to get past some unused variable complaints. Now there's a libtool 2.4.2 vs 2.4.2ubuntu1 mismatch...
[20:59] <tormod> "rm aclocal.m4 configure; autoreconf -vi" helped. finally built.
[21:02] <tormod> (all this compiling while an eog was stuck on the CPU). Now with the geis patches, eog and evince segfault instead of looping.


[15:18] <Chex> heya cyphermox , how goes it
[15:32] <cyphermox> hey Chex. not bad, how about you?
[16:16] <Chex> cyphermox: pretty good


[01:01] <DanaG> Is xorg-edgers supposed to have a mismatch between core and evdev versions?
[01:01] <DanaG> s/supposed/known/
[02:24] <DanaG> ooh, you can suspend and resume now!  sweet!
[02:24] <DanaG> Mouse cursor disappears on resume, though.
[02:26] <DanaG> oops, meant that for #nouveau.
[08:49] <jneves> anyone else having problemas with 2.9.0-1ubuntu2~xup~1 in jaunty?
[08:50] <jneves> xserver-xorg-video-intel in x-updates
[08:52] <hyperair> what problems?
[08:58] <jneves> hyperair: failing to start X with a virtual of 2048x2048 claiming not enough memory from the video card
[08:58] <jneves> hyperair: and when I remove the virtual, it seems to start gdm somewhere else - I hear the drums but the screen is all black
[09:00] <jneves> hyperair: Mobile 915GM/GMS/910GML Express Graphics Controller in a Dell Latitude D610
[09:01] <hyperair> hmm O_o
[09:01] <hyperair> strange
[09:01] <hyperair> never heard of a problem like that
[09:01]  * hyperair uses 965
[09:01]  * hyperair uses xorg-edgers
[09:05] <jneves> hyperair: it was the latest build on x-updates
[09:05] <jneves> hyperair: the black screen is a regression
[09:05] <hyperair> well poke sarvatt.
[09:06] <hyperair> when he's around, that is
[09:06] <hyperair> i think he's the one who uploads these
[09:06]  * hyperair has nothing to do with X or its drivers
[09:06] <jneves> hyperair: I've gone back to the distribution ones - they just stop playing video at virtual widths over 2048
[09:06] <jneves> hyperair: Tormod Volden
[09:07] <jneves> according to launchpad
[09:07] <hyperair> i see
[09:07] <jneves> hyperair: thanks
[09:08] <hyperair> hmm come to think of it i haven't seen/heard from sarvatt for some time.
[09:08] <hyperair> what happened to him i wonder?
[09:19] <jneves> hyperair: sorry, just a user here - can't help you with that
[09:20] <hyperair> heh
[09:20] <hyperair> i was just wondering aloud
[09:22] <jneves> :)
[14:55] <tormod> jneves, with 2.9.0-1ubuntu2~xup~1 you were probably running the vesa driver, try ~xup~3
[15:05] <jneves> tormod: ok, will try later - project delivery at the moment - thanks - will give you feedback as soon as I have it
[16:20] <tormod> hi albert23, thanks for following up those intel/x-updates/xorg-edgers issues
[16:20] <tormod> I think I have sorted them all out now
[16:22] <albert23> tormod: no problem
[19:45] <tormod> what is the preferred way to create a minimal xorg.conf?
[19:46] <tormod> or, if it only contains a Device section, will it be used?
[19:47] <jcristau> yes
[19:47] <tormod> jcristau, thanks
[19:50] <tormod> do you know if it is still true that "The  Identifier and Driver entries are required in all Device sections." ?
[19:50] <jcristau> it is
[19:50] <Duke`> you just want to put options in the device section?
[19:51] <Duke`> don't you need also a Screen and a ServerLayout sections?
[19:51] <Duke`> for a minimal xorg.conf
[19:52] <jcristau> no
[22:29] <tormod> jcristau, is there a package with xcb-dri2?
[22:30] <jcristau> no
[22:31] <tormod> intel trunk wants it for building xvmc
[22:31] <jcristau> it's only in xcb-proto and libxcb master
[22:31] <tormod> thanks
[22:33] <tormod> since 5 hours ago... :)
[22:34] <tormod> (sigh) it's getting harder and harder to track intel development...
[22:35] <jcristau> bah.  who needs xvmc anyway
[22:35] <tormod> I don't know, is there no big deal to drop it?
[22:36] <jcristau> dropping it temporarily until the xcb part is released is fine imo
[22:38] <tormod> thanks, I'll do that. just was worrying about the uproar from xvmc fans
[22:39] <bryce__> tormod, as long as xvmc works in the distro itself I would think they'd be ok
[22:40] <bryce__> tormod, and there's plenty of time before we would think about pulling new intel bits into the distro (bug would be worth tracking tho)
[22:46] <tormod> ok, pushed xvmc-free -intel to xorg-edgers :)
[22:50] <jcristau> what server does edgers have?
[22:50] <tormod> 2:<IP_ADDRESS>1+git20091005
[22:51] <jcristau> no 1.7 yet then?
[22:53] <tormod> sarvatt was looking at it in his xorg-testing ppa but he hasn't updated it for quite some time
[22:53] <tormod> we were talking about following trunk instead, but wait for Lucid Lynx
[22:54] <jcristau> i should get a ppa with my udev branch in it :)
[22:58] <tormod> that's a branch of xserver 1.7?
[22:58] <tormod> oh http://cgit.freedesktop.org/~jcristau/xserver/log/?h=libudev I guess
[23:05] <jcristau> yeah


[05:33] <fabbione> doko: i get the same error on gcc/pcc with  WITHOUT_LANG=biarch debuild -uc -us -b
[07:11] <doko> fabbione: don't have a G4 to check ...
[07:11] <fabbione> doko: ok.
[07:20] <fabbione> doko: i am about to start the rebootstrap on sparc. do you want to receive the build logs or not?
[08:03] <doko> fabbione: just the failed ones please
[08:13] <fabbione> doko: i can't filter from here
[08:14] <fabbione> i will need to forward it manually
[08:28] <doko> fabbione: we should get these filter scripts from lucas (the guy who did make the cluster build)
[08:30] <fabbione> doko: sbuild doesn't filter.. it just sends
[08:32] <infinity> It's trivial to filter is with procmail.
[08:32] <infinity> Given the uniform subject lines.
[12:42] <Keybuk> do we have a toolchain for feisty yet?
[12:42] <fabbione> no
[12:43] <fabbione> it should be by the end of the week
[12:45] <infinity> We have several, and some of them almost work, we don't have one in the archive yet.
[02:24] <jbailey> doko: g'day!
[02:24] <doko> jbailey: good morning!
[02:24] <jbailey> doko: I put the binutils stuff in bzr based on the current packaging.  One patch merged upstream (i386/amd64 biarch).
[02:24] <jbailey> Build of glibc shows no regressions.
[02:25] <jbailey> (ppc)
[02:25] <jbailey> and ppc64.
[02:25] <jbailey> I have the .orig.tar.gz in my homedir on chinstrap if you're interested.
[02:25] <jbailey> glibc correctly detects the hashing stuff and enables it.
[02:25] <doko> jbailey: ok, will have a look
[02:41] <fabbione> jbailey: hashing is detected fine on sparc too
[02:42] <jbailey> fabbione: Luvly.
[02:43] <jbailey> I have a feeling i'mgoing to need to dust off my G4 for some build tests.
[02:43] <jbailey> the ppc64 glibc has no significant errors.
[02:43] <jbailey> the ppc32 one does.  I suspect it's all compat bugs, though.
[02:43] <jbailey> I still want to look over the i486 one.
[02:43] <jbailey> i686 and amd64 looked fine.
[02:44] <jbailey> I'd be surprised if ia64 were anything other than fine, but I should build that too.
[02:44] <jbailey> fabbione: I haven't committed my patch stuff yet.
[02:44] <jbailey> I'll try to get it done by end of today, I think I was too aggressive in my pruning and want to review it again.
[02:45] <fabbione> jbailey: what patch? glibc or binutils?
[02:46] <jbailey> glibc.
[02:46] <jbailey> binutils is probably final subject to a review from doko.
[02:46] <fabbione> jbailey: this binutils can build hppa right?
[02:47] <jbailey> fabbione: Right.  glibc itself is missing a patch, but the binutils is fine.
[02:47] <fabbione> jbailey: ok. i am going trough a bootstrap sequence.. i will stop before glibc and wait for you
[02:47] <jbailey> fabbione: on hppa?
[02:48] <fabbione> yes
[02:48] <jbailey> I nudged adam a bit about the hppa kernel last night.  Dunno if he found time for it or not.
[02:48] <fabbione> i am building a kernel from git now. just to get the headers and get to binutils -> glibc -> gcc
[02:49] <fabbione> i am pretty sure the kernel does build
[02:49] <fabbione> but it might not run.. tough
 jbailey: binutils looks ok on sparc.. builded glibc on top and gcc on top of glibc... no errors up till now
 it would have fallen apart a while ago
[05:31] <jbailey>  anyway i am off for a bit
 up until now, like you just got an error, or like no errors so far? =)
 time to enjoy wife :)
[05:31] <jbailey> doko: ^^
[05:31] <jbailey> We were in -kernel, instead of -toolchain, sorry.
[05:31] <fabbione> he is in kernel too
[05:32] <jbailey> *lol*
[05:32] <fabbione> ok i am off now
[06:05] <fabbione> jbailey: libc6-dev in dapper Depends: linux-kernel-headers
[06:05] <fabbione> and linux-libc-dev doesn't provide it afaict
[06:06] <fabbione> so once we build hppa kernel, we can't build glibc
[06:06] <fabbione> i guess we will need to force that one in
[06:07] <fabbione> actually no
[06:08] <fabbione> binutils doesn't need new linux-libc-dev to build
[06:08] <fabbione> but glibc does..
[06:08] <fabbione> just postponing the issue..
[06:09] <doko> fabbione: did see it, nice.
[06:09] <fabbione> doko: gcc build seems to going fine now on sparc
[06:09] <fabbione> even on Niagara
[06:09] <fabbione> doko: once gcc is done i will rebuild glibc and open the gates for testing
[06:09] <fabbione> NOTE that i will not be using the rebuilt debs
[06:10] <fabbione> we are only going to test pkg foo built on edgy+feisty toolchain
[06:10] <fabbione> and not feisty rebuilt on feisty
[06:10] <fabbione> that will happen automatically while we import stuff
[06:10] <fabbione> jbailey: i need the glibc patch for hppa somewhere.. even offbandwith so i can test build and test
[06:11] <doko> fabbione, jbailey: for long double 64->128 change: we'll need to rebuild all packages (at least on powerpc and sparc) which uses long double to be safe; it's not that easy to detect thoese packages easily
[06:11] <fabbione> doko: well i will try to rebuild all of main BEFORE we open the gate
[06:11] <doko> not sure, if we want to open the gates for libraries and binary-indep stuff first, then for other packages
[06:11] <fabbione> do you expect just plain FTBFS or runtime errors?
[06:12] <fabbione> we can't really filter manually.. it would be hell of a work to let one package at a time in
[06:12] <doko> fabbione: runtime: libc and libstdc++ dohave support for both 64 and 128 bit long double, but other libraries don't have it.
[06:13] <fabbione> oh christ
[06:13] <fabbione> doko: we do have a local mirror on people.. what about a nice apt-get source $allofmain and a lot of grep magic?
[06:13] <fabbione> that would help me to prioritize pkgs that use that 128bit thingy
[06:13] <fabbione> and test them
[06:14] <doko> fabbione: you would have to unpack tarballs inside packages, scan for typedefs and defines, and probably still miss some
[06:15] <fabbione> doko: well that's doable..
[06:15] <fabbione> missing some can happen
[06:15] <fabbione> but we can still catch a few for testing-?=
[06:15] <doko> yes, probably
[06:17] <fabbione> doko: well want to start a script now so i can actually get to test by tomorrow or something?
[06:18] <doko> yes, probably write one tonight. but you can start testing as well
[06:18] <jbailey> doko: I think in general it would be nice to go through and look at any package that hasn't changed ina release and rebuilt it for good measure anyway.
[06:19] <fabbione> doko: i can't start testing without rebuilding first
[06:19] <fabbione> jbailey: statically i haven't see ONE release in which all packages in main have been the same
[06:19] <fabbione> only one _all.deb in one release IIRC
[10:48] <jbailey> doko: awake?