[00:48] <vorian> ScottK: awesome! thanks very much :)
[00:49] <Laney> Bah, can I use dh_installinit with an upstream provided init file? All the docs I can see need one in debian/
[00:56] <emgent> hi vorian good luke :)
[00:56] <vorian> thanks, same to you :)
[00:56] <emgent> hehe thanks :)
[00:58] <crimsun> RAOF: thanks
[01:00] <RainCT> TheMuso, \sh: bug 239719 is waiting for you when you have time to look at it (with minimal debdiff now) :)
[01:00] <RAOF> crimsun: No problem.
[01:11] <TheMuso> RainCT: Ok lookign now, since I'm in an SRU mode.
[01:12] <TheMuso> RainCT: Is this in intrepid?
[01:15] <TheMuso> RainCT: Why did you not include the changes to youtranslate and Makefile.youtranslate in a patch, as you did add a patch system...
[01:16] <TheMuso> Having some changes in the .diff.gz and some in a patch file doesn't make sense.
[01:16] <TheMuso> RainCT: ^^
[01:19] <RainCT> TheMuso: they are in a patch
[01:19] <TheMuso> RainCT: Um doesn't appear that way to me.
[01:19] <RainCT> TheMuso: 02_fix_ftbfs.dpatch
[01:19] <cody-somerville> jono, ping
[01:21] <RainCT> TheMuso: where are you looking?
[01:21] <RainCT> TheMuso: (and yes, those changes are in intrepid together with a new upstream version and many other packaging improvements)
[01:21] <TheMuso> RainCT: Sorry, I misread the patch.
[01:21] <LaserJock> cody-somerville: isn't it 1am in London?
[01:22] <TheMuso> RainCT: ACKing.
[01:22] <RainCT> TheMuso: great, thanks :)
[01:22] <cody-somerville> LaserJock, aye
[01:22] <TheMuso> RainCT: One change, hardy-proposed and not hardy
[01:24] <RainCT> TheMuso: argh, right
[01:24] <RainCT> I had to do something wrong :P
[01:24] <TheMuso> RainCT: heh
[01:24] <LaserJock> has anybody been thinking about building an Ubuntu PTS?
[01:26] <RainCT> LaserJock: what are you missing in LP?
[01:26] <LaserJock> quit a bit of stuff
[01:28] <emgent> hello people :)
[01:32] <LaserJock> RainCT: sorry, was afk
[01:32] <RainCT> np
[01:33] <LaserJock> things that come to mind are stuff from qa.ubuntuwire.com (unmet deps, FTBFS, NBS, etc.)
[01:33] <LaserJock> right now what I'd like is a package whiteboard too
[01:33] <LaserJock> so we can leave "notes" for each other
[01:34] <LaserJock> LP also doesn't track upstream versions
[01:34] <LaserJock> it would be good to have the Ubuntu version, Debian Version, and Upstream Version easily viewable
[01:35] <RainCT> LaserJock: Right. So basically an overview page for all the QA stuff affecting a single package
[01:35] <LaserJock> pretty much yeah
[01:35] <LaserJock> there would be a bit more than just QA stuff
[01:35] <RainCT> sounds useful
[01:35] <LaserJock> but a lot of it would be yeah
[01:39] <wgrant> LaserJock: I've often thought about building something like the PTS, but uni has grabbed me this holidays so my time is rather limited.
[01:40] <LaserJock> wgrant: I talked with ogasawara today and she seemed to want to work on something like that
[01:40] <LaserJock> and I've wanted to for a long time
[01:41] <wgrant> LP really should do it.
[01:41] <LaserJock> some of it
[01:41] <wgrant> But there's no chance of that until it's Freed.
[01:41] <LaserJock> even then
[01:41] <LaserJock> a lot of it is fairly specific to Ubuntu
[01:42] <LaserJock> I would like to see a package whiteboard in LP though
[01:42] <RainCT> well, good night guys
[01:42] <LaserJock> night
[01:43] <wgrant> LaserJock: That should be very easy to implement, and would be really useful... I wonder if they can be convinced to do it soon after 2.0.
[01:44] <LaserJock> wgrant: perhaps
[01:44] <LaserJock> like today I could have used it
[01:44] <LaserJock> Debian is currently trying to figure out a library issue
[01:45] <LaserJock> but in the mean time I don't want people merging or trying to "fix" dependent packages
[01:45] <LaserJock> it feels a tad weird to file a bug to have work *not* done :-)
[01:47] <wgrant> I've seen it done a number of times.
[01:47] <wgrant> "Don't merge X from Debian unstable"
[01:47] <LaserJock> it also implies that people actually look for those books
[01:47] <wgrant> Bugs?
[01:48] <LaserJock> bah
[01:48] <LaserJock> distracted, sorry
[01:48] <wgrant> I always do before I upload - I hope everybody else does.
[01:48] <wgrant> I've only clobber one contributor's merge before.
[01:48] <RAOF> Certainly for merges.
[01:48] <LaserJock> well, this isn't a merge
[01:48] <LaserJock> it'd be changing build deps
[01:49] <wgrant> Even so, people should be checking for other bugs they can fix in that upload.
[01:49] <LaserJock> *should* ...
[01:49] <wgrant> Right.
[01:49] <crimsun> well, if reasonably, yes.
[01:50] <crimsun> I didn't bother with several, e.g., flashplugin-nonfree.
[01:50] <crimsun> "closes foo, bar, baz, a, b, c, ..." is a bit tedious.
[01:52] <RAOF> Oh, thinking of which, I haven't done anything except upload to intrepid; it needs uploading to hardy-proposed, etc, right?
[01:52] <RAOF> Where 'it' is flashplugin-nonfree, obviously.
[01:53] <crimsun> RAOF: I'd hold off on that.
[01:53] <wgrant> Flash 10?
[01:53] <RAOF> Yay!  Less work.
[01:53] <crimsun> there's no confirmation that beta 2 resolves any of the security issues currently present in hardy's.
[01:54] <RAOF> Beta2 does still manage to consume a core, though.
[01:54] <crimsun> yes, very effective DoS.
[01:55] <wgrant> So multicore is a good security measure!
[01:55] <RAOF> Less effective than gnash, which has a tendency to consume all memory.
[02:19] <emgent> ember: ping about wordpress
[02:20] <ember> emgent ?
[02:20] <ember> err.. i didn't saw sispoty comment
[02:20] <ember> i'm gonna have a look at it emgent
[02:20] <ember> thanks
[02:21] <emgent> ok nice, Thanks to you
[02:27] <emgent> argh stupid comment on dad main -.-
[02:27] <emgent> "school girls xxx"
[02:28] <ember> lol
[02:29] <emgent> i go to clean it.
[02:29] <LaserJock> emgent: I guess perhaps it'd get people to do more merges, but I'm pretty sure that's not the way we want to do it
[02:30] <emgent> :)
[02:31] <nxvl> \o\ <o\ <o> /o> /o/
[02:31] <emgent> nxvl: what is it ?
[02:32]  * nxvl dancing
[02:32] <nxvl> but it look more like steps :S
[02:32] <nxvl> looks*
[02:32] <emgent> lol, you are crazy :)
[02:33] <ajmitch> or someone with a drunken xml fetish :)
[02:33] <emgent> hahaha
[02:33] <nxvl> heh
[02:33] <nxvl> emgent: nop, i'm boried, i'm in classes
[02:37] <nxvl> got dammit, my class already ended and my girlfriend ends in an hour
[02:48] <Gralco> i don't understand why vimtutor isn't working for me
[02:51] <persia> I've got a couple build errors with "/usr/include/sys/syslog.h:88: error: 'NULL' undeclared here (not in a function)".  Would someone who has worked around this before be willing to give me a pointer?
[03:04] <RAOF> nxvl: Your girlfriend ends in an hour?  Man, what're you doing on IRC!? :)
[03:25] <emgent> RAOF: lol
[03:25] <nxvl> RAOF: classes
[03:26] <nxvl> she is already here!!
[03:26] <nxvl> im gone
[03:26] <RAOF> Yay!
[03:26] <nxvl> read you!
[03:30] <bddebian> Heya gang
[03:41] <cody-somerville> Heya
[03:41] <bddebian> Hi cody-somerville
[03:47] <emgent> heya bddebian cody-somerville
[03:49] <cody-somerville> lo
[03:56] <bddebian> Hi emgent
[04:15]  * mneptok staples cody-somerville to his thigh
[04:15] <cody-somerville> ack!
[04:16] <mneptok> happy canada day! (late)
[04:17] <mneptok> have a cold O'Keefe's served in a pewter toque!
[07:06] <\sh> bug #239719 acked ready for -proposed
[07:20] <dholbach> good morning
[07:24] <AstralJava> Morning.
[07:24] <dholbach> hi AstralJava
[07:25] <AstralJava> Hello dholbach! :)
[07:33] <nxvl> dholbach: you have make a lot of videos the same day, but they are being released periodically, don't you?
[07:33] <dholbach> over two days, but yeah
[07:33] <dholbach> hi DktrKranz
[07:33] <nxvl> so, they are more comming?
[07:33] <DktrKranz> hi dholbach
[07:34] <dholbach> I think one more
[07:34] <dholbach> for now
[07:37] <nxvl> :D
[07:37] <nxvl> they are really cool btw
[07:40] <dholbach> thanks a lot
[07:40] <nxvl> i always use them on my packaging jams
[07:45] <nxvl> they help me to give the participants a quick overview about the process
[07:45] <nxvl> and then start to do the same process step by step with them
[07:45] <nxvl> :D
[07:45] <dholbach> I'm very glad they're useful
[07:45] <dholbach> we should do some more of them as a team: http://wiki.ubuntu.com/MOTU/Videos
[07:46] <nxvl> i will be glad
[07:46] <txwikinger> cool
[07:46] <dholbach> and even if they're not in a camera+screencast format, having screencast only would be nice too, maybe with some mixed in audio
[07:47] <dholbach> luckily https://wiki.ubuntu.com/ScreencastTeam/RecordingScreencasts has some information about how to do that
[07:47] <nxvl> yeah, i can find a camera
[07:47] <nxvl> or
[07:47] <nxvl> as you say just do screencast
[07:47] <dholbach> with added audio it should be quite good
[07:47] <nxvl> dholbach: how do you find the idea of translating them?
[07:47] <nxvl> yeah, of course
[07:48] <dholbach> nxvl: I'm all for it!
[07:48] <txwikinger> translating can be difficult
[07:48] <dholbach> sharing the love
[07:48] <nxvl> with translating i mean record same process in spanish, not just edit the audio
[07:48] <txwikinger> you have to basically redo them 100%
[07:48] <txwikinger> you want to use the screen localised too in that case
[07:49] <txwikinger> or if you want to do it the easy way, you could just add subtitles
[07:49] <nxvl> well
[07:49] <nxvl> to read subtitles plus read the commands
[07:49] <nxvl> is quite hard
[07:50] <nxvl> dholbach: or you were thinking on editing the audio or writing subtitles?
[07:50] <dholbach> no, redoing them
[07:50] <nxvl> ok
[07:50] <nxvl> yes
[07:50] <nxvl> i find it better
[07:50] <nxvl> i will try to find some equipment this weekend
[07:51]  * dholbach hugs nxvl
[07:51] <dholbach> awesome awesome awesome
[07:51]  * nxvl hugs dholbach back
[07:51] <nxvl> now
[07:51] <nxvl> i need to sleep
[07:51] <dholbach> sleep tight :)
[07:51] <nxvl> i need to fight with php code on the morning
[07:51] <nxvl> btw
[07:51] <nxvl> i hate php
[07:51] <txwikinger> good idea (even I just got up) :D
[07:51] <nxvl> txwikinger: 2 am here
[07:52] <txwikinger> well.. I got up 5am this morning
[07:52] <nxvl> dholbach: we should write some documentation on "translating the videos" or "doing videos" to have kind of a standard
[07:52] <dholbach> nxvl: just add it to https://wiki.ubuntu.com/MOTU/Videos
[07:53] <nxvl> dholbach: but we can coordinate it by e-mail
[07:53] <dholbach> sure
[07:53] <nxvl> dholbach: yes, i mean, for more people to do them on their languages
[07:53] <dholbach> right
[07:53] <nxvl> i will send you and jono an e-mail this weekend with it
[07:53] <dholbach> alright
[07:53] <dholbach> thanks Nicolas
[07:53] <nxvl> have a good day!
[07:54] <dholbach> gracias
[07:54] <nxvl> dholbach: there is nothing to thank :D
[07:54] <nxvl> just a lot of love to give to new contributors
[07:54] <dholbach> exactly :)
[07:54] <nxvl> now i'm gone
[07:59] <Iulian> G'morning
[08:55] <slytherin> Can someone please clear xml-commons-external source from queue? I plan to upload batik 1.7 to revu today which requires xml-commons-external.
[08:57] <persia> slytherin: You want it processed from the source NEW queue?
[08:58] <slytherin> persia: Yes, that is what I meant. In case you didn't haven't yet yesterday's channel logs, I could build batik 1.7 successfully yesterday.
[08:59] <persia> slytherin: Right.  Only the archive-admins can do source NEW, and this isn't the best channel in which to contact them.  That said, source NEW is hard, as it requires full license checks, etc.  It's typically done last of the archive-admin tasks, in any time remaining.
[09:00] <slytherin> persia: Ok. I will upload to revu any way so that you or geser can review it throughly. I will add a note about xml-commons-external dependency.
[09:03] <persia> slytherin: Batik is a NEW package?  I thought we had it in the repos.
[09:04] <slytherin> persia: not a new package. Updated. But the package source needs to be repackages which was also case with 1.6. And I have added few patches for build to complete properly. So I thought revu is best place for review.
[09:04] <persia> slytherin: We do have it in the repos.  Please don't upload to REVU.  Please attach the debdiff to a bug (or a diff.gz if it is a new upstream version).
[09:05] <persia> slytherin: Yes, but you don't need two people: you can just put it in the sponsors queue as normal.
[09:05] <slytherin> persia: but then I will also have to upload the repackages source right?
[09:05] <slytherin> /repackages/repackaged
[09:06] <persia> slytherin: No, just the diff.gz.  You should encode the repackaging in debian/rules get-orig-source, and document it in README.Debian-source
[09:06] <slytherin> persia: It is already documented in README.Debian-source. I will see if I can encode it in get-orig-source. That is a bit harder.
[09:09] <slytherin> persia: Do you have any example repackaging encoded in get-orig-source? Please note that I also need to do 'svn export <certain url>' in this case.
[09:11] <RainCT> slytherin: adblock-plus, for example, has a get-orig-source where it does a "bzr export"
[09:11] <slytherin> RainCT: Cool. Thanks. I will take a look.
[09:45] <Riddell> Iulian: giver has no dependencies
[09:47] <Riddell> Iulian: bug 245431
[10:01] <Iulian> Riddell: Yes, I'm preparing an upload to Debian with the fix.
[10:02] <Iulian> Riddell: It should be in Debian in a couple of days and then we can sync.
[10:03] <Iulian> Riddell: I can also make an upload to Ubuntu right now with some fixes but I think we should wait for Debian.
[10:05] <Riddell> Iulian: cool, thanks
[10:07] <Iulian> Riddell: So, what do you prefer? Wait for Debian or prepare an upload to Ubuntu today?
[10:08] <Riddell> waiting is fine with me
[10:09] <Iulian> Riddell: Okay
[10:15] <sebner> huhu jono
[10:16] <sebner> dholbach: thanks for ACKing my syncs and sry for the inconvenience
[10:16] <sebner> DktrKranz: now the 200 are full ;)
[10:16] <sebner> huhu sistpoty|work
[10:16] <sistpoty|work> hi folks
[10:16] <sistpoty|work> hi sebner
[10:17] <sebner> morning afflux ;)
[10:17] <afflux> hi sebner :)
[10:20] <DktrKranz> sebner: the more you do the more I'll beat you when I catch you :D
[10:21] <wgrant> ScottK: Are you this SpecialK that I see uploading lots of backports?
[10:58] <norsetto> Laney: giving up on btx?
[10:58] <Laney> norsetto: Yes, I found some problems with the upstream code that make it too much work to include.
[10:59] <Laney> And that fact that the -config UI must run as root will surely make that one more difficult to accept too.
[11:00] <Laney> I think it needs a few more releases to mature before it'll be ready
[11:02] <norsetto> Laney: well, don't nuke it then, you may want to keep it there so that people know you are working on it, and once it will be ready you restart uploading
[11:03] <Laney> norsetto: Righto, just didn't want to clutter up the list
[11:03] <Laney> norsetto: Thanks for your review too, it helped me come to this conclusion :)
[11:03] <norsetto> Laney: I don't think thats an issue, check with sistpoty or RainCT on anyone else with the revu gang to be sure
[11:04] <norsetto> Laney: glad I could help
[11:10] <sistpoty|work> from df on spooky (revu's host): /dev/md0              70568272  30367488  36644336  46% /srv
[11:10] <sistpoty|work> so not a problem in regards to disk space atm :)
[11:12] <Laney> sistpoty|work: I was more thinking visual screen space, or if someone decided to review it ;)
[11:47] <RainCT> Laney: well, you can archive it, then it won't show up on the front page
[11:48] <RainCT> uhm.. that was a fast answer.. :P
[11:48] <sistpoty|work> heh
[11:48] <Laney> RainCT: Up to you, btnx and btnx-config. I'm not going to work on them for this upstream version at least so no point on them being on there unless somoene else takes it up.
[11:49] <RainCT> ok, done
[11:49] <RainCT> sistpoty|work: btw, REVU converts URLs into links now :)
[11:49] <RainCT> (in comments)
[11:49] <Laney> Thanks
[11:49] <sistpoty|work> cool RainCT :)
[11:57] <Laney> siretart: Is it OK to do the ffmpeg-free rebuilds?
[12:05] <Laibsch> Hi
[12:06] <Laibsch> I am trying to use pbuilder to verify correct build of a package
[12:06] <Laibsch> but it fails and I don't understand why, or rather where I am deviating from standard practice http://rafb.net/p/D7HXEU43.html
[12:06] <persia> Laibsch: Are you encountering an issue?
[12:06] <Laibsch> of course I am ;-)
[12:07] <Laibsch> Why does pbuilder want to call mknod?
[12:08] <Festor>
[12:08] <Festor> One question, I'm doing a package that does not exist in debian. I should use 1.2-0ubuntu1 or 1.2-1ubuntu1
[12:08] <Festor> ?
[12:08] <directhex> Festor, 0
[12:08] <Festor> ok, thanks
[12:09] <directhex> Festor, the X in XubuntuY refers to the debian revision - 0 for not-in-debian
[12:09] <Festor> then 1.2-0?
[12:10] <Laibsch> no
[12:10] <Festor> ehh
[12:10] <Laibsch> 1.2-0ubuntu1
[12:10] <Laibsch> AFAIK
[12:10] <persia> Laibsch: I believe pbuilder is to be run as root.  If you want to build without root access, you might investigate sbuild, which does the root bits in a user-invisible way (and with LVM, in a filesystem idempotent way)
[12:10] <Festor> but ubuntu1 is the debian revision, no?
[12:10] <Festor> and my package does not exist in debian
[12:10] <Laibsch> persia: One is supposed to build as root?
[12:10] <Laibsch> I find that hard to believe
[12:11] <Laibsch> How can I be sure not to f*ck up my system
[12:11] <directhex> Festor, it enables debian to take the package
[12:11] <Festor> ok
[12:11] <Laibsch> Festor: 0ubuntu -> not in debian (0), version 1 in ubuntu (ubuntu1)
[12:11] <Laibsch> Festor: 0ubuntu1 -> not in debian (0), version 1 in ubuntu (ubuntu1)
[12:11] <directhex> Festor, 0ubuntu1 means "this is the first ubuntu-specific version of a package with a debian revision of 0 (not at all)"
[12:11] <persia> Laibsch: Use sbuild+LVM to be sure not to affect the system.  pbuilder does a fairly good job, but as it's in the same filesystem, one can break out more easily than with sbuild+LVM.  That said, chroot is pretty good these days.
[12:12] <directhex> Festor, if debian adopts your package, then they start their numbering at 1
[12:12]  * Laibsch does not really feel like setting up an LVM just to build a package
[12:12] <Festor> then 1.2-0ubuntu0? or 1.2-0ubuntu
[12:12] <directhex> Festor, and since syncs are better than merges, you want the first debian version to supercede the first ubuntu version
[12:12] <Laibsch> (13:10:10) Laibsch: 1.2-0ubuntu1
[12:12] <persia> Laibsch: In that case, you need to trust pbuilder to behave.
[12:13] <Laibsch> Festor: you said it yourself
[12:13]  * persia only has ~20GB under LVM, not everything
[12:13] <Festor> sorry
[12:13] <directhex> Festor, your package is debian revision 0 (non existent), ubuntu revision 1 thereof (first version to exist)
[12:13] <directhex> Festor, so 0ubuntu1. see?
[12:13] <Festor> ok, ok, thanks for all
[12:14] <Festor> This package is a amsn plugin
[12:15] <Festor> If I want to send to Intrepid should I put a bug in amsn?
[12:16] <Festor> Forget, I am reading the wiki ubuntu
[12:22] <jcfp> is there a way to get dh_pysupport to also create optimized *.pyo files rather than just *.pyc?
[12:23] <persia> jcfp: It would require changes to python-support, as the compilation happens at install-time.
[12:24] <jcfp> persia: so there's not some easy switch to tell it to just do that
[12:24] <persia> jcfp: Nope.
[12:24] <jcfp> bummer. guess I'll have to use postinstall/prerm scripts then
[12:24] <persia> Or, at least not in dh_pysupport.  I don't pretend to actually understand the details of python-support: that might have such an option, which would apply system-wide.
[12:25] <persia> jcfp: You really don't want to do that.
[12:25] <lifeless> huh
[12:25] <jcfp> persia: any better way?
[12:25] <lifeless> I thought python-support did pyo files
[12:25] <jcfp> lifeless: only creates pyc here?
[12:25] <persia> jcfp: Let's look at this differently: why do you need optimised compilation?
[12:26] <persia> lifeless: There may be such an option, but it's not package-specific.
[12:26] <jcfp> persia: upstream suggested doing so may give better performance?
[12:26] <siretart> Laney: sorry?
[12:27] <Laney> siretart: I saw you requested the deletion of ffmpeg, was just wondering if it was OK to request rebuilds of the NBS
[12:27] <lifeless> interesting, no pyo's
[12:27] <lifeless> that will suck when bzr starts running with -O by default
[12:27] <persia> jcfp: I'm under the impression that the local .pyc files are customised for the system on which they are installed already, despite their extension.  Please benchmark with some local tests: if you can find a signficant increase, it may be worth looking into it more deeply.  Most likely, it won't matter.
[12:28] <persia> lifeless: You also might want to test: it may be that the python-support local compilation at install time is sufficient for your needs.
[12:28] <lifeless> persia: I think you are missing some context :)
[12:28] <jcfp> btw, there is /etc/python/debian_config but changes there dont seem to have any effect on dh_pysupport
[12:29] <lifeless> persia: bzr is looking at making 'bzr' run with python -O rather than plain python
[12:29] <lifeless> persia: this will cause .pyc files to not be used
[12:29] <lifeless> persia: and that matters because users cannot write .pyo files to /usr/lib, so every invocation will have to byte compile
[12:29] <lifeless> persia: -> slow
[12:30] <jcfp> lifeless: similar stuff here, upstream by default uses -OO in the program
[12:30] <siretart> Laney: oh yes, please do!
[12:30] <Laney> siretart: Excellent, will do!
[12:30] <lifeless> jcfp: unless they have significant memory use, or compiled pyc file size, it won't make much differnece
[12:30] <persia> lifeless: Ah.  You've already investigated it :)
[12:31] <lifeless> persia: well, more than I know some parts of pythons internals :)
[12:31] <persia> lifeless: investigating in 30 seconds from memory counts :p
[12:31] <siretart> Laney: I do expect some build failures. please file bugs with patches and tell me about them. thanks!
[12:32] <persia> Anyway, if there is sufficient need for .pyo, it might be possible to do that with the python infrastructure, but since it's all common, it means optimising everything, which may break some things, and may not be a win in terms of disk-sace vs. performance for others.
[12:33] <lifeless> persia: it won't break/unbreak things - because python -O will behave the same anyhow
[12:33] <lifeless> just whether it has to JIT compile it
[12:34] <persia> lifeless: But isn't JIT of .py when .pyc is available likely to not be much faster than using .pyc directly?
[12:34] <lifeless> persia: python -O disables .pyc, thats the point.
[12:34] <jcfp> am I correct in thinking that, in order to use the currently installed pyc files, python for that program must actually be run without any optimization options or it will try to create pyo (and fail at that) every time?
[12:35] <lifeless> persia: if .pyc is available it is a big win over JIT compiling the .py
[12:35] <lifeless> jcfp: yes
[12:35] <persia> By policy, .pyc ought be available for any .py in any module on an Ubuntu system.
[12:35] <persia> scripts aren't compiled by default, so it's best to have a small script to instantiate something in a module, for performance.
[12:36] <lifeless> jcfp: for instance:
[12:36] <lifeless> strace python -O -c 'import bzrlib'
[12:36] <lifeless> ...
[12:36] <lifeless> read(5, "\"\"\"distutils.errors\n\nProvides ex"..., 4096) = 3636
[12:36] <lifeless> read(5, "", 4096)                       = 0
[12:36] <lifeless> unlink("/usr/lib/python2.5/distutils/errors.pyo") = -1 ENOENT (No such file or directory)
[12:36] <lifeless> open("/usr/lib/python2.5/distutils/errors.pyo", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0666) = -1 EACCES (Permission denied)
[12:37] <lifeless> python is really quite unfriendly to system wide installs
[12:37] <jcfp> ayay ;)
[12:37] <persia> Between this confusing optimisation issue and the recommendation to use the cheeseshop, it's annoying in several ways.
[12:38]  * lifeless loaths eggs
[12:38] <Festor> If I want to send to Intrepid my amsn plugin package should I put a bug in amsn?
[12:38] <persia> The cheeseshop provides eggs?  I thought python was supposed to be intuitive.
[12:39] <lifeless> persia: cheeseshop often has setuptools based installer links
[12:40] <persia> lifeless: Yes.  That was intended as humor.  Perhaps I oughtn't try to send you emotional content over IRC...
[12:41] <lifeless> persia: irony and sarcasm need hints
[12:42] <persia> ..orz
[12:42] <Laney> Festor: needs-packaging bugs are usually filed against ubuntu
[12:43] <Festor> Laibsch, this is not a "needs-packaging"
[12:43] <Festor> I made the package
[12:43] <Festor> I have diff.gz and orig.tar files
[12:43] <Laibsch> ???
[12:43] <Laney> Is it already in the Ubuntu archives?
[12:43] <Festor> no
[12:43] <Festor> Is a new package
[12:43] <Festor> a plugin for amsn
[12:43] <Laney> Then you'll want to follow the REVU process
[12:43] <Laney> !revu
[12:44] <persia> Festor: It's a matter of perspective.  You believe that Ubuntu needs to package this application.  You're also doing the work.  That still means it ought get a needs-packaging bug.
[12:44] <Festor> ok
[12:44] <beDrung> dholbach: ping
[12:45] <jcfp> persia, lifeless: thanks for your input, made me a bit wiser again
[12:47] <porthose> slomo: thanks for the update :)
[12:49] <norsetto> porthose: any success with bzr?
[12:50] <porthose> norsetto: havn't tried yet today give me a sec and I will try
[12:51] <porthose> norsetto: still get the same error.
[12:51] <norsetto> porthose: have you seen my email?
[12:52] <porthose> yes
[12:52] <Laney> Rebuild requests which affect a few packages: One bug or one bug per package?
[12:53] <persia> Laney: Depends on how many.  For two or three quick hits, one bug is OK.  For large sets, for which the solution is not clearly obvious, multiple bugs is preferred.
[12:54] <Laney> persia: I imagine most of them will be no-change rebuilds. For anything more complex I'll file a separate bug. There are 26 source packages affected in all
[12:54] <persia> Laney: OK.  Are you sure you need a bug?  Will they appear in NBS?
[12:54] <Laney> persia: They already are
[12:54] <persia> Ah, you're providing the debdiffs for the rebuilds?
[12:55] <Laney> persia: Yeah, I have no other way of getting things done ;)
[12:55] <persia> 26 packages is still a lot of people to poke for an NBS thing though.  I'd try to avoid having a bug have more than 4-5 tasks for now.
[12:55] <persia> what are you NBS'ing?
[12:55] <Laney> It's ffmpeg->ffmpeg-free
[12:56] <persia> Right.  That'll hit a few package subscribers.  I'm not sure we have a good way to do this now that we agreed a bug with lots of affects is bad.
[12:57] <siretart> Laney: btw, we renamed it again from ffmpeg-free to ffmpeg-debian, but that package is currently sitting in debian NEW
[12:57] <persia> Anyone have any suggestions for how Laney ought submit the diffs?
[12:57] <persia> Laney: Based on the last comment: please wait :)
[12:57] <Laney> siretart: Will that cause a problem?
[12:57] <siretart> Laney: no, the binary packages have not been renamed, and it is unclear if we want to do that for intrepid
[12:58] <siretart> Laney: for pure rebuilds there is no real point in attaching a debdiff. just file a bug, and if you want attach a buidlog
[12:58] <siretart> buildlog
[12:59] <Laney> siretart: and subscribe the sponsors, right?
[12:59] <Laney> That makes it easier to script the rebuilds
[13:00] <siretart> script the re
[13:00] <siretart> 'script the rebuilds'?
[13:01] <Laney> If I just have to attach buildlogs instead of debdiffs then I can just rebuild them all locally and not have to worry about changelogs and such
[13:01] <Laney> So just loop over all directories and run sbuild in them
[13:01] <siretart> exatly
[13:05] <Laney> Right, that's going. I'll be back later everyone, have a nice day :)
[13:14] <porthose> norsetto:  going to start over from scratch, and follow the guide step by step (in case it's something I did wrong, which it probably is).  Thanks for the help :)
[13:14] <norsetto> porthose: np, I was just worried that I had to change something on the LP side, but couldn't find any way to do it ;-)
[14:05] <siretart> yay debian Bug #489236 :)
[14:07] <persia> Nifty!
[14:08] <sistpoty|work> well... we still need to do a release first, and I still got no clearance about the parser files :(
[14:08] <sistpoty|work> s/files/file/
[14:36] <slytherin> Can someone give back libspin-java?
[14:38] <sistpoty|work> slytherin: given back
[14:38] <slytherin> sistpoty|work: Thanks.
[14:39] <sistpoty|work> slytherin: np... that was the first time I hit that shiny new button :)
[14:40] <persia> slytherin: You saw that NEW was cleared, right?
[14:40] <slytherin> persia: No. I didn't. Thanks for letting me new. :-D
[14:40] <slytherin> s/new/know
[14:43] <dholbach> beDrung: pong
[14:44] <beDrung> dholbach: i have corrected the xmms2 package.
[14:44] <beDrung> dholbach: please have a look at it.
[14:44] <dholbach> beDrung: right, I'm subscribed to the bug and got a mail for it - I'll take a look at it later on - I'm busy with a bunch of other things right now
[14:45] <dholbach> but I'll get to it
[14:45] <beDrung> thx
[14:47] <DktrKranz> dholbach: it was you who had troubles with mouse in intrepid?
[14:48] <dholbach> DktrKranz: yes, but I fixed it
[14:48] <dholbach> DktrKranz: see the xserver-xorg-input-vmmouse changelog
[14:48] <quio> Can someone please help me get my wireless working.   I have been reading Ubuntu forums and documentation to get it running and cannot figure it out.  It worked before I upgraded to 8.04 hardy.  I know the card works because if I put in an XP hard drive it works right away.  Any suggestions please?
[14:49] <DktrKranz> dholbach: don't know if it's the same problem, but I'll check when I'll be back home
[14:50] <DktrKranz> thanks
[14:50] <RainCT> quio: please ask in #ubuntu, this channel is for development
[14:50] <dholbach> DktrKranz: now my intrepid kvm is happy again
[14:50] <DktrKranz> my real hardware a bit less :)
[14:51] <DktrKranz> mh... no. definitely not my issue :/
[14:55] <slytherin> when I write a get-orig-source target in rules file, how do I test it?
[15:02] <sistpoty|work> slytherin: make -f debian/rules get-orig-source
[15:03] <SWAT> I intend to package a game and want to get into the repository. Since I'm not an official maintainer, what is the best way for me to achieve this goal? Note: I also want this to go upstream.
[15:04] <slytherin> sistpoty|work: Oh, I thought I need to use uscan
[15:04] <slytherin> SWAT which game is it?
[15:07] <SWAT> slytherin: it's not in the repo's yet
[15:09] <slytherin> SWAT: What is the name of game.
[15:13] <directhex> SWAT, games are sometimes trickier to package than other apps, as often the art resources are not Free. we need to know which game it is
[15:50] <nxvl> dholbach: i have just replied you, can you please confirm
[15:54] <ScottK> wgrant: I'm not SpecialK, but his LP id is the same as my IRC nick, so a lot of my backports get attributed to him.
[15:55] <dholbach> nxvl: cool - I got it - thanks a lot
[15:56]  * nxvl hugs dholbach and runs
[15:56] <sebner> lol
[16:09]  * sistpoty|work heads home... cya
[16:16] <highvoltage> dholbach: howdy!
[16:17] <dholbach> hi highvoltage
[16:17] <highvoltage> dholbach: I did my first debdiff yesterday, thanks to you and the video
[16:17] <dholbach> NICE
[16:17] <dholbach> good work
[16:18]  * highvoltage is really happy about it
[16:18] <highvoltage> not sure what to do next though. should I just go through launchpad and fix bugs with debdiffs for now?
[16:19] <dholbach> sounds good - there's bitesize bugs too
[16:19] <dholbach> http://wiki.ubuntu.com/SponsorshipProcess explains how to get them included in Ubuntu
[16:19] <highvoltage> ok. it's one of the bitesize bugs I did last night. will hunt more of them down
[16:20] <dholbach> excellent
[16:20] <highvoltage> ( https://bugs.launchpad.net/ubuntu/+source/pyro/+bug/178948 , for what it's worth )
[16:21] <Laney> Has anyone used the massfile tool from u-d-t before?
[16:21] <Laney> I have no idea what the purpose of the buglist-url is
[16:22] <highvoltage> "1  → 20  of 65800 pages matching "bitesize packaging" "
[16:22] <highvoltage> omg, there's lots of work there!
[16:25] <Laney> highvoltage: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize
[16:26] <highvoltage> Laney: aah, thanks
[16:30] <jpds> Laney: good question, pity the source doesn't say who wrote it
[16:30] <highvoltage> I assume some of those bugs shouldn't really be 'fixed'? (bug 90434 as an example)
[16:31] <Laney> jpds: Yeah :( I think that any packages coming up on that URL won't have bugs filed again by massfile
[16:33] <jpds> Laney: according to the Debian changelog, dholbach added the script.
[16:34] <jpds> Laney: and /usr/share/doc/ubuntu-dev-tools/examples/massfile.instructions has an example of its usage.
[16:35] <Laney> jpds: Yeah, I've got that example. Couldn't see what the url was for without source diving though
[16:35] <Laney> ah well
[16:35] <Laney> (I accidently ran it twice and filed some bugs with that example too :()
[16:35] <jpds> "We Need Man Pages" :)
[16:37] <laga> yes
[16:44] <bliZZardz> in ftbfs, pbuilder is shown in RED for i386 and amd64 - am i missing something to read here or is this possible?
[16:51] <DktrKranz> \sh SRU-related stuff, any opinion on bug 186869? It was one of our biggest issues in the past
[16:52] <DktrKranz> (and it still is)
[16:54] <ScottK> DktrKranz: My suggestion would be it's not regression, data loss, or a crash.  Put it in backports.
[16:54] <\sh> DktrKranz: well, I would say: pushing to backports, testing there, and if there are no serious regressions, copy to -updates
[16:54] <ScottK> Upstream shipped a package that had very limited functionality is not an SRU criteria.
[16:55]  * ScottK disagrees, but wouldn't block it if others want to do it that way.
[16:55] <DktrKranz> I agree with ScottK here. This was my initial interpretation, since changes were very huge (as lool pointed out).
[16:56] <bliZZardz> ScottK : in ftbs list, pbuilder is in RED in both i386 and amd64 - is this fine or am i missing something?
[16:56] <\sh> ScottK, DktrKranz: well, tbh, I'm biased, because I have a problem with e.g. wireshark in dapper too...(regarding security that is...)
[16:57] <DktrKranz> \sh: need to backport a new upstream to fix it?
[16:58] <\sh> DktrKranz: wireshark in dapper? yes
[16:58] <ScottK> bliZZardz: It's right https://launchpad.net/ubuntu/intrepid/+source/pbuilder/0.181ubuntu3
[16:59] <\sh> DktrKranz: but regarding glom and gutsy: I would say, backports is the to go here...(regarding the EoL of gutsy)
[16:59] <\sh> insert "way" between "the" and "to" ;)
[17:00] <DktrKranz> \sh, I'm OK to backport a new upstream if it just ships bugfixes (e.g. startupmanager). We would introduce additional features which are hard to track.
[17:00] <ScottK> bliZZardz: It looks like that problem is that dblatex is not installable on Intrepid.
[17:00] <ScottK> DktrKranz: You're overloading the term backport.  Please pick a different word.
[17:01] <DktrKranz> s/backport/push in -proposed/
[17:01] <ScottK> Yes.  Backport has a specific meaning here that's something else ...
[17:02] <bliZZardz> ScottK : but pkgs using pbuilder for Interpid wouldnt be a problem(just thinking out loud)
[17:02] <\sh> DktrKranz: sometimes this isn't easy to say...I'm one of the kind who believes that a version which is totally not usable is bad for the distro...so having a version wich works is much better, and sometimes, I think, it's ok to push a "new upstream from a newer ubuntu release" through -proposed/-updates...but that's just me...
[17:03] <ScottK> bliZZardz: No, the binaries for the old version are still in the archive.  People can still use that in the meantime.  This is about building the pbuilder package, not using pbuilder to build packages.
[17:03] <DktrKranz> \sh, I never realized glom in gutsy was totally unusable or not. Looking at the comment, it sounds it lacks an important feature, but it's hard to tell what is important and what's not
[17:04] <\sh> DktrKranz: that's why I'm not deciding...if it was an app which I'm using everyday...then it would be different :)
[17:05] <bliZZardz> ScottK : got it.
[17:05] <ScottK> \sh: We have rules about what is good for SRU and I dno't think this qualifies.
[17:05] <DktrKranz> we should reach a decision, I think is worth having a package in -backports just to be able to say "it doesn't work? use the one in -backports", so at least we don't leave users alone
[17:05] <ScottK> \sh: We can discuss changing the policy, but we ought to stick with the one we have until that's done.
[17:06] <ScottK> There's a difference between 'doesn't work' and only supports a limited use case.
[17:06] <ScottK> The bug was filed 4 months after Gutsy's release, so either no one uses the package until then or it was doing something useful for a set of users.
[17:08] <ScottK> While we're on SRUs, I think motu-sru is gettung subscribed way to early in the process.
[17:08] <ScottK> I don't think we should be dealing with large numbers of end users wanting stuff fixed.
[17:08] <ScottK> I think motu-sru should get subscribed when someone has something the might want to upload.
[17:09] <laga> yeah, so people prepare debdiffs, test them only to have them rejected?
[17:09] <ScottK> No.
[17:09] <\sh> ScottK: as I said, it's my opinion...and I'm too busy to start a discussion about "versions which are known to not work are in need to have a newer upstream to be pushed through -proposed/-updates bla"...
[17:10] <ScottK> laga: More someone thinks they might want to fix it subscribes motu-sru and asks if it qualifies.
[17:10] <ScottK> laga: Dealing with large numbers of non-developers who want something fixed just doesn't scale very well.
[17:12] <\sh> ScottK: but I think the "glom" report was filed from murray, and murray is upstream ... no glom package in debian so far, so I think it's also fair to mention, that upstream wants a working version of his project in the distros...
[17:12] <ScottK> \sh: Sure.  My view is it's either not much used or working in a way that's useful for some users and so we shouldn't take on the regression risk.
[17:13] <ScottK> \sh: If upstream doesn't want broken stuff packaged, they shouldn't release broken stuff. ;-)
[17:13] <ScottK> I won't veto if others want it, but that's my opinion.
[17:14] <DktrKranz> ScottK: so, would it be fine to release to gutsy-backports and then take a decision if this is worth the regression risk?
[17:14] <ScottK> DktrKranz: Yes.
[17:15] <\sh> ScottK: that's my conclusion, too...and I don't want to "punish all upstreams wanting newer versions of their software" but "subjectiveness doesn't count as SRU" ;) (and yes..when I'm upstream and I want to push a much better working version of my software into distros, I would argue about it...)
[17:15] <DktrKranz> ScottK: since it has been requested for hardy too, I can test them for both hardy and gutsy and file a backport request
[17:16] <\sh> DktrKranz: I thought hardy is ok?
[17:16] <ScottK> DktrKranz: OK.  Let me know when you need a backports ack.
[17:16] <DktrKranz> \sh, it's ok for this, but bug 243163 brings in new issues
[17:18] <\sh> "There's apparently a new SRU process that allows you to take stable updates." hmm? did I miss something?
[17:18] <DktrKranz> IIRC, no
[17:20] <DktrKranz> IMO, there isn't a clear rule if a new upstream is suitable or not, it just depends how many changes it brings in and what kind of changes
[17:21] <\sh> since I used 4 aspirin today to get rid of my headache...I don't want another one, just because of one package...
[17:22] <DktrKranz> sounds reasonable :)
[17:23] <\sh> DktrKranz: well, we will have the same discussion somehow for leonov in the future 8->
[17:23] <DktrKranz> :)
[17:24] <DktrKranz> we already have one for flashplugin-nonfree
[17:24] <DktrKranz> but we can't do otherwise
[17:26] <\sh> :)
[17:29] <Ash-Fox> I swear, making LSB builds of anything is insanely difficult.
[17:38] <pochu> it would be really useful to have binNMUs in Ubuntu for transitions...
[17:42] <ScottK> Agreed.
[17:43] <ScottK> \sh: There are some packages for which it's been decided new point releases are OK, but the upstream is known reliable and is known to ONLY put bug fixes in the point release.
[17:43] <ScottK> \sh: It's not a free for all.  Postgresql is an example.
[17:44] <\sh> ScottK: ok
[17:44]  * \sh goes home now
[17:45] <ScottK> bliZZardz: Feel free to ask your question, just do it here.
[17:46] <bliZZardz> ScottK : that was a bug related Q - hence asked in #ubuntu-bugs
[17:46] <ScottK> Ah. I'm not in #ubuntu-bugs.
[17:47] <ScottK> Asking me there, won't get you much of an answer.
[17:47] <bliZZardz> w.r.t bug #229575 - this looks like a valid request. i am able to find this right from feisty(not sure abt versions before that :) ) - should this be taken up during packaging?
[17:48] <bliZZardz> am not sure whether this is an upstream request or not
[17:56] <pochu> bug 245594
[17:58] <highvoltage> how strict is man age formatting in ubuntu?
[17:58] <highvoltage> I've seen a few different layouts. is there a policy anywhere?
[17:59] <sistpoty> hi folks
[18:00] <highvoltage> hi sistpoty
[18:00] <sistpoty> hi highvoltage
[18:01] <pochu> devfil: around?
[18:01] <devfil> pochu: yes, I'm here
[18:01] <sistpoty> oh, nice... with today's kde-related upgrade, kvirc once again shows highlights from the tray icon :)
[18:06] <ScottK> bliZZardz: I'm sorry, I have gotten caught up in some stuff and don't have time to answer.
[18:06] <warp10> There is a packaging request on launchpad for bzr-gedit. I was wondering if such a software should be merged with gedit-plugins, or rather go in another package.
[18:06] <warp10> My concern is that merging it in gedit-plugins, would add a dep on bzr, that isn't interesting for normal, non-technical users. What's your opinion?
[18:11] <SWAT> directhex: sorry for the delay, I was in transit. It's freeorion, which is GPL
[18:12] <directhex> fnuh?
[18:12] <directhex> oh, right, sorry
[18:12] <directhex> i have a terrible memory, context is everything
[18:12] <SWAT> directhex: -3 hours, just scroll up ;)
[18:13] <directhex> SWAT, 3 hours is a lifetime!
[18:13] <SWAT> directhex: it depends on gigi, which is lgpl (I'll just package that too)
[18:14] <sistpoty> directhex: irc makes perceived time slower ;)
[18:15] <directhex> sistpoty, i'm generally slow
[18:15] <directhex> sistpoty, also easily confused when conversation carries on across physical locations
[18:15] <SWAT> time is relative, at least to some physicists
[18:16] <sistpoty> directhex: hah
[18:17] <SWAT> directhex: any thoughts on my situation? ;)
[18:19] <directhex> SWAT, seems packageable, but you'll be needing to split the package up to generate binary packages per-platform for the executable/libs and arch-independenct packages for the graphics/audio data (which doesn't need to vary per-platform)
[18:19] <directhex> SWAT, this can (and should) be done from a single source package, but it increases the complexity of the packaging work. sorry about that.
[18:20] <SWAT> directhex: no problem. The only issue is that I'll probably have to get it out of svn, so I'll build my own source package. I've built packages before, just for personal use. When the packages are done, what's the next step?
[18:21] <directhex> SWAT, adding a new package? REVU i think. not sure. i've only worked on existing packages
[18:24] <sistpoty> yep, revu please...
[18:24] <SWAT> directhex: I'll get to work on it, thanks.
[18:24] <sistpoty> !revu > SWAT
[18:24] <sistpoty> SWAT: and please also file a needs-packaging bug, if you haven't done so
[18:24] <SWAT> sistpoty: thanks, I was already on that page :)
[18:25] <sistpoty> heh
[18:25] <directhex> generally, try to get the package "technically" right before bothering people with revu - try to use revu for help with correcting "housekeeping" things like correct formatting of debian/control or whatever
[18:25] <directhex> making a package "work" repeatably is something you do via testing, not really via looking
[18:25] <SWAT> directhex: I know ;)
[18:26] <sistpoty> SWAT: oh, and in case you just now join revu-uploaders, I assume that persia would like to resync the keyring :P
[18:32] <SWAT> sistpoty, directhex, thanks for your time.
[18:32] <sistpoty> np
[18:49] <siretart> sistpoty: is there a role email adress for motu-release?
[18:49] <siretart> sistpoty: I need to contact motu-release as a team
[18:49] <sistpoty> siretart: no
[18:49] <sistpoty> siretart: I guess ubuntu-motu would be best
[18:49] <laga> your nicks are confusingly similar.
[18:50] <sistpoty> laga: that's because we studied at the same university, where login=si (student of informatik) + 2 from first name + 4 from last name
[18:52] <laga> ah. i just have 1 + first name + last name at my university. i guess i'm lucky
[18:54] <pochu> we have firstname.lastname
[18:54] <pochu> :)
[18:54] <RainCT> apt-cache really needs a -t option :(
[18:55] <siretart> sistpoty: can I phone you in about 20 mins?
[18:55] <sistpoty> siretart: sure
[18:55] <highvoltage> how long have debdiffs been around? is it relatively new?
[18:56] <directhex> i used to have initials + unique number signifying which number on the list you are with those initials (e.g. i had 5, a friend on the same course had 3), then the lst 2 year digits
[18:57] <directhex> nowadays it's a 4-digit code for the department i was in when i started, plus a 4 digit uid
[18:59] <sistpoty> highvoltage: afaict debdiffs were there already when I initially installed ubuntu (i.e. breezy)
[18:59] <siretart> highvoltage: check /usr/share/doc/devscripts/changelog.gz. It seems to date from april 99
[18:59] <RainCT> highvoltage: since 1999, it seems
[18:59] <RainCT> heh
[18:59] <sistpoty> *g*
[19:02] <highvoltage> well, I think it's the coolest thing ever and didn't know about it until just a few months ago.
[19:03] <sistpoty> hm... with LP's new ui, does anyone know where I can unsubscribe a team which I'm a member of (looking at bug #205735 atm)
[19:04] <highvoltage> can I attach debdiffs to bugs that apply to packages in main?
[19:04] <sistpoty> highvoltage: sure
[19:04] <highvoltage> sistpoty: excellent.
[19:04] <sistpoty> highvoltage: the procedure is identical, only the sponsors team is ubuntu-main-sponsors instead of ubuntu-universe-sponsors
[19:05] <highvoltage> sistpoty: aah
[19:05] <highvoltage> RainCT: I'm going to attempt to finish off a bug that you reported (bug 185171)
[19:06] <sistpoty> aha, I have to click on "subscribe yourself", to have the choice to unsubscribe the sponsors team
[19:07] <RainCT> highvoltage: great, feel free to ask if you've any question :)
[19:18] <highvoltage> RainCT: I happen to have one right now...
[19:18] <highvoltage> I see in the debian/rules file it says:
[19:18] <highvoltage> DEB_INSTALL_MANPAGES_libgnome2-common += debian/gnome-options.7
[19:18] <highvoltage> can I just add another line like that that ends with gnome-open.1 ?
[19:20] <RainCT> highvoltage: yeah
[19:20] <RainCT> but debian/gnome-open.1 rather
[19:21] <highvoltage> RainCT: ok
[19:21] <highvoltage> the old version was 2.23.3-0ubuntu1, so the new version should be 2.23.3-0ubuntu2, right?
[19:21] <RainCT> highvoltage: and gnome-open is in libgnome2-0
[19:21] <RainCT> right
[19:22] <highvoltage> eesh. ok. I just went with libgnome as the bug report suggested.
[19:23] <highvoltage> ah, but it seems right? libgnome-2.23.3
[19:24] <highvoltage> ah I see there's a libgnome2.0 package. back to the drawying board then :)
[19:24] <RainCT> highvoltage: yes, the libgnome source package creates many binary packages, one of which is libgnome2-0
[19:24] <highvoltage> RainCT: aah
[19:44] <highvoltage> may I gzip a debdiff before attaching it to a bug report?
[19:45] <geser> highvoltage: how big is the debdiff?
[19:45] <highvoltage> geser: 64KB uncompressed, 8KB compressed
[19:46] <highvoltage> I suppose that's small enough to include as-is
[19:46] <highvoltage> but I also don't want to bloat launchpad :)
[19:46] <geser> me too, and a step less for the sponsor :)
[19:46] <highvoltage> good point, uncompressed it is then
[19:46] <highvoltage> launchpad can handle it :)
[19:53] <highvoltage> so, if the debdiff is on the bug report, do I change the status to 'fix committed', or does that only happen when it actually gets merged with the ubuntu sources again?
[19:57] <highvoltage> ah, I can probably just change it to "In Progress". that would make sense, I think
[20:01] <highvoltage> why is the priority for the gnome-open manpage bug on wishlist?
[20:01] <highvoltage> isn't it policy to have a man-page for every executable?
[20:02] <laga> i thought that, too.
[20:02] <laga> AFAIK, many ubuntu tools don't have man pages.
[20:02] <laga> eg jockey
[20:05]  * highvoltage made a comment about that on the bug
[20:05] <highvoltage> maybe someone will answer :)
[20:06] <highvoltage> it's the same for bug 160414 as well
[20:06] <Iulian> highvoltage: You might want to have a look at https://wiki.ubuntu.com/Bugs/Status and https://wiki.ubuntu.com/Bugs/Importance
[20:06] <highvoltage> so maybe there is reasoning behind it
[20:06] <highvoltage> Iulian: thanks, will do so immediately
[20:08] <highvoltage> Iulian: thanks, that is very helpful. imho, a "low" priority would be more appropriate than "wishlist"
[20:10] <Iulian> highvoltage: Really, it doesn't make any difference if the priority of the bug is "wishlist" or "low"
[20:13] <Iulian> highvoltage: If you're working on that bug I can change that for you if you want but it doesn't make any difference.
[20:14] <highvoltage> Iulian: ok, no problem! no need to change them.
[20:15] <highvoltage> Iulian: I guess that it just "feels wrong" to label a policy violation as a wishlist item
[20:15] <highvoltage> but that's probably just me then,
[20:15] <highvoltage> .
[20:17] <Iulian> highvoltage: Well, some Ubuntu devs doesn't like binary packages without a manpage when sponsoring a new package.
[20:17] <Iulian> highvoltage: + lintian will complain if it doesn't have a man page.
[20:18] <ScottK> It's not just 'don't like' it's policy.
[20:19] <Iulian> ScottK: Yea indeed.
[20:19]  * ScottK will change it.
[20:20] <highvoltage> ScottK: thanks, and sorry to be such a pest about it :)
[20:21] <laga> ScottK: change what? change policy or priority?
[20:22] <ScottK> Changed the priority to Low from Whishlist since it represents a minor defect in the packaging.
[20:24] <RainCT> OT, can someone here vala? I'm wondering if it's worth to learn it
[20:27] <tbielawa> hey all
[20:27] <tbielawa> I got feedback on a REVU commit a bit back and I don't see where it applies. Can anyone help me resolve item 4:
[20:27] <tbielawa> http://revu.ubuntuwire.com/details.py?upid=2395
[20:28]  * sistpoty looks
[20:28] <emgent> heya
[20:29] <sebner> huhu emgent our prospetive motu :)
[20:30] <tbielawa> sistpoty, thanks
[20:30] <sistpoty> tbielawa: it doesn't apply for upload 2395 at least
[20:31] <tbielawa> sistpoty, I see it appears 2311. Thanks for clearing that up.  O_o
[20:32] <sistpoty> huhu sebner :P
[20:32] <tbielawa> sistpoty, I've resolved everything but item 6. I did a find on the base directory and there's a lot of .py files which are +x and have a shebang.
[20:32] <DktrKranz> sebner, I misread :D
[20:32] <tbielawa> this will hurt to resolve
[20:32] <sebner> sistpoty: yeah huh you too xD
[20:32] <sebner> DktrKranz: rofl xD
[20:33] <sistpoty> tbielawa: write a script to change these ;)
[20:34] <tbielawa> sistpoty, the find command is my friend.
[20:34] <sistpoty> heh
[20:34] <tbielawa> I suppose I'll just find out which are /supposed/ to have a shebang when things stop working then, huh?
[20:35] <sistpoty> tbielawa: maybe it might be a good idea to find out which scripts are meant to be executed directly?
[20:36] <tbielawa> sistpoty, there is only one which you would actually execute, that I know of
[20:36] <sistpoty> tbielawa: that's a good start ;)
[20:37] <tbielawa> sistpoty, this task doesn't seem quite as insurmountable any longer. thanks
[20:37] <sistpoty> you're welcome ;)
[20:45] <sebner> sistpoty: do you know if a archive admin is around? They stole my syncs. ehm I mean my name isn't written there but auto-sync O_o
[20:46] <sistpoty> sebner: blame pitti, as he accidantly ran autosync recently ;)
[20:46] <crimsun> if only stealing autosync naming were the worst of our troubles.
[20:46] <sebner> sistpoty: again?  They go ACK and an archive admin set it to Fix Released
[20:47] <sebner> crimsun: xD, hey thanks for flash 10 beta2 :D
[20:47] <sistpoty> sebner: not too sure, he told s.th. about "friday habits" earlier on on #ubuntu-devel
[20:47] <sebner> lol
[20:47] <sebner> kay
[20:48] <sistpoty> sebner: however from your +packages page, do you really need more before you go for motu?
[20:48] <sistpoty> ;)
[20:48] <crimsun> sebner: thank RAOF not me.
[20:49] <sebner> sistpoty: well there are only shown the last 50 ones but I have a deal with Luca to have 250 uploads before applying. Now I don't now how many I have. officially 200 uploads but they should be ~203
[20:49] <sebner> crimsun: why? -- Daniel T Chen<EMAIL_ADDRESS> Wed, 02 Jul 2008 23:29:04 -0400
[20:50] <sistpoty> sebner: apply for motu! do it! that's an advice! *g*
[20:50] <crimsun> sebner: because he's responsible for signing the source package and uploading.
[20:50] <sebner> sistpoty: lol, no. first packing things from scratch. first easy package will be tomorrow on revu =) besides I'll think about me and my ubuntu future in my ireland holidays
[20:51] <sebner> crimsun: ah nvm. so *also* thanks to you ;) finally I can use my keyboard again and play flash games xD
[20:51] <sistpoty> sebner: oh, so you're trying to escape to ireland from motu? *g*
[20:52] <sebner> sistpoty: maybe ^^ no to be honest I'm not happy at all with ubuntu rules etc
[20:52] <sistpoty> sebner: with which rules are you not happy?
[20:52] <sebner> sistpoty: nvm. I'll do a discussion with persia later
[20:52] <sistpoty> (feel free to query me, if you don't want to discuss this in public
[20:52] <sistpoty> +)
[20:58]  * RainCT is reading the log..
[20:58] <RainCT> about the gnome-open manpage bug's importance, for this package I agree that it should be Low
[20:58] <geser> \o/ some quiet time for u-u-s soon :)
[20:59] <sebner> geser: O_o
[20:59] <RainCT> but if it was in universe I wouldn't be that sure, as the wiki says about importance Low «A bug that has a moderate impact on a non-core application »
[21:00] <emgent> hello RainCT sebner geser sistpoty ecc.. ecc..
[21:00] <geser> Hi emgent
[21:00] <sistpoty> hi emgent:
[21:00] <sistpoty> -:
[21:02] <RainCT> hey emgent
[21:03] <null_vector> ugh, installing libc failed during upgrade to intrepid
[21:03] <RainCT> geser: hehe seems like that's a workaround for the "can't stop sebner" bug on staging.launchpad.net (which has already been deleted :()
[21:03] <sebner> RainCT: xD
[21:04] <geser> RainCT: there is still the screenshot :)
[21:05] <RainCT> geser: yeah :)
[21:33] <tbielawa> it seems like the kernel and virtualbox are always out of sync recently
[21:37] <tbielawa> non-ose ftw I guess
[21:38] <laga> dkms ftw
[21:39] <tbielawa> kvm ftw
[21:40] <tbielawa> though dkms does look like something I should look at in greater detail later
[22:18]  * sistpoty must go to bed now.. gn8 everyone
[22:20] <sebner> gn8 folks
[22:25] <emgent> bye sebner
[22:28] <nxvl> emgent: what are you doing on IRC, you should be drinking
[22:28] <emgent> nxvl: lol
[22:28] <emgent> nxvl: why ?
[22:29] <Nafallo> hmm
[22:29] <Nafallo> I did it the other way around :-)
[22:31] <nxvl> emgent: because it's friday, and almost midnight at your tz
[22:31] <emgent> nxvl: i know, but tomorrow i should work
[22:32] <nxvl> ember: oh! ok, there you have a problem, i didn't say nothing in that case
[22:32] <nxvl> :P
[22:32] <emgent> hehehe :)
[22:33] <DktrKranz> nxvl, almost midnight here too, but there's nothing at all... so I come back home :(
[22:34] <emgent> hehe
[22:34] <nxvl> DktrKranz: where in the world are you?
[22:34] <DktrKranz> nxvl, italy
[22:35] <nxvl> same as emgent
[22:35] <nxvl> that's cool
[22:35] <emgent> no, it`snt..
[22:35] <nxvl> in peru there is always something to do
[22:35] <emgent> nxvl: can i send Berlusconi & CO in Peru ? :)
[22:36] <nxvl> to the point that sometime i don't do anything cause i'm sick of drinking
[22:36] <DktrKranz> ember, no politics :)
[22:36] <DktrKranz> nxvl, come tomorrow, you'll have to drink a lot
[22:36] <emgent> DktrKranz: heheh ok
[22:37] <nxvl> emgent: plese don't, we have to much with our politics
[22:37] <DktrKranz> oh, I mean emgent, not ember (sorry for bogus ping)
[22:39] <norsetto> I'd propose bug 245679 as BOTD
[22:40] <nxvl> BOTD?
[22:40] <norsetto> nxvl: Bug Of The Day, what else!?
[22:41] <nxvl> :D
[22:41] <nxvl> Build Over Trunk Data?
[22:41] <nxvl> :P
[22:41] <emgent> Uploaded by nhandler
[22:42] <nxvl> to much text to read for a classroom
[22:42] <nxvl> i after my class
[22:43] <nxvl> s/i/i'll/g
[23:30] <beDrung> DktrKranz: Is there someting I have to do for bug #221205? I am not a MOTU, so I need someone who sponsors me.
[23:31] <DktrKranz> beDrung, I can upload it, but need to boot a hardy box to test it
[23:31] <DktrKranz> I subscribe to it, so I keep track
[23:33] <beDrung> normally setting a bug to fix released means that I need a sponsor. but this does not apply for sru?
[23:36] <DktrKranz> fix released means fix is already in the archives
[23:42] <beDrung> DktrKranz: ok
[23:53] <beDrung> Does someone get a point of bug #245701


[18:11] <zaki> .weather chittagong
[18:11] <u-la-la> Cover: Scattered, Temp: 83.8°F (28.8°C), Dew Point: 81.4°F (27.4°C), Humidity: 93%, Apparent Temp: 98.8°F (37.1°C), Pressure: 29.65in (1004.02mb), Condition: Rain, Wind: Gentle breeze 8.0mph (12.9kmh) (↓) - Chittagong, Bangladesh (Powered by Dark Sky, darksky.net)
[18:13] <zaki> darksky.net
[18:15] <zaki> u-la-la, darksky.net
[18:15] <zaki> u-la-la, hi
[18:16] <pavlushka> .ddg darksky.net
[18:16] <u-la-la> https://darksky.net/
[18:16] <u-la-la> Zero Click: darksky.net is a parked domain (last time we checked).
[18:17] <pavlushka> Hello everyone ond others :p
[18:17] <zaki> .food chittagong
[18:17] <u-la-la> TypeError: __init__() takes exactly 3 arguments (5 given) (file "/home/peruvian/gits/jenni/modules/food.py", line 18, in food)
[18:17] <zaki> aii -_-
[18:17] <zaki> hi pavlushka and others :D
[18:18] <zaki> Kilos, you done playing liberators? :|
[18:19] <pavlushka> zaki: for that you have to setup the yelp api first, for the bot
[18:20] <zaki> oh
[18:22] <zaki> .ip <IP_ADDRESS>
[18:22] <u-la-la> zaki: [IP/Host Lookup] Hostname: 27-247-180-104.adsl.fetnet.net | City: Taipei | State: N/A | Country: Taiwan | Latitude: 25.0418 | Longitude: 121.4966
[18:23] <zaki> .mustache_me pavlushka
[18:23] <u-la-la> Can't find anything in Google Images for "pavlushka".
[18:23] <zaki> he he
[18:25] <zaki> ddg xkcd
[18:25] <zaki> .ddg xkcd
[18:25] <u-la-la> https://xkcd.com/
[18:25] <u-la-la> Zero Click: xkcd, sometimes styled XKCD, is a webcomic created by US author Randall Munroe. The comic's tagline describes it as "A webcomic of romance, sarcasm, math, and language". Munroe states on the comic's website that the name of the comic is not an acronym but "just a word with no phonetic pronunciation".
[18:26] <zaki> u-la-la, coffee on
[18:27] <zaki> :|
[18:30] <zaki> .search xkcd
[18:30] <u-la-la> https://xkcd.com/
[18:30] <u-la-la> Zero Click: xkcd, sometimes styled XKCD, is a webcomic created by US author Randall Munroe. The comic's tagline describes it as "A webcomic of romance, sarcasm, math, and language". Munroe states on the comic's website that the name of the comic is not an acronym but "just a word with no phonetic pronunciation".
[18:31] <zaki> .search gattaca
[18:31] <u-la-la> https://en.wikipedia.org/wiki/Gattaca
[18:31] <u-la-la> Zero Click: Gattaca is a 1997 American science fiction film written and directed by Andrew Niccol. It stars Ethan Hawke and Uma Thurman, with Jude Law, Loren Dean, Ernest Borgnine, Gore Vidal, and Alan Arkin appearing in supporting roles. The film presents a biopunk vision of a future society driven by eugenics where potential children are conceived through genetic manipulation to ensure they possess the best hereditary traits of the
[18:32] <zaki> .search source code
[18:32] <u-la-la> https://en.wikipedia.org/wiki/Source_code
[18:32] <u-la-la> Zero Click: In computing, source code is any collection of computer instructions, possibly with comments, written using a human-readable programming language, usually as ordinary text. The source code of a program is specially designed to facilitate the work of computer programmers, who specify the actions to be performed by a computer mostly by writing source code. The source code is often transformed by an assembler or compiler int
[18:32] <zaki> .search u-la-la
[18:32] <u-la-la> https://en.wikipedia.org/wiki/Ulala
[18:32] <zaki> :3
[18:32] <pavlushka> :D
[18:33] <zaki> Ulala (Space Channel 5), a reporter from Space Channel 5, a Japanese music video game
[18:33] <zaki> hehe
[18:34] <zaki> .search Brainstorm
[18:34] <u-la-la> https://en.wikipedia.org/wiki/Brainstorm
[18:35] <zaki> pavlushka, mustache_me not working :D
[18:35] <zaki> mustache_me Brainstorm
[18:41] <zaki> .search inception
[18:41] <u-la-la> https://en.wikipedia.org/wiki/Inception_(disambiguation)
[18:46] <zaki> https://itsfoss.com/ubuntu-17-10-release-features/
[18:46] <u-la-la> [ Ubuntu 17.10 Release Date and New Features ] - https://itsfoss.com
[18:47] <zaki> https://wiki.ubuntu.com/ArtfulAardvark/ReleaseSchedule
[18:47] <u-la-la> [ ArtfulAardvark/ReleaseSchedule - Ubuntu Wiki ] - https://wiki.ubuntu.com
[18:47] <zaki> .search Aardvark
[18:47] <u-la-la> https://en.wikipedia.org/wiki/Aardvark_(disambiguation)


[12:05] <ml|vacation> RAOF: argh now I know how you feel, total travel back is going to be over 32 hours I think..


[00:03] <ridik> sarnold: thx
[01:58] <tomreyn> sarnold: there's also .6, still on releases: http://releases.ubuntu.com/releases/16.04.6/
[01:59] <tomreyn> (ridik's gone)
[01:59] <sarnold> tomreyn: ugh
[01:59] <sarnold> tomreyn: we have too many download sites
[01:59] <tomreyn> :)
[01:59] <sarnold> tomreyn: I plain couldn't recall the name releases.ubuntu.com. :(
[01:59] <sarnold> I've spent half an hour over the last two weeks trying to find "all the download sources" because they all have different subsets of installers and images and so on
[02:00] <tomreyn> there are a lot of subdomains, and not just the servers' hostnames.
[02:00] <tomreyn> i tend to loose them, too.
[02:03] <tomreyn> i think generally everything that's still at least inofficially ESM supported is still on releases.u.c and only the *really* old stuff moves to old-releases.u.c now. and then there is cdimages.u.c and ports.u.c and probably something else i forgot
[02:04] <tomreyn> actually ports.u.c. are a different category, like archive.u.c but for non amd64 (and non i686). however, some installers are only on the archive mirrors. :)
[02:05] <sarnold> cdimages was the easy one to remember :)
[02:06] <sarnold> I also wish we had a single place to rsync all of ports.u.c. and archive.u.c -- there's no good way to have a consistent mirror of the contents of both of those, sharing data where possible :(
[02:06] <sarnold> since I've got ppc64el, aarch64, and amd64 in the house, it'd be super to have a single mirror with all three
[02:07] <tomreyn> couldn't you just have /ports/ next to /archives/ ?
[02:08] <tomreyn> they'd still be separate but on the same hostname and next to one another at least
[02:09] <tomreyn> oh you're probably thinking in terms of automation where youcould just set a $arch variable, i see.
[02:16] <sarnold> tomreyn: well, that and it'd be super-nice to not duplicate all the arch-indep files
[02:16] <sarnold> tomreyn: zfs dedup could do it but at great cost to memory
[02:16] <sarnold> tomreyn: .. and it'd still involve downloading two copies of all arch-indep packages
[02:24] <tomreyn> oh right the arch independant packages, there are some. i don't know how much disk space and how many FSO's they sum up to as opposed to arch dependant, but i guess it certainly slows down the rsync having to copy any of those twice.
[02:27] <tomreyn> i'm not sure how good it is but there are other deduplicating file systems other than zfs (and not all of them consume much ram, i think). btrfs can do it (but not sure how stable) and redhat open sourced VDO: https://www.marksei.com/vdo-linux-deduplication/
[02:33] <sarnold> I've got at least 380 gigs of *_all.deb packages on my mirror right now
[02:33] <sarnold> funny thing, locate '*all.deb' | xargs ls -l  ... emitted *tons* of file not found errors; I wonder what's busted now :)
[02:34] <tomreyn> need to run updatedb ;)
[02:34] <sarnold> and come back tomorrow :)
[02:34] <sarnold> -rw-r----- 1 root mlocate<PHONE_NUMBER> Jan 29 07:17 /var/lib/mlocate/mlocate.db
[02:35] <sarnold> very curious
[02:35] <tomreyn> 4.64 GB, not bad
[02:36] <tomreyn> apparently VDO is also rather ram hungry
[02:36] <sarnold> http://paste.ubuntu.com/p/fNFmSVZN2S/
[02:37] <tomreyn> hmm, outdated kernel packages, but the others, i wouldn't know
[02:40] <tomreyn> http://archive.ubuntu.com/ubuntu/pool/main/f/freeradius/freeradius-common_3.0.20+dfsg-3_all.deb is a 404, but freeradius-common_3.0.20+dfsg-3build1_all.deb exists.
[02:42] <sarnold> 2020-01-28 14:18
[02:45] <tomreyn> i feel like i'm a happy person who does not need to understand those details and can just head to bed now. :)
[02:47] <sarnold> tomreyn: that sounds like an excellent plan!
[02:47] <tomreyn> sarnold: even greater when you make it happen!
[02:47] <sarnold> tomreyn: I wish you great success in your plan :)
[02:48] <sarnold> as I should also find some dinner and exercise
[02:48] <tomreyn> and good luck with yours!
[02:48] <sarnold> :D
[02:56] <tomreyn> https://www.youtube.com/watch?v=7CGr5LEAfRY https://github.com/dm-vdo/kvdo/blame/master/README.md#L80 (out of tree modules so far). and really gone. :)
[02:59] <sarnold> haha nice find :) thanks
[03:00] <sarnold> 1.65T completed (3240MB/s) estimated time remaining: 315079hr 55min 15sec
[03:00] <sarnold> sheeesh. Maybe I don't want to know stats on this afterall :)
[07:11] <lordievader> Good morning
[12:34] <bcx> Hi i'm trying to preseed bionic from whith a floppy containing the d-i selections. Seems like netboot 18.04 has floppy driver but doesn't automatically mount fd0. Is there any way to ask so from boot params ? Thx
[12:35] <bcx> alternatively, a solution enabling running arbitrary command (mount /dev/fd0 /media) from boot params would be accepted :)
[12:51] <ahasenack> cpaelzer: are you familiar with setting up nvdimm devices in qemu/libvirt? I followed rafaeldtinoco's template, but can't get some commands to work, like enable-namespaces, or create-namespaces, I'm wondering what I'm missing. strace didn't show anything obvious
[12:51] <ahasenack> https://pastebin.ubuntu.com/p/HMtXy2yqDT/ my xml
[12:51] <ahasenack> commands: https://pastebin.ubuntu.com/p/hjNCFBjykH/
[12:52] <ahasenack> maybe I'm missing /dev/pmem* devices
[12:55] <sdhd-sascha> Hi, which daily ubuntu-server 20.04 image is usable for installation ? i already tried some. But didn't had luck yet
[12:57] <sdhd-sascha> I want to reinstall, because my ZFS has crashed SSD for the log device. After that it won't boot. It was 18.04 before. Upgrade to 20.04 didn't resolve `apt & dpkg` dependencies. Now i try to install a fresh 20.04.
[12:57] <sdhd-sascha> Don't need a stable version. Just want to try 20.04 now
[12:57] <ahasenack> what faileD?
[12:59] <sdhd-sascha> My raid-controller said, something about foreign disk. After cleaning that in the raid-controller, uefi said something like "ubuntu unavailable" ...
[12:59] <sdhd-sascha> It's a no-name SSD. Wich wasn't supported my server firmware.
[12:59] <sdhd-sascha> by
[13:00] <sdhd-sascha> ahasenack: You mean, with the installer ?
[13:00] <ahasenack> yes
[13:01] <sdhd-sascha> Oh, well. One time xz-compression didn't work. Other time the /cow couldn't get mounted. Lastly squashfs error . Not sure, if it's usb 3.0 stick with usb 2.0 port...
[13:01] <sdhd-sascha> Maybe i try a usb 2.0 stick, to be sure
[13:03] <tomreyn> bcx: maybe you want something like https://www.debian.org/releases/stable/amd64/apbs02.en.html#preseed-auto rather
[13:03] <sdhd-sascha> This is the version, which i try currently: http://cdimage.ubuntu.com/ubuntu-server/daily-live/20200129/
[13:04] <ahasenack> sdhd-sascha: that's odd indeed, did you verify the hash of the downloaded image?
[13:04] <sdhd-sascha> yes, gpg and sha256sum. But only on filesystem. Didn't know if i could check this after copying to usb.
[13:06] <sdhd-sascha> ahasenack: well... Seems to be the usb-port on my current host. Because on copying the stick didn't blink ... Hmm, weird. Wait i try another machine or port...
[13:06] <sdhd-sascha> I already, have trouble with this usb-port. Didn't find the cause, yet
[13:09] <tomreyn> is this server hardware? got an OOB access / networked KVM system with 'virtual media' / cdrom?
[13:11] <tomreyn> alternatively https://unix.stackexchange.com/questions/75483/how-to-check-if-the-iso-was-written-to-my-usb-stick-without-errors
[13:12] <sdhd-sascha> tomreyn: the machine, with the strange usb-port is a small `zotac`. (Sometimes the usb port works, for only one time. If i do a shutdown, and remove the ac-power. After that, Linux 5.3 boots and the port works again... )
[13:12] <sdhd-sascha> The other server is a dell
[13:12] <sdhd-sascha> tomreyn: thank you :-)
[13:13] <sdhd-sascha> Now i use another machine for usb copy... I will report, if the installer works now.
[13:13]  * sdhd-sascha usb blinks now, on copying. how expected ;-)
[13:13] <ahasenack> :)
[13:14] <tomreyn> sdhd-sascha: if the dell got an idrac it may have virtual media support so you could mount the iso to the server 'directly' over network, assuming that is stable.
[13:14] <sdhd-sascha> tomreyn: that's true. But there's maybe another machine here. Without an idrac
[13:14] <tomreyn> but i guess the usb method works, too, if data is actually written to it. ;)
[13:15] <sdhd-sascha> :-) yes... it's still copying... Seems to work better now ;-)
[13:15] <sdhd-sascha> But crazy, that the installer has booted.
[13:20] <sdhd-sascha> tomreyn: Normally, i would use maas for installation. But that's the other machine, which makes trouble today ;-)
[13:21] <tomreyn> things could be so easy if things would just work. :)
[13:21] <sdhd-sascha> :-)
[13:22] <sdhd-sascha> i have here an error: `ACPI: SPCR: unexpected SPCR Access Width. Defaulting to byte size` . Can i ignore this on boot ?
[13:27] <cpaelzer> ahasenack: ah here you actually asked :-)
[13:27] <cpaelzer> ahasenack: https://libvirt.org/formatdomain.html#elementsMemory
[13:27] <ahasenack> sorry
[13:27] <ahasenack> too many channels
[13:28] <cpaelzer> ahasenack: if you use a qemu built with pmem, then you should be bale to set <pmem/>
[13:28] <cpaelzer> ahasenack: inside the <source> element of the nvdimms
[13:28] <sdhd-sascha> Is there a way to configure keyboard repeat in the python terminal installer ?
[13:28] <ahasenack> cpaelzer: I'm wondering if I can get away with not doing that rebuild by rebooting with the memmap trick in the kernel cmdline
[13:28] <sdhd-sascha> It hangs sometimes
[13:29] <cpaelzer> ahasenack: depends on what you actually want to test atm
[13:29] <ahasenack> I seem to have gotten the nvdimm devices, backed by files on the host
[13:29] <ahasenack> but kilobyte tells me that "persistence_domain":"unknown" says it's not recognized as pmem
[13:29] <ahasenack> so I need this other layer
[13:30] <cpaelzer> ok, the qemu part is about AFTER you have whatever you miss to then  use things for your guest
[13:30] <cpaelzer> but I don't know the trick tinoco used to get it working in the tests
[13:31] <cpaelzer> I also thought the kernel commandline to fake some would be the main part
[13:31] <cpaelzer> seems there might be more
[13:31]  * cpaelzer is re-reading the inbox
[13:31] <ahasenack> ok, this is my cmdline: https://pastebin.ubuntu.com/p/X5V7vz9BhF/
[13:31] <cpaelzer> which is fine for faked nvdimms
[13:31] <sdhd-sascha> tomreyn: ahasenack: thank you. It works now. (The keyboard repeat, was also normal now ;-) weird)
[13:31] <cpaelzer> at least I'd think so
[13:32] <ahasenack> sdhd-sascha: nice
[13:32] <cpaelzer> ahasenack: the pmem in the domain xml will add pmem=on to the commandline
[13:32] <cpaelzer> and a non rebuilt qemu will tell you "I can't do that"
[13:33] <tomreyn> sdhd-sascha: you're welcome. SPCR is the serial port console redirection ACPI table. so unless you're installing through a serial console you can probably ignore it during installation.
[13:33] <ahasenack> let me ask him on telegram
[13:33] <cpaelzer> ahasenack: can I log into your system to work with you there?
[13:33] <cpaelzer> I have found old notes between me and tinoco
[13:34] <ahasenack> hm, not trivially
[13:34] <sdhd-sascha> tomreyn: thanks :-) At the moment no serial console
[13:34] <ahasenack> I could move the vm to diglett
[13:34] <ahasenack> migration and sutch
[13:34] <ahasenack> does that work nowadays? :)
[13:34] <cpaelzer> like live migrating?
[13:34] <cpaelzer> it would work if you had shared storage
[13:35] <ahasenack> doesn't have to be live
[13:35] <ahasenack> shut down, copy over, bring up
[13:35] <ahasenack> a big copy, yeah
[13:35] <cpaelzer> that should be ok
[13:35] <ahasenack> xml + img
[13:35] <ahasenack> cpaelzer: I got a hold of tinoco
[13:35] <ahasenack> he thinks he used a ppa you setup for the mir
[13:35] <ahasenack> so it must have been linked with pmem
[13:36] <cpaelzer> that might explain
[13:36] <cpaelzer> I don't remember a PPA for it TBH
[13:36] <ahasenack> if the mir succeeds, we would have that in focal, and require the security team to use focal when testing this
[13:36] <cpaelzer> yes
[13:36] <ahasenack> or I could try the memmap cmdline trick
[13:36] <cpaelzer> yes
[13:37] <cpaelzer> the only PPA in that regard which I know is https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1853506
[13:42] <ahasenack> cpaelzer: he may have been using debian as the host, hence, debian's qemu
[14:04] <ahasenack> cpaelzer: n00b libvirt migraton user here
[14:04] <ahasenack> cpaelzer: the "Migrate" option is grayed out in the context menu of the vm I want to migrate, in virt-manager
[14:04] <ahasenack> cpaelzer: but it's available in the running vm
[14:04] <ahasenack> live-migrate is the *only* migration option?
[14:06]  * ahasenack resorts to virsh
[14:11] <ahasenack> cpaelzer: any tip here? virsh -c is fine with that url, but not virsh migrate: https://pastebin.ubuntu.com/p/MYY5W4Sbrp/
[14:17] <cpaelzer> ahasenack: reading ..
[14:19] <cpaelzer> with all those firewalls you never know
[14:19] <cpaelzer> ahasenack: you can push it to a real file
[14:19] <cpaelzer> virsh save bionic-nvdimm > bionic-nvdimm.state
[14:19] <ahasenack> "host key verification failed" seems to be an ssh issue, but virsh -c worked just fine :/
[14:20] <cpaelzer> also dumpxml (to virsh define the content on the target)
[14:20] <cpaelzer> copy all that is shown in 'virsh domblklist bionic-nvdimm' as well
[14:21] <cpaelzer> once all those (state, disks, xml defined) are in place
[14:21] <cpaelzer> you can restore via
[14:21] <cpaelzer> virsh restore bionic-nvdimm.state
[14:21] <cpaelzer> otherwise you'd need ssh keys and all that between the daemons and so on
[14:21] <cpaelzer> I guess if just you copy the files you might be better off on a one shot action
[14:23] <sdeziel> ahasenack: I'd be curious to see a strace of that 'virsh migrate', I wonder how SSH is invoked
[14:24] <ahasenack> I'll try
[14:24] <ahasenack> I'll need sudo for the strace, which will change the user, ssh key is not in /root/.ssh/, etc
[14:24] <sdeziel> I don't know the --p2p option but it sounds as if libvirt was going to try to reach the other QEMU itself and would thus have problem reaching your key
[14:24] <sdeziel> ahasenack: you can strace your own processes
[14:25] <ahasenack> hm, I don't see an exec for ssh, it must be the libvirt-daemon doing it
[14:25] <sdeziel> or have root strace your running user's process
[14:25] <sdeziel> check apparmor messages in dmesg
[14:25] <ahasenack> that is clear
[14:25] <sdeziel> hmm
[14:28] <ahasenack> with virsh -c, strace shows it calling ssh
[14:28] <ahasenack> but not with virsh migrate
[14:28] <ahasenack> that must be going through the daemon
[14:28] <ahasenack> tracing that
[14:29] <ahasenack> yeah, got something tracing the daemon
[14:30] <ahasenack> it's the libvirtd daemon calling ssh, and the user it's running as probably isn't me :)
[14:31] <ahasenack> 10950 openat(AT_FDCWD, "/root/.ssh/config", O_RDONLY) = -1 ENOENT (No such file or directory)
[14:31] <ahasenack> it's root, obviously
[14:31] <ahasenack> meh
[14:32] <ahasenack> so to migrate, the user running libvird (root) needs to have access to my ssh key, its known_hosts, needs to be clean, etc
[14:32] <sdeziel> shouldn't the above come with a lot of noise from Apparmor?
[14:32] <ahasenack> libvirtd not being able to read /root/.ssh, when it's running as root?
[14:32] <sdeziel> yeah, I wouldn't expect it to have access there
[14:33] <ahasenack>   # Very lenient profile for libvirtd since we want to first focus on confining
[14:33] <ahasenack>   # the guests. Guests will have a very restricted profile.
[14:33] <ahasenack>   / r,
[14:33] <ahasenack>   /** rwmkl,
[14:33] <ahasenack> that's in /etc/apparmor.d/usr.sbin.libvirtd
[14:34] <sdeziel> I would have maybe appreciated to have an include of abstractions/private-files-strict :)
[14:35] <sdeziel> ahasenack: is it the same behaviour without --p2p ?
[14:35] <ahasenack> --tunneled requires --p2p
[14:35] <ahasenack> I didn't try without --tunneled, let me check
[14:36] <ahasenack> $ virsh migrate bionic-nvdimm qemu+ssh://andreas@diglett/system --offline --persistent --copy-storage-all --verbose
[14:36] <ahasenack> error: operation failed: domain is no longer running
[14:36] <ahasenack> what has that got to do with anything
[14:37] <ahasenack> same thing without --offline
[14:39] <ahasenack> why does it have to be running. Isn't live migration harder?
[14:42]  * ahasenack gives up
[14:42] <sdeziel> ahasenack: maybe the order of those arguments matters?
[14:42] <ahasenack> I'm too used to lxd's migration
[14:43] <ahasenack> that's really easy, lxc copy <src> <dst>
[14:43] <sdeziel> yeah :)
[14:43] <sdeziel> rejoice, lxd now supports driving VMs :)
[15:23] <zetheroo> to save the iptables over reboot all I need to do is 'iptables-save' ?
[15:23] <zetheroo> or is there something else as well?
[15:25] <sdeziel> zetheroo: it depends on what you use to manage your rules. I recommend the iptables-persistent package that makes it easy to persist rules between reboots
[15:26] <zetheroo> I just entered some new rules and want to save them over reboot. Here https://help.ubuntu.com/community/IptablesHowTo#Saving_iptables it says to just use 'iptables-save' ...
[15:27] <zetheroo> the 'iptables-persistent' method looks like a more work ... ok
[15:27] <zetheroo> *or?
[15:34] <sdeziel> zetheroo: it you use the command iptables-save, you then need to call the iptables-restore on the next boot, that's what iptables-persistent does for you
[15:35] <sdeziel> zetheroo: that help page is a bit dated as it assumes ifupdown which may or may not apply depending on which Ubuntu version you are using
[15:36] <zetheroo> oh
[15:54] <weedmic> you can also save ip-tables to a file and reset it when needed, you can create a script like if condition a exists run tables-a, if b, then b.  iptables are awesome
[16:10] <blscoe> hi, I would like to know if exist a way to get access control of a website using PHP Sessions and Apache? I would like to control access using deny and allow access content in Apache basing on user PHP session information. Can anyone suggest a good material to do that or another suggestion to control access to a group of websites in apache? (I have many Wordpress instances on subdomains and I would like to control the access to al
[16:10] <blscoe> l this sites.)
[16:10] <blscoe> I will have a page of login and after the user login they will redirect to the main page with the links of all subdomains.
[16:13] <weedmic> odd, i don't see biscoe having exited the kamer
[16:14] <weedmic> blscoe: nvm - it was an "l" - do you mean like restricing ALL access to a website ONLY to those with ssh (or something)?  or just those with root privlidges?
[16:17] <blscoe> weedmic: it is a front-end cenario, the users is people that will see the page, not modify. But only users that have a password and username (I have a PHP and database for this.) So I would like to restrict the access to the webpages in my server.
[16:18] <blscoe> So, when a people make a http request, this will be block if he don't have a php session open.
[16:18] <blscoe> It is that I want to do.
[16:18] <blscoe> But I don't know what do.
[16:19] <weedmic> why not use ssh and set your router to reject attemps that do not have an approved key (or use port knocking)?
[16:20] <weedmic> under that scenario they could never get to the webpage.
[16:20] <weedmic> unless they had a valid key/account.
[16:21] <blscoe> but how the user can get access to the web page via ssh using a browser?
[16:22] <sdeziel> blscoe: that's usually not done at the apache level but with PHP itself
[16:23] <sdeziel> blscoe: if you really want to do it with apache, cookies are available and you can probably hack something similar to https://httpd.apache.org/docs/2.4/howto/access.html#rewrite
[16:23] <blscoe> sdeziel: my problem is that the webpage can accessed typing the direct url. For this reason I think in use apache restrictions.
[16:24] <sdeziel> https://httpd.apache.org/docs/2.4/howto/access.html#env is probably a better fit but that's really not where your access control logic should reside IMHO
[16:26] <weedmic> blscoe: first of all, a website should be on it's own router (imho) and not inside the real network, second you set the dtu (that box you get from your provider) to send all traffick to your gw/portal/fw.  make the gw/portal/fw a linux machine which has only one function, to have ssh on it, and restrict the ssh via iptables to allow only approved accounts (maybe after 5 failed attempts - block the incoming ip), then that fw machine sends the
[16:26] <weedmic> approved traffick to the actual webserver.  which I always make a live linux machine (DVD0) and the website (DVD1).  you can replace DVD1 whenever you want (since linux lets live swapping) to update your site's pages.  it's not that rare a thing.
[16:28] <weedmic> or use something like aws who will do it all for you (for a fee)
[16:30] <blscoe> sdeziel: I understand. Do you suggest that the logic control stay in a software layer, like intercept the requests like a PHP control layer? My problem is, how to hide of the user the real address of the pages.
[16:31] <blscoe> weedmic: this is not that I expected, but I like this kind of solution. Is this like a ssh tunneling?
[16:31] <sdeziel> blscoe: trying to hide a URL is useless, it provides 0 security
[16:33] <blscoe> sdeziel: for this reason I think in block the access via apache, not hide the url.
[16:34] <blscoe> If the user get the url he can access.
[16:35] <sdeziel> blscoe: we agree that there is a need to block the access when the user is not authorized. What I'm saying is that logic is best done inside PHP itself
[16:36] <sdeziel> blscoe: or if you want something simpler, there is always HTTP authentication that can be done by Apache
[16:41] <blscoe> sdeziel: thinking... :)
[16:42] <blscoe> sdeziel: oh. my problem is that I have multiples sites over a single domain. Implement an authentication for a single site I can realize, but for many I cannot think in a way to control it. Maybe restrict the access to the internal network is a good idea.
[16:43] <weedmic> ?maybe? - :D
[16:43] <sdeziel> blscoe: you can do per URI path authentication with apache. Doesn't matter if all your sites are using the same domain
[16:44] <sdeziel> blscoe: you can also use IP ACLs in your apache config/vhost definition
[16:44] <weedmic> blscoe: there are may approaches and this really sounds to me like at least one long scrum session would be necessary to figure out exactly what you want, present what could be done, and let you pick the path.
[16:49] <blscoe> ok. I got some informations here, I will seek more about that you said and try do something. It is my hobby project, so I need to do all thinks in my free time. But thanks for the tips and suggestions guys! Helped me a lot.
[18:16] <blscoe> sdeziel: I made a simple solution to deny access to all files in my apache server with htpasswd function. In the future I will need to implement a more sofisticated solution, but it works for now. When a user access the site the browser shows a popup asking for the user and the password to get access. You can create an user with a command line and the users and password are storaged in a file called htpasswd. You can implement the
[18:16] <blscoe>  access control for a entiry directory changing the specific site configuration in /etc/apache2/sites-available/site.conf or only a specific folder using the file .htaccess in the desire folder (after you enable the "AllowOverride All" option.)
[18:16] <blscoe> For references: https://httpd.apache.org/docs/1.3/howto/auth.html and https://www.interserver.net/tips/kb/apache-htpasswd-authentication-ubuntu/
[18:19] <blscoe> There are limitations for logout control, but are a trick to force logout. You need force the user access the url with another user request, like<EMAIL_ADDRESS>to change the user and force the user to send again your user and password.
[18:19] <sdeziel> blscoe: good. You probably are not running Apache 1.3 though ;)
[18:19] <blscoe> No. :P (Old references, sorry.)
[18:20] <blscoe> But works here and it justs for understand.
[18:20] <blscoe> I will consulting the update references...
[18:20] <blscoe> ...only for curiosity. :D
[18:24] <blscoe> Here: https://httpd.apache.org/docs/2.4/howto/auth.html
[18:25] <blscoe> sdeziel: I see that and I remember of you: " For general access control, see the Access     Control How-To."
[18:25] <blscoe> :D
[18:25] <blscoe> Thanks!
[19:38] <DSdavidDS> I am getting an issue as described in this post: https://askubuntu.com/questions/881175/why-installtion-fails-when-preseeding-the-partitioning-method. Has anyone run into something similar?
[19:43] <DSdavidDS> To answer a question in that post, I am booting legacy. I have also tried 'partman-auto/method string lvm' as well as 'partman-auto/method string regular' with the same result
[19:45] <DSdavidDS> https://xkcd.com/979/


[19:33] <Razva> seems that Autopilot doesn't "wants" to setup a 5 node OpenStack cluster. everything is "green" but Cinder fails to deploy. we're digging in the logs but we cannot find anything relevant. any hints?
[20:23] <Razva> [ERROR] Failed to upload leases: 'str' object has no attribute 'mac' < any hints?
[22:13] <balloons> veebers, ping
[22:13] <veebers> balloons: hey, what's the haps?
[22:14] <balloons> hey -- it's about this channel. Sadly openstack-autopilot is ALSO a thing, and it's 80% of what I see in here now
[22:14] <veebers> hah, right :-P
[22:14] <balloons> poor dobey has to keep telling people to join another channel for openstack issues
[22:14] <balloons> I tried to fix the topic, but I can't. Probably need someone from ubuntu-irc.
[22:14] <veebers> balloons: if the traffic is low enough perhaps we could move the (original ;-) )autopilot to -quality?
[22:15] <balloons> but if we're going to go that fair, might I suggest what we are doing in here?
[22:15] <balloons> well.. I mean; it's interesting openstack users find this channel, lol, because AP users never did!
[22:15] <veebers> balloons: I'm not sure I understand, is that a query about my suggestion to go to a different channel and fold this one?
[22:15] <balloons> I kid, only slightly
[22:15] <veebers> heh ^_^
[22:15] <veebers> yeah
[22:16] <balloons> My ramblings amount to a two questions: 1) How can we let people know we are talking about autopilot the testing tool, not openstack? 2) The bigger question. What should we do with this channel?
[22:17] <veebers> balloons: for the 2nd question I think we need to ask; how much conversation re: autopilot happens here?
[22:17] <balloons> So I guess since you jumped at shutting down the channel at the first hint of things, it sounds like perhaps you aren't too attached?
[22:18] <veebers> if it's a lot/enough then we should discuss improving the channel. If it's not enough perhaps we should consider conceding and consolidate somehow
[22:18] <balloons> I would say very litle happens now. It's always somewhere else. Since the tool itself isn't seeing thriving development, all AP conversations revolve around specific tests
[22:18] <balloons> those conversations then occur in teams channels
[22:18] <veebers> right, which is the feeling that I get
[22:19] <balloons> but first -- can you fix the topic to explain it's not openstack-autopilot?
[22:19] <balloons> that's the simple fix
[22:19] <veebers> I can try :-)
[22:20] <balloons> I see you and thomi as the only ones with powers in here. And thomi has control actually
[22:21] <balloons> so we can't do anything too fancy
[22:21] <balloons> without him anyway
[22:21] <veebers> right
[22:21] <dobey> heh
[22:21] <dobey> it's the same damn person
[22:22] <veebers> hmm, topic needs work
[22:23] <veebers> balloons: let me know what you think
[22:23] <balloons> perhaps tell them to join #ubuntu-server for openstack questions
[22:24] <dobey> i think there's an #ubuntu-openastack even
[22:24] <dobey> or at least, there is certainl a just #openstack channel
[22:24] <balloons> yes there is #openstack also
[22:24] <dobey> how the hell people don't find that, i have no idea
[22:24] <balloons> I guess I'd list those


[19:11] <janquark> @now
[19:11] <ubotu> Current time in Etc/UTC: February 25 2008, 19:11:21 - Next meeting: Platform Team in 1 day
[20:22] <mruiz> @schedule
[20:22] <ubotu> Schedule for Etc/UTC: 27 Feb 07:00: Platform Team | 27 Feb 12:00: Education Team | 27 Feb 21:00: Server Team | 28 Feb 14:00: Desktop Team | 29 Feb 12:00: MOTU | 05 Mar 07:00: Platform Team