[00:32] <tsimonq2> vorlon: ack, thanks.
[06:49] <mitya57> xnox: thanks to you :)
[10:20] <LocutusOfBorg> xnox, boxbackup merge/sync please? there is an openssl 1.1 build fix
[10:20] <LocutusOfBorg> also xonsh might be syncable now...
[10:22] <LocutusOfBorg> also meson and something more...
[10:32] <xnox> LocutusOfBorg:  can try these.
[11:00] <LocutusOfBorg> ta
[11:04] <xnox> LocutusOfBorg:  i beleive meson will require a merge, but can try doing force sync to see if it got better or not
[11:12] <LocutusOfBorg> xnox, yes that was my intention, prepare a merge and upload or not based on autopkgtests
[12:06] <odc> the launchpad.net certificate has expired :(
[12:06] <odc> or is it just me?
[12:06] <LocutusOfBorg> September 15, 2019
[12:07] <LocutusOfBorg> I would say just you
[12:07] <rikmills> bugs.launchpad.net has expired
[12:07] <LocutusOfBorg> that one is expired, indeed
[12:07] <odc> yes, it only happens on bugs.lp.net
[12:07] <odc> thought it was the same
[12:07] <rikmills> just been flagged to #canonical-sysadmin channel
[12:08] <LocutusOfBorg> notAfter=Jun 25 12:00:00 2019 GMT
[12:36] <LocutusOfBorg> x
[12:37] <LocutusOfBorg> sahid, hello, I fixed your python-ddt upload, otherwise cinder was not building at all
[12:37] <LocutusOfBorg> please be careful about your upstream tarballs next time :)
[12:37] <LocutusOfBorg> and sync from Debian if possible
[12:37] <LocutusOfBorg> mismatching tarballs are PITA to have
[12:38] <LocutusOfBorg> xnox, looks lie boxbackup needs help...
[12:59] <sahid> LocutusOfBorg: yes true i was actually working on it, how did you fixed it?
[12:59] <sahid> I can't see your change in ubuntu-server-dev
[12:59] <sahid> the problem is that debian.net does not provide doc with the tarball
[13:00] <sahid> and jamespage just proposed to me to use the one from debian experimental
[13:03] <jamespage> sahid, LocutusOfBorg: pkg-openstack in debian generally snapshot from git, so they don't use a sdist generated tarball
[13:04] <jamespage> hence why the version in experimental has the docs subfolder.
[13:09] <LocutusOfBorg> sahid, that one, syncing from experimental did the trick
[13:10] <LocutusOfBorg> I don't honestly care about how debian generated it :) it works
[13:10] <LocutusOfBorg> maybe bugging upstream about fixing their tarball is worth doing
[13:24] <sahid> LocutusOfBorg: in all cases thanks for your help on it :)
[13:38] <jamespage> LocutusOfBorg: yup - that was the next step (patch upstream to include docs folder in release sdist)
[13:40] <jamespage> ok so now for a broader eoan question - I know python2.7 is going to universe this cycle; do we have an objective to remove all of the python-* packages in archive?
[13:41] <jamespage> debian experimental seems to contain alot of pre-work towards that goal
[13:41] <jamespage> LocutusOfBorg: python-ddt being a case in point - the reverse-depends list of binary:python-ddt is quite long
[13:44] <jamespage> which is why we had not synced (yet)
[14:34] <LocutusOfBorg> jamespage, uploading a broken 1.2.1-0ubuntu1 makes no difference wrt syncing 1.2.1-1 from experimental... does it?
[14:51] <Eickmeyer> Working on some packaging and I'm having trouble getting some lintian-overrides to take. Any idea what I'm doing wrong? https://code.launchpad.net/~eeickmeyer/+git/raysession (I'm still learning)
[14:55] <vorlon> Eickmeyer: I see you've created debian/source/lintian-overrides.  I don't recall if this is a supported path (the path I'm used to is debian/source.lintian-overrides; debian/source/lintian-overrides may be supported nowadays but it looks jarring to me to include this in debian/source which is otherwise instructions to dpkg-source).  But the real problem is that the overrides you're declaring there
[14:55] <vorlon> are overrides for binary packages, not for the source
[14:55] <vorlon> Eickmeyer: you need a debian/$binary_package.lintian-overrides for the binary-level overrides
[14:56] <Eickmeyer> vorlon: Thanks, I'll give that a shot.
[14:57] <cjwatson> vorlon: It's the path that Lintian prefers and documents nowadays
[14:58] <cjwatson> There's a pedantic-severity tag for using debian/source.lintian-overrides
[14:58] <cjwatson> (Not disagreeing with you about debian/$binary_package.lintian-overrides)
[14:59] <Eickmeyer> cjwatson, vorlon: Yeah, that's what I read in the documentation.
[15:03] <vorlon> cjwatson: :)
[15:32] <tsimonq2> @pilot in
[15:33] <tsimonq2> https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040751.html
[15:37] <tsimonq2> Wimpress, popey: Would someone with more experience with snaps than I be able to confirm that this bugfix works? bug 1802483
[15:37] <tsimonq2> It's been in the sponsorship queue for a while.
[15:41] <Laney> That fix needs properly reviewing
[15:42] <tsimonq2> Laney: I agree.
[15:43] <tsimonq2> Bug 1770093 needs review from someone who works with Pi stuff more than I do; I have a Pi 3 and I'll circle back once I can get an SD card for it later this week, if needed.
[15:45] <tsimonq2> sil2100: Poke on reviewing bug 1814118 when you get the chance.
[15:48] <tsimonq2> bluesabre: I'm looking at bug 1822380 and I wanted to get your feedback as to what's left here. I don't see any other debdiff specifically that needs sponsoring, so I'll unsubscribe sponsors, but it does seem there's a GTK bug here.
[15:50] <tsimonq2> Hmm, it looks like the upstream GTK issue isn't getting much traction. https://gitlab.gnome.org/GNOME/gtk/issues/1843
[15:50] <tsimonq2> I'm willing to bet a Git bisect will reveal the issue. I'll circle back later this week when I look at Pi stuff.
[15:52] <tsimonq2> Well, I do see a random patch from an obscure forum post. What could go wrong? :P
[16:10] <tsimonq2> jamespage: Would you (or someone else with knowledge of the swift package) be able to take a look at bug 1827340? It's been in the sponsorship queue for a bit.
[16:18] <tsimonq2> juliank: Debian bug 927876 's Ubuntu counterpart, bug 1766068, has been in the sponsorship queue for a bit. Would you be able to review the patch when you can?
[16:22] <tsimonq2> cyphermox: Did you plan on driving the SRU for bug 1828948 as well?
[16:31] <cyphermox> tsimonq2: yes
[16:32] <tsimonq2> cyphermox: Sounds good, thanks.
[16:34] <Eickmeyer> vorlon: RE: lintian-overrides, that did not work. lintian is still throwing invalid errors on the binary.
[16:35] <vorlon> Eickmeyer: I don't believe ' binary' is part of the expected content of the override
[16:35] <vorlon> i.e. it should be $bin_pkg_name: $lintian_tag_name $other_info
[16:36] <Eickmeyer> vorlon: Thanks for the hint, will make the change.
[16:46] <Eickmeyer> vorlon: That didn't work. Does it need "#/usr/bin/python3" appended?
[16:50] <Eickmeyer> rather, #!/usr/bin/python3
[16:51] <tsimonq2> @pilot out
[16:52] <tsimonq2> https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040752.html
[16:56] <Eickmeyer> tsimonq2: I (very quickly) provided the links you requested.
[17:44] <tsimonq2> Eickmeyer: Thanks.
[17:46] <Eickmeyer> vorlon: Answered my own question. It needed the #! line too. Thanks!
[17:50] <sarnold> is that the lintian thing?
[17:50] <Eickmeyer> sarnold: Yep. You can look for yourself at what it needed.
[17:50] <Eickmeyer> If you want...
[17:50] <sarnold> woot
[17:51] <Eickmeyer> \o/
[18:41] <bdmurray> ahasenack: We, the foundations team, would close bug 1810780 but it is assigned to you. Are you still planning on doing any work there?
[18:41] <ahasenack> oh, ow
[18:41] <ahasenack> let me check
[18:42] <ahasenack> bdmurray: it can be closed. My mp was rejected because debian fixed in while it was in review, so no changes needed.
[18:42] <ahasenack> bdmurray: is cosmic still affected, though?
[18:43] <ahasenack> my mp was for disco
[18:43] <bdmurray> ahasenack: It could be but end of life for cosmic is near
[18:44] <ahasenack> I see. Well, I'm not working on that, and if this package needs an sru for another reason, the ftbfs fix is simple enough
[18:44] <ahasenack> I think this is fix released for disco, and a cosmic task may or may not be added
[18:46] <ahasenack> adjusted
[19:31] <juliank> tsimonq2: Sure, but note that Ubuntu is upstream, Debian is downstream
[19:31] <juliank> Debian tracks the latest LTS version of c-n-f, and software-properties
[19:32] <juliank> I'll be tracking stuff more aggressively post buster I think, as this improves quality for everyone
[20:10] <bdmurray> ahasenack: Thanks!


[14:14] <cnf> hello
[14:14] <cnf> i'm trying to get 3 finger swiping to work
[18:12] <TuTornillo> hi there!
[18:13] <TuTornillo> can anyone help me?
[18:25] <Pichy> hi, I have an issue with my touchscreen, it gets loaded as mouse
[18:26] <Pichy> at /proc/bus/input/devices I can see it makes a mouse0 event
[18:26] <Pichy> and I'm not able to get it to work as touch with xorg.conf
[18:47] <Pichy> anyone alive here?


[10:20] <madigens> Anybody here with the power to update the freetype package to 2.6.3 for xenial? https://bugs.launchpad.net/ubuntu/+source/freetype/+bug/1521299
[10:20] <madigens> 2.6.1 may contain security issues.
[11:19] <ksamak> hi all
[11:19] <ksamak> i guess no-one's working today, but i'll ask anyway
[11:19] <ksamak> it's about compiz
[11:20] <ksamak> say a plugin wanted to inquire about the value of... say the current zoom, in ezoom. would that be hard to impl?
[11:21] <ksamak> cause with the zoom changes i made, it break the centering of mouse in showmouse plugin
[11:21] <ksamak> Trevinho: btw, still haven't found that <IP_ADDRESS>.tar.gz ;-)
[11:22] <ksamak> also, we might wanna talk about the changes i'm proposing, when i upload the patch (soon)
[14:24] <tushar> hello friends , can anyone suggest me version which best support on thinkpad p50 ?
[14:25] <tushar> i installed 14.04 which was not supporting wifi and lan card and sound drivers
[15:42] <binary01>  hi all, i am having trouble booting into my desktop. At first after i try to login it would just return to login screen. i read that i may be a problem with lightdm and to try gdm instead. i installed gdm and now i get a black screen on boot. does anyone know how to fix this?
[15:45] <flocculant> binary01: this isn't a support channel - and is extremely quiet at the weekend - try #ubuntu :)


