[08:18] <smb> morning
[08:28] <cking> morning smb
[09:04] <ppisati> cool, last dist-upgrade broke empathy :(
[09:08] <smb> ppisati, Isn't that the "normal" behavior?
[09:38] <ppisati> brb
[09:58]  * apw reboots for 37M of new shiney bits
[11:10] <alexbligh1> is it intended to have a precise-backports kernel for lucid, the same way as we have a oneiric-backports and a natty=backports?
[12:04]  * ppisati -> out for lunch
[12:28] <apw> alexbligh1, no, we are not intending to make that combination
[13:34] <smb> herton, You reckon it is ok to also apply the changes for the cve to maverick master-next, even with a chance that it won't get released in case there is nothing urgent? I sort of completely managed to not read the announcement carefully enough that it should slowly go out of updates.
[13:35] <smb> Otherwise I'd go ahead and apply them (hopefully not clashing with tgardner )
[13:36] <tgardner> smb, I've not started, so you've got the ball
[13:36] <herton> smb, hmm, may be we should wait, unless the CVE is critical enough to have a release
[13:36] <smb> tgardner, Okay will do
[13:36] <smb> herton, It is maybe in between
[13:36] <smb> Not really critical but on the other hand allows a normal user to crash a kvm guest (32bit)
[13:38] <smb> herton, But given it is unclear, I'll leave out M for now
[13:40] <herton> smb, ok, we have to see, if security thinks it should be released, I think bjf mentioned jj should do a review of CVEs that still are pending and should go
[13:41] <smb> herton, Yes, he did. Ok then, pushing all but M
[13:41]  * apw is unclear why we would not apply the thing and include it _if_ there is another upload
[13:42] <apw> its most likely to get lost if you don't apply it, and if we have it, and we do another upload, i cannot see why we would not include it
[13:42] <apw> the review with jj is about which ones we can not bother with the effort to do them, if its no effort or already done ...
[13:43] <apw> plus you can always rebase them out of existance
[13:43] <herton> I don't see any problem as well in applying too, if no one bothers that may be what is in master-next will not be released
[13:44] <herton> yes, it could be rebased/removed later
[13:57] <smb> herton, apw Ok, so that means I should apply it and it can be decided later to drop it? (just wanting to confirm,)
[13:58] <herton> smb, yes, just apply it, in the worst case we can remove it from master-next later
[13:58] <smb> allrighty then
[14:06] <cba123> I'm getting random freezes, on 11.10 (3.0.x kernel).  In my logs I recall seeing "rcu_sched_state detected stall on CPU 0" which I've seen other people have too.  They say they went to 3.2.x and the issue seems to have cleared.  Can I go to the Precise repo for the kernel and go back, or is there an Oneric backport kernel repo I don't see?
[14:12] <apw> cba123, those may well show up in syslog so you might look there.  there is no official 3.2 kernels for oneiric no
[14:14] <cba123> apw, Yes, so I'd imagine that the rcu is the effect not the cause?
[14:14] <apw> yep, its just telling you something got stuck somewhere... though the stack trace can often help
[14:15] <apw> you might be able to get a stack trace with sysrq when it does hang
[14:16] <cba123> What do I use for a stack trace, or sysrq?
[14:18] <desrt> good morning
[14:18] <desrt> who is the curator of all things drm?
[14:21]  * desrt is testing http://lists.freedesktop.org/archives/intel-gfx/2012-March/015486.html
[14:49] <bullgard4> 'man apt-cache': "blue lines are pre-depends, green lines are conflicts." How are »pre-depends« defined?
[15:01] <lamont> if I throw a 3.2 kernel on lucid, how much breaks?
[15:02] <tgardner> lamont, shuold work
[15:02] <tgardner> lamont, we've got 3.0 kernels on Lucid
[15:02] <lamont> well, I know there are userspace things that git a tad bit annoyed at != 2.6.X, no?
[15:03] <lamont> or is that mostly just build time issues
[15:03] <lamont> ?
[15:03] <tgardner> lamont, mostly build time issues, though IIRC there was a user space package that complained.  Maybe DKMS ?
[15:04] <lamont> cool.  I may try that step, or I may just shove the box into precise
[15:04] <smb> Though wasn't the problem more of a "who stole the third digit"?
[15:04] <apw> tgardner, are you or leann handling the upload the end of this week ?
[15:04] <tgardner> apw, leann said whe'd be around tomorrow long enough to do it.
[15:05] <lamont> Mar 15 08:53:21 wfg-gw kernel: [244607.623349] nf_ct_sip: dropping packetIN=eth0 OUT= MAC=00:0e:0c:5c:1c:78:00:0c:85:be:5a:85:08:00 SRC=<IP_ADDRESS> DST=<IP_ADDRESS> LEN=591 TOS=0x10 PREC=0x40 TTL=64 ID=57781 PROTO=UDP SPT=51374 DPT=5060 LEN=571
[15:05] <lamont> mostly, I want to stop having logs full of that
[15:05] <tgardner> lamont, ah, you're still having that issue.
[15:05] <lamont> 72MB/day of that issue
[15:05] <lamont> 2.6.32-39-generic-pae
[15:06] <tgardner> well, 3.2 is worth a try
[15:09] <apw> lamont, i think ps will start moaning a bit about the kernel version
[15:09] <apw> lamont, mostly it was package building which was a bit suspect in that combination
[15:09] <lamont> right.  upgrade it is then
[15:10] <apw> lamont, builds with checks for 2.6.x and similar in them
[15:10] <apw> there is a personality flag, which allows the kernel to report itself as 2.6.39+N i think it is
[15:10] <lamont> yeah
[15:13] <lamont> so lets say I have / on /dev/md2 (swraid1), and I want to migrate to having it on an LVM volume on the same thing... Can I: remove one drive from the array, mdadm create -f on it, pvinit it, pvcreate, vgcreate, lvcreate, mount, sync, reboot onto the half-there md3, and then mdadm --add the other drive and be all shiny and happy?  or is that crazytalk?
[15:13] <lamont> (yes, backup first, because I care)
[15:13] <lamont> s/sync/rsync/
[15:14] <tgardner> lamont, AFAIK each of those steps ought to work, though I think you'll be pioneering....
[15:16] <lamont> tgardner: heh
[15:16] <lamont> my biggest concern is making sure that the *^)*^( swraid doesn't decide that it wants to readd the second drive backinto the original raid and trash all my work
[15:17] <lamont> but if it's already a new array, there's little risk of that
[15:17] <lamont> if lvm is installed, and root is not on lvm, does lvm get all its pretty hooks into the initrd still?
[15:17] <lamont> because not having lvm in the initrd on that reboot would suck
[15:17] <tgardner> lamont, that I can't tell you. I've mostly used mdadm.
[15:18] <lamont> np
[15:18] <smb> lamont, I think it is in there when it is installed
[15:18] <lamont> just one more thing to verify before the reboot
[15:18] <lamont> smb: that would be suitable for my interests
[15:18] <bullgard4> [solved]
[15:26] <smb> lamont, Actually my local machine is done that way. So you should be ok. (after all those test installs I cannot remember reliably what I have done where)
[16:01] <desrt> So I filed https://bugs.launchpad.net/ubuntu/+source/linux/+bug/956046 and built a kernel package with the patch.  It fixes the issue.
[16:01] <ubot2`> Launchpad bug 956046 in linux "intel driver fails to use dual-link LVDS if lid is down at boot" [Undecided,Confirmed]
[16:01] <desrt> not sure if it causes other issues, of course.... :)
[16:32] <ppisati> GrueMaster: 3.2.10 (that's in master-next) fixes the serial problem we have with omap3
[16:38] <GrueMaster> Cool, thanks.
[17:33] <hrw> hi team
[17:34] <hrw> can someone take a look at http://pastebin.com/LwtJ6jzm patch to kernel packaging? first hunk disables build of tools for cross compilation (we do not have all libraries multiarched for it yet), second is irrevelant now but will be needed when we will be able to cross build tools
[17:48]  * ppisati -> out
[17:54] <tgardner> hrw, email it on<EMAIL_ADDRESS>where it'll likely get a bit more attention.
[18:21] <Laibsch> Can somebody please accept the lucid nomination for the critical bug 745836?  This has caused data corruption and frequent crashes in essential pieces of software like OOo.org for more than a year now.  Patch is available and landed in natty and beyond.
[18:21] <ubot2`> Launchpad bug 745836 in linux "encrypted swap corrupts application stack/heap [was: soffice.bin SIGSEGV cppu::throwException()]" [High,Confirmed] https://launchpad.net/bugs/745836
[18:28] <tyhicks> The bug Laibsch is talking about was actually an eCryptfs bug, despite the confusing bug title.
[18:29] <tyhicks> It was a pretty simple patch, but I don't know how it applies to a kernel as old as Lucid's
[18:29] <ohsix> if it's a known bug, patch and SRU shouldn't be hard
[18:33] <Laibsch> ohsix: do you have upload rights to the kernel?  My experiences with "patch served on a platter" for even highly important bugs has been less than good.
[18:34] <ohsix> eh, you mean important by your own criteria; or your own SRU requests?
[18:35] <Laibsch> highly important as in "mass-market netbook without wifi support for more than half a year" even though upstream kernel had a patch after two days
[18:35] <Laibsch> no amount of bugging and begging got anyone's behind moving :-(
[18:36] <ohsix> was there an SRU
[18:36] <ohsix> or was it discovered before a release
[18:36] <Laibsch> that was for lucid at the time it was in development
[18:36] <Laibsch> January 2010
[18:37] <Laibsch> ohsix: will you also answer my question now: do you have commit rights?
[18:38] <ohsix> that question isn't relevant, but no; what would it even mean to have "commit rights", to the bzr on launchpad? people don't just shove things in there to get them into packages ...]
[18:39] <tyhicks> Laibsch: To be fair to the kernel team, this one was extremely hard to debug. IIRC, it wasn't known that it was an eCryptfs issue for quite some time and then once that was determined and I was notified, it took me quite a while to debug it and fix it upstream.
[18:40] <tyhicks> Reading back through the report, it seems that I stumbled upon the fix after removing some crufty code and noticed that the problem went away. That led me to the actual cause.
[18:41] <Laibsch> ohsix: if you consider commit rights irrelevant I'm not even sure there's a point to talk.  That question is so obviously relevant, there's no need to discuss.  tyhicks would fix the issue if he had the powers, but he doesn't.
[18:41] <cking> tyhicks, so this just needs backporting to lucid and testing then? I can look at that one
[18:41] <ohsix> heh why is there still so many random encrypt-x things in use when you can use dm
[18:42] <tyhicks> cking: It sounds like it
[18:42] <ohsix> Laibsch: there's a process, it doesn't sound like you know it; that might be a component of why something so important seemed ignored
[18:42] <Laibsch> tyhicks: I remember the troubles in pinpointing that problem.  And I'm not faulting anyone for 745836.  I'm just afraid that lucid might experience a repeat of the sluggish, non-response I've seen in other problems earlier.
[18:42] <cking> tyhicks, OK - I will slap it on my todo list then
[18:42] <tyhicks> cking: A couple helpful links...
[18:42] <ohsix> just because cking was here this time ... !
[18:42] <tyhicks> A description of the problem: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/745836/comments/86
[18:42] <ubot2`> Launchpad bug 745836 in linux "encrypted swap corrupts application stack/heap [was: soffice.bin SIGSEGV cppu::throwException()]" [High,Confirmed]
[18:43] <cking> nice, I can even write a testcase and add it to the ecryptfs tests
[18:43] <tyhicks> cking: A simple patch which should fix it in old releases if you don't want to backport the upstream changes that luckily solved the problem: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/745836/comments/87
[18:44]  * tyhicks remembers that he needs to merge cking's latest test suite changes sometime this week
[18:44] <cking> OK - I will see if I can get around to this tomorrow or monday
[18:44] <ohsix> cking: but do you have commit rights?!?!!1111
[18:45] <cking> I can do the SRU work, do the testing etc, I've been doing ecryptfs SRU's over the past few weeks, so it's my bread-n-butter
[18:46]  * cking will give it the love it requires
[18:46] <ohsix> nice, but i can't make the joke i was going to had you said yes
[18:46] <ohsix> well, thanks for speaking up; maybe i was explaining things poorly but it didn't seem to be getting any traction
[18:47] <cking> glad you mentioned it, somehow I missed that one, and I've looked a a bunch of these over the past few weeks
[18:48] <cking> tyhicks, is it OK just to use the simple patch in comment 87 rather than backport the other two patches?
[18:48]  * cking being lazy
[18:49] <tyhicks> cking: Let me take another look at those two patches. My mind is going almost completely blank on this bug...
[18:49] <ohsix> who would have thought where you store your pages would be important
[18:52] <tyhicks> cking: Yes, it sounds like I was pretty confident that the simplified patch in comment 87 was the real fix and the upstream commits just covered everything up. I _know_ that I wouldn't have attached that patch without testing.
[18:53] <cking> sure - thanks for checking
[18:56] <lamont> tgardner-lunch: missing step: update mdadm.conf to reflect the new array, so that the vg is found
[18:56] <lamont> \o/
[18:57] <tgardner-lunch> lamont, yeah, I always have to go to the wikipedia page for mdadm to remember that.
[19:00] <lamont> yeah, nothing quite like not finding the root partition
[19:26] <hrw> tgardner: sent
[20:27]  * tgardner -> EOD
[20:34] <_ruben> EOD .. that's the dutch abrev for the bomb squad .. guess he hadda run ;)
[21:03] <unwired> Hi, just found a bug in kernel 3.0.0-17.30 from onieric-proposed, but I'm not sure where to report it...


[02:07] <wallyworld_> wgrant: i thought unclosed
tags were valid html5?
[02:07] <sinzui> no
[02:07] <wgrant> wallyworld_: They're valid HTML5, but not valid XHTML
[02:07] <wgrant> And we are a polyglot
[02:07] <wgrant> Because people parse us with XML parsers
[02:07] <wgrant> Because SGML is awful, and HTML5 is only mildly better
[02:07] <sinzui> we will not permit them because we cannot check our own work...and we do not know what the browser will do
[02:08] <wallyworld_> ok, i'll lp-land a quick fix, didn't see the mp comment before i landed
[02:08] <wgrant> Formally we treat our markup as an HTML5/XHTML polyglot, and I've fixed most historical issues that prevent parsing as either.
[02:09] <sinzui> I patch pocket-lint a few months back because it chocked on html5 with html4 entities
[02:09] <wallyworld_> sinzui: if you're stil lawake, i'd love a quick chat about 1052639
[02:09] <sinzui> they are the same of course, but old tools do not know that
[02:10] <sinzui> wallyworld_, okay
[02:11] <wallyworld_> sinzui: just need to reboot - mumble hates me
[02:38] <wallyworld_> wgrant: i just created a branch to fix those couple of
 tags i left in and doing a search finds lots more. i'll fix those while i'm there
[02:38] <wallyworld_> well, a few anyway
[02:39] <wallyworld_> many are in comments
[02:39] <james_w> lifeless, is there a way to refer to the root context in handlebars?
[02:39] <james_w> I'm looking for a way to do conditional logic based in a partial not on the thing being rendered, but the context in which it is being rendered
[02:40] <wgrant> wallyworld_: I know there are some in structsub JS
[02:40] <wgrant> But what others?
[02:40] <wgrant> Ah, there's one on an edit form
[02:40] <james_w> and I might be any number of layers deep, and don't want to duplicate that config at all layers
[02:40] <wgrant> wallyworld_: Beware about fixing the ones in JS
[02:40] <lifeless> james_w: I don't think so. I mean, we could add / vs ../
[02:40] <wgrant> wallyworld_: Some of our UI relies on the markup being misparsed
[02:40] <wallyworld_> wgrant: yes, they are mainly js ones
[02:41] <wallyworld_> ok, will leave alone then
[02:41] <lifeless> james_w: I'm not sure its a good idea though, as the compiler is pretty unaware of how deep it is today.
[02:41] <wgrant> wallyworld_: eg. the structsub thing relied on accidental empty table cells due to invalid markup
[02:41] <wgrant> Fixing the
 there might change the nesting
[02:41] <james_w> lifeless, yeah, it feels wrong, I'm just struggling to find a solution that doesn't multiply data
[02:42] <james_w> {{#with foo=bar}} would work
[02:42] <james_w> as would {{>partial foo=bar}}
[02:43] <lifeless> james_w: passing it down in userspace, as it were?
[02:43] <lifeless> james_w: that seems like a solid approach to me
[02:43] <james_w> lifeless, those aren't supported syntaxes currently?
[02:46] <lifeless> so, remember that ../ is template nesting, not context nesting
[02:46] <lifeless> james_w: does that help ?
[02:47] <james_w> lifeless, what do you mean?
[02:49] <lifeless> you aren't an arbitrary depth down
[02:50] <lifeless> james_w: anyhow, handlebars does support keyword parameters
[02:51] <james_w> http://paste.ubuntu.com/1217974/
[02:52] <lifeless> hmmm, No OOPS Tools Production OOPSes found for 2012-09-20 <- not sure I believe that.
[02:52] <wgrant> lifeless: Wasn't it upgraded just after midnight?
[02:54] <lifeless> could be
[02:56] <lifeless> james_w: so, I'm suggesting
[02:57] <lifeless> james_w: http://paste.ubuntu.com/1217979/
[02:57] <lifeless> I don't know if that will work OOTB
[02:57] <lifeless> but it may
[02:58] <james_w> it doesn't
[02:58] <lifeless> you tried ?
[02:58] <james_w> yeah
[02:59] <james_w> let me get the error
[03:02] <james_w> pybars/frompymeta.py in moduleFromSource
[03:02] <james_w>         code = compile(source, filename, "exec")
[03:02] <james_w> non-keyword arg after keyword arg (pymeta_grammar__render__195.py, line 8)
[03:02] <lifeless> ok
[03:02] <lifeless> so, there is a protocol for calling helpers with kw arguments
[03:03] <lifeless> it makes sense to me that a template called with extra kw arguments would shove them in the context
[03:03] <lifeless> I suggest either getting handlebars.js or making it require an option to enable or something
[03:03] <lifeless> so we don't go spuriously incompatible indefinitely.
[03:03] <lifeless> james_w: if you think its a sensible approach
[03:04]  * lifeless grabs a drink before fixing https://bugs.launchpad.net/python-timeline-django/+bug/1050852
[03:04] <_mup_> Bug #1050852: Error in action handling <python-timeline-django:New> < https://launchpad.net/bugs/1050852 >
[03:04] <james_w> lifeless, ok
[03:05] <james_w> lifeless, I won't do that now as I'm just trying things out, but if the experiment is a success then I'll still do it if I haven't found a better way to address this
[03:07] <lifeless> kk
[06:10] <wgrant> StevenK: What do you think of the restriction that non-virtual main archives can't be arch-restricted?
[06:10] <wgrant> That is:
[06:10] <wgrant>         if self.is_main and not self.require_virtualized:
[06:10] <wgrant>             return getUtility(IProcessorFamilySet).getRestricted()
[06:10] <wgrant> It seems like a pretty pointless special case
[06:10] <wgrant> So I'm going to give Ubuntu primary/partner all restricted archs and remove it, unless you can think of a reason not to
[06:11] <StevenK> main archives being purpose PRIMARY and PARTNER?
[06:11] <wgrant> And DEBUG, but yes
[06:11] <StevenK> Right
[06:11] <StevenK> Sounds like a good plan
[06:11] <StevenK> Remove PARTNER while you're at it
[06:11] <wgrant> Heh
[07:05] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-897999/+merge/125640
[07:09] <StevenK> wgrant: I was about to comment on your crimes against indenting when I realised it was code you were deleting.
[07:10] <StevenK> wgrant: r=me
[07:33] <adeuring> good morning
[08:35] <cjwatson> StevenK: totally QAable on mawson - it just got trumped by secure boot stuff yesterday
[08:36] <cjwatson> StevenK: I'll do it this morning
[10:47] <czajkowski> jelmer: can this be closed https://answers.launchpad.net/launchpad/+question/206501
[10:57] <cjwatson> wow, that rules file is insane
[10:57] <cjwatson> I'll follow up
[11:04] <czajkowski> cjwatson: thank you
[12:14] <cjwatson> wgrant: Do you have any remaining concerns about https://code.launchpad.net/~cjwatson/launchpad/remove-queue-tool/+merge/114464, once process-accepted-bugs-job is deployed and the associated ops work done?  I'm just merging in current devel now
[12:15] <cjwatson> Because, -1956
[12:15] <wgrant> cjwatson: Well, we should probably live through a bit of freeze first. It's very likely that the bugs thing will be sufficient to get rid of all the timeouts, but we're pretty screwed if it doesn't.
[12:15] <cjwatson> Yeah - fortunately we have a freeze now
[12:15] <wgrant> Right :)
[12:15] <cjwatson> And if we have this deployed and enabled on say Monday, we'll have that freeze period plus the flush at the end
[12:16] <cjwatson> Which I think will be enough
[12:16] <wgrant> Indeed
[12:28] <vila> hi guys, I found a socks_proxy=socks://lpdev.local:8110/ in my env, any idea where it's coming from ?
[12:29] <vila> as in: I setup an lpdev instance long ago, but this line is nowhere to be seen in my .bashrc/.profile
[12:29] <vila> I discover it recently as it breaks a badly isolated test in another project
[14:00] <wgrant> vila: That's not a standard Launchpad thing.
[14:00] <wgrant> vila: No tool I know of uses lpdev.local
[14:00] <wgrant> Or socks_proxy
[14:06] <vila> wgrant: there was a wiki page mentioning socks at some point (I can't find it anymore), the .local is from avahi and comes from me. But I don't remember ever putting that in any .rc file :-/
[14:06] <vila> (and all the significant ones are under version control anyway)
[14:07] <vila> wgrant: note that (from memory) the wiki page was referring to some FF setting, not an env var... but since I *never* used socks myself...
[14:38] <cr3> hi folks, I'd like to have a project and team deleted from launchpad. should I ask a question to launchpad (itself)?
[14:40] <czajkowski> cr3: yes plase
[14:40] <cr3> czajkowski: cheers!
[14:54] <czajkowski> cr3: need the list deleted so just waiting on that to happen
[14:55] <cr3> czajkowski: thanks, no rush
[14:56] <cr3> czajkowski: this is mostly about keeping Launchpad tidy :)
[18:10] <sinzui> jcsackett, how goes to demolition of the suggest ubuntu packages portlet?
[18:11] <jcsackett> sinzui: slowly, though not because of the task itself. i have had a rocky-ish day so far in terms of other things needing doing.
[18:12] <sinzui> I keep getting locked out of my computer bug the screen-lock
[18:12] <jcsackett> sinzui: that sounds like a pain.
[18:12] <sinzui> I just disabled it so I can talk without needing to kill procs or reboot
[18:13] <jcsackett> sinzui: dig.
[18:15] <sinzui> jcsackett, did you see Bug #105376 ? There is a db column that can be removed too I think
[18:15] <_mup_> Bug #105376: Kubuntu 7.04beta Alt. CD install not create a new user. <debian-installer (Ubuntu):Fix Released by brian-murray> < https://launchpad.net/bugs/105376 >
[18:15] <sinzui> jcsackett, did you see Bug #1053765 ? There is a db column that can be removed too I think
[18:15] <_mup_> Bug #1053765: Suggest ubuntu packages portlet has nothing to do <package-link> <projects> <tech-debt> <Launchpad itself:Triaged by jcsackett> < https://launchpad.net/bugs/1053765 >
[18:15] <sinzui> I missed a digit
[18:15] <jcsackett> sinzui: i didn't see that bug. thanks.
[18:16] <jcsackett> ah, i see you updated my card as well.
[18:32] <jcsackett> sinzui: do we want to obliterate the portlet, period? or just the part that's trying to encourage linking if not known?
[18:32] <sinzui> just the suggestions
[18:32] <jcsackett> ok; that's what i was assuming, but i realized it could be meant to remove all of it.
[18:32] <sinzui> we still want to show the 5 most recent packages built from the project's releases
[18:33] <jcsackett> sinzui: dig.
[22:03] <wallyworld_> sinzui: hi, with that new getSHaredProducts branch, i did not return distros because of the lazr restful issues with heterogeneous results. i was thinking about a separate api for distros
[22:03] <wallyworld_> also, there are some comments in the bug about teams vs users
[22:04] <wallyworld_> the idea is that user is removed from teams first, so we only need the api to check for direct shring for the user
[22:05] <wallyworld_> ah hang on, you are talking about teams for maintainer and driver
[22:05] <wallyworld_> i do need to fix this then
[22:05] <wallyworld_> and you also want commercial admins to get back all results, not just admins


[00:25] <arraybolt3> Would love input on this: https://discourse.ubuntu.com/t/lubuntu-and-the-flutter-based-subiquity-installer-personal-concerns-and-thoughts/33586
[00:27] <guiverc> we used calamares since 18.10 (first lxqt release)
[00:28] <arraybolt3> Thanks, will correct that.
[00:30] <guiverc> I've noted some graphic glitches on old hardware with the newer installer; but I've not tested it much  this cycle  (I may have also swapped out the nvidia card where I saw it most; I forget)
[00:32] <arraybolt3> @kc2bex: As I understood it, that was only for Ubuntu Core Desktop and variants, right?
[00:32] <guiverc> fyi:   as an installer is (ideally) only run once; the Qt/GTK mismatch doesn't worry me ; primarily a concern in regards requirements for installer to run (is the mismatch significant and thus a problem for lower-resource end-users?)
[00:33] <guiverc> arraybolt3, it was how it was stressed as I understood it (ubuntu core desktop), what my notes reflect anyway
[00:33] <arraybolt3> I figured as much, it's just probably something we'd want to get out of the way now while we're in the early stages, rather than finding out when there's a push to switch (if there's a push to switch). I *think* I was supposed to mention stuff on Discourse if it would take to long during the meeting?
[00:33] <arraybolt3> kc2bez: re the installer ^
[00:33] <guiverc> using the new installer is our choice (my understanding), no requirement to use it.
[00:35] <guiverc> (if there was a push, it was for those using `ubiquity` they want not to support; thus we're not impacted by that at all!)
[00:35] <arraybolt3> OK, that's good. Personally I think it would be *great* if we all used the same installer, and I know Simon said that yes, we would be interested in it.
[00:35] <guiverc> (and that push ^ does not impact 23.04)
[00:37] <arraybolt3> OK. I may have misunderstood some things then. I took stuff about "blocker" out of the post since if it's optional, there's not really anything that's being blocked.
[00:37] <arraybolt3> Glad I put the note that this was only my thoughts at the top :P
[00:51] <guiverc> arraybolt3, re: wallpaper images, given my recent reply on discourse to a thread; ... were you going to publish screenshots of lunar greeter & wallpaper? (sorry I forget)   OR want me or someone else to?  (given your our source).  I suggested waiting until they were on ISO & I think; ISOs are all good now re UID999 issue etc..) I believe
[00:53] <arraybolt3> guiverc: I intended to and then just forgot :P
[00:53] <arraybolt3> I'll get that done real quick. Desktop screenshot thread, right?
[00:54] <guiverc> yep.  greeter & wallpaper please :)    No hurry though; just when you can etc.
[01:04] <arraybolt3> guiverc: Done, thanks for the reminder!
[01:06] <guiverc> Thank you arraybolt3 :)
[02:50] <kgiii> Speaking of installer, there was a PPA for a bit, is there any planned movement to a minimum install option? I see interest in such a thing fairly regularly, but not like so regularly that I'd call it a major priority...
[03:08] <arraybolt3> kgiii: At one point we were working on that and *just about* had it made, though this was way before I came on. I added it to the list here: https://notes.lubuntu.me/huOk59_iRSaAMZDl_my8bw?edit
[06:48] <arraybolt3> I apologize in advance if I'm not around a whole lot tomorrow. My dad managed to get his laptop hacked and so a lot of my time (and probably most of my Internet bandwidth during that time) is going to be spent on a Windows reinstall complete with Windows Update chaos and driver installation madness. :-/
[06:51] <guiverc> oh what fun arraybolt3 :(
[06:51] <arraybolt3> :P
[06:52] <arraybolt3> Thankfully I have the ISO downloaded and a Linux drive for recovering files already built, so it's possible that most of the work will just be waiting for the system to do its thing while I do other stuff. And I've been getting 2 and 4 MiB/s speeds so it might not be all that horrible. I guess we'll find out tomorrow after file recovery is complete.
[06:52] <arraybolt3> *speeds for my Internet
[08:00] <arraybolt3> Submitted a request for xdg-desktop-portal-lxqt to be added to the Lubuntu packageset, hopefully that will result in less overhead next time it needs an update or NCR.
[17:47] <arraybolt3> I assume the problem with PyQt5 causing regressions and *still* blocking qtbase-opensource-src is known?
[17:47] <arraybolt3> I think I saw something about that.
[17:47] <arraybolt3> What I'm not sure is how it would be fixed :P I don't know enough to know if this is a real, honest-to-goodness regression in PyQt or what.
[17:49] <arraybolt3> Where on earth even is PyQt's homepage?!
[17:49] <arraybolt3> Ah, found it. Finally.
[17:51] <arraybolt3> They seem to have only added a few missing components, so this is weird.
[17:52] <arraybolt3> Oh, because the news has an *incomplete* changelog looks like.
[17:58] <arraybolt3> Where on earth are l-u-n's autopkgtest rules even coming from?
[17:59] <arraybolt3> nvm, found them, I was on the Focal branch rather than Lunar :P
[18:12] <arraybolt3> Alright, looks like maybe the failed autopkgtests are a fluke? I can't reproduce them on my end.
[18:14] <arraybolt3> tsimonq2: ALright, I believe I am ready for the next level of fighting with -proposed, how to retry autopkgtests. I don't know where the docs are on that, though I think the idea is I send some links to people with the right privileges and they do it for me.
[18:21] <kgiii> Thanks for the update @arraybolt3.
[18:47] <tsimonq2> arraybolt3 @arraybolt3:libera.chat: https://autopkgtest-cloud.readthedocs.io/en/latest/architecture.html#test-request-format
[19:04] <arraybolt3> tsimonq2: all-proposed! Perfect, thanks.
[19:05] <arraybolt3> Might let us help get PyQt5 a bit more unstuck.
[19:10] <tsimonq2> Don't use all-proposed unless you have to heh
[19:11] <arraybolt3> tsimonq2: I could see that it had failed multiple times with only picking and choosing stuff and I had done a local test with "autopkgtest --apt-pocket=proposed=* -- schroot lunar-amd64-shm" which passed, so I thought it would make it unstick.
[19:14] <arraybolt3> "This is sometimes necessary when several packages need to land in lockstep but don’t declare versioned Depends:/Breaks: to each other, but might cause mis-blaming if some other package than the trigger got broken in -proposed." I think that's what's happening possibly, and I just tested locally so I don't think the mis-blame will happen. Still, I will keep that in mind for next time.
[19:17] <tsimonq2> What differences are there in packages being pulled in?
[19:17]  * arraybolt3 looks
[19:18] <arraybolt3> I can see that when pyqt/5.15.8 is added to the mix (with or without python3-defaults/3.11.1-0ubuntu1), the test borks. But when I did the above autopkgtest command, everything Just Worked, so... I assume what I probably should have done is figured out what packages needed to be in there too.
[19:18] <arraybolt3> (But vorlon already kicked off the test for me and I didn't realize that --all-proposed was an extreme measure so...)
[19:20] <arraybolt3> Ah, and it looks like the other thing that was part of the setup when it worked was... *drumroll* Qt 5.15.8. Shocker.
[19:21] <arraybolt3> And I see that at no point was the combo of PyQt 5.15.8 + Python 3.11 + Qt 5.15.8 was tried.
[19:41] <arraybolt3> OK so... somehow kde-config-updates is still getting in?
[19:41] <arraybolt3> No, it's not, but systemsettings still is!...
[19:42] <arraybolt3> Gah. Guess what recommends systemsettings. Bluedevil.
[19:45] <arraybolt3> So... our Bluetooth stack is the next offender in the list.
[19:45] <arraybolt3> tsimonq2: ^
[19:50] <arraybolt3> My thoughts on this may be drastic, but I'm thinking we replace Bluedevil with Blueman. (Reasoning coming soon, but I have to go afk...)
[19:51] <arraybolt3> Reasoning:
[19:51] <arraybolt3> 1. At least one user on Discourse wanted a Bluetooth tray icon, which Bluedevil doesn't provide, but Blueman does.
[19:51] <arraybolt3> 2. We aren't all that thrilled with our current Bluetooth stack anyway.
[19:52] <arraybolt3> 3. We already have networking components in Lubuntu that are GNOME-based (the NetworkManager configuration thingy, I believe), and Bluetooth is networking-related, so this isn't that big of a change.
[19:52] <arraybolt3> 4. My previous experience with using Bluedevil on Lubuntu is bad - whereas I can usually do cool things like link two computers so I can play audio from one out the other, Lubuntu wouldn't do that. I suspect Blueman may fix that.
[19:53] <arraybolt3> 5.  :P
[19:54] <arraybolt3> Also, 6. Bluedevil looks like it legitimately recommends systemsettings as it uses it as part of how you configure Bluetooth. Trying to demote systemsettings to a Suggests there may be detrimental.
[20:40] <arraybolt3> XScreenSaver in Debian is rescued! \o/
[21:05] <arraybolt3> New todo list option - write a version of apt-cacher-ng that actually works.
[21:05] <arraybolt3> s/option/item/
 Bluedevil shines with the plasma plasmoid which we don't have. Blueman is great but is GTK. Debian and LXQt recommend conman which is gross and problematic.
[23:07] <arraybolt3> Hmm... Blueman wants to remove pipewire-alsa for goodness-knows-why.
[23:08] <arraybolt3> Which we know breaks audio in weird ways since we had to put it there in the first place to get audio working right.
[23:08] <arraybolt3> Oh, lol, because it Depends on Pulseaudio.
[23:08] <arraybolt3> Er, no, it Recommends pulseaudio-module-bluetooth.
[23:09] <arraybolt3> If I skip the recommends, it's compatible.
[23:11] <arraybolt3> I'll test it out on a system with Bluetooth, it actually doesn't look that out-of-place in my initial testing.


[17:51] <kyrofa> I'd like to be able to request that launchpad build a snap and publish it in a given branch from CI. The branch would be associated with a given pull request. I _think_ I can sort of hack this behavior by creating a snap on LP associated with a given branch, force-push to that branch from the PR, and then use the LP API to set the store_channels for that snap and trigger a build. However, that doesn't scale well
[17:51] <kyrofa> considering the possibility for multiple simultaneous PRs, because I assume the store_channels only apply once the snaps complete building
[17:51] <kyrofa> Does anyone have a better idea?
[22:27] <b-rad> hi, just reporting that a lot of builders seem to be stuck cleaning for 19hr or more


[04:31] <mwhudson> is it possible that there is something systematically odd going on on ppc64el builders?
[04:32] <mwhudson> i'm seeing some random segfaults on unrelated projects
[04:32] <mwhudson> like https://launchpad.net/~mwhudson/+archive/ubuntu/devirt/+build/21750490 and https://launchpad.net/~mwhudson/+archive/ubuntu/rust-stuff/+build/21750478
[04:32] <mwhudson> although that first one is reproducible, but not in canonistack hmm
[07:18] <pmjdebru1jn> https://launchpadlibrarian.net/546549357/buildlog_ubuntu-focal-amd64.prusa-slicer_2.3.2~beta-0pmjdebruijn1~20.04_BUILDING.txt.gz I'm still having memory issues after
[07:18] <pmjdebru1jn> export DEB_LDFLAGS_MAINT_APPEND += -Wl,--reduce-memory-overheads -Wl,--no-keep-memory -Wl,--no-map-whole-files
[07:18] <pmjdebru1jn> 	dh $@ --buildsystem=cmake --no-parallel
[07:19] <pmjdebru1jn> any further tips on how to reduce memory usage?


[13:47] <rtg> apw, bug #1374759 is benign, right ?
[13:51] <rtg> cking, do you know anything about btrfs transid patches ? See bug #1441150
[13:52] <cking> rtg, I'll pick that one up and look at it
[13:52] <rtg> cking, thanks
[14:09] <rtg> apw, nm, you said as much: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1374759/comments/4
[14:48] <rtg> apw, just update unstable to v4.0-rc7
[14:48] <rtg> updated*
[15:06] <jsalisbury> **
[15:06] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:06] <jsalisbury> **
[16:55] <jsalisbury> ##
[16:55] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:55] <jsalisbury> ##


[01:36] <darkxst> robert_ancell, Hi
[01:37] <darkxst> Wondering if you could add a comment to my  membership application? https://wiki.ubuntu.com/TimLunn/DeveloperApplication
[01:38] <robert_ancell> darkxst, sure
[01:38] <darkxst> thanks
[02:01] <darkxst> jbicha, I guess you saw the gtk dnd fix fly by your emails?
[02:05] <darkxst> jbicha, seb128 is pretty much against having two spidermonkeys in the archive. But suggest I email ubuntu-devel list, which I tried but its awaiting moderation
[02:09] <jbicha> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel says cjwatson can approve ubuntu-devel messages
[04:45] <darkxst> jbicha, ok, pinged him
[04:47] <darkxst> oh btw, i built images today, ~+70MB up on last time
[07:43] <darkxst> ricotz, can you update to the new tarball (just to test it)
[07:44] <darkxst> http://people.mozilla.org/~sstangl/mozjs17.0.0.rc0.tar.gz
[07:53] <ricotz> darkxst, sure
[07:54] <ricotz> i see they like screwing with versions, "0.0.rc0" ?
[07:54] <ricotz> darkxst, was the internal soname fixes?
[07:55] <darkxst> ricotz, thats only the tarball version
[07:55] <darkxst> mostly minimal changes, addressing code reviews, within the actual tarball
[07:56] <darkxst> for one, js shell is now installed to 'js17'
[07:58] <darkxst> ricotz, and no they wont take the soname fixes upstream
[07:59] <ricotz> to be clear i am not talking about the symlinks
[07:59] <darkxst> you are talking about i.e. mozjs-17.0.so.1.0 ?
[07:59] <ricotz> no
[08:00] <darkxst> oh the extra_dso_flags thing
[08:00] <ricotz> the internal soname should match the filename
[08:00] <ricotz> EXTRA_DSO_LDOPTS += -Wl,-soname,lib$(LIBRARY_NAME).so.0
[08:00] <ricotz> EXTRA_DSO_LDOPTS += -Wl,-soname,lib$(LIBRARY_NAME).so
[08:00] <darkxst> ricotz, it does
[08:01] <ricotz> afaics it does not
[08:01] <ricotz> it is linked as libmoz.js and renamed to libmozjs-17.0.so
[08:01] <ricotz> *libmozjs.so
[08:02] <darkxst> no only the static is renamed
[08:02] <darkxst> I checked it with objdump, and soname was correct
[08:03] <darkxst> shared library is build as  libmozjs-17.0.so
[08:05] <darkxst> $ objdump -p /opt/gnome/lib64/libmozjs-17.0.so | grep SONAME
[08:05] <darkxst>   SONAME               libmozjs-17.0.so
[08:08] <ricotz> hmm
[08:08] <darkxst> ricotz, that is without any EXTRA_DSO_LDOPTS  -soname stuff added
[08:40] <ricotz> darkxst, uploading the package
[09:10] <darkxst> ricotz, so its ok then? soname wise? afaict it is
[09:12] <ricotz> darkxst, seems so for the tarball, but for debian/ubuntu it needs to be patched
[09:13] <darkxst> ricotz, yeh I realise that, I submitted patches for that but they were rejected.
[09:14] <ricotz> pushed a whole bunch of updates, gtk contains a hack for the dnd problem with mutter
[09:16] <darkxst> ricotz, yeh I saw the dnd fix fly past
[09:17] <ricotz> havent tested it yet though
[09:17] <darkxst> yeh nor have I, was trying to test, ISO's but thats really hard with the stupid mesa bug ;(
[09:18] <ricotz> huh, ISO's, mesa bug?
[09:19] <ricotz> you mean you were checking out the iso build process for ubuntu-gnome?
[09:19] <darkxst> yes
[09:20] <ricotz> ok
[09:20] <darkxst> but there is a mesa bug, that breaks clutter in vmware
[09:20] <darkxst> I can work around that on an installed system, but not a live CD
[09:20] <ricotz> then use vbox in the meantime
[09:21] <ricotz> alright, g2g
[09:21] <darkxst> oh and there starts the fun, last time I tried, vbox was completely broken with raring kernal
[09:21] <darkxst> ok cya
[09:31] <darkxst> anyone here able to help test Ubuntu Gnome (raring) images?


[06:51] <sync350> Hey guys, very new to triaging, was looking through bugs, is 1271340 something that should be marked wishlist?
[08:08] <chetan> I am very new to ubuntu. but I am very enthusiastic and want to learn how to debug ubuntu programs...
[08:09] <chetan> my own gnome-shell has some bug and would like to solve them. Please let me know a good starting point where i can learn on how to debug programs
[09:10] <chetan> anyone?
[12:15] <brainwash> I'm just curious.. the importance of bug 1222021 got reduced from HIGH to MEDIUM, is that correct?
[12:15] <ubot2`> Launchpad bug 1222021 in xfce4-power-manager (Debian) "[SRU] xfce4-power-manager does not inhibit systemd from handling buttons and lid events" [Unknown,New] https://launchpad.net/bugs/1222021
[12:16] <brainwash> the user does not want the system to suspend on lid close because of bad support -> possible data loss
[12:17] <brainwash> the user wants to be asked what power action should be performed, when he presses the power button, but the system simply powers off -> possible data loss
[12:17] <brainwash> on top of that, this bug affects almost every xubuntu user
[12:20] <brainwash> https://wiki.ubuntu.com/Bugs/Bug%20importances
[13:53] <hggdh> brainwash: it does not really matter, a fix has been committed to Saucy already
[14:19] <brainwash> hggdh: it matters to me, what would be the correct importance in this case?
[14:22] <brainwash> and it did matter to person who changed the importance (although the fix has been committed already)
[14:22] <brendand> hggdh, actually the person who changed the importance didn't follow good practice
[14:22] <brendand> hggdh, you should always explain major changes to a bug
[14:23] <brendand> although speaking of which, i have an lplib script that does set importance without explaining :/ but only unset ones :P
[14:23] <brendand> no-one's ever complained
[14:24] <brainwash> I'm just here to understand things better, did not feel like starting a discussion about the importance level in the bug report
[14:25] <brainwash> you are right, an explanation would help in this case
[14:25] <brendand> brainwash, well you have :)
[14:25] <brendand> brainwash, anyway because they didn't explain why, we can all only guess
[14:26] <brendand> brainwash, there are a lot of possibilities
[14:26] <brendand> brainwash, only way to know for sure is to ask them
[14:26] <brainwash> thanks for clarifying :)
[14:53] <hggdh> in general, ALL changes to bug importance and status should commented on.
[14:56] <hggdh> brendand: and yes, I know he did not follow the reccomended practice... after all, I am still one of the admins on bug triaging ;-)
[14:56] <hggdh> (bowing, of course, to the incomparable bdmurray ;-)
[14:57] <brendand> hggdh, it's a pity launchpad doesn't enforce it
[14:59] <hggdh> yes,, it is. Unfortunately, I do not see how we could enforce it without a semantic analyser
[14:59] <hggdh> brainwash: anyway, you *can* comment on the bug, and ask why was the importance reduced. I would be interesting to know
[16:42] <brendand> hggdh, late reply - it could put a dialog in the way of changing status/importance, requiring a comment to be entered. that's unlikely to be done now though
[16:57] <hggdh> brendand: yes, we could, but we cannot guarantee the comment entered has anything to do with the actions performed...
[18:45] <Mapley> Hey, since I haven't rceived a response for nearly two weeks, I'm just going to ask this here. About two weeks ago, I filed a bug for Simple Scan, requesting that the GTK+ toolbar utilize the devices icon "scanner" instead of the application(!) icon on the scan button; see https://bugs.launchpad.net/simple-scan/+bug/1268044 and
[18:45] <ubot2`> Launchpad bug 1268044 in Simple Scan "Icon types used by Simple Scan [UI/not sane]" [Undecided,New]
[18:45] <Mapley> https://bugs.launchpad.net/simple-scan/+bug/1268044/+attachment/3945792/+files/SimpleScan-UseDeviceIcon.png
[18:45] <Mapley> Thoughts?
[18:46] <Mapley> I thought it was rather illogical, imho, for a /toolbar/ to use the /application/ icon. :S
[18:47] <teward> Mapley, lets keep in mind you've filed against the upstream project and not the package in Ubuntu
[18:47] <teward> the speed that upstream can get back to you is... um... unpredictable
[18:47] <teward> s/upstream/upstreams/
[18:47] <teward> (where "upstream" means the project for the program)
[18:47] <Mapley> yeah, I know.
[18:48] <teward> my thoughts are "It's not a bug filed against the Ubuntu package." but I'm semi-distracted :p
[18:48] <Mapley> I'm not even using Ubuntu - I just thought 'lp, gnome, whatever, gimpnet support's kinda slow so I might as well ask here'
[18:48] <Mapley> I'll pop over onto gimpnet now, though.
[18:48] <Mapley> Thanks anyway.


[03:10] <zul> java is fun
[03:13] <crimsun> both fun and brain-stabbing heartache
[03:15] <zul> i have an interview tomorrow so i guess i should go over some stuff
[03:15] <crimsun> good luck!
[03:15] <zul> thanks
[03:15] <crimsun> technical interview, I presume?
[03:16] <zul> i suppose it is...junior/intermediate tech support for a mobile company
[03:16] <crimsun> oh, good
[03:17] <zul> better than not working :)
[03:17] <crimsun> indeed :)
[03:18] <zul> wha...transmeta going out of business?
[03:18] <crimsun> :/
[03:18] <zul> stupid slashdot..
[06:07] <fabbione> morning
[08:36] <fabbione> mjg59: <jgarzik> fabbione: that suspend patch isn't right for SCSI
[08:50] <fabbione> hey JaneW
[09:17] <fabbione> hey JaneW (2nd attempt)
[09:22] <fabbione> infinity http://ftp.kernel.org/pub/linux/kernel/people/mbligh/abat/regression_matrix.html
[09:23] <JaneW> hi fabbione (2nd attempt)
[09:25] <fabbione> JaneW: we need a name today :)
[09:30] <JaneW> fabbione: Bashful Brazil
[09:30] <fabbione> JaneW: is that a nuts? :)
[09:33] <JaneW> Fabbione: Brazil nut yes it's a big one ;P
[09:35] <JaneW> http://www.rain-tree.com/brazilnu.htm
[09:47] <fabbione> great :)
[09:55] <mjg59> fabbione: Hmm. Bah.
[09:55] <mjg59> fabbione: To the extent that it breaks existing scsi, or that it just doesn't work on scsi?
[09:55] <fabbione> it breaks
[09:55] <mjg59> Ok
[09:55] <fabbione> and he doesn't have another patch yet
[09:56] <mjg59> Ok
[09:56] <mjg59> Well, we'll just have to hope he gets a move on :)
[09:56] <fabbione> well.. yeah
[11:12] <jbailey> fabbione: Is that in now?
[11:12] <fabbione> jbailey: just uploaded..
[11:12] <fabbione> but i have binaries handy
[11:12] <jbailey> I don't need to rush it yet.
[11:12] <fabbione> i can spare you to wait 10 hours to build :)
[11:12] <jbailey> Handy. =)  Please.
[11:12] <jbailey> ...
[11:12] <jbailey> 10 *hours*?
[11:13] <fabbione> people.u.c/~fabbione/
[11:13] <fabbione> jbailey: building 8 flavours take ages
[11:13] <fabbione> + we have build problems
[11:13] <fabbione> so it might take way more than 10 hours
[11:14] <fabbione> jbailey: note that i don't even know if that kernel will boot
[11:14] <fabbione> so keep the proper precautions
[11:14] <fabbione> s/keep/take
[11:16] <jbailey> Hey the damned thing unpacks at least, better than svenl's image did.
[11:16] <jbailey> (I still haven't hunted down why.  I get dpkg errors with his .deb)
[11:17] <fabbione> hahah ok :)
[11:18] <jbailey> Look like no joy so far.
[11:18] <chmj> morning
[11:18] <jbailey> Lemme try it again without 'quiet'
[11:18] <jbailey> Heya Charles
[11:19] <fabbione> hey chmj
[11:19] <fabbione> jbailey: is your machine lpar? (or something like that)
[11:19] <jbailey> dict lpar?
[11:19] <chmj> fabbione: I think someone has to specificly maintain external drivers
[11:19] <fabbione> jbailey: dunno... i found a "typo fix" for ppc64 lpar boot
[11:19] <fabbione> jbailey: but i didn't include it
[11:20] <fabbione> chmj: inside or outside the kernel?
[11:20] <fabbione> jbailey: since it will be part of rc6
[11:20] <chmj> fabbione: I don't know about that
[11:21] <jbailey> Oh?  Is he actually doing another rc release?
[11:21] <chmj> fabbione: some off these drivers are already patches from upstream
[11:21] <fabbione> chmj: what external drivers you are talking about... inside our kernel or outside?
[11:21] <fabbione> jbailey: yes.. rc6 and release according to the schedule
[11:21] <jbailey> Looks like it means logical partitions
[11:21] <chmj> fabbione: the ones in external-modules
[11:21] <fabbione> jbailey: probably
[11:22] <fabbione> chmj: i am not sure understand 100% what you mean... why somebody should maintain them specifically?
[11:22] <chmj> fabbione: some off them come as patches
[11:22] <fabbione> chmj: yes
[11:22] <fabbione> and?
[11:23] <chmj> patches have no version numbers
[11:23] <fabbione> chmj: yes they do :)
[11:23] <fabbione> chmj: some of them in the code, others in the name
[11:23] <chmj> hmm
[11:24] <chmj> fabbione: in the code, makes it hard for them to be automatically watched
[11:24] <jbailey> Oh, I see.  http://www.technonics.com/ppc970.htm  - basically lpar is where you do vmwarish things in-chip.  I doubt this beast does that, it's a "consumer" g5 mac.
[11:24] <fabbione> chmj: i never said it was going to be an easy task
[11:26] <chmj> fabbione: wich is why I'm saying that someone will need to manually check that
[11:26] <chmj> s/wich/which/g
[11:26] <fabbione> chmj: well if it's only 2/3 drivers is ok
[11:26] <fabbione> just spits out a warning to check them
[11:26] <fabbione> so that people will remember
[11:26] <jbailey> Nope, still no joy - almost like the framebuffer isn't loaded.
[11:26] <chmj> ok
[11:27] <fabbione> jbailey: FB doesn't build :/
[11:27] <jbailey> I get the Setup Done message, Starting Linux PPC64 2.6.12-1-powerpc64-smp blah blah down to smp_core99_probe smp_core99_kick_cpu smp_Core99_kick_cpu done  smp_core99_setup_cpu 0 done
[11:27] <jbailey> Right, lemme try ssh then. =)
[11:28] <fabbione> powerpc64-smp:CONFIG_FB=m
[11:28] <fabbione> no
[11:28] <fabbione> actually it is built
[11:28] <fabbione> ahhh i see
[11:28] <fabbione> it needs to be inline
[11:28] <fabbione> crap
[11:29] <jbailey> inline?
[11:29] <fabbione> CONFIG_FB=y
[11:29] <fabbione> instead of modular
[11:29] <jbailey> Right, but in the meantime I can modprobe it in the initrd
[11:29] <fabbione> yup
[11:29] <jbailey> It's not getting as far as getting ssh going, so there's some other issue, too.
[11:31] <fabbione> jbailey: probably there is more that needs modprobing
[11:31] <fabbione> if you can start adding fb stuff and see where it stops, that would be great
[11:31] <fabbione> i am pretty sure it's just question of config options
[11:32] <fabbione> but not having the frigging hw locally doesn't make it easier
[11:32] <jbailey> Iz no problem, boss.
[11:32] <fabbione> jbailey: thanks!
[11:34] <fabbione> jbailey: i suggest you to copy also the other FB modules
[11:35] <jbailey> Other than just radeonfb?
[11:36] <fabbione> there is a +CONFIG_FB_MACMODES=m
[11:36] <fabbione> i did it all modular, but problably it needs to go all inline
[11:41] <jbailey> Trying it with all those drivers in the initrd.
[11:42] <jbailey> No joy.
[11:43] <fabbione> crap
[11:44] <fabbione> are you actually modprobing them manually?
[11:44] <fabbione> or just hoping that they will get modprobed?
[11:44] <jbailey> No, putting them in the initrd which is set to modprobe them.
[11:44] <jbailey> I don't have enough connection to the machine at that point to modprobe anything.
[11:45] <jbailey> I don't think this box has a serial port.
[11:45] <fabbione> hmmmm
[11:45] <jbailey> On what speed box does it take 10 hours to build?
[11:46] <fabbione> jbailey: on davis
[11:46] <fabbione> but i can rebuild ppc64 only in not too long
[11:46] <fabbione> 10 hours is the whole package
[11:46] <fabbione> i am changing the config right now :)
[11:51] <fabbione> powerpc64-smp:CONFIG_FRAMEBUFFER_CONSOLE=m
[11:51] <fabbione> powerpc-smp:CONFIG_FRAMEBUFFER_CONSOLE=y
[11:51] <fabbione> yeah there is more :)
[12:00] <fabbione> ok it's building now
[12:01] <fabbione> it shouldn't take too long
[12:01] <jbailey> Cool, thanks.
[12:01] <fabbione> modulo gcc segfaults
[12:02] <fabbione> this will make the FB situtation similar to all the other ppc configs
[12:02] <fabbione> there might be more to change but at least you should be able to get the console
[12:03] <fabbione> i am going to get some lunch while it builds
[12:03] <fabbione> brb
[12:04] <fabbione> never mind.. it already failed on some drivers
[12:12] <jbailey> Cool - if I can see what's failing after this point, that would be lovely. ;)
[12:22] <fabbione> jbailey: i was thinking that perhaps mkinitrd will need ppc64 love too....
[12:22] <fabbione> what about glibc?=
[12:22] <fabbione> would a 64bit kernel search for 64 bit libc6?
[12:23] <jbailey> It shouldn't, no.
[12:24] <fabbione> jbailey: the image is up
[12:24] <jbailey> The first thing it does is fire up /linuxrc, which uses the shell script interpreter in the kernel to seek to /bin/sh, which is 32bit.
[12:24] <jbailey> Same filename as before?
[12:24] <fabbione> note that is the next version :)
[12:24] <fabbione> nope...
[12:24] <fabbione> 1.3
[12:24] <fabbione> instead of 1.2
[12:24] <jbailey> Thanks. =)
[12:25] <fabbione> no problem
[12:50] <fabbione> jbailey: new 1.3 image on people
[12:55] <fabbione> jbailey: tell me something while you are working on it.. your silence is killing me :)
[12:55] <jbailey> Lol, it's just installing.
[12:56] <jbailey> My connection to the data centre is crap.
[12:56] <fabbione> hehe ok
[12:56] <jbailey> booting.
[12:57] <jbailey> I still get a black screen
[12:57] <jbailey> Let's give it a sec and see if I can ssh in, though.
[12:57] <fabbione> crap
[12:57] <jbailey> hey
[12:58] <jbailey> X apparently works, even if the framebuffer doesn't. =)
[12:58] <jbailey> And I can ssh in now. =)
[12:58] <jbailey> I see that it's loading the radeonfb
[12:58] <fabbione> AHHHHHAHAHHAHAHAHA
[12:59] <jbailey> *lol*
[12:59] <fabbione> now...
[12:59] <fabbione> we need to understand why the FB sucks
[12:59] <fabbione> well...
[12:59] <fabbione> there is not much to understand.. it does :)
[01:00] <fabbione> jbailey: can stick dmesg output somewhere?
[01:00] <jbailey> $ file a.out
[01:00] <jbailey> a.out: ELF 64-bit MSB executable, cisco 7500, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), not stripped
[01:00] <jbailey> jbailey@ppc64:/tmp$ ./a.out
[01:00] <jbailey> Hello, world!
[01:00] <fabbione> eheheh
[01:01] <jbailey> sure, need a couple minutes to wake Angie up.
[01:01] <fabbione> no problem
[01:01] <jbailey> And the fans appear to have gone nuts. =)
[01:02] <fabbione> i am not sure APM or PM is available yet
[01:02] <fabbione> i didn't have any option to enable it
[01:04] <jbailey> This thing displaces an amazing amount of air.
[01:04] <jbailey> Also sounds a bit like a jet engine. =)
[01:04] <fabbione> ehhe
[01:04] <jbailey> http://people.ubuntu.com/~jbailey/dmesg.txt
[01:05] <fabbione> [   32.536434]  Console: colour dummy device 80x25
[01:05] <jbailey> Want one from the working setup too?
[01:05] <fabbione> isn't this one from the working ppc64 kernel?
[01:06] <jbailey> I mean from the working ppc32
[01:06] <fabbione> [   32.614271]  Calibrating delay loop... 66.56 BogoMIPS (lpj=33280)
[01:06] <fabbione> interesting
[01:06] <fabbione> yes.. later is fine...
[01:06] <jbailey> I may as well fetch it now to make the 747 go away...
[01:06] <fabbione> how much RAM do you have in that system?????
[01:07] <jbailey> Umm, Looks like 4gb?
[01:07] <fabbione> [   32.763094]  PowerMac SMP probe found 2 cpus
[01:07] <fabbione> uhuuh
[01:07] <fabbione> it's even SMP :)
[01:07] <jbailey> Yes
[01:07] <fabbione> jbailey: [   32.614139]  Memory: 3999720k/6291456k
[01:07] <fabbione> it's more like 6GB
[01:07] <jbailey> $ cat /proc/meminfo
[01:07] <jbailey> MemTotal:      4007812 kB
[01:07] <fabbione> but our kernels don't have more than GB highmem enabled
[01:08] <jbailey> Ah.
[01:08] <fabbione> yeah what's in meminfo comes from what the kernel can actually use :)
[01:09] <fabbione> we need to talk with benh about the FB stuff
[01:09] <fabbione> he hangs on debian-kernel
[01:11] <fabbione> he is not around
[01:13] <jbailey> On ppc32: [   25.954678]  Console: colour dummy device 80x25
[01:13] <jbailey> [   26.045504]  Calibrating delay loop... 1662.97 BogoMIPS (lpj=831488)
[01:15] <jbailey> On the ppc32 there's an extra:
[01:15] <jbailey> [   27.434522]  Console: switching to colour frame buffer device 210x65
[01:15] <jbailey> in there.
[01:16] <fabbione> hmmm
[01:24] <zul> he3y
[01:25] <jbailey> zul: Know anything about framebuffers? =)
[01:25] <zul> no :)
[01:29] <jbailey> Hmm, there's an fbset package.
[01:29] <fabbione> jbailey: that's not what i am looking for
[01:29] <jbailey> But I guess the problem might be making the console point to it?
[01:29] <fabbione> i can't find that exact string
[01:29] <fabbione> so it's generated at runtime
[01:30] <fabbione> that means that we need to find what driver spits it
[01:30] <chmj> jbailey: issint fbset a fluxbox util
[01:30] <fabbione> and see why in 32 bit works and not in 64
[01:30] <jbailey> chmj: No idea. =)
[01:31] <chmj> jbailey: bah, framebuffer device maintanance program
[01:35] <fabbione> ah here is
[01:35] <jbailey> ben's on.
[01:39] <chmj> fabbione: can I give you the watch proggie ?
[01:39] <fabbione> chmj: i am waiting for it...
[01:39] <zul> damn ties
[01:41] <chmj> fabbione: email ?
[01:41] <fabbione> chmj: or commit it in baz?
[01:42] <chmj> ok
[01:42] <fabbione> chmj: you have access to people, don't you?
[01:42] <chmj> yes
[01:42] <fabbione> so just use sftp instead of http to checkout/commit
[01:42] <fabbione> put it inside the debian/ dir
[01:47] <chmj> must I do that from chainstrap ?
[01:47] <fabbione> nope
[01:47] <fabbione> ssh to people is allowed from outise via ssh proxy
[01:48] <chmj> ssh proxy ?
[01:48] <fabbione> chmj: check the wiki
[01:48] <fabbione> there is the doc on how to set that up
[01:59] <fabbione> bbl
[03:01] <chmj> there goes my first kerne-team commit :)
[03:04] <fabbione> ./uscan-extmod --report .
[03:04] <fabbione> Processing ./kernel-extmod.kwatch ......
[03:04] <fabbione> uscan-extmod warning: could not open ./kernel-extmod.kwatch: No such file or directory
[03:05] <fabbione> A   passed.kwatch
[03:05] <fabbione> what's that?
[03:05] <chmj> usca-extmod --wathifile = passed.kwatch
[03:05] <chmj> uscan-extmod --wathifile passed.kwatch
[03:06] <chmj> the wathfile by default will be kernel-extmod.kwatch, one I got it looking pretty
[03:06] <chmj> s/one/once/
[03:06] <fabbione> ehhe nice :)
[03:07] <chmj> the script, or my typing ?
[03:08] <fabbione> the script :)
[03:08] <chmj> :)
[03:08] <fabbione> chmj: did already convert all the entries in external-drivers to the watch file?
[03:09] <fabbione> or only a few for sampling?
[03:09] <chmj> a lot
[03:09] <fabbione> all of them or only a selection?
[03:09] <fabbione> before we spend time updating that file to death...
[03:09] <chmj> only a section,
[03:09] <fabbione> ok
[03:09] <chmj> I'm trying to get the rest off the URLs
[03:10] <fabbione> chmj: ok. you tell me when it's ready for "deplyoment", but it looks good already :)
[03:11] <chmj> did I mention I hate "You don't have permission to access <insert driver location folder here> on this server."
[03:11] <fabbione> ehehhe
[03:13] <jbailey> So who thinks that Apple using "intel chips" might mean itanium? =)
[03:13] <zul> ok wish me luck
[03:13] <jbailey> zul: Good luck, chuck!
[03:16] <fabbione> zul: come back as winner!
[03:16] <jbailey> fabbione: fbcon working right.
[03:16] <fabbione> jbailey: cool
[03:17] <jbailey> fans haven't gone nuts.
[03:17] <jbailey> x is up
[03:17] <fabbione> jbailey: and yes.. i am sure apple will go ia64 :)
[03:17] <chmj> zul: what u need luck for ?
[03:17] <fabbione> goody
[03:17] <jbailey> ssh in.
[03:17] <jbailey> "...  and print!"
[03:23] <fabbione> chmj: you broke the baz archive!
[03:23] <fabbione> you need to fix your umask on people
[03:23] <fabbione> and change some permissions in the baz repo
[03:23] <fabbione> otherwise we are all doomed
[03:24] <fabbione> chmj: login to people and do what i say
[03:24] <fabbione> cd /home/lamont/public_html/Archives/kernel-team@ubuntu.com--2005/kernel-debian--pre1,3--<IP_ADDRESS>
[03:24] <fabbione> chmod 775 patch-4
[03:25] <fabbione> cd patch-4
[03:25] <fabbione> chmod 775 ++revision-lock
[03:25] <fabbione> cd ++revision-lock
[03:25] <fabbione> chmod 775 +contents
[03:26] <jbailey> Not find a chmod -R g+w
[03:26] <jbailey> s/find/just/
[03:26] <fabbione> jbailey: it's the same....
[03:26] <jbailey> ?
[03:27] <fabbione> chmj: once you have done go back to your home and:
[03:28] <fabbione> edit .bash_profile
[03:28] <fabbione> change the umask to look like:
[03:28] <fabbione> umask 002
[03:28] <fabbione> then edit .bashrc and add the same umask line
[03:29] <fabbione> logout
[03:29] <fabbione> and login again
[03:29] <fabbione> that will fix
[03:30] <chmj> done
[03:30] <fabbione> chmj: you need to change the permissions to all the dirs i told you
[03:30] <chmj> I did
[03:30] <fabbione> nope
[03:31] <fabbione>  /home/lamont/public_html/Archives/kernel-team@ubuntu.com--2005/kernel-debian--pre1,3--<IP_ADDRESS>/
[03:31] <fabbione> 4 drwxr-xr-x   3 charles  warthogs 4096 Jun  6 13:57 patch-4
[03:31] <fabbione> that needs to be 775
[03:31] <fabbione> same for the directories inside
[03:32] <chmj> recursively ?
[03:33] <fabbione> chmj: you are missing the ++revision-lock directory inside patch-4/
[03:33] <fabbione> the others are or seem to be ok
[03:36] <chmj> ok, done
[03:36] <fabbione> ok thanks
[03:37] <fabbione> yup
[03:37] <fabbione> did also change your netmask?
[03:37] <fabbione> anyway i need to go offline again
[03:37] <fabbione> bbl
[03:39] <jbailey> fabbione: s/netmask/umask/ ?
[03:40] <chmj> erm,bashrc and bash_profile, done
[03:51] <fabbione> yeah that :)
[04:37] <jbailey> O
[04:37] <jbailey> I'm trying to imagine what the ugliest scenario the initramfs might have to cope with for booting, and whether I care.
[04:38] <jbailey> I'm adding the hooks in, but obviously somethings might care what order they're run in, like lvm before md, and cryptroot after both.
[04:49] <mjg59> Any idea when the -1.2 builds are likely to be done on x86?
[04:49] <jbailey> None.  And Fabio may have sent up -1.3 with the ppc64 changes from this morning.
[04:50] <mjg59> Ah
[04:50] <mjg59> Fair enough
[05:52] <fabbione> no i didn't push 1.3 to archive.
[05:52] <fabbione> 1.2 needs NEW love
[05:52] <fabbione> and i386 is FTBFS
[05:53] <mjg59> Ah, ok
[05:53] <fabbione> hell it did build here!
[05:53] <fabbione> Inconsistent kallsyms data
[05:53] <fabbione> Try setting CONFIG_KALLSYMS_EXTRA_PASS
[05:53] <fabbione> BAH
[05:53] <fabbione> make[2] : Leaving directory `/build/buildd/linux-source-2.6.12-<IP_ADDRESS>/debian/b
[05:53] <fabbione> uild/build-686-dbg'
[05:54] <fabbione> well this is tomorrow's stuff
[09:00] <lamont_r> fabbione: linux-source-2.6.12 won't build on hppa until expect-tcl8.3 arrives in the archive and gcc-3.4 is buildable
[09:03] <doko> lamont: expect-tcl8.3 was made only for you^H^H^Hhppa ;)
[09:04] <lamont_r> doko: yeah
[09:05] <lamont_r> but it's not in the ubuntu archive.  hence gcc-3.4 is pending...
[09:05] <doko> so build it, don't grumble ;-)
[09:05] <lamont_r> another option would be to disable the tests on hppa... :)
[09:05] <doko> it's not?
[09:05] <lamont_r> ah, is in universe
[09:05] <lamont_r> coolness
[10:02] <zul> well round one done
[10:11] <zul> miss a day...miss alot


 I WANT TO GO BACK IN HOLIDAYS!
