[09:43] <trijntje> Is there a way to localise the screenshots in ubuntu-doc? There are file refs in the translation, but I've got no idea if they can be used to submit localised screenshots somewhere
[11:27] <trijntje> Is there a way to localise the screenshots in ubuntu-doc? There are file refs in the translation, but I've got no idea if they can be used to submit localised screenshots somewhere
[13:17] <kelemengabor> trijntje: currently, there is no way/process to submit screenshots, but the build system of ubuntu-docs could handle them. There was an agenda item about this for yesterdays roundtable session, but we had no time to talk about it. I hope we can find a way to do this properly for the Precise cycle.
[13:25] <trijntje> kelemengabor: it looks like there are only 25 'external refs' in the whole package, which means it would not be much work to make te screenshots for a translation team
[13:26] <trijntje> otoh, most explanation is in text, and not in the screenshots, so I could imagine this has a low priority for the folks of ubuntu-docs
[13:34] <kelemengabor> trijntje: that's true, but how exactly is this going to make it into the source? Do I have to submit all the screenshots at once, or is it okay to send one by one? Should I open a bug report and attach the pictures there, or submit a merge proposal? Who will have time to commit 25 images multiplied by 10 ... 30 languages? How do we keep track which image is obsolete? Questions, questions, work, work... we can sort it out, but
[13:41] <trijntje> kelemengabor: thats true, I'd say it would be best to document the procedure and leave it up to individual translation teams to make and submit the screenshots
[13:42] <trijntje> less than 10 languages are anywhere near fully translated, so we could alway's restrict localised screenshot to those languages which are >95% translated
[13:48] <kelemengabor> trijntje: sure. please do not let us forget about this issue - I'll try not to, but can't promise anything. Now, I gotta run, bye


[08:06] <MooDoo> howdy all
[09:11] <diplo> Morning all
[09:15] <SuperMatt> ahoy me hearties!
[09:15] <MooDoo> howdy howdy
[09:31] <foobarry> upgrading my firefox ..
[09:32] <foobarry> i have noticed a difference recently. since for a long time 50 tabs was the max i could use
[09:34] <Laney> not looking forward to losing vimperator
[09:34] <brobostigon> morning boys and girls.
[09:36] <MooDoo> just upgraded my firefox, well impressed so far, they were right it's a lot faster
[09:40] <foobarry> gonna buy a nosebag for disgusting eater in the office
[09:41] <foobarry> have 126 tabs running in my ff 57..lets see how it goes
[09:43] <TwistedLucidity> ARG! FF 57 has killed some of the most important addons! FireGestures is no more. :-(
[09:43] <foobarry> i only really have evernote clipper and ublock
[09:44] <TwistedLucidity> I've been using gestures for years, can live without it
[09:44] <TwistedLucidity> Yay!  You can have anything you like, so long as it is square and flat
[09:59] <foobarry> whats windows?
[09:59] <TwistedLucidity> I actually dislike this whole "flat" trend. It can make hard to see where one window/frame/section/thing starts and ends.
[09:59] <TwistedLucidity> foobarry: Windows is the defactor industry stanard. Where it leads, you will follow. OBEY THE BEAST OF REDMOND!
[09:59] <TwistedLucidity> *de facto
[10:00] <TwistedLucidity> The "hidden" scroll bars in KDE drive me up the wall. The float over text meaning it can be hard to select text under them.
[10:00] <TwistedLucidity> So FF57 follows the MS style guide even in GNBU/Linux?
[10:03] <diplo> TwistedLucidity: You won points last nigt for luci program, thank you :)
[10:03] <TwistedLucidity> diplo: Huzzah! Glad it worked
[10:04] <TwistedLucidity> Yeah, the separate the front-end and back-end. Which is kinda nice, when one remembers....
[10:07] <diplo> heh yep defo, I'd never used it before, searched for ages for the package, my google foo sucked
[10:07] <diplo> Going to try upgrading to lete tonight probably
[10:27] <SuperMatt> I'm looking forward to running the updates on my machines, so I can remove my manually installed copy of ff57
[11:20] <TwistedLucidity> Gadzooks! FF57 and landed in KDE Neon.
[12:39] <diddledan> I've switched my default browser to ff57 to see if I can live with it
[12:43] <TwistedLucidity> Install FoxyGestures. <3 me some gesturey goodness
[13:22] <m0nkey_> diddledan: how are you liking 57?
[13:22] <diddledan> pretty nice
[13:23] <SuperMatt> I've been using it since it was in nightly, and it's so fast it bought my crummy laptop back to life
[13:23] <m0nkey_> :)
[13:24] <m0nkey_> Don't have it on the work laptop yet as it's running ESR
[13:24] <m0nkey_> but i do have it in a VM. even in the VM it's damn fast
[13:24] <m0nkey_> fater than what 56 was with only 2GB RAM
[13:29] <SuperMatt> absolutely
[13:29] <SuperMatt> and container tabs are a thing of beauty
[13:30] <foobarry> what are container tabs?
[13:32] <SuperMatt> essentially they're "containers" which have different cookies
[13:32] <SuperMatt> meaning you can be logged in to the same site multiple times
[13:32] <SuperMatt> or you can do what I do
[13:32] <foobarry> oh tahts nice
[13:33] <SuperMatt> I'm logged in to facebook and google in my "personal" container tab, but browse the rest of the web in the "default" container tab
[13:33] <SuperMatt> This means that sites don't know I'm logged in to facebook
[13:33] <SuperMatt> It's different to private in that the cookies are still remembered
[13:50] <m0nkey_> hmm. where do i find this container tabs feature?
[13:54] <m0nkey_> nvm. found it
[13:56] <SuperMatt> container tabs are the killer feature which will keep me with Firefox, unless Chrome can do it and more
[14:04] <m0nkey_> I'm totally going to start using this.
[14:08] <SuperMatt> It's so awesome, right?
[14:09] <SuperMatt> really it's the feature that FF should be pushing above all else in this release
[14:13] <diddledan> you didn't tell us where you found it though
[14:13] <diddledan> please think about those of us that were waiting for the answer and didn't ask because you did
[14:20] <SuperMatt> https://addons.mozilla.org/en-GB/firefox/addon/multi-account-containers/
[14:49] <diplo> Just installed this myself, trying to see how it works
[15:14] <m0nkey_> diddledan: google it :P
[15:59] <awilkins> Oooh, that's shiny
[15:59]  * awilkins creates containers for each Amazon account
[15:59] <awilkins> AWS MASTEH
[21:38] <daftykins> diddledan: i killed another drive today, it had an old 12.04.5 install on it so i dd zero filled it from the booted OS :D got to watch the journal fail and be disabled
[21:39] <daftykins> nah i jest, it had 24 bad sectors before i started
[21:41]  * zmoylan-samj3 remembers the good old days when you had to type ib the supplied list of bad sectors to novell before it would prepare the drive :-)
[21:41] <daftykins> crikey
[21:42] <zmoylan-samj3> cheaper drives had long long lists... my boss was cheap...
[21:42] <daftykins> they provided you with the manufacturer-known bad sectors and you had to avoid them by hand? ugh they just got into the firmware eventually
[21:42] <daftykins> P-list and G-list, production and grown
[21:43] <zmoylan-samj3> this was before ide with controllers mounted to the drive esdi, rll drives
[21:43] <daftykins> ah yeah, so the OS was talking directly to the motor - or was there still something between?
[21:44] <zmoylan-samj3> duct tape and hope :-)
[21:44] <daftykins> err mobo side controller would exist surely
[21:45] <zmoylan-samj3> massive expansion card with 2 cables iirc for esdi to talje to drive obe for data, one for motor control
[21:45] <daftykins> O_O
[21:46] <zmoylan-samj3> i once made the mistake of wiring one up correctly and ruined 3 days plus weekends of novell preparing the drive
[21:46] <zmoylan-samj3> it was meant to be wired incorrectly, silly me
[21:48] <zmoylan-samj3> now it's all hot swap raid with your namby pamby wishy washy cloud backup... :-)
[21:50] <daftykins> :D
[21:51] <zmoylan-samj3> and the old timer at that time complained about us sending drive back... in his day they'd send an engineer to repair it on site
[21:51] <zmoylan-samj3> or attempt to. multimeter to check the boards, desolder and replace if that was problem
[21:51] <daftykins> hahaha, how big were those drives then, still fill a hamster cage?
[21:52] <zmoylan-samj3> 5mb drive for cpm computer was full height. think 2 5.25! bays filled with one drive
[21:53] <daftykins> ah yeah
[21:53] <zmoylan-samj3> we used them as door stops. they were indestructible
[21:53] <zmoylan-samj3> should have kept one to make a sledgehammer...
[21:53] <zmoylan-samj3> 10mb were 3 years later and half height. so size of cd rom drive
[21:55] <daftykins> cor - and now here's me tossing dead multi terabyte ones
[21:56] <zmoylan-samj3> and i remember a cpm machine brought in with a sound card... music files were midi as no space for real audio
[21:57] <daftykins> haha :D i still remember having to sellotape in the RAM on the creative labs AWE32
[21:57] <zmoylan-samj3> sir clive and his blu tack salute you o>
[21:59] <zmoylan-samj3> about 4pb contains the library of congress... a.c.clarke said mid century... we're getting there
[22:37] <daftykins> a clients house was so hotly heated today, my Yorkie melted!
[22:57] <zmoylan-samj3> i seem to remember in wwii hersheys in america made a bar that xould be carried in pocket in tropucal climea without melting... of course even by american chocolate standards it wasn't nice
[22:57] <daftykins> :D
[22:59] <zmoylan-samj3> american dwarf bread... :-P


[05:29] <jkitchen> I'd like to blacklist a module (qla2xxx specifically) during the installer but *not* have that persist into the installed system
[05:30] <jkitchen> seems I can add qla2xxx.blacklist=yes kernel param to installer, but that persists through
[05:30] <jkitchen> 1) I don't want one of my LUNs coming up as sda or sdb and getting owned. and 2) the scanning partitions takes *forever* with a bunch of LUNs visible
[05:32] <jkitchen> there a proper way to do this? or is it gonna be a sed to kill the line from /etc/modprobe.d/blacklist.conf in my late_command script?
[06:02] <jkitchen> wow, blacklisting that module sped my install up significantly
[06:02] <jkitchen> now just to figure out the best way to unblacklist it :)


[09:36] <flocculant> knome slickymasterWork - thoughts on adding a new slide to the slideshow - 'new stuffs we've got'
[23:39] <knome> flocculant, i'd rather add a slide for such things in a non-generic way once we have new stuff that is worth mentioning :)


[14:31] <dugie> hello
[14:31] <dugie> I have a question about gno-menu ... for whatever reason the Tweak Tool > Extensions > Gno-menu is erroring out with this message "Error loading extension" ... I put a video together on youtube to explain the situation here: https://www.youtube.com/watch?v=vBr-5h2oxpY ... any assistance would be greatly appreciated ... thank you in advance
[14:31] <dugie> I have a question about gno-menu ...
[14:31] <dugie> for whatever reason the Tweak Tool > Extensions > Gno-menu is erroring out with this message "Error loading extension"
[14:31] <dugie> I put a video together on youtube to explain the situation here: https://www.youtube.com/watch?v=vBr-5h2oxpY ... any assistance would be greatly appreciated ... thank you in advance
[14:34] <dugie> sorry about the duplicate question ... it appeared that part of my question was cut off .. that's why i duplicated it
[14:49] <dugie> I have a question about gno-menu ... for whatever reason the Tweak Tool > Extensions > Gno-menu is erroring out with this message "Error loading extension" ... I put a video together on youtube to explain the situation here: https://www.youtube.com/watch?v=vBr-5h2oxpY ... any assistance would be greatly appreciated ... thank you in advance
[16:26] <nathaneltitane> hola!
[16:27] <nathaneltitane> question: how can i set my LVDS laptop monitor (1600x900) top pan vertically only and match my external HDMI output (1920x1080) to get the missing cropped space to show on mouse hover
[16:37] <nathaneltitane> anyone?


