[12:05] <udienz> geser, i took your package (wavesurfer) thanks to mentions on m.u.c
[16:46] <hyperair> was there a solution to the /usr/lib64/libX11.so.6: could not read symbols: Invalid operation
[16:46] <hyperair> errors?
[16:59] <geser> hyperair: what's the line before that? (or pastebin the whole error)
[16:59] <hyperair> /usr/bin/ld: note: 'XFlush' is defined in DSO /usr/lib64/libX11.so.6 so try adding it to the linker command line
[16:59] <hyperair> i mean yeah, sure -lX11 should do the trick
[16:59] <geser> yes
[16:59] <hyperair> but why isn't that flag included in gtk's .pc file?
[17:00] <hyperair> running something like ./configure LDFLAGS=-lX11 feels dirty
[17:00] <geser> why should it when your application uses symbols from -lX11?
[17:00] <geser> and you shouldn't put -l... to LDFLAGS
[17:00] <hyperair> er sorry
[17:00] <hyperair> where should it go then?
[17:01] <hyperair> LIBS or something?
[17:01] <geser> LIBS when it's used my the Makefile
[17:01] <Laney> LDADD?
[17:01] <hyperair> =\
[17:01] <geser> or patching the Makefile.am and add it to ..._LDADD
[17:02] <hyperair> does X11 have a .pc file?
[17:04] <geser> yes, x11.pc
[17:11] <hyperair> alright
[17:35] <kklimonda> hey, any idea if this http://pastebin.com/CpFaWxa9 is still a dfsg-compliant license?
[17:36] <tumbleweed> kklimonda: sounds reasonable (although it really should include an explicit licence statement of some sort
[17:38] <Laney> I don't think "MIT style license" means anything
[17:40] <tumbleweed> it's pretty clear that the author's intention is to let you do what you want, however "not enforcing" doesn't mean "you can"
[17:42] <kklimonda> tumbleweed: it does below
[17:42] <kklimonda> tumbleweed: I'm concerned about the second paragraph
[17:42] <tumbleweed> kklimonda: that refers to contributions submitted to the author, not derivaties in general
[17:43] <kklimonda> tumbleweed: right - so it's like a copyright assignment without explicit assignment? :)
[17:44] <tumbleweed> kklimonda: that is copyright assignment, I'd say
[17:44] <Laney> it's bonkers and he should be notified of the WTFPL
[17:45] <Bachstelze> but without a meaningful license, so I'd say not DFSG, bit IANdebian-legal
[17:45] <kklimonda> I guess what's I'm wondering is if it's legally binding - I'm already not entirely sure how would Canonical's copyright assignment hold in the court and this one feels even less substantianal..
[17:45] <kklimonda> Bachstelze: there is a normal MIT license below
[17:46] <tumbleweed> kklimonda: copyright assignment is out of the scope of redistributability / DFSG-freeness
[17:46] <Bachstelze> oh
[17:46] <Bachstelze> basicalyl the same thing as the old Qt "GPL with exceptions" then
[17:46] <kklimonda> I guess I should have pasted a whole license instead of the interesting bits: http://pastebin.com/PypEWBZ9
[17:47] <Bachstelze> "here's the license, and here's how we modify it"
[17:47] <kklimonda> right
[17:47] <kklimonda> the copyright assignment has been the only thing I was unclear about :)
[17:47] <kklimonda> thanks for helping
[20:31] <manish> I have a small doubt about how to version packages to supersede existing packages
[20:32] <manish> means so that it makes it an update of the package
[20:32] <manish> 0.6-0manish2~0ppa1~maverick is lower version than  0.6-0ubuntu2~0ppa1~maverick ??
[20:32] <manish> right?
[20:32] <Bachstelze> manish: that would depend what the current version is
[20:33] <manish> 0.6-0ubuntu1~0ppa1~maverick
[20:33] <manish> is the current version
[20:33] <manish> Bachstelze: so is 0.6-0manish1~0ppa1~maverick lower version?
[20:34] <Bachstelze> manish: % dpkg --compare-versions "0.6-0manish2~0ppa1~maverick" "<" "0.6-0ubuntu2~0ppa1~maverick" && echo "yes, it is lower"
[20:34] <Bachstelze> yes, it is lower
[20:34] <Bachstelze> :)
[20:34] <Bachstelze> because m < u
[20:34] <manish> ah. Didn't know about this --compare-versions
[20:34] <manish> yeah, that's what I was thinking
[20:34] <Bachstelze> but obviouslt you shouldn't rely on it
[20:34] <manish> but isnt ~ used for version resolution?
[20:35] <Bachstelze> it's irrelevant, because the difference appears earlier
[20:35] <manish> if not, then ~ is used for resolution?
[20:35] <manish> there is a second issue
[20:36] <manish> Bachstelze: in the .changes file the .orig.tar.gz file is not mentioned
[20:36] <micahg> manish: FYI, how the version works: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
[20:37] <manish> I can see in .changes file
[20:37] <manish> Checksums-Sha1:
[20:37] <manish>  a9e77d01398045b64d6108bc9e01463cb1a9c171 1690 zeitgeist_0.6-0ubuntu1~0ppa2~maverick.dsc
[20:37] <manish>  b37853ce4adda8605d7fd56ea6843b4c55cd0243 4501 zeitgeist_0.6-0ubuntu1~0ppa2~maverick.debian.tar.gz
[20:37] <manish> there is no mention of .orig.tar.gz so dput doesnt upload the orig tarball
[20:37] <Bachstelze> yes
[20:37] <manish> and the build system rejects the upload
[20:37] <Bachstelze> you need to build it with -S -sd if you want to include the source tarball
[20:38] <Bachstelze> (or is it -sa ?)
[20:38] <Bachstelze> I can never remember
[20:38] <manish> let me try
[20:38] <Bachstelze> it's in the PPA help pages on LP
[20:38] <geser> -sa (a like all), -sd is diff only
[20:38] <manish> Bachstelze: geser I tried -sa works :)
[20:49] <dapal> evaluate: tonight I hope to give a look to CMS ;)
[20:51] <evaluate> dapal, whenever you have the time. I'm pretty busy myself this week, so I didn't have much time to test it properly either, but I hope I can take some time in the weekend to review it again and maybe fix some more problems if I (or you) can spot any...
[20:52] <dapal> evaluate: ah. I have an exam next week -- better if I delay it altogether then :)
[20:52] <dapal> evaluate: so, back to my books now :/
[20:53] <evaluate> ok. good luck! :-)
[20:55] <evaluate> dapal, also, I've put my eyes on another program that I'd find interesting to package, so I'll keep you busy for a couple more weeks :p
[20:55] <dapal> evaluate: sure, what is it?
[20:57] <evaluate> dapal, it's called bbclone (www.bbclone.de), it's a counter/statistics software for websites. I use it on all of my sites actually...
[20:57] <dapal> ah, I don't know it. Seems like you're interested in web-app packaging :)
[20:59] <evaluate> not necessarily, I just thought about these because I use them myself. btw, I just noticed that bbclone seems to be in stable already. Any idea why it isn't in testing/sid though?
[21:00] <dapal> maybe it was removed.. let's see
[21:01] <dapal> evaluate: it's been removed in July 2010
[21:01] <dapal> evaluate: ROM; dead upstream, license issues, low popcon
[21:02] <evaluate> dapal, I don't know what ROM is, but the latest update was done at "Sat, 01 Jan 2011 00:07:03 +0100", so upstream is far from dead, and the project is licensed under GPL3, so I don'tsee how that can pose any issues...
[21:03] <dapal> evaluate: Request Of Maintainer
[21:03] <evaluate> uhum
[21:03] <dapal> evaluate: yes, I was looking at the website. Maybe it included some problematic thing, at the time
[21:03] <dapal> evaluate: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590332
[21:03] <dapal> ah, icons
[21:04] <dapal> evaluate: I'd say that, if you're able to cope with the icons issue (if it still holds), you could just get the old package from stable, and continue from that one
[21:04] <dapal> evaluate: so we also preserve the package history
[21:06] <evaluate> hmm. I'll have a closer look at this. I'm interested in the package anyway and I also thought about sharing some patches with upstream...
[21:10] <evaluate> btw, I just had a quick look at the local copy of the package that I have and I can't see any separate license for the images, so I'd guess they are also GPL3...
[21:10] <dapal> it's better if you ask upstream :)
[21:12] <evaluate> or I guess I could talk to the former maintainer of the package, maybe he could tell me what the actual problems with the icons were...
[21:12] <dapal> :)