[06:22] <desrt> woh
[06:22] <fabbione> ;)
[06:22] <desrt> sounds like you could really use another week or two :P
[06:23] <fabbione> easily...
[06:23] <desrt> anyway.. i was hacking yaboot on the weekend
[06:23] <desrt> as it is, breezy won't boot on an xserve unless it has a videocard
[06:23] <fabbione> hmmm
[06:23] <desrt> i have a fix
[06:24] <desrt> but......
[06:24] <fabbione> but?
[06:24] <desrt> it disables the stage 1 yaboot menu
[06:24] <desrt> ie: it just loads stage 2 directly
[06:24] <desrt> (stage1 is the part that has a problem)
[06:24] <fabbione> i don't think that's a solution
[06:24] <desrt> well, it is for me :)
[06:24] <fabbione> yeah for you...
[06:24] <desrt> it's only a problem if you have multiple OSes installed (macos dualboot)
[06:24] <desrt> i'm working on generalising the code
[06:25] <desrt> but work has been a bit hectic the past week
[06:25] <desrt> + i don't know forth :)
[07:08] <fabbione> BenC: still awake?
[07:26] <infinity> Gar, is there something mind-numblingly obvious I'm missing, or is the kernel bridging interface really such utter shit?
[07:26] <infinity> When I unplug a cable from one of the bridged interfaces, the whole bridge goes down.  YAY.
[07:26] <infinity> (Or power cycle the system it's plugged into, or whatever)
[07:27] <fabbione> eth brinding?
[07:27] <fabbione> that shouldn't happen
[07:27] <infinity> ethernet, yes.  When one interface loses linkbeat, the bridge dies.
[07:27] <fabbione> are you sure you have no userland tools checking via mii that the iface is connected to a cable?
[07:28] <infinity> (Doesn't actually down the interface, just stops relaying packets, even after the linkbeat comes back)
[07:28] <infinity> Oh, it's possible.  THe bridge is on a breezy desktop, so there might be some irritating magic going on.
[07:28] <fabbione> becasue i use brindging on 2.4 on a dead iface to talk to xen domains
[07:28] <infinity> Though I can't think of what (no, network-manager isn't installed)
[07:28] <fabbione> infinity: try to do it in single user mode to see if it is userland?
[07:33] <desrt> this is completely and totally awesome
[07:35] <fabbione> desrt: what?
[07:35] <desrt> excuse the paste
[07:35] <desrt> 0 > boot hd:2,\\yaboot load-size=24830 adler32=ad6b4eba
[07:35] <desrt> Loading ELF
[07:35] <desrt> Config file read, 678 bytes
[07:35] <desrt> Welcome to yaboot version 1.3.13
[07:35] <desrt> Enter "help" to get some basic usage information
[07:35] <desrt> boot:
[07:35] <desrt>   Linux                      old
[07:35] <desrt> boot: Linux
[07:35] <desrt> Please wait, loading kernel...
[07:35] <desrt>    Elf32 kernel loaded...
[07:35] <desrt> Loading ramdisk...
[07:35] <desrt> i can interact with openfirmware (and yaboot) using a whole bunch of methods
[07:36] <desrt> including -telnet-
[07:36] <fabbione> yeah i knew that OF has telnetd
[07:36] <desrt> that's awesome!
[07:36] <desrt> like, crikey!
[07:36] <fabbione> infinity: ask svenl for upgrades :)
[07:37] <infinity> You think he'll swing me a dual G5 to replace my G3? :)
[07:37] <fabbione> i meant software..
[07:37] <fabbione> and join the queue for g5's ;)
[07:38] <infinity> Software's a no-go.  You can't update the firmware on the Beige G3 past version 2.4 (which I have)
[07:38] <infinity> OF didn't start sucking less until 3.0 (NewWorld), though.
[07:39] <fabbione> i need to hook me up with a nice toy
[07:39] <fabbione> probably i will soon get money for a new machine
[07:39] <fabbione> and i don't want it to be i386
[07:39] <fabbione> either ppc or amd64
[07:39] <fabbione> not sure yet
[07:39] <infinity> I like my amd64.
[07:39] <infinity> And my ppc, for that matter.
[07:39] <fabbione> or replace my server with a couple of sparcs
[07:40] <fabbione> OR
[07:41] <fabbione> make my workstation a new server
[07:41] <fabbione> and buy a new workstation
[07:44] <Mithrandir> amd64 is teh love.
[07:44] <fabbione> yeah i know..
[07:46] <Mithrandir> and hi and good morning and stuff
[07:58] <fabbione> hmmm
[07:58] <fabbione> what's a good brand of ATA harddisks by now?
[07:59] <fabbione> i have the following options: Maxtor, Seagate, WD
[07:59] <calc> seagate seems good and iirc has 5 year warranty
[08:00] <calc> i want my next system to be an amd64 mac mini
[08:00] <fabbione> calc: i am looking for 4x300GB harddisk to replace my server
[08:00] <fabbione> instead of the 8x120GB that i have now
[08:01] <calc> maxtor/wd have shorter warranties iirc so seagate is likely the most reliable as well
[08:01] <fabbione> Maxtor has 16MB of cache compared to the 8Mb of the others..
[08:01] <calc> and the seagate 7200.8 series goes up to 500gb
[08:01] <fabbione> WD has 320GB instead of 300 of the others...
[08:02] <fabbione> calc: i am looking at what's available around :)
[08:02] <fabbione> at least on local hw shops
[08:02] <calc> oh
[08:02] <calc> seagate 400gb seems to be generally available so they may have that also
[08:03] <fabbione> OH right
[08:03] <fabbione> they are 2 lines below
[08:03] <fabbione> they are double as expensive as the 300GB
[08:03] <calc> i see 7200.8 400gb for sale via pricewatch already not sure if regular stores will have that yet
[08:04] <calc> heh
[08:04] <calc> yea i see 300gb seagate for $152 and 400gb for $230 on pricewatch which is still a bit expensive
[08:05] <calc> oh yea the seagate sata drives do ncq as well, not sure about maxtor/wd
[08:05] <fabbione> IMPRESSIVE
[08:05] <fabbione> they are selling Apple.. they didn't use to
[08:08] <fabbione> Mithrandir: what's a good SATA controller?
[08:12] <fabbione> given the minimum differnce in price for the hd, it might be worth making the array SATA
[09:30] <Mithrandir> fabbione: I've actually good experiences with the sii3114
[09:43] <Mithrandir> fabbione: do you have a kernel for me?
[09:46] <fabbione> Mithrandir: Herbert is working on it
[09:46] <Mithrandir> ok, cheers
[10:00] <fabbione> jbailey: i managed to fix klibc on sparc64..
[10:23] <fabbione> Mithrandir: is the sii from 3ware?
[10:23] <Mithrandir> no, silicon image
[10:23] <fabbione> ok
[10:24] <fabbione> of course my hw pusher doesn't have it
[10:24] <Mithrandir> it's often onboard.
[10:24] <fabbione> ah ok..
[10:24] <Mithrandir> and it's the chip name
[10:24] <Mithrandir> http://www.hwb.no/artikkel/15307
[10:24] <Mithrandir> has a test of different controllers.
[10:24] <fabbione> i am looking for a PCI card
[10:26] <fabbione> the 3ware they have is the same as in that pic :)
[10:28] <Mithrandir> well, read the article.  It's fairly decent.
[10:28] <fabbione> Kjernen benyttet under testingen var <IP_ADDRESS>-5-amd64-k8-smp. Det ble brukt x86_64-versjonen av Warty.
[10:28] <Mithrandir> you can read norwegian well enough, can't you?
[10:28] <fabbione> yeah i think so :)
[10:31] <fabbione> well it's a lot of benchmarks
[10:31] <fabbione> but tbh i am not too interested into speed...
[10:31] <fabbione> more about: "It works in Linux,, it doesn't work"
[10:32] <Mithrandir> all of the controllers there work in Linux, obviously. :-P
[10:32] <fabbione> yeah clearly :)
[10:34] <fabbione> looking at the graphs, it makes me wish to buy SCSI :)
[10:35] <Mithrandir> there's a SCSI controller in there as well
[10:35] <fabbione> yeah.. that's why :)
[10:49] <doko> fabbione: the 3ware's are fine controllers, but spend the extra money for the 9500
[10:56] <fabbione> doko: yeah.. it also costs a fortune :)
[11:00] <infinity> Adaptec's 2410 isn't so bad. (or 2810 if you need 8 ports)
[11:01] <infinity> I'd push the 3ware stuff if money was no object, but they are very pricey.
[11:05] <fabbione> yeah
[11:05] <fabbione> but given that it's one time expense.. i guess i can look into 3ware too
[01:57] <mjg59> fabbione: I have ACPI fixup patches for you. Shall I just email a tarball with justification?
[02:00] <fabbione> mjg59: that would do
[02:02] <mjg59> fabbione: Ok, cool
[02:04] <fabbione> mjg59: from now on, please start to CC BenC
[02:05] <fabbione> he will take over the kernel soon..
[02:06] <mjg59> fabbione: Will do
[02:06] <mjg59> fabbione<EMAIL_ADDRESS>[02:07] <fabbione> mjg59: meh.. hold on..
[02:07] <fabbione><EMAIL_ADDRESS>[02:07] <mjg59> Ok
[02:39] <mjg59> fabbione: Mailed
[02:40] <fabbione> mjg59: ok
[02:40] <fabbione> you gotta be kidding...
[02:40] <fabbione> 300KB of tar.gz?????
[02:41] <mjg59> fabbione: Most of that's a replacement for the existing acpi update patch
[02:42] <fabbione> ok
[02:43] <fabbione> mjg59: want to take a look at bugzilla and start marking bugs as pending upload?
[02:43] <mjg59> fabbione: Sure, will do
[02:45] <fabbione> jbailey: ping?
[02:45] <jbailey> fabbione: pong
[02:45] <fabbione> jbailey: did you like the klibc upload?
[02:46] <jbailey> I saw that it had been done, but it's just coming down now. =)
[02:46] <fabbione> nothing too fancy..
[02:46] <fabbione> change the B-D for new kernel headers
[02:46] <fabbione> added a specific sparc64 patch to fix FTBFS
[02:47] <fabbione> that doesn't touch any of the other code
[02:47] <fabbione> so pretty safe
[02:54] <mjg59> fabbione: The patch in 11813 ought to be applied
[02:56] <fabbione> OH DAMN SHIT
[02:57] <fabbione> there is no connectivity with uk toady
[02:57] <fabbione> like yesterday
[02:57] <fabbione> ok.. it's taking ages...
[02:57] <fabbione> mjg59: i need to take my wife to the doc and i will be back in about 2 hours or so
[02:57] <fabbione> probably more...
[02:57] <fabbione> just create a list and mail it..
[02:58] <fabbione> or whatever you prefer..
[02:58] <fabbione> just don't leave the list here on IRC :)
[02:59] <mjg59> fabbione: No problem
[02:59] <fabbione> thanks
[03:21] <jbailey> fabbione: Looks good, thanks.
[03:42] <fabbione> i think nobody noticed before, because klibc was probably built on sparc32 or so
[03:42] <fabbione> that's what come up to mind now..
[03:42] <fabbione> but we don't care to build in 32 bit
[03:43] <fabbione> given that: A) we don't support 32bit b) it's all used once at boot and trashed away
[03:43] <fabbione> anyway.. time to go
[03:43] <fabbione> bbl
[06:01] <fabbione> re
[06:02] <fabbione> BenC: ping?
[06:05] <fabbione> mjg59: i got the patches..
[06:05] <mjg59> fabbione: Rock
[06:08] <fabbione> mjg59: are all the patches done to be applied at the end of 00list?
[06:08] <fabbione> with the order you gave.. or somewhere else?
[06:08] <mjg59> fabbione: Which ones? The first batch or the second batch?
[06:09] <fabbione> both...
[06:09] <mjg59> The second batch should all go after the first batch, but the order doesn't matter
[06:09] <mjg59> The first batch should have the big patch first, followed by acpi-revert-pci-interrupt-resume
[06:10] <fabbione> ok
[06:10] <fabbione> than all the others in no special order...
[06:10] <mjg59> Yeah
[06:10] <fabbione> ok
[06:11] <mjg59> The others all depend on the first two, but other than that are order independent
[06:11] <fabbione> ok
[06:13] <fabbione> on which arches did you test them?
[06:13] <fabbione> do they build on ia64?
[06:13] <mjg59> Tested on x86
[06:13] <fabbione> what about amd64?
[06:13] <mjg59> I don't have access to any ia64
[06:14] <mjg59> I'll check amd64 now
[06:14] <fabbione> ok.. do you don't know if they build on amd64/ia64...
[06:14] <fabbione> try to be around tomorrow than
[06:14] <fabbione> if you can
[06:14] <fabbione> i will start merging now
[06:14] <fabbione> but i will build tomorrow probably...
[06:15] <mjg59> Sure, no problem
[06:15] <mjg59> fabbione: Oh, one thing I forgot to mention - the acpi-i2c one adds a new config option
[06:15] <fabbione> i saw that
[06:16] <mjg59> Ok
[06:16] <fabbione> i guess M is fine...
[06:16] <mjg59> Yup
[06:16] <fabbione> perfect
[06:17] <fabbione> hmmm agp-pm...
[06:17] <fabbione> didn't we include that one already?
[06:17] <mjg59> I don't think so
[06:18] <fabbione>   * Add PCI-E suspend/resume support:
[06:18] <fabbione>     - Add patch drivers-pci-pcie_resume-pcie.dpatch.
[06:18] <fabbione> no
[06:18] <fabbione> it was the PCI-E
[06:18] <mjg59> Yeah
[06:21] <fabbione> mjg59: where all these patches are coming from?
[06:21] <fabbione> just to annotate them properly...
[06:22] <mjg59> fabbione: The acpi ones are all from acpi upstream, except for the ones that we were already carrying
[06:22] <mjg59> toshiba-acpi-dev is from John Belmonte's website
[06:22] <mjg59> agp-pm is from the suspend2 tarball (which contains no indication of who wrote it)
[06:23] <mjg59> acpi-i2c is from Bruno Ducrot's website
[06:23] <mjg59> The reboot patch is me
[06:24] <fabbione> ok
[06:56] <fabbione> mjg59: only 4 left to apply :)
[06:57] <mjg59> fabbione: Woo!
[06:57] <mjg59> fabbione: I've got another couple for you...
[06:57] <mjg59> (But then that's it for the day)
[06:58] <jbailey> mjg59: At some point when you have t ime, can I get you to look over the DSDT patch that I've got to see why the classic initrd case fails?
[06:58] <mjg59> jbailey: I can have a go, yeah
[06:58] <fabbione> mjg59: send me...
[06:58] <jbailey> mjg59: Either that or do you think I can get rid of that case an only handle having a DSDT.aml file in the initramfs?
[06:58] <jbailey> the initramfs case works.
[06:58] <mjg59> Breezy is going with initramfs?
[06:58] <fabbione> mjg59: we already switched
[06:58] <jbailey> mjg59: Yes, it's default already. =)
[06:59] <mjg59> Yeah. I'd drop the initrd support, then.
[06:59] <jbailey> mjg59: Nice, saves much trouble. =)
[06:59] <jbailey> That's the part of the patch I'm having trouble with.
[07:02] <fabbione> applying patch external-drivers-acpi-hardware-hwsleep_gpe-specs to ./ ... failed.
[07:03] <mjg59> Oops
[07:03] <mjg59> That's odd
[07:04] <mjg59> Oh, shit
[07:04] <mjg59> Sorry, I accidently diffed it from the wrong directory level
[07:04] <mjg59> Looked like drivers-acpi-sleep-main_make-system-ready-to-resume.dpatch has the same problem
[07:10] <mjg59> fabbione: Ok, that's it for now
[07:11] <fabbione> mjg59: ok.. everything applies perfectly
[07:12] <fabbione> mjg59: got the last mail
[07:12] <mjg59> Rock
[07:15] <fabbione> mjg59, BenC: i am going to commit the all ACPI stuff untested
[07:15] <fabbione> i only know it applies clean
[07:15] <mjg59> Ok
[07:15] <fabbione> it will need a proper changelog entry
[07:15] <fabbione> test build
[07:15] <fabbione> and overall configs update
[07:16] <fabbione> on all arches..
[07:16] <mjg59> The ACPI stuff is all from upstream, and I haven't /seen/ any complaints on other architectures
[07:16] <fabbione> mjg59: well.. i would like to see it at least builded everywhere
[07:16] <mjg59> Sure
[07:17] <fabbione> BenC: you might have to ask elmo to upgrade some of the chroots.. iirc i did bump a B-D recently
[07:25] <BenC> so you have to build it on all architectures first, then update the debian/abi/* and then do the source upload?
[07:25] <BenC> oops
[07:35] <fabbione> * committed kernel-team@ubuntu.com--2005/kernel-debian--preX,11--2.6.12--patch-18
[07:35] <fabbione> ok this is the commit with all the ACPI crack
[07:37] <fabbione> https://bugzilla.ubuntu.com/show_bug.cgi?id=11813
[07:37] <fabbione> we forgot the patch in here
[07:37] <mjg59> Oops
[07:37] <mjg59> Sorry, meant to send that to you
[07:37] <fabbione> mjg59: is that patch still needed?
[07:38] <mjg59> Yeah
[07:38] <fabbione> oh my mother just bored me enough on the phone to push me to look at bugzilla for fun
[07:38] <mjg59> Haha
[07:38] <fabbione> i need to go and start to cook dinner
[07:38] <fabbione> BenC: do you want to take care of it?
[07:38] <fabbione> just add it at the end of the list
[07:39] <fabbione> we also need that PATA patch.. and i think we are done for 7.11
[07:39] <fabbione> there is enough crack for the rest of week
[07:40] <fabbione> EHHHH??!?!?!?!???
[07:40] <fabbione> ld  -o tests/nfs_no_rpc crt0.o tests/nfs_no_rpc.o libc.a /usr/lib/gcc/sparc-linux-gnu/4.0.2/libgcc.a
[07:40] <fabbione>  /usr/lib/gcc/sparc-linux-gnu/4.0.2/libgcc.a(_muldi3.o): In function `__muldi3':
[07:40] <fabbione>  : undefined reference to `.umul'
[07:40] <fabbione> I DID FUCKING TEST BUILDED IT BEFORE UPLOAD ON EXACTLY THE SAME CHROOT
[07:41] <fabbione> ah no..
[07:41] <fabbione> different binutils..
[07:41] <fabbione> Grrrrr
[07:42] <BenC> sure
[07:43] <fabbione> BenC: cool
[07:44] <fabbione> BenC: if you feel lucky today, there is libaio that is not ported to sparc ;)
[07:44] <fabbione> it's missing an include file with some asm to generate direct syscalls to the kernel bypassing libc
[07:44] <fabbione> ;)
[07:46] <jbailey> fabbione: Why?
[07:47] <fabbione> async i/O
[07:47] <fabbione> it's faster for certain apps like DB
[07:47] <fabbione> (that's the answer i got from upstream at least)
[07:48] <fabbione> anyway... i need to go now
[07:48] <fabbione> i might pass by later
[07:51] <BenC> later
[07:51] <BenC> I'll check into libaio after I do a kernel build
[07:51] <BenC> or better, while the kernel is building
[07:51] <fabbione> BenC: that one is off line and just for fun :)
[07:51] <fabbione> it's not important for sparc anyway
[07:52] <BenC> ok
[09:22] <michele> hello
[09:22] <michele> I'd like to know if this patch (or something to that effect) is going to make into breezy: http://marc.theaimsgroup.com/?l=linux-kernel&m=111504542402455&w=2
[09:23] <fabbione> no
[09:23] <fabbione> that patch is broken
[09:23] <fabbione> and breaks SCSI
[09:23] <fabbione> + other stuff
[09:23] <michele>  oh nice...
[09:24] <michele> does something else exists to have power mgmt in SATA systems?
[09:24] <fabbione> not yet
[09:24] <michele> so I guess that patch isn't even recommended to apply by myself right?
[09:25] <fabbione> 9/10K
[09:25] <michele> uh?
[09:25] <fabbione> nope
[09:26] <fabbione> don't apply it
[09:26] <michele> ok... sigh
[09:38] <mjg59> fabbione: I still don't see any way it can break SCSI
[09:38] <mjg59> The only way it touches the SCSI layer is to add hooks for suspend/resume
[09:38] <mjg59> On the other hand, it doesn't /work/ for SCSI
[09:39] <fabbione> mjg59: ask greg or jeff.. i really don't know and i don't want to experiment it at 2 weeks from preview
[09:39] <mjg59> fabbione: I spoke to alan about it last week
[09:40] <fabbione> alan C?
[09:40] <mjg59> greg and jeff haven't replied to my mails about it
[09:40] <mjg59> Yeah
[09:40] <fabbione> what did he say?
[09:40] <mjg59> He said he couldn't see any problems with it
[09:42] <mjg59> The only code that touches the SCSI subsystem is scsi_bus_suspend and resume
[09:42] <mjg59> As far as I can tell, the objection is that it doesn't successfully suspend/resume SCSI (but then, that doesn't work /anyway/)
[09:43] <mjg59> The rest of it's all safely contained in the sata layer
[09:43] <fabbione> i think the issue was not SCSI as drivers, but as transport layer
[09:44] <mjg59> It doesn't touch that part of the kernel
[09:44] <mjg59> It's all libata stuff except for scsi_bus_suspend and scsi_bus_resume
[09:44] <fabbione> i know.. but that's what they were talking about
[09:44] <michele> fabbione, I can offer to test it in my thinkpad in case you decide to build a package. I have a spare 5GB.
[09:44] <mjg59> There's absolutely no way that that code can touch it
[09:45] <fabbione> michele: one test is not enough over 2309208 millions different combination of hw
[09:45] <michele> fabbione, I know... just in case you needed it. Not trying to push you.
[09:46] <mjg59> The only thing it will do on a SCSI setup is check whether the driver has a suspend method, and if so call it
[09:46] <fabbione> let me ask again...
[09:46] <fabbione> lamont: build or try to from baz..
[09:46] <mjg59> fabbione: I'm prepared to believe that it's a patch that won't always work, but I can't see any way that it can make things worse than they currently are
[09:47] <mjg59> lamont: Newer acpi crack is in, I have no ia64
[09:47] <fabbione> i committed all the acpi crack 2/3 hours ago
[09:48] <lamont> mjg59: coolness
[09:48] <mjg59> lamont: If you want to send me an ia64 laptop...
[09:49] <lamont> mjg59: I don't think they exist, but a zx2000 might be able to land on your doorstep
[09:50] <lamont> it's kinda like a laptop :-)
[09:50] <lamont> in that it'll fill your lap.
[09:50] <mjg59> lamont: Hmm. Unconvinced.
[09:50] <mjg59> Oh, it's on of /those/
[09:51] <mjg59> Did Microsoft ever ship Windows for Itanium?
[09:52] <fabbione> lamont: i am still waiting for my ia64 and hppa :)
[09:52] <lamont> mjg59: HP certainly shipped it.  I expect that MS is at least supporting it in some manner....
[09:53] <fabbione> mjg59: Jeff says 2 things about that patch that he wrote
[09:53] <fabbione> a) it's experimental and not ready for upstream
[09:53] <fabbione> b) it needs a lot of SCSI love to work properly
[09:53] <mjg59> fabbione: Right. But it /does/ work on some systems.
[09:54] <fabbione> yes.. but it might as well breaks other
[09:54] <fabbione> or make them worst than they are
[09:54] <mjg59> fabbione: Uh. At the moment, suspend/resume is broken on *all* SATA machines.
[09:54] <mjg59> There's no way to make them worse.
[09:54] <fabbione> dude.. that's what he said right now
[09:55] <mjg59> I entirely understand why it's not ready for upstream. He wants it to work properly.
[09:55] <mjg59> But failing to work in some cases is still better than failing to work in all cases.
[09:56] <lamont> mjg59: there's an HP org that supports ia64/windoze
[09:56] <mjg59> lamont: Wow
[09:56] <lamont> not sure how much of that is just front-ending M$, though
[09:57] <fabbione> actually....
[09:57] <fabbione> mjg59: the patch can be splitted in 2 i think
[09:57] <fabbione> mjg59: scsi and sata
[09:57] <mjg59> fabbione: Mm?
[09:57] <fabbione> they look sort of indipendet one from each other..
[09:57] <mjg59> fabbione: No - the SCSI part is needed to call the SATA suspend/resume methods
[09:58] <fabbione> it doesn't look like...
[09:58] <mjg59> Check the scsi_bus_suspend routine. It stops the SCSI queue, checks whether the driver has a suspend method and then calls it
[09:58] <mjg59> +	if (sht->suspend)
[09:58] <mjg59> +		err = sht->suspend(sdev);
[09:59] <fabbione> ah ok..
[09:59] <mjg59> On SATA devices, that'll call ata_scsi_device_suspend
[09:59] <mjg59> On SCSI devices, it's a noop
[09:59] <mjg59> Until someone writes the support for them
[10:00] <mjg59> So the only thing it does on SCSI systems is to call scsi_device_quiesce(sdev) and scsi_device_resume(sdev);
[10:00] <mjg59> Which is safe
[10:01] <fabbione> BenC: what do you think?
[10:23] <fabbione> i am going to sleep on it..
[10:24] <fabbione> BenC: if you think the patch is reasonable.. go ahead and commit it..
[10:25] <fabbione> leave a note in an email on what you will manage to finish, so i don't need to spend time tomorrow digging around...
[10:25] <fabbione> good night ladies
[10:25] <mjg59> Night
[10:28] <fs> mjg59: are the acpi patches for the ubuntu kernel somewhere public?
[10:28] <mjg59> fs: They're in the baz archive
[10:29] <fs> is it more than acpi-20050729-2.6.12.patch.bz2?
[10:29] <fs> or git-latest acpi stuff in -mm?
[10:30] <mjg59> It's acpi-20050729 plus most of the to-linus from git
[10:30] <mjg59> So it ought to be pretty close to 2.6.13 mainline
[10:30] <fs> I see
[10:32] <fs> the acpi patch made battery and thermal working on my turion64 box, a 2.6.13-rc git snapshot from a couple of days ago did not
[10:32] <mjg59> You might want to try the ec_burst_mode parameter
[10:33] <mjg59> Or something like that
[10:34] <fs> where?
[10:36] <mjg59> On the kernel command line
[10:36] <mjg59> Hang on a sec
[10:37] <mjg59> Depending on your kernel version, there'll either be an ec_polling parameter or an ec_burst= parameter
[10:38] <mjg59> ec_polling will force a kernel that uses burst mode to use polling mode. ec_burst=1 will force a kernel that uses polling mode to use burst mode
[10:39] <fs> I have <IP_ADDRESS>+acpi now, and that looks like it has ec_polling
[11:22] <BenC> anyone been able to verify if the acpi patch fixes any of the reported bugs?
[11:27] <mjg59> BenC: It ought to fix the various delayed ACPI event bugs, the ones where resuming causes "scheduling while atomic" errors and the fact that the screen doesn't lock when the lid is closed
[11:28] <mjg59> But I wasn't bitten by any of those, so it's a bit hard to tell for certain...
[11:29] <BenC> build fails on ppc
[11:30] <BenC> kernel/power/main.c: In function `suspend_finish':
[11:30] <BenC> kernel/power/main.c:126: error: structure has no member named `leave'
[11:30] <BenC> kernel/power/main.c:127: error: structure has no member named `leave'
[11:31] <BenC> debian/patches/drivers-acpi-sleep-main_make-system-ready-to-resume.dpatch is the culprit that adds those lines
[11:32] <mjg59> BenC: Argh. A patch hunk has gone missing, somehow.
[11:33] <BenC> yeah, it's in the patch
[11:33] <BenC> but include/linux/pm.h doesn't seem to contain the patch for the leave member
[11:34] <BenC> wtf
[11:35] <mjg59> BenC: Ok, got a fixed one for you
[11:36] <mjg59> I'll mail it now
[11:37] <mjg59> BenC: Ok, mailed
[11:37] <BenC> duhthe patch isn't getting applied
[11:38] <mjg59> BenC: Uhm. If the patch isn't getting applied, how does it cause the build to fail?
[11:38] <BenC> let me check something
[11:39] <mjg59> But yeah, there was certainly a hunk missing from that patch
[11:39] <BenC> ok
[11:39] <BenC> the patch I was looking at wasn't getting applied
[11:39] <BenC> must be an old one
[11:40] <BenC> the patch that is getting applied didn't have the pm.h hunk
[11:42] <BenC> thanks, got the updated one
[11:44] <BenC> starting the build over
[11:44] <mjg59> BenC: Cool. Sorry about that.
[11:45] <BenC> no problem
[12:05] <BenC> mjg59: drivers-acpi-sleep-main_make-system-ready-to-resume.dpatch was not listed in 00list-7.11, is there any order that it should be in regards to the other acpi patches?
[12:06] <mjg59> BenC: After the global patch. Other than that, I don't think it matters.
[12:08] <BenC> hmm
[12:08] <BenC> I don't think fab added all the patches in 00list-7.11
[12:10] <BenC> I'll get it squared away


[09:07] <jphilips> hi all. i contribute to xubuntu and wanted to give some feedback to the kubuntu web team after visiting the website
[09:10] <jphilips> on the homepage, there are 4 clickable images for download, tour, help & support, and contribute, but the text under the images arent clickable, even though they have a mouseover effect
[09:13] <jphilips> also on the homepage, paragraphs are jammed together as there is no spacing after each paragraph
[09:13] <jphilips> https://imgur.com/wptYUgz.png
[09:21] <jphilips> who in the team is handling social media
[09:44] <RikMills> spacing should be better
[09:45] <RikMills> a lot of the pages were created with an old wordpress version, and when edited with new wordpress, it helpfully decides to remove some formatting it thinks is no longer needed!
[09:46] <RikMills> I bodeged it for now, but the pages need to be redone with the new block style editor
[09:57] <jphilips> yep thats better
[09:58] <jphilips> any input on the clickable links
[10:00] <jphilips> on the news page, would be good the change the grey 1px separator to potentially blue, so its more visible
[10:00] <jphilips> there seems to be something missing on the date lines 'On February 19, 2020, , In News, With No Comments'
[10:00] <jphilips> you have a comma after the year and then empty space and then another comma
[10:02] <jphilips> seems like alot of space between the 'read more' button and the separator
[10:07] <jphilips> would be good to also have the torrent files shown on the download page, as these have automatic verification
[10:09] <jphilips> on the feature tour page, there are icons at the top, which seem to be clickable, but dont jump to the section on the page about the app
[10:12] <jphilips> on the contribute page, maybe change the icon for testing to something like a test paper with checkmarks on it and for documentation have an icon with a question mark
[10:12] <jphilips> https://www.section508.gov/sites/all/themes/508retheme/images/icons/test-white.png
[10:13] <jphilips> https://upload.wikimedia.org/wikipedia/commons/thumb/7/72/Torchlight_help_icon.svg/768px-Torchlight_help_icon.svg.png
[10:14] <jphilips> or a life raft - https://cdnimg.webstaurantstore.com/uploads/design/2017/3/support-basic-icon.png
[10:15] <jphilips> presume a help icon should already be there in breeze
[10:17] <jphilips> RikMills: think you need to changed your irc handle on the kubuntu team page, as it shows acheronuk. :D
[10:18] <RikMills> keep going if you have more :)
[10:19] <RikMills> some things we are locked out of changing, but we will do what we can
[10:21] <keithzg[m]> Funny story, I actually used the Breeze help icon in the (much micromanaged, but that's another story) website redesign I did for my work ;) It's a life preserver: http://gmcl.com/images/breeze/icons/apps/48/system-help.svg
[10:33] <jphilips> as you asked for me :D
[10:33] <jphilips> on the homepage
[10:34] <jphilips> 1. change the download icon from the world to something common with downloading, like a down arrow
[10:35] <jphilips> 2. change the help icon to the same used on the contribute page
[10:35] <jphilips> 3. change contribute icon to something with a hand in it, rather than code brackets which only symbolize coding contributions
[10:37] <jphilips> maybe something like this with various contribution categories in place of the coins
[10:37] <jphilips> https://www.countryfinancial.com/content/dam/cfin/bands/icons/icon_individualinvestment_annuities_variable_contributions-01.png
[10:38] <jphilips> or better yet something with multiple hands - https://cdn1.iconfinder.com/data/icons/team-work-and-stakeholders-2/500/12-512.png
[10:39] <jphilips> on new page
[10:40] <jphilips> 1. large amount of empty space in the right column
[10:41] <jphilips> on feature page
[10:41] <jphilips> 1. reduce the amount of space below each heading
[10:44] <jphilips> 2. 'Open and read documents easily' seems strange for okular. does it open anything other than pdfs?
[10:45] <jphilips> on contribute page.
[10:45] <keithzg[m]> jphilips: I have an epub book open in Okular literally as we speak!
[10:46] <jphilips> so pdfs, epubs, and?
[10:47] <keithzg[m]> CBZ files too, I know that one.
[10:47] <jphilips> does it open .docx or .odt files
[10:47] <jphilips> cbz is a zip with jpgs in it :D
[10:48] <keithzg[m]> I know that! But it's a nicer experience to open those in Okular than in a zip file GUI ;)
[10:48] <jphilips> of course, just wondering what other types of documents it handles
[10:48] <keithzg[m]> Okular opens .odt files, no idea about .docx files since I avoid those like the plague ;)
[10:49] <jphilips> okay then the heading seems fine. when i first read it, i was quite sure i was going to see libreoffice below it
[10:49] <keithzg[m]> https://okular.kde.org/formats.php
[10:51] <jphilips> getting back to the contribute page
[10:51] <jphilips> 1. layout the items in 2 columns
[10:57] <jphilips> on support page
[10:57] <jphilips> 1. make a table for the epub and pdf documentation
[10:59] <jphilips> 2. add more padding above headings
[11:01] <jphilips> homepage shows 5 logos under 'technologies used', but about page shows only 3
[11:01] <jphilips> might be good to have an entire donate page
[11:02] <jphilips> social media links should be accessible on all the pages and not just in the community apge
[11:03] <jphilips> might be good to add the list of sponsors on the homepage under technologies used
[11:04] <jphilips> that's it for now i guess
[11:05] <jphilips> has michael prepared a new release video for this release?
[11:22] <RikMills> not yet. if he does so, no point until after beta I think
[11:37] <jphilips> when is beta coming out
[11:38] <jphilips> will there be that much changes after the feature freeze is up and the UI freeze happens in a few days?
[11:40] <RikMills> probably not much visibly, but circumstances can force things. beta is on the 2nd april
 https://twitter.com/killyourfm/status/1239179883965812742
[18:51] <keithzg[m]> @RikMills: Yeah I've been running KDE on my Gemini, and even with Debian oldstable and having to customize some things afterwards it was quite great; should get it installed on my Cosmo too now but there's never enough time in the day!
[20:28] <jphilips> RikMills: i've put all the suggestions in this google doc for you to easily go through - https://docs.google.com/document/d/1XWmKwa4k-04MsJaDQWM6lwMGlY5b7W9__lK7InwnX28/edit#
[21:56] <RikMills> jphilips: great. thanks
[21:57] <jphilips> added more stuff to it as well
 kool. hopefully we can gradually work through. the attention to detail is appreciated :)