[12:34] <luisbg> joejaxx, ping!
[12:35] <luisbg> LaserJock, ping!
[12:36] <joejaxx> ?
[12:36] <luisbg> joejaxx, join ubuntu studio now
[12:36] <LaserJock> luisbg: what?
[12:36] <joejaxx> ? lol
[12:37] <jdong> [Sun Dec 03 17:02:42 2006]  [error]  [client <IP_ADDRESS>]  File does not exist: /var
[12:37] <joejaxx> luisbg: i am already there
[12:37] <luisbg> we got a cinelerra developer in ubuntu studio right now
[12:37] <jdong>  /www/i/know.where.you.live.and.will.hunt.you.down.{censored racial slur}
[12:37] <joejaxx> jdong: haha
[12:37] <jdong> lovely :)
[12:37] <luisbg> he is very interested in packaging it for ubuntu
[12:37] <joejaxx> oh no
[12:37] <luisbg> and becoming part of the ubuntu community
[12:37] <joejaxx> jdong: what is that?
[12:37] <jdong> now I'm even getting threats through my apache logs :D
[12:37] <joejaxx> man that is crazy
[12:37] <jdong> joejaxx: well apparently someone really hates me?
[12:37] <jdong> lol
[12:37] <luisbg> some lines from any motu saying he will be helped would be cool, since he says he doesn't know much about packaging
[12:37] <joejaxx> jdong: :(
[01:06] <Admiral_Chicago> ubuntu-doc
[01:06] <Admiral_Chicago> err ignore that
[01:22] <crimsun> tsmithe-afk: um, duplicating asoundconf(1) functionality is madness
[01:23] <crimsun> tsmithe-afk: I'm currently integrating pulseaudio support into asoundconf(1), so you'd have to resync at each iteration. It's much more sensible to invoke asoundconf directly from your gui and to Depend on alsa-utils in debian/control.
[01:25] <Simon80> ajmitch: look at autotools-dev for what?
[01:25] <Adri2000> hi crimsun, have you read my comment on bug 74088 ?
[01:25] <Ubugtu> Malone bug 74088 in oo2c "Please sync oo2c (universe) from unstable (main)" [Wishlist,Needs info]  http://launchpad.net/bugs/74088
[01:26] <Laser_away> Adri2000: did you ask me to revu a couple packages for you the other day?
[01:26] <Adri2000> Laser_away: yeah, this one: http://revu.tauware.de/details.py?upid=3553
[01:27] <Laser_away> Adri2000: that's the only one?
[01:27] <Laser_away> I lost my todo list so I'm trying to not be mean and forget people ;-)
[01:28] <Adri2000> ok :) there is also http://revu.tauware.de/details.py?upid=3540 but waiting for a new upstream release
[01:28] <Laser_away> ok, I won't do that one yet then
[01:34] <ajmitch> Simon80: the lintian issue you asked me about
[01:34] <crimsun> Adri2000: I'm about 1/10th through my e-mail flood; I'll probably get around to it in 4 hours.
[01:34] <Adri2000> crimsun: okay :-)
[01:37] <Simon80> ajmitch, err, isn't it as simple as running autoconf in the directory?
[01:37] <Simon80> incidentally, the Makefile.am does it, so probably that means that the lintian warning can be ignored
[01:38] <Simon80> ah, ajmitch, thanks a lot, the README is nice and informative
[01:39] <Burgundavia> ajmitch: ping
[01:44] <ajmitch> Burgundavia: yes?
[01:44] <Burgundavia> ajmitch: compiz... I had a question, but now I have lost it
[01:44] <ajmitch> fine
[01:48] <ademan> hey is there any possibility of someone working side by side with me on this stupid eclipse-cdt?
[01:49] <zul> meh..
[01:58] <ademan> hrm, would it be bad of me to make a *.deb of the eclipse-cdt without source? (ie make it from the java jar files)
[01:58] <ademan> its platform independant, but it's also not source...
[02:00] <zul> yes
[02:00] <zul> it would be bad
[02:10] <ademan> zul: weak, cause i think i could have had a chance packaging it from scratch
[02:14] <Simon80> well, given its history, calling java bytecode arch independent is a stretch sometimes
[02:14] <jdong> Simon80: the bytecode is arch-independent, sure ;-)
[02:15] <jdong> but that doesn't mean it'll work on all arches :)
[02:15] <lifeless> whats the cdt licence
[02:15] <Simon80> jdong: I was making fun of java
[02:15] <Simon80> ah
[02:15] <Simon80> nvm
[02:15] <jdong> so was I :)
[02:15] <lifeless> it will say much more about whether its ok to package from the jars
[02:16] <Simon80> plugwash: too late, haha
[02:16] <plugwash> Simon80 last i checked they had opensourced the compiler (virtually zero value) and the vm (reasonablly high value) but not the class libraries (highest value)
[02:16] <Simon80> ah
[02:17] <Simon80> yeah, that's still the last I heard
[02:17] <Simon80> I think they will, I mean, they GPL'd the VM
[02:17] <Simon80> now they can't stop, or else they're flipflopping, that looks bad
[02:21] <plugwash> the impression i always got was that sun had a dual personality
[02:22] <plugwash> on the one hand they seem to think its good for them if *nix gains ground over windows and if java gains ground over microsofts java derivitives/clones (j++ and .net)
[02:23] <plugwash> on the other hand they know as well as anyone else how much damage lintel has done to traditional unix vendors
[02:23] <lifeless> they make money on hardware
[02:23] <lifeless> so as linux grows, they get to sell more niagaras ?
[02:25] <plugwash> yes, but traditional unix only ran on expensive high end hardware
[02:25] <plugwash> linux runs on cheap intel/amd based whiteboxes
[03:28] <Simon80> sun sort of has a weird strategy like that
[03:35] <Simon80> but one could argue that linux is good for them, they DO sell hardware..
[03:37] <Simon80> joel spolsky had a piece where he says, ok, they're commoditising the software by open sourcing staroffice and stuff, but they're commoditising hardware by supporting java
[03:38] <Simon80> I don't know if that makes sense, cause open source software is made fairly portable just by being open source, which is similar to java
[03:39] <Simon80> what it means is that there's more software that will run on your hardware
[03:39] <Simon80> but at the same time, lots of other people's hardware
[03:39] <lifeless> his thing was about complementary products
[03:39] <Simon80> yeah
[03:40] <lifeless> so java is about enterprise right
[03:40] <lifeless> if you make the enterprise software pervasive
[03:40] <Simon80> not really
[03:40] <lifeless> in the context of java & sun hw it is :)
[03:40] <Simon80> yeah, true
[03:40] <Simon80> which is wierd
[03:40] <lifeless> things like ME are clearly different
[03:41] <Simon80> whenever I see people using java on a server, I'm like, what? but when I think about it, unless you use fastCGI or something, you're going to be using a scripting lang of some kind
[03:41] <Simon80> php, lisp, perl, python, ASP, .NET (which is like java)
[03:41] <lifeless> java is pretty fast
[03:41] <lifeless> the hotspot vm - slick as
[03:42] <Simon80> I wouldn't really know.. but my desktop java experience has always left me wishing for a native app
[03:42] <zul> oh hey lifeless
[03:42] <Simon80> mostly when on windows htough
[03:42] <lifeless> Simon80: in which regard, UI? performance? startup ?
[03:42] <lifeless> zul: hi
[03:42] <Simon80> lmao, lifeless, that about sums it up, just remove the "in which regard" part
[03:43] <Simon80> memory usage is part of performance, to be clear
[03:43] <Simon80> cause that's another thing
[03:48] <Simon80> I'm doing another upload of stepmania, feel free to review it anyone
[03:48] <Simon80> I didn't repack the original tarball, but I remove some cruft in clean instead
[03:59] <nixternal> are the us archives ever coming back
[05:05] <Laser_away> rmjb: around?
[05:05] <rmjb> ya
[05:06] <jabra> hey guys
[05:06] <Laser_away> rmjb: did you ask me to do a review the other day?
[05:06] <rmjb> yeah, the iriverter, I just updated the dependency as per my email to the list today
[05:08] <rmjb> I'll send you the fresh link
[05:08] <rmjb> you have time now?
[05:12] <Laser_away> rmjb: not exactly now, but I lost my todo list so I wanted to make sure I didn't leave anybody hanging
[05:13] <rmjb> I'll send it to you in an email then... I have to go to sleep now anyhow
[05:13] <rmjb> one question about depends, recommends and suggests though
[05:13] <Simon80> Laser: I need a review :)
[05:14] <rmjb> iriverter needs java to start, but needs mplayer, mencoder and ffmpeg to function, should they all go under depends?
[05:17] <Laser_away> is it going to be of any use without them?
[05:17] <rmjb> nah, just look pretty
[05:17] <Simon80> lol
[05:17] <rmjb> so depends
[05:17] <rmjb> thanks
[05:17] <Simon80> does it need all three to be useful?
[05:17] <rmjb> yep
[05:17] <Simon80> well then
[05:17] <Simon80> lol, nobody will want it without them, right?
[05:18] <rmjb> just wanted to know if depends is only for what's needed to get the prog running
[05:18] <rmjb> Laser_away: I'll send you that email now, thanks again
[05:18] <Laser_away> no, more like things that make it actually work
[05:18] <Simon80> heh, no, but that's probably in the debian policy manual
[05:18] <Simon80> which is rather descriptive
[05:18] <Laser_away> if they are optional put them in Recommends
[05:18] <Simon80> though lintian seems to be more detailed sometimes
[05:18] <Simon80> like complaining that my extended description lines are too long
[05:19] <Simon80> it's not in the DPM
[05:22] <Simon80> Laser_away, do you care to put me in your TODO?
[05:24] <Laser_away> I can, I certainly can't promise I'll get to it right away
[05:24] <Laser_away> but I can add to the list ;-)
[05:27] <Simon80> sure
[05:28] <Simon80> stepmania and stepmania-data
[05:28] <Simon80> but I hope you prefer preserving the upstream tarball over repacking it to remove upstream cvs cruft
[05:28] <Simon80> like, not a lot of cvs cruft
[05:28] <Simon80> 4 files
[05:29] <rmjb> well I'm off to bed
[05:29] <rmjb> g'night all
[05:29] <Simon80> night
[05:36] <Simon80> I'm doing another upload of stepmania and stepmania-data, to fix some binary warnings from lintian
[05:37] <Simon80> I've done too many uploads... but anyway, that's it, hopefully in a week's time or so someone will have seen fit to review them (pretty please), and I'm not going to bug anyone about it during that time
[05:38] <Simon80> nor am I uploading any more revisions, hehe
[05:44] <Hobbsee> Simon80: keep bugging about it, it's fine.  and uploading - it's what REVU is for
[05:44] <Simon80> hehe
[05:44] <Simon80> it shouldn't take bugging, my package is a killer app ;)
[05:44] <crimsun> upid?
[05:44] <Simon80> that's why i'm packaging it
[05:45] <ajmitch> Hobbsee: too much bugging in a short time can be detrimental, however
[05:45] <Simon80> hehe..
[05:46] <crimsun> Simon80: upid?
[05:46] <Simon80> crimsun: what?
[05:46] <Simon80> lol
[05:46] <crimsun> the revu upid for stepmania.
[05:46] <Simon80> ohh
[05:46] <Simon80> hehe, sorry
[05:46] <Simon80> lemme fetch it
[05:46] <Hobbsee> ajmitch: true
[05:46] <Simon80> you could just go to revu.tauware.de and find it... but one sec
[05:47] <crimsun> yes, I could, but then I wouldn't have asked for it.
[05:47] <Simon80> lol
[05:47] <Simon80> http://revu.tauware.de/details.py?upid=3662, http://revu.tauware.de/details.py?upid=3663
[05:47] <Simon80> both are needed
[05:47] <Simon80> one is just data
[05:51] <crimsun> for 3662, have you considered stripping the cvs copies/data to generate a 3.9+ubuntu.orig.tar.gz?
[05:52] <Simon80> ...others have, I thought it was a bad idea?
[05:52] <Simon80> I mean, like, I don't see why it's better to complicate things by changing the orig tarball just for the sake of the cruft
[05:53] <crimsun> depends what you consider "good practice"
[05:53] <crimsun> the clean target won't remove said cruft regardless
[05:53] <Simon80> I thought preserving upsteam was good practice
[05:53] <crimsun> it surely is.
[05:54] <crimsun> having no cruft in the orig.tar.gz is also good practice.
[05:54] <Simon80> what do you mean about clean? I know it doesn't remove it from the sources, but at least nobody can complain that it's interfering with the build
[05:54] <Simon80> I don't see why no cruft is better practice than preserving upstream though
[05:55] <crimsun> preserving upstream is not necessarily best given one's approach
[05:55] <crimsun> see automake1.9, for instance.
[05:56] <Simon80> what about automake?
[05:56] <crimsun> look at the orig.tar.gz
[05:56] <Simon80> you want me to source it right now?
[05:57] <crimsun> automake1.9_1.9.6+nogfdl.orig.tar.gz
[05:57] <Simon80> ok, that's irrelevant, that's a licensing issue
[05:57] <crimsun> that's not irrelevant.
[05:57] <Simon80> to this cruft issue, yes, I would say
[05:57] <crimsun> I wouldn't.
[05:57] <Simon80> that is one example of a reason to repack
[05:58] <crimsun> if I were rolling stepmania, I'd strip the cruft.
[05:58] <Simon80> but licensing issues aren't the same as cruft issues
[06:00] <Simon80> from common mistakes:
[06:00] <Simon80> The following are not reasons to change the original tarball:
[06:00] <Simon80> Files need to be removed to keep the .diff.gz small (e.g., files created by autotools). Everything that needs to be deleted should be removed in the clean rule. Since the .diff.gz is created with diff -u, you will not see removed files in the .diff.gz.
[06:01] <Simon80> I delete anything that needs to be deleted in the clean rule, just like it says
[06:01] <Simon80> https://help.ubuntu.com/ubuntu/packagingguide/C/basic-mistakes.html
[06:01] <crimsun> again, that's your approach.
[06:02] <Hobbsee> crimsun: you're a core dev arent you?
[06:02] <Simon80> oh, so you aren't saying my approach is bad?
[06:02] <crimsun> Simon80: I've not said it's bad, no.
[06:02] <crimsun> Hobbsee: yes
[06:02] <Simon80> ok, cause a couple of other MOTUs seemed to be saying that leaving it in was THAT bad
[06:03] <crimsun> Simon80: personally it's unclean and not best practice, but it's not wrong.
[06:03] <Simon80> one of them even went so far as to say that a package not putting prefs in ~/.package was equally as bad as cruft
[06:04] <Simon80> I agree it's unclean, but I feel just as unclean repacking just for cruft, and the guidelines in the the common mistakes discussion seem to agree with me, and I think those guidelines make sense
[06:06] <Simon80> argh, edgy's nautilus managed to get released with a spinlooping bug
[06:06] <Simon80> and it happens so often, it's amazing
[06:07] <Simon80> thanks for looking at my package, btw
[06:07] <Simon80> crimsun
[06:19] <superm1> crimsun, do u have a min to do another revu?
[06:19] <crimsun> I will after stepmania-data
[06:19] <superm1> okay cool
[06:21] <Simon80> thank you very much crimsun
[06:22] <crimsun> Simon80: debian/copyright seems a bit odd for stepmania-data, and its Description needs to be changed to describe its actual function
[06:22] <Simon80> the description in control?
[06:22] <crimsun> yes, the one-line summary
[06:22] <Simon80> oh, the one liner
[06:22] <Simon80> ok
[06:23] <Simon80> feel free to suggest
[06:23] <Simon80> you just mean for data, right?
[06:23] <Amaranth> ajmitch: I'm sure you'll be happy to know I'll now be fighting to _not_ have beryl in ubuntu-desktop.
[06:23] <Simon80> lol
[06:23] <crimsun> Simon80: stepmania-data only, yes
[06:23] <Simon80> just beryl? why beryl?
[06:23] <ajmitch> Amaranth: haha, excellent
[06:24] <crimsun> Simon80: ([for stepmania-data]  debian/control references files that don't exist)
[06:24] <Amaranth> I had my python stuff as LGPL, Quinn threw a fit because she is a GPL-freak, now they're talking about hijacking my stuff the same way they hijacked compiz and making it GPL
[06:25] <ajmitch> I love this *community* project
[06:25] <Simon80> lol
[06:25] <crimsun> oh it's certainly community!
[06:25] <Simon80> crimsun, explain?
[06:25] <Simon80> about my control, I mean
[06:25] <Amaranth> ajmitch: Did you know they changed everything from MIT to GPL?
[06:26] <Amaranth> They had a document saying it was GPL but all the code still said MIT. They just finished actually changing it
[06:26] <Amaranth> So now they can take freely from compiz but compiz can't touch their code
[06:26] <ajmitch> that's... special
[06:26] <crimsun> Simon80: RageFileDriverZip.cpp, src/crypto/, RageSurfaceUtilsPalettize.cpp, libmad, etc.
[06:26] <Simon80> oh, copyright?
[06:27] <crimsun> yes
[06:27] <crimsun> sorry, meant copyright
[06:27] <Simon80> I copied that all verbatim from the same tarball..
[06:27] <Lathiat> Amaranth: im pretty sure you can *actually* relicense LGPL to GPL tho
[06:27] <Lathiat> right?
[06:27] <crimsun> Simon80: that's my point :)
[06:27] <Simon80> yeah
[06:27] <Simon80> what should I do though?
[06:27] <Amaranth> Lathiat: They can.
[06:27] <Amaranth> Lathiat: They're talking about 'freeing' my code right now.
[06:28] <crimsun> Simon80: since those files aren't actually in the source package for stepmania-data, they shouldn't be included in stepmania-data's debian/copyright.
[06:28] <Simon80> lol, if it was freeing, it wouldn't be legal
[06:28] <ajmitch> Lathiat: it's not a matter of whether it's possible, it's a matter of whether it's right to do so
[06:28] <crimsun> Simon80: the relevant info for the actual files in -data should be
[06:29] <Lathiat> ajmitch: i beleive their perfectly within their right too
[06:29] <Lathiat> that said
[06:29] <Lathiat> the whole beryl thign seems like a big mes
[06:29] <ajmitch> Lathiat: sure, if they want to just fork everything & never worry about being able to give code back
[06:29] <Lathiat> and im jsut goign to stay away from it
[06:29] <Simon80> crimsun: the original copying file is in the / of the orig
[06:29] <ajmitch> which is pretty much how things have gone now
[06:29] <Lathiat> nod
[06:29] <Simon80> so you can see that's all I have to work with from upstream
[06:29] <Lathiat> what about MIT->GPL tho
[06:29] <Lathiat> is that legal?
[06:30] <Amaranth> Haha, Quinn said he wishes he could fork ever BSD project just to make it GPL
[06:30] <Amaranth> Fucking looney tunes.
[06:30] <Simon80> Lathiat, yes, stepmania ddoes it
[06:30] <Simon80> I mean, they include gpl code
[06:30] <Simon80> which implies that yes, it's gpl compat
[06:31] <Simon80> wow, talk about anal about licensing, lol, I mean, sure you may have a different opinion from the BSDs, but GPL forking it is a hostile move
[06:32] <Simon80> you only acheive any good copylefting if you include your own code in there that makes the GPL fork more appealing... in effect destroying the BSD licensed project
[06:32] <Simon80> embrace, extend, extinguish, right?
[06:32] <mnepton> do we *ahve* to talk about anal licensing? that just leads to discussions of open anal licensing, and things inevitably trundle downhill from there.
[06:33] <Lathiat> i think 'trundle' is a bit slow
[06:33] <Lathiat> turn into a rolling landslide?
[06:33] <Simon80> haha
[06:33] <Lathiat> with an earthquake *and* hat lava chasing you?
[06:33] <ajmitch> mnepton!
[06:33] <mnepton> AUGH!
[06:34] <Amaranth> So, uh, I think sabdfl is the _only_ person still pushing for beryl.
[06:34] <Amaranth> And since I'm no longer writing the user-friendly frontend stuff that would be required...
[06:34] <Simon80> crimsun: The following license applies to most of the StepMania codebase [including this package] :
[06:34] <Simon80> and then sm's MIT license
[06:34] <Simon80> and nothing irrelevant after
[06:34] <Simon80> is that ok?
[06:35] <crimsun> Simon80: there's no actual code in this source package, though.
[06:35] <Hobbsee> Amaranth: then no beryl-by-default?  yay!
[06:36] <Amaranth> Hobbsee: Pretty much
[06:36] <Hobbsee> :P
[06:36] <Lathiat> do we get compiz-by-default?
[06:36] <crimsun> Simon80: i.e., under what license(s) are these images available?
[06:36] <Amaranth> Quinn claims he'll write the new frontend but, uh, have you _seen_ beryl-settings? :)
[06:36] <Simon80> crimsun: I think that's all I've got
[06:36] <Amaranth> Lathiat: That'd be nice
[06:36] <Lathiat> or how bout
[06:36] <Lathiat> compiz-installed-by-disabled-by-default? :P
[06:36] <Amaranth> Lathiat: And I think it's already got metacity binding compatibility
[06:36] <crimsun> Simon80: I'm also noting a StepMania-3.9a binary package (which I presume contains the data) on sf.net
[06:36] <mnepton> i want compositing. i just don't want it now.
[06:37] <Simon80> yeah, that's the orig for sm-data
[06:37] <ajmitch> everyone else seems to be moving towards compiz
[06:37] <crimsun> Simon80: so the data are identical (not diff from 3.9)?
[06:38] <elkbuntu> mnepton, exactly. i'd rather wait until it's ready for use
[06:38] <Simon80> crimsun: when you say strip the leading article, you men remove "A free", right?  - and yes, I mean that they only included the data in the binary release, so you need it with the source as well, see stepmania.com
[06:38] <crimsun> Simon80: "A"
[06:38] <Simon80> oh
[06:38] <crimsun> package is a "foo bar blah"
[06:39] <Simon80> right, ok, there's prolly something in the DPM about that, huh
[06:39] <crimsun> instead of package is a "a foo bar blah"
[06:39] <crimsun> if there currently isn't, there should be a patch made available :-)
[06:39] <mnepton> linux compositing is like freddy kreuger. you see and it's like "zomg! pinch me i'm dreaming!" and then *just* as you begin to think you haven't really fallen asleep *BAM* it's all chainsaws and entrails
[06:39] <mnepton> or something like that.
[06:40] <Simon80> crimsun: patch? you talking about stepmania? if so, I'm confused what is being patched
[06:40] <crimsun> well, xfwm4 4.2+ have compositing, but imo it's not worth switching environments just to gain that. YMMV.
[06:40] <crimsun> Simon80: I'm referring to the Ubuntu packaging guide
[06:40] <Simon80> oh
[06:40] <Simon80> lol
[06:41] <ajmitch> crimsun: opengl compositing?
[06:41] <Amaranth> crimsun: that's XRender based
[06:41] <crimsun> ah, thanks.
[06:41] <Amaranth> crimsun: You can do that with xcompmgr, same thing.
[06:42] <Simon80> so crimsun: is my copyright fine? I'm going to upload that and stepmania and go to bed
[06:43] <Simon80> ie. is removing the irrelevant stuff, and leaving in the MIT license
[06:43] <Simon80> ok
[06:43] <crimsun> Simon80: it would be best to get clarification from upstream themselves regarding those files
[06:43] <Simon80> ah
[06:43] <Simon80> :(
[06:44] <crimsun> trust me, you want to put in the time now, since the archive admins will reject this source package if you don't include all the license info
[06:46] <crimsun> thanks for working on the packaging!
[06:46] <crimsun> superm1: ping, which source package?
[06:47] <superm1> pong.... http://revu.tauware.de/details.py?upid=3396
[06:47] <superm1> its been sitting up there a while
[06:47] <crimsun> thanks
[06:47] <superm1> it was derived from flashplugin
[06:47] <superm1> nonfree
[06:47] <superm1> installer
[06:48] <superm1> once this sort of package is down for ivtv-firmware, i am planning to do the same sort of thing for pchdtv 2k,3k cards and ATI HDTV Wonder cards, with firmware packages for them
[06:48] <crimsun> superm1: hmm, you might want to take a look at the current flashplugin-nonfree source package, then, because Bart cleaned it up significantly.
[06:49] <Simon80> crimsun: what kind of clarification, do I need proof of what was said about it or something?
[06:49] <Simon80> Hobbsee: from Debian? good enough for Debian but not Ubuntu?
[06:49] <crimsun> Simon80: yes, including e-mail is sufficient, but actual changes to upstream cvs are even better
[06:49] <Hobbsee> Simon80: i'm not sure how that slipped through
[06:50] <superm1> how current is the "current"?  I think i actually took this one from sabfdl's repository or someone elses that used a flashplugin 9
[06:50] <superm1> and modified from that
[06:50] <Simon80> Hobbsee: what?
[06:50] <Hobbsee> Simon80: from debian - i dont know how those couple of packages got into debian
[06:50] <crimsun> superm1: current current; see the source package in feisty/multiverse
[06:50] <Simon80> oh
[06:50] <superm1> oh.
[06:51] <ademan> crimsun: i'm royally frustrated with the eclipse-cdt at this point, do you know if there's any place i can get attention for this?  for help or otherwise?
[06:52] <Simon80> does the package now just bundle flash? it seems to
[06:52] <ademan> like a mailing list or something?
[06:52] <superm1> ah i see it has been cleaned up
[06:52] <superm1> crimsun, should I redo it against that one then u think?
[06:52] <lifeless> ademan: yes, the motu list may help.
[06:52] <lifeless> ademan: I'm interested in this but too busy right now to do much. sorry.
[06:53] <ademan> lifeless: that's fine, thanks for the mailing list, i'll google but do you have a link?
[06:53] <ademan> !motu list
[06:53] <ubotu> Sorry, I don't know anything about motu list - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[06:53] <crimsun> superm1: personally preferable, yes, but it's your choice. I think you'll find the migration quite advantageous.
[06:53] <superm1> yikes simple debian rules :)
[06:53] <crimsun> ademan: ubuntu-motu at lists dot ourfavouritedistro
[06:54] <superm1> crimsun, that being the case, i think i will just redo it against this newer one
[06:54] <superm1> its *much* prettier
[06:54] <crimsun> superm1: great, thanks!
[06:54] <ademan> ourfavoritedistro dot com or just dot ourfavoritedistro ?
[06:54] <crimsun> former
[06:54] <superm1> if i finish up tonite, i'll ping you,elsewise again in a day or two :)
[06:54] <crimsun> superm1: ok
[06:56] <ademan> thanks crimsun
[06:56] <crimsun> np
[06:57] <Simon80> isn't the latest flash package just bundling it as opposed to dling it?
[06:58] <superm1> i dont see the .so sitting in the .tar.gz, and it looks to still download it at first glance
[06:58] <Simon80> hmm
[06:58] <superm1> yea it still downloads it
[06:58] <crimsun> Simon80: nope.
[06:58] <crimsun> it has to download it.
[06:58] <Simon80> but when? it's in my installed files guys
[06:58] <Simon80> /usr/share/lintian/overrides/flashplugin-nonfree
[06:58] <Simon80> /usr/lib/mozilla/plugins/libflashplayer.so
[06:58] <Simon80> /usr/lib/firefox/plugins/libflashplayer.so
[06:59] <crimsun> those are symlinks.
[06:59] <crimsun> take a look at 'em.
[06:59] <Simon80> oh, ok
[06:59] <Simon80> I'm too lazy, man
[07:00] <Simon80> I'm uploading stepmania..  but it's not worth it to upload stepmania-data till I get a reply, right?
[07:00] <crimsun> Simon80: for stepmania-data, debian/copyright is a blocker
[07:00] <crimsun> so, correct.
[07:00] <Simon80> the other issue is stepmania's appearance infringing on Konami's properties
[07:01] <Simon80> they haven't been sued, really, but it's evidently an issue, cause 4.0 features a revamped, intentionally different theme and terminology
[07:01] <crimsun> that's not really any issue, since it'll go into universe due to its license
[07:01] <crimsun> s/any/an/
[07:01] <Simon80> universe?
[07:01] <Simon80> .......
[07:02] <Simon80> universe is for free stuff, no?
[07:02] <crimsun> yes. Is there anything in stepmania that isn't?
[07:02] <Simon80> no
[07:02] <Simon80> not in the source, definitely
[07:02] <crimsun> then its target is universe.
[07:03] <Simon80> but I mean, I don't see how putting it in universe moots the whole infringement thing
[07:03] <crimsun> Ubuntu tends to follow Debian's policy with such regards.
[07:03] <Simon80> is that in the DPM?
[07:06] <Simon80> if so, what section of the DPM
[07:06] <Simon80> 2.3?
[07:09] <crimsun> I don't see anything in DPM regarding it.
[07:09] <crimsun> s/policy/practices/
[07:10] <crimsun> e.g., libmad is in Debian main
[07:10] <crimsun> (even mplayer)
[07:11] <crimsun> if it turns out there are license restrictions, then both stepmania and stepmania-data may have to go to multiverse
[07:17] <Simon80> I think the only issue is the infringement, I would assume that upstream wants their data to be free along with the code, and the copying file seems to indicate that
[07:18] <crimsun> right, and thus universe candidates
[07:23] <Simon80> but what I would think the issue is is that upstream says it's free, but it infringes on Konami
[07:24] <crimsun> that's not enough to punt it into multiverse
[07:25] <Simon80> ah, sweet
[07:25] <Simon80> well then I'll just ignore it and ask them how they want to license it :D
[07:26] <Simon80> I mean, I don't think any of the data is a blatant rip, iirc, it's just that they (Konami) may have reason to call it a derivative work in the same way LKMs are derivative of the kernel
[07:30] <Simon80> silly hats only!
[08:10] <dholbach> good morning
[08:11] <Burgundavia> morning dholbach
[08:11] <dholbach> hi Burgundavia
[08:12] <Burgundavia> going to rock with a new week of Telepathy?
[08:12] <dholbach> and new GNOME
[08:12] <dholbach> (once the archive is unfrozen again)
[08:12] <Burgundavia> yep
[08:12] <superm1> crimsun, still around?
[08:13] <crimsun> superm1: yes
[08:14] <superm1> okay i just finished up and ran the package install a few times.  i love this newer flashplugin basis :)
[08:14] <superm1> http://revu.tauware.de/details.py?upid=3665 if you can take a look
[08:14] <ademan> well i posted in the mailing list, now i play the waiting game
[08:15] <elkbuntu> hehehe
[08:16] <crimsun> superm1: in about 20 minutes, hopefully
[08:16] <superm1> okay sounds good
[08:22] <ajmitch> dholbach!
[08:22] <dholbach> Andrew!
[08:22] <ajmitch> how are you?
[08:23] <dholbach> fine thanks - just waking up
[08:23] <dholbach> how are you?
[08:24] <ajmitch> good :)
[08:39] <crimsun> superm1: sorry, still on the phone (shouldn't be -too- much longer, but I never know)
[08:39] <superm1> hehe okay
[08:39] <dholbach> heya proppy
[08:41] <tsmithe> ping crimsun
[08:45] <tsmithe> ah well
[09:23] <crimsun> superm1: is the non-native-version-but-lacking-orig.tar.gz intentional
[09:24] <superm1> well i got a bit confused how to version this
[09:24] <superm1> so if it should be versioned the way i did it, yes
[09:24] <superm1> should it have been 20061007ubuntu1 instead?
[09:25] <crimsun> do you plan to submit the source package to Debian?
[09:25] <superm1> well not in the near future
[09:26] <crimsun> how often is(are) the firmware(s) updated?
[09:26] <superm1> but i had assummed if it ever would be submitted to debian, there had to be a way to differentiate between the upstream, debian, and our versions
[09:26] <superm1> every few months
[09:26] <crimsun> I would probably use 0.20061007, then.
[09:26] <crimsun> thus making it a native package
[09:27] <superm1> so then would it be 0.20061007ubuntu1?
[09:27] <superm1> or just 0.20061007
[09:27] <crimsun> I would just use 0.20061007 for now
[09:27] <superm1> okay. i'll update that then
[09:28] <crimsun> well, let's rethink
[09:28] <crimsun> you'll run into some nasty situations with Debian NMUs
[09:28] <crimsun> unfortunately that's unavoidable
[09:28] <crimsun> so you can either use the pseudo-epoch (0.date), or use 0.1, 0.2, 0.3, etc.
[09:29] <crimsun> depends how strongly [and immediately obvious]  you want to tie the version to the firmware date
[09:29] <superm1> well i think pseudo-epoch makes more sense
[09:29] <superm1> at least to me
[09:29] <superm1> well firmware date is the easiest to go by
[09:29] <superm1> thats what ivtvdriver.org goes by instead of versions
[09:30] <superm1> their last release prior to this was in july, so it was something along the lines of 20060701
[09:31] <superm1> and this way if someone else was to ever look at the package, it's immediately obvious that there is a new version available without having to match a date to a decoder for versions
[09:34] <crimsun> ok, that part sounds fine. Do you intend it to be native to Ubuntu/Debian, then?
[09:34] <superm1> yes
[09:36] <sivang> morning
[09:37] <ajmitch> morning sivang
[09:41] <crimsun> superm1: is it possible to include the contents of the license "allowing end users to download the firmware from dl.ivtvdriver.org and use on their local machines" in debian/copyright ?
[09:42] <superm1> I'll have to see if Axel can get me a copy.
[09:42] <superm1> he only mentioned it in emails
[09:43] <crimsun> ok, that's possibly a blocker.
[09:43] <superm1> he was a liaison for the community for hauppauge for a bit, and obtained the license allowing him to host firmware on his site for end users.
[09:44] <superm1> *well particularly to host the firmware in extracted form in a .tar.gz archive
[09:45] <crimsun> the /usr/lib/firmware -> /lib/firmware symlink business is a bit dirty, too
[09:45] <superm1> ok i can just throw them right in /lib/firmware
[09:45] <superm1> when your saying obtain, i'm not sure exactly what he'll be able to provide - because for all i know it might just be emails back and forth with Hauppauge HR that allowed him to do this, or it might have only been verbally agreed on
[09:46] <crimsun> quoted e-mail with his permission would suffice, but even better would be a publicly-accessible statement on his Web site
[09:47] <crimsun> Otherwise, looks good. Thanks for working on this source package!
[09:47] <superm1> with "his" permission?  Let me check the exact wording of our contact.  I belive i do have "his" permission
[09:47] <crimsun> it's always better to ask [to receive explicit permission]
[09:49] <superm1> On Mon, Nov 06, 2006 at 12:31:02PM -0600, Mario Limonciello wrote:
[09:49] <superm1> > The firmware itself wouldn't have been hosted on the Ubuntu servers.  Just a
[09:49] <superm1> > small package (<30k) that would contain a preinstall script.  When this
[09:49] <superm1> > package was installed, the "end user's machine" would then grab the firmware
[09:49] <superm1> > from your server, possibly display some licensing info about the license
[09:49] <superm1> > that you have for hosting the files, and then place them in the correct
[09:49] <superm1> > place on the users machine.  So in short, the firmware itself wouldn't ever
[09:49] <superm1> > touch ubuntu servers.
[09:49] <superm1> That would be no legal issue at all I think (but IANAL still
[09:49] <superm1> applies). There is also a way to use the redistributable Windows
[09:49] <superm1> driver and extract the firmware from there on the fly. Perhaps that's
[09:49] <superm1> the legally cleanest approach currently. If you're interested I'll dig
[09:49] <superm1> out my notes on how to extract the firmware.
[09:49] <superm1> that is a small snippet from some conversation, i'm not sure if that would suffice
[09:54] <crimsun> not really, no
[09:55] <superm1> Ok.  I'll send him a note and see if he can add a bit about licensing on his site
[09:55] <crimsun> it needs to be clear from either upstream's license or from his e-mail(s) that he has been given explicit permission to host them, and that third parties have upstream's consent to download from his site
[09:56] <crimsun> thanks.
[09:56] <superm1> In the meanwhile - if this doesnt work out for some reason or another, can the fallback be to extract from the windows driver on the fly
[09:57] <superm1> eg download the windows driver during install and extract from that.  it for sure does have redistribution rights
[09:59] <superm1> (and before axel had this license with hauppauge straightened out, that was the only way to get this firmware)
[09:59] <crimsun> I don't see any reason why not.
[10:00] <superm1> Ok.  i'll see what axel says about getting the license right on his website then.
[10:01] <superm1> so other question though - something like pcHDTV also has firmware, and I was going to do a very similar package for it.  but again there is no license on the site directly, so I would have to email them to find out about how they feel about redistribution as well correct?
[10:03] <crimsun> superm1: yes, explicit permission is best
[10:03] <superm1> okay then.  i'll send this out and get to bed then.  thanks for all the help here crimsun.
[10:05] <crimsun> np
[10:29] <Adri2000> freeflying: ping
[10:33] <freeflying> Adri2000: pong?
[10:33] <Adri2000> freeflying: bug 74272
[10:33] <Ubugtu> Malone bug 74272 in quarry "Quarry is available in Debian" [Undecided,Unconfirmed]  http://launchpad.net/bugs/74272
[10:34] <Adri2000> are you ok to request a sync?
[10:34] <freeflying> Adri2000: I have uploaded it, so needn't sync
[10:35] <freeflying> Adri2000: would you mind close it?  :)
[10:35] <Adri2000> freeflying: uploaded the new upstream release or the debian package?
[10:37] <freeflying> Adri2000: have we synced? if not, please use the one I uploaded
[10:38] <Adri2000> freeflying: I don't know what you uploaded
[10:38] <Adri2000> currently it's still:
[10:38] <freeflying> Adri2000: 0.1.20-0ubuntu1
[10:38] <Adri2000> quarry | 0.1.19-0ubuntu1 | http://archive.ubuntu.com feisty/universe Sources
[10:39] <Adri2000> freeflying: 0.2.0 is available
[10:39] <freeflying> Adri2000: then please sync it
[10:39] <freeflying> Adri2000: thanks
[10:40] <Adri2000> ok, I will do that
[11:08] <wsb> I'd like to submit a citrix ica client package to the multiverse repository, is it possible, or do there are some licence issues ?
[11:09] <crimsun> there shouldn't be if it's to go into multiverse.
[11:10] <crimsun> as long as its license allows us to redistribute it, it should be fine.
[11:11] <wsb> I haven't found anything about submiting to multiverse, do I need to submit to universe, or is there another way ?
[11:13] <crimsun> you don't submit to a particular component; the archive admins handle that based on the licenses in the source package.
[11:13] <crimsun> you follow precisely the identical procedure regardless of component
[11:13] <wsb> ok fine
[11:14] <wsb> other small question, on the install script from the source, the user have to accept the EULA, to I need to make something similar in the package (in debconf... or postinst) ?
[11:15] <crimsun> ouch, EULA acceptance
[11:15] <crimsun> well, yes.
[11:15] <crimsun> a debconf template is one of the easier ways
[11:16] <wsb> ok, any idea where I can find an exemple or tutorial ?
[11:16] <crimsun> sure, flashplugin-nonfree
[11:16] <crimsun> beware it defaults to -accepting- the eula, however.
[11:17] <crimsun> obviously that's a trivial change
[11:22] <wsb> I'll need to make some homework ;) , one trivial question, how can I decompress a deb with the DEBIAN directory ?
[11:24] <crimsun> more context, please?
[11:25] <wsb> I've downloaded the flashplugin deb, I know how to decompress the files and see the control file with dpkg-deb, but not how to have the whole DEBIAN directory
[11:25] <wsb> with postinst and so on in it...
[11:26] <Adri2000> wsb: apt-get source flashplugin-nonfree
[11:27] <Lathiat> or if you wanted it out of the binary package
[11:27] <Lathiat> ar x <deb file>
[11:27] <Lathiat> tar zxvf control.tar.gz
[11:27] <Lathiat> less postinst
[11:27] <Lathiat> note thatl dump files in the current directory so do it from a temporary directory :)
[11:41] <ajmitch> hi \sh
[11:41] <\sh> moins
[11:43] <wsb> sorry about asking so many questions... can somebody explane me in a few word how debconf works, or were I can find a small tutorial, I've googled, but could not find anything
[11:45] <mnepton> wsb: "gray magicks from before the dawn of recorded history"
[11:47] <wsb> sorry but this sentence is like japanese for me !
[11:50] <mnepton> wsb: there is no brief description of debconf.
[11:51] <crimsun> wsb: try http://kitenet.net/~joey/talks/debconf-debconf/tutorial-doc.html
[11:51] <wsb> I've downloaded the flashplugin-nonfree package to see how it is made, but I don't understand were the reference to debconf is...
[11:52] <wsb> I'll try thanks
[11:52] <crimsun> once you read the tutorial above, you'll see.
[11:54] <wsb> great tutorial, thank you, will help me a lot !
[01:50] <xerxas> I'm trying to merge a package
[01:51] <xerxas> I need this file: /usr/share/gnome-pkg-tools/1/rules/uploaders.mk
[01:51] <xerxas> does anybody know where I can find it ?
[01:51] <xerxas> apt-file search doesn't give nothing
[01:51] <Hobbsee> in gnome-pkg-tools i expect
[01:51] <xerxas> ok
[01:52] <xerxas> Hobbsee,  thanks
[02:07] <crimsun> ogra: I see that LP bug (silent drop) approximately once per fifty uploads.
[02:07] <Sp4rKy> hi there
[02:08] <ogra> crimsun, bah, that needs fixage
[02:09] <crimsun> yeah, it's kinda annoying. I got into the habit of queueing my uploads so they'd upload right around :04, :09, etc.
[02:11] <xerxas> Hobbsee,  I have merged gnome-backgrounds what should I do to "upload" it ?
[02:12] <geser> first test that it still builds
[02:13] <geser> then create a debdiff, file a bug, attach debdiff, subscribe ubuntu-universe-sponsors and wait
[02:14] <xerxas> geser,  ok , thanks, you already told me that on friday, sorry ! :)
[02:16] <crimsun> and if you do it quickly enough, you can skip the waiting when you tell me what bug # it is immediately after filing it
[02:18] <xerxas> crimsun,  ok
[02:18] <xerxas> thanks
[02:19] <xerxas> what should I tell the debdiff to diff ?
[02:19] <xerxas> previous vs new ubuntu version ?
[02:19] <geser> debdiff debian_version.dsc merged_version.dsc > debdiff
[02:19] <xerxas> ok
[02:19] <xerxas> thanks
[02:20] <Hobbsee> er, why the debian version?
[02:21] <Hobbsee> guess you should do both, really
[02:22] <xerxas> $ ls *dsc
[02:22] <xerxas> gnome-backgrounds_2.15.92-1.dsc        gnome-backgrounds_2.16.1-1.dsc
[02:22] <xerxas> gnome-backgrounds_2.16.1-0ubuntu1.dsc  gnome-backgrounds_2.16.1-1ubuntu1.dsc
[02:22] <xerxas> so I should debidff gnome-backgrounds_2.16.1-1.dsc gnome-backgrounds_2.16.1-1ubuntu1.dsc
[02:22] <xerxas> ?
[02:22] <geser> yes
[02:22] <crimsun> doesn't ultimately matter as long as the diff context is clear
[02:22] <crimsun> u-u-s is capable of processing either way :)
[02:23] <crimsun> I think I should pass the u-u-s processing baton to Hobbsee :)
[02:24] <Hobbsee> crimsun: nah, keep it :)
[02:24] <crimsun> bah
[02:24] <Hobbsee> crimsun: i got rid of some yesterday though :)
[02:24] <crimsun> yep, I saw. Thanks! :)
[02:25] <Hobbsee> :)
[02:25] <geser> Hobbsee: IMHO a debdiff against the debian version is easier to check than against the last ubuntu version
[02:25] <xerxas> u-u-s ?
[02:25] <Hobbsee> true
[02:25] <geser> you don't have all the debian changes and upstream changes
[02:26] <geser> xerxas: u-u-s = ubuntu-universe-sponsors
[02:26] <xerxas> ok
[02:28] <xerxas> geser,  the bug should be called: "please sync gnome-backgrounds" ?
[02:29] <xerxas> [debdiff attached]  ?
[02:29] <xerxas> or anything else ?
[02:29] <geser> it's up to you, I usally use "[Merge]  packagename version"
[02:29] <xerxas> ok
[02:29] <xerxas> thanks
[02:30] <crimsun> yes, please use [merge]
[02:30] <crimsun> I filter based on [sync]  vs. [merge] ; the former gets processed faster
[02:32] <xerxas> crimsun,  k
[02:35] <xerxas> crimsun,  https://bugs.launchpad.net/distros/ubuntu/+source/gnome-backgrounds/+bug/74378
[02:35] <Ubugtu> Malone bug 74378 in gnome-backgrounds "[merge]  gnome-backgrounds 2.16.1-1" [Undecided,Unconfirmed]
[02:35] <xerxas> could you check everything is ok ?
[02:35] <geser> xerxas: you forgot to update debian/changelog
[02:36] <xerxas> geser:
[02:36] <xerxas> gnome-backgrounds (2.16.1-1ubuntu1) feisty; urgency=low
[02:36] <xerxas>   * Merge from debian unstable.
[02:36] <xerxas>  -- Ubuntu Merge-o-Matic<EMAIL_ADDRESS>Mon, 30 Oct 2006 14:17:41 +0000
[02:36] <xerxas> isn't this enough ?
[02:36] <Hobbsee> no
[02:36] <Hobbsee> you have to list the ubuntu changes kept
[02:36] <Hobbsee> and you're nto mom
[02:37] <crimsun> also, be careful about the debian/control.in* changes
[02:37] <crimsun> and debian/compat
[02:38] <xerxas> I think there's no changed kepts
[02:38] <xerxas> I need to put in my e-mail address ?
[02:38] <geser> if there are no ubuntu changes than the package should be synced instead of merged
[02:41] <xerxas> lol , ok
[02:41] <xerxas> so how do I request a sync ?
[02:44] <geser> https://wiki.ubuntu.com/DeveloperResources section "Syncs"
[02:45] <geser> but subscribe ubuntu-universe-sponsors instead of ubuntu-archive until you are a MOTU
[02:45] <geser> you need an ACK from a MOTU
[02:52] <gnomefreak> was ff2.0 backported or shoved into -proposed for dapper?
[02:57] <crimsun> gnomefreak: not according to http://archive.ubuntu.com/ubuntu/dists/dapper-proposed/main/source/Sources.gz or http://archive.ubuntu.com/ubuntu/dists/dapper-backports/main/source/Sources.gz
[02:58] <gnomefreak> i was just looking on p.u.c but they dont list proposed thank you
[03:51] <bddebian> Heya gang
[03:55] <crimsun> 'morning
[03:55] <bddebian> crimsun: Hi
[04:13] <sivang> hey crimsun , bddebian
[04:13] <crimsun> 'lo sivang
[04:14] <bddebian> Heya sivang
[04:40] <crimsun> sivang: RE: your latest blog, note that -lowlatency does not have CONFIG_PREEMPT enabled, which _may_ affect your symptoms.
[04:41] <crimsun> sivang: (it was overlooked and has been corrected in feisty's git)
[04:44] <sivang> crimsun: uh-ha! interesting :)
[04:44] <sivang> crimsun: do you think it could have any good effects once its enabled ?
[04:45] <sivang> crimsun: I can't really go to IBM's repair service as they will test in in windows,
[04:45] <crimsun> sivang: possibly. I honestly can't pinpoint right this moment whether it's an X driver issue, a kernel issue, or something else.
[04:45] <sivang> crimsun: and there it mostly works (although the best I did there was to dir /s on a root drive)
[04:46] <sivang> crimsun: I just can't accept that everytime my disk IO jumps high, my mouse will stop working.
[04:47] <sivang> crimsun: I was never willing to accept something like this from a linux based OS, I wish I had enough disk space to try this with debian.
[04:47] <sivang> crimsun: thanks for your note though ;)
[06:11] <xerxas> crimsun, you here ?
[06:43] <stgraber> Any MOTU around to have a look at my upload on review ?
[07:29] <elektranox> can sb. review my small package? :P
[07:29] <dholbach> elektranox: I'm busy doing something else atm, but if you like drop me a mail with the link to<EMAIL_ADDRESS>and I'll get back to you once I solved some other 'small' problems
[07:30] <elektranox> dholbach: ok, thx :)
[07:39] <dholbach> elektranox: got your mail - thanks a lot
[07:43] <elektranox> dholbach: k, thanks for reviewing :)
[07:47] <Sp4rKy> joejaxx: ping
[08:12] <tsmithe> hiho: anyone wanna review the latest incarnation of asoundconf-gtk?
[08:13] <joejaxx> Sp4rKy: ?
[08:13] <tsmithe> but if anyone could that would be great!
[08:13] <tsmithe> http://revu.tauware.de/details.py?upid=3669
[08:13] <tsmithe> thanks in advance ;)
[08:16] <Sp4rKy> joejaxx: do you have some time to "review" entrance packge ?
[08:17] <joejaxx> Sp4rKy: i am not actually motu yet
[08:17] <Sp4rKy> joejaxx: np, entrance isn't on REVU, is for Elbuntu project :)
[08:18] <joejaxx> Sp4rKy: ah
[08:18] <joejaxx> sure
[08:19] <LaserJock> Sp4rKy: Elbuntu, is that what they're calling it now?
[08:20] <joejaxx> Sp4rKy: how do you want to go about doing that?
[08:20] <tsmithe> what's elbuntu?
[08:20] <Lutin> LaserJock: yes
[08:21] <Sp4rKy> tsmithe: Enlightenemnt based Ubuntu distro
[08:21] <Sp4rKy>  /j #elbuntu for more information :)
[08:21] <tsmithe> ah, thanks Sp4rKy
[08:21] <Sp4rKy> LaserJock: yes
[08:21] <Sp4rKy> it's the "old" Ebuntu
[08:26] <crimsun> Sp4rKy: why wouldn't you want entrance on revu?
[08:26] <Sp4rKy> crimsun: it's always the same problem
[08:26] <Sp4rKy> it's a part of the E17 project
[08:26] <Lutin> crimsun: because all the lib it relies on are not in revu, and won't be for awhile
[08:26] <crimsun> but why is revu the blocker?
[08:26] <Sp4rKy> and the main dev of E17 (raster) doesn't want we put any part of E17 in official repository :)
[08:27] <Lutin> crimsun: revu is not the blocker. raster is, as Sp4rKy said (and i can understand that)
[08:27] <crimsun> revu's not an official repository, so I see no reason why the source packages shouldn't go onto revu
[08:27] <tsmithe> hi crimsun
[08:27] <tsmithe> could you take another look at asoundconf-gtk?
[08:28] <crimsun> tsmithe: tomorrow, yes. I haven't slept in three days, so I'm not going to do any more reviewing.
[08:28] <tsmithe> ok
[08:28] <tsmithe> cool
[08:28] <tsmithe> that's a long time :)
[08:28] <dholbach> crimsun: :-(
[08:28] <Lutin> crimsun: the goal of revu is to put the packages in ubuntu, right ?
[08:29] <crimsun> Lutin: yes, but it's more importantly a place to have peer review of packaging.
[08:30] <tsmithe> keep them oiled and in good working order
[08:30] <tsmithe> and nice looking ;)
[08:30] <Lutin> crimsun: the point is, we can't put packages in revu just to have them reviwed
[08:30] <crimsun> but you can in some other repo?
[08:30] <crimsun> that sounds shady.
[08:31] <crimsun> and I don't buy it at all.
[08:31] <Lutin> crimsun: not sure I understood what you mean
[08:32] <crimsun> Lutin: my question regards why revu can't be used for review. That's its primary purpose.
[08:33] <crimsun> there's no binary repo associated with revu; people can't add deb lines to sources.list(5)
[08:33] <LaserJock> in other words, REVU can be used for any reviewing
[08:34] <Sp4rKy> LaserJock: crimsun yes of course
[08:34] <Sp4rKy> but package putted at revu.tauware.de will be uploaded in universe after 2 validation, right ?
[08:34] <crimsun> it's never automatic
[08:34] <Sp4rKy> but indeed, we may use our own revu platform
[08:35] <crimsun> a member of ubuntu-dev must manually upload the source package to ubuntu
[08:35] <Sp4rKy> crimsun: i think motu have a lot of work
[08:35] <LaserJock> what we're saying is you can use REVU
[08:35] <Sp4rKy> yes, we'll do
[08:36] <Sp4rKy> but on our own server
[08:36] <LaserJock> why not use ours?
[08:36] <Sp4rKy> because we've many & many packages
[08:36] <LaserJock> if you've already got accounts it seems logical
[08:36] <LaserJock> we already have 140+
[08:36] <Sp4rKy> we have smthg like 190 packages !
[08:36] <Sp4rKy> (deb packages)
[08:37] <Sp4rKy> we've account :)
[08:37] <crimsun> it's not the number of packages that matters; it's the quality.
[08:37] <Sp4rKy> crimsun: of course
[08:38] <Sp4rKy> but we don't want overload revu with 150+ packages which don't go to universe
[08:38] <crimsun> anyhow, revu's there; I'd use it, but of course you're free to choose your own approach
[08:38] <Sp4rKy> crimsun: i really think revu is a very good tool
[08:39] <Sp4rKy> and we probably try to use it at our server
[08:39] <Sp4rKy> do you really think we can upload our packages to revu.tauware , and spend MOTU time with them ?
[08:40] <LaserJock> 190 NEW packages for E17?
[08:40] <LaserJock> I thought it was more like 20 or so
[08:40] <Sp4rKy> nop
[08:40] <crimsun> Sp4rKy: do you hope to get any sort of peer review by MOTU (or DD/NM)?
[08:40] <ajmitch> maybe 190 binary packages
[08:40] <Sp4rKy> there isn't 190 source pkge
[08:41] <Sp4rKy> but 190 deb pkge
[08:41] <LaserJock> oh
[08:41] <Lutin> LaserJock: about 20 source pkge for e17 + some stuff around
[08:41] <ajmitch> still a lot
[08:41] <Sp4rKy> 26 source pkge for i386 arch :)
[08:41] <Lutin> LaserJock: but the core libs and E itself are only 6-7 source pkgefs
[08:41] <Sp4rKy> sorry for misunderstanding :p
[08:42] <Adri2000> crimsun: haven't yet reached my email for the oo2c sync? :)
[08:42] <Sp4rKy> crimsun: we like , but i think motu have already a lot of work
[08:43] <Lutin> crimsun: yes, we'll get any sort of peer review by MOTU (or DD/NM)
[08:43] <Sp4rKy> if we can, we'll help you, and so maybe we could put our package to tauware
[08:44] <crimsun> I'll get to it tomorrow. I'm a bit tired atm.
[08:44] <Lutin> crimsun: if I understood you correctly, you're saying that we can put our packages on revu, and even if they're advocated, say 'no, we don't want that to be in universe" ?
[08:44] <crimsun> ^ Adri2000
[08:44] <Adri2000> crimsun: ok, np :)
[08:45] <crimsun> Lutin: sure. I'm fairly sure no one in ubuntu-dev is going to be uploading E17 packages to Ubuntu.
[08:46] <Sp4rKy> crimsun: if it's really no a problem for you (motus) , we're really happy to get this help !
[08:46] <Lutin> crimsun: hum ... I'm going to think seriously about that, if I can be sure nobody will upload it (if it gets advocated)
[08:46] <Sp4rKy> and of course, make our best to become MOTU too and work you :)
[08:46] <crimsun> Lutin: I'm pretty sure none of us are going to advocate them, either.
[08:46] <Sp4rKy> isn't it Lutin ?
[08:47] <Lutin> Sp4rKy: lol
[08:47] <Sp4rKy> :)
[08:47] <Lutin> crimsun: ok
[08:50] <Lutin> crimsun: because of its devel state ?
[08:50] <crimsun> yes
[08:50] <Lutin> ok
[08:51] <Sp4rKy> crimsun: don't you think motus have enough work without those packages ?
[08:51] <crimsun> Sp4rKy: absolutely, the MOTU have tons of work already.
[08:53] <Sp4rKy> so if at this time we can do without overload tauware, but just with some dev/packagers/motu who help us, it's better, don't you think ?
[08:53] <crimsun> if you can't convince MOTU to go to revu, what makes you think they'll go to yet another site?
[08:54] <Sp4rKy> crimsun: we don't convince
[08:54] <Sp4rKy> people who are interested by our project (E17 repo + elbuntu) come with us
[08:55] <Sp4rKy> and so we ask them for help
[08:56] <Sp4rKy> crimsun: all our packages which are in the repo work, but they are probably not all completly compliant woth debian policy & ubuntu packaging way
[08:56] <crimsun> that should be your foremost goal as package maintainers
[08:56] <Sp4rKy> and, as we want make our package as good as possible, we need some help for some package :)
[08:56] <Sp4rKy> crimsun: is it
[08:57] <Sp4rKy> but i/we can't say we're sure than all our package are completly compliant
[08:58] <Lutin> I can say I'm sure they're not ^^
[08:58] <Sp4rKy> :)
[08:59] <Lutin> almost though
[09:09] <tsmithe> !seen somerville32
[09:09] <ubotu> I last saw somerville32<EMAIL_ADDRESS>21h 13m 52s ago, quiting: "Leaving"
[09:21] <tsmithe> crimsun, you still around! you really should go to bed!
[10:19] <limpbizcuit> hello
[10:24] <tsmithe> hi
[10:41] <Adri2000> Fujitsu: you are probably sleeping, but... ping? :)
[10:46] <Sp4rKy> ^^
[10:59] <tsmithe> ah... much better!
[11:39] <superm1> if debian is lagging behind on a package that we normally would autosync from them on, and say I updated the package for the newer version, could I just attach a debdiff to a bug and have a MOTU ack it?
[11:40] <Sp4rKy> 'd night
[11:41] <LaserJock> superm1: give a specific example
[11:41] <LaserJock> as I think you have one in mind ;-)
[11:41] <superm1> hehe, well ivtv 0.9 is needed for 2.6.19 kernels
[11:41] <superm1> i already wrote a package for it
[11:42] <superm1> and i'm keeping it under lock and key at http://dl.ivtvdriver.org/ubuntu/dists/feisty/ivtv/
[11:42] <LaserJock> ok, and what is the debian version?
[11:43] <superm1> 0.8.1-2
[11:43] <superm1> which will only work on 2.6.18 kernels
[11:43] <LaserJock> ok, well I think as long as you start from the debian package and just update it to 0.9
[11:43] <LaserJock> just call it 0.9-0ubuntu1
[11:44] <superm1> yea thats exactly what i did, except that i called it 0.9-0ubuntu0ivtv1 for now since its sitting on the ivtv driver website
[11:44] <superm1> so just change it to match us and then post to a bug
[11:45] <LaserJock> do you know how big the diff between 0.8 and 0.9 is?
[11:45] <superm1> i didn't have to change any packaging actually.  it all just worked using the newer upstream version
[11:46] <LaserJock> yeah, but how big is the diff in the upstream version?
[11:46] <superm1> oh i haven't done a diff on that yet
[11:46] <superm1> give me a sec and i'll grab both and do it
[11:48] <tsmithe> hi CarlF1
[11:48] <superm1> about 15K difference it looks like
[11:48] <tsmithe> urgh
[11:48] <CarlF1> FK! not f1... grrr
[11:48] <CarlF1> hi tsmithe
[11:49] <LaserJock> superm1: ok, throw it into a bug report, but just make sure to say what you're doing
[11:49] <LaserJock> CarlF1: is that how you ask for help? :-)
[11:49] <superm1> which needs to be attached exactly, just the diff between upstream versions and the new diff.gz, dsc?
[11:50] <LaserJock> just debdiff between the current fiesty version and yours
[11:50] <superm1> k
[11:50] <LaserJock> and say that that's what you did
[11:50] <LaserJock> so we don't try to apply the debdiff to the Debian package
[11:50] <superm1> k
[11:51] <superm1> anyone particularly to subscribe?
[11:52] <Adri2000> ubuntu-universe-sponsors
[11:52] <superm1> k
[11:52] <rmjb> Hey LaserJock
[11:52] <LaserJock> hi rmjb
[11:52] <rmjb> I saw that the packaging guide got some more content since I read it
[11:53] <rmjb> has that update made to lulu yet?
[11:53] <LaserJock> probably not
[11:53] <LaserJock> I think we are most likely going to drop lulu
[11:53] <LaserJock> or perhaps just update when it's changed significantly
[11:54] <LaserJock> making good looking pdfs for print is really hard
[11:54] <rmjb> hmm... got some money for Christmas so I was going to buy myself a present of an Ubuntu Packaging Guide!
[11:54] <LaserJock> you could do that
[11:54] <LaserJock> or you could get the latest PDF and have a printshop print it out
[11:54] <rmjb> I'd want to get the most complete version I can though
[11:54] <rmjb> ah, that might be a solution
[11:55] <LaserJock> well, we'll see
[11:55] <rmjb> there's pdfs on doc.ubuntu.com?
[11:55] <LaserJock> yeah
[11:55] <LaserJock> well, help.ubuntu.com
[11:55] <LaserJock> doc. probably doesn't
[11:55] <rmjb> how often is help updated with the content from doc?
[11:55] <LaserJock> when it's released
[11:56] <LaserJock> so help.u.c has the breezy, dapper, and edgy docs
[11:56] <rmjb> ok
[11:56] <rmjb> I'll check it and see
[11:56] <LaserJock> doc.u.c is just built from our svn repo
[11:56] <rmjb> thanks
[11:57] <rmjb> the section on patching was added for edgy right?
[11:57] <rmjb> I'm trying to see what it is I missed
[11:58] <rmjb> it looks so
[11:58] <LaserJock> yeah
[11:58] <LaserJock> I haven't really done much of anything for Feisty yet
[12:02] <rmjb> hmm... pdf is black and white...
[12:02] <rmjb> is there a colour version available? with the slick cover that's on lulu?
[12:03] <LaserJock> I don't think so
[12:04] <LaserJock> you might be able to email he -doc list and convince somebody to make one :-)
[12:12] <tsmithe> hi hobbsee: you're a good revu critic... could you do mine?
[12:12] <Hobbsee> tsmithe: no, sorry - i'm catching a plane today
[12:12] <tsmithe> cool


