[18:41] <CrazyLemon> godbyk would you be so kind and build slovenian manual again? thanks
[22:33] <godbyk> CrazyLemon: http://builds.ubuntu-manual.org/builds/ubuntu-manual-sl.pdf ← updated PDF with the latest translations from Launchpad
[22:58] <CrazyLemon> godbyk thanks man!
[22:58] <godbyk> CrazyLemon: No problem! :)
[22:59] <CrazyLemon> this is probably our final build :)
[23:00] <godbyk> That's great!  Take your time and whenever you're finished editing, let me know and I'll start the publication process (assuming CreateSpace will let me! ;-)).
[23:01] <CrazyLemon> godbyk yea we'll recheck it once more then it'll be ready
[23:01] <godbyk> Cool
[23:02] <godbyk> I look forward to it!
[23:03] <CrazyLemon> godbyk hmm
[23:03] <CrazyLemon> there's a page missing
[23:03] <CrazyLemon> page 20.. page 19 has only a screenshot in it and page 20 is blank
[23:03] <CrazyLemon> is that how its supposed to be?
[23:03] <godbyk> If page 21 is the beginning of a chapter, then yes.
[23:03] <godbyk> Otherwise no. :)
[23:04] <CrazyLemon> it is yes :)
[23:04] <godbyk> When it's printed double-sided, the chapters always open on the right-hand-side page.
[23:04] <godbyk> So the left page will be blank sometimes.
[23:05] <CrazyLemon> godbyk there's a different issue on page 22
[23:05] <CrazyLemon> image 2.3 is a bit too low and the title of the image goes too low
[23:06] <CrazyLemon> should i gather notes and then send it at once instead of mentioning them one by one? :)
[23:07] <godbyk> Ah, yes. I'll fix any margin notes and images that are falling off the bottom of the page after you've finalzed the editing.
[23:07] <godbyk> It's probably easier to track them that way. You can email me a list if you like.
[23:12] <CrazyLemon> will do
[23:12] <CrazyLemon> thanks again and take care


[13:01] <doko> cyphermox, didrocks, cpaelzer, jamespage: MIR meeting?
[13:01] <jamespage> o/
[13:01] <jamespage> hello
[13:01] <joeubuntu> I'm joining for jdstrand doko.
[13:02] <didrocks> hey
[13:02] <cpaelzer> hiho
[13:03] <cpaelzer> jamespage: while we are here you might answer https://bugs.launchpad.net/ubuntu/+source/nfs-ganesha/+bug/1843403/comments/4 ?
[13:04] <jamespage> my plan was to work the identified work items very early next cycle and then submit for full review
[13:04] <cpaelzer> perfect
[13:04] <cpaelzer> I'll quote that into the bug - or will you add it there?
[13:04] <jamespage> I can add it
[13:04] <cpaelzer> ok
[13:04] <cpaelzer> while we wait for cyphermox I think we should get this started ...
[13:04] <cpaelzer> #startmeeting Weekly Main Inclusion Requests status
[13:04] <meetingology> Meeting started Tue Oct  8 13:04:59 2019 UTC.  The chair is cpaelzer. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[13:04] <meetingology> Available commands: action commands idea info link nick
[13:05] <cpaelzer> #topic Review of previous action items
[13:05] <cpaelzer> I wasn't here last week, any actions defined there?
[13:05] <cpaelzer> we didn't have any meeting actions the week before ...
[13:05] <doko> joeubuntu: added you to the calendar, and removed jdstrand
[13:05] <doko> https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[13:05] <doko> joeubuntu: any chance for the libheif review?
[13:06] <doko> I don't think so
[13:06] <joeubuntu> Sure, it 2nd in the queue right now doko
[13:06] <joeubuntu> Sorry, you mean to be pass. I am not sure. Seth it reviewing it.
[13:08] <cpaelzer> just after zsys :-)
[13:08] <cpaelzer> so didrocks can give heif a boost by passing zsys position int he queue :-)
[13:08] <didrocks> \o/
[13:09] <cpaelzer> doko: the good part is that both are above the "known to be needed for 19.10" line
[13:09] <cpaelzer> so Seth, joeubuntu and others are aware of the urgency I think
[13:10] <cpaelzer> joeubuntu: you might ask sarnold if there is any interim progres to report, if so he can share that on the bug
[13:10] <joeubuntu> libheif was moved out of the 19.10 queue by foundations, but then Brian asked that we add it back in last week, so we did.
[13:10] <cpaelzer> thanks
[13:10] <joeubuntu> cpaelzer will do
[13:10] <cpaelzer> going to new MIRs then
[13:10] <cpaelzer> #topic New MIRs
[13:10] <cpaelzer> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir
[13:11] <cpaelzer> the only one being https://bugs.launchpad.net/ubuntu/+source/nfs-ganesha/+bug/1843403
[13:11] <cpaelzer> jamespage: just confirmed that he will work on the known tasks beofre review
[13:11] <cpaelzer> so I'll mark this incomplete
[13:11] <cpaelzer> once known todos are done it can be set back to new to show up again
[13:11] <cpaelzer> doen, no others in this queue this week
[13:11] <cpaelzer> #topic Incomplete bugs / questions
[13:11] <cpaelzer> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.subscriber=ubuntu-mir
[13:12] <cpaelzer> didrocks: doko: libextutils-depends-perl and libextutils-pkgconfig-perl came in recently
[13:12] <cpaelzer> I have realized that was in main before
[13:13] <cpaelzer> so it would be a fast-pass case
[13:13] <cpaelzer> the uncertainty was about which Team would subscribe
[13:13] <cpaelzer> currently it seems none is
[13:13] <didrocks> yeah, seb128 and doko had some discussions on it
[13:13] <didrocks> but no conclusion it seems
[13:13] <cpaelzer> OTOH without knowing details I wonder how a pkgconfig kind of package can be a runtime dependency
[13:13] <doko> "discussions?"  I think it's escalated now to management
[13:14] <didrocks> doko: can you make sure they discuss this in the foundation/desktop sync?
[13:14] <didrocks> they already had one last week, but I didn't hear about the results
[13:14] <doko> didrocks: I asked for that before the last sync
[13:14] <didrocks> doko: if you need me to push on the desktop side for getting feedback as well, do not hesitate
[13:15] <didrocks> cpaelzer: yeah, same questionning on pkgconfig
[13:15] <cpaelzer> from changelog
[13:15] <cpaelzer>   9   * Reformat debian/control with "dh-make-perl --refresh".
[13:16] <cpaelzer> could that have been buggy and pulling it in by accident
[13:16] <cpaelzer> anyway it seems that needs sorting out between Desktop and Foundations
[13:16] <cpaelzer> given the short time before 19.10 I'd ask you all to keep bothering the people you need for this
[13:17] <cpaelzer> if one could prove the dependency isn't necesary this would resolve itslef :-)
[13:17] <cpaelzer> did you last week talk about https://bugs.launchpad.net/ubuntu/+source/abootimg/+bug/1846208 ?
[13:18] <cpaelzer> it was opened on 1st october not sure it was visible to you last week already
[13:18] <doko> no idea, the comments sound like bikeshedding
[13:18] <cpaelzer> It seems like it was opened incomplete, is this waiting on something?
[13:18] <cpaelzer> xnox: are you around to comment?
[13:19] <cpaelzer> The rest of the list looks fine to me
[13:20] <cpaelzer> xnox: can still chime in later here or on the bug - until then we handle the bug as it is flagged "incomplete->no-action"
[13:20] <cpaelzer> #topic Any other business?
[13:20] <cpaelzer> we all hav eseen the jdstrand joeubuntu sarnold change in responsibility
[13:20] <cpaelzer> nothing on top from server teams side
[13:20] <cpaelzer> anything else?
[13:22] <cpaelzer> I'll take this as a lonely no :-)
[13:22] <cpaelzer> #endmeeting
[13:22] <meetingology> Meeting ended Tue Oct  8 13:22:53 2019 UTC.
[13:22] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2019/ubuntu-meeting.2019-10-08-13.04.moin.txt
[13:23] <joeubuntu> bye all.
[13:23] <didrocks> doko: FYI, the between team sync didn't happen last week
[13:23] <didrocks> so, probably this one
[13:23] <didrocks> bye!
[13:23] <doko> bye
[16:03] <sarnold> l
[17:28] <xnox> ii
[17:31] <sarnold> :)


