[00:01] <nagappan> jtatum, have you created a deb package for python project ?
[00:01] <nagappan> jtatum, I'm planing to create Ubuntu 9.04 package for LDTPv2
[00:02] <jtatum> nagappan: It's pretty simple if there is a working setup.py.
[00:02] <nagappan> jtatum, not sure, how to create the diff.gz
[00:02] <nagappan> jtatum, awesome :)
[00:02]  * nagappan listening jtatum
[00:02] <nagappan> {}
[00:02] <jtatum> nagappan: just a sec, let me power on that vm
[00:02] <nagappan> jtatum, sure
[00:04] <jtatum> nagappan: did you already setup the debian dir?
[00:04] <nagappan> jtatum, nope
[00:04] <nagappan> jtatum, http://cgit.freedesktop.org/ldtp/ldtp2/
[00:07] <jtatum> nagappan: ok, pulling it down
[00:09] <nagappan> jtatum, ok
[00:12] <jtatum> nagappan: lol. firewall here does not allow it :) that's OK though. you need a debian dir. to bootstrap it, change to a temp directory and apt-get source mago
[00:14] <nagappan> jtatum, sure
[00:15]  * nagappan doing now
[00:15] <nagappan> jtatum, mago not available on Ubuntu 9.04 I think ?
[00:16] <jtatum> nagappan: ah, you're right. that's ok, we can just pastebin everything
[00:16] <nagappan> jtatum, :)
[00:16] <nagappan> jtatum, I actually tried and I got the error "E: Unable to find a source package for mago", then realized that ara built it only for Karmic :)
[00:16] <jtatum> nagappan: i assume you have the source for ldtp2 somewhere. in the root of that directory, create a dir named debian. we'll just add the handful of needed files.
[00:17] <nagappan> jtatum, sure
[00:17] <nagappan> jtatum, done
[00:17] <nagappan> jtatum, next
[00:17] <nagappan> {}
[00:18] <jtatum> nagappan: a couple of lines to throw in .bashrc - export<EMAIL_ADDRESS>[00:18] <jtatum> export DEBFULLNAME="Naggapan"
[00:18] <nagappan> jtatum, sure
[00:19] <nagappan> jtatum, you know, actually I use openSUSE build service for building Ubuntu / Debian / SUSE / RedHat based LDTP package, so I guess I don't need this entry !?!
[00:20] <nagappan> jtatum, http://download.opensuse.org/repositories/home:/anagappan/
[00:20] <jtatum> hm. not sure. dch reads it for sure, and I think other things will as well, for instance if you are going to upload it to a PPA
[00:20] <nagappan> jtatum, ok
[00:20] <jtatum> that's interesting though, not familiar with the opensuse builder
[00:21] <jtatum> ok. your source dir should be named something like ldtpv2-0.99.whatever
[00:21] <jtatum> package-version
[00:21] <nagappan> jtatum, I grabbed ldtp dsc from Debian and uploaded to there and it build the package for me
[00:21] <jtatum> neat
[00:21] <nagappan> jtatum, sure
[00:21]  * nagappan renaming the folder
[00:23] <nagappan> jtatum, done
[00:23] <jtatum> inside that directory, run dch --create --package ldtpv2 -v 0.99.whatever --distribution jaunty
[00:24] <nagappan> jtatum, sure
[00:24] <jtatum> the changelog has kind of a prickly format. if you're happy with the single bullet, it should be ok. if you want to add more stuff, you probably want to read one of the packaging guides.
[00:24]  * nagappan installing devscripts package
[00:25] <jtatum> :) thank you command-not-found for catching my mistake :)
[00:28] <nagappan> jtatum, :)
[00:28] <jtatum> nagappan: should have debian/changelog after running dch. next, debian/control. http://pastebin.com/m4ee4fbac <- mago's control file
[00:29] <nagappan> jtatum, yes, it has created the file debian/changelog
[00:29] <jtatum> The control file describes the source package and the resulting binary package. so you'll want to s/mago/ldtpv2, remove XSBC-Original-Maintainer (this is for uploading stuff to ubuntu proper), change maintainer to you
[00:30]  * nagappan doing debian/control
[00:30] <jtatum> The depends may need some tweaking. The system detects depends from setup.py, but you can specify others here if they get missed.
[00:31] <jtatum> for now you probably want Depends: ${misc:Depends}, ${python:Depends}
[00:31] <jtatum> remove line 14
[00:33] <nagappan> jtatum, I want to remove ldtpv1 if its installed
[00:33] <nagappan> jtatum, guess conflict
[00:33] <nagappan> jtatum, is the tag ?
[00:33] <jtatum> yes. also your binary package (line 11) should probably be python-ldtpv2
[00:33] <jtatum> to stay consistent with other py libs
[00:34] <nagappan> jtatum, sure
[00:36] <jtatum> debian/rules - http://pastebin.com/mc0748d6
[00:36] <nagappan> jtatum, control file created
[00:36] <nagappan> jtatum, let me create rules now
[00:37] <nagappan> jtatum, we don't have man page for now
[00:37] <jtatum> a lot of magic happens here. cdbs automates a lot of junk. in ye olden days, this rules file would be long and complicated to behold :)
[00:37] <jtatum> right, remove that line
[00:37] <nagappan> jtatum, can I ignore this ?
[00:37] <nagappan> jtatum, ok
[00:38] <nagappan> jtatum, done
[00:38] <jtatum> echo 7 > debian/compat
[00:39] <nagappan> launchpad.net is up now !!!
[00:39]  * nagappan creating compact file
[00:39] <jtatum> echo 2 > debian/pycompat
[00:39] <nagappan> jtatum, done, both the files
[00:40] <jtatum> one more file, copyright. checking to see if it's required.
[00:40] <nagappan> jtatum, sure
[00:42] <jtatum> easier to just create I guess. debian/copyright: http://pastebin.com/m764af635
[00:42] <jtatum> (didn't paste the whole GPL)
[00:44] <jtatum> I forgot an important step. the orig tar file. mv the debian directory somewhere outside your source directory.
[00:44] <jtatum> we need to create a .tar.gz that includes only your source, not the debian dir
[00:45] <jtatum> so if the dir is ldtpv2-0.99.0. you'll want to tar -czvf ldtpv2_0.99.0.orig.tar.gz <-- note the - changes to an _ in the orig
[00:46] <jtatum> the packaging tools are dash and underscore sensitive :)
[00:46] <jtatum> they'll magically detect this orig file and use it to create the changes file
[00:49] <jtatum> nagappan: ^^
[00:49] <nagappan> jtatum, sure, just saw the above message
[00:50] <nagappan> jtatum, we have LGPL
[00:50] <nagappan> jtatum, will get it from LDTPv1
[00:50] <jtatum> that's fine :)
[00:53] <nagappan> jtatum, created copyright file
[00:53] <jtatum> nagappan: ok
[00:55] <nagappan> jtatum, I have the source file created using python setup.py sdist, is that okay ?
[00:55] <nagappan> jtatum, now whats the next step ?
[00:56] <jtatum> nagappan: that should be OK. did you create the .orig.tar.gz ?
[00:59] <nagappan> jtatum, just rename that file should be good ?
[00:59] <nagappan> jtatum, which was created by python setup.py sdist ?
[00:59] <jtatum> i would suggest creating a new one.
[01:00] <jtatum> you want to capture your ldtpv2-whatever dir as it is now, including any .git or whatever directories might be in it
[01:00] <nagappan> jtatum, nope, sdist doesn't create them
[01:00] <jtatum> that is a problem
[01:00] <nagappan> jtatum, what ever we have mentioned in MAINFEST, it will create
[01:00] <jtatum> nagappan: otherwise, when you copy the debian folder in, and run the scripts to build the .dsc and .changes file, it will create diffs for a whole bunch of junk
[01:01] <nagappan> jtatum, ah ! ok
[01:02] <nagappan> jtatum, I have created the tar.gz
[01:02] <nagappan> jtatum, tar the complete folder
[01:02] <jtatum> ok. move the debian dir back in, change into the dir and run debuild -S -sa
[01:02] <nagappan> jtatum, sure
[01:04] <jtatum> curious to hear what errors if any come up :)
[01:04] <nagappan> jtatum, I get http://pastebin.com/d4290ccbc
[01:04] <jtatum> lintian is invoked against your package as well
[01:05] <jtatum> nagappan: ah, need apt-get install cdbs
[01:05]  * nagappan installing cdbs as suggested by jtatum :)
[01:06] <jtatum> it's also going to sign all your packages. it should pull your email address from changelog and it will feed that to gpg, so if you're prompted for a keyphrase by debuild, it's for your gpg key
[01:08] <nagappan> jtatum, http://pastebin.com/d6f9206cc I get different error
[01:09] <jtatum> pastebin debian/control, please?
[01:09] <jtatum> i think this is probably dir naming, nagappan
[01:10] <nagappan> jtatum, http://pastebin.com/d1c59467b
[01:10] <nagappan> jtatum, ah ! ok
[01:10] <jtatum> directory should be ldtpv2-2.0.1
[01:10] <jtatum> Source: should be ldtpv2
[01:10] <nagappan> jtatum, let me change it now
[01:10] <jtatum> oh - sorry
[01:10] <jtatum> ldtp2
[01:10] <jtatum> source: and directory name should agree
[01:11] <jtatum> also don't forget to rename .orig.tar.gz
[01:12] <nagappan> jtatum, changing the folder to ldtp2 or ldtpv2 doesn't help
[01:13] <nagappan> jtatum, getting same error message
[01:13] <jtatum> what's folder name?
[01:13] <nagappan> jtatum, ldtpv2, also tried ldtp2
[01:13] <jtatum> the exact folder  name is ldtp2?
[01:13] <jtatum> should be ldtp2-2.0.1
[01:13] <nagappan> jtatum, ah ! ok
[01:13] <jtatum> tar file should be ldtp2_2.0.1.orig.tar.gz
[01:14] <jtatum> first line of debian/control should be Source: ldtp2
[01:14] <jtatum> (leave Package: line as is)
[01:16] <nagappan> jtatum, now a diff error, the above one passed
[01:17] <nagappan> jtatum, gpg: skipped "Nagappan<EMAIL_ADDRESS>secret key not available
[01:17] <nagappan> gpg: [stdin]: clearsign failed: secret key not available
[01:17] <nagappan> debsign: gpg error occurred!  Aborting....
[01:17] <nagappan> debuild: fatal error at line 1250:
[01:17] <jtatum> do you have a gpg key?
[01:17] <nagappan> jtatum, I need to have my gpg pub keys ?
[01:17] <nagappan> jtatum, yes :)
[01:17] <jtatum> you need your pivate key actually :)
[01:17] <nagappan> jtatum, will copy it to my development box
[01:19] <nagappan> jtatum, I have already id_rsa and id_rsa.pub in my ~/.ssh folder
[01:20] <jtatum> those are ssh keys, not gpg
[01:21] <nagappan> jtatum, ah ! my bad, let me get my gpg now
[01:22] <jtatum> you can tack on a -us -uc to skip signing. your build system may or may not think that's important. it also makes a difference at install time. users can trust your gpg key after they add your repo. otherwise, they will get an error.
[01:22] <nagappan> jtatum, I have this http://pgp.mit.edu:11371/pks/lookup?search=nagappan&op=index
[01:22] <nagappan> jtatum, created 2005, forgot about it :) as it was too long
[01:23] <jtatum> nagappan: that's your public key :) guess your private key is lost
[01:23] <jtatum> no worries. try -us -uc
[01:23] <nagappan> jtatum, sure
[01:23] <jtatum> can always rebuild and sign it later
[01:24] <jtatum> so that should generate the .dsc and .changes, which you'll feed to your builder. hopefully it builds :)
[01:25] <nagappan> jtatum, sure, thanks :)
[01:26] <jtatum> nagappan: np :) heading home, afk a bit
[01:26] <nagappan> jtatum, sure
[01:26] <nagappan> jtatum, I get this
[01:26] <nagappan> E: ldtp2 source: missing-build-dependency cdbs
[01:26] <nagappan> W: ldtp2 source: unknown-field-in-dsc original-maintainer
[01:26] <nagappan> jtatum, will add cdbs
[01:26] <jtatum> nagappan: from your builder?
[01:27] <nagappan> jtatum, from this debuild -S -sa -us -uc
[01:27] <jtatum> nagappan: hm... ah. yes, cdbs needs to be one of the build-depends
[01:29] <nagappan> jtatum, ok, fixed most of the warnings
[01:29] <jtatum> nagappan: great! the original maintainer can be ignored or removed from control, it's not necessary for a private package
[01:29] <nagappan> jtatum, ok
[01:30] <rmcbride> nagappan: your bug number is 435570. I'm trying to get the log attached but firefox is not cooperating (or maybe it's the new LP drop)
[01:30] <nagappan> rmcbride, sure, thanks :)
[01:31] <rmcbride> nagappan: I'm going to leave my browser spinning for a bit and then I'll restart it and tretry the attach
[01:32] <nagappan> rmcbride, sure, thanks :)
[01:32] <nagappan> jtatum, thanks for guiding this layman :)
[01:33] <jtatum> nagappan: in case your builder gives you trouble, you may want to google pbuilder. it's a pretty great build system for debian/ubuntu which creates a full chroot, installs build depends and builds in a very clean environment, then spits out the binaries.
[01:33] <jtatum> nagappan: no problem :) my pleasure :)
[01:33] <nagappan> jtatum, sure
[01:47] <rmcbride> nagappan: Ah, either you're not behind a firewall/proxy anymore or the problem was the LP update teh whole time I guess :)
[01:48] <rmcbride> just saw your comment once my browser started talking again
[01:48] <nagappan> rmcbride, I can access the web through proxy, but apport-cli could not upload the logs, as it doesn't understand https proxy
[01:49] <rmcbride> nagappan: AH! OK
[01:49] <rmcbride> nagappan: I'm going to be out the rest of the night. I was able to get the apport-cli log attached.
[01:49] <nagappan> rmcbride, that has been fixed in karmic, but the issue here is karmic is not getting installed on this, probably I should try installing karmic on some other box and then report the issue :)
[01:50] <nagappan> rmcbride, cool, thanks :)
[01:50] <rmcbride> nagappan: any time :)
[02:06] <jtatum> nagappan, how's the package look? :)
[02:10] <nagappan> jtatum, oops, I haven't looked at it yet, got into diff work, will look now
[02:10] <nagappan> jtatum, sorry
[02:14] <jtatum> lol, nagappan, no worries :)
[06:44] <ara> good morning all!
[08:37] <davmor2> Morning all
[08:44] <whereisdarran> mornin brotha
[08:44] <whereisdarran> from nz
[08:57] <davmor2> whereisdarran: evening then
[09:15] <whereisdarran> thanks brotha
[09:15] <whereisdarran> how you doin davmor2
[09:15] <davmor2> whereisdarran: sound as a pound you?
[09:16] <whereisdarran> hangin in there
[09:16] <whereisdarran> been under the weather since monday
[09:16] <whereisdarran> but trying to get back on top
[11:40] <ara> popey, ping
[12:00] <davmor2> ara: try popey again now :)
[12:00] <ara> popey, hello :)
[12:01] <davmor2> ara: actually looking at his gmail ac it says he's not here so he must of just signed onto his facebook ac
[12:37] <popey> davmor2: stalker
[12:37] <popey> ara: pong
[12:38] <ara> popey, don't worry. I wasn't having any sound with recordmydesktop, but I asked dholbach and he gave me a script that you had given him
[12:38] <ara> popey, it works now :)
[12:38] <popey> :)
[12:45] <davmor2> popey: not my fault that we are signed up on most of each others accounts :)
[13:07] <davmor2> fader|away: alternates are bust still cjwatson has uploaded a fix can you let cr3 know please :)
[14:40] <davmor2> cr3: alternates are still bust dude
[14:40] <davmor2> cr3: morning by the way :)
[14:41] <cr3> davmor2: thanks for the heads up, but desktops are fine?
[14:42] <davmor2> cr3: seem to be although today's iso your network tests may fail in live cd mode
[14:42] <cr3> I haven't gotten any desktop results either, which seems to indicate there might be a problem there as well
[14:43] <davmor2> cr3: live desktop's nm is just spiralling apparently there is a new version uploaded already
[14:44] <davmor2> cr3: I don't know if or how that might effect you.  But if you are running the install as a pxe boot then that might be the cause the minute the desktop comes up you lose networking that would be a cause for the install to fail :)
[14:44] <cr3> davmor2: cool, and I just fixed a bug in my mago integration, so I might be able to test the new desktop image and that at the same time
[16:06] <ara> popey, ping
[16:10] <popey> ara: lo
[16:11] <ara> popey, can you have a look? http://people.canonical.com/~ara/temp/iso-tracker.avi
[16:11] <ara> popey, if you approve, feel free to upload it to screencast.u.c
[16:11] <ara> popey, thanks
[16:11] <cr3> ara: btw, you might like to mention in your indicator-applet README that the test depends on python-indicator
[16:12] <cr3> err, make that python-indicate
[16:12] <popey> \o/ awesome!
[16:12] <popey> ara: no, thank _you_
[16:13] <ara> cr3, OK. I will, thanks for telling me that
[16:13] <ara> cr3, btw, notify-osd tests are failing because the need the images to compare with
[16:14] <ara> cr3, maybe that's why they were appearing as faling?
[16:14] <cr3> ara: possible, I'll blacklist those as well then
[16:15] <ara> cr3, why??
[16:15] <cr3> ara: I have lots of machines with different resolutions, so I would need to introduce the concept of golden images on a per system basis
[16:16] <cr3> ara: if you have the spare cycles to implement this, let me know and we could work together on this
[16:16] <ara> cr3, we will need to discuss, marjo, you and I, the need of having mago tests running in all the machines. (which I think is not worth it)
[16:18] <cr3> ara: sure, if you want to work on the scheduler too, let me know. I'd like to implement something like the JESS rules engine to schedule where mago tests should run
[16:19] <cr3> ara: it would be nice for this rules engine to be able to schedule tests on multiple machines, because mago takes a rather long time to run and it will only get longer as times goes by. so, being able to balance the load across multiple machines might be worthwhile
[16:19] <ara> cr3, the number of hw related bugs mago tests could catch are so small I don't think it is worth it. I would prefer running mago tests always on the same machine. with all the needed data (like screenshots for comparison) is correct for that one
[16:20] <cr3> ara: cool, that doesn't need to run in certification then, why not a kvm instance on your machine overnight?
[16:21] <ara> cr3, no, thanks ;-)
[16:22] <cr3> ara: it could be a simple matter of: apt-get update; apt-get dist-upgrade; bzr pull mago; run mago. just do that at the end of your day and, voila, we gots daily tests :)
[16:23] <cr3> ara: or, we have a vmware esx server in the datacenter, how about there?
[16:25] <ara> cr3, I think all of those posibilities should be discussed with marjo first, don't you think?
[16:26] <cr3> ara: sure, but if you're not comfortable with the possibility of running it on your own hardware, I wouldn't even bother mentionning it to marjo
[16:28] <cr3> ara: I'd rather we consider possible possibilities together which can then be presented to marjo. so, you mentionned you just want to run it on a single machine. if that machine were running vmware esx, would that be a good solution for you?
[16:38] <ara> cr3, what I am suggesting is that maybe marjo WANTS to run it in the datacenter, as part of the certification tests
[16:41] <cr3> ara: ah, good point then, there are costs to introducing the concept of a golden image in order to run it across multiple machines or implementing the scheduler to only run on a single machine. and, marjo would be best positionned to make a decision on those costs
[16:41] <cr3> ara: however, karmic is pretty full right now, so I suspect this will have to be a karmic+1 thing
[16:42] <ara> cr3, indeed :)
[17:06] <davmor3> hey everyone wazzup?
[17:07] <davmor2> davmor3: nothing just chilling with a bud
[18:18] <popey> http://screencasts.ubuntu.com/2009/09/24/Ubuntu_Testing_-_ISO_Tracker \o/
[18:21] <jcastro> popey: \o/
[18:22] <popey> :)
[18:26]  * jpds \o/'s myself.
[18:26] <jpds> himself*
[18:37]  * davmor2 joins the belated mexican wave \o/
[19:11] <StefanAO> hello everybody...what is to be tested next monday?
[19:22] <cr3> StefanAO: what do you mean? which milestone release is to be tested?
[19:41] <StefanAO> i am new to this...i thought there would be some feature to test
[19:43] <cr3> StefanAO: there are always features to test :) since you are new to this, perhaps you might like to prepare for the beta release which will be available next week
[19:44] <cr3> StefanAO: to do so, you can have a look at the above URL pasted by popey and try testing an image or two
[19:44] <cr3> oh wait, you joined after popey pasted. here's the URL: http://screencasts.ubuntu.com/2009/09/24/Ubuntu_Testing_-_ISO_Tracker
[19:44] <cr3> this is a nice screencast that tells you everything you need to know to prepare for ISO testing
[20:33] <mikefletcher> Hi.  What time do the daily iso's get generated?  When a bug is marked 'Fix Released' does that mean the fix would be on the iso at that time?
[23:25] <FlyingBishop> If I'm building a new computer, should I run an install with 9.04 before trying out one of the alphas?
[23:26] <whereisdarran> probably
[23:26] <whereisdarran> if you want to know that your hardware is ok
[23:26] <whereisdarran> probably best to run stomething stable first
[23:26] <FlyingBishop> yeah that sounds wise I'll run a basic install then try the alpha
[23:29]  * popey hugs jpds