[06:59] <dholbach> good morning
[07:02] <PaoloRotolo> Good morning
[07:03] <dholbach> ciao PaoloRotolo
[07:03] <dholbach> come stai?
[07:03] <PaoloRotolo> dholbach, fine, thanks :D
[07:03] <dholbach> :-)
[07:04] <PaoloRotolo> dholbach, your italian is good :P
[07:04] <dholbach> no, it's not ;-)
[07:04] <dholbach> but I picked up a few words and hope to pick up a few more - because I'll be on holiday in Italy in ~2 weeks :)
[07:05] <PaoloRotolo> dholbach, nice, where?
[07:06] <dholbach> we're invited to a wedding in Massafra, but we're going to see other parts of the country as well :)
[07:08] <PaoloRotolo> dholbach, it's near my town :) I live in Puglia
[07:08] <dholbach> ah nice :)
[07:08] <didrocks> hey dholbach ;)
[07:09] <dholbach> salut didrocks
[07:09] <didrocks> hi PaoloRotolo
[07:09] <dholbach> PaoloRotolo, I'm looking forward to it
[07:09] <PaoloRotolo> dholbach, hi!
[07:09] <didrocks> wrong d<tab> ;)
[07:09] <PaoloRotolo> didrocks, yes, sorry
[07:09] <PaoloRotolo> didrocks, hi
[07:10] <didrocks> PaoloRotolo: no worry, happens to me every single day! :)
[07:10] <PaoloRotolo> didrocks, me too :)
[07:23] <dholbach> if any of you could help test the bugs mentioned in https://bugs.launchpad.net/ubuntu/+source/python-distutils-extra/+bug/1020017 (test-cases are in there), it'd be much appreciated
[07:42] <dholbach> ajmitch, are you feeling any better now?
[07:42] <dholbach> ajmitch, what do we do with the wikipedia lens?
[07:50] <ajmitch> dholbach: usually the person who puts it up for vote has been the uploader, but that obviously won't work
[07:51]  * ajmitch has just got back in from pycon meeting, needs to sort dinner
[07:51] <dholbach> ajmitch, wow, you're in meeting throughout the week :)
[07:51] <ajmitch> well, last night was codecraft, a monthly meeting
[07:51] <ajmitch> so we moved the pycon one to tonight
[08:15] <BerndSch> ajmitch: are there any news for my submitted app (https://myapps.developer.ubuntu.com/dev/apps/548/) for the precise software center?
[08:20] <PaoloRotolo> ok, can I review the last app: variety?
[08:21] <dholbach> PaoloRotolo, sure
[08:21] <PaoloRotolo> good
[08:21] <dholbach> BerndSch, I'll take a look
[08:21] <PaoloRotolo> Let's start :)
[08:32] <dholbach> ajmitch, does etc/apparmor.d/opt.extras.ubuntu.com.unity-lens-sshsearch.unity-lens-sshsearch.py look like a correct path to you?
[08:33] <dholbach> I never dealt with any of this, so I'm not 100% sure
[08:35] <dholbach> BerndSch, I pushed a few changes to lp:~dholbach/ubuntu-app-reviews/unity-lens-sshsearch which you might be interested in
[08:36] <dholbach> BerndSch, I'm a bit unsure about the location of the apparmor profile, but as I'm not an expert, I'll leave it as it is :)
[08:48] <ajmitch> dholbach: I left that & the debian/{control,rules} stuff in - what I wanted was for other people to vote on it
[08:48] <ajmitch> there were some problems with qreator & the metadata getting through to software-center from what I recall
[08:57] <dholbach> oh
[08:58] <dholbach> you mean the dh_gencontrol stuff?
[09:00] <dholbach> ok, I reapplied it to lp:~dholbach/ubuntu-app-reviews/unity-lens-sshsearch
[10:34]  * dholbach just had a look at pyMi
[10:43]  * dholbach has a look at indicator pingdom
[10:48] <dholbach> I'll have a look at utrails next
[10:48] <dholbach> this is actually fun :)
[10:55] <dholbach> utrails might actually be ready soon
[11:03]  * dholbach has a look at protoborsa
[11:10] <achuni> good morning!
[11:11] <dholbach> hey achuni
[11:11] <achuni> hi dholbach :)
[12:30] <didrocks> hey dholbach :)
[12:31] <didrocks> dholbach: so the new requirements on http://bazaar.launchpad.net/~dholbach/ubuntu-app-reviews/indicator-pingdom/changes/4?start_revid=4 (like apport and the .rtupdate) makes it difficult for people using Quickly for the context
[12:31] <didrocks> as it won't be update for this
[12:31] <didrocks> and next quickly package will overwrite this
[12:31] <didrocks> TommyBrunn: for 2. you can quickly configure dependencies
[12:31] <didrocks> then manually add in a line the dep
[12:31] <didrocks> then, quickly package will add this dep when recreating debian/control
[12:32] <TommyBrunn> didrocks: Ok, that I can certainly do.
[12:32] <didrocks> TommyBrunn: for the copyright, right, it's a case we don't support, apart from copying over the debian/copyright, I'm unsure :)
[12:32] <didrocks> but it's interesting, yeah, didn't think about apps wrapping multiple libs
[12:33] <TommyBrunn> didrocks: Wouldn't it be fairly common to have at least something that's not necessarily your own. Such as using a CC icon or something?
[12:34] <dholbach> didrocks, urgh :-(
[12:34] <didrocks> TommyBrunn: well, Quickly was done for applications in the distro first, not ARB one
[12:34] <dholbach> didrocks, it wasn't clear to me that quickly would overwrite it again
[12:35] <didrocks> TommyBrunn: so normally, that would ask for a separate source package
[12:40] <TommyBrunn> didrocks: doing quickly configure dependencies will add libglib2.0-bin as a regular dependency, not a build-dependency. Is that a problem?
[12:40] <didrocks> TommyBrunn: not really, automagic build-dep doesn't work in dh_python2 anyway
[12:40] <didrocks> but yeah, something to note when it will work :)
[12:42] <dholbach> didrocks, do you know what might cause something like lines 8-10 in http://bazaar.launchpad.net/~dholbach/ubuntu-app-reviews/protoborsa/revision/24?
[12:43] <didrocks> dholbach: what is wrong? :)
[12:43] <dholbach> didrocks, the removed lines
[12:43] <dholbach> didrocks, I think it's auto-generated stuff
[12:43] <didrocks> it's a quickly project?
[12:43] <dholbach> and I've seen it many times reviewing apps
[12:43] <dholbach> yes
[12:43] <didrocks> this comes from the AUTHORS file
[12:43] <dholbach> almost all of them are
[12:43] <didrocks> so if the AUTHORS file changed, it's put there
[12:43] <dholbach> "</property>" does not look like a standard AUTHORS bit
[12:44] <didrocks> the first stenza changed is the new format
[12:44] <didrocks> http://bazaar.launchpad.net/~dholbach/ubuntu-app-reviews/protoborsa/view/head:/AUTHORS
[12:44] <dholbach> what about the "</property>" bit?
[12:45] <dholbach> but I guess it's more of a p-d-e problem anyway, right?
[12:49]  * didrocks doesn't see </property>
[12:49] <didrocks> ah
[12:49] <didrocks> in the lines removed
[12:49] <didrocks> yeah, it's an old bug of p-d-e
[12:49] <didrocks> the new update, as you can see, removes it :)
[12:50] <dholbach> sweet
[12:50] <dholbach> I can't wait for the update to go into -updates
[12:50] <dholbach> it's in -proposed already
[12:53] <dholbach> didrocks, I'm not sure what we do about 'quickly package' overwriting things :-/
[12:57] <didrocks> dholbach: well, if the requirements are moving, we won't be ever able to stabilize some stuff on quickly
[12:57] <didrocks> dholbach: we do have to update because the packaging is changing
[12:58] <coolbhavi> highvoltage, ajmitch dholbach https://myapps.developer.ubuntu.com/dev/apps/1111/ < -- can I reject this request?
[12:59] <coolbhavi> its available freely and readily for download I see no point in pushing this through as an app
[13:00] <coolbhavi> available as is as a pdf
[13:08] <coolbhavi> any comments?
[13:10] <dholbach> didrocks, the requirements stayed the same - it's the packaging infrastructure which changed :)
[13:22] <highvoltage> coolbhavi: hmm, PDFs are usually allowed, I think it usually goes through the commercial process because they have some process for that. I agree that it's kind of pointless but I'm not sure if that's enough basis to reject it on
[13:22] <dholbach> you can punt it to the other queue
[13:25] <coolbhavi> highvoltage, thanks for that
[13:25] <coolbhavi> dholbach, whom to contact for the commercial queue?
[13:26] <coolbhavi> for moving the app?
[13:29] <coolbhavi> this is the first time I am encountering such situations
[13:39] <coolbhavi> achuni, hi
[13:39] <achuni> hey coolbhavi
[13:40] <coolbhavi> https://myapps.developer.ubuntu.com/dev/apps/1111/ there is a pdf which is readily available for download.. Yet submitted to the ARB for processing
[13:41] <coolbhavi> achuni, ^^^
[13:42] <achuni> coolbhavi: right, MyApps bumps everything that is $0 and uses a free license over to the ARB
[13:42] <achuni> coolbhavi: even though the ARB doesn't do pdf content, it's hard to tell automatically when an app is a pdf-in-a-box
[13:43] <achuni> coolbhavi: ah, I see your comments above (I might have missed a few, I dropped out a bit I think)
[13:44] <coolbhavi> achuni, personally I see no point in pushing this as an app because its available as is for download as pdf  as I said above
[13:44] <achuni> coolbhavi: I'd say bump over to the non-ARB queue
[13:45] <coolbhavi> achuni, do you guys have a process for packing a pdf document btw? and how to move it over?
[13:45] <achuni> coolbhavi: until there's a separate "book store" for ubuntu, pdfs and apps are being mingled... there's an intent to separate them out at some point soon
[13:46] <achuni> coolbhavi: to move over, during review you should have a button at the bottom of the page that says "Move to MyApps"
[13:47] <coolbhavi> achuni, ah ok never used that thanks!
[13:47] <achuni> coolbhavi: which is a very non-intuitive label, yep.  at first we referred to the non-ARB queue as the "MyApps" queue
[13:47] <achuni> coolbhavi: I still don't think we have a good name for the non-ARB queue :)
[13:49] <coolbhavi> achuni, seemed a bit confusing at first look because we are reviewing in the My apps portal atleast going by the website :) so I just got a bit dumb I guess
[13:49] <coolbhavi> sorry for that
[13:51] <achuni> coolbhavi: np :)
[14:09] <TommyBrunn> So dholbach, didrocks, any ideas on how to solve this problem? I imagine I'm not going to be the only person in the Ubuntu App Showdown to use quickly and have some third-party stuff in there. I'd be fine with a hacky solution for now, as long as there _is_ a solution.
[14:10] <dholbach> TommyBrunn, which problem are you referring to? the .rtupdate and apport issue?
[14:10] <dholbach> if that's the case, ignore it for now - I'll send a mail to the ARB list about it
[14:11] <TommyBrunn> No, I was referring to the issue with the copyright file
[14:11] <didrocks> well, you are the only one about the copyright file as of today TBH :/
[14:11] <didrocks> it's something to open a bug for, it's an interesting case quickly wasn't design for
[14:12] <didrocks> right now, I can only see this as copying it over
[14:13] <TommyBrunn> What do you mean about that last part?
[14:13] <dholbach> I think I'm missing part of the discussion right now - is debian/copyright auto-generated too and overwritten or what is the issue?
[14:13] <TommyBrunn> That is correct
[14:14] <TommyBrunn> When quickly packages the project, it generates a new copyright file and overwrites the old one
[14:14] <dholbach> ok
[14:14] <didrocks> as you can have added AUTHORS to this file
[14:15] <didrocks> bundling other libs in your app was not what quickly was designed for
[14:15] <dholbach> didrocks, once the project is in the "finishing touches" stage, would it be possible to use something like "bzr bd -- -S -sa; cd ..; dput ppa package*.changes" instead of 'quickly package'? or would it cause problems?
[14:16] <dholbach> so we could tell people to concentrate on the code and once they're happy, "upload it regularly"?
[14:16] <didrocks> dholbach: that won't cause any problem
[14:16] <didrocks> well
[14:16] <didrocks> until you add new deps :)
[14:16] <didrocks> or update AUTHORS
[14:16] <didrocks> or add new files :p
[14:17] <dholbach> right
[14:17] <dholbach> debuild -i.bzr then ;-)
[14:18] <didrocks> same issue if you add new deps or update AUTHORS, but yeah, at least, new files are handled :)
[14:21] <dholbach> didrocks, or we would tell app authors to just give us a link to their bzr branch
[14:22] <didrocks> yeah, but that will break at next release
[14:22] <didrocks> I think it's something to discuss for next week
[14:22] <didrocks> it's a tricky question
[14:22] <dholbach> I just sent https://lists.ubuntu.com/archives/app-review-board/2012-July/001056.html
[14:23] <didrocks> until now, we told "the debian directory is owned by quickly"
[14:23] <dholbach> and CCed you
[14:23] <didrocks> thanks :)
[14:23] <dholbach> TommyBrunn, for now I'd recommend to ignore the issue
[14:24] <dholbach> and just keep on working on the app :)
[14:24] <dholbach> as soon as we have a solution we'll advise through myApps comments
[14:24] <TommyBrunn> Okay, thanks for your time. :)
[14:24] <dholbach> thanks a lot for bringing it up
[14:25]  * dholbach goes back to teaching the apps-brancher to pull from PPAs :)
[14:40] <PaoloRotolo> Hi all!
[14:42] <highvoltage> hi PaoloRotolo
[14:42] <PaoloRotolo> hi highvoltage
[14:42] <dholbach> ciao PaoloRotolo
[14:43] <dholbach> PaoloRotolo, I'm not sure if you saw https://lists.ubuntu.com/archives/app-review-board/2012-July/001056.html yet
[14:43] <PaoloRotolo> dholbach, ciao :)
[14:43] <dholbach> (not sure if you are on the list)
[14:43] <dholbach> but for now we should probably hold off making .rtupdate, crashdb and DEP5 changes
[14:43] <dholbach> as they will be overwritten anway :-/
[14:44] <dholbach> hey highvoltage
[14:45] <dholbach> but still it should make sense to branch apps, install them, test them and review them - there might be other issues we can point out or fix :)
[14:45] <PaoloRotolo> dholbach, sorry I don't understand... We can't fix the DEP5 in the copyright, for example?
[14:46] <dholbach> PaoloRotolo, yes, even if the app author merges the changes, they will be overwritten the next time they run 'quickly package'
[14:46] <dholbach> so until we have a good solution to the problem, it doesn't make sense yet
[14:48] <PaoloRotolo> dholbach, and... what happens if someone doesn't use Quickly?
[14:48] <PaoloRotolo> is not obligatory
[14:52] <dholbach> in that case the change would make sense :)
[14:57] <PaoloRotolo> dholbach, so, if the app don't use Quickly I can fix the issue, right? How can I know if the app are using it?
[14:58] <dholbach> didrocks, is the .quickly file always shipped?
[14:59] <didrocks> dholbach: in the source package? right, but it shouldn't be installed
[14:59] <dholbach> sure, sorry - that's what I meant
[15:00] <didrocks> yeah yeah ;)
[15:00] <didrocks> apart if the dev is doing some tricks ;)
[15:00] <didrocks> but no garantee then!
[15:00] <dholbach> PaoloRotolo, if there's a .quickly file in the source package then it uses Quickly
[15:02] <dholbach> the apport crash db we filed a bug report for, the DEP5 thing should be fixed once python-distutils-extra gets into -updates
[15:02] <dholbach> but for the .rtupdate thing we still don't have a good answer :/
[15:03] <dholbach> didrocks, can we get a 'quickly package --dont-do-it' option? :-P
[15:04] <PaoloRotolo> dholbach, good. If there isn't a quickly file I can fix the issue. If there is, we can invite the owner of the app to run 'quicly package', ok?
[15:04] <didrocks> dholbach: well, we need to find a way, as told in the email, there are a lot of reasons to have those files owned by quickly
[15:04] <dholbach> PaoloRotolo, 'quickly package' will overwrite all our changes to debian/rules and debian/copyright
[15:04] <didrocks> the issue is when the platform and requirements changes :)
[15:05] <didrocks> like this new rtupdate file
[15:05] <didrocks> the copyright dep5, it's not mandatory to push latest versions
[15:05] <dholbach> and in more complicated cases like a more complicated debian/copyright
[15:05] <dholbach> no, it's not - agreed
[15:05] <didrocks> the older spec is still valid
[15:05] <didrocks> and we have a bunch of packages in main still following it :)
[15:06] <didrocks> the "I embeed a separate lib in my app" is more worrying
[15:06] <didrocks> not really sure how we can do that
[15:06] <didrocks> I'm sure pkgme has the same issue btw
[15:06] <dholbach> ask authors to add a EXTRA_COPYING file which gets >> debian/copyright ;-)
[15:09] <PaoloRotolo> dholbach, oh, I finally got it :D
[15:11] <PaoloRotolo> dholbach, So this affects only the apps in development. (for the contest)
[15:12] <dholbach> PaoloRotolo, let's wait which replies come up in the discussion on the mailing list
[15:12] <PaoloRotolo> It's not valid for the mature apps submitted to the ARB
[15:12] <dholbach> right now, I'd say best ignore it for quickly apps
[15:14] <PaoloRotolo> dholbach, ok, thanks! I'm going to subscribe the mailing list
[15:14] <dholbach> thanks :)
[15:14] <PaoloRotolo> [I'm afk for 5 minutes]
[15:48] <PaoloRotolo> ok, fixed 4 issues with "variety"
[15:48] <PaoloRotolo> I'm uploading it into a branch
[16:13] <PaoloRotolo> Here it is: https://code.launchpad.net/~ubuntu-app-review-contributors/ubuntu-app-reviews/variety
[17:48] <BerndSch> dholbach, ajmitch: I updated my branch with dholbach changes and submitted the new tar.gz for my app https://myapps.developer.ubuntu.com/dev/apps/548/changerequest/145/


[01:15] <Blazeix> i really liked 1devday
[01:16] <Blazeix> there were a few good talks. the jvm concurrency and 'using types to write your code' were my favorite
[01:17] <Blazeix> both keynotes were _really_ bad though
[01:18] <Blazeix> i really wanted to go the Neo4j talk but decided at the last second not to. I heard that was good too, though
[02:01] <widox> Blazeix: I almost hit the types talk
[02:01] <Blazeix> that was a good one. i just barely knew enough haskell to hang on
[02:01] <widox> haha, yeah the first keynote was pretty awful
[02:11] <jrwren> who gave it?
[02:11] <jrwren> and who gave the good ones?
[02:13] <Blazeix> Ted Neward gave the first keynote.
[02:14] <jrwren> ah, i do not like him very much.
[02:14] <Blazeix> Nilanjan Raychaudhuri (from Typesafe) gave the jvm concurrency one
[02:14] <jrwren> i don't know him.
[02:14] <Blazeix> and Job Vranish from Atomic Object gave the haskell types talk
[02:14] <jrwren> cool
[02:14] <Blazeix> yeah, i didn't know him either, but typesafe is a pretty popular company in the scala world
[02:16] <Blazeix> would a pythony person be willing to tell me if this is reasonably idiomatic python? http://vpaste.net/yueLT?bg=dark
[02:16] <Blazeix> it finds the mathematical modes of a list of ints
[02:17] <jrwren> looks reasonably pythonic
[02:18] <Blazeix> the freqs[0][1] feels a bit dirty to me
[02:18] <jrwren> its a local, i don't care about those.
[02:20] <Blazeix> yeah, true. i suppose it's a simple enough method that it doesn't really matter
[02:20] <Blazeix> s/method/function/
[02:21] <Blazeix> this will be used as a reference implementation for a programming quiz, so i want to put it under a bit of scrutiny
[04:29] <derekv> https://github.com/DerekV/stacksp/blob/master/stacksp.lisp *evil laugh*
[04:29] <Blazeix> derekv: haha, nice
[04:31] <derekv> so with that code "2 3 4 +" emits "( 9 )" and "2 3 4 + 20 -" is "( 11 )" etc
[04:32] <derekv> but what i'm going to work on next is being able to define functions from inside the language, and nested stacks
[12:24] <snap-l> Blazeix: I've used that convention before (freqs[0][1]), but not sure if it's the most pythonic way to do it
[12:29] <rick_h> Blazeix: yea, I feel dirty with that stuff, but native types ftw and you don't keep around the freq. value so there's no point turning it into a NamedTuple for the pretty code factor
[12:33] <snap-l> rick_h: I'm glad I'm not the only one. :)
[12:35] <rick_h> yea, if Counter was your own method I'd say make it return a namedtuple
[12:35] <rick_h> and then use that
[12:35] <rick_h> but it's a stdlib biult in so no point
[12:46] <rick_h> Blazeix: http://paste.mitechie.com/show/840/ though is what I'd go with. Move hte return to avoid the Collection at all. max is a reserved word since it's a built in method.
[12:47] <rick_h> Blazeix: and the optional is returning a generator vs the actual list to make it lazy
[12:51] <snap-l> Wow, Quantal is pretty slow in a virtual machine as far as rendering
[12:51] <snap-l> I mean "watch, as I fade in this window" slow
[12:52] <rick_h> they removed the unity 2d stuff so you get sofware rendering
[12:52] <rick_h> so need 3d on there or non-unity I think
[12:53] <snap-l> Even with it turned on, it's pretty slow.
[12:55] <brousch> Unity?
[12:57] <snap-l> Yeah
[12:58] <snap-l> And as such, you can't turn the transitions off without help
[13:33] <Blazeix> rick_h: oh yeah, good call on the 'max' variable name
[13:36] <Blazeix> not sure about returning a generator though. most_common() returns a list, so i think i'll try to ape that pattern
[13:36] <rick_h> yea just tossed that out as an optional over optimized version :)
[13:40] <Blazeix> haha, thanks snap-l rick_h jrwren for your help
[14:19] <jrwren> anytime.
[14:19] <jrwren> did you pylint it?
[14:20] <rick_h> only lint issues are the testing code at the bottom missing spaces after the ,
[14:20] <rick_h> :)
[14:20] <rick_h> I looked at it
[14:22] <jrwren> cool
[14:22] <jrwren> just a suggested first step
[15:03] <rick_h> gah, monday screw up.
[15:03] <rick_h> forgot my headphones at the coffee shop and sitting next to EMTs with their radios going off every other minute
[15:05] <ColonelPanic001> working without headphones < death
[15:05] <rick_h> yea, #firstworldproblems and all that jazz
[15:05] <ColonelPanic001> I should seriously start trying to get up really early in the morning. The cube farm is much less annoying when it's nearly empty
[15:06] <ColonelPanic001> the problem is, I'm more of a "sleep from 2am-10am" person
[15:06] <rick_h> yea, always loved my quiet morning time in the cube
[15:06] <rick_h> ugh, yea no good there
[15:06] <ColonelPanic001> I miss Traffic Engine et. al.
[15:06] <ColonelPanic001> being able to get up at 10am, walk into the living room and check email
[15:06] <rick_h> well it should think out a bit after 5pm
[15:06] <ColonelPanic001> etc
[15:06] <jjesse> our office has gotten louder since we've gone to non-assigned cubes
[15:06] <ColonelPanic001> non-assigned cubes? may as well hang yourself
[15:06] <ColonelPanic001> this is MY CUBE
[15:06] <ColonelPanic001> IT SUCKS, BUT IT IS MINE
[15:06] <jjesse> so we have people who make phone calls all day sitting in the open area
[15:07] <ColonelPanic001> seriously, murder them.
[15:07] <rick_h> more reason to get in early
[15:07] <ColonelPanic001> murder.
[15:07] <rick_h> get the good cubes
[15:07] <jjesse> that's what i do
[15:07] <jjesse> or work more from home :)
[15:07] <ColonelPanic001> one thing I do like about working on a campus, though - I coule grab a laptop and gtfo, go to many other buildings
[15:07] <ColonelPanic001> the problem is I have two monitors here, and that is a thing of beauty
[15:07] <ColonelPanic001> and finding another location that has power/decent net/desk/etc
[15:08] <rick_h> hah, yea.  understand that
[15:08] <ColonelPanic001> but the potential exists
[15:08] <rick_h> gah, christmas music
[15:08] <rick_h> I'm not going to make it here at the coffee shop until lunch ... ugh
[15:08] <ColonelPanic001> rick_h: you're really facing many problems this morning that are worse than death
[15:08] <ColonelPanic001> are you sure life is still worth living?
[15:08] <rick_h> ColonelPanic001: hmm, debating
[15:08] <ColonelPanic001> EMTs radios and christmas music? Think carefully.
[15:09] <rick_h> but UPS has toys in the mail...I need to live until Wed at least
[15:09] <ColonelPanic001> bequeath them to me
[15:09] <ColonelPanic001> problem solved :D
[15:09] <rick_h> hah!
[15:10] <ColonelPanic001> speaking of dark/morbid humor, ordered Cards Against Humanity a little while ago, came in the other day. Have to do a test play of that soon
[15:10] <rick_h> heh, the first few runs through it are the best
[15:11] <rick_h> so make sure to make the first ones great groups of peeps with plenty of accessory liquids
[15:15] <ColonelPanic001> heh
[15:16] <widox> ColonelPanic001: I hope you don't /really/ miss TE ;)
[15:16] <jrwren>  i hate cubes. i refuse to wok in them. this cubbie is bad enough.
[15:16] <jrwren> i like open desks everywehre.
[15:18] <ColonelPanic001> widox: just the workplace
[15:19]  * widox still works from home
[15:19] <ColonelPanic001> If they gave us open desks up here, I'd never come here again. Laptop workin' from a library or something
[15:19] <ColonelPanic001> I hear enough inane babbling here as it is
[15:20] <jrwren> it depends on how many people to a room you have.
[15:20] <jrwren> we have a max of about 7.
[15:20] <jrwren> there are 6 in my room.
[15:20] <jrwren> WALLS ARE GOOD!
[15:21] <jrwren> Wall all the things!
[15:37] <ColonelPanic001> I have about 20 or 30 in here probably
[15:37] <ColonelPanic001> I'd kill for walls around me. And a light switch.
[15:40] <jrwren> i assume for lights out?
[15:41] <jrwren> tahnkfully, we 6 are lights out.
[15:41] <ColonelPanic001> open desks might be okay if it were with 4-5 others who worked on similar/same things as me. Collaboration and cross-pollination would be awesome. But, that's my limit.
[15:41] <ColonelPanic001> exactly
[15:41] <ColonelPanic001> I hate lights
[15:41] <ColonelPanic001> my monitors light up guys, stop turning on the damn lights
[15:41] <jrwren> what do you do?
[15:41] <jrwren> are you looking for a new job?
[15:41] <ColonelPanic001> no, despite my whining right now, I love working here
[15:41] <jrwren> WSU IT, right?
[15:41] <ColonelPanic001> yeah
[15:42] <jrwren> do you know Glen ?
[15:42] <ColonelPanic001> same group as _stink_, actually
[15:42] <ColonelPanic001> maybe
[15:42] <ColonelPanic001> Wasik, I think his last name is?
[15:42] <jrwren> does Banner stuff? I worked with him at Oakland 10 yrs ago.
[15:42] <jrwren> yes, I think that is his last name.
[15:42] <ColonelPanic001> yeah, not well, but we've met
[15:42] <ColonelPanic001> seems like a nice guy
[15:42] <jrwren> he is.
[15:42] <jrwren> what kind of IT systems do you do at WSU ?
[15:43] <jrwren> do they still do mirapoint email?
[15:44] <ColonelPanic001> I, in particular, wrote the Android app for the uni, and now spend all my time getting a Magento installation working
[15:44] <ColonelPanic001> and yeah, I think so. Merit's email, with Zimbra for the web interface
[15:44] <jrwren> wtf is magento?
[15:44] <ColonelPanic001> ecommerce site thing. PHP written with Zend Framework
[15:45] <jrwren> wtf does wsu need with an ecommerce platform?
[15:45] <ColonelPanic001> we sell stuff.
[15:45] <ColonelPanic001> on the internets
[15:46] <jrwren> athletics?
[15:46] <ColonelPanic001> software clearinghouse, WSU Press, events, etc
[15:46] <ColonelPanic001> Athletics is another one, yeah
[15:46] <jrwren> interesting!
[15:46] <ColonelPanic001> Institute of Gerontology is looking to sell spots at ongoing learning events, etc
[15:46] <ColonelPanic001> mostly very small stores (not all, but mostly), but before we'd do all these one-off things for them, and that was just annoying. This is before I got here, so couldn't speak from experience
[15:47] <ColonelPanic001> so now we can start up a new store in like, minutes, and just say "here, use this" and they can self-manage it
[15:47] <ColonelPanic001> that's the goal anyway, and so far it seems pretty feasible
[15:48] <ColonelPanic001> I know the Press seemed to fall in love with it when they saw it. They're looking for a new place to sell subscriptions and issues of their journals, and when they got to playing with it, started talking about just moving everything to it.
[15:49] <ColonelPanic001> but I know what you mean, when it was first mentioned to me, I wondered if it was really worth the investment, too. But, now that it's coming up, departments are coming out of thw woodwork with stuff they might like to use it for, now that it's here.
[15:51] <_stink_> ColonelPanic001: don't incriminate me
[15:52] <ColonelPanic001> too late, CRM-boy
[15:52] <ColonelPanic001> he maintains our relationships.
[15:52] <_stink_> <3
[15:52] <ColonelPanic001> makes them more intimate
[15:54] <ColonelPanic001> he sends the Dear John letters to people that fail out.
[16:02] <rick_h> hah, geeked about lightbulbs. Crazy http://arstechnica.com/gadgets/2012/11/in-living-color-ars-reviews-the-hacker-approved-philips-hue-leds/
[16:49] <snap-l> I'm not sure how you folks deal with sick kids.
[16:50] <snap-l> I swear, JoDee and I are going to enter into a suicide pact if Pixel doesn't get better soon
[16:51] <brousch> It can be rough
[16:52] <brousch> When they are sick and pitiful and there's nothing you can do but snuggle
[16:53] <snap-l> It's hard to snuggle her when she's under the bed.
[16:54] <snap-l> I think we're going to need to teach her how to communicate better with us humans
[16:55] <rick_h> good luck
[16:59] <snap-l> hh
[16:59] <snap-l> heh
[17:09] <greg-g> is this an elaborate troll? http://arstechnica.com/business/2012/11/how-goatse-cx-went-from-shock-site-to-webmail-service/
[17:12] <rick_h> greg-g: honeypot ftw
[17:32] <rick_h> http://de2.eu.apcdn.com/full/89181.png
[17:48] <snap-l> rick_h: lol
[18:17] <snap-l> New CoC is up for signing
[18:17] <snap-l> (And no, that's not Call of Cthulhu, Corrosion of Conformity, or god knows what else has that acronym)
[18:17] <snap-l> https://launchpad.net/codeofconduct
[18:18] <rick_h> I know, I deployed it :P
[18:18] <snap-l> The current version is 2.0, released 2005-04-11
[18:18] <rick_h> lol, well I didn't say I wrote it?
[18:18]  * rick_h runs and hides
[18:18] <brousch> If I don't sign it can I be politically incorrect?
[18:19] <snap-l> brousch: Nope, you already signed one, so you must be on your best behavior
[18:19] <brousch> dangitalltoheck
[18:19] <snap-l> or you can un-sign it, but then we get to shun you.
[18:19] <snap-l> Actually, we might just shun you anyway, just for grins.
[18:20] <brousch> That might be good for me. Last night I dreamt of Federated Wiki
[18:20] <snap-l> Commence the shun-o-tron 5000
[18:20] <brousch> And in the dream I remember thinking "OMG, greg-g and snap-l are going to love this!"
 I just like the saying
[18:28] <snap-l> Just FYI: Paleo is rather bunk if you think it actually dates back to diets from the paleozoic era
[18:28] <snap-l> if you want to eat meat and cut carbs, call it a low carb diet.
[18:28] <snap-l> But thinking you're some form of neo-caveman dietician is rubbish. :)
[18:28] <snap-l> here endeth the skeptic
[18:28] <greg-g> snap-l: I think you're making a lot of assumptions about what I eat with that statement
[18:28] <_stink_> i had to look that term up, heh
[18:29] <_stink_> you eat wooly mammoth?
[18:29] <snap-l> greg-g: I figure you're more careful about what you put in your mouth tan most
[18:29] <greg-g> _stink_: you wouldn't believe the farmers markets here in SF!
[18:29] <_stink_> hahah
[18:29] <snap-l> Just the term paleo really gets my goat and offers it up for sacrifice.
[18:30] <_stink_> or goat stew.  with no flour.
[18:30] <greg-g> snap-l: you're sometimes too easily offended by what other people do ;)
[18:30] <snap-l> greg-g: You're damn right I am. ;)
[18:31] <brousch> I am offended by how easily offended you are
[18:31] <snap-l> greg-g: I just have a real difficult time with fad diets, of which paleo is the latest in a long line
[18:32] <snap-l> I attribute some of the complications in my uncle's diabetes with the Atkins Diet he was on
[18:32] <greg-g> alright, time to do last minute stupidness for this webinar bs
[18:32] <snap-l> No proof, mind you, so I have nothing to base this on
[18:33] <greg-g> atkins was shit, any diet from one single book sold in the self help section is shit, but, that doesn't mean that the research I have done re my food intake is any less valid just because I use a term that is easily recognizable to refer to a certain set of guidelines. "What Greg has decided to eat after reading a lot and pooping a lot" is'nt the best name for my diet (diet, here, is the definition number 1: what you eat.)
[18:34] <jrwren> atkins should be good for diabetes. it wasn't for him?
[18:35] <snap-l> greg-g: I'm sure you researched this. You're one of the more careful folks about figuring out what's edible
[18:36] <snap-l> hell, you ate stuff from the weed-pile we loosely call a garden. :)
[18:37] <snap-l> jrwren: I've heard that anecdotally, but I'm not sure.
[18:38] <jrwren> type2 i assume?
[18:39] <snap-l> He's having trouble with his eyesight, yes.
[20:16] <brousch> snap-l: Your prayers have been answered! http://www.lazytruth.com/
[20:17] <snap-l> Now I need one for Hotmail. ;)
[20:17] <snap-l> But this is a good start in the right direction
[20:22] <user-12345> Hi Group, I am new to linux. I got a question about. Create a new group Called mygroup. Hint: / usr/ sbin/ groupadd.
[20:23] <user-12345> My friend is trying to this, but getting error msg
[20:23] <user-12345> permission denied
[20:23] <user-12345> any clue?
[20:23] <brousch> sudo groupadd
[20:24] <_stink_> i think people typically use the addgroup, though
[20:24] <_stink_> it's a bit friendlier
[20:24] <brousch> I always do sudo adduser group
[20:24] <brousch> But lack of sudo is probably the issue here
[20:25] <greg-g> snap-l: hehe, that was fun (eating stuff out of your uhhh, backyard) ;)
[20:26] <brousch> That sounds dirty
[20:26] <greg-g> to YOU
[20:27] <brousch> You're the one putting the suspicious uhhh in there
[20:28] <brousch> So I have to try to find out what you are insinuating
[20:29] <user-12345> THank you, will ask to try that
[20:34] <greg-g> oh man, I'm the worst ambassador now
[20:35] <brousch> Ambassador to what?
[20:35] <greg-g> this channel
[20:36] <greg-g> I used to be so good at welcoming and not encouraging off-color jokes when new people were here
[20:38] <snap-l> greg-g: That's why we banished you to California. :)
[20:39] <snap-l> user-12345: Welcome, BTW. :)
[20:54] <greg-g> heh, the best way to say GNU/Linux on a CD: http://penguin-pete.tumblr.com/post/36083435184/and-it-isnt-produced-by-murderers-like-mcafee
[20:55] <brousch> nice
[21:05] <jrwren> just contributed to by murderers like Hans Rieser
[21:05] <greg-g> jrwren: he mentions that :)
[21:07] <brousch> Did you see the blog by Mcaffee?
[21:08] <brousch> http://www.whoismcafee.com/
[21:11] <jrwren> oh, lol, how did I miss that.
[21:11] <greg-g> wait, what, that's real?!
[21:12] <jrwren> https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tree;f=fs/reiserfs;h=37c1da6b2c3ee2da3e0a71aee4d3578b555f0593;hb=f4a75d2eb7b1e2206094b901be09adb31ba63681  <-- not out of the repositories or default kernel.
[21:12] <snap-l> Y'know, I'd rather McAffee wasn't tried by the media before he gets even questioned.
[21:13] <jrwren> snap-l: we are teh masses, its what we do.  Assange too
[21:13] <snap-l> Precisely.
[21:13] <snap-l> That's why we have courts, and not lynch-mobs
[21:14] <snap-l> Hah, the Republic Wireless pre-order is now up
[21:14] <snap-l> Too bad Ting got me first. :)
[21:16] <snap-l> Ah, forgot, McAfee isn't in the US.
[21:17] <snap-l> Something tells me this is going to get much, much weirder.
[21:19] <jrwren> i wonder who he pissed off to frame him.
[21:20] <jrwren> i wonder if anonymous will take sides and attack the belizian gvment
[21:20] <brousch> jrwren: It's all on the blog
[21:21] <brousch> Apparently he pissed off the Belizian president
[21:21] <jrwren> nice.
[21:28] <greg-g> brousch: huh (re Synder's edu reform article)
[21:29] <greg-g> the one part I'm not sure of is getting rid of summer vacation!
[21:29] <greg-g> oh, right, that was on twitter....
[21:31] <brousch> summer vacation is useless
[21:31] <brousch> It's for farmers
[21:32] <greg-g> that's the POINT
[21:32] <brousch> Kids sit around playing video games at home all day
[21:32] <greg-g> (not the farmers, it being useless)
[21:32] <greg-g> yeah, and..... ;)
[21:32] <snap-l> Big problem is the funding for schools will get distributed so only a handful of schools will get all of the money
[21:33] <greg-g> actually, I see your point, I'm mostly joking, I just have great memories of summer camping trips
[21:33] <brousch> There is still a lot of time off, it's just spread out more
[21:33] <snap-l> I can see some districts getting completely shut out
[21:34] <brousch> Yeah, I'm as sure about the funding part
[21:34] <greg-g> brousch: can you be my lazyweb and find me a url of the actual proposal?
[21:34] <snap-l> Of course it'll get spun that the teachers are so wedded to summer vacation, and pretty much gloss over the funding
[21:34] <brousch> greg-g: It's a report, so I don't know if they published it
[21:34] <greg-g> ah
[21:35] <snap-l> And it's wxyz, so lord knows what it actually says. ;)
[21:35] <greg-g> hahaha
[21:35] <greg-g> I just saw the teaser for "Why would anyone want to give money to a politician, but keep it a secret?
[21:35] <snap-l> TV news = crap.
[21:35] <greg-g> Read more: http://www.wxyz.com/dpp/news/governor-snyder-report-proposes-michigan-education-overhaul#ixzz2Chsv1s60
[21:35] <greg-g> FUCK YOU FUCKING COPY/PASTE BUFFER MODIFYING JAVASCRIPT
[21:36] <greg-g> that shit is everywhere on news sites
[21:36] <greg-g> thanks for annoying your fucking users, assholes
[21:36]  * greg-g is especially annoyed by this stuff because it is sold as a snake oil as a way to "track use and reuse of CC licensed materials"
[21:36] <brousch> hehehe
[21:37] <snap-l> greg-g: You mean the pop-up ads for monkey-punching give us your gold we'll turn it into chocolate aren't enough of a nut-kicker?
[21:37] <greg-g> snap-l: I have adblock for that :)
[21:37] <greg-g> some javascript is good, though, so I don't want to block it all by default :/
[21:37] <snap-l> It's the only way I'll head to the Detroit News. (adblock)
[21:37] <brousch> Better one from wdiv http://www.myfoxdetroit.com/story/20139266/mich-plan-would-give-money-for-early-graduation
[21:38] <snap-l> I went to detnews without adblock on my parents machine, and my ees bled.
[21:38] <snap-l> eyes, even
[21:38] <snap-l> brousch: That's WJBK
[21:38] <jrwren> NOSCRIPT block it all by default, allow per site as necessary.
[21:38] <snap-l> WDIV is "clickondetroit"
[21:38] <brousch> blah, whatever
[21:40] <snap-l> Also, love detnews, or "what the current pro sports team and college teams are doing, mixed with auto news"
[21:40] <brousch> greg-g: Links to drafts of the bill here http://oxfordfoundationmi.com/michigan-education-finance-act-updates/michigan-public-education-finance-project-draft/
[21:40] <snap-l> as opposed to the Freep, which is "what the current pro sports team and college teams are doing, mixed with Mitch Albom pretending he's a profound writer"
[21:41] <greg-g> brousch: thanks man!
[21:44] <jrwren> pretty sure many days on new york times best seller list means he is a well sold writer, not a profound writer.
[21:44] <jrwren> although having read a book by him, its obvious he is trying for profound :)
[21:44] <snap-l> jrwren: There's a lot of bleed-over into his column
[21:45]  * snap-l wonders if he could get on the NY Times best seller list for "the book of shit"
[21:46] <snap-l> and get some gigs on talk shows talking about "the book of shit"
[21:46] <brousch> yes
[21:46] <snap-l> What is it about?