[00:52] <riz0n> Hello. I have an Ubuntu 12.04.1 server running, and I am getting cron emails daily /etc/cron.daily/spamassassin: http: GET http://sa-update.dnswl.org/1423347.tar.gz request failed: 500 Can't connect to sa-update.dnswl.org:80 (Bad hostname): Can't connect to sa-update.dnswl.org:80 (Bad hostname) LWP::Protocol::http::Socket: Bad hostname 'sa-update.dnswl.org' at /usr/share/perl5/LWP/Prot
[00:52] <riz0n> ocol/http.pm line 51.  What has happened, and what do I need to change to fix this? Thanks.
[00:53] <TheLordOfTime> sa-update.dnswl.org:80 (Bad hostname)  <--- is that a valid hostname?
[00:53] <riz0n> I would hope so, its part of Spam Assassin.
[00:53] <TheLordOfTime> i think your system's not resolving its hostname right
[00:54] <sarnold> can you ping it? or connect with wget, w3m, lynx, curl, etc?
[00:54] <TheLordOfTime> from your server, that is.
[00:54]  * TheLordOfTime confirmed its up from his system here
[00:54] <sarnold> me, I get NXDOMAIN. So. :)
[00:54] <riz0n> Yes I can ping it from the server.
[00:55] <riz0n> Trying to do wget now
[00:55] <ablyss> accidentally installed the debian package "javascript-common".  If your javascripts stop working all of a sudden, more than likely you installed this horrible, vile, inate idea of crap too.
[00:56] <riz0n> I was able to wget http://sa-update.dnswl.org/1423347.tar.gz from the server as well.
[01:00] <sarnold> try sticking the wget command you just used into a file in cron.hourly or something -- at the next hour, (darn, just missed the lsat one), you'll be able to see if running via cron influences the ability to do name lookups
[01:02] <riz0n> I'll give it a shot.
[04:58] <TaylorJohnson> Hi guys. I'm having trouble with oubount HTTP connections (apt-get/wget/etc) with my IPTABLES configuration. This is my configuration file: http://pastebin.com/LYwp5YHf Is there anything obvious that sticks out as being incorrect? DNS resolves perfectly fine and inbound originated HTTP works fine too.
[05:18] <lickalott> all, my server has been randomly going "offline".  3x in the last two days.  I've checked the syslog but didn't see anything that jumped out at me.   I rebooted it this morning and it was fine, at about 4:00 i was unable to reach it (across the network).  When I hit a button on the keyboard nothing happens (the monitor shows an empty black screen.  I hit the reset button on the case and
[05:18] <lickalott> it acts like it's going to reboot but nothing happens.  The only way it comes back is if I cold boot it.
[05:18] <lickalott> Where else would I look to find out whats happening?
[06:47] <thejoecarroll> hi! could someone please help me with figuring out why chroot-jailed scp works but sftp doesn't after following these instructions: http://olivier.sessink.nl/jailkit/howtos_sftp_scp_only.html
[06:48] <vezq> TaylorJohnson: looked okay to me, personally I don't usually filter OUTPUT much as it causes easily weird problems
[06:49] <vezq> lickalott: sounds like a hardware issue, can you test with some LiveCD?
[07:48] <qman__> thejoecarroll, that method is outdated as of openssh 4.8p1
[07:48] <qman__> it now has a MUCH easier built-in chroot function
[07:48] <qman__> http://www.debian-administration.org/articles/590
[07:53] <thejoecarroll> thanks for that link, qman__
[07:53] <thejoecarroll> i'll give that a go
[11:39] <ariel> i wanna know how to setup a server and configure it
[11:45] <RoyK> ariel: it all starts with a CD and a machine, or perhaps setup a VM ... it's not learned in an hour, or a week, or a year, but little by little, you'll understand more and more...
[11:48] <ariel> i know the learning curb is at a slow pace a just wanted to get to know the little details
[11:48] <ariel> i*
[11:50] <RoyK> !ask
[11:55] <ariel> i wanna know if its good to install ubuntu server via vm or full install
[12:06] <RoyK> ariel: that obviously depends what you need
[12:08] <ariel> i have a computer with a 200gb hard drive is this enough
[12:12] <RoyK> ariel: yes, you need far less for a base install
[12:13] <RoyK> ~1-2GB should do
[13:10] <tboat> hey all, im running a 12.04 server and the recent kernel update broke samba
[13:10] <tboat> ive tried uninstalling with --purge then reinstalling
[13:11] <tboat> it gives this error: /var/lib/dpkg/info/samba4.postinst: 14: /var/lib/dpkg/info/samba4.postinst: /usr/share/samba/setoption.pl: Permission denied
[13:11] <tboat> dpkg: error processing samba4 (--configure):
[13:11] <tboat>  subprocess installed post-installation script returned error exit status 126
[13:11] <tboat> Errors were encountered while processing:
[13:11] <tboat>  samba4
[13:11] <tboat> E: Sub-process /usr/bin/dpkg returned an error code (1)
[13:12] <tboat> anyone around>
[13:15] <tboat> crickets
[13:15] <tboat> so 371 people all just lurking?
[13:15] <freesbie> offcourse :)
[13:16] <tboat> well that is so very helpful
[13:16] <freesbie> sorry, might be that the .pl file is missing the execute bit for the package scripts to run properly
[13:17] <tboat> Need help with 12.04 server, samba is broken. http://paste.ubuntu.com/1452244/
[13:17] <tboat> so is that something i can find, or is it broken in the repo?
[13:17] <freesbie> havent touched samba on ubuntu, but that looks like a basic error
[13:18] <tboat> well...what i dont get is all i did was update kernel and packages, samba wasnt even listed, now it is broken
[13:19] <freesbie> start by checking if /usr/share/samba/setoption.pl is executable and run the apt-get purge again
[13:20] <tboat> so apparently perl isnt installed?
[13:21] <tboat> maybe my server got hit, because i didnt remove perl, and i dont see why updates would have removed it
[13:21] <ewook> tboat: what do you get by running 'perl -v'
[13:22] <Pici> bug 988509 seems to be related
[13:22] <ewook> Pici: nice catch.
[13:22] <tboat> @ewook perl version 5 r 14
[13:22] <ewook> tboat: there ya go. perl is intact.
[13:23] <tboat> yes thank you, i found similar bug pages but none pertaining to the .pl file
[13:23] <ewook> tboat: try looking at the launchpad bug, perhaps there's a easy fix like chmod +x on the setoption.pl
[13:27] <tboat> hmm it appears the samba4 package is broken in the ubuntu repo, so i guess i have to build samba3 from source?
[13:29] <ewook> tboat: samba4, isn't that still experimental?
[13:30] <ewook> !samba4
[13:30] <Pici> tboat: the 'samba' package is samba3.
[13:30] <ewook> there we go.
[13:30] <Pici> ewook: #ubuntu-server and #ubuntu have the same factoids, no need to ask ubottu in both channels.
[13:33] <ewook> Pici: Doh..
[13:33] <ewook> thanks ;)
[13:36] <samba35> RoyK: hi
[13:40] <tboat> @ewook @Pici samba4 is experimental, but anytime I try to do "apt-get install samba" it says i need to do "samba4"
[13:41] <tboat> hmm but after removing samba4, it seems to have gone back to samba3 now
[13:43] <tboat> ok so just installed samba3, however when i do "samba -v" it says samba is not installed
[13:43] <tboat> but proccess smdb and nmdb are running
[14:01] <tboat> still cant access my server locally with samba, anyone else have broken samba?
[14:11] <patdk-lap> nope
[14:18] <RoyK> samba35: hi
[14:19] <samba35> sorry i could not come back to you on iscsi
[14:21] <RoyK> well, did you manage to make it work?
[14:22] <samba35> no it was issuse with vmware
[14:23] <samba35> do you have idea on dhcp/dns
[14:24] <samba35> I have configure ubuntu as a dhcp client from dhcp server (dhcp server from another utm box ) but i want to configure FQDN on ubuntu
[14:25] <RoyK> iirc that's set by the dhcp client
[14:25] <RoyK> but not sure
[14:26] <samba35> ok
[15:05] <tboat> can someone explained why this bug is "resolved" when I still get that error? https://bugs.launchpad.net/ubuntu/+source/samba4/+bug/988509
[16:07] <tboat> anyone have a fix for this: https://bugs.launchpad.net/ubuntu/+source/samba4/+bug/988509
[16:11] <tboat> 384 lurkers, someone has to know something
[16:16] <tboat> so i guess no one here knows nothing about samba and samba4?
[16:37] <RoyK> tboat: what do you want to know?
[16:40] <tboat> @RoyK im on ubuntu server 12.04, samba broke after latest kernel update.  "samba" in terminal returns: "samba is not installed, use apt-get install samba4 to get it", but samba4 is what broke in the first place (https://bugs.launchpad.net/ubuntu/+source/samba4/+bug/988509).  when i do "apt-get install samba", it says samba is already installed.  I can not view my server on Windows share
[16:52] <RoyK> tboat: erm
[16:53] <RoyK> well, shoot
[16:54] <xixek> join #bmw
[17:23] <tboat> im on ubuntu server 12.04, samba broke after latest kernel update.  "samba" in terminal returns: "samba is not installed, use apt-get install samba4 to get it", but samba4 is what broke in the first place (https://bugs.launchpad.net/ubuntu/+source/samba4/+bug/988509).  when i do "apt-get install samba", it says samba is already installed.  I can not view my server on Windows share
[17:42] <sarnold> tboat: perhaps you meant "smbclient" ?
[17:44] <tboat> sarnold: smbclient would be client side not server side no?
[17:46] <sarnold> tboat: ah, I misread "can not view my server on Windows share" as "cannot view windows shares". Sorry. :)
[17:47] <tboat> no worries, yeah this server is just a media share server, but its one function, be shared on my LAN, isnt working haha.  and no one seems to be able to help me
[18:41] <claude2_> anyone here good with qos?
[18:46] <rcaskey> claude2_, #networking may be better
[18:46] <claude2_> thanks
[19:04] <hallyn> stgraber: I'm changing the qemu-kvm upstart job (which is only there to load and configure the kernel modules) to not run in a container at all.  You presumably have no objection to that?
[19:11] <stgraber> hallyn: sounds good
[19:28] <zul> hallyn: ill get libvirt 1.0.1 packaged after i get back
[19:31] <hallyn> zul: ok
[20:29] <LuizAngioletti> I've just installed and configured an apt-cacher. My client machines are all collecting their updates from my server.
[20:30] <LuizAngioletti> When I run 'apt-get upgrade' on my server, apt downloads all the packages again, although they are already available from the cacher.
[20:30] <LuizAngioletti> Is it healthy to set the 01proxy file under /etc/apt/apt.conf.d/ on the server?
[20:30] <LuizAngioletti> pointing to himself?
[20:31] <sarnold> LuizAngioletti: I've done that on my worksation and fleet of VMs I run on the laptop...
[20:32] <LuizAngioletti> sarnold: I thought it could go into a loop. Who is my cacher? Me. Who has the most up-to-date files? Me. Who should I ask for more up-to-date files? Me.
[20:33] <sarnold> LuizAngioletti: hehe :)
[20:33] <LuizAngioletti> sarnold: I doesn't then?
[20:33] <sarnold> I think mine even caches the stuff I serve out of /var/www/debs/ for testing .. it's not ideal :) but it doesn't seem to cause any problems.
[20:34] <LuizAngioletti> sarnold: I keep an eye on it, just in case. =)
[20:34] <sarnold> :)
[20:35] <LuizAngioletti> damn, my english is horrible today. =P My fingers are dumb, I apologize for taht.
[20:35] <LuizAngioletti> =P
[20:35] <LuizAngioletti> Thank you for your help.
[20:39] <sarnold> LuizAngioletti: it's IRC :) mistakes and non-native are expected. :)
[23:38] <zurich> hi: i have a 3 disk raid 5 software array. today we had some serious power issues and one of the disks failed. nowthe array won't come up (not even as degraded). I have tried mdadm -A and --autodetect but still won't come up... any suggestions?


