[00:03] <ohsix> hah why does the copy dialogue notification icon just have a mouse cursor on it
[00:03] <ohsix> it used to be a file cabinet
[00:28] <kklimonda> the problem with this transmission patch is that it would restore a functionality that upstream doesn't want in this form.
[00:29] <kklimonda> I'm reluctant to restore functionality removed by upstream, as imo it's not our call what they want to do with their software. This particular issue has been discussed in the upstream tracker to death, there is a workaround, and the better proxy support will come soon..
[00:30] <kklimonda> ohsix: I think I've lost your email in the pile of emails to reply to.. I can't find it right now, but I do remember reading it.
[00:32] <kklimonda> ohsix: there are more problems with the patch, we are 9 days before release and the patch would break user interface freeze, and there are no longer translations shipped in the package (I wonder if they are available in the language packs)
[00:34] <ohsix> kklimonda: yea i tried to speak with them about what form is acceptable, they weren't having it
[00:35] <ohsix> it's just "WE DONT WANT IT", caps usesd for emphasis and to cover the frankly obscene interaction i had with them
[00:35] <kklimonda> ohsix: that's because the decision how to bring proxy support back has been made.
[00:36] <kklimonda> the idea is to use system-wide settings
[00:36] <ohsix> kklimonda: i've discussed that with them as well; torrent clients are in a unique position that ptoxy options will probably differ between the different types of connections they make; you really need private settings
[00:36] <kklimonda> the problem is this solution doesn't make everyone happy.
[00:36] <ohsix> the problem was proxy support didn't suit everyone in the first place, so they removed it alltogether
[00:37] <ohsix> they really seemed to invite public input but they aren'ty, they're moderating trac comments and the like
[00:37] <kklimonda> have you given good and legal reasons for not wanting to use system-wide proxy settings? afair at no point did anyone give a reason for private proxy settings that didn't involve vague words like "privacy"
[00:37] <ohsix> kklimonda: i couldn't find the "to death"
[00:37] <ohsix> yes, and i told them
[00:38] <ohsix> i can provide the entire irc log if you wish
[00:38] <ohsix> but the long short of it is i use it to scrape/announce trackers as if i were at home; while i roam with  my laptop
[00:38] <ohsix> (ssh -D to home ... etc)
[00:39] <ohsix> i know about people saying they want privacy and thinking thats what they get, and about the protocol itself; frankly all of it
[00:39] <kklimonda> no need, I have the logs.
[00:39] <kklimonda> but really, what are the reasons anyone would want a privacy?
[00:39] <ohsix> ok, i hope you'll see that i was perfectly frank in my intentions and polite to no end
[00:40] <ohsix> no clue; i don't want or need for privacy or i wouldn't be using a torrent client
[00:40] <ohsix> my very narrow case is having a socks proxy to home, so it looks like the scrapews/announces are from there
[00:40] <ohsix> you can probably see that having global options when that's all i want is untenable
[00:42] <cnd> @pilot out
[00:42] <kklimonda> really, from where I stand the issue is rather simple - some people want to use private trackers, and T devs knowing what is being shared there don't give much thought about it.
[00:42] <ohsix> the discussion was far from exaustive, at least the things archived in trac tickets
[00:43] <ohsix> so you mean they have made a moral judgement  with regard to the usage, expecially concerned with proxy support?
[00:44] <kklimonda> I can't speak for them, but that's how I see the whole issue.
[00:44] <ohsix> after all the software can be used to pirate things, just like the proxy support can be used in ways they don't like; but they don't remove the torrent downloading ability
[00:44] <ohsix> it's getting very tough to type, on 3g at the moment
[00:45] <ohsix> so is my use case unlike the concerns you've heard aired before?
[00:45] <kklimonda> I'd have to read your discussion with jordan to really comment on this particular case.
[00:46] <ohsix> i could certainly use a voice other than my own, apparently, to get my concerns aired
[00:47] <kklimonda> but my main issue with reintroducing proxy support doesn't have anything to do with whether I agree with their judgment, or not.
[00:47] <ohsix> btwe, notwithstanding; current "global" support doesn't work with socks, though jordan pointed out where it would need to be fixed AND he didn't disapprove my ttrac ticket like they've been doing with my comments on trac tickets
[00:47] <kklimonda> as I see it there are three problems: It's really late in the cycle to reintroduce this patch given that it adds the new interface, and requires translations. I don't know if those translations are still being shipped, or not.
[00:48] <kklimonda> We, as maintainers, shouldn't really make calls about whether some changes made by upstream are good or bad.
[00:48] <ohsix> so i have to setup privoxy to forward http to socks (ssh -D) and only for certain hosts, since i don't want to send my web traffic through the same proxy
[00:48] <kklimonda> (can't think of the third point, as it's getting late)
[00:49] <ohsix> i get that, and don't expect you to do much more than comment; at best speak for my concerns since nobody is listening
[00:49] <kklimonda> jordan did acknowledge that he has handled the removal of proxy badly.
[00:50] <ohsix> i have to say it's the worst treatment i've _ever_ gotten trying to work with another project
[00:50] <ohsix> my beef is that they invited public discussion but didn't really mean it
[00:50] <kklimonda> but it's his decision, him being the lead developer, how he'd like to handle it further.
[00:50] <kklimonda> them moderating trac most likely have nothing to do with moderating the discussion.
[00:51] <ohsix> (re: censoring trac tickets and the treatment of people politely airing their concerns)
[00:51] <kklimonda> moderation has been enabled some time ago for other reasons
[00:51] <ohsix> well if my comments show up; i'll let you know, they were quite specific and only on one bug
[00:51] <ohsix> i can't impress upon you how rudely i was treated, that i'm being moderated on trac is not far fetched
[00:52] <ohsix> as i said during that conversation, i'm being romantic about switching away from transmission; i should just do it if it no longer suits, but i'm having a very hard time doing so, it is the most usable client
[00:54] <ohsix> it's really a shame they only have forums, trac, and irc; i couldn't find any public discussion outside of those trac tickets
[00:55] <ohsix> i offered to completely own the feature and implement it in a shape and form they could agree with it
[00:56] <ohsix> obsequiousness is a word roused in the mind about the situation
[00:57] <kklimonda> hmm, no - from what I have read jordan has given you hand in implementing socks support in the current code (which takes socks configuration from gnome proxy settings)
[00:57] <ohsix> kklimonda: thanks for your time, like i said; maybe you can speak for the use-case, i've been dismissed and thrown into the memory hole
[00:57] <ohsix> as i've explained that isn't useful to me
[00:57] <kklimonda> but you were pressing the issue of restoring the original private proxy support, and you were told over and over that it's not going back
[00:57] <ohsix> privoxy is going to nee dto be in the middle even if socks support worked
[00:58] <kklimonda> and then the entire discussion went south.
[00:58] <ohsix> i don't want all my web traffic to go through my home connection; it is heavily metered
[00:58] <ohsix> only "original" insofar as not using the global settings, i don't care what the ui looked like; and was willing to own it
[00:59] <kklimonda> but it's not a matter of how gui looks like, they are just not interested in the private proxy support.
[00:59] <ohsix> he would not be forthwright in telling me what was wrong with it; he was not being intellectually honest, it was his choice of course, but
[00:59] <ohsix> i have to stop using the best torrent client available because of that
[01:00] <ohsix> i hope you understand that i don't want that
[01:00] <ohsix> i don't care if it's only available by edfiting settings.json directly; or anything
[01:00] <ohsix> you cant get tsocks to pick one port to forward either; so you can't use it
[01:01] <ohsix> torrent clients are in a unique situation, one where having different proxies for different types of connection the client makes is desirable
[01:01] <ohsix> that can only be supported in the client itself; as it's the only one that makes any real discrimination
[01:03] <ohsix> i couldn't get him to explain why it was there at all if it didn't please them now, either; he didn't have to of course, but i kept grasping at connections i could make and still treat him as a reasonable person
[01:03] <kklimonda> many features are being added because it seems to be a good idea at the time.
[01:04] <ohsix> right
[01:04] <ohsix> i'm not asking for exaustive proxy support like some people were either; just what was there
[01:07] <ohsix> kklimonda: do you at least accept the premise that torrent clients are unique with the respect to how they connect? i can't think of anything that uses several connection types in one program that you'd desire proxying
[01:08] <ohsix> it's an exceptional scenario for sure
[01:10] <ohsix> what really blows my mind is the global proxy support still only uses it for scrapes/announces; which doesn't account for the most requested option to be added, the stuff that probably prompted its entire removal in ffrustration
[01:11] <ohsix> i get your position as maintainer; but it'd be nice to have another person speak for my use case, since i'm appaarently not leet enough to do so
[01:11] <lifeless> ohsix: how are torrent clients unique?
[01:12] <kklimonda> ohsix: I accept that some people don't want to have their torrent activity tracked to themselves.
[01:12] <ohsix> lifeless: unique in the sense that it can be desirous to have different proxying options for only certain types of connections they make
[01:12] <ohsix> kklimonda: no, that's exactly what i want
[01:12] <lifeless> ohsix: like voip clients, lots of fps games and web browsers?
[01:13] <ohsix> kklimonda: just like i ssh'd in here on my laptop, with my phone; to use the resources i have at home
[01:14] <ohsix> i roam a lot and i want it to scrape/announce from my home connection
[01:15] <ohsix> i know the implications, and i also know you can't tell transmission to use your local ip for scrapes like you can for some other clients, but i still desire to scrape/announce from home
[01:15] <ohsix> and i still desire to use transmission D:
[01:15] <kklimonda> change trackers that you use - binding ratio to ip is a retarded idea.
[01:16] <ohsix> there are no ratios involved my friend
[01:16] <kklimonda> what's the point then?
[01:16] <kklimonda> I'm really curious
[01:16] <ohsix> i'm thinking you are implying some things in our conversation that just aren't the case
[01:17] <kklimonda> well, not really. I just know only of two reasons to use proxy for tracker communication.
[01:17] <ohsix> i'll tel you privately if you really wish to know
[01:17] <kklimonda> neither of them really imply anything.
[01:17] <ohsix> i told you my reason; you fit it into some preconcieved notion
[01:18] <ohsix> i don't know of any trackers that use your ip to track ratios, either; but lets not digress
[01:18] <ohsix> i get the sense that i'm sort of being dismissed again; since you assume i'm making the case for something you've seen made before, with respect to "privacy" or whatever
[01:19] <ohsix> but at least you're being very honest about your concerns, and out in the open
[01:19] <kklimonda> I'm not dismissing you, I understand your concerns, and I'm aware of the entire issue.
[01:20] <ohsix> but you misconstrue my intent to announce/scrape from my home computer as something else; you even mentioned ratios
[01:20] <ohsix> as i say that though, i get how you might
[01:20] <ohsix> but i'm literally only connectiong home, not to some 3rd party shell or "vpn" provider, and only so it scrapes from home
[01:20] <kklimonda> it's just that I have a feeling that we are going in circles.
[01:21] <kklimonda> All I'm saying is that the removal of feature is upstream developers' decision.
[01:21] <ohsix> i got that
[01:21] <kklimonda> I've even tried to give you my point of view on why has they made this particular choice.
[01:21] <ohsix> my use case is valid for me, and i will have to use another client, i do not want to; as it's the most usable client packaged in ubuntu; my dillema is that i'm being irrational about just switching
[01:23] <ohsix> and i'm asking you to voice my concern, since i tried and failed
[01:23] <ohsix> let me message you and tell you why i do it
[01:23] <kklimonda> sure
[03:21] <ohsix> hm re: adding ubuntu-sponsors to a patch request, if it's within the guidelines for a possible change is it generally well considered and most likely added?
[04:00] <ohsix> can someone unsub ubuntu-sponsors here https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/765248 the bug is all sorts of garbage now; and i don't want to spam them with every reply
[04:04] <TheMuso> Hrm either someone didn't beat me to it, or https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/765248 doesn't have ubuntu-sponsors subscribd.
[04:04] <SpamapS> TheMuso: ditto ;)
[04:05] <TheMuso> s/didn't//
[04:05] <ohsix> ok thanks whoever did it
[04:06] <ohsix> and apologies to the messages that did get to them :[
[04:07] <ohsix> i'm just forehead slapping amazed, over and over again
[04:21] <SpamapS> hmm.. is there an easy way to extract the core dump out of an apport crash file?
[04:32] <TheMuso> SpamapS: Apport does have a way to unpack a crash file, apport-cli does anyway.
[04:32] <TheMuso> Manpage or -h should give you the info.
[04:33] <SpamapS> TheMuso: its just telling me I have out of date packages
[04:33] <SpamapS> --save should just save it anyway, damnit. :-P
[04:33] <TheMuso> SpamapS: apport-unpack is what you want.
[04:33] <TheMuso> I knew it was there somewhere.
[04:34] <SpamapS> yes thats what I wanted.. :)
[06:46] <ilea> someone here that helps on ubuntu 11.04?
[06:48] <cinerama> hi ilea, you might want to join #ubuntu and ask over there...
[06:48] <ohsix> specifically #ubuntu+1
[06:48] <ilea> i want to talk with someone that is in the team that makes ubuntu 11.04
[06:49] <ilea> not to chat
[06:49] <ohsix> about what?
[06:49] <ilea> because there is a bug in ubuntu 11.04 and i need to talk with them
[06:49]  * SpamapS bets $5 on Unity
[06:50] <ohsix> ilea: bugs can be filed on launchpad, security bugs are private by default if you want only developers to see it
[06:50] <SpamapS> ilea: tho to add to ohsix's point, it is appropriate to ping this channel about important bugs that have been filed and ignored.
[06:51] <ilea> after i make a dsl conection (username, service, pasword) i try to conect and after a time it dosnt conect
[06:52] <ilea> the indicator is going up like a wi-fi conection
[06:52] <ilea> but nothing
[06:52] <ohsix> that sounds like grist for #ubuntu+1, and if they figure something out; filing a bug
[06:53] <ohsix> ilea: networkmanager keeps logs, you can see what it does when it brings the link up
[06:53] <ohsix> grep NetworkManager /var/log/daemon.log
[06:54] <ilea> i cant fill a bug report because i cant send it with no internet conection and i am a litle new and dont now how to save it and send it from another distro
[06:55] <ilea> after conection fails to try and type that in terminal?
[06:55] <ohsix> that's alright, the information that will help will be in that file; if you can save a text file with the output, people in #ubuntu+1 can help you find the real cause
[06:55] <ilea> grepnetworkmanager....?
[06:55] <ohsix> yep
[06:55] <ohsix> case and spacing is important
[06:56] <ilea> so i have to wryte that is terminal after conection fails and then save a text file with it and go on ubuntu+1?
[06:57] <ohsix> yep, once they can read it they can try and help fix it
[06:58] <ilea> but how to send it on irc? i have to paste it here for them to read it
[07:32] <pitti> Good morning
[07:42] <SpamapS> howdy pitti
[07:43] <pitti> hey SpamapS, how are you?
[07:51] <SpamapS> pitti: good. Way too busy. :-P
[07:54] <didrocks> good morning
[07:55] <steveire> Hi, I'm trying to learn packaging. I've got the source of grantlee, and I've got the newer source tarball from http://downloads.grantlee.org/
[07:55] <steveire> (I'm the grantlee upsteam)
[07:55] <steveire> What's my next step?
[07:57] <broder> hmm...what makes plymouth actually show the splash on shutdown? on bootup, it's the plymouth-splash job, but none of the conditions there will trigger on shutdown
[07:57] <broder> oh, wait - just noticed the post-start script. bah
[07:57] <SpamapS> broder: shutdown is all sysv
[07:57] <diwic> steveire, unfortunately there are several ways of doing packaging and how to easiest update to a new upstream version depends on how it is currently packaged
[07:58] <SpamapS> steveire: there's a new tool thats somewhat experimental, called pkgme, that may help
[07:58] <SpamapS> steveire: what language is grantlee in?
[07:58] <broder> SpamapS: i think i'm seeing a race between the plymouth upstart job and the casper sysv init script on shutdown. does that seem plausible to you?
[07:58] <steveire> C++/Qt
[07:58] <SpamapS> broder: yes its always a possibility
[07:59] <steveire> diwic: How do I find out whihc it is?
[08:00] <broder> SpamapS: yeah, i think a race there is consistent with what i'm seeing. i guess this puts me in support of your plans to upstart-ify the shutdown for O :)
[08:00] <diwic> steveire, from looking at debian/rules we can see that it uses cdbs
[08:00] <SpamapS> broder: plymouth is  start on stopped gdm
[08:00] <broder> yeah, and gdm is stop on runlevel [016]
[08:01] <SpamapS> broder: if you need to make sure you run before plymouth 'start on starting plymouth' works
[08:01] <dholbach> good morning
[08:02] <diwic> steveire, and from debian/source/format we can see that this is a quilt patch system
[08:02] <steveire> Ok
[08:02] <broder> SpamapS: plymouth looks at the $RUNLEVEL variable it inherits from the runlevel event. will my job get that variable as well?
[08:04] <steveire> So do I need to set up pbuilder?
[08:04] <diwic> steveire, that is helpful for checking that your package does not need more dependencies than you actually state in the control file
[08:05] <diwic> steveire, or for compiling for another version than you're currently running
[08:08] <SpamapS> broder: only if plymouth exports it
[08:08] <diwic> steveire, I'm realizing I'm not very helpful to you because I'm not sure what the easiest way of updating a 3.0 quilt package is, sorry
[08:08] <SpamapS> broder: so, in short, no. You could fake it tho..   start on runlevel [016] and stopped gdm
[08:09] <broder> well, if i wanted it to be strictly after plymouth, i'd do runlevel [016] and started plymouth, right?
[08:10] <broder> or is that going to get in the way of plymouth starting at boot? start on clauses with "and" still trip me up...
[08:12] <steveire> diwic: Ok, I'll scan through some docs
[08:18] <doko> which package should be used to file issues about the new scrollbar?
[08:20] <pitti> doko: overlay-scrollbar
[08:20] <doko> thanks
[08:21] <abhinav-> pitti: hi, I noticed that the man pages of apport haven't been updated for the -w/--window option ?  http://manpages.ubuntu.com/manpages/natty/man1/apport-cli.1.html
[08:22] <pitti> abhinav-: ah, good catch
[08:22] <abhinav-> pitti: thanks :) . should I file a bug ?
[08:23] <pitti> abhinav-: sure, can't hurt
[08:23] <smb> @pilot in
[08:23] <pitti> you don't happen to want to add it yourself? :-)
[08:23] <abhinav-> pitti: I can do that, provided I will have to look at the man page syntax :D
[08:25] <akheron> it's not hard
[08:27] <pitti> abhinav-: syntax-wise you can just copy&paste
[08:27] <pitti> abhinav-: anyway, it's quick, I can also do it myself, I just wanted to know whether you'd like to try
[08:27] <abhinav-> pitti: yes , alright I will do it :)
[08:27] <pitti> great, thanks!
[08:28] <steveire> "If a package for the application does not exist in Debian, then the Debian revision is 0 (e.g., 2.4-0ubuntu1). " https://wiki.ubuntu.com/PackagingGuide/Complete
[08:29] <steveire> The grantlee package has 0.1.7-0ubuntu3
[08:29] <steveire> Even though there is an upsteam debian version
[08:31] <pitti> dpm: so, Thursday is the final langpack translation deadline
[08:32] <pitti> dpm: so I think if we get a full export on the weekend, I'll be able to kick off a build on Monday, in time for the final release
[08:33] <dpm> pitti, that sounds good. Let me re-check the schedule for when we get the export.
[08:33] <pitti> dpm: I think we usually get one Friday, don't we?
[08:33] <pitti> I'll try to kick it off earlier than Monday, but no promises due to holidays
[08:36] <dpm> pitti, we get an export on Thursday 14:00 UTC, which we could use -> https://dev.launchpad.net/Translations/LanguagePackSchedule. I remember we changed it so it aligned better to the deadline. If that works for you, we could use that. If not, we can just ask the LP guys to set up a one-off export on Friday.
[08:36] <pitti> dpm: sounds fine
[08:37] <pitti> dpm: so yesterday's is already done, and I could request a full export now?
[08:37] <pitti> hm, I don't see one for Apr 19, though
[08:41] <dpm> pitti, it might take longer to be generated. But yeah, that's strange, especially because delta exports appear earlier in the day than full ones. But I think if you request it now it should be fine. AFAIK, the exports are simply on a cron job, and requesting the full export now would not interfere with the previous delta one, which was already triggered yesterday
[08:46] <pitti> dpm: right, as long as it's already runnning it should be okay
[08:46] <pitti> dpm: but I guess I'll just keep the tab open and request it tomorrow then
[08:47] <dpm> pitti, sure, sounds good
[08:55] <geser> steveire: Debian has only 0.1.4 while Ubuntu has 0.1.7 (there is no 0.1.7 in Debian on which to base the Ubuntu delta -> revision 0)
[08:56] <steveire> geser: Ah, right
[09:05] <steveire> http://dpaste.com/533477/ How do I remove that patch from the package?
[09:13] <abhinav-> pitti: I have added this content in apport-cli.1 http://paste.ubuntu.com/595871/
[09:13] <abhinav-> is it ok ?
[09:14] <pitti> abhinav-: looks fine
[09:14] <abhinav-> pitti: alright. thanks. pushing the branch
[09:26] <pitti> $ change-override.py -S -c universe xulrunner-2.0
[09:26] <pitti> chrisccoulson: ^ MUHAHA!
[09:26]  * pitti ^5s chrisccoulson
[09:28] <chrisccoulson> pitti, excellent, thanks :)
[09:28]  * chrisccoulson ^5s pitti
[09:29] <chrisccoulson> pitti - we'll probably kill it entirely next cycle ;)
[09:31] <abhinav-> pitti: https://code.launchpad.net/~er-abhinav-upadhyay/apport/bugfix-765600/+merge/58241  ,thanks for letting me do this :)
[09:31] <pitti> abhinav-: cool, thanks! will merge in a sec
[09:38] <abhinav-> smb: Hi, can you review this ? (https://code.launchpad.net/~er-abhinav-upadhyay/ubuntu/natty/tomboy/bugfix-757635/+merge/57282) or it has to come from upstream ?
[09:41] <smb> abhinav-, I am not sure but I have a look. hm, ubotu seems slightly confused...
[09:41] <pitti> ubottu tries to interpret merge request IDs as bug numbers
[09:41] <abhinav-> smb: thanks, :)
[09:41] <abhinav-> lo
[09:41] <abhinav-> lol
[09:47] <c2tarun> can anyone help me with Xauthority authentication failed error in ubuntu?
[09:56] <speakman> A few days ago I asked how to maintain the debian/ dir in my own source, and then I was suggested to keep it in a separate branch. But in the mean time, why can't the debian dir be part of the project? The one could use debian/changelog for the projects own changelog? Ideas?
[09:59] <pitti> speakman: some projects do, but at least I find it highly inconvenient
[09:59] <pitti> and apparently others as well, the current dpkg source format even allows stripping the upstream debian/ dir
[09:59] <pitti> so that it doesn't get in the way of the real debian/ dir from the distro
[10:00] <pitti> it's also inconvenient for upstream, as it will constantly be out of date, not match anythign real in debian/ubuntu, and over time you'll accumulate spec files, debian/ dirs, ebuild recipes, and what not
[10:01] <smb> abhinav-, The change itself look reasonable. though for ubuntu merge the code change should be done by a patch in debian/patches, not directly
[10:05] <speakman> pitti: thanks alot for your comments! But what if I _am_ upstream and the deb maintainer as well?
[10:06] <pitti> speakman: as I said, some projects do that, so if you find it more convenient, there's nobody stopping you :)
[10:07] <pitti> IMHO packaging stuff doesn't belong into upstream tarballs/VCSes, but that might just be me
[10:07] <pitti> (main reason: it's the wrong level to have it, as upstream releases are not tied to a particular distro and release)
[10:09] <speakman> pitti: Fair enough! But since this will be just my own private project shared with only a few mates, I think I make the exception and manage the debian/ dir within it's source tree :)
[10:10] <pitti> speakman: sure :) you can always drop it again if the project becomes more popular and it gets in the way
[10:11] <abhinav-> smb: alright thanks for the review :) . But I think the bug is not Ubuntu specific, so it should be merged directly. perhaps we should wait for it to come from upstream ?
[10:11] <speakman> pitti: you're absolutely right :) thanks alot!
[10:12] <pitti> abhinav-: it should still be a separate patch; directly modifying the upstream source is both hard to maintain and also hard to see what actually changed
[10:13] <speakman> By the way - is there some good documentation about managing a patchset within the debian/ dir? If I'm not the upstream owner, that is. :)
[10:14] <pitti> speakman: https://wiki.ubuntu.com/PackagingGuide/PatchSystems might be of some help
[10:15] <speakman> pitti: thanks! again! :D
[10:16] <abhinav-> pitti: that link explains it :) . so until the upstream developers don't review and merge the patch in their repo , the patch can be included in Ubuntu through debina/patches ?
[10:16] <pitti> abhinav-: rightg
[10:17] <abhinav-> alright, thanks. then I will do that :)
[10:33] <steveire> Why is this telling me there's no orig.tar when there is a orig.tar.gz? Shouldn't it find that?
[10:33] <steveire> http://dpaste.com/533496/
[10:37] <steveire> Discovered I need to add a '.1' to the tarball file name kdepim_<IP_ADDRESS>.orig.tar.gz
[10:37] <steveire> But why?
[10:41] <directhex> steveire, what's the version number in debian/changelog?
[10:42] <steveire> Ah, 4:<IP_ADDRESS>-0ubuntu2 indeed
[10:42] <steveire> But what is the '4:' about?
[10:45] <mdz> anyone else seeing syndaemon spin on the CPU?
[10:45] <directhex> steveire, it's called an epoch. it bumps the version number up ahead of 3: and 2: and 1: and 0:
[10:46] <directhex> where no epoch at all is the same as 0:
[10:46] <directhex> usually you use an epoch when you mess up & want to go down a version number, permanently
[10:46] <directhex> e.g. you had a metapackage with version numbers like "100", and suddenly you want a real version of "4.4"#
[10:48] <Kurisutian> cjwatson: I checked again with the beta 2 of the server install with a btrfs rootfs but I get the same error like I had with beta 1
[10:52] <steveire> directhex: Ah, so probably related to the kdelibs5 stuff
[10:53] <directhex> steveire, i'm afraid i don't know the specific history, but yeah, moving from one package to another might be related
[10:59] <Kurisutian> is anyone here that knows how to install ubuntu server beta2 on a rootfs.... I get some weird behaviour when using the installer..... or is it possible to bootstrap from an existing live cd. I need to put it on btrfs because of the snapshot capability it has....
[11:02] <Riddell> debfx: what are the relative merits of your patch compared to Sarvatt's in bug 753370 ?
[11:05] <debfx> Riddell: he discovered a case where his patch doesn't work
[11:10] <Riddell> debfx: groovy, uploading
[11:11] <debfx> Riddell: oh, tjaalton already uploaded it
[11:11] <Riddell> oh but it's in the queue?
[11:11] <tjaalton> yes
[11:11] <Riddell> in that case, accepting
[11:15] <speakman> hm... is it hard to setup my own apt repo? Like a local ppa with just a few packages?
[11:22] <pitti> speakman: no, not at all; you can just run apt-ftparchive and then add "deb file://... /" URL
[11:23] <pitti> see example section in the manpage
[11:23] <speakman> oh, cool! :)
[11:23] <speakman> just fired up man apt-ftparchive :)
[11:37] <TeTeT> speakman: I find reprepro to be a good fit for maintaining a custom repo. It had some issues with parallel writes in the past though, so you want to make sure only one reprepro is running at any given time. Think that was fixed upstream though
[11:40] <abhinav-> dholbach: how should I generate a patch for debian/patch of Tomboy ? I have patch both in debdiff and git format ? or should I start from scratch using quilt ?
[11:42] <dholbach> abhinav-, best use   edit-patch <some-name-for-the-patch>
[11:42] <dholbach> then apply the patch from git, then hit Ctrl-D
[11:42] <abhinav-> dholbach: ah great :)
[11:43] <abhinav-> dholbach: and how to submit the patch ? normal merge proposal ?
[11:43] <dholbach> yep
[11:43] <abhinav-> dholbach: great. thanks :)
[12:09] <speakman> TeTeT: great thanks!
[12:49] <abhinav-> dholbach: I did the steps as described in the packaging guide but something seems to be going wrong. After editing the dch , it asked to commit the changes, I said 'yes', but the new patch created in the debian/patches directory contains code from all the  patches :-/
[12:50] <dholbach> abhinav-, I'm just about to get lunch - can you just ask in the channel and see if somebody else can help?
[12:50] <dholbach> see you later
[12:50] <abhinav-> dholbach: alright. no problem
[12:50] <abhinav-> I will try again
[12:51] <m4n1sh> abhinav-, #ubuntu-motu whenever you are stuck up in packaging issue
[12:52] <abhinav-> m4n1sh: oh thanks :)
[13:19] <ogra_> ogra@panda:~$ ls /var/log/messages
[13:19] <ogra_> ls: cannot access /var/log/messages: No such file or directory
[13:19] <ogra_> hmm, is that normal ?
[13:19] <ogra_> did we drop messages from rsyslog ?
[13:20] <seb128> ogra_, see the changelog
[13:21] <ogra_> ah, pitti's fault !
[13:21] <ogra_> :)
[13:25] <diwic> ogra, actually it's my fault, I thought people running ARM *hint hint* would be happy for the extra disk space ;-)
[13:25] <ogra_> haha
[13:25] <diwic> ogra_, everything is in syslog anyway, so...
[13:25] <ogra_> its a great move, just need to get used to it
[13:25] <ogra_> yeah
[13:26] <ogra_> diwic, btw, i dont seem to get forward in any way with the panda sound stuff
[13:26] <diwic> ogra_, oh is it still bad?
[13:27] <ogra_> diwic, yes, i tried TheMuso's test packages, added and removed patches but no go ...
[13:27] <ogra_> in dmesg i end up with "asoc: no valid backend routes for PCM: SDP4430 Media"
[13:28] <ogra_> in the UI i managed to see the pulse profiles once but thats gone again with the last test build, i'm not sure how i made it work actually
[13:29] <jdstrand> @pilot in
[13:30] <ogra_> i kept the packages that showed this around ... but reinstalling them doesnt get me back the items in the UI
[13:32] <diwic> ogra_, hmm, are you sure that's from dmesg? I'm trying to grep for that message in a kernel tree but find nothing
[13:33] <ogra_> ogra@panda:~$ dmesg|grep -c "asoc: no valid backend routes for PCM: SDP4430 Media"
[13:33] <ogra_> 96
[13:33] <ogra_> i get it every time i restart pulse manually or re-login
[13:33] <ogra_> funnily it initializes the HDMI interface just fine
[13:34] <ogra_> (though that was there even before UCM was added to alsa)
[13:34] <diwic> ogra_, is that a standard natty kernel?
[13:35] <ogra_> yes, its a beta2 image i'm running
[13:35] <ogra_> (with recent updates)
[13:36] <ogra_> though there was a new upload that should have built now, i can upgrade to it ... but i dont think there were any asoc related changes in that revision
[13:36] <diwic> naah, just thought if there was some patchset that might have added the message
[13:37] <ogra_> well, omap4 uses its own kernel tree
[13:37] <ogra_> you are grepping in that one, right ?
[13:37] <diwic> ogra_, where's that tree?
[13:38]  * ogra_ looks on the kernel git server
[13:38] <ogra_> i never use it, so i have to dig
[13:39]  * ogra_ wonders if http://kernel.ubuntu.com/git will ever load
[13:39] <diwic> ogra_, it does, be patient
[13:39] <ogra_> heh
[13:40] <ogra_> *twiddle*
[13:41] <ogra_> desnt load but doesnt time out either
[13:42] <jdstrand> smb: fyi, I'm looking at bug #644632
[13:42] <ogra_> i see the gitweb header though
[13:42] <jdstrand> smoser: I think you pinged me about that ^
[13:42] <diwic> ogra_, so how well are things functioning at the alsaucm layer?
[13:43] <ogra_> diwic, not at all ?
[13:43] <smb> jdstrand, ookaaayy (not exactly sure what to do with that information) I suppose it is somewhere on the pilot list
[13:44] <jdstrand> smb: it is in the pilot list. fyi only so we don't both jump on it :)
[13:44] <ogra_> diwic, i honestly have no clue how to check it, apart from running alsaucm (which tells me its setting defaults) and seeing the pulse profiles in the UI i dont know where else to look
[13:45] <ogra_> oh, it loaded !
[13:45] <ogra_> 7me hugs his browser "... and i thought you were dead !"
[13:45] <smb> jdstrand, Ok. :) Well as I am mostly useless outside the kernel area (missing rights and such) I would be concentrating on kernel bugs with patches anyway, ;) Though I should also do a bit more in the other direction
[13:47] <ogra_> diwic, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=tree;h=refs/heads/ti-omap4;hb=ti-omap4
[13:47] <diwic> ogra_, thanks
[13:47] <ogra_> or better http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=shortlog;h=refs/heads/ti-omap4
[13:48] <pitti> ogra_: "messages is not the file you are looking for" </jedi wave>
[13:48] <ogra_> lol
[13:52] <mterry> james_w, ~ubuntu-branches/ubuntu/natty/libgnome-keyring/natty seems stalled -- can it be poked?
[14:01] <james_w> mtaylor, poked
[14:01] <james_w> mterry I mean
[14:13] <mterry> james_w, thanks
[14:31] <tjaalton> i've uploaded xorg-server 1.10.1, which has one single upstream commit since 1.10.1rc2, which reverts a patch that caused bug 757972
[14:32] <abhinav-> smb: if you are still reviewing proposals, please look at my new proposal, I have now moved the changes to be included in debian/patches (https://code.launchpad.net/~er-abhinav-upadhyay/ubuntu/natty/tomboy/patch-757635/+merge/58303)
[14:33] <smb> abhinav-, yup will check
[14:33] <abhinav-> smb: thanks :)
[14:40] <smoser> smb, just to be clear, above, jdstrand had tab-complete failure.
[14:40] <smoser> his comments were intended to be to me
[14:40] <jdstrand> smoser: actually, no. he is a patch pilot and I didn't want to step on his toes, but I also wanted you to know I was looking at it :)
[14:40] <smb> smoser, Ah ok. Well it actually could have been for me as well as we both doing piloting today
[14:40] <smoser> oh... i see.
[14:40] <smoser> funny
[14:40] <smoser> sorry
[14:41] <smoser> jdstrand, yes, i did ping you on that. only because you had worked the other bug in that area.
[14:41] <jdstrand> interestingly, I did tab complete looking for smb, but got smoser, which reminded me that I needed to point this out to smoser too :)
[14:42] <smoser> jdstrand, how is my suggestion incomplete?
[14:42] <smb> abhinav-, I know I may get the pedantic award... but why is the patch numbered 21_... and then sorted after 30_.. in the series file? Sure it does not matter... it just looks a bit odd
[14:43] <abhinav-> smb: I had no idea what number to give, 21 seemed good :D
[14:44] <jdstrand> smoser: OKUSERS=`awk -v vname=nss_initgroups_okusers '$1 == vname { v=$2 }; END { print v }'` doesn't work on its own (now filename or cat)
[14:44] <jdstrand> s/now/no/
[14:44] <smoser> ah. ok. i'll suggest adding '$CONF'. you're correct.
[14:46] <smoser> jdstrand, i was more interested in your feelings on whether or not it would be wise to carry this patch.
[14:46] <smoser> if upstream implements the feature, then we'll have a much more difficult time implementing the 'okusers' functionality on top of that.
[14:49] <dschulz> hi all
[14:49] <jdstrand> smoser: well, we've been carrying this patch for ages
[14:49] <smoser> yes. and upstream is considering adding that function.
[14:49] <smoser> (for ages)
[14:49] <smoser> but if they *did*, then it would be difficult to implement the "okusers"
[14:50] <smoser> possibly impossible to do so and retain backwards compatibility
[14:50] <smoser> unless we patched out the upstream function and relied on our own.
[14:51]  * jdstrand fingertaps waiting on upstream bug
[14:51] <dschulz> does anyone knows if theres a chance to get python-django 1.3 package before natty release? It's currently at 1.2.5
[14:52] <smoser> jdstrand, if you dont think its a concern, then thats fine.
[14:52] <smoser> but i didn't want to provide function in ubuntu that people would use, then be unable to retain backwards compatibility withthat function.
[14:54] <jdstrand> smoser: I think that is a valid concern. it looks like it was revisted as late as 8 months ago
[14:54] <smoser> right.
[14:55] <jdstrand> smoser: I'll comment in the bug
[14:55] <jdstrand> (our bug)
[14:59] <dschulz> pitti: Hi. Do you have a plan to build postgresql 9.x packages for natty soon? And more important, do you have an Amazon wishlist?
[15:00] <pitti> dschulz: 9.x natty> yes, there's a new microrelease from today which I'll package also for natty in my PPA
[15:00] <pitti> amazon wishlist> no, I don't
[15:00] <pitti> (how's that psql related? :-) )
[15:01] <dschulz> Thanks pitti :-)
[15:04] <smb> abhinav-, So basically I think the numbering thing is a bit odd, the description line may need a space at the beginning of the second line and Origin/Author could be Author alone. But I heard that a sponsor may fix this while doing the bits. Unfortunately I lack the rights for real sponsor things and can only complain err suggest.
[15:05] <smb> jdstrand, do you have the rights to do so?
[15:06] <jdstrand> smb: I have upload rights, yes, but all that really needs be done here is either an ACK with your changes, or you can hand me a corrected debdiff
[15:06] <abhinav-> smb: alright thanks. I can fix these and request another review ?
[15:06] <jdstrand> s/ACK with your/ACK conditional upon your/
[15:08] <smb> jdstrand, I think I would have to do the latter as I think lp does not offer me any action
[15:08] <jdstrand> smb: it isn't an lp action afaik anyway. it would just be me fixing the debdiff myself and uploading
[15:17]  * smb` thinks there has been a disruption in his force (irc timeout). I might have missed things
[15:17] <bjf> ##
[15:17] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:17] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[15:17] <bjf> ##
[15:18] <smb`> bjf, #ubuntu-kernel?
[15:18] <bjf> smb`, ack
[15:18] <abhinav-> smb`: I have made the changes, pushing them to launchpad
[15:18] <bjf> smb`, being friendly, inviting everyone :-)
[15:19] <smb`> bjf, We'd need to add "be on time or you miss it here". :)
[15:20] <smb`> abhinav-, thanks
[15:31] <abhinav-> smb: updated (https://code.launchpad.net/~er-abhinav-upadhyay/ubuntu/natty/tomboy/patch-757635/+merge/58303)
[15:33] <stgraber> tkamppeter: ping
[15:34] <smb> abhinav-, Ok, I approved (for what that is worth)
[15:34] <abhinav-> smb: thanks :)
[15:34] <mvo> dpm: is there a way to exclude certain translations for a given package from the langpacks? friendly-recovery is having trouble with the CJK fonts on the console and I'm looking into how to blacklist that currently
[15:35] <stgraber> tkamppeter: I'm trying to debug bug 742935 and one of the things that seem weird on the report's system is "cnijfilter-common:i386" being in state "iU" which might explain why aptdaemon doesn't work so well on that system. I was just wondering what's installing that package and how I can try to install it in my VM
[15:36] <dpm> pitti, how is the langpack-locales package used? I'm just trying to find out the supported locales in Natty, and I was looking at http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/langpack-locales/natty/view/head:/SUPPORTED - however, I've noticed that langpack-locales is not installed on my system
[15:37] <SpamapS> jhunt: will you be around in about 1 hour?
[15:37] <jhunt> SpamapS: sure will!
[15:37] <pitti> dpm: that's the source package name; the binary is "locales"
[15:38] <dpm> pitti, ah, thanks
[15:38] <stgraber> mvo: yep, there's a way to do it in pkgbinarymangler IIRC. There's a blacklist in there (skipranslations.blacklist) which might be what you're looking for. Though my understanding is that it'd simply block all .pot for that package from being imported in LP
[15:39] <stgraber> (I use it for ldm as it ships its own translations and it's installed in an environment where we don't have langpacks installed)
[15:39] <stgraber> though maybe there's a LP way of doing it (as in, filter what gets in the langpacks) that could be slightly cleaner :)
[15:42] <mvo> thanks stgraber not sure this is what I need as I want some languages, but not all (only the ones where we have good console fonts)
[15:43] <OdyX> Hi. Is it possible to have new packages in natty ? (my case is "pyside-tools", a much needed companion for PySide. It has no issues in Debian, for two weeks now.
[15:44] <stgraber> mvo: hmm, yeah, pkgbinarymangler probably isn't what you're looking for then as you'd need to manually import the translations in the source package and ship them yourself. Probably would be a lot better to patch whatever builds the langpacks then.
[15:45] <OdyX> Lemme rephrase. What more can I do to get https://bugs.launchpad.net/ubuntu/+bug/750295 solved ?
[15:51] <tumbleweed> OdyX: looks like ScottK didn't subscribe ubuntu-archive to do the sync
[15:51] <ScottK> Sure I did.
[15:52] <ScottK> Just not until now.
[15:52] <ScottK> ;-)
[15:52] <tumbleweed> :)
[15:52] <ScottK> tumbleweed: Thanks for pointing it out.
[15:53] <OdyX> thanks to you both.
[15:53] <OdyX> (I had a user request, which reminded me… Otherwise I wouldn't have noticed)
[15:54] <smoser> pitti, i've a lang related quesiton, and unfortunately for you, i think you're knowledgable.
[15:54] <pitti> jdstrand, kees, sconklin: linux-ti-omap4/maverick copied to -updates and -security
[15:54] <praveen_> can i ask a question about qt here???
[15:54] <pitti> smoser: just shoot :) (busy with two other things, so might lag a bit)
[15:55] <smoser> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html gives says that accept-language might be 'en' or 'en-gb'. if it is just 'en', is there something i can correlate that to in an LC_ALL or LANG setting ? is there a  way to chose default _XX value?
[15:56] <praveen_> please have a look here--http://ubuntuforums.org/showthread.php?t=1733402
[15:56] <pitti> smoser: this is mixing two concepts; "en" is a language, LANG/LC_ALL set locales (which are always country specific0
[15:57] <pitti> smoser: so you cannot translate a language name like English or Spanish to a "default country" easily, unless you make some hardcoded assumptions
[15:57] <pitti> smoser: like default to US for English (and screw the Brits), to Spain for Spanish (and screw south America), etc.
[15:58] <smoser> pitti, right... so the goal is to take what is in accept-language and give the desktop user an appropriate language
[15:58] <pitti> smoser: so in this case this is a language and nto country specific
[15:58] <ScottK> praveen_: There are more Qt knowledgeable people in #kubuntu-devel.  I'd try there.
[15:58] <pitti> smoser: what you can do is to map this to $LANGUAGE
[15:58] <smoser> would you hvae a suggestion on how to hack without hard coding (i dont want to come up with hard codes for all languages)
[15:58] <pitti> smoser: without setting a different locale
[15:59] <pitti> smoser: LANGUAGE is a list of languages and can e. g. be "de_DE:de:en_GB:en"
[15:59] <pitti> smoser: this would mean "if German (Germany) is available, use that, otherwise fall back to any German dialect, if that's not available, use British English, and as a last resort any English
[15:59] <smoser> pitti, thats good. i'm just exposing vast ignorance here :)
[16:00] <smoser> i can potentially get country code also.
[16:00] <pitti> smoser: we set $LANGUAGE by default now in language-selector, so chances are that your /etc/default/locale already has it even
[16:02] <smoser> thanks pitti.
[16:02] <AlanBell> kirkland: got a few minutes to chat about an etherpad server for UDS?
[16:05] <mvo> could someone eyeball the shell code in  https://bugs.edge.launchpad.net/ubuntu-jp-improvement/+bug/573502/comments/15
[16:06] <jcastro> pitti: I think my mail to the techboard might have gotten stuck in moderation - I need someone from the TB to add the linaro track leads to the ~uds-organizers lp group.
[16:08] <pitti> jcastro: moderated
[16:09] <mvo> jhunt: bug #575469 sounds like something for mountall/upstart? being able to tell it to boot in ro mode ?
[16:10] <ev> bum, apt-clone doesn't like being disconnected from the internets.
[16:11] <mvo> ev: ohh, what is it doing? exploding then :/ ?
[16:11] <ev> no, it thankfully doesn't error out
[16:12] <ev> but it equally doesn't preserve the packages
[16:12] <ev> because it can't fetch them, but doesn't add them to the list to repack
[16:12] <mvo> hrm, hrm, bad
[16:12] <ev> digging into it now
[16:12] <mvo> thanks!
[16:12] <ev> sure thing
[16:14] <psurbhi> mvo, bug 575469 needs a grub cmd line change
[16:15] <psurbhi> on which mountall can take better action
[16:15] <mvo> aha, nice - what needs to be added?
[16:15] <psurbhi> i am not sure, but say we add some option like "--recovery"
[16:15] <psurbhi> then mountall can have a look at that and then mount "ro" instead of whats in fstab
[16:15] <psurbhi> i will like to work on that bug :)
[16:16] <mvo> nice, thans!
[16:16] <psurbhi> mvo, np! :)
[16:23] <ev> mvo: I've filed bug 766171 for the apt-clone issue and will track my progress there.
[16:23] <bdmurray> cjwatson: you worked on bug 746758 with ev? it seems that it isn't fixed as there are still some of these coming in with the new version of ia32-libs.
[16:24] <ev> bdmurray: cjwatson is on vacation, but interesting...
[16:24] <bdmurray> ev: I've consolidated the new reports into bug 762968
[16:25] <ev> I'll try to find time to look at that, but I'm knee deep in apt-clone at the moment
[16:25] <bdmurray> ev: okay, thanks!
[16:27] <doko> pitti: what package would you suggest for bug #760544?
[16:29] <mdz> apw, bryceh, I haven't been able to do much with bug 747205 today unfortunately. silbs has been in meetings and I need her to grant me access
[16:30] <pitti> doko: my initial guess is compiz, I assigned it there
[16:30] <doko> ok, thanks
[16:31] <SpamapS> jamespage: ping re your conditional patch question
[16:32] <jamespage> SpamapS: hey
[16:32] <SpamapS> jamespage: what about #ifdef ?
[16:33] <jamespage> SpamapS: within the patch itself? that was my thinking on option #3 - rework the patch using #ifdef
[16:34] <SpamapS> jamespage: I haven't looked at the patch. Would that be super difficult?
[16:34] <apw> mdz no worries
[16:36] <jamespage> SpamapS: do-able if a little fiddly
[16:37] <jamespage> some of the patch is already written this way - it might not take to long to sort out the rest of it.
[16:39] <mdz> apw, ok, I'm on it now
[16:39] <mdz> apw, GL_MAX_TEXTURE_SIZE = 4096
[16:40] <apw> mdz, i assume the width of her display, plus the monitor is less than that in pixels
[16:41] <mdz> apw, her displays are 1440x900 and 1920x1200
[16:42] <dholbach> seb128, 'harvest' is now in natty
[16:42] <seb128> dholbach, great ;-)
[16:43] <mdz> apw, can you think of anything I might try to get the display to switch back on?
[16:43] <mdz> xrandr --auto gets me a black screen with a mouse cursor
[16:46] <mdz> suspending and resuming gets me a text console with a mouse cursor over it :-)
[16:51] <mdz> tjaalton, around?
[16:52] <roadmr> hey! I notice the ubuntu-netbook package is no longer installed on our netbooks, and the package description now says it will be used only for armel systems
[16:52] <roadmr> so will the ubuntu-netbook not be used in intel netbooks going forward?
[16:52] <apw> mdz hmmm, well i feel we don't even know if the GPU is hung
[16:52] <apw> when it gets into this state, knowing that would be helpful as well i think
[16:55] <apw> mdz i believe the contents of /sys/kernel/debug/dri/0/i915_gem_seqno will tell us
[16:57] <kirkland> AlanBell: sorry, i'm pretty tied up today
[16:57] <kirkland> AlanBell: what's up, though?
[16:57] <kirkland> AlanBell: there's a few people willing/interested to work on this
[16:57] <AlanBell> np, just wanted to know who is planned to provide the server for test/deployment?
[16:58] <AlanBell> I have proposed some summit changes to integrate summit and etherpad nicely
[17:03] <hallyn> Daviey: all right, so again - for packages in universe (vmbuilder), I can just dput now?  Either release team will have to look at it and approve (or deny - I can take rejection), or it'll go through with no problems, but no reason for me not to dput?
[17:05] <mdz> apw, how can I check?
[17:05] <mdz> sysfs?
[17:05] <mdz> apw, /sys/kernel/debug/dri/0/i915_error_state shows "no error state collected"
[17:05] <mdz> so does .../64/i915_no_error_state (is it normal to have two?)
[17:06] <apw> what does /sys/kernel/debug/dri/0/i915_gem_seqno say
[17:07] <mdz> apw, in both i915_gem_seqnos, "current sequence (render ring)" and "IRQ sequence (render ring)" are incrementing, and everything else is zero
[17:07] <apw> ok so that says to me that things are continuing normally, that things are being displayed
[17:08] <apw> bryceh, ^^ would that make sense to you as well
[17:18] <doko> bdmurray: is this your bot? bug #766129 ?
[17:20] <bdmurray> doko: looking
[17:20] <bdmurray> doko: yes
[17:21] <doko> bdmurray: please could you avoid filing these reports? doesn't add any value, it's a corrupt .deb
[17:22] <Daviey> hallyn, yes!
[17:22] <doko> or a damamged file system
[17:22] <mdz> tseliot, around?
[17:23] <tseliot> mdz: what's up?
[17:23] <hallyn> Daviey: one :)
[17:23] <bdmurray> doko: to be clear my bot is ubuntu qa's bug bot which moved it to the openjdk-6 package and didn't file the bug.  additionally it makes some checks regarding the number of comments etc.  I'm pretty sure these types of bugs re corrupted debs aren't reported in newer releases.
[17:23] <doko> hmm, ...
[17:25] <mdz> tseliot, I'm trying to get to the bottom of bug 747205. any chance you could have a look?
[17:25] <mdz> I'm in front of the machine now and will only have access to it for another 35m or so
[17:26]  * tseliot has a look
[17:26] <bdmurray> doko: I'm double checking the code that stops the reporting of these now
[17:27] <doko> pitti: would it be possible to update apport for older releases for issues like these? ^^^
[17:28] <bdmurray> doko: the check is actually in apt
[17:28] <tseliot> mdz: can you reproduce the problem if you start the Classic desktop without 3D effects?
[17:29] <rickspencer3> tseliot, before ou go down that route, bryceh did a ton of investigation on this
[17:29] <rickspencer3> tseliot, https://bugs.freedesktop.org/show_bug.cgi?id=35870
[17:29] <mdz> tseliot, if she logs in with classic, it shows the same problem
[17:29] <pitti> doko: sure, if we have a fix, it's easy to backport, and justifies an SRU as well IMHO
[17:29] <tseliot> mdz: ok
[17:30] <tseliot> rickspencer3: thanks for the link
[17:30] <doko> pitti: well, looks as it would be on mvo's plate :-/
[17:30] <tkamppeter> stgraber, hi
[17:31] <bdmurray> there is an ENOSPC check in lucid
[17:31] <mdz> tseliot, very interesting discovery: https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/747205/comments/57
[17:32] <tseliot> mdz: ok, maybe I know what's going on
[17:32] <tkamppeter> stgraber, cnijfilter-common is a package from Canon, not a Ubuntu package. It is a closed-source printer driver which exists only for i386 arch not for x86_64, probably therefore the ":i386".
[17:33] <AlanBell> kirkland: reading back through the mails, is the plan that James Troup will provide a server if it is packaged to a satisfactory standard?
[17:33] <tseliot> mdz: log in with the user which can reproduce the problem and type the following command: rm ~/.config/monitors.*
[17:33] <mdz> tseliot, maybe something in the compiz settings?
[17:33] <jdstrand> @pilot out
[17:34] <bryceh> mdz, tseliot, heya
[17:34] <tseliot> mdz: either that or the gnome-display settings (I suggested to clear the latter)
[17:34] <tseliot> bryceh: hi
[17:35] <bryceh> to save you guys a little work...  I investigated a lot of the (apparent) dupes of this issue yesterday.  I've had other folks test some various theories, but I *think* the issue is just lack of kernel support for Ironlake/Arrandale
[17:35] <tseliot> bryceh: https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/747205/comments/57
[17:35] <mdz> tseliot, bingo
[17:35] <tseliot> mdz: :)
[17:36] <mdz> tseliot, I've attached the monitors.xml to the bug
[17:36]  * tseliot has a look
[17:39] <tseliot> mdz: maybe one of the resolutions listed there caused the problem (probably 1920x1200 for VGA1)
[17:40] <tseliot> mdz: it's still weird though
[17:42] <mdz> tseliot, I think it has to do with having the laptop display switched off
[17:42] <mdz> she says that she does that normally
[17:45] <tseliot> mdz: the display app remembers the last settings and loads them when the session starts. So yes, it can be that
[17:45] <bryceh> mdz, tseliot, right, from what I've seen in other bug reports, it happens on modesetting changes, but it varies from person to person
[17:45] <bryceh> there are a variety of ironlake/arrandale patches proposed at http://lists.freedesktop.org/archives/intel-gfx/2011-April/thread.html#10071 but not yet upstream, including several changes to ironlake's modesetting functionality
[17:46] <bryceh> so I think the next step for this bug is to test that kernel
[17:46] <bryceh> I asked apw and tgardner if we could get a build of that kernel for folks to test
[17:47] <mdz> bryceh, it's starting to look like maybe it's related to the external monitor being primary
[17:47] <mdz> testing that on its own now
[17:47] <bryceh> mdz, tseliot, one other step you could take if you want to make good use of this testing time:
[17:47] <mdz> switching it to be primary didn't break it (and also didn't get saved across sessions)
[17:48] <bryceh> install xdiagnose and tick on the 'Kernel Debug" flag, which will enable the modesetting debugging messages in dmesg, and collect a dmesg when reproducing the problem
[17:48] <tseliot> mdz: because you didn't do it from the gnome app. That's the only way it can remember its settings
[17:49] <tseliot> mdz: the gnome app has no way to set the primary output
[17:49] <tseliot> you should edit the xml file manually
[17:49] <mdz> bryceh, we have "extra graphics debug messages", "display boot messages", "disable VESA framebuffer driver" and "disable PAT memory"
[17:49] <mdz> I assume it's the first one we want?
[17:49] <mdz> tseliot, oh
[17:49] <mdz> and the gnome app has no way of setting which one is primary afaik
[17:50] <tseliot> yes, it's what I said ;)
[17:50] <bryceh> mdz, yes the first one
[17:51] <tseliot> bryceh: BTW I didn't know about xdiagnose, thanks for the tip
[17:53] <bryceh> tseliot, yep
[17:53] <kirkland> AlanBell: that was my impression from elmo's email, which required a) to be packaged, and b) to have been tested at scale
[17:54] <elmo> the testing isn't a requirement
[17:54] <bryceh> mdz, tseliot, ok looking at apw's review of the patches I mentioned, he's doubtful they'll help but will be spinning up that kernel for testing
[17:54] <kirkland> AlanBell: I think we have put a significant dent in (a), if not solved entirely to satisfaction
[17:54] <elmo> we'll be running gobby anyway/additionally, so if you want to make UDS the 'at scale load' you can
[17:54] <apw> bryceh, yep, that is in the queue to build sometime to day
[17:54] <kirkland> AlanBell: I think jcastro and statik were going to try and organize an Ubuntu community-wide scale test of Etherpad
[17:56] <kirkland> AlanBell: okay, so see elmo's comment; we'll offer both gobby and etherpad at UDS-O and let the two offerings duke it out;  if etherpad fails miserably, we'll have gobby too
[17:56] <smb> @pilot out
[17:56] <mdz> bryceh, ok, did that, but I don't see anything extra in dmesg
[17:56] <bryceh> apw, excellent; I think even if it doesn't provide a fix in this particular case that'll help as we go forward, since ickle appears to be slotting his patches in there for people to test
[17:56] <apw> bryceh, yeah seems appropriate, and indeed what we planned those builds for
[17:56] <kirkland> elmo: are you willing to run an etherpad.ubuntu.com on your hardware, or should we plan on running our own in ec2, or some such?
[17:57] <mdz> I do see this though: [343681.753493] compiz[24098]: segfault at 2e38f80 ip<PHONE_NUMBER>e38f80 sp 00007fff71356758 error 15
[17:57] <elmo> kirkland: that depends on the state of the packaging
[17:57] <elmo> kirkland: but we're not pointing u.c at ec2 :-P
[17:57] <mdz> bryceh, tseliot, copying in the old monitors.xml reliably reproduces the problem
[17:57] <kirkland> elmo: understood, of course
[17:57] <bryceh> mdz, ok thanks, well it's a long shot
[17:58] <stgraber> tkamppeter: ok, thanks. is that something that jockey (or similar stuff) might pull directly from Canon or is that manually installed by the user for sure ?
[17:58] <stgraber> tkamppeter: (just trying to understand if that's something that Ubuntu might have installed somehow and that we should fix or if that's just a case where the user did something unsupported and the bug should therefore be closed)
[17:58] <bryceh> mdz, tseliot, there's a number of sections in that monitors.xml; maybe try narrowing it down to the particular section?
[17:59] <kirkland> elmo: latest packaging is in ppa:etherpad/ppa, if you'd like to test and/or review
[17:59] <mdz> bryceh, I'm pretty sure I saw this problem myself
[17:59] <kirkland> elmo: jamespage has vastly improved my initial cut with his java build mastery
[17:59] <mdz> on a different chipset
[18:00] <stgraber> tkamppeter: nevermind, bug report says it was done from a script
[18:00] <mdz> I use a similar setup to Jane with an external monitor as primary
[18:00] <tseliot> bryceh, mdz: yes, one of those combinations in  monitors.xml will show the problem
[18:00] <kirkland> elmo: jamespage can confirm, but I believe we're at a point at which we'd like your IS feedback
[18:01] <speakman> how do I find out which package installed another package?
[18:01] <tseliot> bryceh, mdz: I see both LVDS and LVDS1 in monitors.xml. I think it's a bit... unusual
[18:01] <jamespage> elmo, kirkland: almost - I've been really struggling on removing the last bundled jar;
[18:01] <bryceh> mdz, I'd be interested to see a report on that; what I'm basing my theory that it is arrandale-specific on is that I went through all natty bug reports we've received relating to external monitor or modesetting->blank issues, and found that out of about a dozen or more bug reports, only 2 were *not* arrandale, and one of those two had very different symptoms
[18:02] <kirkland> jamespage: which jar is that?
[18:02] <mdz> tseliot, yes, that's what triggered my memory in fact
[18:02] <elmo> kirkland/jamespage: cool, I'll have a look when i can - thanks for working on this
[18:02] <mdz> I remember having a problem similar to this when all the xrandr display names changed
[18:02] <mdz> VGA->VGA1 etc.
[18:03] <tseliot> yep
[18:03] <bryceh> tseliot, yeah there was a name change about a year ago; -ati, -nouveau, and -intel were all using different naming systems for the output, and they unified them all to be consistent
[18:03] <jamespage> kirkland: well its a patched version of rhino; but I can't tell which version (might be 1.6) and it gets shaded alongside Rhino 1.7R1 so both can co-exist
[18:03] <jamespage> kirkland - really horrible :-(
[18:04] <jamespage> kirkland: jar name is rhino-yuicompressor.jar
[18:04] <tseliot> bryceh, mdz: but still, from what I recall, the gnome app should skip the configurations that don't match the current outputs. This in theory, of course...
[18:04] <jbicha> hi, I'm hunting for a sponsor for bug 426215
[18:05] <kirkland> jamespage: okay, yeah, that's nasty
[18:05] <tkamppeter> stgraber, Canon does not do LSB-based downloadable printer driver packages (yet), so the user must have installed something manually which finally triggered the installation of the mentioned package.
[18:05] <kirkland> jamespage: we will need to clean that up for archive inclusions
[18:05] <stgraber> tkamppeter: ok, thanks
[18:05] <kirkland> jamespage: but I'd hope that we can forgive that one for a trial run of Etherpad at UDS-O
[18:06] <jamespage> kirkland: i'd like to spend a few more hours on it tomorrow; but I am running out of available time...
[18:06] <kirkland> jamespage: k
[18:07] <bryceh> mdz, tseliot, hmm interesting... looking through these other arrandale/modesetting bug reports, I'm noticing their monitors.xml don't have this LVDS/LVDS1 issue but many of them do show LEN as the monitor manufacturer
[18:07] <bryceh> maybe that's coincidental though
[18:10] <tseliot> bryceh: a half broken EDID, perhaps?
[18:10] <bryceh> tseliot, we've certainly seen that before...
[18:11] <bryceh> tseliot, LEN is lenovo?  could be just that it's a popular brand amongst arrandale purchasers
[18:11] <tseliot> bryceh: yes, I think so
[18:12] <mdz> bryceh, what's written on the front is "iiyama"
[18:12] <mdz> (of Jane's monitor)
[18:13] <bryceh> mdz, I mean the laptop panel is LEN
[18:13] <mdz> bryceh, oh. yes, it's a lenovo x201
[18:14] <mdz> the external one is iiyama
[18:15] <AlanBell> kirkland: elmo: my summit modification, links on the schedule http://libertus.co.uk:8000/uds-o/2011-04-14/ to pages like this: http://libertus.co.uk:8000/uds-o/meeting/full-of-awesome/
[18:17] <AlanBell> kirkland: elmo: so the etherpad server gets hidden and exposed through the summit UI in an iframe for each meeting
[18:17] <bryceh> mdz, hmm, examining the product numbers for these that are all LEN, they have differing product id's.  So it probably is just coincidental.
[18:22] <bryceh> mdz, btw one question I think has not been discussed on the bug so far - I assume this is a regression from maverick (where it was working fine), and immediately started after upgrading to natty?
[18:23] <stgraber> AlanBell: that's really cool
[18:23] <AlanBell> thanks stgraber
[18:25] <bryceh> mdz, the plan of attack I'm thinking about is a) have people test the intel-drm-next-proposed kernel to verify it's still an issue upstream (and if not, locate the patch for kernel team to backport), b) (re-)forward the bug upstream, c) do a git bisect between maverick and natty kernels to isolate what patch brought the problem
[18:28] <mdz> bryceh, understood. now that we know how to work around and reproduce the problem, we should make quick progress
[18:28] <SpamapS> ScottK: re the opendkim issue.. it does appear that opendkim doesn't daemonize properly.. :-P
[18:29] <ScottK> SpamapS: Right, but looking at the init, I don't see anything particularly unusual.
[18:29] <ScottK> Since upstream doesn't use Debian/Ubuntu, I wonder if they have a different definition of "properly"?
[18:30] <bryceh> mdz, mind attaching that debug dmesg to the report?  Even if it has nothing useful, that itself may give someone some clue
[18:30] <SpamapS> ScottK: I think the issue is that they are not releasing stdin properly
[18:30] <mdz> bryceh, I've emailed it to you, so you can decide if it's useful and attach if so
[18:31] <bryceh> mdz, comment #59 is interesting; I'd like to see the monitors.xml produced from that action (so we know what settings go with the error)
[18:31] <SpamapS> ScottK: its broken on RH/CentOS too
[18:31] <mdz> bryceh, it's a bit annoying because some wifi driver is spamming dmesg
[18:31] <bryceh> yeah
[18:31] <ScottK> SpamapS: I'd really appreciate it if you could explain this in the thread in a way that the upstream will understand.  He's generally very reasonable.
[18:32] <mdz> bryceh, emailed you the other monitors.xml
[18:33] <SpamapS> ScottK: yeah, I think the attempt to dup2 devnull and stuff is just wasted.. setsid() pretty much takes care of all of that once the parent exit()'s .. will get a patch together and then explain to upstream
[18:34] <bryceh> mdz, thanks
[18:34] <ScottK> SpamapS: Thanks.
[18:47] <tkamppeter> pitti, hi
[18:57] <AlanBell> elmo: any idea what the hostname would be? something like pad.ubuntu.com perhaps?
[18:57] <elmo> AlanBell: sure
[18:58] <AlanBell> perfect
[19:45] <tkamppeter> any buildds expert around? It is about bug 710881, last comment.
[20:13] <mvo> stgraber: I followed up in the python-apt bug, got a test failure. given that the code there is a bit fragile I am inclinced to do the fix as a SRU instead
[20:16] <stgraber> mvo: ok, my understanding was that this bug was basically breaking some ARM image where SRU wouldn't do much good (as it wouldn't fix their sources.list)
[20:18] <mvo> stgraber: ok, I check back with ogra
[20:18] <mvo> stgraber: thanks a bunch, test failure needs investigation then, put on my agenda for tomorroow morning (yet again :)
[20:21] <stgraber> mvo: oh, I see the test failure, that's weird. I'll see if I can easily fix that before you're back tomorrow morning (currently doing some test upgrades for smoser's grub issue)
[20:22] <stgraber> aptsources/sourceslist.py
[20:22] <stgraber> argh, wrong window :)
[20:26] <mvo> stgraber: ok, cool
[20:26] <mvo> I go to bed now
[20:36] <mar> Hello. Anyone has idea what's this dot? Looks like dead pixel ;) (top toolbar, white dot, right) http://mar.lt/uploads/Screenshot.png
[20:37] <ohsix> mar: it could be a broken notification from some app
[20:37] <ohsix> nm
[20:38] <ohsix> dunno w/unity
[20:38] <mar> looks like it's skype
[20:38] <ohsix> missing its icon?
[20:38] <mar> i managed to click on it :)
[20:38] <ohsix> nice
[20:39] <mar> ohsix: don't really know, i've seen skype icon before so it's not missing
[20:39] <mar> do I need to report it somehow? :)
[20:41] <ohsix> probably, but it could be a temporary problem, try quitting skype and restarting it
[20:41] <mar> it'll probably resolve that way
[20:42] <mar> i also have problem skype icon not showing some times, is it common?
[20:42] <mar> i mean it's running, minimized but no icon there
[20:42] <ohsix> i don't know; i don't use skype
[20:43] <ohsix> if there was a problem you'd probably have to report it directly to them, i'm not sure what the procedure is for sw in the partnetr archive
[20:43] <jcastro> kees: I sent a mail to TB about adding those linaro folks to ~uds-planners, if you could do that today before EOD I would love you.
[20:47] <kees> jcastro: ~uds-organizers ?
[20:47] <jcastro> in launchpad
[20:47] <jcastro> sorry, ~uds-planners
[20:47] <kees> you mean uds-organizers ? (there's not uds-planners)
[20:48] <jcastro> ah right: https://launchpad.net/~uds-organizers/
[20:48] <jcastro> (sorry, long day)
[20:49] <kees> jcastro: sure, done.
[20:49] <mar> https://bugs.launchpad.net/ubuntu/+source/skype/+bug/764828
[20:49] <mar> found it :)
[20:50] <ohsix> nice
[21:00] <ScottK> slangasek: Might https://bugs.launchpad.net/bugs/759525 be multi-arch related?
[21:12] <slangasek> ScottK: nope, that's the other upstream sort of "multiarch" being mentioned in the backtrace :)
[21:12] <ScottK> OK.
[21:12] <ScottK> Hopefully doko or barry will look at it then.
[21:12] <ScottK> Thanks.
[21:12] <slangasek> ScottK: could be that the code is being built with the wrong optimization options; we don't want sse4 in the default code path, which seems to be what's happened here
[21:13] <ScottK> Good point.
[21:13]  * barry reads up
[21:14] <doko> barry: about jsquery, it's debian policy to share the jquery.js. so better find out what is wrong with the one in natty. do 2.6, 3.1 and 3.2 work?
[21:14] <barry> doko: personally i think it's a silly policy
[21:14] <doko> slangasek, ScottK: no, it's independent of optimization options, the implementation is selected at runtime depending on the cpu
[21:15] <barry> doko: i do not yet know.  i'm still trying to nail down exactly what's going on
[21:16] <slangasek> doko: right, and I see see4_2 in the cpuinfo flags... so it doesn't seem to be a bug with the selection
[21:17] <slangasek> and no segfault for me here with that command
[21:18] <doko> hmm, this is lucid
[21:18] <slangasek> ah
[22:46] <matttbe> Hi,
[22:46] <matttbe> I'm looking for a sponsor in order to upload our cairo-dock packages on Ubuntu Natty.
[22:46] <matttbe> Bzr branches have been linked to these bugs reports and I've also joined the .debian.tar.gz generated by 'debuild' command and a link the original tarball given by the upstream.
[22:46] <matttbe> https://bugs.launchpad.net/bugs/723994
[22:46] <matttbe> https://bugs.launchpad.net/bugs/723995
[22:47] <matttbe> Is somebody can help me by uploading these packages?
[22:47] <matttbe> Should I have to upload another file or add another comment?
[22:47] <ScottK> Subscribe ubuntu-sponsors to the bug if you didn't.
[22:48] <matttbe> done :)
[22:50] <matttbe> These bug reports are available there: http://reports.qa.ubuntu.com/reports/sponsoring/
[22:52] <vish> couldnt the cairo-dock team (create and) get a PPU access?
[22:53] <vish> (they are active and maybe they could have been uploaded a while ago)
[22:53] <SpamapS> ScottK: so far I'm not able to reproduce the opendkim bug at all
[22:54] <ScottK> SpamapS: OK.  I didn't manage either, but I was sure I was doing something wrong.  Would you mind joining the upstream discussion?
[22:54] <ScottK> I'm kind of out of my depth in it.
[22:54] <matttbe> Hello vish :)
[22:54] <matttbe> vish: What's a PPU? The possibility to only upload a few packages directly on Ubuntu repositories?
[22:54] <SpamapS> ScottK: yeah I'll jump in if this last ditch effort (putting usleeps in a few places) doesn't reproduce it
[22:54] <maco> matttbe: yes
[22:54] <ScottK> Thanks.
[22:55] <maco> matttbe: "Per Package Uploader"
[22:55] <vish> matttbe: hey.. :)  per-package-upload access  some packages have them not sure what the process is though
[22:55] <matttbe> oh interesting
[22:55] <maco> vish: ask the tech board to create a package set
[22:55] <matttbe> I thought that this PPU only exists on Debian
[22:55] <maco> give a list of which packages they are too
[22:56] <maco> they vote, and colin makes a packageset
[22:56] <maco> matttbe: well anyone with upload rights overall could still upload it. NMU approval isnt a thing we do
[22:56] <maco> its just that someone who isnt trusted to touch *everything* can be trusted to touch *some* things
[22:57] <matttbe> ok
[22:57] <vish> matttbe: you guys could go for that.. /me wants cairo-dock fixes asap ;)
[22:57] <SpamapS> You don't have to have a package set either
[22:57] <maco> hmm...maybe the DMB can vote on packageset creation too? not sure
[22:57] <maco> SpamapS: true
[22:57] <SpamapS> you can just request access to a few packages that you are interested in maintaining
[22:57] <matttbe> vish: sure :)
[22:57] <maco> but if you're going to be doing a group of people with the same set of packages, then its easier administratively
[22:57] <maco> if its only one person, then sure, just list which packages you want to be able to upload
[22:58] <maco> Laney: can we vote on packageset creation or just packageset access?
[22:58] <maco> ...i should ask someone who's not also new to the dmb, huh
[23:00] <matttbe> it's easy, it's only one person (me) and only 2 packages: cairo-dock and cairo-dock-plug-ins.
[23:01] <matttbe> these packages doesn't have a library which is used by other packages (there is a library but only used by our plug-ins)
[23:07] <Laney> maco: Yeah, I think so.
[23:08] <Laney> also, please help progress the mail applications going on!
[23:08]  * Laney whips the DMB
[23:08] <maco> Laney: i'm in the middle of typing questions for cyphermox
[23:09] <Laney> excellent :-)
[23:09] <maco> matttbe: in that case https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda
[23:10] <matttbe> maco: thank you!
[23:11] <Laney> how many packages is it? If it's just a couple then PPU is probably preferable
[23:11] <Laney> also I'd /really/ like to see this Debian situation with cairo-dock resolved
[23:11] <maco> Laney: 2
[23:12] <matttbe> Laney: yes, me too...
[23:12] <maco> so yeah, matttbe should just request PPU
[23:13] <ohsix> situation?
[23:14] <matttbe> ohsix: https://bugs.launchpad.net/ubuntu/+source/cairo-dock-plug-ins/+bug/657564
[23:14] <ohsix> thanks
[23:15] <Laney> in general making it syncable
[23:16] <matttbe> ohsix: the official maintainer of cairo-dock debian packages want to split all plugins (more than 50 packages, with a few wrong dependences, wrong names, etc.) and he doesn't want to remove a few patches.
[23:16] <matttbe> And we don't know what to do...
[23:37] <ohsix> matttbe: fwiw, with split packages at least their relationship can be defined; presumably themes will also be packaged and depend on the right ones to get it going; and an "-all" metapackage that would just depend on them all
[23:40] <ohsix> matttbe: i've seen projects do well to clean their own house when interacting with people who distribute their software :P
[23:40] <matttbe> ohsix: yes but if we split packages and finally we only can install all of them, it's strange...
[23:40] <matttbe> maybe we can have something like compiz packages...
[23:41] <matttbe> yes but :) I also have to maintain these packages for our ppa and repository
[23:41] <ohsix> compiz split their own plugins up when they merged with beryl didn't they? sorted by quality & origin
[23:42] <ohsix> similarly, gstreamer has good/bad/ugly and base
[23:42] <matttbe> and we have plug-ins and plug-ins-integration :)
[23:43] <ohsix> are all the plugins of equal quality?
[23:43] <matttbe> mmh no
[23:43] <matttbe> the -integration plug-ins are important
[23:44] <ohsix> what percentage might you consider well done and vital?
[23:45] <matttbe> some of them are used by the default theme so it can be interesting to install them. Some plug-ins are used by other, etc.
[23:45] <matttbe> it's hard to give you a percentage but... yes maybe we can create a few groups
[23:51] <ohsix> it might help to keep focus on the important first class ones too
[23:52] <ohsix> if you had groups, people doing themes could say which group & version instead of exaustively listing them, if they do at all
[23:54] <matttbe> ohsix: yes but if these people do that, it'll be only for Debian and Ubuntu users
[23:54] <matttbe> or we've to create these groups into the code...
[23:54] <ohsix> sure, i was talking about your grouping of them though
[23:54] <ohsix> if you chose to do so
[23:55] <matttbe> and if we have a look to compiz packages, they are split because these plug-ins are not in the same git branch...
[23:55] <ohsix> well, that's one reason
[23:56] <matttbe> but yes, I'll try to find something else in order to sync Debian and Ubuntu version


[02:44] <miseria> "ajedrez batalla entre negros y blancos, al final del final el blanco no tendra peones y el negro prevalecera" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
[07:38] <ppisati> moin
[08:19] <xnox> smb: i'll be uploading dmraid/mdadm into the archive today, blocked in proposed. I didn't manage to get migration from dmraid -> mdadm smooth yesterday.
[08:20] <xnox> (a) kpartx is not executed on mdadm assembled arrays, like it was on dmraid -> thus one doesn't get all partitions present. (and adding a kpartx run to udev rule, didn't do it for me =( )
[08:21] <xnox> (b) and i didn't get compat symlinks for kpartx generated devices in above.
[08:22] <xnox> at least we'll drop dmraid45 dependency, and one can test mdadm assembly from the archive.
[08:22] <xnox> (i'll disable imsm and ddf assembly by mdadm with a config file)
[08:36] <smb> xnox, ok, I can check it out pulling the proposed versions. partitions... weird I have partitions on my test raid5 and beside of the downside of mdadm thinking the array is degraded I at least believe to have had partitions with mdadm
[08:41] <xnox> smb: i only get a device for container (/dev/md/imsm0 or /dev/md127) & the array (/dev/md/Volume1 or /dev/md126), but not partitions in the array.
[08:42] <xnox> smb: mdadm does think the array is degraded, even though that is a lie =) as containers never leave inactive state... and our check believed it was.
[08:42] <xnox> (or e.g. the array can be in-progress rebuilding)
[08:42] <smb> xnox, Hm, I have to check with the version you uploaded, but I got md127px devs, too
[08:44] <xnox> smb: interesting.
[09:00] <smb> xnox, Ok, so just to confirm, with the dmraid which has no support for ism at all plus old mdadm (+udev rule addition to act on isw_members), I currently get /dev/md126p? (not 127) and even /dev/md/Volume0p? symlinks.
[09:02] <xnox> smb: ok. I am using dmraid with ism support compiled, but disabled to not activate the devices, plus mdadm with rules to assemble isw_members, i only get naked devices/symlinks without partitions.
[09:03] <xnox> i wonder if i really should not compile isw in dmraid.
[09:03] <smb> xnox, odd... Well I will replace my versions with your uploaded ones and check whether this happens to me, too.
[09:04] <smb> I guess (iirc) if the script called by udev does not act on isw it should not matter whether dmraid supports things or not
[09:05] <smb> And I would guess that is where you handle the config setting
[09:40]  * apw hates rebasing...
[09:40] <apw> morning
[09:41] <smb> apw, Morning, as long as its only a git tree and not yourself you rebase...
[09:45] <apw> yeah at least i can reset my tree on error
[09:46] <apw> sounds like fun is being had with mdraid
[09:54] <smb> apw, Software is always fun... changing software doubly so... :-P
[09:58] <psivaa> sbeattie: bjf: we have this failure in armadaxp SRU, with precise kernel: https://jenkins.qa.ubuntu.com/view/SRU%20Kernel/job/sru_kernel-precise-generic-armhf_omap4_armada1-serial/97/testReport/autotest/ubuntu_qrt_kernel_security/test_kernel_security_py/?
[09:59] <psivaa> i reran the test to confirm if it's persistent and it occurred during both runs.
[10:08] <cking> apw, do you mind syncing packages thermald and health-check some time today for me?
[10:13] <infinity> cking: sync from Debian?  I can do that.
[10:14] <infinity> cking: Done.
[10:14] <infinity> cking: Hrm, powerpc, but no ppc64 or ppc64el?
[10:15]  * cking slaps himself, bad me
[10:15] <infinity> cking: Do you have reason to believe it won't work with 64-bit userspace?
[10:16] <infinity> cking: (I assume with "powerpc", you're already assuming it works with 64-bit kernels...)
[10:16] <cking> infinity, no, I forgot to put those arches in, nnggg
[10:16] <cking> i guess another tweak and upload is now required...
[10:17] <infinity> cking: Well, I can fix it in Ubuntu right now for you, and you can fix it in Debian whenever.
[10:17] <infinity> cking: ppc64 is an unofficial arch in Debian, and ppc64el doesn't exist yet at all, so...
[10:17] <cking> infinity, if you can, that would be awesome, and I can fix it for the next time I do any other bug fixes
[10:19] <cking> can't believe I did the tricky part and screwed up the easy bit
[10:19] <infinity> cking: No arm64 yet?
[10:19] <cking> infinity, if I get access to H/W I can try it out.. and then add that too ;-)
[10:19] <infinity> Heh.
[10:19] <infinity> cking: Oh, also, you don't need all the "linux-" prefixes, it just clutters up the control file.
[10:20] <infinity> cking: "amd64" *is* "linux-amd64", there's no ambiguity.
[10:20] <cking> ah, ok
[10:21] <infinity> any-i386 == i386, hurd-i386, kfreebsd-i386, but i386 on its own is just i386, which is the Linux port.
[10:21] <infinity> So, I'll fix that up too while I'm in here, and you can sync it back when you care.
[10:21] <cking> ok, thanks, I remember that for next time I do anything so arch specific, like never I hope
[10:22] <infinity> Well, it would be perfectly reasonable, IMO, to just have it be "any" as well, if it'll FTBFS on unsupported arches.
[10:22] <infinity> It's only bad if it builds but is completely broken subsequently.
[10:22] <infinity> (or linux-any, if it's linux-specific)
[10:23] <cking> ok, but I hate seeing FTBFS on other arches when I know it won't work..
[10:23] <infinity> Heh, fair enough.  To each their own.
[10:23] <infinity> I like the red FTBFS items as a subtle reminder that I have things to fix. :)
[10:23] <cking> very true
[10:25] <infinity> cking: Uploading this: http://paste.ubuntu.com/6953727/
[10:25] <xnox> now i'm enjoying UEFI which selects the wrong hard-drive to boot off...
[10:25] <infinity> cking: unless you have reason to believe x32 wouldn't work.
[10:27] <cking> infinity, well, I'm not 100% sure, it may just go horribly wrong, I can't recall what's required for x32 special cases
[10:27] <cking> let's see if it breaks, I can always fix it later :-)
[10:27] <apw> heh
[10:27] <infinity> cking: There's some syscall duplication, and, of course, not effing up your pointer sizes, but otherwise I expect anything that works on amd64 to Just Work on x32.
[10:28] <infinity> cking: Should be testable with gcc-multilib installed and gcc -mx32
[10:28] <infinity> Anyhow, uploading for kicks.
[10:28] <cking> ok, I can give it a spin later today :-)
[10:29] <infinity> We don't build for x32 in Ubuntu anyway, this is more for the benefit of the unofficial Debian x32 port when you go and merge this back.
[10:29] <cking> yup, i've tinkered with that a while ago
[10:30] <infinity> cking: As for arm64 hardware, do you have access to batuan?
[10:31]  * cking checks, yep
[10:31] <infinity> cking<EMAIL_ADDRESS>from batuan, then.
[10:31] <cking> ack
[10:32] <infinity> cking: Password as insecure as you suspect it.  Full sudo.  Please make a user and work in your ~
[10:32] <cking> shiney
[10:32] <infinity> Err, and there's a whopping 1.7G free.  Let me see who needs slapping.
[11:04] <xnox> smb: i believe i had invalid half of GPT partition table (either primary or backup) recreating the array and recreating partition table, now results in proper md126p? and md/Volume1p? devices to appear.
[11:04] <smb> xnox, Errm, I hate to say I think you forgot a little "exit 0" in the dmraid-activate script as well
[11:05] <smb> Given that after install there is no (dm) raid for me and in the check for nomdmonddf looks odd too
[11:06] <smb> Oh its negated...
[11:06] <smb> but anyway exit 0 is just wrong
[11:07] <smb> xnox, Though maybe phrasing both as "mdadm xxx assembly disabled by boot option" would be less hm... strange?
[11:12] <xnox> smb: yeah missing exit 0.
[11:13] <xnox> correcting text.
[11:15] <smb> xnox, I guess it should be about what is default. But I catch myself going something disabled ... something enabled... wait were those options not both nomd...bla...? :)
[11:15] <xnox> =)))
[11:16] <xnox> smb: also the /etc/default/grub.d/dmraid2mdadm.cfg
[11:16] <smb> Oh, _there_ those come form
[11:17] <smb> I was already wondering... did we have a grub.d there ever before?
[11:17] <xnox> smb: that's fairly new. we have /etc/grub.d/ for template generators, /etc/default/grub for default "settings" and /etc/default/grub.d/ for sourced settings....
[11:18] <xnox> e.g. kexec-tools uses the last one as well to set crashkernel= line
[11:18] <smb> xnox, Neat to know for me ... There might be some use for that for Xen...
[11:29] <smb> xnox, Ok, so the switch to md works for me and has partitions, too.
[11:30] <smb> So the only problem I saw was the "exit 0"
[11:31] <smb> And maybe but thats RTFRN the surprising source of the nomd* grub cmdline args
[14:19] <jsalisbury> apw, It looks like the amd64 kernel is missing for the 3.14-rc3 mainline build:
[14:19] <jsalisbury> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-rc3-trusty/
[14:44] <pkern> Is there an relatively easy way to add a suffix to the Ubuntu kernel version when compiling it? "DEB_BUILD_OPTIONS=parallel=14 AUTOBUILD=1 NOEXTRAS=1 /usr/bin/time fakeroot debian/rules binary-generic" is the current build command I use. |:
[14:51] <arges> jsalisbury: I was going to mention the same thing. : ) was just going to test with latest
[14:52] <jsalisbury> arges, I haven't tried to build manually yet, or search upstream to see if its a known issue.
[14:53] <arges> /bin/bash: line 0: cd: /home/apw/COD/linux/debian/build/tools-perarch/tools/hv: No such file or directory
[14:53] <arges> from http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/BUILD.LOG
[14:54] <arges> apw: ^^^ might want to look
[15:03] <apw> jsalisbury, yep upstream does not build on that arch.... sucks to be it
[15:03] <jsalisbury> apw, whoops
[15:03] <apw> pkern, add your suffix to debian.master/changelog, to the first version entry there
[15:03] <apw> arges, meh mainline smainline
[15:08] <hallyn> smb: so I'm not sure if you were waiting for more info from me about the overlayfs-whiteout patch...  pls ping me if you are
[15:13] <apw> hallyn, for me, i have not yet had a chance to think about why that one bit differs from the rest; why it is able to take the privs it needs elsewhere to copy up for instance, and yet does not do the trusted.* bit under the same elevatio
[15:13] <smb> hallyn, No, after realizing that the first part describes how whiteout is done right now, I understood the patch. Hm, oh just to make sure: this was targeted for some upstream. Or were you asking us (kernel-team) to apply it to Trusty?
[15:25] <rtg> apw, pushed 'UBUNTU: [Config] CONFIG_CGROUP_SCHED=y for ppc64el' after test build. There are a couple of other cgroup related configs that I'll make consistent as well.
[15:26] <pkern> apw: I wonder if AUTOBUILD=1 NOEXTRAS=1 does the ABI checks. So I tried -17gg.31 as a version but it did not pick 17gg as the ABI identifier. ;) I think I do want to diverge in the package name. So I'm not sure where to place the suffix. |:
[15:36] <ppisati> apw: what was the name of the pastebin cli tool?
[15:36] <apw> ppisati, pastebinit
[15:36] <ppisati> ah
[15:36] <ppisati> 10x
[15:37] <apw> pkern, no the abi on disk is always just the numeric prefix
[15:41] <hallyn> smb: there is no 'upstream' right now AFAIUI.  I cc:d Miklos, but overlayfs is not upstream so...
[15:41] <hallyn> apw: the copy-up only requires write access to the writeable layer.  That requires either uid equivalence, or *targeted* capabilities to the user namespace owning the inode
[15:42] <hallyn> apw: writing to trusted.* xattrs requires capabilities targeted to the *initial* user namespace
[15:43] <hallyn> that's the bit I'm changing, poking a hole just for trusted.overlay*
[15:52] <apw> hallyn, i mean to say overlayfs is already raiding its creds beyond the caller to do the copy
[15:52] <apw> hallyn, why is it not raising them to what it needs
[15:52] <jsalisbury> ##
[15:52] <jsalisbury> ## Kernel team meeting today @ 17:00 UTC in #ubuntu-meeting
[15:52] <jsalisbury> ##
[15:54] <hallyn> apw: it raises all creds.  But the creds are targeted to cred->userns.  Now I suppose we could look into changing the userns there.  That may be deemed a 'correct' fix.  not quite sure
[16:23] <bjf> arges, you around?
[16:23] <arges> bjf: yes
[16:23] <bjf> arges, did you SRU a netfilter: nf_conntrack commit for Precise ?
[16:23] <arges> bjf: yes
[16:24] <bjf> arges, it doesn't build :-(
[16:24] <arges> hmm...
[16:24] <bjf> arges, yeah, that's what i say
[16:24] <arges> bjf: so assuming by precise you mean 3.2
[16:25] <rtg> amb, apw, are you both happy with '[PATCH 1/1] overlayfs, xattr: allow unprivileged users to whiteout' ?
[16:25] <bjf> arges, i can fix it but i'm grumpy. yes 3.2
[16:25] <rtg> smb^^
[16:25] <arges> bjf: i'll fix it. re-building/testing it now
[16:25] <apw> rtg, i am still thinking about it
[16:26] <rtg> apw, frankly, I don't know how to think about it. too inexperienced in that subsystem.
[16:27] <apw> rtg, i need to sit down and look at it and not had any "uninterrupted time" to think on it
[16:27] <rtg> apw, log off of IRC, that'll help :)
[16:27] <bjf> arges, /tmp/kernel-bradf-RBDocT6R/build.log on tangerine
[16:34] <hallyn> apw: override_creds vs. userns will probably need to be addressed more fully at some point, but it's not entirely clear how to best do that.
[16:35] <hallyn> i.e. if a thread is running as root and wants to switch to some uid or subuid, there is no good way for it to get a good userns
[16:35] <hallyn> now i guess in those cases it doesn't matter as much.  the case where we care is override_creds to root
[16:36] <hallyn> so maybe an 'override_creds_to_init_root()' would be useful as a new helper;  for nfs and overlayfs.  but i'm guessing there'll be bikeshedding on that till summertime
[16:42] <psivaa> bjf: curious if you saw my previous message to you and sbeattie about the precise armadaxp test failure on the SRU.
[16:42] <psivaa> https://jenkins.qa.ubuntu.com/view/SRU%20Kernel/job/sru_kernel-precise-generic-armhf_omap4_armada1-serial/97/testReport/autotest/ubuntu_qrt_kernel_security/test_kernel_security_py/?
[16:42] <bjf> psivaa, i had not seen it
[16:42] <psivaa> bjf: ack, this is holding the release of the armadaxp precise kernel
[16:43] <psivaa> bjf: i've run twice just to confirm if this is reproducible and it is
[16:43] <bjf> ppisati, do you have access to one of these armadaxp boards ?
[16:44] <ppisati> bjf: uhm no, i may ask on #hwe if needed
[16:44] <bjf> ppisati, is that ike's baby?
[16:44] <ppisati> bjf: hold on
[16:44] <ppisati> bjf: yep
[16:45] <ppisati> weird
[16:45] <ppisati> that's a compile time opt
[16:45] <ppisati> either it was changed in the last upload
[16:45] <ppisati> or i don't know
[16:46] <bjf> yeah
[16:55]  * apw finds it a little off that he can build "unstable" ok but the mainline 3.14-rc3 doesn't build ...
[16:55] <apw> rtg, you didn't add any local patches did you ... hmmm
[16:56] <jsalisbury> ##
[16:56] <jsalisbury> ## Kernel team meeting in 5 minutes in #ubuntu-meeting
[16:56] <jsalisbury> ##
[16:57] <rtg> apw, other then the usual SAUCE and other ubuntization, I can't recall...
[17:05] <ppisati> psivaa: uhm
[17:05] <ppisati> [flag@luxor ubuntu-precise]$ git grep "config DEBUG_RODATA"
[17:05] <ppisati> arch/parisc/Kconfig.debug:config DEBUG_RODATA
[17:05] <ppisati> arch/x86/Kconfig.debug:config DEBUG_RODATA
[17:05] <ppisati> arch/x86/Kconfig.debug:config DEBUG_RODATA_TEST
[17:05] <ppisati> [flag@luxor ubuntu-precise]$
[17:05] <ppisati> psivaa: and indeed, it's off in my omap4 branch
[17:06] <ppisati> psivaa: what do you do wrt omap4 for that test? does it run? or do you skip it?
[17:06] <ppisati> psivaa: i guess the second
[17:06] <ppisati> psivaa: and when the last time that test was run on the armadaxp kernel?
[17:06] <ppisati> *when was
[17:07] <psivaa> ppisati: so for omap4 with precise we run it manually, and i think it's skipped. but let me confirm it in a bit
[17:08] <psivaa> for armadaxp this was run yesterday
[17:08] <ppisati> psivaa: and it failed, right?
[17:08] <psivaa> ppisati: yes
[17:08] <ppisati> psivaa: i mean, last time it was run and it passed
[17:08] <ppisati> psivaa: because IMO, that test should never run for arm
[17:09] <ppisati> psivaa: at least in precise, maybe newer kernel have that
[17:09] <psivaa> ppisati: ack, let me check
[17:11] <psivaa> ppisati: https://jenkins.qa.ubuntu.com/view/SRU%20Kernel/job/sru_kernel-precise-generic-armhf_omap4_armada1-serial/90/consoleText has that test passing
[17:11] <psivaa> ppisati: the kernel tested was 3.2.0-1630.42
[17:12] <ppisati> psivaa: that's impossible
[17:13] <ppisati> psivaa: [flag@luxor ubuntu-precise]$ grep RODATA debian/build/build-omap4/.config
[17:13] <ppisati> [flag@luxor ubuntu-precise]$
[17:13] <ppisati> psivaa: that option is off in precise/omap4, so how can the test pass?
[17:15] <psivaa> ppisati: no idea but assume you've seen the above link :)
[17:15] <ppisati> psivaa: where is the code for the test suite?
[17:16] <psivaa> ppisati: we pull the code from git://kernel.ubuntu.com/ubuntu/autotest-client-tests
[17:21] <ppisati> psivaa: are you sure those are the test that you are running?
[17:22] <ppisati> psivaa: [flag@luxor autotest-client-tests]$ grep -Ri config_debug_rodata *
[17:22] <ppisati> kernbench/config:CONFIG_DEBUG_RODATA=y
[17:22] <ppisati> kernbench/config:# CONFIG_DEBUG_RODATA_TEST is not set
[17:22] <ppisati> [flag@luxor autotest-client-tests]$
[17:22] <ppisati> psivaa: [flag@luxor autotest-client-tests]$ git grep KernelSecurityTest
[17:22] <ppisati> [flag@luxor autotest-client-tests]$
[17:27] <ppisati> psivaa: bzr+ssh://bazaar.launchpad.net/%2Bbranch/qa-regression-testing/
[17:28] <arges> apw: well 3.13.0-8-lowlatency locks up my laptop : )
[17:28] <arges> time for -9
[17:28] <psivaa> ppisati: i'm pretty sure we run the tests that's in the git repo. and i see exactly same output:
[17:29] <psivaa> usit@morgan:~/kernel-sru/branches/autotest-client-tests$ grep -Ri config_debug_rodata *
[17:29] <psivaa> kernbench/config:CONFIG_DEBUG_RODATA=y
[17:29] <psivaa> kernbench/config:# CONFIG_DEBUG_RODATA_TEST is not set
[17:29] <psivaa> usit@morgan:~/kernel-sru/branches/autotest-client-tests$ git grep KernelSecurityTest
[17:29] <psivaa> usit@morgan:~/kernel-sru/branches/autotest-client-tests$
[17:29] <psivaa> ppisati: and that's what we run the test on.. not sure how/why the tests are not skipped
[17:29] <zequence> arges: Try using nothreadirqs boot parameter
[17:30] <zequence> arges: Also, try linux-generic with threadirqs boot parameter, to see if it freezes too
[17:30] <arges> zequence: ok. is there already a bug # for this issue?
[17:30] <zequence> arges: I myself have a problem only when having a wifi driver loaded, with threadirqs. That makes the kernel freeze
[17:30] <zequence> arges: Yes. A few bugs, that may be related
[17:31] <zequence> arges: bug: 1279081
[17:31] <ubot2`> Launchpad bug 1279081 in linux (Ubuntu) "linux freezes with threadirqs parameter when rt73usb is loaded" [High,Confirmed] https://launchpad.net/bugs/1279081
[17:31] <arges> cool subscribing
[17:34] <ppisati> psivaa: the actual test is not there, how can the test be there if grepping for any string doesn't return anything?
[17:34] <ppisati> psivaa: File "./test-kernel-security.py", line 672, in test_072_config_debug_rodata
[17:34] <ppisati> psivaa: can you find that file? no
[17:34] <psivaa> ppisati: let me see
[17:35] <ppisati> psivaa: the actual test is here: bzr+ssh://bazaar.launchpad.net/%2Bbranch/qa-regression-testing/
[17:35] <ppisati> psivaa: flag@luxor qa-regression-testing]$ ls -la scripts/test-kernel-security.py
[17:35] <ppisati> -rwxrwxr-x 1 flag flag 63535 Feb 18 18:26 scripts/test-kernel-security.py
[17:36] <psivaa> ppisati: we dont use the qrt from bzr directly.. bjf may be able to give a better explanation for that
[17:37] <ppisati> psivaa: do you have a log from an omap4 kernel testing?
[17:38] <psivaa> ppisati: i dont see scripts/test-kernel-security.py in our test code.  yes let me find the omap4 logs
[17:40] <henrix> ppisati: psivaa: iirc, those tests are actually inside a bz2 archive in the source tree. but it's been a while since last time i looked
[17:40] <psivaa> ppisati: https://jenkins.qa.ubuntu.com/view/SRU%20Kernel/job/sru_kernel-quantal-generic-armhf_omap4_panda_ES-serial/163/consoleFull is the omap4 logs
[17:41] <ppisati> 21:39:16 ERROR| [stderr] test_072_config_debug_rodata (__main__.KernelSecurityTest)
[17:41] <ppisati> 21:39:16 ERROR| [stderr] CONFIG_DEBUG_RODATA enabled ... FAIL
[17:41] <ppisati> indeed that options is off
[17:41] <arges> bjf: hey, sent an updated patch. it builds and boottest works
[17:41] <psivaa> ppisati: this log has that test 'FAIL' although jenkins report at the end as no test failures. this has now been fixed
[17:42] <bjf> arges, thanks
[17:44] <ppisati> psivaa: as i said, DEBUG_RODATA is not available on arm in that kernel, so it's normal that the test fails
[17:49] <psivaa> ppisati: sorry i am confused. do you mean to say that it's expected that the test fails on omap4 *and on armadaxp boards since the kernel does not have DEBUG_RODATA?
[17:50] <bjf> arges, did you send that me directly? i'm not seeing it
[17:51] <arges> bjf: sent it to kteam ml
[17:51] <ppisati> psivaa: yes, either that test was skipped or no one noticed it since now
[17:51] <psivaa> ppisati: ok, the test is not skipped in our setup as we could see. right ( sorry i am trying to understand as we are going.. so bear with me :))
[17:52] <arges> bjf: i just fwd it directly to you as well
[17:52] <bjf> thanks
[17:54] <bjf> arges, got it
[17:58]  * ppisati -> EOD
[18:04] <kees> henrix, sbeattie: odd, ARM should not be testing for CONFIG_DEBUG_RODATA. that option doesn't exist yet there.
[18:04] <kees> the test should be skipping that check.
[18:05] <kees> also, how come jenkins output doesn't log correctly? the notes on tests (the stuff in ()s) isn't logged in the correct place.
[18:05] <henrix> psivaa: ^^
[18:08] <psivaa> kees: i dont understand your comment. where is it wrong.
[18:11] <gQuigs> kernel 3.14 landing in 14.04 is not possible anymore?
[18:17] <kees> psivaa: the test itself should be detecting that it is an ARM kernel and not requiring the CONFIG_DEBUG_RODATA option. the test appear broken, but it's a harmless failure condition.
[18:17] <kees> psivaa: or did you mean the jenkins output?
[18:18] <manjo> rtg, what is the final kernel version for trusty?
[18:18] <psivaa> kees: i'm not really bothered about jenkins output issue if that failure is harmless :)
[18:18] <rtg> manjo, 3.13.x
[18:18] <psivaa> kees: just was talking to plars and there was already a bug opened for this:  https://bugs.launchpad.net/qa-regression-testing/+bug/1190668
[18:18] <ubot2`> Launchpad bug 1190668 in QA Regression Testing "FAIL: test_072_config_debug_rodata (__main__.KernelSecurityTest) on SRU kernel 3.5.0-226.39 omap4" [Undecided,New]
[18:19] <plars> yeah, we get the same failure on omap4
[18:19] <plars> for a while now, and were told that the option needs to be disabled in the kernel iirc
[18:19] <manjo> rtg, thanks... is it too late to request a pull  from 3.14-RCX? possibly one or 2 patches
[18:20] <rtg> manjo, not too late, but its obviously dependent on the content of the patch. send it on the list.
[18:20] <manjo> rtg, will do when it lands there
[18:21] <kees> plars: the option doesn't exist on ARM kernels. it's the test that needs to be fixed to not expect it
[18:25] <manjo> rtg, atm there was a one liner hack that was put into saucy to get guest kernels to boot and use serial ... hopefully ppisati carried that fwd. The real fix is landing upstream somewhere in 3.14.rc1 according to linaro ... so just checking when it lands we could replace the hack with real fix
[18:25] <rtg> manjo, 3.14 is already at -rc3
[18:26] <manjo> rtg, right ... checking on it and will let ppisati know
[20:36] <miseria> "cuantos millones de humanos perderian su trabajo si un miserable salario minimo fuera mandatorio en el planeta?" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
[21:46] <nickez> anybody knows what is going on with the 64bit dailies?