[07:48] <ziroday> @time Singapore
[11:56] <dholbach> hi elmo
[11:57] <dholbach> I pinged mako, sabdfl won't make it
[11:57] <dholbach> Technoviking: are you up already? :-)
[11:57] <dholbach> Burgundavia is not around yet
[11:57] <dholbach> and mdke won't be able to attend, he's at work
[11:58] <dholbach> only item on https://wiki.ubuntu.com/CommunityCouncilAgenda is: 'Is there a need to coin a new phrase for an "Ubuntero"? discussion'
[12:00] <dholbach> there's a few suggestions on bug 272826 already
[12:01] <dholbach> if we can't reach quorum, I'd be happy to chase up everybody and come to a conclusion on the bug itself
[12:01] <dholbach> elmo: WDYT?
[12:01] <elmo> sorry, just finishing up another meeting
[12:01] <dholbach> let's wait a few then, np
[12:02] <elmo> dholbach: since we're clearly not quorum, I think chasing it out of band is probably a good idea
[12:02] <elmo> (unless anyone here has anything to contribute right now)
[12:02] <dholbach> I personally wouldn't mind getting the input of all CC members on this one instead of just the input of the few who could make it
[12:03] <james_w> I have a question about something that I may raise at a later point, if you'll allow me.
[12:03] <dholbach> james_w: sure, go ahead
[12:03] <james_w> If we are unhappy with the behaviour of someone on launchpad, would that be a matter for the CC, or the LP admins?
[12:04] <dholbach> james_w: did somebody try talking to that person already? was there any of the team councils involved in discussions already?
[12:05] <dholbach> generally, I'd prefer if we can reach out and talk to people before LP admins start deactivating accounts or something
[12:05] <james_w> I haven't asked around much yet, I'm not sure that there is an appropriate team council, hence asking the CC
[12:05] <james_w> oh yeah, it was more a question of whether the CC would just direct me straight to the LP admins to discuss it with them.
[12:05] <dholbach> james_w: could you mail some details to the CC list about it?
[12:06] <james_w> sure, it's a private list?
[12:06] <dholbach> yes
[12:06] <james_w> cool
[12:06] <dholbach><EMAIL_ADDRESS>[12:06] <dholbach> thanks a lot james_w
[12:07] <james_w> It's not got to stay private if I pursue it, but I don't want to risk tarnishing the person's name at this point
[12:07] <dholbach> as I said, I'd be happier if we start reaching out first
[12:07] <dholbach> OK, let's adjourn the meeting - I'll chase up everybody to express their opinions on the bug report itself
[12:08] <dholbach> thanks elmo
[12:08] <james_w> thanks dholbach
[12:08] <Rafik> dholbach, if you have time, i'd like to have some advices from you
[12:08] <dholbach> Rafik: is this something you want the Community Council to think about or is this unrelated to the CC?
[12:09] <Rafik> this is also a question i'd like to ask :)
[12:09] <Rafik> i'm writing, in private
[12:09] <dholbach> ok, ask your question :)
[12:09] <dholbach> ah ok
[12:09] <dholbach> thanks
[12:09] <Rafik> thank you
[12:10]  * dholbach will update the CC's TeamReport
[12:10] <dholbach> Adjourned.
[12:10] <dholbach> see you around :)
[13:04] <lifeless> dholbach: lp admins don't like disabling accounts either
[13:04] <lifeless> dholbach: FWIW :)
[13:04] <dholbach> lifeless: I know
[14:53] <davidbarth> elmo: ping?
[14:59] <mdz> #startmeeting
[14:59] <MootBot> Meeting started at 08:59. The chair is mdz.
[14:59] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[14:59] <mdz> Keybuk: ping
[15:00] <Keybuk> mdz: here, on the phone
[15:01] <mdz> Keybuk: ETA?
[15:01] <mdz> sabdfl will not be attending the meeting, so it is just us
[15:03] <mdz> [LINK] https://wiki.ubuntu.com/TechnicalBoardAgenda
[15:03] <MootBot> LINK received:  https://wiki.ubuntu.com/TechnicalBoardAgenda
[15:04] <mdz> [TOPIC] Upload rights for pre-MOTUs
[15:04] <MootBot> New Topic:  Upload rights for pre-MOTUs
[15:04] <mdz> recently, we've started to explore the possibility of granting upload privileges at a fine-grained (package) level
[15:04] <mdz> for example, allowing a MOTU to upload certain packages to main in advance of becoming a core developer
[15:05] <mdz> this has been broadly well received, and while there is some work to be done on policy and documentation, it is reasonably straightforward to offer this
[15:06] <mdz> perhaps as a result of this, we've also now started to receive inquiries about upload privileges from people who are not Ubuntu developers at all (but may be Debian developers), who want to be able to upload certain packages
[15:06] <mdz> this is not at all as straightforward
[15:07] <mdz> MOTUs can be reasonably expected to have a good working knowledge of the Ubuntu project, its policies and procedures, as validated by the MOTU council
[15:07] <mdz> fine-grained upload privileges for packages in main are a natural extension of t his
[15:08] <mdz> however, for someone who is new to the Ubuntu project, we have no assurance of this
[15:09] <mdz> the consensus in the tech board was that, since these amount to requests to fast-track or bypass the existing process, we needed to discuss this with the MOTU council in order to take a view
[15:10] <james_w> why is sponsorship not an option in these cases? It ensures there is someone who is familiar with the project looking at each upload.
[15:10] <mdz> I haven't received feedback from the MOTU council on this yet, but have asked to schedule a meeting with representation from both the technical board and the MOTU council
[15:10] <mdz> james_w: I think it absolutely is an option, but it is not what has been requested of us
[15:11] <persia> MOTU Council has been discussing this, but has not yet reached consensus.
[15:11] <james_w> yes, sorry, why do these people feel that sponsorship is not sufficient for them? Do you know?
[15:11] <mdz> it's possible that there is a communication gap, and that the requestors are not aware of all of the options; I haven't investigated that thoroughly
[15:12] <mdz> we are (I am) a bit backlogged lately on TB issues and have been slow to process this
[15:12] <persia> james_w, It's to cover the case where someone routinely does *all* the uploads of only one or two packages.  A historical example would be Yokozar, who eventually became MOTU, but only after much discussion.
[15:13] <mdz> I think there's no question that we want to find ways for people in this situation, who want to contribute, to do so
[15:13] <mdz> these are, based on the examples I've seen, people who have demonstrated competency in packaging (e.g. in Debian) and are interested in similar work in Ubuntu
[15:14] <mdz> it may be that, simply because they are accustomed to working in a per-package manner in Debian, they come to Ubuntu looking for a similar arrangement
[15:14] <mdz> whereas we more easily accommodate developers who are interested in contributing to the system as a whole
[15:14] <persia> From what loose consensus is present in MC, I can say that we view it typically as an exception, with sponsoring being more common.  We don't want to encourage an adoption of general per-package maintenance.
[15:15] <mdz> such people may be put off by our descriptions of what a MOTU or core-dev does, because it is broader than their interests
[15:15] <james_w> I can understand not wanting to go through the MOTU application process and all the work that that involves if they only have an interest in one package
[15:16] <mdz> persia: why not? (I'm not necessarily disagreeing, but am interested in the rationale)
[15:16] <james_w> but if we are going to let them upload that package without supervision then why not just have a sponsor do cursory checks, that the package is appropriate for the point in the release cycle, etc?
[15:17] <persia> mdz, I can't speak for the council for rationale, but personally, I believe it is a perception of value of a team approach, and wanting to continue to avoid the concept of maintainer-lock.
[15:17] <james_w> In the case of Roman, he was sponsored by siretart, who made the request for the upload rights, so was the sponsorship requirement slowing things down?
[15:17] <mdz> james_w: perhaps the sponsorship process can be a bit cumbersome compared to directly uploading (filing bugs, attaching patches, etc.)
[15:17] <mdz> james_w: if only we just had everything in revision control so it could be easily reviewed and merged...;-)
[15:18] <james_w> if only... :-)
[15:18] <mdz> persia: I think avoiding maintainer-lock continues to be desirable and healthy, but does it actually conflict with what these developers want?
[15:19] <mdz> persia: is there an indication that they would expect to have an exclusive lock on that package?
[15:19] <james_w> I think not, as long as it is clear to them that they don't.
[15:20] <persia> mdz, The concept of exclusive lock has been discussed previously by regular serial uploaders, but I have not heard of any expectation for either the current candidates or the historical cases.
[15:20] <mdz> we should certainly try to avoid clashing of uploads etc., but that seems orthogonal to whether someone happens to work on one package or many
[15:20] <persia> Again, I'm sharing some portions of a pre-consensus state, so it's certainly not complete.
[15:20] <persia> Certainly.  As much as anything it's about documenting the right properly.
[15:20] <mdz> after all, we could easily have the same problem with two MOTUs, for example, and it may have even happened before
[15:20] <dholbach> I personally think it's fine that people will upload one package or packages of a certain genre, but when they apply for the 3rd or 4th time (for another package or another set), they probably have enough experience to join MOTU instead
[15:21] <persia> Or if not, something else probably went wrong.
[15:21] <mdz> if I ask the question: would Ubuntu be better off with these uploads than without them? the answer seems clearly to be yes
[15:22] <mdz> but there are valid concerns about the process
[15:22] <persia> Except in rare cases, "Yes" is the likely answer.
[15:22] <mdz> as dholbach points out, we do want to encourage and enable people to make a broader contribution if their interests expand
[15:22] <james_w> in the first case I understand why the person isn't pursuing rights to upload these packages to Debian, but can't we encourage most people to contribute their work on single packages to Debian through the DM scheme?
[15:22] <Keybuk> for me, the question is more: if we allow someone access to upload one package in universe, why wouldn't we allow them access to upload any?
[15:22] <mdz> however, if they've been uploading on their own, they won't have received any feedback, and how will we evaluate whether they should be accepted into MOTU?
[15:23] <persia> james_w, Some packages need to have persisting variance.  A common solution to embed this in the source in a sync-compatible way is yet to be well advertised.
[15:23] <mdz> sponsorship is not just about enabling contributions; it's what gives us insight into the quality of someone's work
[15:23] <dholbach> Keybuk: from a process point of view they will have a harder time to demonstrate their technical ability when they just worked on one package
[15:24] <persia> Especially for a package with a particularly well behaved upstream.
[15:24] <james_w> persia: ok, but to me that just makes the cases where this would be appropriate be even more exceptional.
[15:24] <Keybuk> how do they demonstrate their technical ability to work on that package in the first palce?
[15:24] <mdz> it's interesting that the requests are coming from Debian developers.  in some sense, they could just request syncs rather than upload
[15:24] <persia> james_w, Correct.
[15:24] <Keybuk> mdz: I wonder how much of this is the need for a sense of ownership
[15:24] <Keybuk> and maintainer lock
[15:24] <mdz> Keybuk: I do as well
[15:24] <mdz> perhaps what we need to do is talk to them about what they're really after
[15:25] <dholbach> Keybuk: in cases of people who just care for one or two packages (let's call them "upstream MOTUs"), I'm more intersted how much they really maintain (in the true sense of the word) the package: work on bugs, work on forwarding them upstream talking to upstream, etc.
[15:25] <mdz> I took the requests at face value at first, but the discussion is leading me to want to dig deeper
[15:25] <dholbach> Keybuk: if the end result is that they upload simply new upstream versions with less bugs, I'm happy :)
[15:25] <Keybuk> dholbach: why can't we do that within the bounds of the existing sponsorship process
[15:25] <Keybuk> and use that as proof of their technical ability to become a full MOTU?
[15:26] <mdz> Keybuk: because, as dholbach points out, their work on a single package might not provide enough information for the MC's selection process
[15:26] <dholbach> Keybuk: we have done that before (YokoZar is a good example) - it turned out to take longer to demonstrate experience with packaging, etc.
[15:26] <mdz> Keybuk: someone who just serially uploads new upstream versions wouldn't really demonstrate much ability
[15:27] <persia> YokoZar is the perfect example of the sort that we want to use such a mechanism.  For Debian developers, it's a little more confusing why they would want it.
[15:27] <Keybuk> someone who just serially uploads new upstream versions, to my mind, requires sponsorship to ensure they're following our procedures and policies
[15:27] <Keybuk> they're unlikely to be reading our mailing lists, learning about our changes and habits
[15:27] <Q-FUNK> ?
[15:28] <mdz> Q-FUNK: thanks for joining us
[15:28] <ScottK> persia: I think Yokozar is more an example of people thinking it wasn't possible to be MOTU based on experience with a single package.
[15:28] <persia> Keybuk, That's one of the reasons why many uploads to a small number of packages has historically not been a good path to MOTUship.
[15:29] <persia> ScottK, Yes, but it would have been nice to let him upload wine a year or so before he became MOTU.
[15:29] <Q-FUNK> mdz: I was just pointed to the agenda.  let's continue.
[15:29] <mdz> Q-FUNK: it would help us discuss the issues if you could tell us about your reasons for wanting upload rights to Ubuntu: what do you want to do in Ubuntu?
[15:30] <ScottK> persia: My vote would have been to make him MOTU the first time he applied, but we're wondering off the topic I guess.
[15:30] <Q-FUNK> mdz: understood.  it mainly is that SRU for packages I maintain, especially the Geode X driver and dictionaries, keep on lagging behind when it coes to uploading fixes.
[15:30] <Q-FUNK> so far, SRU diffs tend to be approved quickly, bjut there's always ubuntu+1 to prepare, which means that Hardy work lags behind.
[15:31] <mdz> Q-FUNK: that's interesting and unexpected
[15:31] <mdz> Q-FUNK: so you actually don't plan to work on the current development branch at all, you only want to upload SRUs?
[15:31] <Q-FUNK> it would thus be simpler if I could upload approved SRU directly, rather than wait for X and language pack teams to find a minute away from ubuntu+1 and upload for me.
[15:32] <Q-FUNK> mdz: I might get involved on the development branches too, whenever appropriate.
[15:32] <Q-FUNK> my main concern is with how too many SRU remain unuploaded for too long and how it prevent hardware support issues from being adressed in a timely manner.
[15:34] <mdz> Q-FUNK: ok, that's a very different issue then, and one which wouldn't be very well addressed by an upload ACL
[15:34] <Q-FUNK> my secondary concern is with things like http://packages.qa.debian.org/r/rus-ispell/news/20081002T091712Z.html requiring swift actions on development branches too.
[15:35] <mdz> Q-FUNK: if SRUs take too long, then an ACL would only solve that problem for you, not for anyone else
[15:35] <Q-FUNK> for the above debia bug (also affects intrepid), dholbach already replied that the required build-dep wasn't in intrepid yet for this to be fixed.
[15:35] <mdz> if those contributions aren't being reviewed and sponsored effectively, I would rather fix that underlying problem than try to work around it
[15:36] <Q-FUNK> mdz: that would also work.  agreed.  personally, I see that X and kernel driver issues for LTS releases often remain unanswered for too long, or receive generic "try our latest and greates upcoming release" boilerplate replies which solve nothing.
[15:36] <mdz> it's true that a great majority of our work is focused on the upcoming release rather than maintenance of stable releases
[15:37] <mdz> I don't think there's a good focal point for that work either, such as a stable maintenance team
[15:37] <Q-FUNK> one thing that I would like to see is a team that is dedicated to LTS release issues, such as SRU and unanswered kernel driver bugs.  if I can contribute anythingto that by taking the lead, I'd love to.
[15:37] <Q-FUNK> sync :)
[15:38] <mdz> I think it would be a good idea to bring together developers who are particularly interested in LTS maintenance
[15:38] <Q-FUNK> that's an issue I already mentioned to mpitt and hemo at IDS Intrepid in Prague. LTS needs its own dedicated team.
[15:39] <mdz> dholbach: what do you think about that?
[15:39] <dholbach> mdz: I think it makes perfect sense
[15:39] <Q-FUNK> not directly related and more of a btw than anything else:
[15:39] <Q-FUNK> rushing gvfs into Hardy, when it's meant as an LTS release and gvfs was still uncooked, also relates to the sort of separate agenda I think would matter for LTS releases.
[15:40] <persia> I'd also rather see more focus generally on stable updates than using ACLs to work around the issue.
[15:40] <dholbach> we have lots of people who start doing development and think about "how do I fix <bug X> in <old release>?", people who triage those bugs, etc
[15:40] <mdz> Q-FUNK: let's take one thing at a time and try to stay on topic
[15:40] <Q-FUNK> any way I can be made to start or launch an LTS maintenance team, with guidance from existing core-dev, then?
[15:40] <mdz> we have several more agenda items we need to cover
[15:40] <Q-FUNK> öö.. start or join
[15:41] <Q-FUNK> ok
[15:41] <mdz> dholbach: would you be able to spend some time helping to set up such a team and gather people interested in stable maintenance?
[15:41] <Q-FUNK> can we put the issue of a separate LTS team for the next meeting, then?
[15:41] <dholbach> mdz: I'll get working on that
[15:42] <mdz> Q-FUNK: you can work with dholbach on that, I think it's a fine idea.  The question of what goes into an LTS release is a separate one, though, and can't be dealt with by a single team as it affects everyone
[15:42] <Q-FUNK> dholbach: please keep me in the loop by e-mail.  I do debian/ubuntu work in my spare time and don't follow the mailing lists. :)
[15:42] <mdz> dholbach: ok, thank you
[15:42] <dholbach> Q-FUNK: will do
[15:42]  * dholbach hugs mdz
[15:42] <Q-FUNK> cheers! :)
[15:42] <mdz> [ACTION] dholbach to work on setting up a stable maintenance team and gathering interested developers
[15:42] <MootBot> ACTION received:  dholbach to work on setting up a stable maintenance team and gathering interested developers
[15:42]  * Q-FUNK hugs dholbach
[15:42]  * dholbach hugs Q-FUNK back
[15:43] <mdz> siretart: are you here?
[15:43] <ogra> mdz, skipped stgraber ?
[15:43] <mdz> I'm curious about the circumstances of the emacs-snapshot case as well
[15:43] <mdz> ogra: I haven't skipped anything, we are on the very first agenda item
[15:43] <mdz> ogra: and 45 minutes into the meeting
[15:43] <ogra> oh, i thought that was done :)
[15:44] <ogra> (with aboves action)
[15:44] <mdz> ogra: siretart requested a similar arrangement for emacs-snapshot for Romain Francoise
[15:44] <ogra> ah
[15:44] <ogra> sorry ...
[15:44] <mdz> in that case, the rationale was also to avoid sponsorship delays
[15:44]  * ogra crawls back into corner keeping quiet
[15:44] <mdz> "Granting him upload access to ubuntu for this package would eliminate sync delays to intrepid"
[15:44] <mdz> dholbach: could you try to find out the cause of the delays and whether there is a better way around this?
[15:45] <mdz> we need to move on, I'll respond to Reinhard by email
[15:46] <mdz> [ACTION] mdz to follow up on Reinhard Tartler's request for emacs-snapshot upload ACL for Romain Francoise
[15:46] <MootBot> ACTION received:  mdz to follow up on Reinhard Tartler's request for emacs-snapshot upload ACL for Romain Francoise
[15:46] <dholbach> mdz: I'll do that
[15:46] <mdz> [TOPIC] Limited main upload rights for Stephane Graber
[15:46] <MootBot> New Topic:  Limited main upload rights for Stephane Graber
[15:46]  * ogra crawls back out of the corner :)
[15:46] <mdz> [LINK] https://edge.launchpad.net/~stgraber
[15:46] <MootBot> LINK received:  https://edge.launchpad.net/~stgraber
[15:47] <mdz> the list of packages is italc, ltsp, ltspfs, ldm
[15:47] <ogra> stgraber would like to take over ltsp maintenance from me, he now works full time for a company on ltsp so can demote more time to it than i even can remotely
[15:48] <ogra> i think the recent intrepid uploads alone i sponsored for him prove the quality of his packaging skill (all went in untouched by me) and his interest
[15:48] <mdz> ogra: I thought stgraber was already a MOTU
[15:48] <stgraber> nope
[15:49] <stgraber> I only have one of my package in Universe and this one is now in Debian so I never had the need to upload something in Universe for a release or so
[15:49] <mdz> ogra: have you considered recommending him for MOTU?
[15:49] <ogra> i sponsor his uploads since a year or so regulary
[15:49] <stgraber> (and so never felt the need of asking for MOTU as I don't think someone uploading only a single package should get MOTU membership)
[15:50] <stgraber> (a single package in Universe that's)
[15:50] <ScottK> Based on recent feedback for other candidates, I think it likely he'd get rejected for exactly that reason.
[15:50] <ogra> the main interest was to get him upload rights for ltsp and friends far *before* RC which sadly didnt happen yet, but ltsp really suffers from me having not enouch time for it
[15:50] <mdz> hmm, I thought we'd avoid another lengthy topic, but it sounds like perhaps not
[15:51] <stgraber> ScottK: yeah, why I never asked :) I work for a company doing LTSP and educational stuff so my interest is in LTSP, iTalc and educational packages and all of these are in Main, not Universe
[15:51] <ogra> i wil have even less time for ltsp in jaunty by the looks of it, since ubuntu-mobile suddely gains lots of community attention
[15:51] <mdz> I think that scope of packaging work is not a good reason to reject someone for MOTU
[15:51] <Keybuk> knee-jerk reaction: I'd prefer not to short-cut someone straight into main, bypassing universe, and only with an ACL for a couple of packages
[15:51] <mdz> in and of itself
[15:51] <Q-FUNK> sounds like the problem I encountered a couple of years back.  working on packages that are mostly in main, but only on these packages and not on ubuntu as a whole.
[15:51] <ScottK> mdz: I agree, but that's what MC has been doing.
[15:51] <Keybuk> again, the reasons for having MOTU are not just technical, but a matter of community and practice as well
[15:52] <ogra> on a sidenote i'd like to point out that sabdfl gave a +1 by mail on the initial request sent to the TB ... though there wasnt the above discussion back then
[15:52] <mdz> if a developer does good quality work, and understands Ubuntu development practices well enough to be granted unsupervised upload rights, why should they not be MOTUs?
[15:53] <ogra> mdz, is tkamppeter MOTU ?
[15:53] <persia> Not any more.
[15:53]  * ogra wasnt aware
[15:53] <mdz> ogra: yes
[15:53] <persia> still?
[15:53] <mdz> Joined on 2007-12-12
[15:53] <Keybuk> persia: he is still a member of that team
[15:54] <mdz> persia: he was temporarily core-dev with a limited mandate for certain packages, and that was migrated to an ACL
[15:54] <persia> Why was that not changed when he was removed from core-dev?  Does that require separate action?
[15:55] <persia> Alternately, is there a reason that the TB believes he shoud be MOTU?
[15:55] <mdz> persia: till was approved as a MOTU ages ago, there is no reason to question that
[15:56] <persia> Well, I questioned it then, but I'll quiesce about it again.
[15:56] <mdz> persia: he was accepted as a MOTU ages before the ACL change
[15:56] <Keybuk> persia: I'm confused
[15:56] <mdz> persia: the MOTU council recommended him for core-dev in fact, but the TB elected to go with a more limited grant
[15:56] <Keybuk> are you questioning his right to be a MOTU?
[15:57] <Keybuk> are you questioning his conduct as a MOTU?
[15:57] <Keybuk> or are you suggesting that anyone granted core-dev should lose their MOTU membership?
[15:57] <mdz> this is completely off-topic I'm afraid
[15:57] <ogra> yes
[15:57] <persia> I'm not formally questioning his conduct.  It's off topic.
[15:57] <mdz> to come back to stgraber, I feel that the right thing to do is to support him in joining MOTU
[15:57] <ogra> and doesnt solve the prob that the massively regressed quality of ltsp in hardy got is a very bad community reputation which s the main point of my request
[15:57] <persia> Forgetting the specifics, the question is really: is "MOTU" a wide group of developers, some of whom never upload to universe, or the set of people who upload to universe, who participate as part of the development team?
[15:58] <persia> Essentially, while stgraber could apply for MOTU, if he's only working on main packages, the definition of MOTU in the eyes of the TB is important if the TB is expecting MOTUship prior to his grant.
[15:58] <ogra> there is a person who is willing to take care, has the skills and provides good quality packaging for it which is would like to be able to upload on his own
[15:58] <mdz> persia: it is both (hence the implicit membership core-dev has in MOTU)
[15:58] <ogra> *which is why
[15:59]  * mathiaz waves
[15:59] <kirkland> o/^
[15:59] <Keybuk> mdz: more accurately, ubuntu-core-dev and motu are both members of the ubuntu-dev team
[15:59] <ogra> the quality of intrepid is far beyond the one in hardy only because of stgraber
[15:59] <Keybuk> ogra: and that is to be commended
[16:00] <ogra> and my time is more and more limited to mobile tasks
[16:00] <mdz> stgraber has positive feedback from his sponsor, has demonstrated commitment to the project...why shouldn't he be considered?
[16:00] <Keybuk> and it sounds that both mdz and I would support his application to MOTU
[16:00] <ogra> which ends up in sponsored uploads being delayed etc
[16:00] <Keybuk> and would be surprised if the MC did not
[16:00] <persia> Keybuk, Which makes me wonder about requiring (or expecting) MOTU for those who don't touch universe.
[16:00]  * kirkland finds this conversation very familiar
[16:00] <Keybuk> persia: MOTU is also a training ground
[16:00] <mdz> well, I can't take a stance first-hand on his application, I'm only comparing superficially to other applications I've seen approved by the MOTU Council
[16:01] <Q-FUNK> mdz: if I may pop my head out for a second, I face a similar issue. I focus on maintaining specific packages, most of which are in main, thus why MOTU would be a nice test of community spirit, it does not come with the right upload rights to focus on packages in main.
[16:01] <Keybuk> Q-FUNK: that is deliberate
[16:01] <Q-FUNK> öö.. s/why/while
[16:02] <persia> Keybuk, I understand, but it's about the shape of the graph.  Ubuntu-dev = <MOTU> + <core-dev> is different than <MOTU> = <non-core> + <core>
[16:02] <nijaba> o/
[16:02] <mdz> persia: I suppose it depends on whether you see it as a responsibility or a privilege
[16:02] <ogra> well, it depends how the motu council sees it :)
[16:02] <Keybuk> persia: I don't see that there's any difference
[16:02] <ogra> imho you are expected to at least help with merges and syncs at the beginning of a cycle if you are motu
[16:03] <Q-FUNK> Keybuk: right, except that getting MOTU status gives me rights to upload to somewhere my packages don't belong, which is useless to me.  heck, as a direct result, I cannot prove my deeds by starting in universe so, by default, never get to ACL or core-dev to take care of my packages in main.
[16:03] <persia> mdz, Yes.  I'm personally flexible either way, but I think either it should be explicit that MOTU is not necessarily related to universe, or there should not be an expectation of MOTUship for those applying for limited upload to main.
[16:03] <stgraber> well, I actually never thought I should apply for MOTUship because I'm not touching any package in Universe anymore, so getting Universe upload right wouldn't make any difference, I would just wait some months and ask again for main upload rights
[16:03] <ogra> which means that there are responsibilities coming with the privilege
[16:03] <sommer> hey all
[16:03] <mdz> persia: I think the "developer" aspect of MOTU is (should be?) much more important than the "universe" aspect
[16:03] <Keybuk> mdz: you named it ;)
[16:03] <dendrobates> The server team community meeting should have started 3 min. ago, can this discussion be moved to another channel?
[16:04] <ogra> but there is a community requirement going hand in hand
[16:04] <Q-FUNK> is work in main less of a community effort?
[16:04] <ogra> .oO(wasnt the TB booked for 2h ?)
[16:04] <mdz> ogra: once upon a time it was
[16:04] <ogra> ah
[16:05] <mdz> ogra: mathiaz asked me if I saw a conflict between TB and the server team meeting at this time, and I said no
[16:05] <ogra> we have to many teams if it gets tight in -meeting :)
[16:05] <mdz> because we'd been finishing on time for quite a while
[16:05] <persia> mdz, OK.  I just wonder if upload access to universe is useful for those that do not intend to use it.  I'm happy focusing on development and ignoring universe.  Thanks for the clarification.
[16:05] <mdz> it looks like I was wrong
[16:05] <Keybuk> persia: you're not looking at the motu team in the same way we do
[16:05] <Q-FUNK> persia: same here.
[16:05] <mdz> persia: I think we need to take this to email and involve a lot more people
[16:06] <persia> Keybuk, Right, which is why I sought clarification.
[16:06] <mdz> persia: I'd prefer to ask the question of MOTUs what the team means to them than to have the TB issue some official decree
[16:06] <Keybuk> persia: for us, grant of the privilege to upload to "main" - the set of packages installed by default on many people's machines and their related packages, is a privilege earned by demonstrating good work in the rest of the archive
[16:07] <mdz> [ACTION] mdz to start a discussion thread on the role of the MOTU team in the project and implications for new developers joining
[16:07] <MootBot> ACTION received:  mdz to start a discussion thread on the role of the MOTU team in the project and implications for new developers joining
[16:07] <persia> Keybuk, That makes sense to me.  It doesn't make sense for the cases of Till or stgraber, where that isn't expected to happen.
[16:07] <mdz> dendrobates: I will finish up here very shortly
[16:07] <persia> Email is probably better.
[16:07] <mdz> [TOPIC] Approach to ffmpeg in ubuntu, cf. siretart's email to technical-board@
[16:07] <MootBot> New Topic:  Approach to ffmpeg in ubuntu, cf. siretart's email to technical-board@
[16:07] <Keybuk> persia: Till was a MOTU before he was granted limited core-dev
[16:08] <persia> It was never exercised.
[16:08] <mdz> siretart has asked the technical board for a policy statement regarding codecs in ffmpeg in Ubuntu
[16:08] <Q-FUNK> Keybuk: this mostly makes sense, except that the packages I work on are those I already maintian at Debian and they already are in main.  what to do, then?
[16:08] <ogra> persia, it has to have been exercised if he became a MOTU
[16:08] <Keybuk> Q-FUNK: how would you maintain them differently in Ubuntu than you do in Debian?
[16:08] <ogra> persia, how else would he have become motu ;)
[16:08] <mdz> unsurprisingly, the TB are not legal experts or familiar with the alleged intellectual property claims
[16:08] <mdz> Keybuk: please, let's take it to email and free up the channel for the server team
[16:09] <mdz> so I've sought advice from Canonical's legal counsel and will respond when I have more information
[16:09] <Q-FUNK> Keybuk: similar methods, but more community-oriented in Ubuntu - since there's no package ownership per se in Ubuntu.
[16:09] <mdz> [TOPIC] cdrtools update
[16:09] <MootBot> New Topic:  cdrtools update
[16:09] <mdz> we seem to be very close to a cdrtools package which has Eben Moglen's blessing
[16:09] <ogra> wow
[16:09] <mdz> we're just waiting for a few final clarifications from Eben and from Joerg
[16:10] <Keybuk> mdz: which worries me ;)
[16:10] <Keybuk> I'm not sure which immovable force has been moved
[16:10] <mdz> assuming the two of them can be satisfied with the same text, we will be able to go ahead
[16:11] <mdz> Keybuk: I can tell you about that later
[16:11] <mdz> [TOPIC] AOB
[16:11] <MootBot> New Topic:  AOB
[16:12] <mdz> any urgent business before we turn over to dendrobates?
[16:12] <mdz> ok, thanks all
[16:12] <mdz> #endmeeting
[16:12] <MootBot> Meeting finished at 10:12.
[16:12] <mdz> dendrobates: apologies for running over
[16:12]  * nealmcb figures AOB is Any Other Business :)
[16:12] <zul> hello
[16:12] <mathiaz> mdz: np
[16:13] <mathiaz> let's get the server team meeting started
[16:13] <mathiaz> #startmeeting
[16:13] <MootBot> Meeting started at 10:13. The chair is mathiaz.
[16:13] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:13] <nealmcb> o/
[16:13] <nijaba> o/
[16:13] <Koon> \o
[16:13] <mathiaz> Today's exceptional agenda: https://wiki.ubuntu.com/ServerTeam/Meeting
[16:14] <mathiaz> Last week minutes: https://wiki.ubuntu.com/MeetingLogs/Server/20081014
[16:14] <mathiaz> [TOPIC] python-vm-builder
[16:14] <MootBot> New Topic:  python-vm-builder
[16:14] <mathiaz> So I've started to look at python-vm-builder.
[16:14] <mathiaz> And did a lot of testing.
[16:14] <mathiaz> Things are in good shape. The last bit I'm testing is the ec2 plugin.
[16:15] <mathiaz> I'm able to boot an instance, but not able to ssh in
[16:15] <zul> did you install ssh?
[16:15] <mathiaz> nijaba: thanks for all the hard work you've put in fixing the bugs
[16:15] <mathiaz> zul: yes.
[16:15] <mathiaz> zul: I may ask some help later on this part.
[16:15] <nijaba> mathiaz: a learning treasure and pleasure while soren was away
[16:15] <zul> mathiaz: okies
[16:16] <mathiaz> soren: did you have some time to review all the changes to vmbuilder?
[16:16] <mathiaz> soren: do you want to do the upload?
[16:18] <soren> I'd like to to the upload, but I've not caught up yet.
[16:18] <soren> I still have 25 commits to look through.
[16:18] <mathiaz> soren: ok - the deadline is thursday
[16:18]  * soren nods
[16:18] <mathiaz> soren: IMO we'll have to ask for a FFe as we're introducing the ec2 public.;
[16:18] <mathiaz> soren: other than that everything looks like bug fixes
[16:19] <zul> soren: yeah nijaba has been a busy little beaver
[16:19] <soren> mathiaz: Sort of.
[16:19] <soren> mathiaz: The ec2 plugin is already in the version in the archive.
[16:19] <nijaba> mathiaz: ec2 plugin was there in v2
[16:19] <mathiaz> ah - hm- ok then
[16:19] <nijaba> mathiaz: we added missing parameters, to fix bugs
[16:19] <mathiaz> then I don't think we've added new features
[16:20] <nijaba> mathiaz: I had to refrain myself ;)
[16:20] <mathiaz> that's all I have on vmbuilder
[16:20] <mathiaz> zul: nijaba: anything else?
[16:20] <nijaba> mathiaz: nope
[16:20] <ScottK> So is the ec2-ami-tools upload that was just done only bugfix?
[16:21] <zul> nope
[16:21] <zul> mathiaz: nope
[16:21] <zul> the ec2-ami-tools was the tools for ec2
[16:21] <nijaba> ScottK: but this had its own ffe
[16:21] <mathiaz> ScottK: which upload?
[16:21] <ScottK> New package: ec2-ami-tools (multiverse) [1.3-26357-0ubuntu3 → 1.3-26357-0ubuntu4]
[16:22] <ScottK> The ubuntu4 one
[16:22] <zul> thats me...I just uploaded a typo fix in a patch
[16:22] <ScottK> zul: OK.  I'll ask to get it accepted then.
[16:22] <zul> k thanks
[16:23] <mathiaz> ok. There are other things than need to be fixed.
[16:23] <mathiaz> zul: what did you fix?
[16:23] <zul> mathiaz: the upload bundle ruby script was pointing to the wrong directory
[16:23] <mathiaz> I've noticed that there is a curl dependency missing as well as a fix in the point-to-right-location patch
[16:24] <mathiaz> zul: ok - that's the second fix I'm talking about
[16:24] <mathiaz> ScottK: I'll do another upload to fix the curl dependency
[16:24] <zul> uhhh...ok
[16:25] <mathiaz> that's all from last week minutes
[16:25] <mathiaz> anything else to add?
[16:26] <mathiaz> nope - let's move on
[16:26] <mathiaz> [TOPIC] iscsi support for interpid
[16:26] <MootBot> New Topic:  iscsi support for interpid
[16:26] <mathiaz> kirkland: ^^?
[16:26] <kirkland> mathiaz: per dendrobates, this is too late for intrepid
[16:27] <mathiaz> kirkland: ok.
[16:27] <mathiaz> [TOPIC] Iso testing
[16:27] <nijaba> kirkland: so we did not make any progress since the support provided n hardy, right.
[16:27] <MootBot> New Topic:  Iso testing
[16:27] <kirkland> nijaba: not that i'm aware
[16:28] <kirkland> nijaba: i have had almost zero cycles to devote iscsi
[16:28] <nijaba> kirkland: np, just wanted to be sure`
[16:28] <mathiaz> so iso candidates for RC have been published
[16:29] <mathiaz> and testing them is welcomed
[16:29] <mathiaz> http://iso.qa.ubuntu.com/
[16:29] <MootBot> LINK received:  http://iso.qa.ubuntu.com/
[16:29] <mathiaz> this is the place where we track our results
[16:29] <nijaba> mathiaz: I've added a couple test cases for JeOS/F4
[16:29] <mathiaz> test cases have been updated
[16:29] <mathiaz> nijaba: when?
[16:30] <nijaba> mathiaz: last week
[16:30] <mathiaz> nijaba: ok - they've been added to the tracker now
[16:30] <nijaba> mathiaz: yes they have
[16:30] <mathiaz> we have 14 test cases to cover for 2 isos
[16:31] <mathiaz> I've got some more testing scenarios, especially related to raid installation
[16:31] <mathiaz> as of now I was only able to do one raid installation that was successful (raid1 on i386)
[16:31] <mathiaz> all the others have failed
[16:32] <mathiaz> so if someone could also do some test on raid install that would be helpful
[16:32] <sommer> I should have some time to do raid on i386
[16:33] <mathiaz> sommer: try to do a manual install of raid0 and raid5 then
[16:33] <sommer> sure
[16:33] <mathiaz> sommer: if you have enough hd for raid5 of course
[16:33] <sommer> mathiaz: I think I should
[16:33] <mathiaz> I'm doing all my tests with vms
[16:34] <mathiaz> sommer: I'd like to know if this is an issue with virtualization or with the installer
[16:34] <kirkland> mathiaz: ?
[16:34] <kirkland> mathiaz: raid installs are failing?
[16:34] <mathiaz> kirkland: yes - automated raid installs are failing
[16:34] <soren> .(
[16:34] <kirkland> mathiaz: and manual raid installs?
[16:35] <mathiaz> kirkland: amd64 fails because the partitions are wrong (while i386 with the same setup works)
[16:35]  * kirkland downloading iso's now
[16:35] <mathiaz> kirkland: haven't tried manual raid installs
[16:35] <mathiaz> testing manual raid install would be helpful
[16:36] <kirkland> i'm on it
[16:36] <mathiaz> kirkland: and then i386 raid0 and raid5 get the installer stuck
[16:36] <mathiaz> anyway - that's what I had to say wrt to iso testing.
[16:37] <mathiaz> of course if you have hardware available testing a bare-bone install is welcome (making sure the hw is correctly supported)
[16:37] <kirkland> my tests will be on vm's
[16:37] <kirkland> mathiaz: but i'll test manual raid on amd64
[16:37] <kirkland> mathiaz: raid1, raid0, raid5
[16:37] <mathiaz> kirkland: awesome - thanks.
[16:37] <mathiaz> kirkland: let me know of the results.
[16:37] <mathiaz> [TOPIC] RC bugs
[16:37] <MootBot> New Topic:  RC bugs
[16:37] <mathiaz> anyone discovered Release Critical bugs?
[16:38] <Koon> nope
[16:39] <mathiaz> ok - keep searching then ;)
[16:39] <Koon> I will.
[16:39] <mathiaz> [TOPIC] ubuntu-server-devel channel
[16:39] <MootBot> New Topic:  ubuntu-server-devel channel
[16:39] <mathiaz> nijaba: ^^
[16:40] <mathiaz> seems that traffic is increasing in #ubuntu-server
[16:40] <nijaba> I was wondering if now would be a good time to create a separate server channel for devel
[16:40] <mathiaz> and it may be worth creating a -devel channel for ubuntu-server
[16:40] <mathiaz> what do people think about this?
[16:40] <nijaba> I feel sorry for user asking for help when we are chatting about devel and not answering their question
[16:40] <kirkland> hmm....
[16:41] <ScottK> nijaba: Alternatively they'd just get silence.
[16:41] <nijaba> at the same time it may divide our community
[16:41] <nijaba> ScottK: right...
[16:41] <ScottK> I think the problem isn't needing a different channel, but needing more people willing to answer support questions.
[16:41] <kirkland> i'd say move that particular conversation to #ubuntu-devel, if it's a problem
[16:41] <nealmcb> I don't notice an overload of traffic, and with server users they often are interested in some devel topics also. but I could go either way
[16:41] <ScottK> Personally, if you split the channel, I'd just be on -devel
[16:41] <kirkland> my gut reaction is to wince at another irc channel
[16:42] <nijaba> ok, bad idea then
[16:42] <kirkland> i agree with ScottK's note that "answering support questions" is a real issue
[16:42]  * nealmcb nods
[16:42] <sommer> seems like they pick up as release date gets closer
[16:43] <nijaba> most of us do, when we can, but it is not always the highest prio
[16:43] <kirkland> nijaba: right... and too many questions are flamebait and traps
[16:43]  * nealmcb has been working around the clock on electionaudits so has been less helpful recently
[16:44] <kirkland> nijaba: seems that some people just want to the opportunity to tell a bunch of linux developers, "Fine, I'm going back to Windows/Mac/BSD"
[16:44] <ScottK> I find it odd they think that would bother us.
[16:44] <nijaba> kirkland: I'm not talking about *these*
[16:44] <kirkland> nijaba: ;-)
[16:45] <mathiaz> nijaba: IIUC your main concert is that questions are not answered while conversation is ongoing
[16:45] <mathiaz> nijaba: and that seems rude to the person asking for help
[16:45] <Koon> mathiaz: yep
[16:45] <nijaba> yes, gives me a strange feeling to ignore these guys
[16:45] <kirkland> nijaba: i can see that....
[16:46] <Koon> though that strange feeling migt not be worth risking more splitting of an already-thin community
[16:46] <nijaba> Koon: point fully taken
[16:47] <Koon> but I'm balanced.
[16:47] <nealmcb> yeah, it is easier when it is just totally silent and they can reread the topic :/
[16:47] <mathiaz> nijaba: one option would be to give a more generic answer to eh user
[16:47] <mathiaz> !volunter
[16:47] <mathiaz> !volunteer
[16:47] <mathiaz> hm - there is such an answer in ubotu
[16:48] <mathiaz> I don't remember the correct key though
[16:48] <mathiaz> !patience
[16:48] <nealmcb> :)
[16:48] <ScottK> Of course that's not entirely accurate.  Not all are volunteers.
[16:48] <ScottK> Are any of the Canonical server team tasked with answering support questions in #ubuntu-server?
[16:49] <sommer> IRC volunteers... sort of :)
[16:49] <soren> And answer are also always available. We're just keeping them secret.
[16:49] <nealmcb> right - if it noted that user support is on a volunteer basis that might be clearer
[16:49] <ScottK> Right.  Because our jobs depend on keeping the secrets ;-)
[16:49] <nealmcb> lol
[16:49] <kirkland> ScottK: Canonical sells support
[16:49] <ScottK> kirkland: I understand that.
[16:50] <kirkland> ScottK: none of us are tasked as community support volunteers
[16:50] <kirkland> ScottK: we do what we can, when we can to help
[16:50] <ScottK> As I'd expected, but I wanted to actually know rather than guess.
[16:50] <nijaba> but I do spend, as well of others, spend a lot of personal time one the chan
[16:50] <ScottK> Agreed.
[16:51] <mathiaz> all right -so it seems that creating another -devel channel is not really a good solution to the stated problem
[16:51] <nealmcb> so a factoid to reflect that might help - giving alternatives etc
[16:51] <nijaba> nealmcb: sounds like a good plan
[16:51] <mathiaz> isn't the topic already good on that point?
[16:52] <kirkland> a little verbose, if anything ;-)
[16:52] <nijaba> mathiaz: lots do not even read it, a factoid is more visible
[16:53] <mathiaz> kirkland: right - the second link to asking smart question may be removed
[16:53] <Koon> -ChanServ- [#ubuntu-server] Ubuntu Server Discussions (development and, sometimes, support)
[16:53] <mathiaz> ok - let's move on
[16:54] <mathiaz> I guess that the final outcome of this discussion is that we won't create a separate -devel channel
[16:54] <nijaba> yep
[16:54] <mathiaz> [TOPIC] UDS topics
[16:54] <MootBot> New Topic:  UDS topics
[16:54] <kirkland> mathiaz: are you calling for topics?
[16:54] <mathiaz> Altought we are *all* testing the intrepid isos, some of us may have ideas for the next release cycle
[16:55] <mathiaz> If so, please add them to the IdeaPool from the server team wiki pages
[16:55] <nealmcb> hmmm - irc client died right after my last comment....
[16:55] <mathiaz> https://wiki.ubuntu.com/ServerTeam/IdeaPool
[16:56] <mathiaz> That page will be used as input for the UDS topics
[16:56] <mathiaz> dendrobates: will be watching this page closely.
[16:57] <mathiaz> dendrobates: anything else to add wrt to UDS topics?
[16:57] <dendrobates> mathiaz: not at this time.
[16:58] <mathiaz> okidoki
[16:58] <mathiaz> [TOPIC] Open discussion
[16:58] <MootBot> New Topic:  Open discussion
[16:58] <mathiaz> anything else to add?
[16:58] <mathiaz> speak up now
[16:58] <zul> blub blub
[16:59] <mathiaz> zul: is that a program you want to package for jaunty?
[17:00] <sommer> heh
[17:00] <zul> mathiaz: yes its a replacement for frozen bubble
[17:00] <kirkland> it better be *damn* good, if it's to replace FB
[17:00] <nijaba> zul: under the blub licence?  not sure it is GPL friendly
[17:00] <mathiaz> zul: you mean - you plan to remove frozen bubble from the archive in jaunty?
[17:01]  * kirkland draws his slingshot back........
[17:01] <zul> what? I dont want to be public enemy number 1
[17:01] <mathiaz> zul: that needs to be discussed at uds
[17:01] <mathiaz> zul: at least one slot, if not a whole day
[17:01]  * nijaba loading mentos
[17:01] <zul> heh
[17:01] <mathiaz> zul: you've opened a can of worms...
[17:02] <zul> didnt mean to ;(
[17:02] <mathiaz> all right - anything else to add?
[17:03] <mathiaz> nope
[17:03] <mathiaz> [TOPIC] Agree on next meeting date and time
[17:03] <MootBot> New Topic:  Agree on next meeting date and time
[17:03] <mathiaz> next week, same time, same place?
[17:03] <nijaba> +1.02
[17:04] <zul> same bat channel?
[17:04] <sommer> o//
[17:04] <nealmcb> nijaba: sorry - that is an overvote....
[17:04] <ScottK> Is there going to be anything to meet about this time next week?
[17:04] <mathiaz> ScottK: well - I don't know.
[17:04] <nijaba> nealmcb: great, just testing your auditing algo
[17:04] <nealmcb> :)
[17:04] <mathiaz> ScottK: it may only a be a 5 minutes meeting.
[17:05] <ScottK> mathiaz: If we're going anything except ISO testing next week, we're in bug trouble.
[17:05] <sommer> there might be more jaunty ideas
[17:05] <mathiaz> ScottK: let's hope not. We'll meet next week to find out ;)
[17:05] <nijaba> dumrolls...
[17:06] <nijaba> drumrolls too
[17:06] <mathiaz> all right - so see you all next week, here, same time, same date.
[17:06] <mathiaz> and happy iso testing!
[17:07] <mathiaz> #endmeeting
[17:07] <MootBot> Meeting finished at 11:07.
[17:07] <sommer> thanks mathiaz, later on all
[17:07] <nijaba> thanks mathiaz
[17:07] <james_w> damn, too slow
[17:08] <james_w> just wanted to point out bug 286643 in case you had missed it
[17:08] <mathiaz> james_w: right - saw the bug
[17:08] <mathiaz> james_w: I have to investigate this issue a little bit more
[18:00]  * BenC is here
[18:00] <pgraner> Roll Call...
[18:00] <lieb> Yo
[18:00]  * cking is here
[18:00] <highvoltage> yay
[18:00] <pgraner> smb won't be making it
[18:01]  * ogasawara waves
[18:01] <amitk> hi
[18:01] <pgraner> ok looks like we are just missing rtg...
[18:01] <pgraner> nope here he is
[18:01] <pgraner> ok we can get moving
[18:02] <pgraner> #startmeeting
[18:02] <MootBot> Meeting started at 12:02. The chair is pgraner.
[18:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[18:02] <pgraner> [TOPIC] Intrepid Status
[18:02] <MootBot> New Topic:  Intrepid Status
[18:02] <pgraner> [LINK] https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux/+bug/259157
[18:02] <MootBot> LINK received:  https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux/+bug/259157
[18:02] <pgraner> [MASTER 0.7 regression] atheros/madwifi and orinoco drivers not supported (rtg)
[18:02] <pgraner> rtg: How do we sit with the one?
[18:03] <rtg> pgraner: I've been ignoring it in favor of other problems.
[18:03] <rtg> I think amitkhas run into it
[18:03] <pgraner> rtg: whats it going to take to get it moving?
[18:04] <rtg> clone me?
[18:04] <rtg> I need time to look at this one, but I'm not sure its really a bug.
[18:04] <BenC> is the bug in nm or in the kernel?
[18:04] <amitk> rtg: this is a different bug AFAIK. the madwifi wpa module isn't in N-M anymore according to asac
[18:05] <asac> amitk: just a slight correction: the madwifi module isnt available in wpasupplicant anymore
[18:05] <rtg> amitk: how can it not be? we haven't changed madwifi, have we Be?
[18:05] <amitk> aah..
[18:05] <asac> (NM just explicitly used that instead of wext for ath_pci in the past)
[18:05] <rtg> asac: ah
[18:06] <BenC> So the bug is that NM doesn't have the right module for ath_pci anymore?
[18:06] <asac> i think that was decided quite early during this cycle
[18:06] <rtg> asac: thats a whole different issue. why was it removed?
[18:06] <asac> BenC: wpasupplicant doesnt have the hacky-module anymore yes.
[18:07] <amitk> asac: IOW, the bug is that ath5k doesn't work as well as it was supposed to at the beginning of intrepid?
[18:07] <BenC> hacky module > no module?
[18:07] <rtg> well, I don't think ath5k is ready for prime time in all cases.
[18:07] <rtg> at least the hacky module worked.
[18:07] <asac> rtg: because wpasupplicant upstream obsoleted it from what i know.
[18:07] <BenC> any way to pull it back in?
[18:08] <rtg> nice of them to do that before a suitable alternative was completed.
[18:08] <ogra> rtg, the lbm ath5k module seems to work very good for the devices where it was broken for me
[18:08] <asac> rtg: actually i think you signed that off in that thread (sorry if i am wrong)
[18:08] <rtg> asac: I don't remember taht, but its possible.
[18:09] <asac> BenC: for intrepid? even if we could add that back we wouldnt have enough time to add hacks for that in nm
[18:09] <rtg> asac: is it sufficient for folks to go the LBM route?
[18:09] <BenC> so what's the solution?
[18:10] <asac> i cannot say what the solution is. maybe ath_pci has a improved in regards to wext and just blacklisting the right ids for ath5k would be enough to get back basic networking for them
[18:10] <rtg> seems like madwifi is a no-show for anything other then open APs
[18:10] <ogra> works here with WPA
[18:10] <pgraner> asac: do we know what the "right ids" are?
[18:10] <asac> at least i saw some comments that suggested that blacklisting ath5k was enough.
[18:10] <ogra> err
[18:10] <ogra> WEP
[18:10] <rtg> pgraner: thas a real problem.
[18:11] <NCommander> ogra, when I used madwifi on my old laptop, WPA worked fine, I can test it with whatever the current WPA solution is
[18:11] <asac> pgraner: no... i think rtg asked on that bug but i dont think we have enough info on that
[18:11] <amitk> pgraner: we don't. I have a pci id that works with madwifi for eee pc and ath5k for samsung q1.
[18:11] <rtg> the PCI ID refers to the AR5007, but not the RF part on the back-end.
[18:11] <ogra> pgraner, it also seems to depend on the HW combo ... while the same PCI id seems to work on an eeepc it doesnt on a samsung Q1
[18:11] <asac> what we really would need would be a bunch of different ath5k cards and test ;)
[18:11]  * pgraner mutters what a frickin' mess
[18:11] <ogra> ++
[18:12] <rtg> indeed
[18:12] <BenC> Sounds like there's no way to get it right at this point
[18:12] <pgraner> Ok, lets table this one and take it to kernel-list and see if we can get some consensus there
[18:12] <NCommander> asac, I think I have a ath5k card that is supported
[18:13] <asac> BenC: we can continue to gather information and consider a SRU to update the blacklist ... to at least fix this later
[18:13] <amitk> rtg: what if madwifi was blacklisted by default and lbm recommendation but in release notes?
[18:13]  * ogra likes to note that the prob with eee vs Q1 seems solved with lbm
[18:13] <NCommander> The problem is madwifi is still needed for a lot of macbook pros and apple hardware
[18:13] <NCommander> I don't think ath5k covers those cards
[18:13] <asac> and of course try to get as much info as possible before (if there is still an upload happening)
[18:13] <pgraner> rtg: can you write up a summary and send to the list to get the discussion going?
[18:13] <amitk> NCommander: newer ath5k?
[18:13] <rtg> without WPA, madwifi is largely useless
[18:13] <rtg> pgraner: sure
[18:14] <asac> rtg: well. but maybe wext support in ath_pci has improved and works for more
[18:14] <NCommander> amitk, ath5k only supports a subset of the madwifi cards (the newer ones) my first gen MacBook Pro wasn't supported last I checked.
[18:14] <asac> NCommander: so does blacklisting ath5k help for you?
[18:14] <pgraner> [ACTION] rtg to send email summary to kernel-team to continue discussion LP#246269
[18:14] <MootBot> ACTION received:  rtg to send email summary to kernel-team to continue discussion LP#246269
[18:14] <amitk> time to talk to luis
[18:15] <rtg> amitk: I've chatted with him 4 times in 5 days. its still a mess.
[18:15] <NCommander> asac, I haven't had to blacklist anything, but this machine isn't running intrepid, so its not a recent kernel
[18:15] <pgraner> Ok... lets move on...
[18:15] <pgraner> [LINK] https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux/+bug/246269
[18:15] <MootBot> LINK received:  https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux/+bug/246269
[18:15] <pgraner> Switched from vesafb to uvesafb, but uvesafb can't work without v86d (BenC)
[18:15] <pgraner> This should have been fixed by reverting to vesafb, but needs to be thoroughly tested and closely monitored for regressions. Ben: have you scanned for bug reports which might be related to this change?
[18:16] <BenC> pgraner: I have, and haven't noticed anything
[18:16] <pgraner> BenC: what about Dell's report of corruption on shutdown?
[18:16] <pgraner> rtg: ^^^^^^^^^
[18:16] <BenC> pgraner: I haven't heard anything back about that
[18:16] <BenC> rtg: ?
[18:17] <rtg> pgraner: I just received the laptop today. its installing as we chat
[18:17] <pgraner> rtg: let BenC know if you find anything
[18:17] <rtg> np
[18:17] <pgraner> [ACTION] rtg to report to BenC on shutdown screen corruption
[18:17] <MootBot> ACTION received:  rtg to report to BenC on shutdown screen corruption
[18:17] <rtg> i gotta say, though, that problem is way down the list.
[18:17] <pgraner> [LINK] https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux/+bug/267295
[18:17] <MootBot> LINK received:  https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux/+bug/267295
[18:18] <pgraner> This has been confirmed to still fail with -7.10, though the bug is generally in pretty bad shape. There are no details about the hardware involved. (BenC)
[18:18] <heno> I've tested the vesa change here and ara is doing more testing in Montreal
[18:18] <BenC> pgraner: as far as I know the situation where usplash was working on boot, and had graphical entities on shutdown is not a bug in the kernel...it's like usplash, or a bad interaction with xorg
[18:18] <pgraner> heno: great
[18:19] <pgraner> BenC: Can you look into this one today and see if its valid and update the bug or close if it fits?
[18:19] <heno> is booting with vga=792 testcase enough?
[18:19] <BenC> pgraner: will do
[18:20] <pgraner> [ACTION] BenC to look into LP #267295
[18:20] <MootBot> ACTION received:  BenC to look into LP #267295
[18:20] <pgraner> [LINK] https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux/+bug/284354
[18:20] <MootBot> LINK received:  https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux/+bug/284354
[18:20] <BenC> heno: yes
[18:20] <heno> thanks
[18:20] <pgraner> amitk: is this in the same boat as the other ath5k?
[18:21] <rtg> amitk: and why does it load both?
[18:21] <rtg> ath_pci should be preferred since its in LRM and not blacklisted.
[18:21] <amitk> pgraner: yes. Loading the ath5k from lbm fixes the problem
[18:22] <pgraner> amitk: Its looking like we will have to do one more upload, will this one be ready if we do?
[18:22] <amitk> rtg: I am investigating why both modules are loaded as we speak
[18:22] <rtg> pgraner: its in LBM, so its already uploaded.
[18:23] <pgraner> rtg: great
[18:23] <amitk> pgraner: lbm fixes it. so not much we can do
[18:23] <amitk> much else we can do
[18:23] <pgraner> amitk: ok, can we get the bug to reflect that along with updated state?
[18:23] <amitk> pgraner: on it
[18:24] <pgraner> [ACTION] amitk to update LP#284354
[18:24] <MootBot> ACTION received:  amitk to update LP#284354
[18:24] <pgraner> [LINK] https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux/+bug/249448
[18:24] <MootBot> LINK received:  https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux/+bug/249448
[18:24] <pgraner> rtg: this one is for you :-)
[18:24] <pgraner> This was fixed by Tim for Hardy, and the patch was carried forward (presumably to Intrepid?), but it's being reported in Intrepid now. Is this OBE due to the newer bluetooth stack? (rtg)
[18:25] <rtg> pgraner: I did check on this. the patch is still in Intrepid.
[18:25] <pgraner> ogasawara: can you ask for additional testing and see if we can close this one?
[18:25] <ogasawara> pgraner: sure
[18:25] <rtg> I'm assigned to it. I'll get to if I can.
[18:26] <pgraner> [ACTION] ogasawara to ask for additional testing on LP #249448
[18:26] <MootBot> ACTION received:  ogasawara to ask for additional testing on LP #249448
[18:26] <pgraner> [LINK] https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux/+bug/193970
[18:26] <MootBot> LINK received:  https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux/+bug/193970
[18:26] <pgraner> It appears that this has to do with the position of the switch when the module is loaded. Back to kernel? (rtg)
[18:26] <rtg> pgraner: yep - LBM is the likely solution (again)
[18:27] <pgraner> rtg: do you have a fix?
[18:27] <rtg> no for the stock kernel. rf-kill was in a state of flux when Linus slammed the lid on it.
[18:28] <rtg> like I said, LBM is the way to go for rf-kill support.
[18:28] <ogasawara> there is a workaroud for that one by unloading/reloading the module if you happened to boot with the kill switch enabled
[18:28] <NCommander> That bug is no longer true
[18:28] <pgraner> NCommander: ???
[18:28] <rtg> ogasawara: we could just stick it in pm-utils
[18:28] <NCommander> It used to be, but on my machine, the kill switch has been working for about a month
[18:28] <NCommander> I have an iwl4965 on this machine
[18:29] <NCommander> kill switch works the way its susposed to
[18:29] <rtg> its i3945 that is the issue
[18:29] <NCommander> Oh, the bug should be retitled then ;-)
[18:29] <pgraner> Ok, lbm for this one
[18:29] <rtg> well, it was originally a Hardy problem
[18:30] <pgraner> [TOPIC] QA Bugs
[18:30] <pgraner> [LINK] http://people.ubuntu.com/~ogasawara/intrepid-buglist.html
[18:30] <MootBot> New Topic:  QA Bugs
[18:30] <MootBot> LINK received:  http://people.ubuntu.com/~ogasawara/intrepid-buglist.html
[18:30] <pgraner> ogasawara: any new show stoppers?
[18:31] <ogasawara> pgraner: the only one was 263059 which has been resolved by disabling CONFIG_DYNAMIC_FTRACE
[18:31] <ogasawara> pgraner: there is also bug 276990 but I suspect it should be resolved with lbm
[18:32] <ogasawara> other than that I haven't seen any major showstoppers
[18:32] <NCommander> ogasawara, I can test that
[18:32] <rtg> ogasawara: yep, and I have a shiny new 802.11n AP which I'm about to turn on.
[18:32] <ogasawara> NCommander: that'd be great, thanks
[18:32] <NCommander> ogasawara, I'm still a little foggy w.r.t to lbm, so if you can explain it better after the meeting
[18:32] <pgraner> [ACTION] NCommander to test LP #276990 and report back to the bug
[18:32] <MootBot> ACTION received:  NCommander to test LP #276990 and report back to the bug
[18:32] <ogasawara> NCommander: sure
[18:33]  * NCommander assigns himself to the bug
[18:33] <pgraner> Anyone else have any other kernel bugs to raise for Intrepid?
[18:33] <NCommander> There are no unqiue show stoppers that I am aware of in ports
[18:33] <rtg> NCommander: sudo apt-get install linux-backports-modules-intrepid
[18:34]  * NCommander determines if he needs an n router to test
[18:34] <pgraner> Ok... I guess we can move on then...
[18:34] <pgraner> [TOPIC] UDS Status & Prep
[18:34] <MootBot> New Topic:  UDS Status & Prep
[18:34] <pgraner> I am starting to get tracks together for UDS and would like input from folks on what they would like to see.
[18:35] <pgraner> Current topics are: Fastboot, tree mgt and process, dropping the lpia arch and a few others that have escaped my recall right now
[18:36] <NCommander> I think we also have the topic of merging some of the port architectures to the main kernel if I followed a few other people correctly
[18:36] <rydberg> Fastboot is a great thing - forces some cleanup onto the whole system, too
[18:36] <pgraner> Email is the best submission method and I'll work them into the tracks. Make sure to give me a small bit of background and I'll follow up with everyone
[18:37] <rtg> NCommander: I'm not sure where you've come up with that idea. I'm not aware of any plans beyond ARM.
[18:37] <pgraner> rydberg: ack on that
[18:37] <rtg> pgraner: get amitk to talk about the ARM port.
[18:38] <pgraner> rtg: ack, thats there via davidm's tracks
[18:38]  * NCommander has ARM hardware, and doesn't mind doing the inital work to get the ARM kernel buildable/runnable
[18:38] <pgraner> rtg: we have lots of coordination to do with others, fastboot is one, its not only kernel
[18:39] <amitk> NCommander: I wouldn't mind help testing and taking care of flavours for which I don't have hardware. Lets take it up offline
[18:39] <pgraner> Anything else on UDS?
[18:40] <pgraner> I'll take silence as approval :-)
[18:40] <pgraner> [TOPIC] Open Discussion
[18:40] <MootBot> New Topic:  Open Discussion
[18:40] <pgraner> Anyone have anything?
[18:40] <NCommander> amitk, shoot
[18:41] <NCommander> Yeah
[18:41] <NCommander> I've been doing work on blowing the dust off -ports
[18:41] <NCommander> I have a working <IP_ADDRESS> based ports tree with the i386 and powerpc architectures tested
[18:42] <amitk> ia64 and sparc build?
[18:42] <NCommander> I'll be testing sparc
[18:42] <NCommander> ia64 might be tricky to test
[18:42] <NCommander> I have access to a VERY loaded down ia64 box from HP
[18:42] <BenC> I have ia64 and hppa
[18:42] <NCommander> Ok, following on that
[18:42] <BenC> local, so easy to test on
[18:42] <NCommander> There will be a new powerpc varient, powerpc-rt and powerpc-smp-rt
[18:43] <NCommander> er
[18:43] <NCommander> powerpc64-rt
[18:43]  * NCommander typoed
[18:43] <NCommander> I'll be working with the linux-rt maintainer to get that changeset landed in ports git tree
[18:43] <amitk> pgraner: topic for UDS: What arches and flavours to support inside canonical?
[18:44] <ogra> BenC, how are you able to test anything on hppa ? nothing has built there for weeks :)
[18:45] <pgraner> amitk: got it
[18:45] <BenC> ogra: magical pixie dust :)
[18:46] <NCommander> There is also the possibility that we could merge the linux-rt package into linux-ports. Formally ports also include community-supported build variants (just i386-386 ATM), but it might make sense to have rt there, and have i386-rt and amd64-rt build out of the ports tree instead
[18:46] <BenC> NCommander: we can't integrate the patches as a whole
[18:46] <NCommander> BenC, ?
[18:46] <BenC> NCommander: causes build failures and merge failures with other architectures
[18:47] <NCommander> BenC, we can add a patch system to add that patch dymanically
[18:47] <NCommander> Which is what linux-rt currently does AFAIK
[18:47]  * NCommander hates the idea of making the build system even more complex but this might be an unavoidable evil for powerpc-rt
[18:47] <BenC> NCommander: We have that...custom flavours...just letting you know it isn't a matter of just applying the patches without care :)
[18:48] <NCommander> BenC, of course not. Every patch has the tendency to break everything expect you ;-)
[18:48]  * NCommander has worked on gnumach before and learned that lesson the hard way
[18:48] <BenC> NCommander: but I also disagree with doing that because things like that tend to become blockers when they break
[18:48] <BenC> NCommander: and then we open the door for xen, openvz, patch-set-of-the-week
[18:49] <BenC> NCommander: and any one can block the whole package
[18:49] <NCommander> Hrm
[18:49] <rtg> oh no, don't go there. that was a nightmare.
[18:49] <zul> yes xen is evil
[18:49] <NCommander> I thought xen finally landed in 2.6.27
[18:49] <BenC> xen guest, but not host
[18:49] <NCommander> ouch
[18:50] <NCommander> Ok, so maybe having linux-rt merged into ports isn't the best idea ever ;-)
[18:50] <NCommander> however, I am working to make sure that at least the ports kernel is not three revisions old for the next time around
[18:50] <BenC> we've been down that road before...it's paved with evil things
[18:50] <pgraner> OK NCommander you can take this up on #u*-kernel with BenC and others
[18:51] <pgraner> we have 10min and need to watch time
[18:51]  * NCommander nods
[18:51] <pgraner> [TOPIC] Round Table
[18:51] <MootBot> New Topic:  Round Table
[18:51] <pgraner> pgraner -
[18:51] <rtg> seems like that was the round table.
[18:51] <pgraner> Reminder I'll be in London for release week with most of the other disto team mgt.
[18:52] <pgraner> rtg: whats going on for the remainder of this week for you?
[18:52] <BenC> pgraner: at least you get to be at the party
[18:52] <rtg> A key repeat bug is annoying my Dell friends.
[18:52]  * pgraner goes "yea!"
[18:52] <rtg> probably some more wireless issues.
[18:52] <pgraner> rtg: I've seen others mostly about the brightness keys
[18:53] <rtg> pgraner: I think they are releated.
[18:53] <rtg> related, even
[18:53] <pgraner> ogasawara: can you round all those up and see if we can mark as dupes?
[18:53] <ogasawara> pgraner: yup, I'll take a look
[18:53] <pgraner> [ACTION] ogasawara to round up all the repeat keypress bugs and look for dupes etc....
[18:53] <MootBot> ACTION received:  ogasawara to round up all the repeat keypress bugs and look for dupes etc....
[18:54] <pgraner> BenC: you're on... whats on your plate?
[18:54] <rtg> I can't see beyond that.
[18:54] <BenC> pgraner: toshiba-acpi cleanup and eventual testing, linux-firmware copyright/license (much harder than it appears tracking down history)...
[18:55] <pgraner> BenC: ACK.... Can you help rtg out and take a few things off his plate? i.e. key repeat
[18:55] <BenC> pgraner: Sure can
[18:55] <BenC> rtg: just spot me some bug numbers
[18:55] <rtg> like I know what they are.
[18:55] <pgraner> [ACTION] BenC to get with rtg on off loading some bugs
[18:55] <MootBot> ACTION received:  BenC to get with rtg on off loading some bugs
[18:55] <pgraner> amitk: what say you ?
[18:56] <amitk> I'm rebasing the lpia tree on top of <IP_ADDRESS> and working to solve ath5k/madwifi issue for mobile folks.
[18:56] <pgraner> amitk: cool
[18:56] <amitk> and then i'll work on bugs
[18:57] <rtg> pgraner: off topic - we should roll a kernel today. I've cherry-picked the <IP_ADDRESS> patches which has a couple of important fixes. xfs barrier, and scheduler reset.
[18:57] <BenC> Quick question: Anyone working on rebasing for jaunty yet?
[18:57] <pgraner> amitk: might want to work down ogasawara bug list top to bottom and see if there is any low hanging stuff you can knock out
[18:57] <BenC> If not, I'll add that to the back of my queue
[18:57] <amitk> pgraner: ack
[18:57] <pgraner> cking: sup with you?
[18:58] <NCommander> BenC, I'll help with that if you want.
[18:58] <cking> My pipeline is full with OEM issues to resolve
[18:58] <pgraner> cking: happy happy joy joy
[18:58] <BenC> cking: Good catch on some of those issues btw
[18:58] <cking> ..its getting less tedious now
[18:58]  * pgraner was being polite thought i'd give you the chance to bitch :-)
[18:59] <cking> BenC: thanks. it's been an education
[18:59] <pgraner> cking: is now the resident dsdt & BIOS guru
[18:59] <cking> pgraner: maybe :)
[18:59] <pgraner> lieb: how goes it your first week?
[18:59] <BenC> What a horrible thing to say
[18:59]  * pgraner says it with much love
[19:00] <lieb> thanks to benc I'm working on oem stuff.  got 8.10 beta running dual screen
[19:00] <lieb> is there a way to get adept to sort packages other than hash key?
[19:01] <pgraner> lieb: VT races are just plain good fun no?
[19:01] <lieb> almost as much fun as groking acronyms.  lbm??? lrm???
[19:01] <rtg> little-big-man
[19:01] <BenC> linux-backports-modules and linux-restricted-modules
[19:02] <pgraner> lieb: its gets easier ... really!
[19:02] <lieb> yea, eventually
[19:02] <pgraner> Ok... guys we are over so we'll call it end of meeting...
[19:02] <pgraner> #endmeeting
[19:02] <MootBot> Meeting finished at 13:02.
[19:02] <amitk> thanks all...