[00:01] <savvas> coppro: I think it is: http://packages.ubuntu.com/jaunty/openoffice.org
[00:01] <savvas> Package: openoffice.org (1:3.0.1~rc1-2ubuntu4)
[00:01] <savvas> spitfire: bug report link?
[00:01] <coppro> oh, so it is
[00:01] <spitfire> https://bugs.edge.launchpad.net/ubuntu/+source/mtpfs/+bug/301645
[00:02] <spitfire> changed the topis as with libmtp;)
[00:05] <savvas> spitfire: did you try to build the new version in your PPA?
[00:06] <spitfire> savvas: I've built them both locally.
[00:06] <spitfire> they are waaaay faster than previous ones.
[00:06] <spitfire> savvas: built them using pbuilder
[00:08] <savvas> spitfire: ok here's what you do: 1) bookmark https://wiki.ubuntu.com/SyncRequestProcess :) 2) since you aren't the person who submitted it, you are allowed to change the bug status from "new" to "confirmed": https://bugs.edge.launchpad.net/ubuntu/+source/mtpfs/+bug/301645/+editstatus
[00:10] <savvas> spitfire: 3) subscribe yourself in the bug 4) provide GOOD reasons except for the fact that they've released a stable version (look in their changelog, find good changes and post them in your comment).
[00:12] <savvas> spitfire: 5) mtpfs is in universe (see here next to the version: http://packages.ubuntu.com/jaunty/mtpfs ), so you subscribe the ubuntu-universe-sponsors at https://bugs.launchpad.net/ubuntu/+source/mtpfs/+bug/301645/+addsubscriber
[00:12] <savvas> and that's it :P
[00:13] <spitfire> savvas: thanks for the guide;)
[00:13] <savvas> np
[01:29] <james_w> TheMuso: are you happy for me to upload the patch in bug 317496?
[01:32] <TheMuso> james_w: Go for it.
[01:32] <james_w> thanks TheMuso
[01:36] <Laney> 'ow do lads
[01:38] <james_w> 'ello Laney
[01:46] <emgent> argh launchpad running slow again..
[01:47] <james_w>  /. :-)
[01:50]  * ScottK-desktop doesn't recall ever considering Launchpad "Not slow".
[01:52] <emgent> hahah
[01:52] <emgent> ScottK: the real problem now is that launchpad go in timeout..
[01:53] <emgent> Please try again
[01:53] <emgent> Sorry, there was a problem connecting to the Launchpad server.
[01:53] <emgent> Try reloading this page in a minute or two. If the problem persists, let us know in the #launchpad IRC channel on Freenode.
[01:53] <emgent> Thanks for your patience.
[01:53] <emgent> what balls..
[01:54] <emgent> ok I go to sleep and I will try to continue my work tomorrow.
[01:54] <emgent> good night
[02:06] <Laney> Who runs the rcbugs page? It seems to be not updating correctly
[02:06] <Laney> showing Ubuntu versions that were superceded long ago
[02:08] <james_w> I'm not sure, wgrant, you probably know?
[02:09] <Laney> Oh, I think it might be targetting Intrepid still
[02:20]  * Laney gets bored with triaging the list
[02:27] <ScottK> Laney: It is pointed at intrepid still.
[02:33] <Laney> ScottK: Do you know who to poke?
[02:33] <ScottK> Laney: Just did.
[02:33] <Laney> Excellent
[02:35]  * Laney heads bedward
[07:08] <coppro> what are the odds we'll see a backport of OO.o?
[07:16] <ScottK> Slim and none unless someone shows up who is really interested in working on it and supporting it.
[07:16] <coppro> :(
[07:17] <ScottK> If someone were interested to actually do the work, then sure.
[07:17]  * coppro checks to see if the PPA packages are working
[07:19] <coppro> hmm... nope
[07:21]  * ScottK considers how much he is going to worry about incompatible symbol changes in a library that has no packaged rdepends, but upstream didn't bump soname.
[07:24] <coppro> last time I tried the PPA, OO.org broke, we'll see if it works now
[07:38] <coppro> hmm... the PPA works
[07:38] <coppro> yay
[09:20] <HarassmentPanda|> I was asking about the process of getting a program which I have written considered for packaging for Ubuntu in here yesterday and some one (sorry I can't recall who) suggested filing a bug report under the tag of needs-packaging but I can't find out how to tag a bug
[09:20] <HarassmentPanda|> is there any special option I have missed or somthing?
[09:24] <iulian> HarassmentPanda|: You can either click on that button below the description of the bug (Update description/tags) or append /+edit to the url.
[09:25] <HarassmentPanda|> iulian: Ok - this is after I have logger the bug?
[09:26] <iulian> HarassmentPanda|: What is the bug #?
[09:27] <HarassmentPanda|> iulian: I didn't log it yet because I wasn't sure if It was right :-)
[09:29] <iulian> HarassmentPanda: Ah, this is the right way of requesting an application to be packaged.
[09:29] <HarassmentPanda> iulian: ok cool, I'll log it now, thanks
[09:30] <iulian> HarassmentPanda: You might want to take a look at https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[09:39] <lidaobing> ppa does not work now? I can't upload.
[09:41] <iulian> lidaobing: What message do you get?
[09:42] <lidaobing> iulian, Connection failed, aborting. Check your network (111, 'Connection refused')
[09:43] <lidaobing> iulian, full information in: http://paste.ubuntu.com/106317/
[09:44] <ripps> Can someone tell me if ppa.launchpad.net is down or something, i keep getting "Connection failed, aborting. Check your network (111, 'Connection refused')" from dput
[09:44] <iulian> lidaobing: Odd, I've no idea.  Ask in #launchpad, maybe you'll get an answer there.
[09:44] <iulian> It seems you're not the only one.
[09:45] <lidaobing> iulian, thanks
[09:49] <HarassmentPanda> julian: Is this right https://bugs.launchpad.net/ubuntu/+bug/318389 ?
[09:50] <HarassmentPanda> iulian: sorry thought it was a j on my screen :-)
[09:51] <HarassmentPanda> also does launchpad update me if the status changes?
[09:53] <HarassmentPanda> ubottu: that hyperlink is wrong
[09:55] <Nafallo> some might argue talking to a bot is wrong as well :-)
[09:55] <HarassmentPanda> perhaps
[09:56] <HarassmentPanda> strange though the bot responded and thanked me for my attention to detail
[09:56] <HarassmentPanda> did you ever hear that song about the bot on irc?
[09:56] <Nafallo> and that your message got escalated to the ops channel?
[09:56] <Nafallo> not really ;-)
[09:57] <HarassmentPanda> Any way did I log the issue correctly?
[09:57] <HarassmentPanda> Is the tagging correct?
[09:58] <HarassmentPanda> It was called Boten Anna by Basshunter - http://au.youtube.com/watch?v=RYQUsp-jxDQ&NR=1
[09:59] <HarassmentPanda> Not sure of the language, if you look around you can find one with subtitles
[10:00]  * Nafallo is sure about the language and wouldn't mind that song not to exist.
[10:01] <HarassmentPanda> I take it you don't like it
[10:02]  * Nafallo nods
[10:03] <hyperair> is there a motu free to revu today? =p
[10:05] <HarassmentPanda> what language is it btw?
[10:05] <Nafallo> HarassmentPanda: .se
[10:10] <hyperair> http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin
[11:10] <petski> I get a "connection refused" when I try to connect to Launchpad's PPA:
[11:10] <petski> pet@workmate:~/work$ nc ppa.launchpad.net 21
[11:10] <petski> ppa.launchpad.net [<IP_ADDRESS>] 21 (ftp) : Connection refused
[11:10] <savvas> that's more of a #launchpad problem :)
[11:11] <petski> hehe, you are damn right :)
[11:11] <petski> thanks :)
[11:11] <savvas> and it's already mentioned: < det> (can't upload to launchpad using dput, "connection refused")
[11:12] <savvas> I wonder if they're creating the signatures for PPA hehe
[11:16] <ripps> the server admin is drunk with his face on the keyboard
[11:26] <petski> I've subscribed ubuntu-sru for a certain bug (#276603) in launchpad. According to the procedure, I have to upload my package into -proposed, but I'm not allowed to. Is this mandatory? Does anyone know the average response time for ubuntu-sru?
[11:28] <laga> petski: usually, someone sponsors the package after motu-sru has ACKed it
[11:28] <petski> the package is in 'main', ... so I think motu is not involved?
[11:29] <petski> again, I could be asking the wrong channel :)
[12:13] <maxb> petski: As you say, packages in main are better discussed in #ubuntu-devel. My guess (I can't find any official doc) would be that the procedure would go something along the lines of attaching the .debdiff to the bug and subscribing ~ubuntu-main-sponsors. It's probably worth hanging around on #ubuntu-devel to see if you can get a more definitive answer
[12:14] <petski> thanks maxb !
[12:15] <ia> hello. could you tell me, please, which the best way to create deb package with sources of modificated linux kernel? for example, i clone ubunut-jaunty source tree via git; it compiles successfully via debian/rules or via make-kpkg as well. But I would like to know, does exist some alternative for "make-kpkg kernel-source" via existing original debian/rules way?
[12:19] <ia> by other words, what maintainer do, that user can just type "apt-get source linux-image-2.6.X-Y-<type>" and get: 1.original tarball 2.tarball with diffs 3.dir from tarball with applied diffs?
[12:24] <pochu> ia: that may be better asked in #ubuntu-kernel
[12:33] <hyperair> or #ubuntu-kernel
[12:38] <pochu> isn't that what I said? :)
[12:53] <hyperair> oh shit i read #ubuntu-devel
[12:53] <hyperair> sorry
[12:53] <hyperair> T_T
[12:54] <hyperair> anyway pochu, would you have time for a review? =p
[13:01] <pochu> hyperair: not really. what is it?
[13:02] <hyperair> banshee lyrics plugin
[13:02] <hyperair> http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin
[13:02] <hyperair> if you're not free then nevermind
[14:56]  * sukiminna says is anybody here..?
[14:59] <spitfire_> In ubuntu intrepid, gksu "window" is transparent. How did it change since hardy, and what do I need to have it in hh?
[15:00] <sukiminna> spitfire_: i think u are in the wrong channel buddy
[15:00] <spitfire_> sukiminna: what channel do you suggest?
[15:01] <sukiminna> spitfire_: #kubuntu maybe..
[15:01] <spitfire_> sukiminna: i said "GKSU"
[15:01] <sukiminna> spitfire_:or  #ubuntu
[15:01] <jpds> spitfire_: #ubuntu-devl might help, but maqny people are out for the weekend.
[15:01] <jpds> #ubuntu-devel that is.
[15:01] <spitfire_> jpds: thanks.
[15:01] <jpds> Stupid keyboard.
[15:02] <spitfire_> that's where I might get answer:P
[15:02] <spitfire_> jpds: and don't blame keyboard:D
[15:03] <jpds> spitfire_: it's a netbook, thus tiny keys.
[15:03] <spitfire_> oh, I undrstand.
[15:03] <spitfire_> I wouldn't buy one:P
[15:03] <sukiminna> ..juz wanna ask why i cant include linux/module.h..
[15:04] <spitfire_> I have a 15" laptop;)
[15:05] <iulian> sukiminna: What do you mean? What are you trying to do?
[15:05] <sukiminna> im learning how to code a kernel module..im a newbie..
[15:06] <iulian> sukiminna: It's #include <linux/module.h> but this isn't the right channel.  For writing kernel modules I suggest you to try google.  There are a lot of good documentation on how to write one.
[15:06] <iulian> There is also a #kernelnewbies channel on OFTC, IIRC.
[15:07] <iulian> I believe they deal with kernel modules there.
[15:07] <sukiminna> iulian: thanx
[15:46] <fabrice_sp_> Hi. Who wants to win a free DVD Authoring tool? Just review DVDStyler (http://revu.ubuntuwire.com/details.py?package=dvdstyler) and gives me the second advocate. Limited number of players allowed! :-)
[15:57] <\sh> evening
[15:58] <iulian> Hiya \sh.
[16:21] <hyperair> how does one add descriptions to quilt patches?
[16:21] <hyperair> # ?
[16:30] <JontheEchidna> Quilt will ignore anything above where the patch stuff starts
[16:31] <JontheEchidna> before Index: path/to/patched/file.cpp
[16:31] <JontheEchidna> example: http://paste.ubuntu.com/106507/
[16:32] <JontheEchidna> this is for patches in general
[16:32] <ScottK> Very strange beast this quilt.
[16:32] <hyperair> heh
[16:32] <hyperair> thanks
[16:32] <hyperair> yay now lintian is clean
[16:33] <maxb> Isn't ignoring leading text the behaviour of good old traditional patch(1) ?
[16:34] <hggdh> how is an upstream source that comes already debiansed dealt with, if we need to change it?
[16:34] <\sh> hail to the difference between patch and patch-management ,-)
[16:34] <hyperair> hggdh: you tidy the tarball
[16:34] <ScottK> maxb: I don't think relying on "patch  tries  to skip any leading garbage" is the same as "here's how you put in a comment".
[16:34] <jharr> Where's an appropriate channel for help with some deboostrap issues?
[16:34] <hyperair> hggdh: use a get-orig-source rule to remove the debian/ folder
[16:34] <\sh> hggdh: ask upstream to not play debian maintainer..
[16:34]  * ScottK mostly likes dpatch.
[16:34] <hggdh> heh
[16:34]  * hyperair prefers quilt
[16:35] <JontheEchidna> quilt ftw
[16:35] <ScottK> hyperair: It's not actuall required to remove it.
[16:35] <JontheEchidna> once you get used to it, it's awesome
[16:35] <hggdh> but this will mean changing the source tarball
[16:35] <ScottK> hggdh: If it's OKish, then just edit it and move forward.  It makes the .diff.gz awkward, but it's doable.
[16:36] <ScottK> If you need to remove entire files from the debian dir then you have to repack it.
[16:36] <ScottK> If not, it's up to you.
[16:36] <ScottK> In any case ask upstream to remove it in their next release.
[16:38] <hggdh> thanks. Second question: this package (libpst-0.6.25, right now) will need to create a new library; should the library be split in a separate package (and another one for the -dev)?
[16:38] <hyperair> ScottK: if you don't remove it your diff.gz is going to be exceptionally large
[16:39] <ScottK> hggdh: Generally yes.  You'll want to look at https://wiki.ubuntu.com/MOTU/School/LibraryPackaging and https://wiki.ubuntu.com/DanielB%C3%BCltmann/CreatingLibraryPackages that tries to summarize it.
[16:40] <ScottK> hyperair: Not necessarily.  I've dealt with these before where all I had to do was change revision/release target and so .diff.gz was essentially one debian/changelog entry.
[16:40] <ScottK> It's really up to the packager if they want to repack (except if files have to be deleted).
[16:41] <hggdh> in this case it is a debhelper, no patch support, no default library creation, and the debuild will create a lot of .ex under ./debian
[16:41] <hggdh> which does not sound kosher to me...
[16:41] <ScottK> What they are is confusing since you can't read the .diff.gz and understand the packaging (which I do do)
[16:42] <hyperair> i do that too
[16:42] <ScottK> dpkg-buildpackage doesn't create the .ex templates.  dh_make does that.
[16:43] <hggdh> they force it in under Makefile.am, EXTRA_DIST
[16:43] <ScottK> Ah.
[16:44] <ScottK> Well if the upstream build system is insane and you're going to have to redo a lot of stuff, then repacking often can give you a more understandable package.
[16:44]  * hggdh got hit with a small beast for the first even packaging from upstream ;-)
[16:45] <hggdh> that was my view, but... this will involve changing upstream tarball... and I hate that
[16:45] <hggdh> in this cases -- is bzr an option?
[16:45] <hyperair> hggdh: bzr?
[16:46] <hggdh> so that we could load the original tar ball there, and then just update
[16:46] <hyperair> hggdh: in the case of my package bansheelyricsplugin, i repacked it removing all .svn files
[16:46] <hyperair> hggdh: load the orig tarball and update? i don't get what you mean
[16:47] <hggdh> I would like to have an original tarball available for audit
[16:47] <hggdh> and repackaging will create a brand new original source, different from what upstream releases
[16:48] <hggdh> (because dh_make is run upstream before release)
[16:49] <hggdh> so: load upstream in bzr; adjust the packaging; tag it; and release
[16:50] <ScottK> hggdh: The way you want to do this is with a get-orig-source rule in your Debian rules.  It should grab the upstream tarball and repack it for you.  This both documents your changes and eases future maintenance.
[16:51] <hggdh> k, thanjs
[16:51] <ScottK> JontheEchidna: What was the package of yours I reviewed recently with a get-orig-source?
[16:51] <JontheEchidna> plasmoid-kbstate
[16:51] <ScottK> hggdh: ^^^ for an example.
[16:51] <ScottK> Thanks
[16:52] <hggdh> downloading it now
[16:53] <hggdh> ah, OK. get the source straight from the repository at the required version
[17:00]  * ScottK looks over at soren and geser for their MOTU vote on JontheEchidna ....
[17:04] <hyperair> hmm how should i fix a pacakge which isntalls stuff into /etc/gconf/schemas
[17:04] <tobi_> if a package gets updated in Debain after the DebianImportFreeze, will this be merged not until the next ubuntu release?(now the one after jaunty)
[17:08] <lfaraone> tobi_: unless a merge request is made
[17:09] <tobi_> but that needs some serious reason?
[17:10] <ScottK> tobi_: No more serious than a developer agrees it's reasonable to do.
[17:12] <tobi_> how is a merge request done? through a bug? I didn't find any special tag for that in the wiki(https://wiki.ubuntu.com/Bugs/Tags)
[17:18] <tobi_> I'm sorry I disconnected. so again: how is a merge request done? through a bug? I didn't find any special tag for that in the wiki(https://wiki.ubuntu.com/Bugs/Tags)
[17:20] <ScottK> Generally the best way to get a package merge done is to do it and attach the resulting .diff.gz to a bug.
[17:21] <hyperair> is any motu free enough to review a package?
[17:21] <Laney> ScottK: Not a debdiff?
[17:22] <ScottK> Laney: Right.  tobi_: debdiff.
[17:22] <ScottK> Not diff.gz.
[17:22]  * ScottK needs more coffee.
[17:22] <tobi_> ok thanks for the info :D
[17:22] <Laney> Generally two debdiffs, debian-ubuntu and (previous)ubuntu-ubuntu
[17:23] <Laney> https://wiki.ubuntu.com/UbuntuDevelopment/Merging
[17:23] <ScottK> Although th ubuntu-ubuntu one always seemed pointless to me.
[17:27] <ScottK> Any sponsors here who use the ubuntu-ubuntu debdiff provided by sponsorees?
[17:27] <james_w> o/
[17:27] <james_w> sometimes
[17:27] <ScottK> The requirement is present in the first version of that page, so I don't know where it came from.
[17:28] <ScottK> Another benifit of wiki reorgs.
[17:30] <ScottK> james_w: Do you feel it's of enough value to you to have the sponsorees go to the trouble of making it every time?
[17:31] <james_w> well, not everyone does
[17:31] <pochu> I sometimes looked at both, but I'm not active on sponsoring lately...
[17:31] <james_w> and it's generally easier for them to make it than me
[17:32] <ScottK> Well if people use it, I guess I won't bitch.
[17:32] <james_w> but most of the time I don't look at it
[17:32] <ScottK> I'm fairly certain I never had.
[17:32] <ScottK> I think if I really found a reason to care I'd do it myself anyway.
[17:33] <james_w> in a way it's what we should be reviewing, as it's the changes that are being made to Ubuntu
[17:33] <james_w> but generally reviewing the debian-ubuntu one is more important
[17:43] <hyperair> could a motu review my package vazaar? http://revu.ubuntuwire.com/details.py?package=vazaar
[17:45] <ScottK> james_w: In theory I agree, but we don't do source code review of new upstream versions generally, so as a practical matter I think the need for it is a corner case.
[17:54] <ramvi> I've read the wiki on how to customize the alternative cd: https://help.ubuntu.com/community/InstallCDCustomization
[17:54] <ramvi> There doesn't seem to be a way to remove software though, as with livecd customization. How do I go about removing software?
[18:32] <fabrice_sp> ramvi, you can have a look at remastersys. It allows you to do a livecd from an existing installation
[18:54] <Ubuntuxer> Hi, I would like to ask, how I use postinst.ex
[18:57] <Ubuntuxer> a link would be very useful
[18:57] <Ubuntuxer> thank you
[19:00] <jpds> Ubuntuxer: http://www.debian.org/doc/manuals/maint-guide/ch-dother.en.html#s-maintscripts
[19:01] <Ubuntuxer> thanks
[19:12] <pochu> awesome. diffstat can read .diff.gz files
[19:12]  * pochu now feels stupid for doing $(zgrep "^+++ " *.diff.gz)
[19:12] <LordDetain> I updated the libsmbios package from 2.0.3 to 2.2.8.  I have the new diff.gz, .dsc, and all the other stuff.     How do i go about submitting this ? I'm looking on this packaging guide thing on the ubuntu site but .. still nto really sure what to do
[19:13] <pochu> LordDetain: report a bug in launchpad, attach the .diff.gz and subscribe ubuntu-universe-sponsors
[19:13] <jpds> pochu: How was the English exam?
[19:14] <pochu> LordDetain: actually, subscribe ubuntu-main-sponsors as the package is in main
[19:14] <pochu> jpds: I think I did good at the Reading/Writing sections, but not so good at the Listening/Speaking ones
[19:14] <pochu> jpds: so I think with a bit luck I will get the mark I need :)
[19:16] <jpds> pochu: Well done. :)
[19:16] <LordDetain> ok im repotting a bug in launchpad, should i just put like    "upgrading 2.0.3 -> 2.2.8" as the bug ?
[19:21] <pochu> jpds: thanks :) I hope I get that mark
[19:22] <pochu> jpds: if so, I may be studying in the US starting this August :)
[19:26] <ScottK> pochu: Where?
[19:27] <Chris`> pochu: Where abouts are you from?
[19:27] <pochu> ScottK: not sure yet. I'm thinking about North Carolina State University. It'll be in CS of course :)
[19:28] <ScottK> Of course.
[19:28] <pochu> ScottK: it can be any of the universities on this list, as long as I get a good enough TOEFL mark: http://www.isep.org/students/Directory/members_in_usa.asp
[19:28] <pochu> Chris`: Spain
[19:28] <Chris`> Ah cool OK
[19:28] <nhandler> pochu: *cough* Choose Illinois *cough*
[19:29] <Chris`> *cough* Choose Bangor *cough*
[19:30]  * pochu maps.google.com those
[19:30] <Laney> Bangor's a bit far from the US
[19:30] <ScottK> pochu: Interesting.  Only choose Illinois if you like cold.
[19:31] <pochu> nhandler: Chicago, Illinois?
[19:31] <pochu> ScottK: yeah :(
[19:31] <ScottK> Laney: More than one Bangor in the world
[19:31] <Chris`> Bangor in Wales I meant, not the one in the USA, there are two Bangors in the States or so GMaps says
[19:31] <nhandler> pochu: I didn't see Chicago offerred on that list. But any university in Illinois ;)
[19:31] <Laney> ScottK: I knew what he meant
[19:31] <Chris`> Bangor, Gwynedd
[19:31] <nhandler> ScottK: And what are you talking about Illinois being cold? We are above 0F right now ;)
[19:31] <pochu> nhandler: too bad then
[19:31] <ScottK> nhandler: We're about 0C here.
[19:31] <ScottK> about/above
[19:31] <nhandler> ScottK: Lucky
[19:31] <pochu> my sister is likely going to live near Chicago RSN
[19:32] <nhandler> pochu: Then she will be relatively close to me and nixternal
[19:32] <ScottK> Tell her to watch out.
[19:32] <nhandler> :D
[19:32] <nixternal> hah
[19:32] <pochu> heh
[19:32] <Chris`> http://www.bangor.ac.uk/courses/undergrad/index.php.en?view=course&prospectustype=undergraduate&courseid=123&subjectarea=4 :D
[19:32] <nixternal> Chicago FTW!
[19:32] <pochu> .oO ( poor sister... )
[19:32] <pochu> :P
[19:32] <nhandler> pochu: I promise I won't visit her for at least a few years
[19:32] <nixternal> Chicago is great, we had more murders than any other city in the US for 2008
[19:33] <nixternal> can't beat that :p
[19:33] <pochu> lol
[19:33] <nhandler> nixternal: We just had a murder the other day about 5 minutes from my house (the day care one)
[19:33] <nixternal> didn't even hear about that one
[19:34] <nhandler> nixternal: It was in the paper today iirc. Daycare worker threw a kid down on his head hard in Lincolnshire
[19:34] <nhandler> Gotta run. BBL
[19:36] <ScottK> pochu: I don't know much about NC State, but that area is a good area for tech stuff.
[19:37] <Laney> jpds: Know anything about this? (requestsync) http://pastebin.ubuntu.com/106601/
[19:39] <nixternal> I think crimsun knows the NC State area a little bit
[19:40] <pochu> ScottK: that's what my brother told me too :)
[19:40] <nixternal> pochu: why is your sister moving to chicago?
[19:40] <pochu> nixternal: because of my brother-in-law's work
[19:41] <pochu> nixternal: I'll ping crimsun when he's online then, thanks :)
[19:41] <nixternal> ahhh...what does he do?
[19:42] <pochu> he works for power generators company
[19:42] <nixternal> holy smokes, he might actually be working by my hours then as we have a very large company that does that stuff, but I cannot remember their name for the life of me
[19:42] <nixternal> by my hours? wth!
[19:42] <nixternal> by my house
[19:43] <pochu> heh
[19:51] <jpds> Laney: Which version of lplib are you using? Never seen that before.
[19:51] <Laney> jpds: I just installed it from jaunty, but on an Intrepid system
[19:51] <Laney> maybe it's some weird interaction?
[19:53] <jpds> pochu: Neat.
[19:54] <jpds> Laney: Looks like a problem in build/bdist.linux-x86_64/egg/launchpadlib/resource.py ?
[19:54] <Laney> right
[19:56] <jreinhardt> hi everybody. Is someone interested in reviewing my packaging of a (imho) really handy LaTeX package? http://revu.ubuntuwire.com/details.py?package=pgfplots
[20:22] <Laney> jpds: Oh, I forgot that I had a manually installed version of lplib. Mea culpa!
[20:22] <jpds> Laney: No problem.
[20:22] <Laney> ...althouh I just got launchpadlib.errors.HTTPError: HTTP Error 401: Unauthorized
[20:22] <Laney> but the bug was filed. Weird.
[21:22] <RainCT> pochu: can't the key be added to -config?
[21:27] <SolarWar> hi folks, quick question on packaging a program- must the licence appear on top of every source file at line 0 exactly? Or can the license be described after all the includes & ifdefs of the source file?
[21:27] <RainCT> SolarWar: that shouldn't be a problem
[21:27] <SolarWar> okay thanks :)
[21:37] <Chris`> Could someone review my package please, http://revu.ubuntuwire.com/details.py?package=partitionmanager
[21:45] <RainCT> uhm.. what does "wired/wireless NIC" mean? (it's in the HW testing page)
[21:46] <Chris`> Network interface card?
[21:47] <RainCT> ah :P
[21:47] <RainCT> thx
[21:47] <Chris`> You're welcome
[21:52] <RainCT> How are those keys which work by moving the finger over them called?
[21:52] <RainCT> (those which are activated by the electricity in our fingers, or whatever)
[21:52] <laga> electro-capacitative?
[21:53] <RainCT> nice name :P
[21:56] <Nafallo> fingerprint reader? ;-)
[21:56] <RainCT> LOL
[21:57]  * RainCT may not know how those thingies are called, but this does still not mean that he is stupid enough to not know how a fingerprint read looks :P
[21:59] <fta> RainCT, "touch sensitive keys"? like the multimedia keys on dell inspirion laptops?
[22:07] <RainCT> laga, fta: thanks
[22:21] <cbx33> hey guys
[22:21] <cbx33> howz it going
[22:21] <Chris`> cbx33: It goes good ;)
[22:22] <cbx33> any one know how to create a second tun device?
[22:22] <cbx33> tun1
[22:36] <hggdh> I would really appreciate if a MOTU could look & comment at the libpst-0.6.25-1ppa1 on my PPA (https://launchpad.net/~hggdh2/+archive).


[00:14] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-136.140] (core, kernel)
[00:15] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (groovy-proposed/main) [5.8.0-42.47] (core, kernel)
[00:15] -queuebot:#ubuntu-release- New binary: linux-signed [s390x] (groovy-proposed/main) [5.8.0-42.47] (core, kernel)
[00:15] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-136.140] (core, kernel)
[00:18] -queuebot:#ubuntu-release- New binary: linux-signed [arm64] (groovy-proposed/main) [5.8.0-42.47] (core, kernel)
[00:24] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (groovy-proposed/main) [5.8.0-42.47] (core, kernel)
[00:45] <sil2100> Oh well, looks like we'll have to build the .2 RCs tomorrow
[00:45] <sil2100> o/
[01:20] -queuebot:#ubuntu-release- New binary: adios [riscv64] (hirsute-proposed/universe) [1.13.1-27] (no packageset)
[02:05] -queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:<IP_ADDRESS> => 1:20.04.13] (core)
[06:23] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (groovy-proposed) [5.8.0-42.47]
[06:23] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (groovy-proposed) [5.8.0-42.47]
[06:23] -queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (groovy-proposed) [5.8.0-42.47]
[06:23] -queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (groovy-proposed) [5.8.0-42.47]
[06:23] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-136.140]
[06:23] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-136.140]
[09:53] <sil2100> o/
[09:53] <sil2100> xnox: give me a poke once you were able to do the manual test of u-boot-menu
[09:56] <sil2100> tseliot: hey! Guess you have been pinged about the ubuntu-drivers-common issue in focal? https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1913651
[09:57] <sil2100> Seeing that it appears rather frequent, I'd like to get that fixed before .2
[10:09] <xnox> sil2100:  https://bugs.launchpad.net/ubuntu/+source/u-boot-menu/+bug/1913468 verified.
[10:12] <sil2100> xnox: thank you!
[10:43] <tseliot> sil2100, ubuntu-drivers should be used with root privileges, at least when installing drivers
[10:45] <tseliot> I'll make sure to check that, and make the program exit when those privileges are not available
[10:46] <juliank> tseliot: ubuntu-drivers {devices,debug,list{,-oem}} probably not
[10:47] <juliank> as in please don't break those
[10:48] <tseliot> juliank, no, it's just the install case that requires root privileges
[11:17] <paride> sil2100, hi! I see there are no amd64 dailies here: https://cdimage.ubuntu.com/ubuntu-server/focal/daily-live/pending/
[11:19] <paride> and also no arm64
[11:19] <paride> did something go wrong with the image build process?
[11:19]  * paride checks
[11:23] <paride> yup, there are two "ERROR WHILE BUILDING OFFICIAL IMAGES" in the latest build log https://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/focal/daily-live-20210129.log
[11:23] <ogra> 32bit are enough for everyone !
[11:24] <seb128> cp: cannot stat '/srv/cdimage.ubuntu.com/ftp/dists/focal-updates/main/installer-arm64/current/legacy-images/hwe-cdrom/vmlinuz': No such file or directory
[11:24] <Laney> that sounds like xnox's change from yesterday
[11:25] <jibel> cp: cannot stat '/srv/cdimage.ubuntu.com/ftp/dists/focal-updates/main/installer-amd64/current/legacy-images/hwe-cdrom/initrd.gz': No such file or directory
[11:25]  * Laney joins the club
[11:25] <Laney> cp: cannot stat '/srv/cdimage.ubuntu.com/ftp/dists/focal-updates/main/installer-amd64/current/legacy-images/hwe-cdrom/initrd.gz': No such file or directory
[11:25] <sil2100> Legacy?
[11:25] <paride> :) saw that
[11:26] <sil2100> Why does everything have to explode on Fridays
[11:27] <paride> on release candidates friday
[11:27] <sil2100> Anyway, looking at this, but anyway xnox ^
[11:28] <paride> thanks sil2100
[11:35] <sil2100> uh, crap
[11:37] <sil2100> Ok, so we weren't ready for this yet, I see the debian-cd focal boot-amd64 is still written to work with debian-installer
[11:37] <sil2100> And since we do not use d-i anymore, and therefore we did not bump d-i with the HWE variant, it looks in legacy-images/ and doesn't find anything interesting
[11:37] <sil2100> Need to see how boot-amd64 looked in groovy and backport that there
[11:37]  * sil2100 looks
[11:39] <sil2100> ARGH, then again, we have no cd-boot-images-* for focal
[11:41] <sil2100> Ok, so we have two options, either hacking boot-* scripts in debian-cd to do the right thing, but I'd need xnox to look at that - or actually bump debian-installer and continue using the legacy-server bits
[11:41] <sil2100> I'll prepare the second option since the first feels very frisky to me
[11:58] -queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:<IP_ADDRESS> => 1:<IP_ADDRESS>] (core)
[12:00] <tjaalton> sil2100, xnox: 20.04.2 should use oem-5.6
[12:02] <sil2100> This is about server
[12:02] <tjaalton> right, but the desktop image, instead of oem-5.10
[12:02] -queuebot:#ubuntu-release- Unapproved: update-manager (groovy-proposed/main) [1:20.10.3 => 1:20.10.4] (core)
[12:03] <sil2100> Argh, ok, one thing at a time
[12:03] <sil2100> ;)
[12:03] <tjaalton> so, no changes needed, unless there's a sane way to get rid of the 5.10 bits
[12:03] <tjaalton> hehe, right
[12:03] <tjaalton> no action needed :)
[12:03] <Laney> I forgot how that gets on there
[12:03] <tjaalton> just a fyi
[12:04] <tjaalton> Laney: because of nvidia?
[12:04] <Laney> is that a question question or a statement question :p
[12:05] <Laney> you can probably tell a bit by diving in https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.focal/ or cd build logs
[12:05] <tjaalton> statement I think :)
[12:05] <tjaalton> I'll look
[12:06] <Laney> https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.focal/ship-live.seedtext
[12:06] <xnox> tjaalton:  well, we probably want to get rid of the nvidia oem 5.10 bits i'll see if that can be fixed.
[12:06] <Laney> if it's that and there's a way to tweak this regex, we could do it
[12:06] <xnox> sil2100:  sigh.
[12:06] <xnox> Laney:  it is.
[12:07] <xnox> sil2100:  i wonder if we can somehow not tweak CONF at all (i.e. revert my change from yesterday) and just set that to true inside all the boot scripts and/or like for ubuntu-server only.
[12:07] <xnox> sil2100:  let me see what i can make up.
[12:08] <tjaalton> ah yes, that linux-modules-nvidia regex will pick 20.04b as well
[12:08] <xnox> har har
[12:08] <xnox> so we try to download d-i stuff..... and then we do not use it.
[12:09] <Laney> you could probably add a $ at the end, that would exclude the b variants
[12:09] <tjaalton> yeah
[12:12] <sil2100> xnox: oh, so it's not actually used, just downloaded?
[12:13] <sil2100> You know these code paths much better, but if anything I have a d-i upload almost done that would add those files - even if for dummy reasons
[12:13] <xnox> sil2100:  yeah, downloaded checked, then later we end up with if live use the casper one; else use the downloaded d-i one.
[12:14] <xnox> sil2100:  and all of that stopped using d-i bits in groovy+
[12:14] <xnox> sil2100: if you want you can revert the CONF commit for now, i'm reworking matching boot-* changes to have it all work in concert.
[12:14] <sil2100> hm, so maybe it would be trivial enough to just modify the boot-* scripts to do what we did in groovy?
[12:14] <sil2100> Ok
[12:15] <xnox> sil2100:  not quite, cause in groovy+ we use cd-boot-images-* stuff that doesn't exist in focal.
[12:15] <sil2100> Yeah, saw that indeed
[12:15] <xnox> focal still uses syslinux boot
[12:15] <sil2100> (which is why I didn't want to do it myself)
[12:16] <sil2100> Ok, so in that case you do your magic, I'll revert the CONF.sh piece
[12:29] -queuebot:#ubuntu-release- Unapproved: rejected base-files [source] (focal-proposed) [11ubuntu5.3]
[12:30] <tjaalton> ^ this was the old version from September, which now needs to be rebased..
[12:32] <xnox> sil2100:  your comment in the debian-cd revert is incorrect. teh BACKPORT_KERNEL setting is used to trigger hwe code-paths for both d-i & subiquity; but we always download d-i kernels, even when building just the subiquity image.
[12:32] <xnox> but whatever.
[12:33] <sil2100> Ah, you are right! I see it now, as it causes adding a new KERNEL_PREFIX, and I see a lot of possibly non-legacy stuff done per kp
[12:34] <sil2100> ...and even more than that
[12:36] <sil2100> hm, if I was to hack on this, I wonder what would happen if we simply re-added BACKPORT_KERNEL but removed the bits for "# Download boot images" + the loop for copying over the kernel stuff from ${!kp}cdrom/
[12:38] <xnox> sil2100:  we still use debian_cd tarball on both d-i & subiquity images.
[12:38] <xnox> i have this so far:
[12:38] <xnox> https://paste.ubuntu.com/p/vdwGHX3m7W/
[12:39] <xnox> https://paste.ubuntu.com/p/cZ7sChDYSP/ => with CONF.sh change back in.
[12:39] <xnox> but need to test all of this.
[12:39] <sil2100> oh!
[12:39] <xnox> let me try to sync a mirror, and try to do local builds of all of these without the --livefs
[12:39] <xnox> to test that everything is sane.
[12:40] <sil2100> Yeah, this feels like a better idea
[12:40] <xnox> and it will be the first time we are doing hwe on s390x subiquity iso
[12:40] <xnox> cause there was no s390x subiquity in bionic
[12:43] <sil2100> xnox: hm, you still might be working on that, but I think you might be missing moving the list_kernel_abis call for ppc64el to under the "$CDIMAGE_INSTALL_BASE" = 1 conditional
[12:44] <xnox> sil2100:  it looks scoped correctly to me.
[12:44] <xnox> above the else
[12:44] <xnox> and else is for the cdimage_install_base
[12:44]  * xnox is not sure if i should be reindenting this stuff or not.
[12:45] <sil2100> Oh, indeed, nvm, I think my eyes got confused by the indent and lack of coffee, thanks!
[12:51] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (groovy-proposed) [1:20.10.4]
[12:56] -queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (focal-proposed) [1:20.04.13]
[13:00] -queuebot:#ubuntu-release- Unapproved: update-notifier (focal-proposed/main) [<IP_ADDRESS> => <IP_ADDRESS>] (ubuntu-desktop, ubuntu-server)
[13:13] -queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:<IP_ADDRESS> => 1:<IP_ADDRESS>] (core)
[13:17] -queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (focal-proposed) [1:<IP_ADDRESS>]
[13:17] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (focal-proposed) [1:<IP_ADDRESS>]
[13:18] <sil2100> xnox: you fine testing that locally? Since we could also do a cdimage build with the changes without --livefs
[13:21] <Laney> I'm going to push that ship-live change discussed above
[13:21] <Laney> tjaalton: is there somewhere we should note this to remember to fix it when rolling the oem kernel
[13:21] <Laney> ?
[13:21] <sil2100> Laney: ACK
[13:22] <tjaalton> Laney: maybe we should have a public tracker bug for that
[13:23] <tjaalton> don't think there is one now
[13:23] <Laney> I was thinking like a SOP or a bug template - to roll an OEM kernel onto a new series do x, y, z
[13:23] <tjaalton> ah
[13:24] <Laney> otherwise I predict us forgetting this part
[13:24] <Laney> :p
[13:24] <tjaalton> heh, quite possibly
[13:26] <Laney> ok committed
[13:26] <Laney> we must must remember to verify this worked and test an nvidia install
[13:49] <xnox> in my local builds the seed change looks good
[13:49] <xnox> it shows me the diff that the 5.10 stuff is gone
[13:56] <sil2100> tseliot: ok, so the crash from the mentioned ubuntu-drivers-common is only from when `ubuntu-drivers install` is called as non-root, right (seeing that the trash is via command_install())?
[13:56] <tseliot> sil2100, correct
[13:57] <sil2100> Just making sure that the other commands don't crash when ran as non-root
[13:57] <sil2100> Ok, so not a blocker then!
[13:57] <tseliot> no, they won't
[13:57] <sil2100> Thanks o/
[13:57] <tseliot> np
[13:57] <sil2100> Guess it would be good to print out a message about missing privilages, but that's more of an UX improvement for the future. Anyway, let me get it off from the blocker list
[14:01] <sil2100> Wonder how users encountered this cash though, by manually running the command?
[14:09] <xnox> not sure that arm64 subiquity was ever built with hwe before either
[14:10] <xnox> also not sure if my arm64 subiquity hwe changes would break arm64 desktop which i'm not sure if we are building for focal still
[14:10] <xnox> leh sigh.
[14:10] <xnox> and also on arm64 we probably ought to add 64k kernel installer option.
[14:10] <xnox> (for hirsute)
[14:34] <sil2100> xnox: yeah, so we are still building dailies of the arm64 desktop
[14:35] <sil2100> (for focal)
[14:36] <xnox> sil2100:  cool.
[14:37] <xnox> sil2100:  so i'm finding more and more issues. s390x & arm64 are now building; and my mirror was incomplete for amd64.
[14:37] <xnox> however none of them have the right grub menu.
[14:37] <xnox> ie. arm64 ends up without hwe entries in grub.cfg; and has menu entries that are complete BS. I.e. desktop-like entries for oem-config and what not which make no sense with subiquity.
[14:40] <sil2100> ugh, where is all of this coming from? Is this all from the boot-amd64 etc. scripts as well?
[14:40] <xnox> and boot-arm64
[14:41] <xnox> we really did add all the subiquity stuff for hwe in boot-amd64 only, in bionic only, for .2 release. meaning that focal boot-* have none of that, because they derived from cosmic / bionic .0
[14:41] <xnox> anyway, getting there.
[14:41] <xnox> it also means we didn't test any of the subiquity installers with hwe kernels =)
[14:41] <xnox> fun fun fun
[14:42] <xnox> on any arch.
[14:43] <sil2100> Glorious
[14:43] <ogra> kernels ... so overrated
[14:43] <sil2100> I don't know all the code-paths there, but I guess this would basically mean we'd have similar problems with the boot entries even if I did my debian-installer workaround with adding the HWE entries there, oh well
[14:44] <sil2100> Nothing like discovering such issues on a Friday before release ;)
[14:50] -queuebot:#ubuntu-release- New source: directx-headers (hirsute-proposed/primary) [1.0.1-0ubuntu1]
[14:50] <sil2100> xnox: ...should we just backport cd-boot-images-* to focal? ;D
[14:52] <xnox> har har har
[14:52] <xnox> so. ppc64le is now perfect.
[14:52] <xnox> arm64 one has two extra entries, will try to make it as perfect as ppc64le
[14:52] <xnox> but meeting time.
[14:53] <xnox> if i don't finish i will hand-over to somebody else before eod.
[14:56] <sil2100> Thanks!
[14:57] <sil2100> I don't know these parts but if you won't be able to find anyone, I could potentially take over - already learned like a LOT about this
[14:57] <sil2100> But probably vorlon would be more useful
[15:57] <sil2100> tseliot: hey! Sorry to get back to this again, but I want to make sure about that: what about if users start the 'Additional Drivers' section and select a driver to install - is that using `ubuntu-drivers install`? If yes, are the permissions escalated by that point so this is running as root?
[15:59] <tseliot> sil2100, yes, I think they use polkit or something like that, since apt won't let users install packages unless they have root privileges
[16:00] <sil2100> Ok, if this was tested then good, thanks - since I have no way of testing that as I have nothing that I could install drivers for there ;p
[16:04] <tseliot> sil2100, it's always been this way, it's just that now it tries writing to a file before using apt, hence the different error
[16:05] <Laney> it could do like systemd does and use polkit to get elevated permissions
[16:05] <Laney> might be too much work :p
[16:36] <xnox> vorlon:  does grubx64.efi on the amd64 iso come from d-i build, in focal?
[16:42] <Eickmeyer> ubuntu-archive: Is there a reason why hydrogen is on the Debian blacklist? IIRC it had to do with the qt4-qt5 transition, but I could be wrong.
[16:43] <vorlon> xnox: that is my recollection yes
[16:44] <vorlon> Eickmeyer: the sync blacklist has a bzr log :) "blacklist hydrogen, documenting that it shouldn't be removed" - hydrogen had been removed from Debian and this was a way to document that the removal shouldn't be followed in Ubuntu
[16:45] <vorlon> (in principle we want process-removals to honor sync-blacklist but in practice this is not implemented)
[16:46] <Eickmeyer> vorlon: Hi! Good to read you. :) Since it's in Debian now, and is being actively maintained there, wouldn't it be logical to remove the blacklist on it?
[16:46] <vorlon> Eickmeyer: if you want this dropped from the blacklist now that it's back in Debian, I'm happy to remove it from the blacklist yes
[16:46] <Eickmeyer> vorlon: Awesome, that would be great. :)
[16:46] <vorlon> done
[16:46] <Eickmeyer> Thanks. :)
[16:48] -queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:<IP_ADDRESS> => 1:<IP_ADDRESS>] (core)
[16:58] -queuebot:#ubuntu-release- Unapproved: rejected ubiquity [source] (focal-proposed) [<IP_ADDRESS>]
[17:02]  * sil2100 goes AFK a bit to rest
[17:02] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (focal-proposed) [1:<IP_ADDRESS>]
[17:05] <xnox> vorlon:  i'm kind of confused how i'm failing to identify which signed build of it, is used. will try again but like using the .iso from cdimage, rather than locally built. cause maybe my environment is dirty.
[17:06] <xnox> vorlon:  a separate question then, should i be preparing d-i rebuild, for us to gain `exit 1` in grub & to potentially get secureboot on arm64?
[17:06] <xnox> or should we do what was mentioned a few times now, and backport cd-boot-images-* to focal, such that we can pull grub from there for the efi boot.
[17:10] <xnox> i am thinking to somehow download & unpack grub-efi-amd64-signed
[17:10] <xnox> and steal the right grub from there.
[17:14] <Eickmeyer> vorlon: Now I'm having difficulty as the hydrogen orig tarballs have differing contents. Even tried a manual upload with the same result. Got any suggestions? (sorry to take any of your time).
[17:17] <xnox> fakesync?
[17:17] <xnox> (from ubuntu-dev-tools)
[17:17] <Eickmeyer> xnox: Yeah, tried that, same issue.
[17:17] <xnox> sigh
[17:17] <xnox> Eickmeyer:  i am a bit tied up now, but if you tell me what needs to be achieved, i can poke it when i'm free next.
[17:18] <xnox> Eickmeyer:  do you want "to sync it from debian to ubuntu, for realz, kthxbye"?
[17:18] <Eickmeyer> xnox: Hahaha! Exactly.
[17:18] <xnox> cool. will do.
[17:18] <Eickmeyer> xnox: You're amazing. Thanks a lot. :)
[17:42] <xnox> vorlon:  d-i pulls signed grub directly from /uefi/ from the archive; like grub2-signed does at build time. but because we actually generate different signatures for each suite, it means that d-i's & grub2-signed deb binaries have different checksums => horay.
[17:42] <xnox> but if one strips signatures with sbattach --remove, then the two grubs are identical and comparable.
[17:43] <xnox> so yeah, our isos ship with `grub2-signed 1.142.3` still and thus don't have support for `exit 1` on both amd64 & arm64; nor secureboot on arm64.
[18:07] <xnox> sil2100:  vorlon: https://code.launchpad.net/~xnox/debian-cd/hwe-focal/+merge/397181
[18:07] <xnox> otherwise we don't have hwe stack on the subiquity isos.
[18:07] <xnox> as in no boot-loader menus
[18:17] <sil2100> o/
[18:17] <sil2100> Looking
[18:21] <xnox> Eickmeyer:  uploaded.
[18:27] <sil2100> Ok, for this I think I need a coffee, back to the review in a bit
[18:30] <Eickmeyer> xnox: Thanks so much! :)
[18:50] <xnox> sil2100:  it's a mish mash of bionic's boot-* with focal's boot-*, sometimes cheating and looking at what hirsute's boot-* files do.
[18:50] <xnox> plus a few trials and errors to get it more or less ok.
[19:09] <cking> sil2100, i verified 1894329
[19:13] -queuebot:#ubuntu-release- Unapproved: ubiquity (groovy-proposed/main) [<IP_ADDRESS> => <IP_ADDRESS>] (desktop-core)
[19:26] <tumbleweed> I'm fixing up a bunch of old data in distro-info-data
[19:27] <tumbleweed> Is there a canonical EOL date for ESM releases?
[19:27] <tumbleweed> according to https://wiki.ubuntu.com/Releases 12.04 ESM should be EOL, but there's no date there
[19:28] <tumbleweed> I see ubuntu-security-status consults distro-info-data
[19:28] <tumbleweed> if I tweak eol by a couple of days, should I be tweaking eol-esm too?
[19:29] <tumbleweed> I've also seen that ESM can be available for 5 years rather than the 2 we're quoting
[19:32] <xnox> tumbleweed:  precise ESM is no longer for sale; but as can be obviously seen precise archives are not yet removed from primary mirrors .................. sigh .....
[19:33] <tumbleweed> yeah, I gathered as much
[19:33] <xnox> tumbleweed:  Security updates for 14.04 LTS until 2022 to trusty is defined at least on https://ubuntu.com/security/esm as 3 years of ESM
[19:34] <xnox> and ditto for xenial Extended Security Maintenance for Ubuntu 16.04 LTS will be available April 2021 until 2024.
[19:34] <xnox> bionic is yet to be defined.
[19:34] <xnox> focal has been announced in the past as offering 5 years of esm.
[19:34] <tumbleweed> does anyone care if I tweak the exact dates in there to match the final eol date
[19:35] <xnox> tumbleweed:  i think it is a fair default of 3 years of esm for everything for now.
[19:35] <tumbleweed> + 3 years
[19:35] <xnox> tumbleweed:  bdmurray i think is off, but i think he in the past was involved in those dates.
[19:36] <xnox> tumbleweed:  plus it's not like we will publish your tweaks to said data into ESM repos themselves. and people see their entitements via the `ua` (ubuntu advantage) client anyway.
[19:36] <tumbleweed> true
[19:36] <xnox> tumbleweed:  i don't see any harm in +3years as a rule of thumb. but maybe wait for someone else to speak up. like bdmurray and/or vorlon.
[19:37] <tumbleweed> thanks!
[19:37] <xnox> something something us holiday last or the week before, swap for today, happening a lot though. so maybe they will only respond next week.
[19:37] <tumbleweed> it's kind of amazing how many off by one or two mistakes there were
[19:37] <tumbleweed> I should stop caring :P
[19:38] <sil2100> cking: thanks!
[19:42] <sil2100> Back on it now
[19:44] <tumbleweed> xnox: turns out the only tweak was to precise (2017-04-26 -> 28). It's in the past, I'm sure nobody cares.
[19:45]  * tumbleweed tweaks eol-esm and is done with it
[19:47] <tumbleweed> https://salsa.debian.org/debian/distro-info-data/-/commit/c84eef6eda6c87e0bd5229e6202385202c8c440a
[19:48] <bdmurray> thanks tumbleweed
[19:48] <tumbleweed> merging your esm patches, this should be more maintainable in the future
[19:54] <vorlon> xnox: which signed build of it> you're looking at gcdx64.efi not grubx64.efi in the source, right?
[19:54] <vorlon> xnox: and yes, we want a d-i rebuild; have you done this yet?
[19:55] <vorlon> xnox: "generate different signatures for each suite" uh?
[19:57] <vorlon> xnox, tumbleweed: for releases where Canonical has not declared a support period, I would prefer you not list any end date as that may prematurely influence customers' decisions if it turns out to be inaccurate. "TBD" please
[19:57] <vorlon> xnox: as I don't see a d-i upload in the queue, should I do one?
[19:58] <tumbleweed> vorlon: I think that'd only be Focal
[19:59] <tumbleweed> but no ESM release has a day of the month specified, only the month
[19:59] <vorlon> tumbleweed: xnox said bionic "is yet to be defined" whereas focal has been announced as 5 years
[19:59] <tumbleweed> vorlon: it has an EOL date on https://wiki.ubuntu.com/Releases
[19:59] <tumbleweed> focal does not
[20:00] <tumbleweed> if there was somewhere I could refer to for what time frames canonical has declared support for, that'd be great, it's what I was asking for
[20:02] <vorlon> I'll see if I can track that down; but again, if there hasn't been an announcement, we shouldn't list any end date on this page
[20:02] <tumbleweed> the decleration of the date for bionic came from https://bugs.launchpad.net/ubuntu/+source/distro-info-data/+bug/1848688
[20:02] <tumbleweed> which wasn't me
[20:02] <tumbleweed> but I would have done the same thing
[20:03] <tumbleweed> err no, that's focal
[20:03] <tumbleweed> https://launchpad.net/ubuntu/+source/distro-info-data/0.37ubuntu0.3 - bdmurray
[20:05] <sil2100> xnox: hm hm, ok, so I'm might need some clarification. I mean, generally this hwe debian-cd branch seems fine with my limited knowledge, I'm just wondering about the HWE menu labels on the arm64 image
[20:07] <sil2100> Ah, no, I think I get it
[20:07] <tumbleweed> vorlon: https://ubuntu.com/security/esm declares 5 years for >= Bionic
[20:08] <tumbleweed> which I guess means 2 years (5 total - 3 LTS)
[20:08] <vorlon> tumbleweed: yeah I was just about to send you that link
[20:08] <vorlon> :)
[20:10] <tumbleweed> oh, no that is LTS + 5 years
[20:11] <Odd_Bloke> It actually declares "up to" 5 years, which is less categorical.
[20:12] <tumbleweed> yeah, but I need a date
[20:12] <tumbleweed> and eol + 5 years is what ubuntu is currently carrying
[20:15] <Odd_Bloke> Yeah, I agree that's your best option for a date.
[20:16] <tumbleweed> at some point, we probably need a more complex data structure to be able to carry nuance like announced vs expected
[20:16] -queuebot:#ubuntu-release- Unapproved: ubiquity (focal-proposed/main) [<IP_ADDRESS> => <IP_ADDRESS>] (core)
[20:18] -queuebot:#ubuntu-release- Unapproved: debian-installer (focal-proposed/main) [20101020ubuntu614.1 => 20101020ubuntu614.2] (core)
[20:21] <sil2100> xnox: ok, I think this is almost +1 - just had one quick question there, inline
[20:23] <vorlon> sil2100: ^^ do you want to review this trivial d-i upload or should I self-accept?
[20:24] <sil2100> vorlon: I'll just glance it real quick
[20:25] <sil2100> ahaha
[20:25] <sil2100> Ok
[20:25] <sil2100> Forgot it's just the rebuild, ugh
[20:26] -queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (focal-proposed) [20101020ubuntu614.2]
[20:29] <sil2100> vorlon: could you also have a second look at https://code.launchpad.net/~xnox/debian-cd/hwe-focal/+merge/397181 ? You feel more comfortable in debian-cd - to me it seemed fine with just one stupid inline question
[20:30] <vorlon> darn, I was hoping you wouldn't ask ;)
[20:30] <vorlon> yes, I'll look
[20:32] <sil2100> Thanks ;) I'd merged it if not for my worry about those HWE entries for desktop suddenly appearing
[20:35] <sil2100> s/merged/merge
[20:46] <vorlon> sil2100: bleurgh, ftbfs
[20:46] <vorlon> (d-i)
[20:46] <vorlon> I'll chase it up after the debian-cd review unless you want to look at it
[20:53] <vorlon> lolwut, xfsprogs upstream regressed its architecture support and now ftbfs on riscv64
[20:56] <vorlon> sil2100: addressed your open question on the hwe mp; doing a more thorough review now
[20:56] <vorlon> also I really want to change this code to say "KERNEL_PREFICES"
[20:58] -queuebot:#ubuntu-release- Packageset: Added p7zip to i386-whitelist in hirsute
[20:58] -queuebot:#ubuntu-release- Packageset: Added rpm to i386-whitelist in hirsute
[21:02] <xnox> sil2100:  so i don't think anything will appear on desktop; as we only ever set KERNEL_PREFIX to more than one value, if PROJECT is ubuntu-server, on top of the file.
[21:06] <juliank> vorlon: eww, KERNEL_PREFICES is just wrong
[21:06] <vorlon> ;)
[21:07] <juliank> it's an interesting word because you'd think it's like matrix, but it isn't
[21:08] <juliank> the plural of praefixum being praefixa
[21:08] <juliank> latin weird
[21:09] <vorlon> juliank: cool, didn't know that, just was enjoying making the false analogy
[21:11] <juliank> vorlon: for some reason prefices, was popular-ish in the 70s/80s: https://books.google.com/ngrams/graph?content=prefices&year_start=1800&year_end=2000&corpus=15&smoothing=3&share=&direct_url=t1%3B%2Cprefices%3B%2Cc0#t1%3B%2Cprefices%3B%2Cc0
[21:11] <juliank> well just late 70s really
[21:12] <sil2100> xnox: got it!
[21:16] <vorlon> xnox: TAR_IMAGES="$TAR_IMAGES ${!kp}netboot/netboot.tar.gz" but I don't see that hwe-netboot/netboot.tar.gz ever exists, or even hwe-cdrom/initrd.gz, what gives?
[21:16] <vorlon> xnox: without that, this debian-cd change seems less useful?
[21:17] <vorlon> sil2100: ^^
[21:18] <vorlon> d-i build failure: "Disk full' on mcopy -i./tmp/netboot/boot.img ./tmp/netboot/initrd.gz ::initrd.gz :P
[21:20] <sil2100> Another FLOPPY_SIZE bump?
[21:20] <vorlon> yeah
[21:23] <sil2100> Test building with a 5MB bump in a PPA
[21:23] <vorlon> sil2100: so you'll take care of this change?
[21:24] <sil2100> vorlon: I can!
[21:25] <vorlon> sil2100: might want to also wait for xnox to respond wrt the missing hwe-* trees under installer-$arch in the archive before uploading
[21:26] <sil2100> I thought those are not really used right now, that was my understanding when I talked with xnox - that they're just checked, downloaded and then the casper bits are used?
[21:26] <sil2100> Since in the morning I wanted to prep the d-i hwe additions already, have even an almost-done package
[21:27] <vorlon> sil2100: so this code would only be used for legacy ISOs which we no longer build; in which case, why not kill this code instead of adding an additional if block?
[21:34] <sil2100> vorlon: it's probably absurd but I think we want to be as safe as possible ;p Guess we could kill it, but I personally feel better not removing code just-in-case - silly
[21:34] <vorlon> sil2100: whereas I feel better not having additional dead and broken code branches as future pitfalls :)
[21:41] <sil2100> hah, I think we can remove it in that case ;) But it does make me feel uneasy!
[22:20] <cking> sil2100, what was the status of the zfsutils-linux and grub being blocked in proposed?
[22:25] <sil2100> Let me try that now
[22:27] <cking> thanks
[22:29] <sil2100> vorlon: since I built that d-i successfully in a bileto PPA, I guess I can just bin-copy it over to focal-proposed to save build time, right?
[22:29] -queuebot:#ubuntu-release- Unapproved: debian-installer (focal-proposed/main) [20101020ubuntu614.2 => 20101020ubuntu614.3] (core) (sync)
[22:48] <vorlon> sil2100: yes
[22:58] -queuebot:#ubuntu-release- Unapproved: accepted debian-installer [sync] (focal-proposed) [20101020ubuntu614.3]
[23:00] <sil2100> xnox, vorlon: ok, I need to EOD now, but I'll be back tomorrow - can you sort out the debian-cd merge? I guess we could take xnox's change and just remove that unused block of code
[23:03] <vorlon> sil2100: yeah I can follow through
[23:12] <sil2100> Thank you o/ If anything needs doing just drop me a msg on mm
[23:23] -queuebot:#ubuntu-release- New binary: gevent-websocket [amd64] (hirsute-proposed/universe) [0.10.1-4] (no packageset)
[23:26] -queuebot:#ubuntu-release- New: accepted adios [amd64] (hirsute-proposed) [1.13.1-27]
[23:26] -queuebot:#ubuntu-release- New: accepted adios [armhf] (hirsute-proposed) [1.13.1-27]
[23:26] -queuebot:#ubuntu-release- New: accepted adios [riscv64] (hirsute-proposed) [1.13.1-27]
[23:26] -queuebot:#ubuntu-release- New: accepted adios [arm64] (hirsute-proposed) [1.13.1-27]
[23:26] -queuebot:#ubuntu-release- New: accepted gevent-websocket [amd64] (hirsute-proposed) [0.10.1-4]
[23:27] -queuebot:#ubuntu-release- New: accepted adios [ppc64el] (hirsute-proposed) [1.13.1-27]
[23:27] -queuebot:#ubuntu-release- New: accepted adios [s390x] (hirsute-proposed) [1.13.1-27]
[23:27] -queuebot:#ubuntu-release- New: accepted linkchecker [arm64] (hirsute-proposed) [10.0.0-1]
[23:27] -queuebot:#ubuntu-release- New: accepted linkchecker [ppc64el] (hirsute-proposed) [10.0.0-1]
[23:27] -queuebot:#ubuntu-release- New: accepted linkchecker [s390x] (hirsute-proposed) [10.0.0-1]
[23:27] -queuebot:#ubuntu-release- New: accepted linkchecker [amd64] (hirsute-proposed) [10.0.0-1]
[23:27] -queuebot:#ubuntu-release- New: accepted linkchecker [riscv64] (hirsute-proposed) [10.0.0-1]
[23:27] -queuebot:#ubuntu-release- New: accepted linkchecker [armhf] (hirsute-proposed) [10.0.0-1]


[00:50] <mgi> What alternatives to MAAS + juju are there with Ubuntu? For installing and maintaining a cluster of Ubuntu nodes.
[00:53] <andol> mgi: A traditional preseeded PXE install, handing over to something like Puppet?
[00:53] <andol> (Which by no means is an Ubuntu specific answer.)
[00:53] <mgi> Yeah, that's fine, I'm not after Ubuntu specific, just Ubuntu-enabled :)
[00:53] <mgi> (as in, I'd rather not use rocks)
[00:55] <mgi> So, does Puppet do the actual install for you?
[00:55] <mgi> (just reading the site now)
[00:55] <andol> mgi: No, Puppet needs an existing (basic) os install to run off.
[00:56] <mgi> So I need to deploy Ubuntu (or whatever OS) to all the compute nodes first?
[00:57] <andol> mgi: Yepp, for example using a preseeded install
[00:57] <andol> https://help.ubuntu.com/12.04/installation-guide/amd64/appendix-preseed.html
[00:57] <mgi> Ah brilliant, I think that's what I was looking for.
[00:58] <mgi> I've never done preseeding before - and will read the docs now - but before I get too excited, is this a valid approach for installing up to 80 nodes?
[00:59] <andol> mgi: Can't see why not. Even with a limited number of server it is still nice to have the install automated, making it easy to reinstall broken nodes, etc.
[00:59] <mgi> Yeah, cool. I guess my other option is to install them all using MAAS and then use Puppet after that.
[01:00] <andol> mgi: Well, even with a preseeded install I think you will just want to use the preseeds for the basic, and then hand of to Puppet as a final stage.
[01:00] <mgi> Ok, sounds good. Thanks!
[01:01] <andol> mgi: Both because it is easier to do a lot of the detailed configuration in Puppet, and because it is a good thing to have as much as possible controlled by Puppet, when you need to roll out configuration changes on existing nodes.
[01:02] <mgi> Yeah, Puppet sounds like a good way to manage anything beyond the bare-bones install.
[01:11] <uvirtbot`> New bug: #1023729 in maas "maas-import-isos requires wget, but maas has no wget dependency" [Undecided,Confirmed] https://launchpad.net/bugs/1023729
[05:16] <stgraber> hallyn: it's late here so I won't investigate until tomorrow, but it looks like containers spawned through the API fail to reboot (they just die)
[07:08] <RpqDcpuwA> does ubuntu server comes with LAMP plus ssl? and send and recieve mail functions?
[07:27] <RoyK> hi all. I have a home server that used to have a mirrored root, but only has a single drive now (one of the two). This means the mirror is "broken" - how can I remove the missing drive from the mirror to shut up mdadm monitoring? http://paste.ubuntu.com/1094469/ <-- this is how it looks today
[08:05] <ivoks> RoyK: it's rebuilding right now
[08:05] <ivoks> RoyK: look at mdadm --fail
[08:05] <ivoks> example: mdadm --fail /dev/md0 /dev/sda1
[08:06] <RoyK> ivoks: that works well if you have a device name to give mdadm - I don't
[08:07] <ivoks> then replace the disk, it's already marked as failed
[08:07] <RoyK> I don't want to replace it
[08:07] <ivoks> oh, now i get it
[08:07] <ivoks> i want to kill raid
[08:07] <RoyK> no, not kill the raid
[08:08] <RoyK> just reduce the number of mirror copies to one
[08:08] <RoyK> linux supports "mirrors" with only one side
[08:08] <ivoks> mdadm /dev/mdX --grow --force -n 1
[08:10] <RoyK> whee - thanks!
[08:10] <RoyK> then all I need to do is find the missing spare in md0
[08:16] <babyface_> Jamespage, ping
[08:16] <jamespage> babyface_, morning
[08:17] <babyface_> jamespage, good morning, James
[08:17] <babyface_> jamespage, how about the tomcat bug?
[08:17] <babyface_> Jamespage, when will it be  fixed?
[08:18] <jamespage> babyface_, so I noticed - although this is actually a test failure rather than related to last weeks issue with MIR's etc...
[08:18] <jamespage> I will look at it now
[08:18] <babyface_> Jamespage, ok, thanks.
[09:03] <jamespage> babyface_, hey - so I could not reproduce the issue seen in the daily ISO test - I re-ran and it cleared itself
[09:03] <jamespage> babyface_, this may actually point to a bug; but I'm not sure what it is yet
[09:03] <jamespage> it looks like the control port on 8005 for tomcat7 is not listening when the test executes....
[09:20] <jamespage> babyface_, I notice that the amd64 version was also doing it three days OK - but has also cleared...
[09:20] <jamespage> odd
[09:26] <RoyK> stgraber: ping
[09:30] <jamespage> apw, smb: where can I discover which modules are built for arm/omap4?
[10:34] <RoyK> jamespage: there is another channel, #ubuntu-arm, that might be appropriate for arm questions
[10:35] <jamespage> RoyK, I'll try there instead...
[10:57] <RoyK> anyone here tried to setup kvm on multiple hosts with shared storage?
[11:06]  * RoyK gives up and installs CentOS :þ
[11:12] <RoyK> hrm
[11:13] <RoyK> anyone with an idea of why the iscsi initiator on these servers fail to connect to their LUN on bootup, but why it works just after reboot with a simple iscsiadm -m node -l ?
[11:22] <ivoks> on which servers?
[11:23] <pmatulis> RoyK: i guess you need to tell the initiator to log in upon bootup?
[11:26] <RoyK> pmatulis: normally it should
[11:27] <RoyK> pmatulis: I've setup this before, similar setup, but other targets, and once setup and logged in, it should do so automatically on bootup, but something may be timing out - dunno
[11:27] <RoyK> we're not using any fancy authentication, just matching an autogenerated target name
[11:27] <ivoks> is mounting done before iscsid is started?
[11:28] <RoyK> it really shouldn't
[11:28] <RoyK> but I don't know upstart that well
[11:28] <RoyK> it's just basic 12.04
[11:30] <ivoks> so, it's not /-on-iscsi?
[11:30] <RoyK> no, root is on a local mirror
[11:31] <RoyK> on both nodes
[11:31] <RoyK> but they're supposed to share a volume on a SAN with OCFS2 for VM storage
[11:31] <ivoks> and, once system boots, you can easily mount the the target?
[11:31] <RoyK> after I've logged into the lun with the above command, but it doesn't show up before that - but w8... think I found something
[11:33] <Pupeno_W> Which MTA do you recommend for a server that only sends email? so that cron, for example, can send emails?
[11:34] <RoyK> !postfix
[11:34] <Pupeno_W> Thanks.
[11:36] <RoyK> ivoks: hrmf - seems node.startup in /etc/iscsi/iscsid.conf was set to manual, by default. However, changing it to 'automatic' didn't change anything - the iscsi LUN isn't in /proc/partitions after bootup, and really, it should be
[11:39] <nokia> newbie. Can someone explain how to change Ubuntu Server to a static ip address, the default installation set it to dhcp.
[11:40] <RoyK> nokia: edit /etc/network/interfaces - set it to static - google that for more info ;)
[11:40] <RoyK> !interfaces
[11:41] <nokia> RoyK every time i reboot my asdl router all MY PC's Laptop's and Server ip's change. How do i make them all have same STATIC ip address's.
[11:52] <pmatulis> RoyK: i remember having to configure each lun individually for automatic login
[11:53] <RoyK> hrmf - seems it now works on node1, but not on node2, configured the same
[11:54] <RoyK> iscsiadm -m discovery <cr> shows my sendtarget, iscsiadm -m node<cr> shows my target '<IP_ADDRESS>:3260,1 iqn.2001-05.com.equallogic:0-8a0906-79b9aec05-128001a0ef84ffff-kvm-test-vol1', but it's not logged in
[11:55] <RoyK> hm... and dmesg tells me eth1 was started ~3 seconds after iscsi
[11:56]  * pmatulis facepalm
[11:56] <RoyK> ?
[11:57] <RoyK> pmatulis: I didn't set the order...
[11:57] <pmatulis> well, network is needed before iscsi right?
[11:57] <RoyK> I would think so...
[11:57] <RoyK> so... smells like a good old byg
[11:58] <pmatulis> so it was a 'buntu facepalm, not a RoyK facepalm
[11:58] <RoyK> :)
[11:58] <pmatulis> and i've seen this kind of bug before, so prolly a regression.  but no one else running iscsi on 12.04?
[11:59] <RoyK> node.conn[0].timeo.login_timeout was set to 15 - trying 60...
[11:59] <pmatulis> ah ok
[12:02] <RoyK> these dell machines spend like 3-5 minutes just to POST
[12:04] <RoyK> duh
[12:04] <RoyK> increasing timeout to 60 didn't help
[12:05] <zul> good morning
[12:06] <uvirtbot`> New bug: #1006738 in php5 (main) "php5-fpm segfaults with error 4 in libc-2.15.so" [Low,New] https://launchpad.net/bugs/1006738
[12:07] <ivoks> pmatulis: i have iscsi on 12.04
[12:08] <ivoks> but i set networking within initramfs, so i doubt that counts :)
[12:08] <pmatulis> bingo
[12:08] <pmatulis> :)
[12:08] <ivoks> but
[12:08] <ivoks> iscsi is restarted once network interface is up, so that shouldn't be a problem
[12:09] <ivoks> if you look at /etc/network/if-up.d/, you'll see iscsi bits and pieces
[12:09] <ivoks> it's a link to /etc/init.d/open-iscsi, iirc
[12:10] <ivoks> questions are... do you have multiple interfaces? does restarting open-iscsi works once system is booted?
[12:17] <RoyK> hrmf - bug 1025240
[12:17] <uvirtbot`> Launchpad bug 1025240 in open-iscsi "iscsid is started before networking" [Undecided,New] https://launchpad.net/bugs/1025240
[12:17] <ivoks> RoyK: your bug is invalid
[12:17] <ivoks> RoyK: open-iscsi is restarted after the interface is set up
[12:18] <ivoks> the fact that iscsiadm works is a proof
[12:18] <ivoks> iscsiadm wouldn't work if iscsid isn't running
[12:19] <RoyK> hm... then why doesn't it connect to its LUN?
[12:20] <ivoks> why do you think it's not connected? you don't see /dev/sdX?
[12:20] <RoyK> nothing in /proc/partitions
[12:20] <RoyK> which is a rather good indication ;)
[12:20] <RoyK> if I login manually, it shows up there
[12:21] <uvirtbot`> New bug: #1025239 in ipxe (main) "kvm-ipxe does not support https" [Undecided,New] https://launchpad.net/bugs/1025239
[12:27] <ivoks> so, concentrate debugging on 'why isn't discovery done automatically'
[12:27] <ivoks> not on 'iscsi is started before networking'
[12:28] <RoyK> I am
[12:28] <RoyK> but discovery looks ok
[12:28] <RoyK> everything is reported correctly
[12:28] <RoyK> but it doesn't login to the target
[12:33] <RoyK> ivoks: heh - check the bug again :-þ
[12:33] <ivoks> there you go
[12:35] <patdk-wk> I just wish the installer would stop changing the iscsi name so many times during the install
[12:36] <RoyK> ivoks: it would be rather nice if that stuff was documented, though
[12:46] <glosoli> hey folks I setuped ubuntu server and openerp in it, I watn somehow to access it from remote distance, not sure how to do it, for example as I have wifi on same internet, and I go to the ip and port it simply doesn't show anything
[12:46] <glosoli> any udw
[12:46] <glosoli> any uide
[12:46] <glosoli> ideas""
[12:48] <hallyn> stgraber: the reboot logic was wrapped around the core start, so that's conceivable.
[13:11] <uvirtbot`> New bug: #724616 in ceph (main) "not lintian clean" [Wishlist,Triaged] https://launchpad.net/bugs/724616
[13:21] <toshko> hi, I'm not sure this is the channel, but I will ask you: I use Ubuntu 12.04 server for host and guest and have QCOW2 images for the guest. The problem is that with initial "virtual" size of 10GB, now the image is with physical/disk size of 15GB. This is causing me out of space problems all the time. Can anyone tell me if this behaviour is normal. How should I limit the file size of the image???
[13:22] <toshko> You can have a look here for more info: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1025244
[13:22] <uvirtbot`> Launchpad bug 1025244 in libvirt "qcow2 image increasing disk size above the virtual limit" [Undecided,New]
[13:26] <uvirtbot`> New bug: #961389 in txlongpoll (main) "[MIR] txlongpoll" [High,In progress] https://launchpad.net/bugs/961389
[13:30] <stgraber> hallyn: yeah, I guess that makes sense. I'm kind of surprised I haven't tried it before though :) How much pain will that be to fix it?
[13:30] <stgraber> hallyn: I don't have anything relying on reboot in those containers yet, but that probably won't be the case for long
[13:39] <hallyn> stgraber: not sure.  lemme finish verifying libvirt on precise sru then i'll take a look
[13:39] <stgraber> sure, no hurry. thanks
[13:58] <hallyn> hm, just updated from precise-updates to precise-proposed, and ssh now takes a loooot longer to get in
[14:00] <Daviey> hallyn: check dns resolution still works
[14:00] <Daviey> hallyn: the most common reason for slow logins is broken dns resolution of the client from the server
[14:00] <Daviey> reverse dns
[14:00] <hallyn> Daviey: it doesn't seem to, but i don't understand why
[14:00] <hallyn> doesn't seem to be part of what was updated
[14:02] <hallyn> oh.  heh.  maybe i see the problem.
[14:10] <zul> jamespage: hey did you check openvswitch on arm?
[14:38] <jamespage> zul, won't work yet as openvswitch module is not built with the kernel
[14:39] <zul> thats what i thought
[14:39] <jamespage> zul, hit the same thing with ceph rbd today as well BTW
[14:39] <jamespage> rbd is also not built as far as I can tell
[14:49] <jamespage> zul, actually that was only the case for omap4 - its enabled for all other ARM targets
[14:52] <zul> so highbank should work?
[14:56] <uvirtbot`> New bug: #1020603 in quantum (universe) "[MIR] quantum" [High,New] https://launchpad.net/bugs/1020603
[15:12] <motorcity> anyone here?
[15:14] <hallyn> if a bug gets marked 'invalid', it doesn't show up in LP searches right?
[15:16] <Daviey> hallyn: correct, but you should be able to search in an advanced search for it
[15:18] <zul> hallyn: what did you have to do for libvirt permissions?
[15:19] <hallyn> zul: I had to chown /var/lib/libvirt/images to libvirt-qemu:kvm and make it group readable
[15:19] <hallyn> but i notice that on precise it isn't like that either
[15:23] <adac> Hi guys. We had ldap auth via ssh on our server, but now want to move back to "normal" ssh authentication. Any odeas whcih files I need to change?
[15:24] <th0mz> adac: etc/pam.d/sshd ?
[15:25] <hallyn> zul: right now it seems to be working for me.  <boggle>
[15:25] <adac> th0mz, I thougt maybe: /etc/pam.d/common-auth
[15:25] <adac> but I'm unsure
[15:26] <adac> th0mz, curretnly looks like this:
[15:26] <adac> cat /etc/pam.d/common-auth
[15:26] <adac> auth    sufficient      pam_ldap.so
[15:26] <adac> auth    required        pam_unix.so use_first_pass nullok_secure
[15:27] <hallyn> zul: ah i think it just needs go+x
[15:29] <hallyn> zul: I'm guessing libvirt-bin.postinst no longer does chmod 711 ${ROOT_DIRS}  (checking)
[15:31] <hallyn> hm, it says it does
[15:34] <armaan> Problem in setting up openldap? Getting this errro :ldap_bind: Invalid credentials (49)
[15:52] <hallyn> zul: d'oh!  when i just install libvirt-bin, the perms are right
[15:52] <zul> hallyn: so its an upgrade issue then
[15:54] <hallyn> zul: no,
[15:54] <hallyn> zul:  i think libvirt is doing it itself
[15:54] <koolheadd17> armaan, hey there
[15:55] <koolheadd17> adam_g, ping
[16:01] <uvirtbot`> New bug: #1025336 in php5 (main) "installing php5-curl reloads apache *before* it's set up" [Undecided,New] https://launchpad.net/bugs/1025336
[16:03] <armaan> koolheadd17: hey...
[16:06] <hallyn> zul: steps so far to reproduce.  spin a new instance.  install libvirt-bin.  ls -l /var/lib/libvirt -> images looks good.  now connect with virt-manager as a user.  images dir is no longer good
[16:06] <koolheadd17> armaan, the document did not help you to configure ldap
[16:06] <koolheadd17> ?
[16:06] <hallyn> checking to see if it's libvirt itself, or virt-manager
[16:06] <armaan> koolheadd17: Nope
[16:06] <armaan> koolheadd17: got the same error
[16:06] <koolheadd17> armaan, can you do one thing
[16:06] <armaan> koolheadd17: ??
[16:06] <koolheadd17> setup a fresh instance
[16:06] <koolheadd17> and try everything from scratch on that
[16:07] <koolheadd17> if u get same error
[16:07] <armaan> koolheadd17: already did it last night.
[16:07] <zul> hallyn: maybe there is something in virt-manager that needs to updating
[16:07] <koolheadd17> dont forget to file a bug
[16:07] <koolheadd17> armaan, file a bug dude
[16:07] <hallyn> zul: could be.
[16:08] <armaan> koolheadd17: i think i have to do it now.
[16:08] <RoyK> hallyn: erm - I have a setup like that
[16:08] <armaan> koolheadd17: do you know someone who might have worked with ldap
[16:08] <hallyn> RoyK: this only seems to affect libvirt on quantal
[16:09] <hallyn> RoyK: results in non-root users being unable to remotely spin up images (unless they use ~/VirtualMachines for storage)
[16:09] <RoyK> quantal?
[16:11] <RoyK> oh
[16:11] <RoyK> hallyn: I usually don't run pre-alpha software on my production machines ;)
[16:12] <koolheadd17> armaan, i was able to get ldap configured without any issue in oneiric
[16:12] <koolheadd17> so am saying
[16:12] <koolheadd17> file a bug
[16:13] <hallyn> RoyK: we're here to make sure it works for you when you switch :)
[16:14] <RoyK> hallyn: good point ;)
[16:14]  * RoyK hardly uses anything but LTS on servers, though
[16:17] <armaan> koolheadd17: okie... i will try once more on a fresh vm if it failed i will file a bug.
[16:22] <koolheadd17> yes sure
[16:23] <bencer> hi guys, we are working on updating the zentyal packages for 12.10, but this is blocking us, any openldap maintainer around that can have a look? https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/82853
[16:23] <uvirtbot`> Launchpad bug 82853 in openldap "Add support for the smbk5pwd overlay" [Wishlist,Confirmed]
[16:26] <hallyn> zul: ok, yeah, virt-manager defines a storage pool, and it ends up with '<mode>0700</mode>' in the xml for it
[16:27] <zul> hallyn: ah hah thought so
[16:27] <hallyn> zul:  i assume libvirt is filling that in as a default.  not sure where we want to fix it
[16:27] <hallyn> zul: gotta run a for bit, bbl
[17:15] <hallyn> zul: all right.  so we could use commit 8a544719aa2fe92332756ea0483844b81d4d56ae which should change the default from 0700 to 0755.  but that's still not quite right :)
[17:16] <hallyn> zul: so we may just want to custom patch it ot make 0711 the default.  not sure
[17:16] <zul> hallyn: up to you
[18:05] <smoser> rbasak, are you around? i was looking at zul's patch at http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/euca2ools/quantal/view/head:/debian/patches/add-armhf-support.patch
[18:05] <smoser> which is now upstream at https://github.com/eucalyptus/euca2ools/commit/b89af8fa79d97a94c033a3d97610035b723f448c
[18:12] <uvirtbot`> New bug: #1006553 in juju "local provider machine agent uses 100% CPU after host reboot" [High,In progress] https://launchpad.net/bugs/1006553
[18:12]  * hallyn goes to check if that's his fault
[18:13] <hallyn> not me
[18:36] <hallyn> zul: mdeslaur: any objection to http://people.canonical.com/~serge/libvirt-perms.debdiff ?
[18:36] <zul> hallyn: nope
[18:40] <hallyn> zul: ok, thanks, will push.  (not *convinced* it's waht we want in the end, is all)
[18:40] <mdeslaur> hallyn: I, uh...not really, if it doesn't break anything
[18:40] <mdeslaur> hallyn: does virt-manager still work if you do that?
[18:41] <hallyn> mdeslaur: without the upstream patch virt-manager is broken.  With just the upstream patch, virt-manager will cause /var/lib/libvirt/images to be 0755 (adding group and world read perms)
[18:41] <hallyn> mdeslaur: yes.
[18:41] <hallyn> mdeslaur: with the upstream patch and the additional one-liner, /var/lib/libvirt/images is back to 0711 as it used to be.
[18:41] <hallyn> the q is,
[18:41] <hallyn> will it confuse other people when they make a new custom storage pool
[18:42] <hallyn> well i'll push this for now.  people can always jsut add the permission tag to their xml if it bothers them
[18:42] <mdeslaur> hallyn: ok
[18:42] <hallyn> mdeslaur: thanks
[18:47] <koolheadd17> Daviey, ping
[19:19] <irv> wehre can i find the shutdown logs from last shutdown?
[19:19] <irv> nfsen is hanging up on shutdown so i want to see if there's any more info
[19:19] <kirkland> utlemming: ping
[19:20] <irv> it's also hanging on startup
[19:31] <hallyn> stgraber: so the reason i hadn't done reboot yet is that lxc_start goes the lazy route - it doesn't clean anything up, just re-execs itself with origina larguments
[19:31] <uvirtbot`> New bug: #1025418 in openssh (main) "Using ProxyCommand w/a non-existant host results in infinite spawns." [Undecided,New] https://launchpad.net/bugs/1025418
[19:31] <RoyK> irv: should be in dmesg
[19:31] <hallyn> i'm going to see just how much it would take to clean up
[19:31] <RoyK> that's the current, though
[19:32] <RoyK> irv: /var/log/syslog or /var/log/syslog.1 for last one
[19:49] <hallyn> stgraber: yay, the only thing *crucially* needed was closing the /var/lib/lxc/container/command socket.  mind you i'm sure this'll leak memory like a seive for now, but it works
[19:55] <Daviey> koolhead17 keeps missing me :(
[19:59] <hallyn> stgraber: pushed my fix, reboot should now work.
[19:59] <stgraber> hallyn: cool, thanks. Will test later (still need to finish adding get_config_item/clear_config_item)
[20:00] <hallyn> stgraber: hopefully i didnt' mess you up by updating the patch
[20:00] <hallyn> oh, your changes aren't to that patch :)
[20:01] <stgraber> hallyn: yeah, my changes are in debian/python-lxc, you're the only one touching that patch :)
[20:52] <hallyn> lynxman: as the common-law maintainer of ipxe, any comments on bug 1025239 ?
[20:52] <uvirtbot`> Launchpad bug 1025239 in ipxe "kvm-ipxe does not support https" [Medium,Confirmed] https://launchpad.net/bugs/1025239
[21:16] <RamJett> I have a NFS question. In NFS v4. How would I use the UID/GID of the client (passwd/group) to map. I do not even need the server to map user/group ..  I've been using NFS v3 for misc file servers and the server has never mapped the UID/GID ..
[22:06] <stgraber> zul: could you take a look at bug 82853
[22:06] <uvirtbot`> Launchpad bug 82853 in openldap "Add support for the smbk5pwd overlay" [Wishlist,Confirmed] https://launchpad.net/bugs/82853
[22:07] <stgraber> zul: AFAICT the reason not to have smbk5pwd was that we weren't building openldap with heimdal-dev, but nowadays we are, so the delta doesn't make much sense and is preventing some folks like bencer from using the tool
[22:07] <bencer> we need that for zentyal-users, having slapd synced with samba4
[22:07] <zul> stgraber: im not comfortable of adding this for an SRU
[22:08] <stgraber> zul: unless there's some other required build-dependecy that'd need MIRing to enable that, I'd suggest reverting that part of our delta and having that package built and put into universe (so we don't need to MIR extra runtime dependency)
[22:08] <stgraber> zul: never said I want that in an SRU
[22:08] <zul> and i dont really maintain openldap either
[22:08] <bencer> zul: for 12.10
[22:08] <bencer> https://launchpad.net/~zentyal/+archive/2.3/+files/openldap_2.4.28-1.1ubuntu4_2.4.28%2B51~precise1.diff.gz
[22:08] <zul> ok
[22:08] <bencer> didnt check that debdiff
[22:08] <stgraber> zul: bencer is working on samba4 support in zentyal for 12.10 and it's apparently a requirement
[22:08] <bencer> but i was told just enable that on debian/rules and the debian/control stuff
[22:09] <zul> stgraber: well if someone wants to drive that than im fine with it
[22:09] <sokol> Hi, does anyone encounter problem setuping cLVM. When i run vgcreate --clustered y mygrp /dev/sdb it reports it is created succesfully but when i try vgdisplay it says "Skipping clustered volume group..." and lvcreate does the same. am i doing something wrong?
[22:10] <stgraber> bencer: can you give me a debdiff against quantal's current openldap? I can then review and sponsor if that looks good
[22:10] <bencer> stgraber: deal
[23:05] <\sh> anyone familiar with freeipa-client and authentication issues?
[23:27] <koolhead11> hi all
[23:34] <koolhead11> jcastro, where are you ppl?
[23:41] <TheLordOfTime> koolhead11: pateince
[23:41] <TheLordOfTime> we're not around 24/7 :P
[23:47] <koolhead11> TheLordOfTime, :P


[00:16] <sarnold> TJ-: maybe apparmor DENIED messages?
[00:20] <TJ-> sarnold: no, premature user :D
[00:20] <sarnold> aha :D
[00:20] <sarnold> and that's why potentially derailing suggestions are made in another channel, hehe
[00:21] <daftykins> back in my day, volunteers fired as many suggestions at people as possible to see what would stick!
[00:21] <daftykins> ;)
[00:21] <sarnold> aye, with the right person seeking help, that works great
[00:23] <daftykins> xD
[01:09] <lotuspsychje> good morning
[01:17] <sarnold> heya lotuspsychje :) alarm clock set today? :)
[01:17] <daftykins> sorry we're closed! come back at 6am!
[01:17] <lotuspsychje> hey sarnold yeah my bio alarm :p
[01:17] <sarnold> six am! I don't want to go to school today
[01:19] <daftykins> Mischief will let you take a sick day
[01:19] <sarnold> yay
[01:19]  * sarnold shakes snacks
[01:19] <daftykins> :D
[03:02] <marcoagpinto> Heya
[03:12] <oerheks> Hola
[03:24]  * lotuspsychje runs
[03:29]  * oerheks makes coffee, no more sleepy
[03:48] <marcoagpinto> let me grab my cola bottle
[03:48] <marcoagpinto> :p
[03:49] <lotuspsychje> oO
[03:49] <lotuspsychje> dont forget 'sugar the silent killer' is in that can
[03:50] <oerheks> cane sugar is not that bad
[03:51] <lotuspsychje> yeah i use that in my coffee oerheks
[03:53] <oerheks> want some water? https://www.buienradar.nl/
[03:53] <oerheks> shampoo in your hair, and step outside
[03:55] <marcoagpinto> yesterday my new UPS was delivered
[03:55] <marcoagpinto> the old one got damaged, so I bought a new one and it came damaged too :(
[03:55] <marcoagpinto> I got so stressed
[03:56] <marcoagpinto> but the delivery guy replaced it yesterday and now it works
[03:56] <daftykins> damaged by cola?
[03:56] <marcoagpinto> UPS Back-UPS 850 VA
[03:56] <marcoagpinto> no, the battery didn't fill
[03:57] <daftykins> didn't try just replacing the battery?
[03:57] <marcoagpinto> I connected it to the wall but it was beeping saying it had no energy
[03:57] <marcoagpinto> daftykins: but it was brand new
[03:57] <marcoagpinto> and the old one was some 10 or 15 years old
[03:57] <marcoagpinto> :)
[03:57] <daftykins> yeah i was asking about the old one
[03:57] <marcoagpinto> it was about time I bought a more recent one
[03:58] <marcoagpinto> daftykins: the warranty was 3 years and it lasted some 10 or 15
[03:58] <marcoagpinto> it was more than time to buy a new one
[03:59] <marcoagpinto> the old one was heavy as hell
[03:59] <marcoagpinto> this one has more power and it is lighter
[03:59] <marcoagpinto> a lot lighter
[03:59] <marcoagpinto> ~5 KG
[06:52] <lordievader> Good morning
[07:17] <ducasse> good morning
[16:00] <lotuspsychje> https://ubuntu.com//blog/help-us-chart-the-ubuntu-community-roadmap