[02:21] <tomreyn> So apparently there are no kernels nor initrd's on the live cds according to bug 1860495
[03:23] <lotuspsychje> good morning
[03:37] <peepsalot> I'm curious about how bug fixes are handled in older LTS releases such as 16.04, when the packages they use are considered not supported by their maintainers?  (for example Qt which seems to have a very aggressive end of support schedule https://en.wikipedia.org/wiki/Qt_version_history#Qt_5 )
[04:08] <lotuspsychje> !info software-properties-gtk eoan
[04:53] <guiverc> peepsalot, your question about fixes in older LTS releases will likely vary on packages; most of 16.04 LTS packages found in universe are no longer supported; so don't get fixes (eg. Kubuntu 16.04 LTS had 3 years of support as it was a flavor, it's eol like mate, lubuntu, xubuntu etc...)
[04:54] <guiverc> peepsalot, for 'main' packages, the fixes are backported to the package already in the older release; unless it's more work to backport than provide newer version...
[04:57] <peepsalot> guiverc: i'm specifically concerned about this issue: https://bugreports.qt.io/browse/QTBUG-55245#  kinda wondering if there's any chance it would get fixed in Qt 5.5.1 which is used by 16.04
[04:58] <peepsalot> or if I would have any better luck reporting through ubuntu than Qt directly?
[04:58] <guiverc> Kubuntu 16.04 LTS is EOL & thus doesn't get support; as I recall a single package was fixed post-EOL date (by a few days); but it was an exception.
[05:00] <guiverc> Kubuntu 16.04 LTS was released on 21st April 2016, and was supported for Kubuntu for a period of year 3 years.* Kubuntu 16.04 LTS support therefore ends 21st April 2019  https://kubuntu.org/news/trusty-14-04-lts-end-of-life-and-end-of-kubuntu-support-for-xenial-16-04-lts/
[05:00] <guiverc> I'm not aware of any Qt packages for 16.04 in 'main' (thus with 5 years of support)
[05:00] <peepsalot> guiverc: but qt5-default is part of xenial main as far as I understand, not just Kubuntu, and its supposed to be supported until Apr 2021?
[05:01] <guiverc> https://packages.ubuntu.com/xenial/qt5-default == universe
[05:01] <peepsalot> oh, oops
[05:02] <guiverc> if it's on your system, use `ubuntu-support-status` to inspect for packages installed on your system
[05:03] <peepsalot> i'm on mint 19.2, which is 18.04 based.  i'm just concerned because I work on a project which supports Ubuntu 16.04, and would really like that bug fix
[05:04] <peepsalot> hell, i'd really like it for 18.04 too, which isn't even out of support for Qt yet
[05:04] <peepsalot> Qt 5.9.5
[05:12] <peepsalot> guiverc: do you know what is policy for updating packages in universe then?  is there any chance it could be fixed for Qt 5.9.5, backported by ubuntu or something?
[05:13] <peepsalot> looks like ubuntu-support-status is part of update-manager-core package, not sure if installing that will interfere with default mint updater though, so not too keen on testing it
[05:19] <guiverc> I can't help with mint; I have no idea.
[05:24] <lotuspsychje> peepsalot: you should mention you are using mint at the beginning of your questions
[05:24] <lotuspsychje> peepsalot: mint has another support channel/server
[05:25] <peepsalot> i contribute to an open source packaage that supports ubuntu 16.04.  this isn't specifically about what my system is running
[05:25] <lotuspsychje> peepsalot: discussing here is allowed for everyone of course, but details 'can' matter when asking questions so volunteers can aid better
[05:26] <peepsalot> our CI servers run Ubuntu 16.04 and 18.04, among other OS
[05:26] <lotuspsychje> cool
[07:17] <ducasse> good morning
[07:25] <lordievader> Good morning
[12:32] <tomreyn> i spent 30 minutes yesterday ebcause i didn't remember what is the exact kernel command line option to boot into non-graphical multi-user mode. i was certain it'd start with either "systemd.target", "systemd-target", "x-systemd.target" or "x-systemd-target", and would be followed by one of "multi-user" or "multi-user.target"
[12:32] <tomreyn> turns out it is actually "systemd.unit=multi-user.target" :-/ we might want a factoid for this
[12:33] <lotuspsychje> !systemd
[12:33] <tomreyn> i haven't found the kernel parameters to be documented anywhere
[12:34] <tomreyn> or initrd parameters rather
[12:35] <lotuspsychje> tomreyn: alinea Adjusting the System State (Runlevel) with Targets is related?
[12:36] <tomreyn> lotuspsychje: where do you see this?
[12:36] <lotuspsychje> the digitalocean one
[12:38] <tomreyn> well, it explains targets in systemd, but not how to boot to them overriding the default target by using kernel command line parameters
[12:38] <lotuspsychje> ah
[12:38] <lotuspsychje> !kernelparm
[12:39] <tomreyn> we should have a list or explain how to get a list of initrd supported kernel command line parameters
[12:40] <tomreyn> having it is more user friendly - until it gets outdated.
[12:41]  * pragmaticenigma is obsolete :-P
[12:47] <tomreyn> aaaah crap there is actually kernel-command-line(7)
[12:48] <lotuspsychje> where did you find tomreyn
[12:49] <tomreyn> i knew about bootparm(7) which doesn't discuss this, and while searchign the web for it stumbled into http://man7.org/linux/man-pages/man7/bootparam.7.html where, on the footer, it says:   Pages that refer to this page: reboot(2),  boot(7),  kernel-command-line(7)
[12:50] <tomreyn> so we should mention bootparm(7) and kernel-command-line(7) on https://wiki.ubuntu.com/Kernel/KernelBootParameters
[12:50] <lotuspsychje> i know someone that likes editing wiki's :p
[12:50] <tomreyn> i don't
[12:50] <lotuspsychje> me neither :p
[13:02] <tomreyn> okay, done
[14:35] <pragmaticenigma> leftyfb: -X always results in an error message being displayed... -Y doesn't... that's why I use -Y... I've not looked in to -G before and I don't know what it does and I don't setup my SSH clients to automatically any forwarding
[14:38] <pragmaticenigma> leftyfb: Also, -X is mapped to forwardx11, -Y is mapped to fowardx11trusted
[14:38] <pragmaticenigma> so I'm not understanding your point
[18:27] <sarnold> pragmaticenigma: I'm pretty sure debian and ubuntu -X and -Y mean the same thing https://sources.debian.org/src/openssh/1:8.1p1-5/debian/patches/debian-config.patch/?hl=47#L47
[18:42] <dps> :wave:
[18:42] <dps> afternoon everyon!
[18:42] <dps> everyone*
[18:45] <sarnold> hey dps
[18:45] <pragmaticenigma> sarnold: Yeah, I tried it and found that is the case from debian to debian system. With cygwin, it always throws a warning message if I try to use -X... that was the basis of my original thought pattern
[18:45] <pragmaticenigma> It would appear in debian, -X and -Y might be interchangable then?
[18:57] <dps> this may be a dumb question, but isnt it a bit unsafe for my IP address to be shown to everyone when i join a channel? lol
[18:58] <sarnold> dps: you can connect via Tor if you wish to hide it
[18:59] <pragmaticenigma> dps: You can also ask in #freenode for a "cloak"
[18:59] <dps> yeah, i guess i could. im just wondering exactly what someone could do with that info. Maybe try gaining access to my rig you think?
[18:59] <dps> oh ok, thanks! ill look into that
[19:00] <pragmaticenigma> dps: If you're on a dynamically changing IP the risk is lower. If someone was actively trying to target you for something, that would be the only risk.
[19:00] <pragmaticenigma> Personally I did it because I tansfer between a few locations, and I didn't like that those IPs don't change often enough, such that if someone were to be paying attention, they could determine if I were home or not
[19:01] <pragmaticenigma> but the reality is, you're more likely to get targetted by someone doing a full sweep of the IPv4 address space, then someone from here.
[19:02] <sarnold> dps: if your firewall is so poorly configured and you've got open services running that can be abused, you'd have already been abused due to just being on the internet; being on irc doesn't drastically change things there
[19:03] <sarnold> dps: the usual risk of being on irc with an IP address visible is saying something to someone who then aims a ddos booter at you and destroys your ISP's connection. I haven't seen that in years, and those kids normally try to take down entire irc networks rather than individual users..
[19:07] <daftykins> don't get suckered into these VPN services and other nonsense, all you need is to register with nickserv and get a cloak and then make sure you SASL auth at login prior to hopping in channels
[19:08] <sarnold> yeah that's like 99% good enough
[19:12] <pragmaticenigma> yup