[02:12] <user|66599> hello i want to be able to write text in arabic switching from english to arabic how is this done in kde?
 @Adam Workman, go to system settings > Input Method > Layouts and add layout for arabic language
 @user|1385, Yes, the website isn't updated since so many days. 🤔
 @Adam Workman, 👍
 1655
[13:55] <sparrow_> hi
[13:55] <sparrow_> anybody here?
[13:57] <sparrow_> hello?
[13:57] <sparrow_> so boring
[13:58] <sparrow_> I see 355 user online, but no one respond me
[13:58] <tuxakadjseb> Hello sparrow_
[13:58] <sparrow_> ohh i t work
[13:59] <sparrow_> do you use Kkonversation to chat ?
[14:01] <sparrow_> how can I find some channel which chat with someone who are active?
[14:01] <tuxakadjseb> I use Konversation too.
[14:02] <tuxakadjseb> What channel do you looking for ? About GNU/Linux ? Ubuntu ? Kubuntu ? Others ? In English ?
[14:02] <BluesKaj> Hi folks
 hi guys
[14:03] <sparrow_> I like all about it , I want make friends
[14:04] <sparrow_> I want to study English in this way
[14:07] <sparrow_> Where are you from?
[14:08] <BluesKaj> hi sparrow_
[14:08] <BluesKaj> @silvestri_nicola, hi
[14:09] <sparrow_> hi!
[14:09] <sparrow_> hi ~
[14:10] <sparrow_> It is my first time use this, so coool
[14:10] <tuxakadjseb> I'm French and I'm living in Angers (West of France).
[14:11] <sparrow_> that is great!
 @sparrow_, not the best way but still useful
[14:11] <explorishabh> hello everybody :)
 @sparrow_, I'm from Italy
[14:12] <explorishabh> today I am talking through konversation...👋
[14:12] <sparrow_> I am Chinese, live in south of China
[14:13] <BluesKaj> northern Ontario Canada here
[14:13] <tuxakadjseb> sparrow_: you can access to a IRC channels with the command /list
[14:14] <sparrow_> How can I @ someone in Konversation?
[14:14] <rishabh> I am an Indian, living in Western India
[14:16] <BluesKaj> sparrow_, look at the top row of the KB, usually shift 2 will do
[14:18] <BluesKaj> depending on which type of KB you use it should be listed in the numruc row
[14:18] <BluesKaj> numeric
[14:19] <sparrow_> just like  '@' + 'someone name '?
[14:20] <BluesKaj> yes
[14:21] <sparrow_> @BluesKaj  Thanks !
[14:21] <BluesKaj> only @ for telegram users (ircsomebot)
[14:22] <BluesKaj> if you use an regular type irc client like konversation or hexchat then @ is not needed
[14:23] <sparrow_> I have understand, thak you
[14:23] <BluesKaj> an/a
[14:24] <sparrow_> understood
[14:26] <BluesKaj> err, not needed for regular users in other words
[14:31] <sparrow_> I have join the @ircsomebot in telegram , but it doesn't work
 do you have any guidelines on how to chat in telegram using konversation? I'm new here