[00:03] <Guest42400> does the bug still exist which causes an upgrade from 14.04 to 16.04 to fail due to some screensaver problem?


[03:30] <pitti> Good morning
[03:30] <pitti> bdmurray: I am now; I got your mail
[06:58] <rbasak> cjwatson: thanks! I'll retry.
[07:17] <dholbach> good morning
[07:25] <cjwatson> rbasak: OK - better do it quick because otherwise I might manage to land this whole stack in saucy first :)
[07:25] <rbasak> cjwatson: done. It's building now :)
[07:28] <cjwatson> cool
[09:04] <doko_> SpamapS, online?
[09:10] <tvoss_> xnox, ping
[09:14] <yolanda> hi, what steps do i need to follow to test lua 5.2 and ruby 1.9 ? i checked package rubyluabridge but it defaults to ruby 1.8
[09:16] <xnox> tvoss_: heya
[09:26] <yolanda> xnox, do you know about that? how to test lua 5.2 bindings for ruby 1.9?
[09:26] <xnox> yolanda: nope =) no idea.
[09:27] <yolanda> found that rubyluabridge package but it forces ruby 1.8, so no clue
[09:29] <Ph0bus> ruby is a wore
[09:31] <cjwatson> Ph0bus: That's hardly appropriate here
[09:31] <yolanda> cjwatson, do you know about how to test that bindings?
[09:31] <yolanda> i'm a bit lost on it
[09:32] <cjwatson> yolanda: Sorry, haven't the foggiest.  Perhaps contact the Debian maintainers, or the appropriate language development communities
[09:34] <yolanda> ScottK seems to be the latest uploader
[09:34] <yolanda> i'll try
[09:46] <rbasak> infinity: have you upstreamed your golang header patch? Or does someone need to do this?
[09:47] <cjwatson> Ph0bus> charming chap
[09:52] <cjwatson> yolanda: Note that rubyluabridge was just auto-synced from Debian, so you might want to update your working tree if you're working on it
[09:52] <cjwatson> (0.7.0-2)
[09:54] <cjwatson> Or, well, would just have been auto-synced if bits of LP weren't disabled in preparation for a deployment
[09:54] <yolanda> cjwatson, lp still shows 0.7.0-1 version
[09:54] <cjwatson> See my previous comment :)
[09:55] <yolanda> was typing at same moment :)
[09:55] <cjwatson> But you can grab it from https://launchpad.net/debian/+source/rubyluabridge/0.7.0-2 in the meantime
[09:55] <yolanda> ok
[09:56] <yolanda> just working on other issue now and i'll grab later, great
[10:12] <jamespage> doko, we where going to talk about go policies this week - when suits you?
[10:13] <tvoss_> ogra_, ping
[10:16] <ogra_> tvyup
[10:16] <ogra_> eh
[10:18] <ogra_> tvoss_, yup ?
[10:18] <doko> jamespage, today is fine, after lunch? 2pm?
[10:19] <jamespage> doko, yeah - thats good with me
[10:23] <infinity> rbasak: I can push it to Debian, but I'd rather someone bypass them and upstream it directly for me, if we have a decent working relationship with them.
[10:23] <cjwatson> yolanda: it's synced and (mostly) built now
[10:24] <yolanda> great
[10:31] <sil2100> mardy: hello!
[10:31] <sil2100> mardy: I'm looking at lp:webaccounts-browser-extension right now
[10:32] <sil2100> mardy: it's not daily-released right now, and I see there are no integration tests there - only unit tests
[10:32] <sil2100> mardy: do you think it's possible to do integration testing with those branches?
[10:35] <rbasak> infinity: OK, I'll ask.
[10:39] <rbasak> infinity, jamespage: bug 1187722 is fixed now then, right, both for dpkg and golang?
[10:44] <infinity> rbasak: Oh, I didn't know there was a bug for it.
[10:45] <infinity> rbasak: Closed.
[10:47] <doko> infinity, eglibc ping
[10:50] <mardy> sil2100: I doubt it, it's something very difficult to test
[10:50] <mardy> sil2100: unless it's possible to programmatically login into facebook
[10:50] <infinity> doko: See /msg
[10:51] <doko> thanks
[10:54] <sil2100> mardy: ACK
[10:55] <rbasak> infinity: no problem. I just wanted to check that there aren't any tasks remaining, apart from upstreaming.
[10:56] <infinity> rbasak: Nah, my simple 3-line patch should DTRT and be upstreamable.
[11:00] <rbasak> ack
[11:00] <rbasak> I've asked Dave to look into it.
[11:19] <yolanda> cjwatson, i checked rubyluabridge package, but it still forces ruby 1.8
[11:27] <cjwatson> yolanda: Sure, I don't actually know about it, I was just letting you know that there was an update since you said you were working on it
[11:28] <yolanda> i messaged ScottK to talk about it
[11:34] <Daviey> yolanda: Do you have a partially done branch or dsc you can throw somewhere?
[11:35] <yolanda> Daviey, for the ruby issue?
[11:36] <yolanda> i just grabbed rubyluabridge but it has a patch forcing to ruby 1.8, i was told to test with 1.9 so not sure about how to act
[12:03] <Daviey> yolanda: Right, ScottK did an NMU in Debian, perhaps he has more info.  Looking at the upstream project, certainly no fix there.
[12:04] <yolanda> Daviey, i pushed a MP for rrdtool, that one is working
[12:09] <Daviey> yolanda: super
[13:02] <ev> any archive admins around who want to NEW something for me? https://launchpad.net/ubuntu/saucy/+queue?queue_state=0&queue_text=whoopsie-preferences
[13:18] <dobey> Laney: sigh. i wonder how these tests ever passed in autopkgtest…
[13:21] <pitti> software-center? they never did
[13:27] <dobey> pitti: really? the entire time that software-center has had autopkgtest setup, it's never actually passed?
[13:27] <pitti> yes, despite several pings they've never been fixed
[13:28] <pitti> FWIW, if nobody has the time or cares, and there is an upstream test suite that at least succeeds locally, it could just be dropped
[13:29] <dobey> i don't know if the tests work locally
[13:30] <dobey> the tests are doing a lot of nasty broken things
[13:31] <SpamapS> doko: online now. Wassup?
[13:35] <doko> SpamapS, did you try to cross-build mysql in the past?
[13:55] <dobey> pitti: ok, since they've never actually worked, i just uploaded a software-center that just removes debian/tests and the X-Testsuite:, please do what you need to do to the jenkins job/britney as a result of that :)
[13:55] <pitti> dobey: ack
[13:56] <pitti> jibel: ^ on that note, I'll remove the job from the actual jenkins; does britney look at that, or at the public mirror?
[13:57] <jibel> pitti, none of them the status is kept on lillypilly. it must be removed from there.
[13:59] <pitti> jibel: hm,  where do I find that?
[14:02] <pitti> jibel: proposed-migration/autopkgtest/data/adt/saucy-proposed/amd64/saucy-proposed_amd64_software-center ?
[14:02] <pitti> jibel: just wipe that?
[14:18] <sergiusens> cjwatson: seems I made a mistake with the click hook by using people.canonical.com (external name), what's the host or fqdn that the builders see? lillypilly.canonical.com, just lillypilly or another internal domain?
[14:20] <stgraber> sergiusens: archive-team.internal but that's a view of people.canonical.com/~ubuntu-archive
[14:22] <dobey> dholbach: hi! can you take another peak at bug #1199017 please? i've updated the dsc/debian.tar for it. thanks
[14:23] <sergiusens> stgraber: ah, so I need one more step
[14:24] <dholbach> dobey, will do
[14:24] <sergiusens> ogra_: ideas? ^^
[14:24] <ogra_> sergiusens, oh, i totally forgot
[14:25] <dobey> pitti: so i'm not sure what to do about the u1-client autopkgtest issue. will you add the feature flag to ignore stderr? hacking up the tests to work around autopkgtest behaving differently than everything else seems wrong to me :)
[14:25] <stgraber> sergiusens: where are those files on lillypilly?
[14:25] <sergiusens> stgraber: http://people.canonical.com/~sergiusens/click_packages/ but they can be anywhere
[14:26] <sergiusens> stgraber: you can copy them ... this is what I do  ~sergiusens/click_ready/click_copy.py https://jenkins.qa.ubuntu.com ~/public_html/click_packages
[14:26] <ogra_> sergiusens, i tallked to cjwatson already ... but wanted to wait for you :) ... the machine is reachable under a different name ond only ~/ubuntu-rachive can be seen ... i think running your copy script from an ubuntu-arechive cronjob and have it dump into ~/ubuntu-archive/public_html/click-packages would be best
[14:26] <ogra_> stgraber, ^^^
[14:26] <stgraber> I just put a symlink, looks like it's working: http://people.canonical.com/~ubuntu-archive/click_packages/
[14:26] <sergiusens> stgraber: awesome
[14:26] <stgraber> on disk, that's a symlink to /home/sergiusens/public_html/click_packages
[14:27] <ogra_> stgraber, well, i'm not sure the access from cadejo works that way
[14:27] <stgraber> ogra_: let me check that
[14:27] <stgraber> ogra_: it does
[14:28] <ogra_> sergiusens, so now we need to change the url to http://archive-team.internal/ in livecd-rootfs
[14:28] <ogra_> (with the proper path indeed)
[14:28] <stgraber> ogra_: I just tried with wget http://archive-team.internal/click_packages/com.ubuntu.calendar-app_0.4_all.click -O /dev/null from nusakan and that worked fine
[14:28] <ogra_> stgraber, you have a login on cadejo ?
[14:28] <sergiusens> ogra_: do you feel jealous? :-P
[14:28] <stgraber> ogra_: no, but nusakan has access to that vhost/proxy server
[14:28] <ogra_> nusakan doesnt help :)
[14:28] <ogra_> the buildd needs to be able to see it
[14:29] <ogra_> i can see it pulls the seeds from http://archive-team.internal/seeds/
[14:29] <ogra_> http://archive-team.internal/ being lilliypilly
[14:29] <ogra_> (see live-build/auto/config)
[14:30] <stgraber> ogra_: archive-team.internal == <IP_ADDRESS> which is a separate IP from the main lillypilly IP, so if cadejo can access it, then it has the same view as I'm getting from nusakan which works when access archive-team.internal/click_packages, so I'm 99% sure it'll work fine from cadejo
[14:30] <ogra_> ok
[14:31] <ogra_> let me change livecd-rootfs and upload
[14:31] <stgraber> (the remaining 1% would be IS sending that traffic to squid and having some ACLs restricting to sub-directories of archive-team.internal, but I very much doubt they'd do that)
[14:34] <ogra_> sergiusens, stgraber, livecd-rootfs change and uploaded
[14:35] <ogra_> lets see how the next build goes
[14:35] <pitti> dobey: we can add the feature flag (bug appreciated, so that I don't forget and we can coordinate who will do it); hacking autopkgtest is always a lot of "fun", might take a bit
[14:35] <dobey> pitti: ok, i'll get a bug filed
[14:36] <cjwatson> sergiusens: So, I'd prefer for the ubuntu-archive user to be fetching the click packages itself rather than symlinking into your home directory
[14:36] <cjwatson> sergiusens: Not least because archive-team.internal will soon be a separate *machine*, not just a separate IP address
[14:36] <cjwatson> sergiusens: Is it possible to run click_copy.py on lillypilly?  I couldn't figure out which Jenkins base URL to use
[14:37] <sergiusens> cjwatson: this is what I do  ~sergiusens/click_ready/click_copy.py https://jenkins.qa.ubuntu.com ~/public_html/click_packages
[14:38] <SpamapS> doko: no, I have noly ever built it for x86
[14:38] <SpamapS> only
[14:38] <SpamapS> doko: well and arm ... it has some signed char issues IIRC
[14:39] <cjwatson> sergiusens: Huh, could've sworn I'd tried that, thanks
[14:39] <cjwatson> sergiusens: I'll cron that in a bit then
[14:39] <ogra_> yay
[14:40] <sergiusens> thanks
[14:41] <cjwatson> sergiusens: do you have it cronned at the moment?  what's the frequency?
[14:42] <sergiusens> cjwatson: I don't, wanted to get an intial build before stressing anything, the click packages are built once a day, so once a day is good enough
[14:42] <sergiusens> a good time would be before the actual touch build but not really as important
[14:45] <ogra_> cjwatson, something like 6 or 7am UTC should be fine
[14:48] <pitti> jibel: did you notice my question about removing the britney software-center check?
[14:48] <pitti> pitti | jibel: proposed-migration/autopkgtest/data/adt/saucy-proposed/amd64/saucy-proposed_amd64_software-center ← just wipe that?
[14:49] <jibel> pitti, yes that's the file, but if the source with a XS-TEstsuite header is still available in the release pocket it will recreate it.
[14:50] <pitti> jibel: ah, chicken-egg problem
[14:53] <jibel> pitti, yes. the copy must be forced, in any case that won't hurt since the tests have been removed.
[14:55] <sil2100> Wellark: hi!
[14:56] <sil2100> Wellark: could you tell me what's up with lp:~unity-team/unity-action-api/nohud ? Is it supposed to be daily-released as well? Should this land to distro?
[15:17] <jodh> jibel/pitti: hi - can I pester you about bug 1158391? I need to get DEP-8 integration tests working for upstart in the next few weeks so really need the ability for an autopkgtest env to spin up a nested kvm instance say and prod it in various ways.
[15:22] <rbasak> Perhaps I should write an adt-virt-libvirt at some point
[15:23] <rbasak> Or just a direct adt-virt-kvm
[15:25] <rbasak> xnox: I'm having some trouble reproducing your apache 2.4 upgrade problem. I tried installing libapache2-mod-wsgi first, but the upgrade didn't fail.
[15:26] <xnox> rbasak: i'll try to recreate my setup and i'll let you know.
[15:26] <rbasak> THanks
[15:28] <rbasak> Looks like apt chose in my case to configure libapache2-mod-wsgi before apache2.2-bin but after all unpacks.
[15:28] <rbasak> I'm not quite clear on the ordering required to reproduce it.
[15:32] <pitti> jibel: ah, thanks
[15:32] <pitti> Laney: can you do the magic to let software-center in despite failing tests? (-proposed removes the tests deliberately)
[15:33] <Laney> pitti: how are there failing tests then?
[15:36] <cjwatson> Laney: Apparently something in the stack is not good at handling removed tests and considers them a failure
[15:36] <pitti> Laney: it never succeeded, but jibel says our britney integration requires forcing this once
[15:36] <cjwatson> That is, adt-britney incorrectly requests a test run when there are no tests in that case
[15:36] <Laney> Yeah, seems like a bug
[15:36] <Laney> as long as jibel knows about it :-)
[15:37] <cjwatson> Should be sufficient to force-badtest it
[15:37] <Laney> indeed, but I didn't want to without making people at least aware
[15:37] <pitti> well, that saved us from accidentally losing tests yesterday
[15:37] <pitti> and it's the first time we actually remove a test (and I hope that won't happen too often)
[15:42] <mdeslaur> rbasak: are you planning on merging php5 5.5.0+dfsg-15 ?
[15:45] <rbasak> mdeslaur: wow. Struggling to keep up!
[15:45]  * rbasak looks
[15:46] <rbasak> mdeslaur: I understand why you asked now. If I do, I won't get around to it until tomorrow afternoon at the earliest I think. Do you need it sooner?
[15:46] <mdeslaur> rbasak: I can do it now if you don't mind
[15:47] <rbasak> mdeslaur: sure, go ahead. Or just a cherry-pick if that's appropriate. At the pace they're going I expect to do at least another merge before release.
[15:47] <mdeslaur> rbasak: ok, I'll handle it...just wanted to make sure you didn't start something already. Thanks!
[15:48] <stgraber> cjwatson: hey, so I'm looking at those ubiquity and grub2 changes to always install and use the shim on EFI. My current plan is to simply remove the sb check in ubiquity so we always install shim-signed, grub2-signed and linux-signed, then change grub-install to always set the shim as the boot entry if it exists and grub2-signed is installed. Did I miss anything?
[15:48] <rbasak> mdeslaur: OK. Thanks for checking!
[15:52] <sil2100> Wellark: if you're around, could you backlog to the question I posted earlier?
[15:52] <sil2100> Wellark: thanks
[15:53] <cjwatson> stgraber: You need to change grub-installer as well, before ubiquity
[15:53] <cjwatson> (i.e. both grub-install and grub-installer)
[15:54] <Laney> ev: Hey, I'm just looking at your system-settings MP... is it supposed to work on desktop?
[15:54] <Laney> your first isValid() call returns false here for me
[15:54] <ev> Laney: it needs activity-log-manager installed at the same time. I'm working on splitting out the dbus service into the whoopsie-preferences package
[15:55] <Laney> ev: I already had that
[15:55] <Laney> I can see it in d-feet (but get polkit errors when I try to query the methods)
[15:55] <ev> oh right, sorry
[15:56] <ev> the other part is you need to abuse /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkla
[15:56] <smoser> pitti, i'm looking at ./debian/extra/initramfs.top in lp:ubuntu/systemd
[15:56] <smoser> http://paste.ubuntu.com/5887973/
[15:56] <ev> Change crash reporting settings]
[15:56] <ev> Identity=unix-group:admin
[15:56] <ev> Action=com.ubuntu.whoopsiepreferences.change
[15:56] <ev> ResultActive=yes
[15:56] <ev> Laney: ^
[15:57] <smoser> the ROOTDELAY lines blame to you. i dont think that you authored them, but i'm wondering if you could provide some insigth there.
[15:57] <stgraber> cjwatson: ah right, forgot that one, thanks
[15:57] <pitti> smoser: no idea, I'm afraid; I mostly took what we had in the old udev scripts, and I was afraid to remove it
[15:57] <pitti> smoser: but it is certainly a gross hack
[15:58] <pitti> smoser: as with wait-for-root it should just work
[15:58] <smoser> pitti, i've never seen it before
[15:58] <smoser> it is not in raring
[15:59] <pitti> smoser: ah, then maybe it came in through debian
[15:59] <smoser> they dont have that file in their systmed package
[15:59] <pitti> smoser: right, not in version 44, it's from the 182 packages
[15:59] <pitti> smoser: anyway, is that creating a problem?
[15:59] <pitti> smoser: we can certainly take it out, but it seems like a no-op
[16:00] <smoser> for context, on azure, we had been booting with the 'rootdelay=' which is a similarly crappy hack to deal with the fact that their scsi disks are terribly underperformant.
[16:00] <smoser> and now we're seeing bug 1202700 because of this sleep.
[16:00] <smoser> its not a no-op for sure.
[16:00] <smoser> if you boot with rootdelay= it most definitely causes a sleep of that long.
[16:01] <pitti> smoser: yes, but I meant if that didn't exist in raring, why would this parameter exist?
[16:01] <smoser> the parameter in raring goes to wait-for-root
[16:01] <smoser> it increases its default timeout
[16:02] <smoser> (and it still doe sgo there in saucy, it just also gets used here :)
[16:02] <utlemming> rootdelay for the kernel means wait up to X for the root to appear, but doesn't have to wait that long
[16:02] <smoser> utlemming, it doesn't mean anything to the kernel.
[16:02] <pitti> smoser: aah, ok; so we shared the parameter, but now got a second implementation
[16:02] <smoser> just to 'wait-for-root'
[16:02] <smoser> and initramfs.
[16:03] <smoser> well, it seems it came and went in debian.
[16:03] <smoser> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=414842
[16:03] <smoser> i suspect somehow we merged bad or something...
[16:03] <pitti> no, they just implemented it differently
[16:03] <smoser> hm..
[16:03] <pitti> the wait-for-root program is an ubuntuism, it's not in debian
[16:03] <smoser> well, wait-for-root is better.  :)
[16:03] <pitti> so the sleep shoudl certainly go away from the initramfs script then
[16:03] <utlemming> smoser: https://www.kernel.org/doc/Documentation/kernel-parameters.txt
[16:04] <pitti> smoser: wait-for-root is better> for sure :)
[16:04] <smoser> utlemming, it must do nothing if there is an initramfs.
[16:04] <pitti> smoser: the part that I don't understand is why that parameter is needed at all; it still smells like a bad hack
[16:04] <pitti> sleep is never the right answer for those kinds of problems
[16:05] <smoser> pitti, it is.
[16:05] <smoser> well, right.
[16:05] <utlemming> pitti: for Azure, it was requested by MS
[16:05] <smoser> on azure its necessary
[16:05] <smoser> because their devices suck
[16:05] <smoser> the disks might just not wake up for 300 seconds
[16:05] <smoser> and you should pretned that is not a bug
[16:05]  * smoser ends rant
[16:05] <smoser> anyway.
[16:06] <smoser> pitti, so you support me just dropping those lines in our systemd ?
[16:06] <pitti> smoser: ah, so is that mostly to just extend the timeout of wait-for-root? (that defaults to 60 seconds, I think)
[16:06] <utlemming> the actual reason, given by MS is that on earlier version of Azure, the network backed devices might have the full the disk presented during the time of boot.....but smoser summed it up nicely
[16:06] <pitti> smoser: yes, sure
[16:06] <smoser> pitti, thanks for your help.
[16:06] <pitti> so for ubuntu, that command line argument should mostly change the 60 seconds wait-for-root timeout, not actually sleep for that time
[16:06] <smoser> pitti, it does
[16:06] <pitti> with that semantics it would make sense, WDYT?
[16:06] <pitti> ah, good
[16:07] <pitti> smoser: thanks!
[16:07] <smoser> or at least it used to :)
[16:07] <smoser> but i'll make sure.
[16:10] <pitti> smoser: committed to my local packaging git
[16:10] <smoser> ah.
[16:10] <pitti> smoser: I plan some other systemd debugging/fixes tomorrow, is that enough? or do you want it uploaded now?
[16:10] <smoser> well then.
[16:10] <smoser> thank you.
[16:10] <smoser> i was going to do it
[16:10] <smoser> but good enough
[16:10] <smoser> in looking, i find that cryptsetup also reads ROOTDELAY
[16:11] <smoser> but it does a 'while sleep .1' for 10 x ROOTDELAY.
[16:11] <smoser> so thats much better than 'sleep ROOTDELAY'
[16:11] <smoser> but it should probably still use wait-for-root
[16:21] <cjwatson> jbicha: Um, when you synced https://launchpad.net/ubuntu/+source/packagekit-qt, you did realise that that would break future attempts to upload 0.7-series packagekit, right?
[16:24] <xnox> jodh: looks like pre compiled headers work fine with gcc4.8. So must be something with abi-compliance-checker!
[16:25] <jodh> xnox: interesting - I'll take a look tomorrow.
[16:27] <stokachu> is there a way to tell bzr to use-existing-dir within the conf file?
[16:37] <jbicha> cjwatson: I only synced it after packagekit 0.8 had been in saucy-proposed for ~6 weeks
[16:38] <jbicha> anyway, the pk8-compatible aptdaemon should be nearly ready for saucy https://code.launchpad.net/~aptdaemon-developers/aptdaemon/main
[16:42] <jbicha> I was surprised that pk-qt didn't get stuck in -proposed like the rest of the pk8 stack, and no I didn't realize that would prevent uploading "newer" pk7 updates
[17:05] <dobey> anyone know why i would get a symbols change error immediately after generating the symbols file, building a source package with the new file, and then trying to build the binaries in pbuilder? it makes no sense to me, and i can't figure out how to make it not happen
[17:07] <cjwatson> jbicha: ah, right, packagekit got deleted from -proposed ...
[17:08] <cjwatson> jbicha: indeed, I saw about aptdaemon, I just have packagekit changes to land in advance of that.  I'll work around it
[17:12] <dobey> should i just pull the .symbols file for now and not worry about it?
[17:13] <cjwatson> wg 28
[17:13] <cjwatson> doh
[17:24] <jdstrand> cjwatson, mdeslaur, sbeattie: I just responded to the ubuntu-appstore-developers list asking for confirmation that we agree on the new json structure. can you guys respond (so everyone can be unblocked)?
[17:24] <jdstrand> it sounds like we are, but wanted to be sure
[17:27] <sbeattie> jdstrand: responded
[17:28] <mdeslaur> jdstrand: yep
[17:29] <jdstrand> sbeattie: I'll ditch the unconfined profile too
[17:29] <mdeslaur> jdstrand: hum? unconfined profile?
[17:30] <jdstrand> sorry,unconfined template
[17:30] <mdeslaur> what do you mean by "ditching it"?
[17:31] <jdstrand> mdeslaur: well, sbeattie mentioned we could remove it, but now that I think about it, I think we may still want it
[17:31] <mdeslaur> we can't remove it, the upstart job still needs to switch to it
[17:31] <cjwatson> replied
[17:32] <cjwatson> There's no rush to ditch unconfined
[17:32] <jdstrand> mdeslaur: right
[17:32] <jdstrand> cjwatson: thanks
[17:32] <dobey> anyone?
[17:34] <sbeattie> mdeslaur: ah, right.
[17:36] <cjwatson> jdstrand: It turns out that 30C heat in a country without pervasive aircon is not the optimal weather for doing complex rearrangements of hook execution code, but I'm trying ;-)
[17:36] <cjwatson> (Not that I expect complaints about heat to get much sympathy from your neck of the woods)
[17:36] <mdeslaur> hehe :)
[17:37] <jdstrand> cjwatson: haha :)
[17:37] <jdstrand> actually, we've had unseasonably cool and rainy weather here this week :)
[17:39] <slangasek> (if you can't stand the heat, stay out of Texas?)
[17:39] <ScottK> Plus Texas is the land of pervasive air conditioning.
[17:40] <jdstrand> and fans. don't forget the fans
[17:40] <mdeslaur> stepping back from the BBQ is kind of like air conditioning
[17:41]  * jdstrand is getting hungry
[18:02] <xnox> dobey: well, please provide logs of the local build and pbuilder. cause e.g. symbols of libraries used can link into your symbols, especially if local build is on raring and pbuilder on saucy-proposed.
[18:04] <dobey> xnox: that seems like a complete failure of the system if so. the symbols provided by a library shouldn't change between raring and saucy
[18:06] <xnox> dobey: depends what you code. if you include a boost template, boot transition from 1.49 to 1.53 between raring and saucy suddently the same API compatible template changes functions, boom you can new/changed symbols in a saucy rebuild.
[18:06] <dobey> does that only happen with c++ or something crazy?
[18:06] <xnox> dobey: that's not the only case.
[18:06] <xnox> dobey: e.g. gcc-4.8 change symbol visibility / export rules slightly, enough to break bionic and loading binary drivers on android.
[18:06] <xnox> dobey: and that's pure c
[18:07] <xnox> (with with assembly)
[18:07] <dobey> so yes, "something crazy" :(
[18:07] <xnox> dobey: so nobody can tell what's going on between your local build and pbuilder, without seeing the logs.
[18:07] <xnox> dobey: i'm sure, our toolchain is deterministic producer of symbols in same or compatible environments.
[18:07] <xnox> =)))))
[18:08] <dobey> :(
[18:08] <xnox> dobey: better give the URL to the source package in question and the logs of local build vs saucy build.
[18:08] <stgraber> cjwatson: is bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/saucy/grub2/saucy/ the right branch for grub2? the status of the patches in this one appears to be a bit weird (they're applied but .pc is empty, so quilt refuses to push/pop patches)
[18:09] <xnox> stgraber: lp:~ubuntu-core-dev/grub/ubuntu ?
[18:10] <xnox> nah, that one looks old.
[18:10] <xnox> stgraber: does http://people.canonical.com/~cjwatson/dpkg-quilt-setup help at all?
[18:11] <stgraber> xnox: ah I think it'd yes, that also explains what I'm seeing in the branch I think
[18:11] <dobey> xnox: well, if gcc changed things, then that must be it
[18:11] <xnox> stgraber: i remember using that for some of patches-applied-pc-dir-vcs-ignored packaging styles
[18:11] <stgraber> (well, except that .pc exists in my case but is empty ;))
[18:12] <xnox> dobey: don't assume, can you not like pastebin the diff of symbols that pbuilder generated for you?
[18:12] <jdstrand> sbeattie: if we have this in the click manifest:
[18:12] <jdstrand> "hooks": {
[18:12] <jdstrand>   "myapp": {
[18:12] <xnox> stgraber: =)))))) patches-applied-.pc/*-vcs-ignored packaging styles
[18:12] <jdstrand>   "apparmor": "apparmor/myapp.json",
[18:12] <dobey> xnox: well, i did gensymbols on raring (local), and pbuilder on saucy, so yeah. it explains it. plus pbuilder didn't fail when building on raring.
[18:13] <dobey> xnox: and the symbols are all low level red-black tree things in qt or something :(
[18:13] <jdstrand> sbeattie: I understand the a symlink will be created that is of the form $name_myapp_$version
[18:13] <jdstrand> sbeattie: what is creating that symlink?
[18:13] <dobey> that should not be exported anyway, but yay c++ is crazy
[18:13] <jdstrand> oh, you know, let me reread the spec
[18:14] <xnox> dobey: c++filt makes those symbols not look crazy. but is it still compatible?! =/
[18:14] <jdstrand> "On install, the package manager creates the target path as a symlink to a path provided by the Click package"
[18:14] <jdstrand> sbeattie: nm
[18:18] <dobey> xnox: http://pastebin.ubuntu.com/5888378/
[18:22] <xnox> dobey: looks to me like abi got broken http://paste.ubuntu.com/5888384/
[18:22] <xnox> dobey: and it's not in the Qt* symbols anything. Are you using C++11?
[18:23] <dobey> xnox: no: -std=c++0x is what is passed to g++
[18:24] <stgraber> slangasek, cjwatson: So, I've got: http://paste.ubuntu.com/5888394/ http://paste.ubuntu.com/5888396/ http://paste.ubuntu.com/5888397/
[18:25] <stgraber> I "think" that's all that needs changing but I can't very easily test it as the real test is spinning a new media with all of those landed
[18:25] <dobey> would be nice if the symbols stuff could avoid things that aren't directly from the library.
[18:26] <stgraber> so my plan is to push that to the archive today, spin a new desktop image as soon as I can, test that in an OVMF VM without SB, confirm I boot through shim, and if that's the case, then push the same change to precise tomorrow
[18:26] <dobey> but yes, definitely a change in stl there
[18:27] <xnox> dobey: well, if it's a change in templates, it does get included in your library, it also means at the moment that ABI is broken and you need to recompile all reverse-dependencies as raring packages will fail with this saucy build lib.
[18:27] <dobey> xnox: is there really no way to make this work correctly on both saucy and raring with the same symbols file?
[18:28] <xnox> dobey: the problem here is not about "getting symbols to work", but that abi is broken and incompatible library is getting built.
[18:28] <xnox> the solution here is to either: bump the soname or fix the abi to stay the same.
[18:28] <dobey> there is no change in abi in the code. this is a problem of g++ breaking things
[18:29] <dobey> all i want to do is have a package that can be built on both saucy and on raring, without changes
[18:29] <dobey> why is that so hard to do?
[18:29] <xnox> well a crashing application doesn't care where the problem is, apart from that libfoo.so.2.0.0 is missing symbols.
[18:30] <xnox> dobey: it is most likely in your code. By the say specifying -std=c++0x is unstable abi as that's what c++11 was known as before releasing.
[18:31] <dobey> "they say" ? who is they? and where do they say that?
[18:31] <dobey> (and it's not my code, i didn't write libsdtd++)
[18:31] <xnox> dobey: Gnu GCC upstream -- enable experimental features to support c++11 standard.
[18:32] <xnox> dobey: the package specified to build with that standard enabled one way or the other, thus it's in the package's code. as c++0x is not the default.
[18:33] <xnox> (packaging or upstream)
[18:34] <xnox> SET (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x -O2 -g -Wall -Werror -fPIC") in https://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntuone-credentials/trunk/view/head:/CMakeLists.txt
[18:34] <xnox> dobey: try compile on raring without specifying "-std=c++0x" and compile on saucy, and compare the symbols between the two.
[18:35] <xnox> "Important: GCC's support for C++11 is still experimental. Some features were implemented based on early proposals, and no attempt will be made to maintain backward compatibility when they are updated to match the final C++11 standard."
[18:35] <xnox> http://gcc.gnu.org/projects/cxx0x.html
[18:35] <doko> dobey, why do you include symbols of libstdc++ at all in the symbols files?
[18:35] <dobey> doko: i didn't make a choice to do so
[18:35] <doko> dobey, but you do have the choice to fix it
[18:36] <dobey> i'm trying to understand why those symbols are there, and how to fix it
[18:36] <dobey> but telling me my library broke ABI just because it was built on a different version of ubuntu doesn't help me
[18:36] <xnox> doko: how? mark them as (optional)? but isn't the abi broken?
[18:37] <doko> xnox, how would it? it's not part of the API of this library
[18:38] <dobey>  error: non-static data member initializers only available with -std=c++11 or -std=gnu++11 [-Werror]
[18:38] <dobey> bah
[18:38] <xnox> (yeah, c++0x is now aliased to c++11, due to standard rename after final publication)
[18:44] <xnox> dobey: (c++|regex|optional)"std::.*@Base 13.07" in the symbols file, should make any removals/changes ignored under std::* namespace.
[18:50] <dobey> xnox: where is that documented? http://wiki.debian.org/UsingSymbolsFiles is not especially helpful here :-/
[18:51] <xnox> dobey: man dpkg-gensymbols and https://wiki.ubuntu.com/DailyRelease/FAQ#I.27m_exposing_a_new_C.2BAC8-C.2B-.2B-_symbols_in_my_library.2C_it_seems_that_some_packaging_changes_are_needed.2BICY-
[18:53] <xnox> dobey: the later shows how to use "c++" filter/tag, but not the others "optional, arch, ignore-blakclist, symver, regex"
[18:54] <dobey> xnox: what should be in the .symbols file though? the mangled symbols, or the filtered ones?
[18:55] <dobey> it's not exactly clear what the preference is for that
[18:55] <xnox> dobey: so by default one uses symbols as they are _Zloadsofgibberish@Base 1.0, but that's not very nice for C++ since some of mangled names are architecture specific due to different sizes of things.
[18:57] <dobey> xnox: so it would also likely fail building on i386 or arm, even if it didn't fail on amd64, with the mangled symbols?
[18:57] <xnox> dobey: thus ideally for most symbols one would use full symbols (those that stay the same across all arches), and for arch specific ones use (c++)"myclass::foo()" name, to avoid commiting symbols.i386 symbols.armhf etc...
[18:57] <xnox> dobey: correct.
[18:58] <xnox> dobey: because c++ is crazy, i preffer to use (c++) for all c++ symbols, to have demangled names across the board. That does hide some changes, where mangled name changes to indicate some abi change, yet demangled name is staying the same.
[18:58] <xnox> but that's the price one pays for it.
[18:58] <dobey> it would be nice if gensymbols just did the right thing…
[18:59] <xnox> dobey: to catch remaining changes, I'm working on making dh-acc which takes complete dump of symbols & headers for each arch and generates and checks both ABI and API compatibility.
[18:59] <xnox> by using abi-compliance-checker
[18:59] <xnox> but that's still work in progress.
[19:00] <xnox> dobey: i think, it would be all ok in your case and "done the right thing..." if c++0x/c++11 was not used =/
[19:01] <dobey> xnox: well, no. it wouldn't have the (c++)Foo::bar()@Base for all the symbols, they'd still be mangled
[19:02] <dobey> and it would still probably include things that aren't really part of the library itself, i presume
[19:03] <xnox> dobey: yeah, true, since the std::* is for some reason exported in your example.
[19:03] <xnox> let me find another example i did.
[19:04] <xnox> dobey: https://code.launchpad.net/~didrocks/qtubuntu-sensors/symbols/+merge/170603
[19:04] <xnox> in that one there are actually all symbols part of the api, and no other stuff from std::*
[19:05] <xnox> dobey: i'm not that good with c++ but it is strange that std::* symbols are getting exported.
[19:05] <dobey> and QByteArray::* is also being exported
[19:05] <slangasek> stgraber: testing the whole thing might require an image, but surely the grub2 package itself could be tested locally?  since the grub2 package should fix this up on upgrade as well
[19:06] <dobey> why is all this stuff being exported here i wonder :(
[19:06] <dobey>  (c++)"QString::QString(char const*)@Base" 13.07
[19:06] <dobey> for example
[19:06] <slangasek> stgraber: although, does the installer not install grub2-efi-amd64-signed for us in that case? hrm
[19:06] <dobey> that doesn't belong there. we don't provide the QString object
[19:06] <xnox> dobey: i never had formal C++ education, so it's all even more fuzzy to me =)
[19:07] <infinity> xnox: Make the upstart testsuite stop sucking.  Thanks.
[19:07] <slangasek> (grub-efi-amd64-signed, I mean)
[19:08] <xnox> infinity: yeah, that would be good..... managed to reproduce it outside of launchpad?
[19:09] <xnox> infinity: i could disable it on powerpc/buildds, but it does seem wrong, w.r.t. how and why it's hanging.
[19:09] <infinity> xnox: Erm, I probably can, except the thing that triggered the memory was mir, not upstart.  It's one of those days.
[19:09] <slangasek> stgraber: so actually, that's a point... what does http://paste.ubuntu.com/5888394/ wind up doing on upgrade, if grub-efi-amd64-signed (or shim-signed) is not installed?  seems like it'll fail?
[19:09] <infinity> xnox: Can I blame you for the Mir testsuite too? :)
[19:09] <xnox> infinity: sure! =) if that helps you work, why not.... =)
[19:10] <infinity> Awesome.  Done.  Big jerk.
[19:10] <slangasek> stgraber: ahhh nope, I see -     if [ "$uefi_secure_boot" = yes ] && [ -e "$efi_signed" ]; then
[19:11] <stgraber> slangasek: right, it won't fail but won't install the missing package either. So upgrades won't magically fix systems, they'd still have to install the packages or reinstall.
[19:12] <stgraber> slangasek: though by the nature of the bugs reported so far, I doubt it's a big problem as people aren't likely to be able to boot the system in the first place
[19:12] <xnox> a quirk could be added to do-release-upgrade?!
[19:14] <stgraber> xnox: well, any system that booted isn't likely to be affected by the bug so I don't see what that'd gain us
[19:14] <slangasek> stgraber: right, there is that :-)
[19:15] <slangasek> stgraber: anyway, that does mean a useful test of grub post-install would be to install grub-efi-amd64-signed + shim-signed, rerun grub-install on a non-SB system, and see what happens
[19:15] <stgraber> slangasek: yep, doing that now
[19:15] <xnox> stgraber: is there a bug description? i'd like to be able to have efi machine install, upgrade bios, toggle secureboot on, reboot and it boots/works.
[19:15] <slangasek> stgraber: it gains us future-proofing against firmware changes down the line, fwiw
[19:18] <stgraber> slangasek: confirmed that a non-SB system becomes SB-ready once shim-signed and grub-efi-amd64-signed is installed (and not before those two are)
[19:18] <stgraber> xnox: the bug I'm trying to address here is https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1184297
[19:18] <slangasek> stgraber: ok, cool
[19:18] <stgraber> xnox: so I'm mostly interested by new installs of 13.10 and 12.04.3
[19:19] <stgraber> slangasek: so I'll upload the new grub2 and grub-installer, wait for those two to publish in the release pocket, then push ubiquity and test a new daily, if all looks good, I'll push the same to precise-proposed tomorrow
[19:19] <slangasek> stgraber: LGTM
[19:20] <stgraber> if we really wanted all existing users to get the shim by default, the easiest way would be for grub-efi-amd64 to depend on grub-efi-amd64-signed and shim-signed (or recommend them)
[19:20] <stgraber> not sure it's something we want to do just yet though
[19:21] <xnox> stgraber: i see. so i guess i can simply install *-signed here to be like everyone else ;-)
[19:22] <stgraber> xnox: yep, install all the -signed then the grub I'll upload in a minute and it'll just work
[19:23] <slangasek> making grub-efi-amd64 depend on grub-efi-amd64-signed would present bootstrapping problems
[19:26] <stgraber> good point
[19:41] <dobey> xnox, doko: ok, i got a version building, but it has some +symbols mentioned in the build log, for a bunch of Qt stuff, which also shouldn't be exported. would prefer to just make it so this stuff isn't getting exported if you have any ideas, but if i have to add the optional/regex flag for them, i guess i can do that too.
[19:44] <xnox> dobey: .symbols file is merely a dpkg check. nm -C -D *.so still shows all of those symbols exported.
[19:45] <xnox> dobey: if compiled like so:
[19:45] <xnox> g++ -fvisibility=hidden -Wl,-z,relro -Wl,-Bsymbolic-functions -std=gnu++11 -fPIC -I. -I/usr/include/qt5 -I/usr/include/qt5/QtCore -I/usr/include/qt5/QtNetwork -I/usr/include/libsecret-1 -I/usr/include/glib-2.0/ -I/usr/lib/x86_64-linux-gnu/glib-2.0/include/ -DPROJECT_VERSION='"foo"' -shared -Wl,-soname,1.0 -o libfoo.so *.cpp
[19:45] <xnox> dobey: i get a reduction from 736 -> 467 symbols exported, but it still shows a lot of stuff exported.
[19:46] <xnox> dobey: there is some indication that when a derived class is exported, its parents class' symbols also get exported
[19:47] <dobey> xnox: i don't think we're deriving from QString or QByteArray anywhere. only QObject or maybe something higher level
[19:49] <slangasek> the surest way to control what symbols are exported is to use a version script
[19:51] <xnox> slangasek: do you have an example for c++ code though?
[19:51] <xnox> -fvisibility-inlines-hidden brings me down to 393 exported symbols.
[19:51] <dobey> i wonder if it's moc that's causing the problem
[19:52] <slangasek> no, I expect the version script for C++ might not be very pretty :)
[19:52] <slangasek> but would support globbing
[19:52] <slangasek> on symbol names, not on C++ function names
[19:53] <xnox> but like even things like "oauth_free_array" are still exported, which is C functions, from a linked library
[19:54] <cjwatson> stgraber: Those all look basically right to me.  Thanks.
[19:54] <cjwatson> (Belatedly)
[20:01] <xnox> slangasek: dobey: even with version script matching against public* results in 189 symbols exported with many unneeded ones
[20:01] <xnox> http://paste.ubuntu.com/5888666/
[20:02] <xnox> which is better than current 736 symbols.
[20:02] <xnox> (down to 189 at the moment)
[20:03] <dobey> xnox: not sure where you got the 736 from
[20:03] <xnox> well nm -C -D *.so | wc
[20:03] <xnox> or is that not the same as exported symbols?
[20:04] <dobey> xnox: add --defined-only do that nm?
[20:06] <xnox> dobey: down to 1 symbol, I guess I overdid it now =)
[20:07] <xnox> great, now I only have std::* symbols exported and none of the UbuntuOne::* =(
[20:07] <dobey> i have 170 with -fvisibility-inlines-hidden and -Wl,--as-needed
[20:09] <xnox> dobey: yeah, that looks good. all the C stuff is gone, but there is till a bit of std::* left and Q* stuff.
[20:09] <dobey> yeah, i'd love to know how to get rid of the stl and qt stuff
[20:10] <xnox> dobey: http://accu.org/index.php/journals/1372 seems like a proper description of versioned script for C++
[20:14] <xnox> dobey: win!
[20:14] <xnox> dobey: http://paste.ubuntu.com/5888713/
[20:14] <xnox> dobey: -Wl,--version-script=exports.version   , where exports.version has
[20:15] <xnox> dobey:
[20:15] <xnox> http://paste.ubuntu.com/5888715/
[20:15] <xnox> slangasek: ^^^ just like dpkg-gensymbols has (c++) filter for names, so does GNU linker.
[20:17] <dobey> wonder if i should bother with the --as-needed then
[20:19] <xnox> dobey: i don't think you should. at the moment this is a catch all script. but you can wrap it with UBUNTU_ONE_13.07 { }; for example to version your symbols, and then you can change the abi, by exporting updated symbol under new version.
[20:19] <xnox> dobey: as done later on in the article from http://accu.org/index.php/journals/1372
[20:21] <xnox> dobey: so, now my question, is why doesn't "the toolchain do the right thing by default", it's not that hard to syntactically see what's getting exported / public.
[20:22] <dobey> yeah, i don't know :)
[20:23] <xnox> dobey: thanks for bringing this issue up, this was fun =)
[20:23] <dobey> xnox: well, i suppose using globs together with symbol versioning, is not a great plan
[20:24] <dobey> would need to be explicit for that
[20:30] <xnox> dobey: there is -export-symbols-regex that can be used instead of writting it out in a file for simple regexp.
[20:41] <dobey> xnox: it would be easier if c++ didn't require #include of private headers, to satisfy usage of things from them in the private section of a class
[20:42] <dobey> because i really don't want to export *all* the symbols, only some of them. but since we're forced to install extra headers, it's a bit of a pain
[20:43] <dobey> hopefully i can figure out a way to fix that soon though, and only export the things we want/need to export
[20:44] <xnox> now, you are just getting picky =)
[20:44] <dobey> well, i just don't want people to use API that is almost certainly going to break :)
[20:44] <xnox> =)))))))
[20:57] <dobey> oops
[20:58] <dobey> /home/dobey/Projects/canonical/ubuntuone-credentials/authlib-export-map/libubuntuoneauth/requests.h:44: undefined reference to `vtable for UbuntuOne::OAuthTokenRequest'
[20:58] <dobey> plenty of those when it tries to build the test program that links
[20:58] <dobey> that's with UbuntuOne::*; in the version script
[21:06] <dobey> the 'vtable for FOo*' are definitely not in the nm output now :-/
[21:07] <dobey> so this sucks :(
[21:26] <dobey> oh, wtf; cmake is being stupid. it's trying to add the -Wl,--version-script= to the test target as well. even though i only added to the lib target.
[21:53] <Noskcaj> roaksoax, kirkland: I've made wiki page for the testdrive hackfest. wiki.ubuntu.com/QATeam/Testdrive/Hackfest If either of you could be online through part of it that would be great. I'm still looking for someone to run it from 1600-2000UTC
[22:06] <sarnold> pitti: hello :) I think the retracer service may be sick; https://bugs.launchpad.net/bugs/1201254 was filed three or four days ago, but still has the 'need-i386-retrace' tag and coredump file attached


[13:26] <AlanBell> hi all
[13:26] <AlanBell> is there a futon client for desktop couchdb?
[13:26] <AlanBell> http://arstechnica.com/open-source/guides/2009/12/code-tutorial-make-your-application-sync-with-ubuntu-one.ars suggests there should be
[13:26] <AlanBell> but ~/.local/share/desktop-couch/couchdb.html does not exist for me
[15:55] <dsl_> can'y sync ubuntu one files from netbook remix computer, can anyone help please?
[15:55] <dsl_> can't*
[15:55] <AlanBell> dsl_: how far have you got with it?
[15:55] <AlanBell> and which version of netbook remix?
[15:57] <dsl_> AlanBell: latest version. set up account and added computer to account. i put a file in the ubuntuone folder but it doesn't get copied. checked account on web interface, same computer was added twice. removed both and followed install instructions but clicking 'ubuntu one' in internet tab doesn't launch browser page
[15:58] <dsl_> edited config file to set bandwidth limit to false as per troubleshooting instructions
[15:59] <dsl_> AlanBell: panel icon shows disconnected, when I click connect button in nautilus ubuntuone folder it connects briefly but no copy
[16:01] <dsl_> AlanBell: one sec... tried again and panel icon shows 'authentication failed' and opened log in page in browser
[16:01] <AlanBell> OK, I have no idea, but someone else no doubt will do
[16:02] <dsl_> AlanBell: that's taken me to the 'add this computer' page so fingers crossed
[16:05] <dsl_> AlanBell: well i now have a 'full' cloud icon on the panel and the button in nautilus reads 'disconnect' so i must be connected...but files don't appear to be copying. Does it usually happen automatically (syncing that is)
[16:08] <AlanBell> does for me, but I am not too sure, just here asking questions myself
[16:10] <dsl_> welll i just created a text file and saved it in ubuntuone folder but it doesn't appear when looking at file list via web interface
[16:13] <dsl_> ok, I just got a notifier saying 98 files updated (or uploaded ) which fits because i placed a lot of files/folders under ubuntuone. However the only file showing n the web is the text file i just created i.e. none of the folders or 98 files on my local computer
[16:21] <dsl_> ok, it's a bit odd but it works. I created a folder in ubuntuone and a text file within that folder. it sync'ed automatically and when i refreshed browser page this time all the previously created folders and files appeared"
[21:08] <pjfry1> Hello;
[21:56] <AlanBell> is this the best channel for desktopcouch questions?
[21:56] <AlanBell> I am struggling to get the futon client running
[21:56] <AlanBell> I think it is something to do with oauth
[21:58] <rtgz> AlanBell, this channel is mostly ubuntuone specific and there are no devs at this time here, what problem do you have?
[21:58] <rtgz> AlanBell, the dc already comes in with futon preconfigured and in case couchdb is running then futon is running as well
[21:59] <AlanBell> well the bookmark file with the oath token doesn't seem to exist
[21:59] <AlanBell> I don't have ~/.local/share/desktop-couch/couchdb.html
[22:00] <rtgz> AlanBell, ok, _sometimes_ it fails to create. This is a known bug (i guess) and supposedly fixed in dc (cannot check atm)
[22:00] <rtgz> AlanBell, however, you may try restarting the service
[22:00] <AlanBell> I tried rebooting
[22:00] <rtgz> AlanBell, /usr/lib/desktopcouch/desktopcouch-stop
[22:00] <rtgz> /usr/lib/desktopcouch/desktopcouch-service
[22:01] <rtgz> AlanBell, I guess there is some kind of issue with dc controlling couchdb and whenever it gets no response (e.g. during initial login where all apps starting up compete for disk and CPU) it just gives up leaving us without the file.
[22:02] <AlanBell> ah OK. This is in a VM
[22:02] <AlanBell> just ran /usr/lib/desktopcouch/desktopcouch-service stop
[22:02] <AlanBell> seems to be hanging, doesn't respond to ctrl+c
[22:02] <rtgz> AlanBell, mmm the stop cript is a separate one at the moment
[22:03] <rtgz>  /usr/lib/desktopcouch/desktopcouch-stop  is an actual script
[22:03] <AlanBell> ah, got it
[22:04] <AlanBell> ok, killed and now starting again
[22:04] <rtgz> you may try killing erland's bean.smp/bean to force couchdb shutdown
[22:04] <rtgz> AlanBell, it should display waiting... waiting... and then give the URL for the futon login-redirect page
[22:04] <AlanBell> yay!
[22:05] <rtgz> AlanBell, ?
[22:05] <AlanBell> I now have futon in my browser
[22:05] <AlanBell> thanks very much!
[22:05] <rtgz> :)
[22:06] <rtgz> AlanBell, you are very welcome, thanks for flying UbuntuOne airlines
[22:06] <rtgz> :)
[22:06] <AlanBell> I am using it to write an IRC client
[22:06] <rtgz> AlanBell, the logs are going to be stored in couchdb, i suppose?
[22:06] <AlanBell> yes, each message as a document
[22:07] <AlanBell> with views and couchtables to display them
[22:07] <AlanBell> so there is a daemon listening to your IRC channels and filling up the database
[22:08] <AlanBell> the client(s) just talk couchdb to get the data. To say something they create a record and the daemon says it for you.
[22:09] <rtgz> AlanBell, I made a simple telepathy logger to couchdb (1-1 connections only, never got to the groupchat)... You might want to join desktopcouch mailing list for the discussion of IM document format (not sure that IRC in your case IS viewed as IM, though)
[22:09] <AlanBell> yes, I just stumbled across that discussion on the google groups thing
[22:09] <AlanBell> it might be IM too
[22:10] <AlanBell> I was thinking of adding twitter
[22:10] <rtgz> http://groups.google.com/group/desktop-couchdb/subscribe
[22:10] <rtgz> AlanBell, yup, we need more CouchDB apps :)
[22:11] <AlanBell> I think it is going to be really really important for Ubuntu
[22:12] <rtgz> AlanBell, yep, the idea is very interesting. There are certain things that also need to be sorted, like document removals from the db and propagation of such removal (i guess it is done via _changes property now)
[22:12] <AlanBell> and I have been following couchdb since 2005
[22:12] <rtgz> And we need more robust framework...
[22:13] <rtgz> AlanBell, heh, I faced it only this September, with karmic alpha installs.
[22:14] <AlanBell> I was a Lotus Notes developer so I knew Damien Katz since before he left IBM the first time
[22:15] <AlanBell> deletion stubs are a fairly robust concept I think
[22:19] <rtgz> AlanBell, I am sorry for not being able to continue the discussion, but it is already tomorrow over here and I've got to go offline :)
[22:19] <rtgz> So, everyone, Happy New Year and devs, get the Tomboy note sync sorted out, pleeeease!
[22:19] <AlanBell> ok, bye for now rtgz
[22:19] <AlanBell> oh, the client is called cozy btw
[22:20] <rtgz> AlanBell, found the description on wiki :)
[22:20] <rtgz> okay, final bye :)