[05:13] <drizzt_> why package maintainers never update translations? even there was no release in last years, somebody could contribute new or updated translations, but they are never checked for nor updated in package
[05:16] <micahg> drizzt_: probably depends how the translations are packaged
[05:16] <micahg> drizzt_: what package?
[05:16] <drizzt_> *most* universe packages have missing or outdated translations comparing to project's trunk or whichever upstream it use
[05:18] <micahg> drizzt_: are upstream packaging the translations in the tarballs?
[05:22] <drizzt_> usually they do not backport translations to the release version packaged in Ubuntu, but they usually include it in trunk or recent development version
[05:23] <micahg> drizzt_: well, we take the versions in the release we package generally
[05:24] <micahg> drizzt_: and universe is community maintained, so if there's a package that you'd like to have a new version, you can work on it
[06:43] <anoteng> I've got two packages I'd like to have reviewed by a motu. http://revu.ubuntuwire.com/p/python-easygui bug #596406, and http://revu.ubuntuwire.com/p/transgui bug #332067
[07:33] <ScottK> anoteng: For python-easygui, you might consider packaging it for Debian and having it sync'ed into Ubuntu.  The Debian Python Modules Team is very open to Ubuntu people and sponsoring new Python packages.  See #debian-python on OFTC network.
[07:33] <ScottK> Honestly your odds are better there.
[07:35] <anoteng> ScottK, I'm already looking into it, thanks. I'd still like a review though, as I'm kind of new to this, and probably did something wrong...
[07:36] <ScottK> They don't expect you to be an expert when you show up there, so no need to wait.
[07:36] <ScottK> You'll get more and better reviews there.
[07:36] <ScottK> We get hugely more package requests than we can review each cycle.
[07:40] <anoteng> ok, thanks.
[09:20] <dupondje> How can I upgrade a package to the newest upstream version? The package is not in debian (so no merge/sync)
[09:34] <micahg> dupondje: is there a watch file?
[09:36] <jmarsden> dupondje: See https://wiki.ubuntu.com/PackagingGuide/Complete#Updating%20an%20Ubuntu%20Package for the basic idea.
[09:37] <dupondje> http://ubuntu.dupondje.be/pybootchartgui.debdiff
[09:37] <dupondje> it looks ok ?
[09:40] <micahg> dupondje: you might want to ask the maintainer
[09:46] <BlackZ> zul: could you please take a look at bug #595520 ?
[09:46] <dupondje> micahg: https://bugs.launchpad.net/ubuntu/+source/pybootchartgui/+bug/596475
[09:46] <dupondje> and subscribed the maintainer :)
[09:47] <micahg> dupondje: k
[09:47] <dupondje> can you set it to Wishlist btw ?
[09:47] <micahg> dupondje: sure
[09:48] <BlackZ> dupondje: why is it '0+r141' rather than '0+r141ubuntu1' ?
[09:48] <micahg> BlackZ: native Ubuntu package
[09:49] <BlackZ> ah, true
[09:49] <BlackZ> micahg: good luck for the DMB :P
[09:49] <micahg> BlackZ: thanks :)
[09:52] <micahg> BlackZ: you too
[09:53] <BlackZ> micahg: heh, thanks!
[10:22] <riccetn> Is there any MOTU that can review my package of clementine (Music player): http://revu.ubuntuwire.com/p/clementine
[10:57]  * drizzt_ thinks that we have enough gstreamer-based music players already
[13:37] <ari-tczew> please unsubscribe ubuntu-sponsors from bug 582576
[13:40] <ari-tczew> can someone tell me whether it's necessary change: Update Maintainer field as per spec  ? bug 230350 for example
[13:47] <sebner> ari-tczew: unsubscribed
[13:50] <sebner> ari-tczew: https://wiki.ubuntu.com/DebianMaintainerField
[14:27] <ari-tczew> sebner: thanks for unsubscribe. and what about this maintainer field?
[14:28] <sebner> ari-tczew: I thought that would answer your question if it's necessary to change the maintainer field
[14:28] <ari-tczew> sebner: I asked whether it's necessary
[14:29] <sebner> ari-tczew: well, as the wiki page suggests, every time you modify a debian package that was unchanged before, you have to update the maintainer field
[14:29] <ari-tczew> if there is no delta, package is synced from Debian, so don't change maintainer field
[14:29] <ari-tczew> sebner: still don't understand.
[14:30] <sebner> ari-tczew: right, I don't understand what you don't understand ^^
[14:32] <tumbleweed> ari-tczew: if you modify the package, you update-maintainer. If you sync, the maintainer update is done automatically, on build.
[14:32] <tumbleweed> (and I can't see https://launchpad.net/bugs/230350 due to lp timeouts)
[14:32] <ari-tczew> sebner, tumbleweed: sorry bugs, I have you wrong bug number. let
[14:32] <ari-tczew> let check bug 300858
[14:33] <BlackZ> ari-tczew: what's the problem there?
[14:34] <tumbleweed> BlackZ: no need to mention maintainer update in changelog
[14:34] <ari-tczew> yea
[14:35] <tumbleweed> (also, that bug's description could use an update)
[14:35] <BlackZ> tumbleweed: I think that's not a big deal
[14:35] <tumbleweed> BlackZ: not at all
[14:35] <ari-tczew> BlackZ: and bug number in debian/changelog is wrong
[14:36] <BlackZ> ari-tczew: as you can see, it's a merged change
[14:37] <tumbleweed> BlackZ: however, you didn't close LP: #300858
[14:37] <BlackZ> forgot about that, sorry
[14:38] <ari-tczew> :]
[14:38] <ari-tczew> please check package https://launchpad.net/ubuntu/+source/mtx/1.3.12-3ubuntu1
[14:39] <tumbleweed> yeah, mom should add some boilerplate for closing the merge bug (although I guess people would forget to fill it out)
[14:39] <ari-tczew> Remaining changes: update maintainer according to spec.
[14:39] <BlackZ> ari-tczew: it's not a big deal, as I said
[14:39] <ari-tczew> I think that it's wrong
[14:40] <ari-tczew> BlackZ: what do you mean "not a big deal" ?
[14:40] <BlackZ> ari-tczew: it's not so wrong
[14:40] <ari-tczew> I don't understand a remaining change as update maintainer field
[14:40] <BlackZ> if I found it in the changelog I'd merge it
[14:40] <tumbleweed> ari-tczew: I agree, that could have been a sync.
[14:41] <tumbleweed> there are some other minor changes, though
[14:41] <BlackZ> but as tumbleweed as said, it could be a merge if there aren't other changes
[14:41] <ari-tczew> zul: ping for above case ^^
[14:41] <BlackZ> s/as/has
[14:41] <tumbleweed> ari-tczew: it can't be synced now. ubuntu has never version than debian
[14:42] <ari-tczew> tumbleweed: I know. I want to talk zul for now merging this package due to update maintainer field
[14:42] <ari-tczew> in future
[14:42] <ari-tczew> s/now/not
[14:43] <ari-tczew> BlackZ: "it could be a merge if there aren't other changes" what you mean?
[14:43] <ari-tczew> maybe sync instead merge?
[14:43] <BlackZ> s/merge/sync
[14:43] <ari-tczew> :]
[14:44] <BlackZ> however in my case the sponsor could modify the changelog for remove that if it's considered "wrong" :)
[14:45] <dupondje> tons of merge/sync requests it seems in the MoM :)
[14:46] <ari-tczew> BlackZ: +1. he should upload next XubuntuY with information, that package doesn't need to be merged. no delta
[14:47] <tumbleweed> ari-tczew: the description was changed - there is a delta
[14:48] <ari-tczew> tumbleweed: question of importance of description
[14:48] <ari-tczew> and why he doesn't include information about it in debian/changelog
[14:49] <tumbleweed> :)
[14:55] <ari-tczew> omg, what a mess https://launchpad.net/ubuntu/+source/ilohamail/0.8.14-0rc3ubuntu4
[15:05] <BlackZ> tumbleweed: fixed, thank you
[15:10] <tumbleweed> BlackZ: um, is it just me or has debian fixed your hp-ppd issue? (They run that script with bash)
[15:11] <BlackZ> no tumbleweed, seems it's not fixed at all
[15:11] <tumbleweed> BlackZ: ok how about "it builds fine for me on maverick"
[15:11] <BlackZ> tumbleweed: doesn't it?
[15:11] <tumbleweed> no I'm saying it does
[15:12] <BlackZ> tumbleweed: ah, ok
[15:12] <tumbleweed> ubuntu's solution was to remove bashisms, debian's was to run "bash install.sh"
[15:12] <tumbleweed> looks syncable to me
[15:15] <BlackZ> tumbleweed: in case I will follow up the bug
[15:21] <ari-tczew> NCommander: why did you upload package in version ubuntu4? https://launchpad.net/ubuntu/+source/ilohamail/0.8.14-0rc3ubuntu4
[15:22] <ari-tczew> ah, previous package uploaded in ubuntu3, then you removed old ubuntuX
[15:46] <ari-tczew> sebner: could you take sponsorship for me @ bug 596577 ?
[16:32] <ScottK> statik: You've got a couple of python packages sitting on REVU for almost a year.  Are you still interested in them?
[16:37] <ari-tczew> james_w: why package pyexiv2 doesn't have created branch? https://code.launchpad.net/ubuntu/+source/pyexiv2
[17:21] <slytherin> Now that we support 3.0 formats, we should ideally switch to .orig.tar.bz2 if upstream releases bz2, right? After all every byte of saved storage space counts.
[17:22] <micahg> slytherin: usually, depends if backports lower than lucid are needed
[17:23] <micahg> *archive backports/updates
[17:24] <slytherin> The package in question is gstreamer plugins package. I don't think they are backported frequently.
[17:26] <micahg> slytherin: sounds right
[17:30] <shadeslayer_> any MOTU around to review my REVU upload?
[19:30] <shadeslayer_> hi any MOTU to advocate my package here : http://revu.ubuntuwire.com/details.py?upid=8319
[20:12] <NorthernLights> Hello all
[20:17] <NorthernLights> Hello all
[20:17]  * NorthernLights is poking for a check of REVU packages synergy-plus and killrogues
[20:18] <tumbleweed> NorthernLights: hi. I (stefanor) was just commenting on your synergy-plus package. Looks good to me. But I'd liek to see it in Debian too :)
[20:18]  * tumbleweed uses synergy between debian and Ubuntu
[20:18] <NorthernLights> Hi there
[20:19] <NorthernLights> Sure, as I was answering on launchpad, i want to do this too. I was waiting to get into Ubuntu first, to avoid having to ask twice as much to review my package.
[20:19] <NorthernLights> And I'd like to give the Ubuntu process a chance
[20:35] <shadeslayer_> NorthernLights: could you please check my package too? http://revu.ubuntuwire.com/details.py?upid=8319
[20:35] <NorthernLights> ok
[20:36] <shadeslayer_> thanks :)
[20:44] <shadeslayer_> NorthernLights: ok ill clean that up :)
[20:45] <shadeslayer_> i did put the section as net,then checked p.u.c and saw it was network.. so changed it
[20:47] <shadeslayer_> NorthernLights: also if upstream doesnt ship with a copy right year,do i put in this year?
[20:47] <ScottK> shadeslayer_: Just copy/paste was upstream shipped.
[20:49] <tumbleweed> shadeslayer_: stefanor is me, not NorthernLights :)
[20:49] <shadeslayer_> ohhh
[20:49] <shadeslayer_> tumbleweed: :P
[20:49] <NorthernLights> aaaah ok! Thanks, i was wondering if i pushed the submit button by mistake
[20:50] <shadeslayer_> hehe :)
[20:52] <shadeslayer_> tumbleweed: does : You should have received a copy of the GNU General Public License
[20:52] <shadeslayer_>     along with QIpMsg. If not, see "/usr/share/common-licenses/GPL-3". sound ok?
[20:58] <tumbleweed> fine fine
[20:59] <shadeslayer_> ok fixed most stuff ... will make the rules changes later ....
[21:00] <shadeslayer_> ciao :)
[21:06] <NorthernLights> shadeslayer_, i'm adding a comment too
[21:06] <NorthernLights> (basically, "run lintian :)")
[21:10] <NorthernLights> (i'm building the binary package to make sure it works)
[23:12] <ari-tczew> lool: check your e-mail's inbox. libsmbios's maintainer has Cced message to you about libsmbios package handling
[23:21] <sebner> ari-tczew: well, either you wait until wednesday (quite some stuff to do for university) or you ask someone else aka just wait for someone to sponsor it, and it's a bzw branch too .. brrrr :P
[23:22] <ari-tczew> sebner: sorry, I forgot about your issue
[23:23] <ari-tczew> sebner: I want to see grow of bug numbers sponsored. besides you I'm going block some bugs on 2 other sponsors
[23:23] <ari-tczew> sebner: maybe you should take some lessons about bzr sponsoring?
[23:24] <sebner> ari-tczew: bah let me push that back for maverick +1 :P
[23:24] <ari-tczew> sebner: why +1?
[23:24] <ari-tczew> instead maverick 0 :d
[23:25] <sebner> ari-tczew: well, DIF is around and I think bzr sponsoring will become more stable and more common for maverick+1
[23:25] <micahg> ari-tczew: people have limited time, I had a great idea I ran a session for at UDS that I have to push off till maverick +1
[23:26]  * sebner ^5 micahg
[23:27] <ari-tczew> micahg: so you won't work anymore in maverick+1? correct translated?
[23:27] <sebner> ari-tczew: deal: I sponsor your non-bzr stuff and I might get into this bzr stuff in my summer holidays
[23:27] <micahg> ari-tczew: no, I just have my own list of things, so this other one has to wait
[23:28] <ari-tczew> sebner: I think that you can download a bzr diff from bug and patch -p1 it on current ubuntu's package
[23:29] <sebner> ari-tczew: I could but that goes against the sense of having a bzr branch and do bzr sponsoring ;)
[23:30] <ari-tczew> sebner: so do you will sponsor it only by debdiff and soon in wednesday?
[23:31] <sebner> ari-tczew: well, keep ubuntu sponsors subscribed and if nobody has sponsored it until then I'll do it
[23:32] <ari-tczew> sebner: ok I'll talk with other sponsors who has not enough sponsored bugs for me
[23:32] <sebner> ari-tczew: so I guess you won't apply tomorrow? (You once told me something about the 22th)
[23:33] <ari-tczew> sebner: no, later
[23:33] <ari-tczew> sebner: not ready now
[23:36] <sebner> kk