[14:42] <BluesKaj> don't think you need an irc client to chat on irc in telegram
[14:44] <BluesKaj> https://steemit.com/technology/@martin-stuessy/hack-your-telegram-to-your-irc-server
 @BluesKaj, ah ok understooth
 @BluesKaj, thank you very much!
[16:58] <dougl> good morning
[17:04] <BluesKaj> 'morning dougl
[17:34] <dougl> Blue - I found you... been looking on and off for about a month or so - how have you been?
 this channel is not so useful because the distro owner can't or won't reposnd... its's a pity
 Why Kubuntu still maintain that old forum when there are really good platforms like discourse? It can attract a lot of people and share knowlengs in a constructive manner
 No one responds... so goodbye
[19:52] <ThunderBeaver> hi
[19:53] <ThunderBeaver> Why does every forum need to migrate to the hot new forum software? savbran
 To facilitate aggregation using powerful tools
 for example
 searching, be informed in time when important decision are taken, etc.
 For example, can you tell me how can I know what will be in the next kubuntu lts update?
 is there any rss feed that I can subscribe to have this info?
 using a modern platform allows the community to have a lot of tools of these kinds, and to owners to use intuitive artifacts that stimulate the good content reporting
 another reason is the help you can receive on any level (artistic, thecnical, architectural, infrastructural) using modern tools
 people like to have simple toos that are powerful at the same time
 nowadays
 no loss of time, just tools that help at their best
 don't you agree?
[22:42] <lolilolilol> hi
[22:49] <lolilolilol> I don't understand anything about IRC, I don't even know if people see my messages
 hello
 could anyone tell me where can i configure dolphin to continue where it left off after reopining it? Like all the tabs and locations?


[07:38] <tumbleweed> jtaylor: of course you don't have to merge the branch, if you don't the UDD importer will create a revision for tha tupload, and the detailed history from the sponsoree will be lost
[07:39] <tumbleweed> jtaylor: with SRUs that's pretty much what ends up happening, because there aren't existing branches for -proposed for most packages