[07:12] <dholbach> good morning
[09:32] <Laney> hiya
[09:32] <nigelb> ohai Laney :)
[09:32] <Laney> alright?
[09:33] <nigelb> Yep, you?
[09:36] <Laney> aye
[09:36] <Laney> we're in the middle of a mini heatwave
[09:36] <Laney> which is always nice
[09:37] <nigelb> Oh, heat wave here as well, but I won't call that nice ;)
[10:18] <Laney> apparently we're in for a very cold autumn/winter, so I'll take it while it lasts...
[10:26] <iulian> Laney: Exactly what I was about to say.
[10:26]  * Laney knits iulian a jumper
[10:27] <iulian> Oh, thanks. :)
[10:27] <tumbleweed> and we've just had a couple of cold nights. Can't wait for summer (even though I know I'll be cursing the heat)
[11:42] <ScottSanbar> hi
[15:46] <jariq> i've accidentally deleted urls in my apt.conf could someone please provide me one?
[15:46] <jariq> default one would be great
[15:48] <jariq> just found http://en.archive.ubuntu.com/ubuntu/ thx for support :)
[16:28] <lfaraone> persia: ping
[16:46] <Chat2389> heeey


[00:09] <poolie> hi all
[00:17] <mathrick> hiya poolie
[00:17] <mathrick> poolie: <mathrick> re: bug #838469, should improvements to mini-tutorial be submitted for released versions as well, or will they only be accepted for bzr.dev?
[00:19] <poolie> hi mathrick
[00:20] <poolie> we can take doc updates for released versions
[00:22] <mathrick> poolie: great, should I then make a patch against the 2.4 braching point, or should I rebase it, or should it rather be cherry-picked for release branches?
[00:23] <poolie> just do a revision based off lp:bzr/2.4 tip
[00:23] <mathrick> OK
[06:19] <vila> hi all ! Happy Friday !
[06:20] <AuroraBorealis> yay
[06:54] <jam> morning all
[07:28] <jbicha> hi, is there already a bug open for bzr-builddeb's lack of support for .tar.xz? that's going to be especially annoying since GNOME 3.3 won't ship other tarballs
[07:35] <mgz> morning all
[07:58] <poolie> jam, hi - you're feisty today! :)
[08:25] <jam> mgz: I have some ideas about bug #869366, are you looking at it, or just reporting it for posterity?
[08:25] <ubot5`> Launchpad bug 869366 in Bazaar "TestTCPServerInAThread.test_server_crash_while_responding random failure" [Medium,Confirmed] https://launchpad.net/bugs/869366
[08:25] <mgz> just reporting, as I ran into it EOD yesterday
[08:25] <mgz> I seem to be getting lucky with random failures on PQM
[08:29] <mgz> looking at the test, it seems possible for the subthread to not do any futher work after the sync
[08:32] <vila> mgz: yes, that's the race I was mentioning the other day, the same one exists for the test just above, it triggers very rarely and it took quite a while to put my finger on it
[08:33] <vila> mgz: the main thread really want to wait for both the connection thread to raise the exception *and* to the server thread to re-raise it
[08:33] <mgz> I'm not even sure what tools python gives us to resolve such problems
[08:34] <mgz> I guess in this case try:/raise/finally:/sync2 would work?
[08:35] <mgz> because the exception won't propogate until the test looks for it?
[08:35] <vila> mgz: the test looks for the exception to be swallowed :)
[08:35] <jam> mgz: for that particular test, you could call 'server.stop_server()" instead of "server.pending_exception()"
[08:35] <vila> mgz:  the previous test (test_server_crash_while_responding) looks for the exception
[08:35] <jam> stop can be called twice
[08:35] <jam> and that way it will have joined its threads
[08:36] <vila> which is not what the test is about: test_exception_swallowed_while_serving
[08:37] <vila> this a test about the server not about the client
[08:39] <vila> we don't want the server to shut down, we want it to keep serving (swallowed_while_serving)
[08:39] <jam> vila: that is the other test
[08:39] <jam> "test_server_crash_while_responding" wants it to raise the exception
[08:39] <jam> we can just change pending_exception to stop_server and it will sync with the clients
[08:39] <jam> client threads
[08:40] <jam> maybe connection threads is a better term
[08:40] <jam> though I guess that doesn't make the tests symmetric except for the exception being ignored.
[08:42] <vila> with 'that' == test_server_crash_while_responding, this test is about crashing the server, not shutting it down
[08:42] <vila> pending_exception is what is used to implement shutting down
[08:43] <vila> which illustrate why I disagreed with your modifications which were about client behavior and as such replacing these tests instead of adding your owns
[08:44] <vila> bug mgz encounters the issue in 2.4 so your modifications are out of scope here
[08:45] <vila> mgz: by the way, thanks for filing that bug, I thought I did as this failure has been seen on babune on several occasions (rare enough to not trigger a fix)
[08:45] <mgz> hm yes, I might not have said that in big enough letters in the bug, but this was a landing on the 2.4 branch
[08:46] <vila> mgz: ... and *never* triggered on pqm AFAIK... before you claimed the unlucky badge :)
[08:49] <mgz> two different random failures in about four landings on 2.4 PQM is pretty good going
[08:49] <vila> mgz: yup, don't let them go ! :)
[08:50] <mgz> oh hey, looking at babune, lucid is red
[08:50] <mgz> and guess what the failing test is :)
[08:50] <vila> mgz: but can we assume the cause is the same now that the test is not ?
[08:51] <mgz> ...one thing going for testtools is seeing both tracebacks makes this miles clearer
[08:51] <mgz> vila: if there's still just the one sync before the raise, then yes I think
[08:54] <vila> mgz: I was kidding ;) test_server_fails_while_serving_or_stopping shouldn't suffer from the same race because it explicitly call stop_server I think...
[08:54] <poolie> hi mgz, vila
[08:54] <vila> helli pooloe
[08:54] <vila> meh
[08:54] <vila> hello poolie ;)
[08:55] <mgz> hellipolis?
[09:02] <vila> mgz: so the ' Wait for the exception to propagate' is a lie, it waits for the exception to be 'about to be raised' and just doing 'sync.wait()' is not enough to guarantee that. That's where the race is. A possible fix will be to connect with another client and get served properly (i.e. yes, the server is still up and running)
[09:02] <vila> mgz: trying to be more precise would require hooking somewhere the server really swallows
[09:12] <vila> mgz: hehe, but that's in fact required as this test server cannot server properly (by test design :)
[09:37] <AuroraBorealis> is there a way to force bzr to use its built in ssh rather then another ssh that is on the path?
[09:38] <AuroraBorealis> (installed git, and of course it has an ssh.exe that causes bzr to just hang for some reason)
[09:39] <jam> AuroraBorealis: "export BZR_SSH=paramiko"
[09:39] <AuroraBorealis> where do i put that if i'm on windows?
[09:39] <jam> if you're on Windows it is spelled
[09:39] <jam> set BZR_SSH=paramiko
[09:39] <jam> but you can set it in global env vars
[09:39] <jam> right click My Computer, Properties, Advanced System Settings, Environment Variables
[09:40] <AuroraBorealis> ah kk
[09:40] <AuroraBorealis> user or system variable, does it matter?
[09:42] <jam> AuroraBorealis: doesn't matter for you
[09:42] <jam> depends if you have more than one user on the machine
[09:42] <AuroraBorealis> but python getenv can access both ?
[09:43] <AuroraBorealis> (guess just a python question now =P )
[09:45] <mgz> bug 641330 is the shelve issue
[09:45] <ubot5`> Launchpad bug 641330 in Bazaar "unable to unshelve shelved root-id change" [Medium,Confirmed] https://launchpad.net/bugs/641330
[09:45] <mgz> bug 82555 looks like the root cause
[09:45] <ubot5`> Launchpad bug 82555 in Bazaar "Merging to an empty branch doesn't work" [High,Confirmed] https://launchpad.net/bugs/82555
[09:46] <mgz> bug 242175 is the mitigation for that Riddell added for the merge case
[09:46] <ubot5`> Launchpad bug 242175 in Bazaar "ValueError: WorkingTree.set_root_id with fileid=None when merging into empty branch" [High,Fix released] https://launchpad.net/bugs/242175
[09:48] <mgz> AuroraBorealis: windows merges them before starting a process as your user
[09:48] <AuroraBorealis> k
[10:15] <AfC> Do bzr-builddeb's `import-upstream` and bzrtools's `import` use the same change detection / file-id (ie, file checksum, perhaps) algorithms?
[10:16] <AfC> (anyone know?)
[10:16] <AuroraBorealis> not me :>
[10:17] <jelmer> AfC: hi
[10:17] <jelmer> AfC: change against what?
[10:17] <AfC> jelmer: hi
[10:18] <AfC> jelmer: so, in both cases, there's considerable work done to detect (for example) renames, right?
[10:18] <AfC> [so I infer]
[10:18] <jelmer> AfC: no, no renames are inferred in either case as far as I know
[10:18] <AfC> oh
[10:19] <jelmer> I could be wrong, I don't have much experience with either
[10:19] <jelmer> actually, "bzr import" could help
[10:19] <jelmer> since it doesn't commit
[10:19] <jelmer> so you can do "bzr import ..; bzr mv --auto; bzr ci -m 'import x'"
[10:19] <AfC> jelmer: ok, well, it's doing *something* for the minutes of CPU time its sitting there burning away
[10:19] <AfC> mv --auto, yeah, that might be interesting
[10:20] <jelmer> AfC: which one is burning CPU? import or import-upstream?
[10:20] <AfC> [both]
[10:20] <AfC> I just now did an import; import-upstream was taking ~9 minutes each.
[10:20] <jelmer> AfC: what are you importing?
[10:20] <AfC> :)
[10:21] <AfC> that large well known project prominently using someone else's version control system that I've been blundering along with this p
[10:21] <AfC> past week
[10:22] <AuroraBorealis> if its git, we are already seeing that fast-import or whatever is taking huge amounts of time / memory.
[10:23] <AfC> AuroraBorealis: so I'm not working with bzr-git in this case; I've instead used bzr-builddeb's facilities against the upstream project's release tarballs.
[10:23] <AuroraBorealis> ah
[10:23] <jelmer> AfC: I don't think either import or import-upstream have been optimized for kernel-sized trees..
[10:24] <jelmer> AfC: any particular reason you're not using the launchpad imports, or are you just seeing how far you can get?
[10:24] <AfC> jelmer: that's ok, I'm not bitching about import performance per se
[10:24] <AfC> jelmer: so, having established the deterministic behaviour, I tried the lp imports branch
[10:25] <AfC> jelmer: but I kept getting swap thrash. I'm sure I'll be able to make use of it at some point, though
[10:26] <jelmer> AfC: you're getting swapping trash even just running "bzr branch lp:linux linux" ?
[10:28] <AfC> yeah
[10:28] <AfC> [anyway, that's done, I let it run overnight or whatever]
[10:28] <jelmer> AfC: what version of bzr are you running?
[10:28] <AfC> jelmer: daily
[10:28] <AuroraBorealis> is lp:linux already a bazaar repo?
[10:28] <AfC> yes
[10:29] <AfC> AuroraBorealis: ^
[10:30] <AuroraBorealis> weird that its thrashing when its just branching.
[10:30] <AfC> it just took a long time; it was quite a few days ago; I've had bigger problems since then doing other stuff, but as I said, it's here now should I need it.
[10:31] <AfC> bzr tags
[10:31] <AuroraBorealis> might be related to the uhh
[10:31] <AuroraBorealis> bug i'm having when importing the git linux repo
[10:32] <AuroraBorealis> where its using so much memory (therefore thrashing if you don't have enough ram) cause its keeping the entire history in memory
[10:35] <jelmer> AuroraBorealis: where are you getting that? using bzr-git, bzr-fastimport, regular clone?
[10:36] <jelmer> none of them should really be  keeping all history in RAM
[10:37] <AuroraBorealis> https://bugs.launchpad.net/bugs/864217
[10:37] <ubot5`> Ubuntu bug 864217 in Bazaar "MemoryError when repacking repository with large numbers of revisions " [Medium,Confirmed]
[10:37] <AuroraBorealis> doing fast-import of the git linux kernel uses about 2 gigs of memory , and it wasn't even done
[10:37] <AfC> jelmer: well it is attempting to keeping 3.0 GB of something in memory. This doesn't go down well :/
[10:39] <AuroraBorealis> and mgz said something about it was keeping history in memory
[10:39] <AfC> jelmer: (this was even with bzr branch -r 1 URL; I never could get it to finish with -r > 100)
[10:40] <AfC> (I imagine looping one revision at a time over n days would have worked out, but having established it was deterministic and didn't have missing revision relative to the lp import, I knew I could trust that)
[10:46] <jelmer> AfC: did you see the bug I filed earlier about -r1 not actually doing that?
[10:48] <mgz> jelmer: from a (partial) memdump AuroraBorealis had from fast-import, there was a _KnownGraph taking up a bg chunk of memory
[10:48] <mgz> that may well be a bug, there's a _known_heads cache dict that seems essentially unbounded
[10:49] <mgz> it only ever gets cleared on a couple of error paths
[10:49] <AuroraBorealis> have you worked on meliae not actually dumping all the objects?
[10:49] <AuroraBorealis> so we can see more of whats in the dumps?
[10:49] <mgz> nope, but I've got that down as a project for this weekend
[10:50] <AuroraBorealis> kk
[10:51] <AuroraBorealis> i should be around, although you seem to be on the other side of the world from me so hours will be interesting =P
[10:52] <mgz> on Monday I saw a reproducable segfault, some type errors, and the issue with missing objects causing the dump to not load
[10:53] <mgz> fixing all those should get us somewhere, but the incomplete dump may still be a win64 size/alignment issue which will be a pain to work out from here
[10:53] <AuroraBorealis> oh gee ;<
[10:53] <AuroraBorealis> do you have access to a win64 computer?
[10:53] <mgz> no, that's the fun bit :)
[10:54] <mgz> the code has the wrong size of all the pointer->int casts though, so there's some hope I can just fix things till it magically works
[10:57] <AuroraBorealis> i'll mail you my crappy 500 dollar laptop with windows 7 64 bit on it thats collecting dust behind me
[11:00] <AfC> jelmer: no, I didn't; I'll look
[11:00] <mgz> where on the other side of the world are you AuroraBorealis? :)
[11:00] <AuroraBorealis> arizona, usa
[11:01] <AfC> I would have thought you would have to go a bit further north than that to see the aurora borealis. Unless we just got spanked by a giant gamma ray burst...
[11:02] <fullermd> Plate tectonics.  Just takes a little longer.
[11:02] <AfC> ah, yes, of course :)
[11:03] <AuroraBorealis> yes
[11:03] <fullermd> ('course, it does make you wonder what kinda nutcase would be in AZ, awake, and on IRC at this hour   :p)
[11:03] <AfC> [I only ever saw it once. I was rather far up, as I recall. Was pretty]
[11:03] <AuroraBorealis> the nutcase who was procostinating on his small prolog assignment
[11:03]  * mgz thinks fullermd isn't one to talk
[11:03] <fullermd> Saying 'prolog' isn't helping your case!
[11:04] <AuroraBorealis> haha
[11:04] <fullermd> Hey, I'm a solid hour ahead of him.  That makes me totally sane.
[11:07] <AuroraBorealis> haha
[11:11] <AuroraBorealis> anyway, bed time for me. school in a few hours
[11:11] <AuroraBorealis> chat with you this weekend i guess mgz
[16:05] <jml> james_w: would you mind merging my branch?
[16:10] <james_w> sure thing
[16:28] <vila> jml, james_w : sry about that, I planned to do it but get interrupted longer than expected
[16:29] <jml> vila: np
[19:22] <sponge-> is there a way to do a sparse/bare checkout in bzr? in svn i'd do --depth immediates and then svn up --set-depth infinity on the folders i wanted, looking for something similar
[20:19] <elmo> when merging someone else's branch, should I commit, then do fix ups, or can I merge, fix + commit result and still be able to usefully differieniate the two sets of changes?
[20:36] <lifeless> elmo: difftastic/difftacular - I never remember the name - can untangle them for you
[20:37] <lifeless> so sure, do whatever ;)
[21:45] <wgz> lifeless: can I pester you for your thoughts on bug 866107 at some point?
[21:48] <lifeless> sure, not right now sadly
[21:48] <wgz> I shall ping again over the weekend at some point.
[21:53] <wgz> and in other news, I have once again made PQM fail in some weird way
[21:53] <wgz> this time... all the tests pass but...
[21:54] <wgz> star-merge succeeded at Fri Oct  7 16:26:04 2011 (0:24:02.142211)
[21:54] <wgz> 'Exception processing merge: [Errno 2] No such file or directory'
[21:55] <vila> O.o
[21:56] <wgz> stderr has the slightly suspicious:
[21:56] <wgz> Fri Oct 7 16:02:43 UTC 2011 : selftest starts
[21:56] <wgz> failed to open trace file: [Errno 13] Permission denied: '/you-should-use-TestCaseInTempDir-if-you-need-a-log-file'
[21:56] <wgz> Fri Oct 7 16:26:01 UTC 2011 : selftest ends
[21:56] <wgz> but there's no mention of a test with that issue in the test suite output
[21:58] <hazmat> is there a cli command to get the latest revid out of a repo... ie. analogue of revno?
[21:58] <vila> red herring, it's a leak somewhere, has been there for ages
[21:58] <vila> wgz: ^
[21:58] <wgz> okay, so it's the merge failing somehow that's the issue
[21:58] <wgz> but... after all the tests run, which is just weird
[21:59] <vila> wgz: more precisely some TestCase should be a TestCaseInTemp... err, yeah, that's what the path says ;)
[21:59] <wgz> hazmat: `bzr revision-info`?
[21:59] <vila> wgz: could be related to the issue with the lack of mails to bazaar-commits
[22:00] <wgz> I'll post to the mp so MvG knows I'm not just holding out on him.
[22:03] <lifeless> wgz: anyhow, testresources is good; I plan to supercede its model with testfixtures once I or someone else implements a fixture graph with reasonable introspection semantics (such that you can do the testresources planning on unsetup fixtures)
[22:12] <wgz> lifeless: do you have any particular opinions about what bzr needs on this front?
[22:12] <lifeless> wgz: I'd write your stuff as fixtures and use a shallow fixture->resource-manager shim
[22:13] <lifeless> as I don't expect you to need deep route planning, merely aggregation of all the tests using a given external server
[22:14] <wgz> one part of your fixtures readme really confused me
[22:15] <wgz> resources had a clear part about dependent resources
[22:15] <hazmat> wgz, perfect thanks.. didn't show up on a bzr help commands | grep rev
[22:15] <wgz> whereas fixtures had a long example about how you couldn't share a tempdir if there were also a db and a webserver
[22:16] <wgz> which... I didn't get at all
[22:17] <lifeless> fixtures is a simpler model
[22:18] <wgz> but that seems simpler to the point of not being useful
[22:18] <lifeless> fixtures has seen more use in less time
[22:18] <lifeless> this is one of the paradoxes of design :)
[22:18] <wgz> if I can't share the tempdir created by TestCaseInTempDir (with some added carefulness in reset), I can't build any other fixtures of use on top of it
[22:19] <lifeless> of course you can, if you want to
[22:19] <wgz> nearly everything thats expensive enough to want to share between tests first derives from TestCaseInTempDir
[22:20] <wgz> does testresources basically get around this by running all webserver tests together, then all db tests, and if it can't do that tearing down the lot between?
[22:22] <lifeless> well back up a step
[22:22] <lifeless> I think you have some conflation
[22:22] <wgz> this is likely.
[22:22] <lifeless> TestCaseInTempDir using unique temp dirs for each test case
[22:22] <wgz> it shares a ROOT_DIR
[22:22] <wgz> this is a bad thing, because it's global state
[22:22] <lifeless> yes
[22:22] <lifeless> its something we were working to nuke
[22:23] <wgz> this is something I'd like to nuke with one of your nice packages :)
[22:23] <lifeless> anyhow, fixtures describes an extended context manager basically
[22:23] <lifeless> which happens to be very useful for tests because it exposes things like getDetails
[22:23] <lifeless> and a convenient addCleanup for the code within it.
[22:24] <lifeless> testresources describes an optimisation framework for expensive things; each of which could be a fixture (but needs a graph which fixtures doesn't expose)
[22:25] <lifeless> the fixtures README talks about using just fixtures in similar situations to what testresources is targeted at - and in that world its kludgy, because of the lack of an introspectable graph
[22:25] <lifeless> (you can't tell that the webserver and db are going to be using the same temp dir, and you can
[22:26] <lifeless> 't (if they use addFixture) cleanup just the webserver or just the db, because that will implicitly cleanup the tempdir, hurting the other user
[22:26] <lifeless> so
[22:26] <lifeless> this is why I was saying to use testresources, but write the resources as a manager shimming across to a fixture
[22:26] <lifeless> now, as far as test dir reuse, I think you want an external server to have the following properties:
[22:28] <lifeless>  - totally decoupled from the test process
[22:28] <lifeless>  - but managed by it
[22:29] <lifeless> so I don't think you want testcaseintempdir to have anything to do with the server
[22:29] <lifeless> just have the server make its own temp dir, for its logs etc, and each test case can tell the server where the test case is rooted etc
[22:29] <wgz> well, often the tests that need a server have their own local branch for the client
[22:29] <wgz> which then chats to the server
[22:29] <wgz> so, it would have a server resource, and some other resources for the actual test
[22:30] <lifeless> definitely a server resource, but unless you intend to share the other resources, they don't need to be exposed to testresources
[22:30] <wgz> I think it would be worth sharing the safe-contain-in-filesystem infrastructure
[22:31] <lifeless> and can be just fixtures (which bzr already uses though without using the library)
[22:31] <wgz> the branch and trying to escape test isolation stuff
[22:31] <wgz> which is basically just some state on disk, that doesn't change unless something goes wrong (and could then be reset)
[22:31] <lifeless> sure
[22:32] <wgz> fixtures does have the advantage of not needing the actual package
[22:32] <wgz> and bzr may not really need the fancy graph stuff
[22:32] <lifeless> I think bzr should use the packages :)
[22:32] <lifeless> the fixtures package has very useful helpers
[22:32] <wgz> the existing test arrangements may be enough without whole test suite reordering
[22:32] <wgz> as much as I like your graph code :)
[22:32] <lifeless> and the testresources graph stuff will be needed if you want a single reused server for each of the server types
[22:33] <wgz> well, we really only need it shared 'enough'
[22:33] <lifeless> bzr tests are currently totally isolated except for the safety mechanisms
[22:33] <lifeless> wgz: I -really- wouldn't do 'enough' - do it right, don't NIH
[22:33] <wgz> starting a new one per module rather than per test method is still a win.
[22:34] <lifeless> wgz: with the in-test servers, thats not at all clear when compared to an out of test server
[22:34] <lifeless> wgz: starting in-test servers is pretty darn cheap
[22:35] <wgz> yeah, I feel very fearful of the NIH, but I'm also wondering if I'm going to need as much plumbing as doing something dumb like that would be anyway
[22:38] <wgz> I think I actually like the testresources api better (except for that ugly hack you have at the bottom to sniff out a TestResult), but if leaning towards fixtures I guess I need to work out how they could actually be used instead
[22:39] <wgz> ...I don't really like context managers with unittest, doesn't fit with the seperate methods for setup/teardown style
[22:40] <wgz> +you
[22:40] <wgz> in one of those malformed sentences somewhere
[22:42] <wgz> okay, thanks for your time lifeless, I'll try some things out and see where I get
[22:44] <lifeless> wgz: so my point was you need two things, you should use both of them
[22:45] <lifeless> testresources takes care of the ordering and external bringup-takedown aspects
[22:45] <lifeless> fixtures takes care of easy code for encapsulated services
[22:45] <lifeless> wgz: tearDown should be deleted, can't be for compat, but don't use it.


[17:34] -queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/4554 Proposed pocket (focal/python3-stdlib-extensions). Ready to build (focal/python3.10). UNAPPROVED queue (focal/python3.9)
[17:55] -queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/4554 Proposed pocket (focal/python3-stdlib-extensions, focal/python3.9). Ready to build (focal/python3.10)


[02:01] <beata|lemur> Howdy y'all. I'm following the Ubuntu kernel compile guides, checking out natty, running the 'debian/rules binary-$local' method, on AMD64 system. What I'd like to figure out how to do, is build for i386 on that same tree.
[02:02] <AceLan> beata|lemur: you need to setup chroot environment
[02:03] <beata|lemur> I presume, then, I can use the same build tree in the chroot?
[02:03] <AceLan> beata|lemur: https://wiki.ubuntu.com/Kernel/Action/BuildChroot
[02:04] <AceLan> beata|lemur: yes
[02:04] <beata|lemur> I'll read it up then, thanks.
[02:04] <AceLan> beata|lemur: no problem
[02:15] <psusi> I'm trying to chase down a kernel BUG I just ran into on natty in dput().  It does BUG_ON(inode->i_state & I_CLEAR);  this was tripped when removing a dmraid partition device ( linear mapping ).  what is I_CLEAR?
[02:24] <beata|lemur> *giggle* The last chroot experience I had was trying to build the natty kernel on hardy. That was..ugh..painful.
[02:25] <psusi> hrm... maybe a multiple free problem?  hrm...
[02:26]  * psusi sure is glad for make -j4
[02:28] <beata|lemur> Hey. I'm happy for auto-jobbing. We didn't have that back in 1999.
[02:38] <psusi> auto jobbing?
[02:39] <psusi> you know what we DID have in 1999 that we don't anymore?  a defrag package ;)
[02:39]  * psusi really needs to get that put back into the main archive, or at least universe
[02:43] <beata|lemur> *laugh*
[02:43] <beata|lemur> Oh dear. The chroot is grabbing over half a gig of archives.
[02:44] <beata|lemur> It wasn't that long ago I wouldn't have had space on the whole disk. ;)
[02:47] <ohsix> it's going to be much huger by the time it gets underway
[02:49] <beata|lemur> I can believe it.
[04:31] <beata|lemur> This chroot thing is a *lot* harder than I expected, even given the other one.
[08:21]  * apw yawns
[08:59] <apw> cking, moin
[08:59]  * smb returns
[09:00] <smb> apw, cking morning
[09:00] <apw> smb, and to you
[09:02] <cking> morning
[09:07] <abogani> morning all
[09:07] <smb> abogani, morning
[10:30] <apw> smb, bug
[10:30] <apw> bug #723066
[10:30] <ubot2> Launchpad bug 723066 in linux "[STAGING] ENE card reader fails with IO errors on streaming reads" [Medium,Triaged] https://launchpad.net/bugs/723066
[10:31] <smb> apw, ok, thanks. I will include that into the reply
[10:32] <apw> yeah, its pretty bust, we do not want it backported as it is for sure
[12:19] <herton> apw, there are two bugs which also will be fixed by latest rebase, bug 722689 and bug 722310
[12:19] <ubot2> Launchpad bug 722689 in linux "visual corruption of all screen after upgrading to <IP_ADDRESS>.18" [Undecided,Confirmed] https://launchpad.net/bugs/722689
[12:19] <ubot2> Launchpad bug 722310 in linux "Suspend fails due to tpm_tis: error -62 with kernel 2.6.38-4 (2.6.38-3 works)" [High,Triaged] https://launchpad.net/bugs/722310
[12:19] <herton> I asked the reporters to test with the fixes included and they confirmed
[13:09] <apw> herton, thanks, will make sure they are listed in the changelog  before i upload it
[14:57] <rsajdok> Where is the list of bugs to bug day?
[15:08] <apw> JFo, ^^
[15:09] <JFo> rsajdok, we are looking at all the new status bugs
[15:09] <JFo> I'll get you a link :)
[15:12] <JFo> rsajdok, http://goo.gl/f5CAz
[15:12] <JFo> that is the list of all kernel bugs in the new status
[15:12] <JFo> we'll be working from there
[15:23] <bjf> ##
[15:23] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:23] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[15:23] <bjf> ##
[15:26] <JFo> rsajdok, here is a better list http://goo.gl/2wO4A
[15:27] <tgardner> bjf, how about some CVE reviews so I can get them scraped off my list ?
[15:28] <bjf> tgardner, i'll add you to my list
[15:31] <tgardner> apw, your -rc5 kernel seems to be working well on emerald
[15:31] <apw> tgardner, excellent ... just finishing up the boot tests here ... will shove it shortly
[15:32] <tgardner> apw, one of the commit messages is wrong. it says -rc5 when it should say -rc6.
[15:33] <apw> doh will correct
[15:33] <tgardner> UBUNTU: v2.6.38-rc5 rebased fixes Bug #716811 ?
[15:33] <ubot2> Launchpad bug 716811 in linux "[SandyBridge] kernel BUG at /build/buildd/linux-2.6.38/fs/nfsd/nfs4state.c:3132!" [Undecided,Fix released] https://launchpad.net/bugs/716811
[15:33] <apw> tgardner, no that one is actually correct, it was an older bug
[15:33] <tgardner> although it may be correct
[15:33] <tgardner> ok
[15:33] <apw> just added it for completeness as i closed it out
[15:36] <tgardner> apw, the scheduler really seems to work well. even at 322 load average its fairly responsive on another SID
[15:36] <apw> tgardner, that is most in-credible
[15:50] <rsajdok> JFo: thanks
[15:50] <JFo> rsajdok, thank you :)
[15:53] <tgardner> apw, lemme know when you've pushed natty master so I can start the ti-omap-dev rebase.
[15:53] <apw> tgardner, it should be as you have, i have just pushed the tag
[15:54] <tgardner> apw, ack
[15:54] <apw> oh its not on master yet sorry
[15:54] <apw> will do that right now
[15:54] <apw> tgardner, ok done on master correctly
[15:55] <tgardner> apw, got it
[15:55]  * apw goes do the lucid ones
[16:01] <JFo> need cofee brb
[16:15] <kees> tgardner: seriously, can't we just remove debugfs?? http://seclists.org/oss-sec/2011/q1/229
[16:15] <kees> tgardner: it's horrible
[16:19] <tgardner> kees, IMHO its no worse then a regular sysfs. Its just that folks are paying less attention to debug interfaces. Perhaps we can get smb to agree to not mount it by default? We should also fix these holes.
[16:20] <kees> tgardner: sysfs has a regular interface, debugfs has become a dumping ground
[16:21]  * smb had no issues with not mounting it by default
[16:21] <tgardner> kees, well, maybe we can look at turning off the worst offenders (after fixing some of the permission problems)
[16:21] <kees> tgardner: we can also mount it somewhere that only root can get to
[16:22] <kees> tgardner: right, I want to keep the arbitrary memory writing interfaces totally gone (acpi/custom_method)
[16:22] <apw> kees, might that not be achieveable by just chanign permissions on the directory to be mounted on
[16:22] <kees> tgardner: but mostly this is just me pointing out yet more vulnerabilities in debugfs globally.
[16:22] <kees> apw: yup.
[16:22] <tgardner> kees, would mounting somewhere else be sufficient ?
[16:22] <tgardner> nm
[16:23] <apw> what mounts them up?  is that upstart
[16:23] <apw> i think it needs to use debugs
[16:23] <kees> tgardner: there are two classes of issue: root gaining arbitrary write (which we've fixed by dropping acpi/custom_method) and non-root messing with the system (for which there are tons of holes it seems)
[16:23] <apw> for its boot tracing
[16:23] <apw> so we might need to fix it there
[16:23] <kees> afaik, ureadahead and the dri debugging hooks need debugfs
[16:23] <kees> both should be running as root
[16:24] <sforshee> I think debugfs is also needed for perf, isn't it?
[16:24] <kees> none on /sys/kernel/debug type debugfs (rw)
[16:24] <kees> none on /var/lib/ureadahead/debugfs type debugfs (rw,relatime)
[16:25] <kees> sforshee: not sure.
[16:26] <abogani> ftrace
[16:27] <apw> kees, i meant more that upstart is likely mounting it early
[16:27] <kees> abogani: ftrace is a rootly thing, though, right?
[16:28] <kees> apw: likely mountall, but yeah
[16:29] <apw> kees, so something you could just try probabally
[16:30]  * kees has 2 days before feature freeze. :)
[16:31] <sforshee> kees, looks like debugfs is needed for some perf functionality: https://perf.wiki.kernel.org/index.php/Perf_examples
[16:31] <kees> sforshee: but that's all rootly stuff.
[16:32] <kees> sforshee: i.e. not mounting it or making the mount 0600 shouldn't wreck that.
[16:32] <sforshee> kees, yep, just an argument for not ripping out debugfs support completely
[16:33] <kees> sforshee: well... I'm against allowing the root user instrumenting the kernel in general. I'd prefer a "debug" flavor for that kind of thing, but I know it's a losing battle. :)
[16:34] <kees> sforshee: the middle ground is to just keep from allowing root to manipulate arbitrary memory.
[16:35] <kees> apw: setting 0600 is still a kernel change (since the mounted fs determines the mode of the root node)
[16:38] <apw> kees, i thought it was the OR of the root in the FS and the directory onto which it was mounted
[16:38] <kees> apw: looks like not
[16:39] <apw> ok, then likely yes a small change kernel wise
[16:39] <apw> as its just that top directory
[16:44] <bjf> ubuntu-meeting
[16:48] <bjf> ##
[16:48] <bjf> ## Kernel team meeting in 12 minutes
[16:48] <bjf> ##
[16:49] <kees> apw: I don't see a way to make the root inode 0600 without patching fs/libfs.c simple_fill_super()
[16:55] <apw> kees, hm
[16:56] <apw> probabally needs a _mode() version
[16:56] <kees> apw: well, actually, I could change the mode after the simple_fill_super call
[16:58] <kees> apw: in debug_fill_super, test the simple_fill_super return, then set sb->s_root->d_inode->i_mode
[16:58] <kees> seems like a psychotic hack, though
[17:01] <apw> i think add a new versionw hcih takes a mode
[17:01] <apw> and make the existing one pass 0600 to it
[17:02] <kees> apw: yeah. there aren't many users of simple_fill_super
[17:13] <JFo> grabbing a bite bbiab
[17:15] <jjohansen> smb: good news, the hardy -xen kernels do boot on ec2
[17:15] <smoser> wait
[17:16] <smoser> maybe
[17:16] <smoser> i don't know that they dont
[17:16] <smoser> i can test that fairly quickly
[17:16] <jjohansen> smoser: oh, I took it as you had already tested
[17:16] <smoser> no. i only know that i did something wrong when they failed.
[17:16] <smoser> lets see.
[17:16] <jjohansen> smoser: ah
[17:18] <smb> jjohansen, partially good news then :)
[17:19] <jjohansen> smb: yes
[17:19] <jjohansen> smb: smoser and I were discussing whether it was worth while pulling pv-grub back to hardy
[17:19] <smoser> oh wait...
[17:19] <smoser> i wasn't necessarily going that far...
[17:20] <smoser> first would be to get to using the archive kernels
[17:20] <jjohansen> hehe, /me over enthusistic again
[17:20] <smoser> that would require some changes in image building
[17:20] <jjohansen> smoser: right
[17:20] <smb> jjohansen, I was just commenting like that. :)
[17:20] <smoser> using pv-grub would be wonderful.
[17:20] <jjohansen> I think archive kernels is a given
[17:20] <jjohansen> yes it would be
[17:20] <smoser> ok.
[17:20] <smoser> so
[17:21] <smoser> let me upload a kernel and ramdisk and see if they boot.  this is such a pain for hardy :)
[17:21] <smoser> which is why we'd want to get to pv-grub
[17:21] <jjohansen> yep
[17:23] <kees> apw: I'm testing this now, what do you think? http://kernel.ubuntu.com/git?p=kees/ubuntu-natty.git;a=commitdiff;h=eca3653fb5aaa514c734821dc68813bb0fdc49fc http://kernel.ubuntu.com/git?p=kees/ubuntu-natty.git;a=commitdiff;h=f787804f21a3070e14df32ce8098b3f0b4a40646
[17:23] <smb> jjohansen, smoser Though I think I noticed a slight pain with pv-grub once an ami is not booting. Just overriding the aki seemes not to work as simple (I guess I would need to publish a ramdisk there)
[17:24] <smoser> smb, well, maybe
[17:24] <smb> But I generally agree on the beauty of pv-grub
[17:24] <jjohansen> smb: with hardy and lucid you could always just manually specify an aki instead of using the pv-grub aki
[17:25] <smoser> well, they dont run
[17:25] <jjohansen> so it should be no worse than now
[17:25] <jjohansen> smoser: darn
[17:25] <smoser> as there is no network driver in the image
[17:25] <smoser> unless you get the -modules into the image
[17:25] <jjohansen> smoser: okay, /me and smb will persue getting -xen to work
[17:25] <smoser> although... we could potentially fix that by getting the netowrk driver into the ramdisk
[17:25] <smoser> i think that would be very worth it
[17:26] <smb> yep. just having to fiddle with the network driver does sound like it could be done without breaking our ppa builders
[17:28] <smoser> smb, well, the ramdisks are manually built
[17:29] <smb> Ok, so that would be an option, too. Probably even better than arguing for a change of the xen image if it can be avoided.
[17:30] <smoser> yeah.
[17:31] <smoser> smb, i might have been wrong on network
[17:31] <smoser> http://paste.ubuntu.com/570675/
[17:31] <smoser> that is output of lsmod in a current instance
[17:32] <smoser> none of those look like network module to me
[17:33] <smb> smoser, neither to me. at least not an nif driver
[17:34] <smoser> off topic, but i'm personally happy to see that kernel clock apparent time travel occurred on this hardy kernel (http://paste.ubuntu.com/570676/) ... ie, htats not a regression in lucid or maverick its been there for quite a while. i had never looked on hardy before
[17:34] <smb> Is ifconfig -a show something
[17:35] <smb> smoser, I saw it occasionally when restoring an instance
[17:35] <jjohansen> smoser: time travel problems have plagued virtualization for a long time
[17:37] <smoser> smb, yes, there is definitely a network device
[17:41] <jjohansen> CONFIG_XEN_NETDEV_BACKEND=y
[17:41] <jjohansen> CONFIG_XEN_NETDEV_FRONTEND=y
[17:41] <jjohansen> smoser, smb ^
[17:41] <smoser> so maybe it was disk that was failing
[17:41] <smoser> hold on
[17:41] <smb> jjohansen, yup that makes sense with a network interface there but not in modules
[17:42] <smoser> smb, you can poke around at ec2-50-17-93-174.compute-1.amazonaws.com if you'd like. please don't modify anhything though
[17:42] <jjohansen> smb: yep, /me was just double checking
[17:43] <smoser> smb, http://paste.ubuntu.com/570680/ is output of a hardy i386 instance booted with a differnet kernel ramdisk than it is expecting
[17:43] <smoser> thats why i had suspected no network driver
[17:45] <smb> hm, yes. on a very quick glance that looks like either the network driver is not working, the network not setup or the magic http-meta server missing
[17:45] <smoser> well meta data service isn't missing multiple times in a row
[17:45] <smoser> i've only seen that happen maybe 3 times ever
[17:47] <smb> smoser, Yeah, I only came up with it because that is what usually happened to me when trying on my test-system (thanks for the uncloudify script btw, though unfortunately time seems to have warped without me having any to try again)
[17:47] <smoser> yeah
[17:47] <smoser> right
[17:47] <smoser> but it seems like its something else, and i suspect that it is solved by installation of the apprpriate linux-modules package
[17:48] <smb> It is really hard to say. Disk and network look to be ok from the messages...
[17:52] <smb> smoser, If I have understood jjohansen correctly he was syncing up the patches for the ppa image. So that would only leave some configuration difference to be found
[17:53] <smoser> right.
[17:53] <jjohansen> hence the question does, the new image boot
[17:53] <smoser> well. it boots.
[17:53] <smoser> that is for sure.
[17:54] <smoser> i suspect that re-bundling an image with its modules instlaled will work.
[17:55] <smoser> so i guess, we need to test that putting them there would fix this
[17:55] <smoser> and then try to work out exactly what is going wrong
[19:03]  * tgardner --> lunch
[19:14] <apw> JFo, you there?
[19:15] <JFo> apw, yep
[19:16]  * apw mumbles at you
[19:16]  * JFo is on there
[19:16] <JFo> I don't see you apw
[19:17] <apw> and i cannot connect hrm
[19:17] <JFo> ah, there you are
[19:25] <kees> tgardner: well there you have it; greg doesn't want to take it.
[19:43] <apw> kees, what was his objection
[19:43] <JFo> apw, bug 709591 is one we only tagged kj-triage
[19:43] <ubot2> Launchpad bug 709591 in linux "i915 doesn't detect HDMI display" [Undecided,New] https://launchpad.net/bugs/709591
[19:45] <apw> JFo, and weher can i find the script which did this
[19:46] <apw> JFo, cranberry?  if so where
[19:46] <tgardner> kees, is he only objecting to 'debugfs: only allow root access to debugging interfaces' ?
[19:46] <JFo> it is in the kernel team branch of arsenal
[19:47] <JFo> it is the new-process-new-bugs.py under the contrib/linux/ dir
[19:48] <apw> and what output did the run produce for that bug
[19:49]  * JFo digs back
[19:49] <kees> tgardner: I would note that viro just said that debugfs "should not be mounted on production systems".
[19:49] <kees> apw: "debugfs has no rules and is for debugging only"
[19:50] <tgardner> kees, I'm just replying in email something to that effect.
[19:50] <kees> tgardner: okay
[19:51] <tgardner> kees, and it was Alan Cox that said "don't mount debugfs"
[19:51] <JFo> apw, can't find that one in the output. but I did find bug 714415
[19:51] <ubot2> Launchpad bug 714415 in linux "BUG: unable to handle kernel paging request at 80808080" [Undecided,New] https://launchpad.net/bugs/714415
[19:51] <JFo> the output is here https://pastebin.canonical.com/43753/
[19:52] <JFo> same deal
[19:53] <apw> what was the next line of the output
[19:53] <tgardner> sforshee, wren't you having tpm suspend issues for awhile ?
[19:53] <JFo> apw, it was for the next bug
[19:53] <JFo> want me to pull out a few more?
[19:54] <JFo> I should note, the output there is with the --verbose option enabled
[19:54] <JFo> so there isn't much more for us to get without debugging print statements
[19:54] <JFo> or rather debug print statements
[19:55] <sforshee> tgardner, not me
[19:55] <sforshee> mine was an i915 regression
[19:55] <tgardner> sforshee, hmm, ok
[19:56] <smb> tgardner, reading the tales from the unkown stable mailing list?
[19:56] <tgardner> smb, about what?
[19:57] <smb> About the regression they caused on some tpm hardware
[19:57] <tgardner> smb, oh thatt. no, I saw some patches going by on LKML that fix the tpm patch that was reverted
[19:58] <smb> tgardner, Yeah, noted the story on the stable mailing list.
[20:02]  * jjohansen -> lunch
[20:10] <apw> JFo, for it to print Action: <blank> i think something odd happened in skipit
[20:10] <JFo> I wondered that too
[20:10] <JFo> but I still can't wrap my head around it enough to determine what
[20:14] <apw>         if result and not self.reason:
[20:14] <apw>             self.reson = "skip it returned true"
[20:14] <apw> perhaps add (a correct) version of that to the bottom of skipit
[20:22] <apw> and run it in ry run and verbose
[20:24] <apw> dry
[20:25] <JFo> k
[20:32] <JFo> is it sad that it took me a bit of looking at that to determine what needed to be fixed? ;-P
[20:40] <skaet_> JFo, which specific packages do your tools search for, for identifying interesting bugs?  my guess is linux,  linux-ec2, and ???
[20:40] <JFo> the tools are looking only at linux for the moment
[20:40] <JFo> we are still working out some issues
[20:40] <skaet_> ok thanks.
[21:39] <bdmurray> I've been looking at some kenrel debugging documentation particularly https://wiki.ubuntu.com/Kernel/CrashdumpRecipe - is it current / accurate?
[21:44] <bdmurray> apw: are you still affected by bug 451390?
[21:50] <ubot2> Launchpad bug 451390 in launchpad "limited upload rights no longer give series nomination accept/decline rights" [High,Triaged] https://launchpad.net/bugs/451390
[22:06] <apw> bdmurray, has it been fixed?  i cannot trivially tell without asking mr watson to remove the work around
[22:07] <bdmurray> apw: which work around is that?
[22:08] <apw> the bug is that package sets do not give you the nom rights for the packages in, for the linux package mr watson added linux to each of the kernel uploaders direct rights
[22:08] <apw> this works round the issue for the main package for which we use nominations, but does not solve the bug
[22:09] <bdmurray> apw: ah okay I wasn't aware of *that* workaround
[22:10] <apw> yeah though it means the other 20 packages on my list i don't have noms for
[22:10] <apw> i think i'd need to find a bug on another package to confirm
[22:10] <bdmurray> apw: its okay I'm playing with it on staging now
[22:10] <apw> bdmurray, that was the only thing stopping me moaning every single day
[22:12] <bdmurray> apw: actually if you could try one of the other 20 packages on staging.launchpad.net that'd be interesting
[22:14] <apw> bdmurray, ok
[22:15] <apw> shame everything i do on launchpad also triggers timeouts
[22:15] <apw> dammit
[22:15] <apw> fileing a bug doesn't work on staging for me ...
[22:17] <apw> bdmurray, it may be working (nomination s for other packages) i need to test it on live i guess
[22:17] <apw> https://bugs.staging.launchpad.net/ubuntu/+source/linux-meta/+bug/722414
[22:17] <ubot2> Launchpad bug 722414 in ubuntuone-android-files "syncable icon too small" [Medium,Confirmed]
[22:39] <bryceh> apw, upstream is telling me "for all the 915/945 bugs can you please have the reporters test the latest kernel with the enlarged unfenced alignment."
[22:39] <bryceh> google isn't informing me what an "enlarged unfenced alignment" is... do you recognize that?
[22:45] <cking> apw, do you never sleep?
[22:45] <RAOF> bryceh: That sounds like a libdrm commit to me?
[22:47] <bryceh> RAOF, didn't get much more context than that
[22:47] <bryceh> Bryce, for all the 915/945 bugs can you please have the reporters test the
[22:47] <bryceh> latest kernel with the enlarged unfenced alignment. That's the most likely
[22:47] <bryceh> cause of random writes, though I don't suspect it in this case.
[22:48] <bryceh> figure I shouldn't forward all the rest of these bug reports until I've gotten people to test whatever he's referring to
[22:48] <bryceh> but I suspect if it doesn't occur in tip, he won't care and we'll be on our own to dig out what patch(es) provide the fix
[22:49] <jjohansen> cking: of course he doesn't
[22:50] <RAOF> bryceh: Sounds about right :)
[22:50] <bryceh> RAOF, however `git log | grep "unfenced alignment"` in linus' tree returns null
[22:51] <bryceh> nor found anything in ickle's drm-intel tree
[22:51] <bryceh> wonder if he is sending me on a snipe hunt ;-)
[22:55] <bryceh> RAOF, hmm wonder if this is a possible solution to the vesafb bug?  http://git.kernel.org/?p=linux/kernel/git/ickle/drm-intel.git;a=commit;h=86b27d8050b6b2aec31063fa9f40b16fb347afb3
[23:11] <RAOF> bryceh: I suspect ickle's talking about 5e7833
[23:19] <bryceh> RAOF, ah thanks!
[23:24] <smoser> jjohansen, smb i kicked off a hardy-server uec build that is going to use linux-xen from the ubuntu archive.  it should appear in a couple hours on uec-images.  its not using -proposed kernel, but it is loads closer.
[23:25] <jjohansen> smoser: nice
[23:31] <kees> smoser: do you recognize "2.6.31-302.7-rs" as an Ubuntu kernel version? looks like a fork of an early karmic linux-ec2 version or something.
[23:32] <jjohansen> kees: that isn't one of ours
[23:32] <kees> jjohansen: I didn't think so.
[23:35] <chrismsnz> Hi Guys, I have a set of Supermicro 2u twins (4 nodes) running Lucid. A couple of them have been having OS trouble under high load
[23:36] <chrismsnz> usually what happens is the machine is still reachable via connecting to a port (i.e. you can connect to the http port, memcache port and it will respond to ping), but anything further than that is unresponsive
[23:37] <chrismsnz> so you can connect to the HTTP port, but you cannot request a document - it will hang
[23:37] <chrismsnz> It can work pretty hard but as soon as it "crashes" like this the only thing you can do is reboot
[23:38] <chrismsnz> I think it's a kernel problem with the version that comes with Lucid - what is the recommended kernel upgrade to try while still sticking with 10.04?
[23:41] <chrismsnz> running 2.6.32-27-server


[20:47] <pleia2> shaping up to be another lean issue, if anyone finds news, please feel free to add it to the doc :)


[17:58] <LIDH> hello
[17:59] <LIDH> anyone to give me a hand on a problem related to touchscreen?
[18:07] <bregma> LIDH, depends on your problem
[18:11] <LIDH> So, I have Ubuntu 12.10 and a POS system EBN X-950 with touchscreen (EgalaxyTouch according to the manual), so, i tried $lsusb and it doesn't list the touchscreen controller. If I do a screen /dev/ttyS[0-4] can't get any input from the touchscreen. Already did $ modprobe -r usbtouchscreen and still doesn't detect, any ideas what's the problem?