[01:52] <sarnold> is discord supposed to be doing this? https://pastebin.com/fcxZ3aQc
[02:36] <mup> PR snapcraft#2739 opened: tests: fix mypy error with test_errors.py <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2739>
[05:18] <mup> PR snapd#7555 opened: tests: add a test demonstrating that snaps can't access the session agent socket <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7555>
[05:22] <mborzecki> morning
[07:05] <pstolowski> mornings
[07:08] <marcustomlinson> pstolowski: hi :)
[07:11] <mborzecki> pstolowski: marcustomlinson: hey guys
[07:11] <marcustomlinson> mborzecki: hey
[07:59] <mborzecki> we don't have any code that uses the new seedwriter pedronis is working on, or do we?
[08:15] <pokk> Chipaca: sorry for afk:ing last night. No my problem have no relation with joedborg. I'm just trying to get a rsync backup from A to B where B is a ubuntu core raspberry pi
[08:15] <pokk> Chipaca: is there a specific reason why you say it's a terribly bad idea?
[08:15] <Chipaca> pokk: I thought you were trying to make an rsync copy of a core device
[08:15] <pokk> oh no :)
[08:16] <Chipaca> pokk: phew
[08:16] <Chipaca> pokk: as long as the place you're rsync'ing *to* isn't readonly, that should work fine
[08:16] <pokk> no, I'd agree that would be a rather bad idea.
[08:16] <Chipaca> pokk: so, i guess, where are you rsync'ing to?
[08:16] <pokk> I've not played around with Core befor but it seemed like a good fit. A low maintanance secure dist. Very little that would need to be tweaked
[08:17] <pokk>  /media/data, a mounted usb disk
[08:17] <Chipaca> pokk: ohhh, and you installed rsync from a snap?
[08:18] <Chipaca> of coruse :)
[08:18] <pokk> yes
[08:18] <Chipaca> pokk: there's an extra manual step, indeed because of confinement
[08:18] <pokk> there's a provided apparmor profile, /var/lib/snapd/apparmor/profiles/snap.rsync.rsync
[08:18] <pokk> but I've not been able to figure out what it should look like. I'm new to apparmor
[08:18] <Chipaca> actually, we might need to ask the rsync snap's author to tweak the snap
[08:19] <Chipaca> pokk: nah, the snappy way would be to do 'snap connect rsync:removable-media'
[08:19] <Chipaca> but
[08:19] <Chipaca> that snap is missing the interface
[08:19] <pokk> oh, I figured I should just have to add something like /media/data/* rw, to the profile. But no game
[08:19] <Chipaca> well, that's what the connect boils down to (and a bit more but essentially that)
[08:19] <Chipaca> but the snap needs to declare it as something ok to do
[08:20] <pokk> oh, so it's not enought to add it to apparmor?
[08:20] <Chipaca> pokk: if it can wait a bit, we'll get the snap author to tweak it
[08:20] <pokk> I'm not really in any hurry
[08:20] <Chipaca> pokk: easiest then to wait until cachio wakes up, he'll be here in ~3 hours, maybe 4
[08:20] <pokk> I was thinking of having it run as a remote backup solution. But atm I'm just playing around with it
[08:21] <Chipaca> 👍
[08:21] <pokk> lol, yeah if the waiting time for more discussions is 3 hours I'd barely call that waiting :D
[08:21] <pokk> I'm used to days between messages at times. So far I'm really loving this distro tho
[08:22] <pokk> it's like the perfect mix between coreos and ubuntu
[08:23] <Chipaca> do let us know of any bumps
[08:24] <Chipaca> wait, is cachio actually away today
[08:25] <Chipaca> ah no, just mvo and ijohnson
[08:28] <pokk> The setup process was definitly interesting. I'd have prefered a more cloud-config centered way of setting things up, but that's really just personal oppionons
[08:29] <Chipaca> mwhudson: ^
[08:29] <pokk> I've also found it some what hard to google thing, not sure of what to prefix the searches with. When searching "Ubuntu core" 90% of the hits are just ubuntu
[08:31] <pokk> I've really not had time to read all the docs either so some googles could have probably been avoided
[08:31] <Chipaca> pokk: yeah, we've not made that bit easy. Adding 'snappy' in there sometimes helps. Otherwise, forum.snapcraft.io can be easier to find stuff in than google, strangely
[08:34] <Chipaca> pedronis: 👋
[08:34] <pedronis> mborzecki: hi, tried to answer some questions in your reviews. Seedwriter is a reorg of image.go, is not trying to add much new functionality.
[08:34] <Chipaca> pedronis: https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001/49?u=chipaca
[08:34] <pokk> Chipaca: I take it you're a contributor in some way?
[08:34] <Chipaca> pokk: yeah
[08:35] <pedronis> Chipaca: sometimes? yes, now? unlikely
[08:35] <Chipaca> pedronis: k
[08:35] <pokk> cool :) it's always nice with friendly developers on irc
[08:36] <Chipaca> pedronis: i'll try to remember to badger about this periodically then
[08:36] <Chipaca> pokk: why thank you
[08:36] <Chipaca> we can also get ornery sometimes
[08:36] <pedronis> Chipaca: if I remember the issue was that we cannot trust NM
[08:36] <zyga> Hey
[08:36] <pedronis> anyway I have no bandwidth to think about this right now
[08:37] <zyga> I have a complicated morning. I will make up for it in the evening but I cannot work yet
[08:37] <Chipaca> pedronis: understandable
[08:37] <Chipaca> zyga: how much birthday cake did you eat
[08:37]  * Chipaca imagines zyga in a coma
[08:37] <pokk> zyga: coffee always helps :)
[08:37] <Chipaca> *food* coma
[08:38] <Chipaca> zyga: take care, thank you for letting us know
[08:38] <pokk> Chipaca:oh, one more thing. It's reallly minor but you didn't get to pick a timezone when installing. I'm sure it's been discussed and decided on not being included. But it's a think I tend to forget
[08:38] <pokk> resulting in having the wrong time on the system for days/weeks/months...
[08:39] <zyga> Chipaca: Lucy has a small bite :-)
[08:39] <Chipaca> pokk: ah the fight between minimalist and quick setup, and all the options
[08:39] <pokk> yepp
[08:39] <Chipaca> mwhudson: do you know if there are plans for prompting for the timezone (or any other extra stuff) ?
[08:40] <pokk> Why I sort of like a cloud-config file. I can decide on how minimalist I want it on my own
[08:40] <pokk> as for most other things I tend to remember doing them once installed. But for some reason I forget about timezones
[08:46] <mborzecki> pedronis:  https://github.com/snapcore/snapd/pull/7529 is the next one?
[08:46] <mup> PR #7529: seed/seedwriter: cleanups and small left over todos <Created by pedronis> <https://github.com/snapcore/snapd/pull/7529>
[08:46] <pedronis> mborzecki: yes
[08:47] <mborzecki> pedronis: i'll land #7469 or do you want to push anything more there?
[08:47] <mup> PR #7469: seed/seedwriter,snap/naming: support classic models  <Created by pedronis> <https://github.com/snapcore/snapd/pull/7469>
[08:47] <pedronis> mborzecki: I'll land it
[08:48] <mborzecki> pedronis: ok
[08:49] <mup> PR snapd#7469 closed: seed/seedwriter,snap/naming: support classic models  <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7469>
[08:50] <pedronis> mborzecki: do you want me to rebase 7529 before looking at it?
[08:51] <mborzecki> pedronis: yeah, can you merge master there?
[08:51] <mborzecki> gh should really be smart enough do to it when generating diffs and there's no conflicts
[08:54] <pedronis> mborzecki: done, it's smallish in itself
[08:54] <mborzecki> pedronis: thanks
[08:54] <pedronis> a bit of kitchen sink of various things though
[09:01] <pedronis> Chipaca: +1 for #7445
[09:01] <mup> PR #7445: overlord/snapstate/policy, etc: introduce policy, move canRemove to it <Created by chipaca> <https://github.com/snapcore/snapd/pull/7445>
[09:01] <Chipaca> woop
[09:02] <Chipaca> pstolowski: when you find a moment, could you take a look at ^ 7445? it's a bit big but not complicated
[09:03] <pstolowski> Chipaca: yes
[09:14] <mup> PR snapd#7553 closed: cmd/snap: update 'snap find' help because it's no longer narrow <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7553>
[09:14]  * Chipaca is helping
[09:28] <mborzecki> pstolowski: regarding https://github.com/snapcore/snapd/pull/7443#discussion_r330408988 how about `weekdayInMonth()`?
[09:28] <mup> PR #7443: timeutil: fix schedules with ambiguous nth weekday spans <Bug> <Needs Samuele review> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7443>
[09:30] <pstolowski> mborzecki: perhaps weekday*s*InMonth() - it gives number of days right?
[09:31] <mborzecki> pstolowski: yeah, sgtm
[09:31] <pstolowski> weekdayInMoth sounds like it would return time.Time
[09:39] <mborzecki> pstolowski: hehe, adding tests with time.Time{}
[09:39] <mborzecki> actually according to go 0001-01-01 is monday :P
[09:39] <pstolowski> mborzecki: is it a problem actually?
[09:40] <mborzecki> pstolowski: no, but i'm adding the test to make sure that future changes don't break it
[09:40] <pstolowski> mborzecki: sounds great
[09:47] <mborzecki> pstolowski: equalWeekdaysInMonth or matchingWeekdaysInMonth
[09:47] <mborzecki> how about this?
[09:49] <pstolowski> mborzecki: is this wrt weekday*s*InMonth still?
[09:49] <mborzecki> pstolowski: yeah, still on my mind
[09:50] <pstolowski> mborzecki: I like matchingWeekdaysInMonth
[09:50] <Chipaca> yeesh, family drama brewing
[09:50]  * Chipaca goes for a coffee
[09:52] <pokk> My blood is probably more coffee than anything atm :|
[10:13] <mup> PR snapd#7529 closed: seed/seedwriter: cleanups and small left over todos <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7529>
[10:15] <pedronis> pstolowski: mborzecki: in case #7451 is ready for review now
[10:15] <mup> PR #7451: sandbox/cgroup: introduce cgroup wrappers package <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7451>
[10:18] <pstolowski> pedronis: ack
[10:22] <mborzecki> pstolowski: i've updated #7443
[10:22] <mborzecki> also it needs a 2nd review
[10:22] <mup> PR #7443: timeutil: fix schedules with ambiguous nth weekday spans <Bug> <Needs Samuele review> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7443>
[10:24] <pstolowski> mborzecki: thanks
[10:31] <mup> PR snapcraft#2739 closed: tests: fix mypy error with test_errors.py <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2739>
[10:32] <mborzecki> school run, back in a bit
[10:50] <abeato> hm, it looks like we cannot have base core18 in classic?
[10:50] <abeato> error: cannot assemble assertion model: cannot specify a base with a classic model
[10:50] <abeato> pedronis, do you know that? ^^
[10:51] <abeato> I get on snapd initialization:
[10:51] <abeato> Oct 04 10:45:01 numancia snapd[1047]: stateengine.go:108: state ensure error: devicemgr: cannot use gadget snap because its base "core18" is different from model base ""
[10:58] <pokk> Chipaca: so would one dare pinging cachio now?
[10:58] <Chipaca> cachio: 👋
[10:59] <Chipaca> cachio: could you add home and removable-media to the rsync snap?
[11:01] <cachio> Chipaca, sure
[11:01] <pokk> I'd offer you a strawberry and banana small pancake as a thank you, but I'm guessing they'd not be so nice after an airplane trip
[11:01] <cachio> Chipaca, you mean to the save/restore snapd state ritght?
[11:02] <Chipaca> cachio: no, it's because pokk is wanting to rsync some things to /media/<something>/
[11:02] <Chipaca> cachio: and the rsync snap doesn't have the right interfaces
[11:02] <Chipaca> cachio: and you're the rsync snap publisher :)
[11:02] <cachio> Chipaca, ah
[11:03] <cachio> sure
[11:06] <mborzecki> re
[11:15] <cachio> pokk the snap is being built, I'll ping you in few minutes when it is published
[11:15] <pokk> out of curiousity. Where's the code for something like rsync? Is it all on github? If so my foo seems to be missing it
[11:15] <pokk> cachio: wow, that's some quick working!
[11:15] <cachio> pokk, it was a small change
[11:19] <mborzecki> cachio: Refreshing store authorization failed for test-snapd-rsync hmm
[11:20] <cachio> mborzecki, didn't update the test-snapd-rsync :)
[11:20] <cachio> it is the same
[11:20] <mborzecki> cachio: ah, i read some of the backlog, but not all :P
[11:20] <cachio> just updates the rsync
[11:20] <cachio> and it is not published yet
[11:21] <cachio> mborzecki, but if you have a log please share it so I can take a look
[11:21] <mborzecki> cachio: got this by email just few minutes ago
[11:22] <mborzecki> cachio: https://launchpad.net/~snappy-dev/+snap/test-snapd-rsync/+build/693784 store upload failed
[11:22] <mborzecki> btw. does anyone click the retry button when it happens?
[11:24] <cachio> mborzecki, you are right
[11:25] <cachio> rsync project created the test-snapd-rsync snap
[11:26] <Chipaca> cachio: mborzecki: I too am being spammed with these test-snapd-rsync emails
[11:26] <Chipaca> no idea what they're about :-)
[11:26] <cachio> but is was correctly built
[11:27] <Chipaca> cachio: the email says: Depending on the error message above, this may indicate a bug.  If so, you
[11:27] <Chipaca> may be able to work around it by reauthorizing Launchpad to upload the
[11:27] <Chipaca> package in question:
[11:27] <Chipaca> cachio:
[11:27] <Chipaca>   https://launchpad.net/~snappy-dev/+snap/test-snapd-rsync/+authorize
[11:27] <Chipaca> ¯\_(ツ)_/¯
[11:27] <Chipaca> cachio: but I don't know how this is connected to the 'rsync' snap :)
[11:28] <mborzecki> Chipaca: test-snapd->>>>>rsync<<<<< xD
[11:28] <mborzecki> only connection i see tbh
[11:29] <Chipaca> cachio: ACKshully, it might be that you created both (they're both in your name), and it looks like the only difference is the snap name itself :-)
[11:29] <Chipaca> cachio: so maybe you just changed the name: entry in the yaml :)
[11:29] <cachio> mborzecki, Chipaca I think the problem is that the owner for the snap package in launchpad is dnappy-developers and in the stop I am
[11:29] <mborzecki> pedronis: can you take a look https://github.com/snapcore/snapd/pull/7543 later on?
[11:29] <mup> PR #7543: release: make forced dev mode look at cgroupv2 support <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7543>
[11:30] <Chipaca> cachio: wo'a mess
[11:47] <cachio> Chipaca, moving all the test snaps to snappy-dev
[11:47] <Chipaca> cachio: and the plain 'rsync' snap?
[11:47] <cachio> Chipaca, too
[11:48] <cachio> Chipaca, does it make sense for you?
[11:48] <Chipaca> cachio: yeah, probably (either that or straight up Canonical for the rsync one)
[12:01] <pokk> seems like I caused some added trouble here :| sorry about that
[12:07] <Chipaca> pokk: it obviously needed sorting
[12:08] <Chipaca> that snap hadn't been rebuilt in over a year → it almost certainly needed rebuilding at least to pick up new libs
[12:12] <pokk> sure, but also unplaned workd
[12:24] <cachio> pokk, hey, could you try the test-snapd-rsync snap
[12:25] <cachio> pokk, this is the same than the rsync once
[12:25] <cachio> pokk, if it works well then I'll see how to release the rsync once
[12:25] <cachio> one
[12:26] <pokk> just `snap install test-snapd-rsync` then?
[12:27] <cachio> then you need to connect the interface
[12:28] <cachio> pokk, you also can do snap alias test-snapd-rsync.rsync rsync
[12:28] <pokk> right
[12:29] <cachio> so then you will be able to do rsync and it will call the test-snapd-rsync snap
[12:31] <cachio> pokk, did it connect=
[12:31] <cachio> ?
[12:31] <cachio> pokk, sudo snap connect test-snapd-rsync:removable-media
[12:31] <cachio> this should be enough
[12:31] <cachio> then you should be able to use it
[12:31] <pokk> it seeems to work
[12:32] <pokk> I'm running it on an raspberry pie 3 so it's sloooow
[12:33] <cachio> pokk, is it ok for you to use it until we decide what to do with the rsync one?
[12:33] <cachio> today/monday
[12:34] <pokk> cachio: oh for sure. Atm I'm really just trying core out. Trying to get a feel for it. I'd probably reinstall next week anyway and restart from scratch
[12:35] <cachio> pokk, nice, I'll discuss about this today
[12:35] <cachio> thanks
[12:35] <pokk> it's not like I'm paying you for the development atm :) So I can't demand things to be solved in hours. Monday would be weeks/months faster than some problems one encounters at times
[12:35] <pokk> aaaaand, sometimes you'll not get things fixed even when paying looots of money :|
[12:35] <Chipaca> ooh, I could go with that plan
[12:36] <Chipaca> (a) get paid looots of money, (b) do nothing
[12:36] <Chipaca> (c) and (d) are not needed because see (a)
[12:37] <pokk> well I mean, we're getting the service. But not getting things outside of the very small box
[12:37]  * pokk isn't at all grumpy
[12:37] <pokk> oh, and just to be clear. I'm not talking about Ubuntu at all here
[12:38] <pokk> and now my rsync backup works :) Thanks a lot!
[12:40] <Chipaca> pokk: with my canonical-employee hat on, if you ever find yourself in that kind of place with canonical, please do reach out
[12:41] <Chipaca> everybody can mess up and get stuck in that kind of place with a contract, but all it should take is a conversation to dislodge things
[12:44] <pokk> Chipaca: I'm talking about some of the bigger cloud providers :) At times they can be super helpful, at times they'll just refuse to help at all. No matter how many zeroes there's in the bill you're paying each month
[12:45] <mup> PR snapd#7556 opened: image,seed/seedwriter: switch image to use seedwriter.Writer <Created by pedronis> <https://github.com/snapcore/snapd/pull/7556>
[13:01] <Chipaca> pedronis: stdup?
[13:01] <zyga> I cannot join
[13:01] <zyga> Still looking after Lucy
[13:01] <zyga> No work done today
[13:09]  * Chipaca hugs zyga
[13:09] <Chipaca> zyga: that's ok
[13:10] <Chipaca> zyga: you know what happens when you don't come to the standup
[13:10]  * Chipaca assigns everything to zyga
[13:30] <cachio> mborzecki, https://travis-ci.org/snapcore/snapd/jobs/593470475#L9354
[13:30] <cachio> now happening in i386
[13:32] <mborzecki> cachio: looks like the job took too long, nothing seems to have explicitly failed
[13:37] <cachio> mborzecki, I thing it got stuck as it used to happend in arch
[13:37] <cachio> mborzecki, then the build fails because of this test
[13:39] <mborzecki> cachio: hmm that's possible, we know there's a race, but unless someone picks up the work on the kernel or strace side it's not going to get fixed :(
[13:41] <cachio> mborzecki, makes sense, if I see this again in i386 I'll apply the same solution than arch
[13:52] <Chipaca> popey: are you a round?
[13:54] <roadmr> round like 🔵  ?
[14:28] <mup> PR snapcraft#2740 opened: crystal plugin: add flags to use during shards build <Created by mamantoha> <https://github.com/snapcore/snapcraft/pull/2740>
[14:33] <cachio> zyga, there?
[15:05] <joeubuntu> Snappers (is that a thing? it should be...) I have a snap that uses python's plotly module to create an html page which it opens using the default browser. In my snap when that is called it just hangs. What do I need to do in my yaml to make it work? Thanks for the help!
[15:08] <Chipaca> joeubuntu: https://www.urbandictionary.com/define.php?term=snapper er.
[15:08]  * cachio lunch
[15:09] <Chipaca> joeubuntu: add the 'desktop' interface, so you can run xdg-open
[15:09] <joeubuntu> thanks Chipaca , let me try that!
[15:26] <joeubuntu> Woot! It worked if I installed the package snapd-xdg-open on the host, is there a way to make the snap require that somehow on install or in the yaml ?
[15:40] <Chipaca> joeubuntu: what is the description of snapd-xdg-open?
[15:40] <joeubuntu> Chipaca  This is a transitional dummy package. It can safely be removed.
[15:40] <Chipaca> joeubuntu: thank you.
[15:41] <Chipaca> joeubuntu: you can remove that package, it has nothing in it.
[15:41] <joeubuntu> The browser will not launch without it though.
[15:41] <Chipaca> joeubuntu: try a second time
[15:41] <Chipaca> there's a bug with the auto-launching of the service
[15:41] <Chipaca> where the first time it auto-laucnhes but doesn't open the thing
[15:42] <Chipaca> it's fixed in … master at least
[15:42] <Chipaca> dunno where it is in the release queue
[15:45] <joeubuntu> That is incredibly confusing. It throws the error:" user-open error: Object does not implement the interface ." Which googling leads to snapcraft forum posts about the snapd-xdg-open package needing  to be installed
[15:45] <joeubuntu> But you are right, running it a second time fixes that.
[15:48] <Chipaca> joeubuntu: yeah! it's a stupid bug
[15:48] <Chipaca> joeubuntu: we put the service on the bus before attaching the interfaces to it
[15:49] <Chipaca> joeubuntu: because we are super smart (tm)
[15:49] <Chipaca> anyway it's fixed, but annoying until that's sorted
[15:49] <Chipaca> joeubuntu: the fascinating thing is how long it took for that one to be noticed
[15:49] <Chipaca> people just double-clicked, i guess?
[15:50] <joeubuntu> Chipaca I just click harder if it doesn't work ... that helps, right?
[15:50] <joeubuntu> Thanks for the help!
[15:50] <Chipaca> joeubuntu: totally. That error message _means_ "click harder next time!"
[15:50] <joeubuntu> 😂
[15:53]  * diddledan clicks. quite hard.
[15:55]  * Chipaca buys shares in sellers of replacement clicky things
[15:55] <diddledan> I got a new clicky today!
[15:56] <diddledan> it's not got a wire!
[15:56] <diddledan> this is voodoo...
[16:29] <Chipaca> diddledan: who do?
[16:29] <diddledan> you do!
[16:30] <Chipaca> https://www.youtube.com/watch?v=UunvsU66B4Y
[16:39]  * cwayne is disappointed that YouTube links not for labyrinth
[16:49] <Chipaca> it'd have to be a qr code
[16:55] <mup> PR snapcraft#2697 closed: Neon extension <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2697>
[17:02] <pokk> so far it seems like a raspberry pi 3b+ with ubuntu core on it is a really great setup. The poor thing have been on heavy load for a few hours but it seems to work great
[17:13] <ackk> hi, is there a way to autoconnect interfaces for a snap with "snap try" or when installing with --dangerous?
[17:24] <mup> PR snapd#7445 closed: overlord/snapstate/policy, etc: introduce policy, move canRemove to it <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7445>
[19:10]  * cachio afk
[19:53] <mup> PR snapcraft#2741 opened: extensions: support using gjs from gnome runtime <Created by galgalesh> <https://github.com/snapcore/snapcraft/pull/2741>
[20:56] <mup> PR snapcraft#2742 opened: cli: use click utilities for login prompts <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2742>


[17:03] <mpt> "If you don't save the image, changes from the last 25 hours will be lost. That's not quite as bad as it sounds, because you were probably asleep some of that time."


[03:29] <duflu> kdub: Still around?
[09:31] <duflu> That's fun. Apparently I wrote almost half the Ubuntu spinner code and didn't even know it
[09:32] <alan_g> That's being productive. ;)
[09:38] <duflu> Yeah, welcome to open source
[09:43] <alan_g> duflu: have you any thoughts on this one? https://code.launchpad.net/~alan-griffiths/mir/integrate-generic-shell/+merge/251581
[09:43] <duflu> alan_g: Nope. I haven't looked at any of your shell work
[09:44] <duflu> And am about to run out of week
[09:44] <alan_g> np Have a fun weekend
[14:50] <kenvandine> i tried enabling some reporting in mir, to debug my trust session issues
[14:50] <kenvandine> but now the shell isn't starting
[14:50] <kenvandine> MIR_SERVER_SESSION_MEDIATOR_REPORT=1
[14:50] <kenvandine> MIR_SERVER_SCENE_REPORT=1
[14:50] <kenvandine> any ideas?
[14:52] <alan_g> MIR_SERVER_SESSION_MEDIATOR_REPORT=log MIR_SERVER_SCENE_REPORT=log
[14:52] <kenvandine> oh
[14:52] <kenvandine> alan_g, thanks!
[14:53] <alan_g> yw
[14:53] <alan_g> I guess you don't see the error message. ;)
[14:53] <kenvandine> alan_g, to debug trust sessions is MIR_SERVER_SESSION_MEDIATOR_REPORT the most important one?
[14:53] <kenvandine> not sure where to look for the error :)
[14:54] <alan_g> What's the symptom?
[14:54] <kenvandine> my client is getting rejected
[14:55] <alan_g> Are you connecting to the trusted socket or the regular one?
[14:56] <kenvandine> with MIR_SOCKET set to the file descriptor
[14:56] <kenvandine> not sure what the regular one is
[14:57] <alan_g> That's OK, I misunderstood
[14:58] <alan_g> You could also see what msg-processor-report and rpc-report have to say
[14:58] <alan_g> but session mediator is a starting point
[14:59] <kenvandine> wow that's verbose
[17:41]  * alan_g wonders if the only reason handle_surface_created() exists is to raise() a surface that hasn't yet posted a buffer.


[01:27] <TheDukeNY> ..
[05:25] <valorie> hi finn - damn, not online anymore
[05:25] <valorie> I'll text ya


[00:02] <timClicks> hi all, i'm new to packaging and am currently working on bug #271260, i'm trying to get https://launchpad.net/sahana/trunk uploaded into REVU
[00:02] <timClicks> i have two questions
[00:02] <timClicks> 1) is there a guide on packaging programmes written in interpreted languages (PHP ideally)
[00:03] <directhex> does debian have a pkg-php team? they might have a guide
[00:03] <directhex> if not, look at another package & steal their packaging files
[00:04] <timClicks> 2) a debian/changelog, etc. has not been used so far - is it sufficient to have *first Ubuntu package in the log?
[00:04] <timClicks> directhex - cheers, will look into it
[00:05] <directhex> timClicks, yes. use "dch" to edit changelogs.
[00:07] <timClicks> ok - that's a relief, there's +3800 revisions already
[00:19] <maxb> timClicks: Yes, it's perfectly normal for the first debian/changelog entry to just say "* Initial package (LP: #number of needs-packaging bug)."
[00:35] <maxb> I see pbuilder-dist has the option to create i386 chroots on amd64, but it doesn't use linux32 when invoking things in them (afaics)
[00:35] <maxb> Does that matter?
[00:43] <directhex> maxb, in some cases, yes
[00:43] <directhex> maxb, exceedingly stupid cases, mind you
[00:49] <maxb> The only one I know of is uname
[00:54] <maxb> :-/
[00:55] <maxb> So far I've managed to cram all my pbuilder magic into .pbuilderrc, but it looks like there just aren't the hooks for this.
[01:53] <timClicks> debian/control question : is it possible to set an either/or dependency?
[01:56] <bddebian> foo | bar
[01:57] <timClicks> ta
[04:38] <ossud> hi!
[04:38] <nhandler> Hey ossud
[04:39] <ossud> i would like to compile software packages for the ubuntu universe repo ... where can i upload my .debs?
[04:39] <ossud> (mostly not my own programs)
[04:40] <timClicks> ossud: try googling REVU
[04:40] <nhandler> ossud: You can also upload them to your PPA on Launchpad
[04:42] <ossud> u shure? because i would upload programs of other people which i had compiled from source
[04:42] <ossud> (not the people)
[04:42] <nhandler> ossud: You would need to actually packagethe application before you could upload it to these locations
[04:43] <ossud> as .deb
[04:44] <nhandler> ossud: No, a .deb is a binary package. You would need to upload the source package
[04:44] <nhandler> ossud: Take a look at https://wiki.ubuntu.com/PackagingGuide/Complete for all the information you could ever want about creating the source package
[04:44] <ossud> thanks but i don't own the source
[04:45] <ossud> how can i be shure that's ok with the developer of this app?
[04:45] <nhandler> ossud: Check the license the code is released under
[04:46] <ossud> ah!
[04:47] <ossud> would this appear in a repo or just on the site?
[04:47] <nhandler> ossud: The license should be included in the .tar.gz that contains the source code
[04:49] <ossud> i ment: would the appilikation then be includet in a ubuntu repo where i can install it from?
[04:51] <ossud> because i saw that there are a lot of old versions of programs in the normal repos
[04:52] <nhandler> ossud: Your PPA is a repository. If you want it included in the official ubuntu repositories, follow https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[04:52] <ossud> thank you! you are very kind :)
[05:53] <calc> what is the proper Ubuntu MOTU line for maintainer field?
[05:54] <calc> Ubuntu MOTU Team<EMAIL_ADDRESS>?
[05:55] <StevenK> Ubuntu MOTU Developers
[05:55] <jdong> https://wiki.edubuntu.org/DebianMaintainerField
[05:56] <jdong> see Design
[05:56] <jdong> (but in short StevenK is always right :D)
[05:58] <calc> ah ok
[05:58]  * calc is beating a package someone else created into revu clean
[05:59] <calc> what do i do for a package that has no original source location, eg just in a branch in lp bzr?
[06:18] <calc> grr i can't determine how to cause make to execute a grep after bzr checkout to determine the version number, it seems to do it immediately before the bzr checkout even happens
[06:18] <calc> trying to do something like this:
[06:18] <calc>         bzr co lp:~flimm/+junk/bash-ooo-thumbnailer && \
[06:18] <calc>         UPSTREAM_VERSION=`grep version bash-ooo-thumbnailer/setup.py | cut -f 2 -d \\"` && \
[06:18] <calc>         mv bash-ooo-thumbnailer ooo-thumbnailer-$(UPSTREAM_VERSION)
[06:19] <calc> is there a way to delay evalution until execution?
[06:29] <calc> got it working :)
[06:29] <calc> needed $$
[07:11] <calc> grr now its complaining about setup.py not having a copyright
[07:13] <calc> anyone have any ideas about this: http://revu.ubuntuwire.com/report.py/legal?upid=5448
[07:20] <mrooney> calc: shouldn't setup.py have a copyright file? that seems like a legit complaint
[07:20] <calc> mrooney: its already listed as cc public domain in the header
[07:21] <mrooney> ah I see
[07:21] <calc> mrooney: i think maybe its a problem of the revu grepper not being good enough?
[07:21] <mrooney> that could be, if lintian is fine with it
[07:21] <calc> i fixed it up to say this and it is still complaining:
[07:21] <calc> +# Copyright 2009 - David D Lowe<EMAIL_ADDRESS>[07:21] <calc> +# Released into the public domain:
[07:21] <calc> +#   http://creativecommons.org/licenses/publicdomain/
[07:21] <calc> yea lintian was clean long before revu got close to passing it
[07:22] <calc> the setup.py itself is what is public domain the script is licensed as gpl
[07:22] <mrooney> I assume you aren't the owner and can't just gpl the setup.py the same way?
[07:22] <calc> no
[07:23]  * calc is headed to bed, maybe someone will take a look at it later today :)
[07:25] <calc> once i get it approved i am going to send it back to the original author since he also made the debian packaging but it had lots of issues
[07:29]  * calc gone to bed now
[08:54] <savvas> hm..
[08:54] <savvas>  │ The configuration file /etc/default/console-setup specifies a keyboard    │
[08:54] <savvas>  │ layout and variant that are not supported by the configuration program.   │
[10:50] <Laney> What's the exception process for bugfix uploads now?
[10:51] <Laney> The mail that slangasek linked to implies that only one ack is needed. Is that right?
[10:55] <mok0> Laney: what mail are you referring to?
[10:55] <james_w> the freeze mail
[10:58] <mok0> Ha, just got it this second
[10:59] <james_w> there's also https://lists.ubuntu.com/archives/ubuntu-motu/2008-October/004845.html
[10:59] <james_w> which confuses matters a bit more
[11:00] <james_w> perhaps motu-release would like to comment on whether that policy will be used again
[11:17] <Toadstool> hi all
[11:19]  * Laney mails the list
[11:19] <Laney> hi Toadstool
[11:20] <Toadstool> hi Laney
[15:05] <radix> hi guys, is there a good place to put instructions for future maintainers? i.e., for procedures on making updates to the package, version number conventions, and so on?
[15:06] <james_w> radix: debian/README.Source is the preferred place for that I think
[15:07] <james_w> http://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource
[15:07] <james_w> debian/README.source sorry
[15:07] <radix> okay, cool
[15:11] <bddebian> Heya gang
[15:28] <mehdid> general question: if a bug is found in a package (in a supported version of ubuntu, not current), what can I do to get it updated (if possible)? Can I make an updated package and send a link to the .dsc?
[15:29] <cjwatson> mehdid: https://wiki.ubuntu.com/SponsorshipProcess
[15:31] <joaopinto> !sru
[15:32] <mehdid> ubottu: thanks, that's what I was looking for
[15:32] <mehdid> :)
[16:03] <CarlFK1> why does pbuilder depend on postfix?  http://packages.ubuntu.com/jaunty/pbuilder
[16:04] <Pici> CarlFK1: I don't see that listed there.
[16:04] <CarlFK1> Pici: it must be in the tree somewhere
[16:05] <Pici> hm
[16:06] <CarlFK1> what's the d-foo command that shows the tree?
[16:07] <geser> I guess it's because pbuilder recommends devscripts which recommends bsd-mailx which depends on postfix | mta
[16:12] <CarlFK1> oh yeah...  something about now recommendeds get installed by default
[16:13] <jpds> --no-install-recommends.
[16:15] <CarlFK1> is there a way to not prompt "Hit <enter> to confirm:"  dh_make --single -f ../sphinx3-3.7.tar.bz
[16:16] <calc> anyone have time to revu a package? http://revu.ubuntuwire.com/p/ooo-thumbnailer
[16:17] <calc> its still complaining about a file but i think its just a bad test afaict
[16:17] <RainCT> calc: nevermind the legal thing, that's just the output of license-check
[16:17] <calc> RainCT: ok
[16:18] <RainCT> calc: is that for Jaunty?
[16:18] <calc> RainCT: yea
[16:18] <calc> RainCT: trying to get it in for jaunty to universe
[16:23] <RainCT> calc: No need to install the README as it doesn't say anything useful; e-mail of upstream is missing in the manpage (and it is a bit poor anyway, at least adding an example would be good); debian/copyright doesn't mention from where the source is; drop all changelog entries except for one with version -0ubuntu1.
[16:24] <RainCT> That's all I can find from looking at the diff
[16:25] <calc> ok
[16:25]  * calc didn't do the original packaging but is trying to beat it into shape
[16:26] <calc> RainCT: will dropping back to 0ubuntu1 work uploading to revu?
[16:26] <RainCT> calc: Yep, REVU doesn't mind about the version number
[16:26] <calc> ok
[16:27] <RainCT> It takes whatever you give it and achieves it labeled with the upload date
[16:27] <calc> ok
[16:28] <RainCT> *archives
[16:45] <fatal_> would be nice if someone would do the necessary massaging to get iproute synced from debian.... see https://bugs.launchpad.net/ubuntu/+source/iproute/+bug/335554
[16:46] <fatal_> ^-- filed by upstream himself.
[16:55] <cjwatson> fatal_: needs a freeze exception, and is far from guaranteed to get one at this point; "out of date with respect to upstream" isn't in itself enough
[16:56] <cjwatson> I understand it's missing some things but we also have to consider our fallback position if things break
[16:57] <cjwatson> james_w: ^- reminder for that bug, since you were looking at it earlier
[16:57] <cjwatson> fatal_: sorry we apparently forgot about this, I think it may have to wait for karmic at this point
[16:57] <james_w> ah, damn
[16:57] <james_w> thanks for the ping
[16:57] <cjwatson> (but will let james_w decide if he wants to go for a freeze exception)
[17:09] <directhex> i wonder if a pretty MOTU could tickle https://edge.launchpad.net/bugs/358558 before the next level of freeziness begins
[17:09] <fatal_> cjwatson: no need to say sorry. I'm just suggesting that it's a possibility to update it. I haven't seen any possible regressions and there has been no new issues reported since the lenny version = what you have....
[17:15] <fatal_> (personally I'm mostly here to poke around and see if there are any possibilities to hook up some nice ubuntu/debian collaboration contacts w.r.t. iproute. Don't really care if you update or not. :P)
[17:16] <fatal_> anyway, feel free to send me an email if there's anything I can help out with.... I'd be happy to<EMAIL_ADDRESS>[17:30] <bdmurray> Is there a MOTU release person around?
[18:26] <LaserJock> any MOTU Release people about?
[18:36] <iulian> LaserJock: A bit busy at the moment but I'm here.
[18:37] <LaserJock> the sugar team is wanting an FFe for the latest bug-fix releases of Sugar and I'd personally like to get it in, but I wanted to get some broader opinion from motu-release
[18:38] <iulian> LaserJock: I was looking at those packages right now.
[18:39] <LaserJock> iulian: ah, excellent
[18:47] <bdmurray> iulian: Can you help explain the type of freeze we are in right now?
[18:55] <iulian> bdmurray: We are in Final Freeze, two weeks from the final release.  Please see https://lists.ubuntu.com/archives/ubuntu-devel/2008-April/025259.html.
[18:55] <iulian> LaserJock: I'd say go ahead.
[18:55] <LaserJock> iulian: awesome, thanks
[18:55] <iulian> LaserJock: Would you like to take care of sponsoring those packages?
[18:56] <bdmurray> iulian: I did so "more intrusive changes" are okay now since it just started right?
[18:56] <LaserJock> iulian: I don't have to, if you'd like me to I can though
[18:56] <bdmurray> iulian: and no motu-release approval is required now?
[18:57] <iulian> LaserJock: That would be great, I'd appreciate it.
[18:57] <LaserJock> iulian: will do
[18:58] <iulian> bdmurray: What do you mean by "intrusive changes"?  Could you upload a debdiff somewhere so I can see exactly what you're on about?
[18:58] <iulian> LaserJock: Thanks a lot.
[18:59] <bdmurray> iulian: that's the wording in the announcement you pointed me to.  Regardless my specific question is about sponsoring the debdiff in bug 349114.  It adds a patch system which may be inappropriate based off the wording in that announcement.
[19:00] <iulian> bdmurray: By the way, all uploads to universe and multiverse will need to be acked by motu-release.
[19:00]  * iulian looks
[19:02] <iulian> bdmurray: Yes, please go ahead and upload.
[19:02] <bdmurray> iulian: okay, thanks!
[19:03] <bdmurray> iulian: What's the correct process for getting an ack? asking in irc subscribing to the bug?
[19:03] <iulian> bdmurray: Subscribing motu-release is better IMHO.
[19:03] <iulian> I've just commented on that bug.
[19:04] <iulian> bdmurray: You could ask on IRC as well.  That would make things easier for us.
[19:06] <iulian> Blah, I cannot find the list of motu-release delegates. :(
[19:07]  * iulian is always forgetting!
[19:14] <iulian> Ah, got it.
[19:20] <ode> hi
[19:23] <ode> lintian is giving me an message about duplicate name for source and package in control
[19:24] <ode> how do I just name it once
[19:24] <ode> and then reference when I use it the second time?
[19:24] <geser> can you please pastebin your debian/control?
[19:26] <ode> http://pastebin.com/m39cf641
[19:30] <hyperair> ode: can you give the exact lintian error?
[19:30] <hyperair> verbatim
[19:30] <geser> what's the exact lintian message? as the control looks ok to me
[19:32] <bddebian> Is it complaining about the duplicate section: perl?
[19:32] <ode> http://pastebin.com/d6724f4b0
[19:32] <ode> i think it's the duplicate of the name of the package
[19:33] <bddebian> No, you don't need Section: perl in the binary if the sourc epackage is Section: perl
[19:33] <ode> I guess there is a way to reference the name
[19:33] <hyperair> ode: no you can omit Section: perl completely
[19:33] <hyperair> ode: in the binary package
[19:33] <hyperair> ode: just have it once in the source package section
[19:34] <LaserJock> bddebian: my favorite MOTU!
[19:34] <bddebian> Heh, your lame-ass MOTU! :)  How are you?
[19:35] <LaserJock> doin' OK
[19:35] <LaserJock> can't wait to get Jaunty out the door
[19:35] <bddebian> heh
[19:38] <ode> thanks, that fixed it
[19:38] <LaserJock> anybody seen something like this before:
[19:38] <LaserJock> dh_install -psugar
[19:38] <LaserJock> dh_install: sugar missing files (debian/tmp/usr/lib/*), aborting
[19:39] <geser> isn't sugar written in python?
[19:39] <LaserJock> there's a debian/tmp/usr/lib/* line in sugar.install
[19:39] <LaserJock> but it shouldn't bail I'd think
[19:40] <geser> does the directory exist after running the install target?
[19:41] <geser> dh_install complains that it should install files from that location but they aren't there
[19:42] <geser> as sugar build-depends on python-dev my guess it it didn't transitioned to python 2.6 yet and installs the files to usr/local/lib (missing --install-layout=deb to setup.py install)
[19:44] <LaserJock> geser: I missed what you said
[19:44] <LaserJock> stupid Jaunty is locking up on me
[19:46] <geser> dh_install complains that it should install files from that location but they aren't there
[19:46] <geser> as sugar build-depends on python-dev my guess it it didn't transitioned to python 2.6 yet and installs the files to usr/local/lib (missing --install-layout=deb to setup.py install)
[19:48] <LaserJock> geser: ah, yeah, that'd make sense
[19:50] <ode> when i package a perl app am i meant to just rename the orig tarball to the perl naming scheme e.g. orig=stockmonkey-2.9013.tar.gz package=libmath-business-stockmonkey-perl-2.13?
[19:51] <ode> just wondered since it's meant to be orig, unchanged tarball
[19:54] <LaserJock> my goodness this is a nasty CDBS package
[19:54] <LaserJock> what's the point of using CDBS if you're just going to build your own .mk files anyway
[20:18] <Laney> siretart: do you have any preview debs for screen-profiles for debian for the daring?
[20:18]  * Laney likes it too much
[20:21] <Laney> kirkland: good work on it btw \o
[20:49] <maxriskfactor> any MOTU here who manages eric?
[21:03] <MOKHTE> INA perian ki miharfe
[21:12] <geser> anyone here using vim and bicyclerepair?
[21:22] <bdmurray> iulian: Could you ack bug 254992?
[21:55] <ScottK> Other motu-release people: If there's stuff you've acked, that's been uploaded, but not accepted, please let me know and I'll accept it.


[00:23] <Unit193> For the sake of py3, https://packages.qa.debian.org/c/calibre/news/20191025T011934Z.html might be great to grab, no?
[06:25] <cpaelzer> rafaeldtinoco: rbasak: I've had two MPs of which I said they are not important since they wait on Focal, now that it is open I'd appreciate a timely review if one of you could take a look
[06:25] <cpaelzer> https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/374446
[06:25] <cpaelzer> https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/374447
[06:27] <cpaelzer> well, now that we know Focal is open and no other fixes will be stacked let me combine them into one ...
[06:42] <cpaelzer> rbasak: rafaeldtinoco: https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/374770 would be better
[06:42] <cpaelzer> and in a few minutes we also have proper up to date Focal test build builds in a PPA to try if you want
[06:53] <cpaelzer> also I'm still waiting for all 4  haproxy MPs reachable from https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1841936
[06:53] <cpaelzer> Those are enough MPs to also tag you ahasenack :-)
[06:54] <cpaelzer> ^^
[07:11] <cpaelzer> rafaeldtinoco: the second and third chapter have a lot of overlap
[07:11] <cpaelzer> not sure if you'd want to merge that into one
[07:11] <cpaelzer> rafaeldtinoco: you also have to add a huge disclaimer at the manual qemu-cmdline that this disables everything that libvirt would do in terms of feature control
[07:12] <cpaelzer> it is a (very) last resort effort to do it that way
[07:12] <cpaelzer> also e.g. mds-no can be set normally, I ask you to only use those in the cmdline examples which really don't work any other way
[07:13] <cpaelzer> page breaks before new chapters would also help readability
[07:14] <cpaelzer> Oh you meant this to be for bionic, that is why you consider mds missing
[07:14] <cpaelzer> still ahuge disclaimer please
[07:17] <cpaelzer> IIRC while mds-no was one of the complex arch_capability ones
[07:17] <cpaelzer> md-clear was a normal bit and can be used in Bionic
[07:18] <cpaelzer> TBH I'd not even tell people to use qemu commandline from libvirt xml, it just leads to so many bugs later on all too often
[07:18] <cpaelzer> but with a big disclaimer it might be ok
[07:19] <cpaelzer> overll the doc surely will help people, so I hope you get not only mine but also other feedback and then can publish it somewhere
[09:46] <rafaeldtinoco> thx. yep I need to split what can be done on each version, like the msd-no. and will sure look for feedbacks. Greg's presentation today was all about that, impressive..
[09:48] <rafaeldtinoco> I'll start doing merges today, and code reviews as the doc is finished and repo is opened.
[10:17] <rbasak> cpaelzer: I'm still cloning qemu :-/
[10:17] <cpaelzer> hehe
[10:17] <cpaelzer> rbasak: rafaeldtinoco: glad to see you both, please coordinate that not both of you clean qemu for too long :-)
[10:18] <rbasak> I'm getting an eventual 503 Service Unavailable trying to fetch your branch
[10:18] <rbasak> So I might move on and see if it's working later
[10:19] <cpaelzer> rbasak: maybe do haproxy and let qemu for rafaeldtinoco ?
[10:19] <cpaelzer> that is smaller
[10:19] <cpaelzer> and you are involved from a second POV of the SRU team
[10:19] <rbasak> haproxy isn't cloning either right now
[10:19] <cpaelzer> oh, so it is LP in general
[10:20] <rbasak> I wonder if it's related to the archive opening
[10:20] <rbasak> The git-ubuntu importer is presumably very busy
[10:20] <rafaeldtinoco> I'm starting little later today, will catch up and sync with what's left (leave some reviews for me :)
[10:42] <cjwatson> rbasak: The git-ubuntu importer presumably always uses SSH though?
[10:42] <cjwatson> Or does it use HTTPS to pull?
[10:45] <rbasak> I'm not sure. I can look it up if you need?
[10:45] <cjwatson> Not especially
[10:46] <cjwatson> I should unpack what I said though: the 503s are because there's a lowish limit on concurrent HTTPS connections at the moment because there are some frequent events that amount to DDoS by HTTPS
[10:46] <cjwatson> And limiting concurrent connections makes it easier for the service to recover somewhat naturally most of the time without just faceplanting
[10:47] <rbasak> That makes sense, thanks
[10:51] <rbasak> cpaelzer: looks like haproxy for Focal needs rebasing onto proposed :-/
[10:51] <rbasak> Does that change anything?
[10:51] <cpaelzer> no
[10:51] <cpaelzer> rbasak: I already abandoned the focal MP
[10:51] <rbasak> Ah
[10:51] <cpaelzer> and updated the  bug
[10:52] <cpaelzer> the sync relaces the Focal MP, but SRU MPs stay as-is
[10:52] <cpaelzer> +p
[10:52] <rbasak> Sorry I shouldn't have jumped straight to your branches
[10:57] <rbasak> cpaelzer: I don't see the fix in 2.0.8-1? src/ssl_sock.c appears unchanged.
[10:57] <cpaelzer> I was relying on what I found it tagged in the upstream branch - let me check the actual upload that we got synced
[10:58] <cpaelzer> $ git tag --contains d6de151248603b357565ae52fe92440e66c1177c
[10:58] <cpaelzer> v2.0.8
[10:59] <cpaelzer> just to confirm why I have assumed it would be in there
[10:59] <rbasak> Suddenly I get the opposite answer to my query
[10:59] <rbasak> git diff pkg/ubuntu/eoan-devel pkg/ubuntu/focal-proposed -- src/ssl_sock.c
[10:59] <rbasak> This was previously giving me nothing, but now I see it
[10:59]  * rbasak is puzzled
[11:00] <rbasak> Ah
[11:00] <cpaelzer> the fixes are in on my check to focal-proposed that I just did
[11:00] <rbasak> Apparently working directory matters for that
[11:00] <rbasak> My mistake, osrry
[11:00] <cpaelzer> np
[11:51] <rbasak> cpaelzer: haproxy (three branches) looks good. What's the plan with the bug reference and SRU information?
[11:51] <rbasak> Right now the bug reference doesn't trigger a Launchpad-Bugs-Fixed
[11:51] <rbasak> And the SRU information is for the previous no-change rebuild I think?
[11:52] <cpaelzer> SRU information is for both
[11:52] <cpaelzer> if you read the bug it has two templates now
[11:52] <cpaelzer> and the upload will be done with an -v to the last released version
[11:52] <rbasak> Ah
[11:52] <cpaelzer> that way it will trigger the updates excactly once
[11:52] <rbasak> OK
[11:53] <cpaelzer> but atm autopkgtest has so much to do, I'm not sure when the 2.0.8 sync will release anyway
[11:54] <cpaelzer> but then -proposed is enough (in terms of prereq) to get the SRUs uploaded
[11:54] <cpaelzer> so if you approved them I can go on
[11:55] <cpaelzer> rbasak: I agree that the later ones which already had openssl need updated bug links
[11:55] <cpaelzer> consider that done
[11:56] <rbasak> Well you just convinced me that with a -v in the upload you don't need them? :-P
[11:56] <cpaelzer> which is correct for Bionic
[11:56] <cpaelzer> but D/E never had the openssl upload
[11:56] <rbasak> Ah
[11:56] <cpaelzer> there your feedback was correct
[11:57] <cpaelzer> I'm just proactively fixing your way to be green
[11:59] <cpaelzer> and the 2.0.8 would already be released if the opening of the sync wouldn't put that much pressure on autopkgtest
[11:59] <cpaelzer> things might need a while to settle there
[11:59] <rbasak> I think it's OK for you to mark Fix Committed for Focal and for me to then accept the SRUs.
[12:00] <cpaelzer> done
[12:00] <cpaelzer> now uploading
[12:03] <cpaelzer> rbasak: all tagged and uplaoded, the MPs are marked approved and the bug on Focal "Fix Committed"
[12:03] <cpaelzer> thanks for the review
[12:14] <cpaelzer> thanks for the accept rbasak, that way I can do the tests right away later today
[12:15] <cpaelzer> giving it an hour or two to build and show up in proposed
[12:17] <TJ-> Is the expected output of "dpkg --verify" mostly made up of '?' aside from the MD5 check? Docs say it is using RPM format which would normally be '.' for a pass - can I assume that '?' means "this check not done on Debian" ?
[12:39] <ddstreet> xnox you mind if i merge mdadm, or are you working on it
[13:25] <rafaeldtinoco> xnox: mind taking a look at the following MR whenever you have some time (https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/systemd/+git/systemd/+merge/374027), pls ? systemd-networkd related.
[14:21] <ubuking> Hey!
[15:37] <cpaelzer> ahasenack: postgresql-common 208 showed up, but needs a while to be syncable
[15:37] <cpaelzer> as I said in my mail, maybe you could kick the sync at your EOD
[15:37] <cpaelzer> then it should be available for a sync I'd hope
[15:45] <marcustomlinson> slashd: hey, have I been granted PPU for LibreOffice yet? I noticed I'm still not allowed to trigger autopkgtests against LibreOffice in a PPA
[15:45] <marcustomlinson> "You submitted an invalid request: You are not allowed to upload libreoffice or libreoffice to Ubuntu, thus you are not allowed to use this service."
[15:47] <cpaelzer> marcustomlinson: IIRC that is an action that only core-dev's can do atm
[15:47] <cpaelzer> I think it lacks an ACL finer than that
[15:47] <marcustomlinson> :(
[15:49] <cjwatson> marcustomlinson: I think cpaelzer is mistaken
[15:49] <cjwatson> bileto uses archive.checkUpload to determine whether the requester can upload
[15:50] <marcustomlinson> sounds promising cjwatson thanks
[15:50] <seb128> if you can upload I think you should be able to trigger tests
[15:51] <cjwatson> Indeed.  I checked and marcustomlinson hasn't yet been granted any kind of PPU
[15:51] <marcustomlinson> cjwatson: that would make sense yeah. slashd was gonna do that for me, I just suspect he hasn't gotten around to it yet.
[15:52] <slashd> marcustomlinson, I thought it was sil2100 task, I'll get back to you soon. Sorry for the delay.
[15:52] <seb128> marcustomlinson, just share retry urls on #ubuntu-desktop meanwhile if needed (or sent in query, I'm happy to click on those for you)
[15:52] <Laney> It needs to be done by a member of the TB
[15:53] <marcustomlinson> slashd: ah sorry, you did the team additions, cyphermox was gonna do the PPU
[15:54] <marcustomlinson> thanks seb128, I don't actually need one at this moment, was just giving it a test
[15:54] <slashd> marcustomlinson, I'll figure this out with the other member of the dmb and get back to you soon.
[15:54] <marcustomlinson> thanks slashd, sorry for bugging you (the wrong person)
[15:55] <slashd> marcustomlinson, not problem at all, it's dmb matter so all good
[15:55] <Laney> Not really happy with testing access by trying to create unnecessary jobs
[15:55] <Laney> We are slammed at the minute and libreoffice isn't exactly trivial
[15:56] <marcustomlinson> Laney: well I don't NEED to test is what I'm saying, as I can for amd64 locally first
[16:00] <Laney> Great, that's what everyone should be doing :>
[16:02] <cjwatson> Also you can test for access using edit-acl (lp:ubuntu-archive-tools)
[16:02] <cjwatson> edit-acl -p marcustomlinson query
[16:04] <marcustomlinson> cjwatson: useful thanks :)
[16:24] <sil2100> slashd: I thought only the PPU package addition for Gunnar was my action item?
[16:24] <sil2100> Did I forget something?
[16:24] <sil2100> uh!
[16:27] <slashd> sil2100, it's cyphermox's action
[17:24] <rbasak> bryce: https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+ref/importer-add-tests
[17:25] <rbasak> More refactoring and cleanups to come, but that should give you an idea of what's coming.
[17:25] <rbasak> You'll want to spend some time understanding the structure
[17:25] <rbasak> Diff against master please - the individual commits probably won't be helpful
[20:12] <cyphermox> marcustomlinson: PPU is done.
[20:39] <sdk> <jbicha "sdk: there are alternate depende"> That's what I tought but what would be the rationale behing installing the whole ubuntu desktop when apt installing xorg on a netinst? I mean wouldn't it be better to move those dependencies in "suggested packages" insteand of "recommended"?
[20:40] <sdk> <JanC "you can also use --no-install-re"> Thanks but that's exactly what I tried to avoid since I'll need to install each packages I need individually.
[22:32] <RAOF> <sdk "That's what I tought but what wo"> There's no difference in the dependencies between netinst and other install methods; they're backed by the same archive. The solution suggested - `apt install xorg gnome-shell-` should get you xorg without gnome-shell. Check if that set of packages is what you're after. If not, repeat, excluding another likely-looking package with `$PACKAGE-` on the end, until the set of packages is
[22:32] <RAOF> to your liking.
[22:45] <sdk> RAOF: Well, I'll try that solution even if there's a wall of packages to check. I guess I'll have some fun --dry-run'ing a few times until I find all the packages I need to exclude XD.


[01:08] <martink3> apw: finally got around to file #1559609 regarding arcmsr timeouts with ARC1882 RAID controllers... hope the bug report is useful enough to get things going
[06:09] <alkisg> I'm continuing trying to troubleshoot https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1259861
[06:09] <alkisg> My plan is to do a small bisection by using the kernels from the mainline ppa, and see when it broke
[06:10] <alkisg> It was after 3.2 and before 3.8, I'll pinpoint it better in a while
[06:10] <alkisg> Then I'm planning to compare the configs of those two kernels, because I'm thinking it might be a config issue and not a source code (ipconfig.c) issue that caused it
[06:10] <alkisg> If you guys have some better suggestion, please ping me :)
[06:13] <alkisg> Erm, do the mainline ppa kernels use a different config from the ones shipped in the ubuntu archives + live CDs?
[06:23] <alkisg> Trying with Ubuntu 12.04 and the stock kernels,
[06:23] <alkisg> 3.5 does not have the issue, while 3.8 does
[06:23] <alkisg> So the problem was somewhere after Ubuntu 12.10 and before 13.04
[06:23] <alkisg> I'll compare the configs now
[06:26] <alkisg> 3.5: # CONFIG_IP_PNP is not set
[06:26] <alkisg> 3.8: CONFIG_IP_PNP=y
[06:26] <alkisg> CONFIG_IP_PNP_DHCP=y
[06:27] <alkisg> Is it reasonable to ask that to be reverted?
[06:32] <alkisg> Also, can I find the Ubuntu config commit for that, so that I can read the reasoning behind it?
[06:32] <alkisg> E.g. maybe it's needed for some ARM devices, if so it could be conditionally enabled only on those arches...
[07:10] <alkisg> I think this is the relevant upstream commit: https://github.com/torvalds/linux/commit/c1b362e3b4d331a63915b268a33207311a439d60#diff-364c3610ebc6899c22148ba10636c71c
[08:13] <alkisg> So, Ubuntu and openSUSE have CONFIG_IP_PNP=y and experience the issue
[08:13] <alkisg> Debian and Fedora don't have it
[10:14] <apw> alkisg: put that info in the bug, needs thinking about indeed
[10:19] <alkisg> apw, I did put it
[10:19] <alkisg> Thank you :)
[10:20] <apw> ok so the real issue is that the initramfs and kernel option overlap
[10:20] <alkisg> Well, it's the same option, it can be handled in 2 places
[10:20] <alkisg> So if the kernel was smart enough to avoid the delay if it can't initialize the NIC, all would be fine
[10:21] <alkisg> Or if the Ubuntu kernel didn't include CONFIG_IP_PNP/ipconfig.c when it doesn't need it
[10:21] <alkisg> (does anyone need it? or was it put there by just copying the new upstream kernel defaults?)
[10:23] <alkisg> I think it would be best to unset CONFIG_IP_PNP in Ubuntu, like Debian and Fedora do, and also report the ipconfig.c issue upstream to the kernel, to be fixed by whoever maintains it, without any hurry...
[10:23] <apw> it would likely sound useful and get enabled
[10:26] <alkisg> I imagine that it's only useful when the modules are built-in, so if someone is building their own kernel, they may as well set CONFIG_IP_PNP themselves...
[10:26] <alkisg> Now it would only be useful in virtio environments, right? (and I'm not sure if all the NFS support is configured...)
[10:27] <alkisg> ogra_: have you ever needed to netboot any boards without using an initramfs? I.e. has CONFIG_IP_PNP=y ever been useful to you?
[10:28] <alkisg> (it's causing 10 sec delay to ltsp clients)
[10:50] <ogra_> no, never
[10:51] <alkisg> Ty :)
[10:54] <ogra_> which doesnt mean there are no people using it like that indeed
[10:56] <alkisg> Sure, but if we can't find anyone, maybe it'd be better to disable it like other distros do
[10:57] <alkisg> Our initramfs now is close to 40 MB, it doesn't help to include all options...
[10:57] <ogra_> iirc (apw might remember better) there was once a task "make ubuntu bootable without initrd" ... not sure if that has ever been mandatory or was just a nice-to-have thing
[10:57] <alkisg> And I'm not sure it even works; I put ip=dhcp under kvm, with virtio drivers built-in, and it does nothing
[10:58] <ogra_> well, i'm pretty sure our cloud setup uses it that way
[10:58] <alkisg> Without an initramfs?
[10:58] <ogra_> no
[10:58] <ogra_> kvm based netboot
[10:59] <alkisg> The clould setup doesn't use an initramfs?!
[10:59] <ogra_> (with initrd, but it surely does more than nothing ;) )
[11:00] <alkisg> When an initrd is present, the ip=xxx and other netbooting options are handled there...
[11:00] <ogra_> right
[11:00] <alkisg> So the cloud people don't need CONFIG_IP_PNP either
[11:00] <ogra_> oh, you meant you used kvm without initrd and virtio builtin
[11:01] <alkisg> I'm just trying to see if CONFIG_IP_PNP actually works or if anyone's using it, because if it doesn't, the easiest solution would be to disable it
[11:03] <alkisg> (it is disabled in other distros and it was disabled up to 12.04.1)
[11:04] <ogra_> if you are lucky there is some papertrail about why it was enabled
[11:04] <alkisg> ogra_: https://github.com/torvalds/linux/commit/c1b362e3b4d331a63915b268a33207311a439d60#diff-364c3610ebc6899c22148ba10636c71c
[11:04] <alkisg> I think we just followed hpa's upstream commit
[11:05] <ogra_> thats more like 8.10 though
[11:05] <ogra_> quite old
[11:06] <tjaalton> xenial server image doesn't support usb keyboards? that's a surprise :)
[11:06] <ogra_> if we had it disabled til 12.04 it sounds like some decision on your side
[11:06] <ogra_> tjaalton, yeah, convergence ... its all touchscreen or nothing now :P
[11:07] <tjaalton> bummer
[11:07] <apw> ogra_, we did a full review and enable a lot of stuff, so it may not have been a specific decision on that option as much as part of a general cleanup
[11:07] <apw> but if the initramfs does this and does it better, we may well be wrong in having it enabled
[11:07] <ogra_> apw, well, thats the decision i mean5t then ;)
[11:08] <ogra_> if we know it just came in with housekeeping it is easy to decide to disable it again
[11:08] <alkisg> Note that we still have CONFIG_IP_PNP_BOOTP and CONFIG_IP_PNP_RARP unset, which is different from upstream, so yup some thought went into that
[11:11] <alkisg> Is there a bazaar branch for the kernel config, where we could pinpoint that commit and read the commit message?
[11:11] <ogra_> has always been kernel.ubuntu.com i think
[11:12] <alkisg> apw, comparing upstream with our config, I see e.g. CONFIG_E1000=y in upstream while CONFIG_E1000=m in ours. Same for realteks and other common NICs.
[11:12] <tjaalton> trying to install a gen8 hp microserver, 1404/1510 images just have syslinux output "boot error", and xenial has no usb.. oh well
[11:13] <alkisg> apw, so I don't think CONFIG_IP_PNP helps us if we don't also include those...
[11:13] <apw> alkisg, yep, and if one is not building those in, it is likely IP_PNP is an error, especially as initramfs will sort them out
[11:14] <alkisg> apw, cool, who do you ping to remove it? could you do it? I can do whatever tests are needed... :)
[11:14] <alkisg> *do we
[11:19] <apw> alkisg, oh i have the power, i need to think about it and check feature parity
[11:19] <apw> remind me of the bug #
[11:21] <alkisg> apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1259861
[11:21] <apw> that is confirmed as "with kernel command line ip= option
[11:21] <apw> right ?
[11:22] <alkisg> Right
[11:22] <apw> and i think it is also confirmed as a 12s delay
[11:22]  * apw fixes the title
[11:22] <alkisg> It's from 2 to 12
[11:22] <alkisg> So maybe it's 10
[11:23] <alkisg> I don't know if it's started at 2 or at 0 though (in which case it would be 12)
[11:23] <alkisg> Maybe it's this one:   #define CONF_CARRIER_TIMEOUT	120000	/* Wait for carrier timeout */
[11:24] <apw> anyhow, its all about feature parity, if initramfs-tools does more than the kernel we are good we can just wack the option
[11:24] <apw> if not we may have to get more creative
[11:25] <alkisg> initramfs-tools certainly does more than the kernel
[11:25] <alkisg> It also supports other protocols that the kernel doesn't, e.g. NBD
[11:27] <ogra_> only if you have the module
[11:28] <apw> alkisg, yeah its if it does less in any way that someone could be using
[11:28] <ogra_> (i dont think it is there by default)
[11:28] <apw> that is really the only thing that matters
[11:31] <alkisg> AFAIK the initramfs ip= handling is in all cases superior to the in-kernel ip= handling
[11:32] <alkisg> The only case that I imagine someone would prefer the in-kernel one, is if he didn't use an initramfs at all
[11:33] <alkisg> apw, thank you for working on this
[11:33]  * alkisg waves, later...
[11:34] <TJ-> for reference, that change to the common config was introduced by 3166c8772 in March 2010
[11:35] <TJ-> (for Quantal)
[11:36] <TJ-> before that it was only used for armhf highbank arch
[11:41] <TJ-> correction, 301b4bb in 13.10 (Saucy)
[12:24] <tjaalton> 14.04 desktop works on ths microserver, so there must be some usb diff with server/desktop kernels that cause non-working usb with server image.. and I'm not the only one it seems
[12:26] <tjaalton> is usbhid included in base kernel?
[12:26] <tjaalton> doesn't look like it
[12:27] <tjaalton> https://blog.al4.co.nz/2014/12/ubuntu-14-04-no-usb-keyboard-after-upgrading-kernel/
[12:27] <tjaalton> so that's why 14.04.1 works and newer ones don't
[12:33] <tjaalton> filed a bug
[13:15] <apw> tjaalton, whats the number ...
[13:17] <apw> tjaalton, that blog post says that a server won't work without linux-image-extra which is correct
[13:17] <apw> tjaalton, -extra is for hardware support essentially, beyond what is in a virt image
[13:41] <apw> alkisg_away, ok ... i think i can see no reason to not turn this off for sure in xenial, so i have done that for the first upload after beta
[13:41] <apw> alkisg_away, if that does not throw regressions then we can consider it for sru, do remind me in a week or so
[13:41] <alkisg> apw, thanks a lot, I'll do so
[13:42] <apw> that means it will be off in linux-lts-x in trusty as well when that propogates back, so not the next one but the one after
[13:42] <alkisg> Will it reach even precise-lts-trusty in the long run?
[13:43] <tjaalton> apw: so server image has -extra too? then my bug description is all wrong :)
[13:43] <apw> tjaalton, yes, we only have linux-generic and linux-virtual, servers use linux-generic
[13:44] <tjaalton> ok
[13:44] <apw> the only way to install akernle without linux-image-extra and get updates is to use linux-virtual
[13:44]  * alkisg managed to get down the 16.04 ltsp client boot process from 45 seconds to 12 seconds, same as in 12.04... there were 4 unrelated timeouts involved :)
[13:44] <apw> linux-server points to linux-generic
[13:44] <apw> alkisg, nice
[13:44] <tjaalton> bug 1559692
[13:44] <tjaalton> hehe
[13:45] <tjaalton> can't update it right now
[13:47] <tjaalton> if there's something to try on cmdline i'll give that a go later
[13:58] <apw> tjaalton, are you saying the live desktop images work ok for xenial images but d-i ones do not ?
[13:59] <tjaalton> apw: i didn't try xenial live, had only trusty available
[14:00] <apw> it is more likely that there is something missing from a udeb if live works and server images not
[14:00] <apw> but we'd want to compare liek with like
[14:00] <apw> xenial live with xenial server
[14:00] <tjaalton> sure, that's what i'll test next
[14:01] <tjaalton> in about six hours from now :)
[16:00] <martink3> bug 1559609
[16:03] <martink3> apw, this is the bug I filed upon your suggestion
[16:28] <apw> martink3, is that the one where there is a couple of small 4.5 ocmmits which might make it work ?
[16:32] <martink3> yes, exactly. it should be sufficient to take the 4.5 commits regarding arcmsr.h and arcmsr_hba.c, and then it should work.
[16:33] <martink3> I was about to try to see if the current xenial kernel compiles with just these two changes, but then I had some dependencies issues for the build chain. I am trying it again using a recent xenial to build a -test1 with those changes
[16:48] <apw> martink3, i should be able to make you a test kernel if you can test it
[16:54] <martink3> apw, happy to do so!
[17:40] <apw> martink3, that (btw) is not two changes, that is the diff from v4.4 to v4.5 for those two files, which is 6-8 changes
[17:41] <apw> martink3, kernels will be here in a few mins, they are pushing now -- http://people.canonical.com/~apw/lp1559609-xenial/
[17:42] <martink3> apw, you are right. I didn't see it this way, but you are right, it's a couple of driver versions higher in areca's version numbering scheme, and they (areca) had some trouble getting anything accepted in mainline for some time
[17:42] <apw> upstream always resists, it is their job
[17:44] <martink3> I agree, and the driver became more readable, too
[17:48] <martink3> apw, I think all files arrived now, I will get them now...
[17:48] <apw> martink3, still pushing -extra, don't be fooled
[17:49] <apw> martink3, and you only need the arch you are, i386 or amd64
[17:49] <apw> likely just linux-image and linux-image-extra for that arch
[17:55] <apw> ugg my uplink sucks today
[17:55] <martink3> but for downlink, traffic is no consideration, right? If so, then I will just wget your whole lp1559609-xenial/ folder ...
[17:57] <apw> martink3, you can hammer my fileserver all you want
[17:57] <apw> the amd64 bits look complete, i386 -extra is still pusin
[17:58] <martink3> amd64 is what I need. will try it in a virtual machine first, and then I hope I can get my hands on one of the real fileservers soon for this test
[18:00] <apw> martink3, push complete
[18:02] <apw> martink3, please report your testing in the bug, and let me know here you did so
[18:07] <martink3> apw, got the files, will do, thanks so far!
[18:32] <lamont> jsalisbury: updated 1543863 for our sadness
[18:33] <apw> lp: #1543863
[18:42] <lamont> apw: also, I fail at typing bug numbers
[18:42] <lamont> lp: #1543683
[18:42] <lamont> yeah that one
[18:43] <lamont> jsalisbury: 1543683 that is
[21:02] <tjaalton> apw: confirmed, xenial desktop image has working input devices and server doesn't
[21:30] <apw> tjaalton: ack could you update the bug to that effwct pls
[21:31] <tjaalton> done
[21:31] <tjaalton> i checked the obvious udebs and they look fine


[18:39] <xu-irc41w> does anyone here have any experience modifying chicago95 themes?  doing this with raw css files isn't very easy.  i don't know what elements correspond to which variable.
[18:39] <xu-irc41w> i tried using oomox, but it doesn't seem to do what i need