[13:59] <Brainstorm> Updates for Bangladesh: +1146 cases (now 1.6 million), +1 deaths (now 28098), +20204 tests (now 11.6 million, 5.7% positive) since a day ago


[08:14] <guiverc> i'm doing checks after a QA-install; 'install using existing partition' which is the repair type install; contrasting packages BEFORE & AFTER .. our new install has telnet????? why?
[08:15]  * guiverc I've noted people talking about telnet before (~recently), but alas took little notice as to why..
 Ubuntu base has telnet
 It is on server too
 To be fair it is the Telnet client and not the server daemon.
[08:17] <guiverc> has it always had it, I don't see it on my prior install?  (last friday from memory; 20230329 ISO save doesn't have it... but I could be missing something my end too
 It has been around for a bit, maybe always.
 I'm pretty sure we checked and it was on Jammy
[08:19] <guiverc> i realize that, and thanks kc2bez, the difference I'm staring out I wonder is something related to my install  (I think 0329 was the first lunar install on box; that install was focal before then)
 I am not sure when but it was noticed earlier in the cycle too. If I had to guess something was missing on the 0329 install if it wasn't there.
 Focal might not have had it.
[08:23] <guiverc> nah i think it was there then; manual check of the --manual-installed after that install has it.. i suspect now it's my procedural issue  (maybe not today; a week ago?)
[08:24] <guiverc> anyway install is good; just noticed telnet/fortune/cowsay/figlet unexpectidely in the diffs of packages (none are critical with 3 being ones I install & check for!)
[08:25]  * guiverc had checked fortune|cowsay which gave me a bad joke... thus as expected!
 :D


[06:04] <pitti> Hi sabdfl
[06:04] <Keybuk> (I'll be about 2 minutes)
[06:04] <fabbione> hi everybody
[06:05] <sabdfl> hey everyone
[06:05] <sabdfl> mdz around?
[06:06] <pitti> sabdfl: yes, in #u-devel
[06:06] <sabdfl> just pinged him
[06:06] <sabdfl> who else do we need? kamion?
[06:06] <pitti> me too :-)
[06:06] <fabbione> elmo perhaps?
[06:07] <sabdfl> Keybuk: ?
[06:08] <sabdfl> Keybuk: ready?
[06:08] <Keybuk> yup
[06:09] <sabdfl> mdz: set?
[06:09] <mdz> yep
[06:09] <sabdfl> ok, warty status matt?
[06:10] <mdz> looks like no new critical bugs were opened while I slept, so currently we are still in release condition as far as bugs
[06:10] <mdz> Kamion: the archive-copier changes went in last night as well?
[06:10] <mdz> I haven't been able to check in with jdub since going to sleep last night, so I'm not sure about the status of his work
[06:11] <sabdfl> from my side, waiting only for new artowrk packages from jdub
[06:11] <mdz> lamont produced a working live CD at the data center
[06:11] <sabdfl> working?
[06:11] <mdz> I downloaded it and used it
[06:11] <sabdfl> network, apps?
[06:11] <pitti> mdz: I checked today's ppc image, archive-copier and stuff was okay
[06:11] <fabbione> sabdfl: yeps.. tested here too
[06:11] <sabdfl> great
[06:11] <mdz> tested network connectivity, firefox, openoffice, etc.
[06:11] <mdz> for some reason my sound came up muted
[06:11] <mdz> wireless was detected and the driver loaded
[06:12] <sabdfl> if we have to tweak live cd, does it involve package tweaks or is it all behind the scenes?
[06:12] <mdz> fabbione: was your sound muted?
[06:12] <mdz> sabdfl: in this case, we had to remove something
[06:12] <Kamion> mdz: yes, today's CD seems to work with it
[06:12] <fabbione> mdz: i don't have any speakers yet sorry
[06:12] <fabbione> mdz: they are still packed and they will be for a long while
[06:12] <mdz> sabdfl: the entire desktop set + the winfoss stuff was > 650M
[06:12] <mdz> just by a hair, but still over
[06:12] <sabdfl> reason for asking is if we can release tomorrow for install, and put out an rc livecd
[06:12] <silbs> lamont knows 3-4 issues (including sound) w/ live cd
[06:12] <mdz> sabdfl: if we could remove one of the winfoss apps, we could restore the font package we removed
[06:13] <sabdfl> lamont asked and i though we should drop a windows package rather than compromise warty
[06:13] <sabdfl> done
[06:13] <mdz> sabdfl: agreed, but I didn't want to do that without asking you
[06:13] <mdz> ok, let's drop that astronomical program
[06:13] <sabdfl> agreed
[06:13] <sabdfl> are the live cd issues fixable without package uploads?
[06:13] <sabdfl> in other words, can we consider the packages final for release?
[06:14] <sabdfl> are the fixes in the underlying layer?
[06:14] <mdz> I haven't caught up with lamont yet this morning, so I'm not sure what the issues are
[06:14] <mdz> I'll follow up after the meeting
[06:14] <silbs> 1) artwork will change
[06:14] <silbs> (16:20:56) lamont: 2) sound is busted some places (due to differences in hwdetection between morphix kernel and ubuntu...)
[06:14] <silbs> 3 was the space thing and 4 is 4) other hardware detection inconsistencies between live and install CD's exist.
[06:14] <mdz> 2) lamont said alex fixed
[06:15] <sabdfl> don't think we can do anything further about hw detection inconsistencies
[06:15] <mdz> 4) is a known issue we must live with for warty
[06:15] <mdz> it's a hoary goal to make it consistent across the board
[06:15] <sabdfl> we knew warty wouldn't have perfect consistency
[06:15] <mdz> lamont: you said alex fixed the order of sound device detection, right?
[06:15] <sabdfl> so i don't think should hold back the release
[06:15] <mdz> we can't call the packages final until we have final artwork, since that's in packaged form
[06:15] <lamont> mdz: he said he reveresed it, but didn't have a 2-sound system to check against.
[06:16] <mdz> lamont: give me a URL and I'll start downloading now
[06:16] <lamont> sound is still unhappy on my vaio
[06:16] <lamont>   http://cdimage.ubuntu.com/sounder-test/live/warty-live-i386.iso.torrent
[06:16] <lamont> Or, if you can't use bit torrent, the actual iso is at:
[06:16] <lamont>   http://cdimage.ubuntu.com/sounder-test/live/warty-live-i386.iso
[06:16] <mdz> ok, will test when I have it
[06:16] <lamont> building a new CD image +ttf-baekmuk -windoze.celestia
[06:17] <mdz> lamont: that still fits, right?
[06:17] <sabdfl> mdz: yes, but do the live cd changes also require package changes, or is it just the autobuilder that changes?
[06:17] <lamont> should.  that's what I'm verifying
[06:17] <amu> looks like the problem is desktop <-> laptop systems based, i tested it today on 4 differnt systems, on laptops it fails on desktops sound works
[06:17] <mdz> sabdfl: the remaining changes are artwork (which requires package changes AND build system changes, I believe) and the changes lamont is doing right now (which are purely build system changes)
[06:17] <lamont> sabdfl: sorry that was to mdz. liveCD changes require (maybe) syncing the local mirror, and then turning the crank again
[06:18] <lamont> mdz: artwork --> package change, sync new packages into the right place, turn crank
[06:18] <mdz> lamont: you don't need to drop the splash image into place?
[06:18] <mdz> or the grub image?
[06:18] <Kamion> lamont: are you building locally now or in the LAN?
[06:18] <lamont> that's the package that has to get sync'ed/
[06:18] <sabdfl> ok, but fixing sound, hw sync etc, that's an autobuilder change, not a package change?
[06:18] <lamont> Kamion: building home-edition right now, if it fits, I'll build the DC-edition
[06:18] <Kamion> lamont: 'kay
[06:19] <sabdfl> "ubuntu, the colorado hills edition"
[06:19] <sabdfl> "live, from colorado"
[06:19] <lamont> fixing sound/hw detection is possibly a major overhaul of morphix
[06:19] <sabdfl> pass
[06:19] <lamont> worst case, sound is a user-obvious case of the hw detection not meshing.
[06:19] <mdz> unfortunately, users will judge Ubuntu hardware detection based on the live CD
[06:20] <lamont> we tried the trivial workaround for that case in the current CD.
[06:20] <mdz> even though they're completely different
[06:20] <lamont> mdz: very true
[06:20] <sabdfl> hoary will be better, right amu?
[06:20] <mdz> amu: in my case, it was simply that the sound devices were found in the opposite order
[06:20] <mdz> on my laptop
[06:20] <mdz> since it has a modem
[06:20] <sabdfl> ok, artwork
[06:21] <sabdfl> did anyone hear anything from jeff today?
[06:21] <lamont> for hoary, since we already have all the autodetection in our kernel/X/whatever, it probably makes sense to just roll the morphix patches over and include things that way, I would think... dunno.
[06:21] <sabdfl> i saw a note about him going to a meeting
[06:21] <amu> sabdfl: i'm sure, with this manpower we reach asap world domination
[06:21] <sabdfl> 9am aussie time
[06:21] <sabdfl> but nothing fter that
[06:21] <lamont> btw, this liveCD has the latest grub screen from jdub
[06:22] <Keybuk> he was off to a presentation of some kind this morning (UK)
[06:22] <amu> mdz: I didnt tested why, i tested more basic things, works/works not
[06:22] <lamont> amu: much of your list was "not for warty" stuff, sadly.
[06:23] <sabdfl> we either have to build a new set of packages based on what jdub last pushed out, or wait for him, or call him at home
[06:23] <amu> lamont: ... i tested it from a view a user, which is imported for a user, in order to do his dayly work with it
[06:23] <sabdfl> i'd really like to have a final build tonight
[06:23] <mdz> we should call him
[06:23] <sabdfl> so we can get it mirrored ut
[06:23] <sabdfl> ok
[06:23] <mdz> it's only 0230 or so, no? :-)
[06:23] <Keybuk> descent scott% TZ=Australia/Sydney date
[06:23] <Keybuk> Wed Oct 20 02:23:51 EST 2004
[06:24] <Kamion> let's wake him up if he's asleep
[06:24] <lamont> amu: understood
[06:24] <Kamion> he should be awake anyway :)
[06:24] <mdz> he did know that we wanted to do a build soon
[06:24] <fabbione> Kamion: eheh
[06:24] <Kamion> mdz: we can push stuff like jigit in post-CD-build, right?
[06:24] <amu> sabdfl: should be possible
[06:24] <Kamion> since it's Supported, not Base/Desktop/Ship
[06:24] <mdz> Kamion: into the archive?
[06:24] <sabdfl> no answer
[06:24] <mdz> yes
[06:24] <sabdfl> voicemail
[06:24] <Kamion> mdz: yes
[06:25] <sabdfl> how will we deal with the flood of "please get xyz version x..z into universe, it fixes a ton of bugs" requests?
[06:25] <mdz> sabdfl: "use hoary"?
[06:25] <lamont> sabdfl: will sync for hoary, I imagine...
[06:25] <sabdfl> ok
[06:25] <Keybuk> are we intending to update universe?  I assumed that would be frozen like supported
[06:26] <mdz> Keybuk: correct
[06:26] <lamont> freeze the whole thing
[06:26] <Keybuk> so yeah, mdz++
[06:26] <mdz> we've been very flexible with updating universe stuff up until now
[06:26] <sabdfl> during hoary's freeze, can we setup a process for the community to nominate and approve syncs without affecting the core team?
[06:26] <mdz> but we do have to call an end to it
[06:26] <mdz> sabdfl: hmm, could work
[06:26] <mdz> for universe
[06:26] <sabdfl> the "universe team"
[06:26] <mdz> "masters of the universe"
[06:26] <sabdfl> as long as they are sane and sensible, they could, erm rule the universe
[06:27] <Kamion> mdz++
[06:27] <lamont> sabdfl: on the "should you care" front, much of multiverse is d-w j2sdk1.[34]
[06:27] <fabbione> i am afraid that will give buildd (and lamont) a lot of headackes to unfuck *
[06:27] <sabdfl> lamont: and in english?
[06:27] <sivang> howdy folks
[06:27] <lamont> lots of multiverse ain't built since we ain't got no java in multiverse
[06:27] <mdz> sabdfl: lacking java
[06:27] <lamont> oh wait. that was 'merican.
[06:27] <sabdfl> 'k
[06:27] <mdz> fabbione: build failures will be the responsibility of the universe guys
[06:28] <lamont> but warty remains warty.  bug fixes for universe go into hoary.
[06:28] <amu> packages: evolution, well it has some nice feature like spamchecks or groupware, outlookplugins, i think we should add those depends
[06:28] <fabbione> mdz: i am more afraid of something that builds and kill the rest of universe
[06:28] <sabdfl> ok
[06:28] <sabdfl> just trying jdub's mobile
[06:28] <mdz> fabbione: also their problem
[06:29] <mdz> this is what it means for universe to be community supported
[06:29] <sabdfl> ok, let's move on
[06:29] <fabbione> mdz: in theory it works perfectly.. let's see how it goes in reality :-)
[06:29] <sabdfl> Hoary starter plans
[06:30] <Keybuk> that was mine, I think
[06:30] <mdz> I estimate we have a solid few weeks of work for the review and merge process
[06:30] <Keybuk> *swaps hats*
[06:30] <sabdfl> Keybuk: hct status?
[06:30] <Keybuk> what I was going to offer, for the review/merge process was setting up a temporary arch repository
[06:30] <Keybuk> import debian from warty freeze to current day into that
[06:30] <mdz> that includes a lot of stuff that we can't really automate, even with hct
[06:30] <Keybuk> import warty into that
[06:31] <Keybuk> that'll give us an easy merge to create hoary
[06:31] <mdz> we need to check which bugs have been fixed, even if they were done in a different way
[06:31] <sabdfl> "easy merge"?
[06:31] <Keybuk> sabdfl: hct is good, but without any arch imports it's not useful
[06:31] <Keybuk> sabdfl: well, I can do an hct tablecloth-trick (jdub's name :p) on it
[06:31] <sabdfl> how many packages did we touch for warty?
[06:31] <Kamion> fwiw I'm happy to merge d-i by hand; estimate about a week ...
[06:31] <Keybuk> sabdfl: many. many. many.
[06:32] <sabdfl> about 340 right?
[06:32] <mdz> sabdfl: at last count
[06:32] <mdz> that figure has only increased since
[06:32] <sabdfl> one option is to put the new things into hoary only
[06:32] <sabdfl> like x.org
[06:32] <sabdfl> gnome 2.9
[06:32] <Keybuk> we can use hct to do the difficult bit, but as a general-use tool it's still waiting on those bloody imports :-(
[06:32] <mdz> 1018 source packages
[06:32] <sabdfl> stuff where we are really the head
[06:32] <mdz> 356 with ubuntu version numbers
[06:33] <mdz> so about 35%
[06:33] <sabdfl> and the number will only go up for hoary
[06:33] <Keybuk> what do we do with the rest of the packages?
[06:33] <sabdfl> (btw fantastic job warty team)
[06:33] <pitti> sabdfl: well, much stuff was sent upstream
[06:33] <mdz> pitti: yes, but we have no record of what was merged and what was not
[06:33] <elmo> I see more like 500 with ubuntu version numbers, including all components
[06:33] <sabdfl> pitti: yes, but a ton of stuff wasn't
[06:33] <mdz> and we have many changes which were not appropriate for upstream
[06:33] <fabbione> sabdfl: for x.org i need xfree86 too. that's not really an option
[06:33] <pitti> no, unfortunately not in an automated way
[06:33] <mdz> elmo: I was only looking at main
[06:34] <sabdfl> fabbione: so manage the transition?
[06:34] <sabdfl> s/so/to/
[06:34] <mdz> elmo has said it is no problem to set things up so that we automatically sync stuff that doesn't have an ubuntu version number
[06:34] <fabbione> sabdfl: in terms of code we have 300K lines of patches from Xfree86 that needs to be reviewed to go into X.org
[06:34] <mdz> then we merge the remainder by hand
[06:34] <fabbione> sabdfl: that's just "upstream" transition
[06:34] <sabdfl> is that likely to lead to real breakage in dependencies?
[06:34] <fabbione> sabdfl: without taking into account all the packaging part
[06:35] <mdz> fabbione: daniel mentioned that 300k number as well; where does that come from?
[06:35] <sabdfl> since the packages we touched hardest are probably also most central?
[06:35] <mdz> there are less than 300k lines of patches in debian/patches
[06:35] <mdz> about half that
[06:35] <elmo> yeah, it's 492 including non-main components.. wonder why we ended up modifying so many non-main things
[06:35] <fabbione> mdz: wc -l debian/patches/*
[06:35] <mdz> sabdfl: yes, there will be dependency breakage
[06:35] <mdz> elmo: libtiff transition in universe, etc.
[06:35] <elmo> ah, right
[06:35] <Keybuk> elmo: lamont had a build-dep mania one day
[06:35] <mdz> fabbione: diffstat debian/patches/*
[06:35] <sabdfl> ok... this isn't an area where i can lead guys, you know best
[06:35] <Kamion> mdz: that will certainly result in much temporary breakage in d-i, but I think that's fine for hoary TBH
[06:35] <mdz> sabdfl: the issue is that we have a ton of work to do before hoary can really start to flow
[06:35] <mdz> sabdfl: which doesn't give us a break after the release at all
[06:36] <Keybuk> we have a semi-automatic solution that might work for everything we're not leading
[06:36] <Kamion> it'll take a few days to make d-i work for hoary anyway, for one reason or another
[06:36] <sabdfl> team deserves a break
[06:36] <Keybuk> things like gnome we're leading Debian anyway
[06:36] <mdz> Keybuk: the semi-automation is not dependent on imports?
[06:36] <Kamion> $ ls src/ubuntu | wc -l
[06:36] <Kamion> 104
[06:36] <sabdfl> Keybuk: what's the status on the imports? lifeless told me we were on our way
[06:37] <Keybuk> mdz: only package imports and I can do those and throw them away afterwards
[06:37] <Keybuk> sabdfl: well, arch.ubuntu.com hasn't changed in three weeks
[06:37] <Kamion> guess about half of those belong to me to merge
[06:37] <T-Bone> lamont: lol
[06:37] <mdz> we should do a manual review up front, before trying anything fancy
[06:38] <sabdfl> ok, i'll chase lifeless on the arch merge front
[06:38] <mdz> we can probably eliminate 25-50% of those packages because everything has been merged upstream
[06:38] <sabdfl> have mostly been focused on malone
[06:38] <mdz> based on changelogs
[06:38] <Kamion> mdz: hardest work will be stuff that's been branded, for sure
[06:38] <fabbione> mdz:  1499 files changed, 161366 insertions(+), 67008 deletions(-)
[06:38] <mdz> Kamion: agreed
[06:38] <sabdfl> are our own patches clearly separated?
[06:38] <Kamion> sabdfl: depends
[06:38] <mdz> sabdfl: only in a subset of cases
[06:38] <Kamion> sabdfl: you can't clearly separate patches to .po files and stay sane at the same time
[06:38] <sabdfl> so are you guys READY for tla?
[06:39] <mdz> sabdfl: no
[06:39] <Keybuk> patches to .po files are evil :-(
[06:39] <sabdfl> Kamion: right
[06:39] <mdz> rather, tla is not ready for us
[06:39] <sabdfl> rosetta :-)
[06:39] <fabbione> sabdfl: no for X.org
[06:39] <Kamion> sabdfl: yes, but even so
[06:39] <sabdfl> tla isn't going to improve soon
[06:39] <sabdfl> we have an arch team drill for two weeks before es-conf
[06:39] <sabdfl> but that's jsut where we will set the goals for usability
[06:39] <mdz> it would be much less work to bring the patches forward manually than to get up to speed with tla
[06:40] <mdz> everyone would take 30 packages
[06:40] <sabdfl> the launchpad team has really battled with tla, and it's certianly not something i'm comfortable recommending for global FLOSS use
[06:40] <mdz> with any luck, 10 of those would be simple changelog review and revert to Debian
[06:40] <sabdfl> at the same time, it's proven fantastic when it works
[06:40] <Keybuk> sabdfl: did you read mako's blog entry?
[06:40] <sabdfl> nope, url?
[06:40] <mdz> that's not a huge amount of work for each of us
[06:40] <Kamion> (er, when I say tla I mean raw/hct/whatever)
[06:40] <Kamion> mdz: I think we could crunch through nearly everything in a week, personally
[06:41] <Keybuk> http://mako.yukidoke.org/copyrighteous/freesoftware/20041017-00.html
[06:41] <mdz> Kamion: we need to pace ourselves :-)
[06:41] <Kamion> a week of fairly solid work, but I don't think it'll be terribly *hard* work
[06:41] <sabdfl> or planet.ubuntu.com
[06:41] <sabdfl> yes, very well put
[06:41] <fabbione> Kamion: i agree..a lot of our local patches have been included in debian
[06:41] <sabdfl> the main issue is not that we can crunch through it, it's that sustaining the delta manually is just going to be "make work" without good tools
[06:41] <Kamion> and the packages we've changed are all hopefully packages we've become familiar with
[06:42] <sabdfl> at least that's how it seems to me, but you guys would know better
[06:42] <fabbione> mdz: pace? i wake up in the middle of the night yelling X.org :)
[06:42] <Keybuk> heh, I had a dream the other night in which everyone was a changeset and all trying to get through a single door
[06:42] <amu> lamont: pay for the old one ? a easy solution, poison her, you go into prison and you have all day time for hacking
[06:42] <mdz> sabdfl: that is correct
[06:42] <mdz> but the tools simply aren't ready yet
[06:42] <Kamion> sabdfl: that's true, but at the same time our feature goals for hoary are such that we need to have a place to put interim work on them fairly soon, without losing too much time with the tools
[06:42] <sabdfl> ok
[06:42] <Kamion> seems to me bringing up the toolset would be better done in the middle of a release cycle, where it can be more easily parallelised?
[06:42] <mdz> we can create a simple source-package-merge tool which can automate the cases where there are no conflicts
[06:43] <mdz> that's not hard
[06:43] <mdz> we can set up a notification system whenever a new merge is needed
[06:43] <sabdfl> one option is just to ignore it till we freeze hoary
[06:43] <sabdfl> because at least then the targete isn't moving so fast
[06:44] <sabdfl> so, start work on all the new things for hoary
[06:44] <sabdfl> push upstream as much as possible
[06:44] <mdz> you mean, ignore merging new stuff from Debian?
[06:44] <sabdfl> no, other way around
[06:44] <Keybuk> mdz: Debian hasn't moved a *huge* amount yet
[06:44] <sabdfl> ignore bringing forward warty stuff
[06:44] <mdz> Keybuk: the RC bugs we've seen fly by say otherwise :-/
[06:44] <mdz> sabdfl: I don't think we can do that
[06:44] <sabdfl> ok
[06:45] <mdz> that would revert all of our branding, all of our bug fixes, everything we've done to make things work right
[06:45] <mdz> the merge will only get more difficult as time goes on
[06:45] <sabdfl> i'm just wondering whether it's more work to port it forward and then keep it merged as debian updates before we freeze
[06:45] <mdz> the right time to do it is immediately when hoary opens
[06:45] <sabdfl> or bring it forward when we freeze
[06:45] <sabdfl> but then we have to merge every time the relevant debian package updates
[06:46] <Kamion> in my experience, repeated small merges are less work
[06:46] <mdz> Kamion: agreed
[06:46] <pitti> Kamion: agreed
[06:46] <sabdfl> oh, ok
[06:46] <mdz> sabdfl: yes, but they're small, easy merges generally
[06:46] <Keybuk> Kamion++, keep the merges small
[06:46] <fabbione> Kamion: agreed!
[06:46] <Kamion> one big merge just becomes unintelligible and you end up breaking it down into repeated small merges anyway
[06:46] <thom> agreed
[06:46] <sabdfl> ok
[06:46] <Keybuk> elmo: ping?
[06:46] <elmo> yeah
[06:46] <sabdfl> well, lots of merge work for the hoary team will make them expert endusers for hct when it comes :-)
[06:47] <Keybuk> elmo: is there any way you can make the warty morgue available ?
[06:47] <mdz> we should schedule a Hoary kickoff meeting
[06:47] <elmo> Keybuk: it already is on rookery
[06:47] <mdz> that will include reviewing the list of potential feature goals, deciding what we can actually do for hoary, and breaking down tasks
[06:47] <elmo> last updated a week or so ago
[06:47] <Kamion> mdz: Thursday for sleep, Friday for meetings? :)
[06:47] <Keybuk> elmo: rookery doesn't have much on it though (like tla :p)
[06:47] <mdz> Kamion: thursday-sunday sleep, monday meeting?
[06:48] <Keybuk> and is rookery caneable?
[06:48] <fabbione> mdz: no later that 14:00 UTC please :-) or my future wife will hunt you down :P
[06:48] <thom> mdz++
[06:48] <sabdfl> mdz: i figure you and the team will make the best call on merge strategy
[06:49] <sabdfl> please push the arch team to make arch suit YOU, not the other way around
[06:49] <pitti> adapt the problem to the solution :-)
[06:49] <mdz> sabdfl: yes, I have no problem with the strategy, only the fact that we don't have time to breathe between releasing warty and opening hoary
[06:49] <mdz> because opening hoary requires the huge merge effort
[06:49] <sabdfl> i think give your team the break
[06:49] <pitti> but we can take our time for it, right?
[06:49] <sabdfl> let's spend some time thinking about what we want in hoary
[06:49] <mdz> fabbione: that's 0700 here, which causes problems for MY home life :-)
[06:49] <sabdfl> the merge will go much faster if we have exciting goals for hoary
[06:49] <mdz> sabdfl: so, announce that hoary will remain more or less equal to Warty for a week or so?
[06:50] <sabdfl> i'm asolutely fine with that
[06:50] <mdz> ok, works for me
[06:50] <sabdfl> the warty team has put in a superhuman effort
[06:50] <mdz> they're chomping at the bit, but they'll survive for a week I think
[06:50] <pitti> I thought we sync all unmodified packages?
[06:50] <sabdfl> the last few days should have been a slight break since we were in such deep freeze
[06:50] <mdz> pitti: I don't think we should do that until we've reviewed the modified ones
[06:50] <mdz> otherwise we're likely to break deps all over the place
[06:50] <sabdfl> but everyone needs a proper release
[06:50] <pitti> mdz: we could employ the sarge testing scripts to check that deps don't break
[06:50] <elmo> mdz: that'll at least warn people hoary is a devel branch ;)
[06:51] <sabdfl> ok, so let's talk about the non-merge challenges for hoary
[06:51] <Kamion> pitti: we're already running them in report-only mode
[06:51] <pitti> so much the better
[06:51] <Kamion> pitti: http://people.ubuntulinux.org/~cjwatson/testing/
[06:51] <mdz> I'd like to discuss the feature goals at the hoary kickoff meeting when everyone is around
[06:51] <pitti> Kamion: so would it be possible to sync all packages that don't conflict to anything?
[06:51] <fabbione> mdz: daniels and I will be busy on the X-Man meeting from the 1st of Nov.
[06:51] <sabdfl> ok, i'm more interested in discussing how we organise it than what the goals are
[06:51] <fabbione> mdz: for 2 full weeks
[06:51] <mdz> sabdfl: which aspects?
[06:51] <Kamion> pitti: I suspect that's more trouble than it's worth; sync 'em, let the team sort out the breakage
[06:52] <sabdfl> well, some of them are similar to warty
[06:52] <pitti> Kamion: okay, agreed
[06:52] <sabdfl> debian sid + stability and security
[06:52] <sabdfl> gnome 2.x
[06:52] <sabdfl> x.org
[06:52] <pitti> Kamion: I don't feel that tooo much will break
[06:52] <sabdfl> but some are also whole chunks of brand new work
[06:52] <pitti> Kamion: (as long as we don't sync older versions)
[06:52] <sabdfl> and that's something we didnt do for warty
[06:52] <sabdfl> new apps and applets
[06:52] <sabdfl> bootsplash
[06:52] <mdz> we did some smaller chunks of new work for warty
[06:53] <sabdfl> but much of that was opportunistic
[06:53] <mdz> right
[06:53] <sabdfl> which is easier to manage
[06:53] <sabdfl> i prefer to work opportunitically, frankly
[06:53] <sabdfl> but for hoary we have set some goals
[06:53] <mdz> for hoary, I think we'll trim down the list of feature goals to a subset which is achievable for hoary
[06:53] <mdz> and build a small team for each
[06:53] <sabdfl> either way, i think we'll find that the goals will fall on the floor if we don't start early
[06:53] <sabdfl> assign each goal to someone
[06:54] <mdz> there are a number of community members who are interested in working on the feature goals
[06:54] <Kamion> it'll be an interesting exercise in the first month or so discovering how much of what we've set ourselves is achievable; we haven't settled into time estimation yet really
[06:54] <sabdfl> or put a reasonable bounty on it
[06:54] <sabdfl> Kamion: agreed
[06:54] <sabdfl> it's that new aspect of things that i'm concerned about
[06:54] <sabdfl> we can do it
[06:54] <mdz> Kamion: as far as I'm concerned, everything on the page now is just brainstorming
[06:54] <mdz> we'll choose from that what we can actually do
[06:54] <sabdfl> but it's a new management thing
[06:54] <sabdfl> mdz: agreed, it's a wiki after all
[06:54] <mdz> much of it will fall to grumpy
[06:55] <sabdfl> estimating is very hard to do
[06:55] <sabdfl> i'd like to identify the things that are absolutely core and have our team do those
[06:55] <pitti> hmm, IMHO the most important Hoary goal is using the new infrastructure
[06:55] <sabdfl> everything else is nice-to-have and we put a bounty on it and try to steer the community in that direction
[06:55] <sabdfl> pitti: launchpad?
[06:55] <pitti> sabdfl: yes
[06:55] <mdz> current hoary feature freeze is February 7th
[06:55] <pitti> sabdfl: hct, arch, and this magic
[06:55] <lamont> mdz: +ttf-baekmuk - windoze.celestia ==> 329950 extents written (644 MB)
[06:55] <sabdfl> we'll have soyuz up and running in a week or two in view mode
[06:56] <Kamion> pitti: I tend to feel that the most important Hoary goal is to release in April :-) We need to convince the community that we can do this six-month release thing ...
[06:56] <sabdfl> malone sooner
[06:56] <sabdfl> Kamion: i agree
[06:56] <pitti> Kamion: okay :-)
[06:56] <mdz> so we will need to select goals where primary development can be complete in ~3 months
[06:56] <sabdfl> yes
[06:56] <sabdfl> that's why i was relaxed about the merging
[06:56] <Keybuk> Kamion++ totally
[06:56] <sabdfl> i'd almost like to get everyone excited about new feature goals and give people time to explore those
[06:56] <Keybuk> the most important thing for hoary is to nail the release datae
[06:57] <sabdfl> i don't want to be in the same situation we were in at oxford
[06:57] <pitti> Keybuk: I took this for granted
[06:57] <mdz> well, if we need to drop a new feature because it isn't ready, we can do that
[06:57] <sabdfl> with exciting new features creeping in very close to final freeze
[06:57] <Keybuk> sabdfl: fortunately December isn't close to freeze, it's actually a good time for development madness
[06:57] <sabdfl> so, for example, bzip should go in NOW
[06:57] <sabdfl> so we have time to tweak and tune
[06:58] <Keybuk> sabdfl: can I clear a day for that?
[06:58] <mdz> Keybuk: yes, the schedule meshes much better now
[06:58] <sabdfl> Keybuk: absoloodle
[06:58] <elmo> or decide that it's crack and not do it :P
[06:58] <fabbione> elmo++
[06:58] <sabdfl> at the hoary launch meeting we can clarify all ofthis
[06:58] <sabdfl> but i wanted to describe the approach here
[06:58] <mdz> sabdfl: ok, so are you proposing that we isolate the core Hoary goals at this meeting?
[06:58] <sabdfl> this meeting now? no
[06:58] <mdz> ok
[06:59] <sabdfl> just agree that we'll work hard on those new feature goals sooner rather than later
[06:59] <sabdfl> otherwise they'll just fall on the floor
[06:59] <sabdfl> and i agree with kamion
[06:59] <mdz> of course
[06:59] <sabdfl> better to set the bar lower and hit the goal
[06:59] <mdz> it's juts that all of this is in direct conflict with giving the team a short break after release
[06:59] <sabdfl> well, change is a holiday :-)
[06:59] <sabdfl> for example, cleaning up that hoary list before the meeting will be relaxing
[07:00] <sabdfl> getting people to figure out what aspects they want to make personal goals
[07:00] <pitti> sounds nice
[07:00] <Keybuk> sabdfl: you find playing with that database schema from hell relaxing, though :)
[07:00] <sabdfl> Keybuk: i don't pretend to be normal :-)
[07:01] <Keybuk> I guess we should skip Hoary Release Plans until the meeting, seeing as the release manager's in bed ? :)
[07:01] <sabdfl> how effectively do you think we can get community interest in bounties up and running?
[07:01] <mdz> I think it's happening already, organically
[07:01] <mdz> I have several things queued up which could become hoary feature bounties
[07:01] <sabdfl> for example, if we publish a list of $100k's worth of bounties for hoary, are we likely to see interest?
[07:01] <Keybuk> yeah, I think the interest is ramping
[07:02] <sabdfl> i think we want to make them bounties, but with drop-dead dates
[07:02] <sabdfl> so people feel an urgency to actually deliver early
[07:02] <lamont> and those dates are pre-freeze, yes?
[07:02] <Keybuk> If they're cool things, I'd be surprised if we didn't get any interest
[07:02] <sabdfl> my experience with bounties in the past is that the take-up is very haphazard
[07:02] <mdz> deadlines like 2-4 weeks before feature freeze
[07:02] <sabdfl> mdz: but with milestone drops sooner rather than later
[07:03] <mdz> agreed
[07:03] <sabdfl> so maybe we say you can "stake a claim" to a bounty
[07:03] <sabdfl> but then you have to start producing code drops every two weeks
[07:03] <lamont> could be first code drop is your stake?\
[07:03] <sabdfl> so people don't just sit on them
[07:03] <sabdfl> lamont: good idea
[07:03] <sabdfl> but people don't like to start work if they think someone else is already on it
[07:04] <sivang> true
[07:04] <sabdfl> simultaneously they dont actually work unless they think it could go to someone else
[07:04] <mdz> we have a number of projects which are bigger than one person
[07:04] <sabdfl> also true
[07:04] <mdz> is there a way to make team-based bounties work?
[07:04] <lamont> right - just means that you have a 2 week window from ITP to first drop...
[07:04] <sabdfl> mdz: yes i think so
[07:04] <sabdfl> need to appoint a team leader, and have them agree the rest
[07:05] <sabdfl> i'll have another person in the office here from November 8th
[07:05] <sabdfl> can keep track of bounties
[07:05] <sabdfl> so the admin should be straightforward
[07:05] <silbs> they should name their own team leader, not us. We shouldn't care if it's 1 person or >1
[07:05] <lamont> right - any bounty could subcontract parts of it.
[07:05] <mdz> silbs: so our agreement would always be with one person, and if they divide things up as a team behind the scenes, that's their problem?
[07:05] <sabdfl> ok, anything else on how we'll organise ourselves for hoary?
[07:06] <mdz> we need to review the release schedule, but that can happen at kickoff
[07:06] <thom> mdz: that seems reasonable as long as they understand that
[07:06] <silbs> mdz: i think so. We don't want to be arbitrator of "X did more work than Y"
[07:06] <sabdfl> jdub put a note on the wiki that he will review the hoary schedule
[07:06] <sabdfl> bounties can be tricky
[07:06] <sabdfl> i had two guys arguing over who's PyGTK Exim Monitor was better
[07:07] <sabdfl> we'll figure that stuff out
[07:07] <Keybuk> sabdfl: before he does, it's worth finding out whether we want to tie it quite as closely to GNOME's as we did this time
[07:07] <Keybuk> mdz had a minor stroke when he realised seb was putting 2.8.1 on RC day
[07:07] <sabdfl> Keybuk, mdz, any reason not to tie to gnome?
[07:07] <sabdfl> oh
[07:07] <mdz> sabdfl: we need a buffer
[07:07] <sabdfl> i think we should plan to make our preview on gnome 2.10
[07:07] <mdz> we can't have new upstream releases going in an hour before we roll the release
[07:07] <sabdfl> and our release gnome 2.10.1 + x days
[07:08] <sabdfl> mdz: we CAN, it's just not sensible ;-)
[07:08] <mdz> for warty, it has actually interfered with building the CD images
[07:08] <mdz> we need +1 day at least
[07:08] <sabdfl> how many days are a sane pressure release?
[07:08] <Keybuk> how many days of testng do we need before we're happy to begin rolling things?
[07:08] <sabdfl> 3?
[07:08] <fabbione> sabdfl, mdz: we also need to kill the overlap between releasing stable and the first CD of the next release
[07:08] <sabdfl> fabbione: yes, agreed
[07:08] <sabdfl> hmm...
[07:08] <mdz> the GNOME point releases are generally very sane
[07:09] <mdz> we just need to avoid having the stuff happen at exactly the same time
[07:09] <sabdfl> will we start grumpy rolling when we freeze hoary?
[07:09] <mdz> 3 days should be fine
[07:09] <mdz> sabdfl: not unless we have automated merge capability
[07:09] <mdz> we can't divert effort to manual merging at that time
[07:09] <sabdfl> ok, so plan for preview on gnome 2.10, final on gnome 2.10.1+3d
[07:09] <sabdfl> mdz: yes, agreed
[07:09] <mdz> Keybuk: 27 December?
[07:09] <sabdfl> what date is that currently?
[07:10] <sabdfl> mdz: stop doing that, it freaks me out
[07:10] <mdz> sabdfl: ^^
[07:10] <Keybuk> mdz: what's 27th December ?
[07:10] <sabdfl> :-)
[07:10] <mdz> Keybuk: upstream version freeze
[07:10] <pitti> feature freeze?
[07:10] <Keybuk> my stuff will be ready well before then, the arch import team need a Saturn V up their arse though to get them moving :p
[07:11] <sabdfl> Keybuk: incoming
[07:11] <mdz> upstream freeze is probably the earliest we would want to do it
[07:11] <mdz> we should "encourage" folks to stick with hoary for as long as possible, to get testing
[07:11] <Keybuk> sabdfl: incoming to where?
[07:11] <sabdfl> hmm... perhaps we could create a grumpy team
[07:11] <sabdfl> community
[07:12] <sabdfl> that uses hct to do the merging
[07:12] <sabdfl> while we keep working on hoary
[07:12] <fabbione> sabdfl, mdz: opening grumpy when we release RC should be ok i think..
[07:12] <sabdfl> i envisage in future we'll have a "stable" team of two or three that keeps working on warty, say
[07:12] <mdz> fabbione: that's far too late in my opinion
[07:12] <sabdfl> so there could be an advance guard and a rearguard
[07:13] <sabdfl> i wouldn't want to distract the core team with the merge issues
[07:13] <sabdfl> anyhow, future problem
[07:13] <sabdfl> next on the agenda
[07:13] <fabbione> mdz: opening un unstable too early will take away the community from stable.
[07:13] <sabdfl> policies and procedures for security
[07:13] <mdz> right
[07:13] <sabdfl> matt?
[07:13] <mdz> for Warty
[07:13] <Kamion> Keybuk: incoming> their arse, presumably? :)
[07:13] <sivang> security team
[07:13] <mdz> elmo has begun setting up the infrastructure side of things
[07:13] <sabdfl> tks elmo
[07:13] <mdz> we need a security team and associated procedures
[07:14] <mdz> the folks who have volunteered are: elmo, lamont, Kamion, fabbione, daniels
[07:14] <pitti> me too
[07:14] <sabdfl> pitti
[07:14] <mdz> , pitti
[07:14] <sivang> me also
[07:14] <mdz> , sivang
[07:14] <mdz> the original list was from Oxford
[07:15] <T-Bone> if i can help, assuming there are roles i can fit in ;)
[07:15] <Keybuk> (1,492 warty patches across 459 source packages, btw)
[07:15] <mdz> so of that list, who is still interested now that the time has come for hard work? :-)
[07:15] <pitti> well, I did not know that there were so many interested people
[07:15] <Kamion> mdz: ayup
[07:15] <fabbione> mdz: yup
[07:15] <pitti> Do we actually need so many sec team members?
[07:15] <sivang> yeppers
[07:15] <mdz> pitti: no, we do not
[07:15] <lamont> mdz: mark me down
[07:15] <mdz> I think we should have two people to start
[07:15] <T-Bone> mdz: doesn't that lower the amount of work on the global team?
[07:16] <pitti> I'm interested, but not if it gets too many
[07:16] <sabdfl> with one person leading
[07:16] <mdz> T-Bone: hmm?
[07:16] <T-Bone> mdz: having several team members
[07:16] <T-Bone> (sec team)
[07:16] <Kamion> the people who've been doing security work so far should be first on the list ...
[07:16] <mdz> T-Bone: I propose two
[07:16] <lamont> T-Bone: with security,  not as much as you might think
[07:16] <T-Bone> lamont: ok
[07:16] <mdz> fabio has already been doing security work with me
[07:16] <elmo> tbh, I don't even remember volunteering, and have more than enough to do elsewhere.  so feel free to take me off the list
[07:17] <mdz> ok
[07:17] <fabbione> elmo: too late for you :P
[07:17] <lamont> mdz: how close to debian practices are you planning to be?
[07:17] <sabdfl> what about pitti leading, with t-bone?
[07:17] <elmo> mdz: do you want to use the same kind of advisory format as Debian, or shall I disable that feature?
[07:18] <sivang> I am still interested in it, and already worked with pitti ;)
[07:18] <T-Bone> sabdfl: i'd rather be "backup" than anything else. ia64 is gonna take me time i guess ;)
[07:18] <mdz> elmo: in terms of the layout of the document, or having the list of packages and sums in it?
[07:18] <sabdfl> i think it would be good to have a canonical person and someone from the community who's taking a more serious interest
[07:18] <sabdfl> i could provide a small retainer for the volunteer
[07:18] <mako> sabdfl: i think that would be ideal
[07:19] <elmo> mdz: well, just having some sort of mail advisory where it'd be useful to have amber fill in the details that she can
[07:19] <pitti> sabdfl: the most important thing is the team leader, to have sb who assures that things get done
[07:19] <mdz> sabdfl: what is the status of malone for tracking warty security issues?
[07:20] <pitti> sabdfl: he can assign tasks to members, but then the particular structure is not so important
[07:20] <sabdfl> mdz: pretty good
[07:20] <sabdfl> not for high volume work
[07:20] <sabdfl> the ui is still crufty
[07:20] <mdz> security should be a good beta
[07:20] <sabdfl> but we can assign a bug to multiple source packages
[07:20] <mdz> or alpha
[07:20] <sabdfl> yes
[07:20] <mdz> it doesn't even need to be public initially
[07:20] <sabdfl> it won't
[07:21] <sabdfl> we haven't planned the work to have hidden bugs though, so vendor-sec should be kept out of it if it's public
[07:21] <mdz> once we have a stable release to point to, I am going to petition for us to be recognized by the security community and join vendor-sec
[07:21] <sabdfl> this week we are bringing up the email interface
[07:21] <sabdfl> and also the ability to watch bugzilla
[07:21] <lamont> would also be good to join first.org at that point
[07:21] <mdz> lamont: is first relevant?
[07:22] <lamont> it's more a community visibility thing with the irt's
[07:22] <lamont> hence "good to", rather than "should"
[07:24] <amu> wow 900$
[07:25] <sabdfl> amu?
[07:25] <mdz> amu: hm?
[07:25] <fabbione> ???
[07:25] <amu> first.org
[07:25] <amu> first's membership fee
[07:25] <sabdfl> ok, we'll appoint a security team
[07:25] <sabdfl> canonical person leading
[07:25] <sabdfl> potentially a community member joining too
[07:26] <mdz> someone who is not mdz
[07:26] <sabdfl> will require a review of credentials and community council signoff
[07:26] <pitti> "credentials"?
[07:26] <thom> mdz: your hat stand full?
[07:26] <mdz> thom: it's collapsing under the weight
[07:26] <sabdfl> pitti: security is very sensitive, requires someone who we trust with our own reputation
[07:27] <lamont> mdz: get a taller one and walk up the wall??? :-)
[07:27] <sabdfl> fabbione: mdz ain't eligible
[07:27] <pitti> sabdfl: I'm still interested, but I might not have earned this after 6 weeks :-)
[07:27] <sabdfl> monica says
[07:27] <fabbione> sabdfl: but he is the one with biggest experience in it
[07:27] <sabdfl> fabbione: agreed, the security team will report to mdz
[07:28] <sabdfl> and he's setup the framework under which they operate
[07:28] <sabdfl> and mentor them
[07:28] <pitti> mdz could lead for a few weeks, then I could take over
[07:28] <mdz> the key attribute for security is meticulousness
[07:28] <mdz> both with preparing updates, and with tracking open issues
[07:28] <sabdfl> we'll figure this out amongst the group of people who've expressed an interest
[07:28] <mdz> agreed
[07:29] <sabdfl> mdz: anything else on the organisation of that team and process?
[07:29] <mdz> yes
[07:29] <mdz> we need an abbreviation for ubuntu security advisories :-)
[07:29] <mdz> USA is a major acronym collision
[07:29] <fabbione> USA :P
[07:29] <sivang> USA ?
[07:29] <sivang> :)
[07:29] <sabdfl> usec'sy thing?
[07:29] <pitti> CSA?
[07:30] <sivang> Canonical Security Advisory ?
[07:30] <mdz> USN = notification?
[07:30] <lamont> WSA? :-)
[07:30] <Keybuk> USI
[07:30] <mdz> RH uses "errata"
[07:30] <lamont> Ubuntu Security Bulletin also has issues.
[07:30] <Keybuk> heh, USE
[07:30] <mdz> lamont: yep
[07:30] <thom> USE isn't a great abreviation either
[07:30] <mako> beter than USA
[07:30] <pitti> SAU
[07:30] <pitti> nice German namecalling
[07:30] <T-Bone> USW?
[07:30] <amu> pitti: ;)
[07:31] <sabdfl> Ubuntu Security Notice?
[07:31] <mako> quick, whats the zulu word for "security advisory"
[07:31] <sivang> ahah
[07:31] <T-Bone> lol
[07:31] <sabdfl> "spear"
[07:31] <sivang> good one mako
[07:31] <mdz> ok, well, think about it, send me ideas, and we'll decide something after the meeting
[07:31] <mdz> sabdfl: hah
[07:31] <mdz> "tiger"
[07:31] <pitti> there aren't many TLAs left
[07:31] <lamont> sabdfl: that's a security response, not advisory
[07:31] <mdz> pitti: even TLA itself is overloaded
[07:31] <sabdfl> default to "ubuntu security defect notice" maybe
[07:31] <thom> Ubuntu Errata ?
[07:31] <pitti> mdz: Three Letter Acronym
[07:32] <sivang> USV
[07:32] <mdz> anyway, I'm going to set aside a day to draft some security policies and procedures
[07:32] <thom> pitti: tom lords arch
[07:32] <mdz> what we'll fix, how, why, etc.
[07:32] <pitti> thom: I know :-)
[07:32] <sabdfl> ok, anything else before we give t-bone the floor?
[07:32] <T-Bone> lol
[07:32] <sabdfl> mdz: kiss
[07:32] <sabdfl> it will evolve
[07:33] <T-Bone> hehe
[07:33] <T-Bone> so that's up to me?
[07:33] <sabdfl> t-bone, go ahead
[07:33] <T-Bone> i'll be pretty quick, for the sake of everyone
[07:34] <T-Bone> as i reported in previous mails, the IA-64 Ubuntu port was to be presented to the Gelato Council in Beijing last week
[07:34] <T-Bone> it has received a good welcome from the members, and interest was shown
[07:34] <sabdfl> with or without rc artwork? <duck>
[07:34] <mdz> gelato, sounds delicious
[07:34] <T-Bone> lol
[07:34] <T-Bone> www.gelato.org for those who don't know what this is about
[07:35] <T-Bone> several members (including people from UIUC/NCSA, HP...) have offered to help the port,
[07:35] <mdz> nice!
[07:35] <T-Bone> and Thierry Simonnet will send a report mail soon about the gelato meeting
[07:35] <fabbione> cool!
[07:35] <T-Bone> so,
[07:35] <mdz> what sort of help have they offered?
[07:36] <T-Bone> hopefully, we are close to get a bigger team than just "me" :^)
[07:36] <T-Bone> mdz: the big idea is that they might be interested in making Ubuntu the somewhat "Gelato recommended Linux distribution for IA64"
[07:37] <mdz> sounds great
[07:37] <T-Bone> mdz: so if you look at the Gelato members page, and at what Gelato is about (IA64 Linux use for massive calculus computing, roughly put),
[07:37] <T-Bone> you'll find out that it will obviously involve "make Ubuntu the best IA-64 distribution" on the TODO list ;)
[07:37] <T-Bone> and that should also be a good thing for Ubuntu as a whole
[07:38] <sabdfl> yes, i'm excited at this
[07:38] <T-Bone> that sounded like to good news to me, so I thought it was worth letting you guys know about it ;)
[07:38] <fabbione> T-Bone: really nice :-9
[07:39] <thom> T-Bone: very cool, thanks for your efforts in getting us to the attention of the gelato folk
[07:39] <lamont> as for the port efforts, T-Bone has been spinlocked on my time
[07:39] <T-Bone> paticipation from the members will probably involve development taks force, material, and stuff like that, but i'll leave the details of the report to Thierry
[07:39] <T-Bone> lamont: yeah, got a bit swamped last week
[07:39] <T-Bone> so, to get back to the port status
[07:40] <T-Bone> I was a bit quick in my announcement of the end of the stage1
[07:40] <T-Bone> actually, we a have a "stage1" ubuntu archive locally
[07:40] <T-Bone> a b0rken one ;)
[07:40] <lamont> and my list includes trying to reproduce the error locally
[07:40] <T-Bone> it seems that there was some trouble in the packaging of some pieces of software (involving overlapping files)
[07:40] <T-Bone> nothing really bad, but it introduced unexpected delays
[07:41] <sabdfl> we have ordered some ia64 machine. elmo what's the eta on those?
[07:41] <T-Bone> the next tasks are: 1) solving this packaging mess so that we can get to stage2; and 2) work on the IA64 installer
[07:41] <elmo> sabdfl: they're here - I plan to install them tomorrow/thursday
[07:41] <elmo> that's why I'm leaving for London as soon as this meeting's over ;-)
[07:42] <lamont> weeehoooo!
[07:42] <T-Bone> sabdfl: wow! That's great news ;^)))
[07:42] <sabdfl> you're both welcome
[07:42] <lamont> elmo: woody for now, I assume?
[07:42] <T-Bone> actually 1) and 2) could be done in parallel, but as i'm not yet ubiquous, i have to serialize
[07:42] <elmo> lamont: yep
[07:43] <elmo> lamont: unless you have something for me to upgrade to ?
[07:43] <Kamion> w00t
[07:43] <lamont> elmo: once I get warty/main built.  not until
[07:43] <T-Bone> i will most likely need help of d-i gurus (Kamion?) for 2)
[07:43] <elmo> lamont: k
[07:43] <Kamion> T-Bone: happy to give you time post-warty
[07:43] <T-Bone> lamont: if you are ok with dpkg --force-overwrite, i have a working warty archive
[07:43] <T-Bone> ;)
[07:43] <lamont> feh
[07:44] <Kamion> T-Bone: (which also means I'll have somewhere to upload source to ...)
[07:44] <T-Bone> Kamion: ok
[07:44] <sabdfl> elmo: we got 4 boxen, right?
[07:44] <elmo> sabdfl: yeah, 3 buildd, one port
[07:44] <T-Bone> Kamion: if you need access to the ia64 boxes i have, i can easily arrange that
[07:44] <mdz> wow
[07:44] <sabdfl> 3 buildd's and a porting box
[07:44] <Kamion> can we commit (in upload-stuff-to-the-archive terms) to ia64 in hoary?
[07:44] <fabbione> gra
[07:44] <fabbione> geart
[07:44] <elmo> btw, what are we going to do about the ia64 and warty?  add it to the archive?
[07:44] <fabbione> AMEN
[07:44] <mdz> don't we have only 2xbuildd for existing architectures?
[07:44] <fabbione> great!
[07:45] <thom> mdz: 3 for existing
[07:45] <sabdfl> elmo: no, not the official one
[07:45] <elmo> sabdfl: ok
[07:45] <Kamion> T-Bone: serial console / netboot access would be ideal if possible
[07:45] <sabdfl> mdz: 3
[07:45] <mdz> ah
[07:45] <elmo> mdz: 3 for amd64, powerpc, 5 for i386
[07:45] <lamont> mdz: i386 currently has 3, ppc 3, amd64 2
[07:45] <T-Bone> Kamion: that can be easily setup, i'll arrange that with you later
[07:45] <Kamion> T-Bone: the sort of setup joeyh has where he can drop in a new image and reboot remotely would rock. :)
[07:45] <lamont> mdz: running buildd, that is.
[07:45] <sabdfl> we should get porting boxes for ppc and amd64
[07:45] <Kamion> joeyh has an ia64 box crash-testing d-i out of cron
[07:45] <T-Bone> Kamion: ok, that shouldn't be an issue
[07:46] <elmo> sabdfl: ok, will do
[07:46] <sabdfl> elmo: great, thanks
[07:47] <sabdfl> t-bone, anything we can do for you now?
[07:47] <T-Bone> any other questions about IA64?
[07:47] <sabdfl> i'm clear
[07:47] <T-Bone> sabdfl: giving me time, providing technical help, find me a job? :^)
[07:47] <sabdfl> no word back from jdub, and i think we can assume we won't hear from him till his monring
[07:47] <sabdfl> in that order? seems reasonable :-)
[07:47] <mdz> sabdfl: so should we roll a build with the current stuff?
[07:47] <T-Bone> sabdfl: lol
[07:48] <mdz> or wait?
[07:48] <sabdfl> mdz: no, let's get *something* of the new artwork in
[07:48] <T-Bone> expect report mail from Thierry by tomorrow noon CEST
[07:48] <mdz> sabdfl: what do we have, and where is it?
[07:48] <fabbione> T-Bone: where are you located?
[07:48] <sabdfl> in my homedir on chinstrap is a wartythemes.tgz which has human and humansimple
[07:48] <sabdfl> that's for the gdm theme
[07:48] <sabdfl> the human one will have to be renamed back to Human and Human.xml so that existing installations don't break
[07:49] <sabdfl> jdub was going to do this last night
[07:49] <sabdfl> so unfortunately we may be repeating work he's done and not published
[07:49] <sabdfl> also, jdub published initial ubuntu-calendar packages
[07:49] <sabdfl> keybuk, did you chat to him about those?
[07:49] <T-Bone> fabbione: i'm in Paris
[07:50] <Keybuk> the ones he forwarded me the other day looked ok
[07:50] <Keybuk> structure-wise anyway
[07:50] <fabbione> T-Bone: oh ok :-)
[07:50] <sabdfl> ok, let's get those in
[07:50] <sabdfl> they will definitely need a tweak for descirptions and his other changes
[07:50] <Keybuk> but the content was just temporary
[07:50] <sabdfl> mdz: it's your call whether to roll a build now
[07:50] <mdz> sabdfl: the calendar stuff is not going on the CD, correct?
[07:50] <sabdfl> mdz: no
[07:51] <mdz> so we basically need the gdm theme and the gnome splash
[07:51] <mdz> i.e., a new rev of ubuntu-artwork
[07:51] <Keybuk> no it's not, or no it is?
[07:51] <sabdfl> no it's not going on the cd
[07:51] <Kamion> #include <english-sucks.h>
[07:51] <fabbione> ok guys.. i am off for today
[07:51] <sabdfl> Kamion: no
[07:51] <Keybuk> mdz: make it ubuntu-artwork_4.10
[07:51] <sabdfl> :-)
[07:51] <fabbione> cya tomorrow and thanks!
[07:51] <Kamion> :)
[07:51] <sabdfl> -0.1
[07:52] <sabdfl> so final can be -1
[07:52] <T-Bone> am i clear to go? I have a dinner outside, and i'm already late ;^)
[07:52] <Kamion> that's always a risky game :)
[07:52] <mdz> sabdfl: are we replacing the existing gdm theme + gnomesplash, or renaming them?
[07:52] <sabdfl> mdz: the humansimple one has to become Human
[07:53] <sabdfl> because existing gm installations will be looking for /usr/share/gdm/themes/Human/Human.xml
[07:53] <mdz> what will we name the current one?
[07:53] <sabdfl> and we want them all to become the one that is humansimple in that
[07:53] <sabdfl> HumanCircle
[07:53] <mdz> humancomplex?
[07:53] <amu> lamont: /usr/share/pixmaps/splash/
[07:53] <mdz> ah
[07:53] <sabdfl> Circle of Friends is in the description
[07:53] <mdz> who can take care of the ubuntu-artwork update?
[07:54] <Keybuk> if I've got the artwork, I can do that
[07:54] <mdz> Keybuk: it's on chinstrap
[07:54] <lamont> hrm.. what's the image viewer in main?
[07:54] <sabdfl> eog
[07:55] <mdz> lamont: testing warty-live-i386.iso
[07:55] <mdz> 688,748,544 bytes
[07:55] <sabdfl> isn't that too big?
[07:55] <mdz> yes
[07:55] <mdz> thaht's 656M
[07:55] <dieman_> iiiiinteresting.  gdm sucked in their own Xsession file now
[07:55] <amu> lamont: gnome-splash.png is default gnome,  ubuntu-splash.png it should be
[07:55] <dieman_> thats what 700MB cdrs are for :)
[07:55] <mako> is this after ttf-baekmuk was cut?
[07:55] <mdz> lamont: do you have a newer one?
[07:56] <mdz> I think this was supposed to be +ttf-baekmuk -celestia
[07:56] <lamont> 20041019-03/warty-live-i386.iso should be what is on cdimage...
[07:56] <mako> right
[07:56] <dieman_> heh, missed the board meeting, hmmm
[07:56] <lamont> 20041019-18 is +ttf-baekmuk -celestia
[07:56] <mdz> lamont: can you name the files with version numbers in them, please?
[07:56] <lamont> certainly
[07:56] <Keybuk> sabdfl: "human" becomes "HumanCircle" and "humansimple" becomes "Human", yes?
[07:56] <mako> koreans rejoice
[07:56] <sabdfl> mako, will you post the transcript somewhere for dieman_ and other?
[07:56] <mdz> lamont: so there is a newer build to be tested, but it isn't on cdimage yet?
[07:56] <sabdfl> Keybuk: yes
[07:57] <sabdfl> jdub had additional tweaks planned, but that was the main thing
[07:57] <mako> sabdfl: a summary or the full transcript?
[07:57] <mako> i'll do the transcript now
[07:57] <Keybuk> sabdfl: leaving the Name=Human (Simple) and Name=Human Circle of Friends ?
[07:57] <sabdfl> mako: full transcript. have you been doing summaries of tb / cc meetings?
[07:58] <mdz> lamont: my sound devices are still reversed
[07:58] <sabdfl> Keybuk: i'd prefer something better than human (Simple) but i'm out of entropy :-)(
[07:58] <mako> sabdfl: i have not yet done a TB summary.. i'm one meting behind on CC meetings but i'm also behind on traffic in general due to the shipping stuff taking priority
[07:58] <dieman_> sabdfl: ive got scrollback like ma
[07:58] <dieman_> sabdfl: mad
[07:58] <mdz> lamont: indeed, it seems very much the same experience as the last one
[07:59] <sabdfl> mako: summary of tb would be very useful but i understand shipit take precedence now
[07:59] <sabdfl> mdz: would you consider an rc of the live cd tomorrow, rather than a final release?
[07:59] <mdz> sabdfl: I'd much rather go out all at once
[08:00] <mdz> what's the hard deadline for shipit?
[08:00] <sabdfl> ok, your call
[08:00] <sabdfl> silbs?
[08:00] <mako> sabdfl: i think it will be reasonable once i can fall back into a routine.. i think all community/technical governnace meetings really need to be summarized
[08:00] <silbs> db frozen today.  No hard deadline but every day delay past tomorrow = day delay in shipping.
[08:00] <sabdfl> mako: agreed
[08:00] <sabdfl> hold on, i think we're going to see a ton of shipit requests when the announcement goes out
[08:00] <mdz> I think the live CD can be there for tomorrow
[08:01] <mdz> sabdfl: agreed
[08:01] <mdz> we should let those queue up a bit
[08:01] <silbs> sorry - frozen in terms of first 170K orders. Will collect new orders, do second batch
[08:01] <sabdfl> ok
[08:01] <lamont> mdz: that's the latest kernel on alextreme.org
[08:01] <mako> plan is to wait until post announcement to finalize the second batch :)
[08:01] <silbs> already requests outnumber cds
[08:02] <mdz> ok, can we close the meeting and take the rest of this to other channels?
[08:02] <sabdfl> done
[08:02] <mdz> ok, thanks everyone
[08:02] <sabdfl> i'd like to say something though
[08:02] <sabdfl> mdz, you and your team have done a fantastic job on warty
[08:02] <sabdfl> far exceeded our Easter expectations
[08:02] <sabdfl> and set a hell of pace for every other distro
[08:02] <sabdfl> thank you
[08:02] <mako> amen
[08:02] <mdz> thanks
[08:03] <mdz> the community response has been very encouraging; I think we're doing the right things
[08:03] <sabdfl> Kamion, fabbione, thom, the whole team have been exceptional
[08:03] <sivang> amen to that , mdz the man :)
[08:03] <sabdfl> yes, i think this will be a shared load for hoary
[08:03] <sabdfl> and that has it's own coordination issues :)
[08:03] <sabdfl> anyhow, well done
[08:03] <sabdfl> looking forward to the reviews
[08:04] <mdz> indeed
[08:04] <pitti> amu: hopefully www.heise.de finally writes about it
[08:04] <sabdfl> cheers everyone
[08:04] <pitti> oh, another thing
[08:04] <amu> pitti: should be no problem ;)
[08:04] <pitti> will it be possible in any way to have a bunch of CDs here in GErmany before Oct 30th?
[08:05] <pitti> I will be at a Linux fair and like to distribute some CDs :-)
[08:05] <silbs> pitti: will be very close. Can't promise but we are keeping "high priority" list for immediate shipment. Send details to Mako.
[08:05] <silbs> pitt: must have commercial mailing address
[08:05] <pitti> silbs: oh, I don't have
[08:06] <pitti> silbs: it's not that crucial, though
[08:06] <amu> pitti: you'll go to Dresden ?
[08:06] <pitti> the thing is, if it is not possible to get them by the 30th, I don't really need them
[08:06] <pitti> amu: I live in Dresden :-)
[08:06] <pitti> http://2004.linuxinfotag.de/
[08:07] <mako> pitti: coordinate with me if you want to try :)
[08:07] <pitti> silbs: I did not order them before because sb told me that the CDs can't be shipped before mid November
[08:07] <pitti> mako: okay
[08:07] <pitti> mako: shall I add an extra item in shipit?
[08:07] <mako> pitti: if you want to order them now it's not too late
[08:07] <mako> pitti: 1 hour it might be :)
[08:08] <pitti> mako: shipit or mail?
[08:08] <mako> pitti: i am finalizing the db output scripts now :)
[08:08] <mako> pitti: shipit
[08:08] <mako> pitti: then too me what address you did it under, irc is fine
[08:09] <pitti> mako: so I just raise my 10 personal CDs to 110 :-)
[08:10] <mako> pitti: right :)
[08:10] <pitti> mako: done<EMAIL_ADDRESS>[08:10] <mako> pitti: sounds good
[08:10] <pitti> this information day is a nice opportunity to promote and distribute Ubuntu
[08:11] <amu> pitti: hehe, i think you'll meet peter_e there, just say a hi from me ;)
[08:11] <pitti> I'll be there and can show off on my laptop
[08:11] <pitti> amu: I know him, I was his application manager :-)
[08:11] <pitti> amu: and we already agreed to meet
[08:11] <pitti> amu: I'll forward your greetings
[08:12] <amu> pitti: ;) cool
[08:12] <Keybuk> sabdfl: do the calendar images need to be removed from this ubuntu-artwork package?
[08:13] <sivang> ahh...don't take the calander images down...;)
[08:16] <Keybuk> sivang: is ending up in another package
[08:17] <sivang> Keybuk : ok..
[08:23] <sabdfl> Keybuk: erm.. YES!
[08:23] <Keybuk> ok, then I got it right :p


[02:16] <ToyKeeper> D'oh.  'adb wait-for-device' doesn't work any more.  :(
[02:17] <ToyKeeper> Actually, I suppose it's just that adb as a whole doesn't work any more.  :(
[02:17] <ToyKeeper> (until logging in and activating developer mode, which kind of invalidates tests when I need to have a silo installed at setup wizard time)
[02:18] <ToyKeeper> Maybe I missed a mailing list post.
[03:05] <imgbot> [04:25] <imgbot> [04:25] <imgbot> [10:14] <ogra_> ToyKeeper, you want --developer-mode and --password= for ubuntu-device-flash, then it will let you in on boot
[10:22] <ToyKeeper> Ah, okay.  I didn't have the --password= bit.  :)
[11:06] <nik90> ogra_: how do I do the developer mode stuff for the emulator?
[11:06] <nik90> ogra_: I enabled it in the emulator image, but it still is recognized by qtcreator.
[11:07] <nik90> s/is/isn't
[14:40] <ogra_> nik90, --developer-mode iirc it sets the default password to 0000 ... also make sure ot use the latest devel-proposed, that has all the fixes
[14:40] <ogra_> rtm doesnt yet
[14:41] <nik90> ogra_: I did that, although the latest emulator devel-proposed is 237 while on phone it is 239
[14:43] <ogra_> plars, manta should work again in devel-proposed, i also added the lightdm bits so you should be able to drop teh workarounds, note that due to some weird issue neither mako nor krillin are buillt at all though
[14:44] <ogra_> nik90, thats expected, numbers are not related to each other at  all anymore
[14:50] <nik90> ogra_: ok, then I am not sure what's wrong. Atm the emulator opens up. I got to the system-settings-app and confirm that the developer mode is enabled. After which I also notice that I need to enter 0000 to unlock the emulator. However qtcreator still says that the emulator is loading and not detecting that it has been loaded.
[14:51] <nik90> ogra_: funny thing is I was sticking to devel images until this developer mode stuff settled down a bit. But then I think the click package updated and now I cannot run apps on the devel emulator as well.
[14:51] <nik90> ogra_: so kinda forced to run on phone which isn't ideal for 3rd party app devs who don't have a phone


[11:53] <icey> slyon: your recent upload for python-pbr breaks; the package is no longer installable: `update-alternatives: error: alternative path /usr/bin/python3-pbr doesn't exist`; it works fine on 5.5.1-0ubuntu1 but breaks on 5.5.1-0ubuntu2
[11:54] <utkarsh2102> icey: hey, slyon is aware and -ubuntu3 is already upload and waiting on AA to process the removal of -ubuntu2 upload.
[11:54] <utkarsh2102> basically, the fix is on its way :)
[11:55] <icey> utkarsh2102: ack thanks :) I was wondering why my uploads yesterday built fine for me but then broke up launchpad :-P
[11:56] <utkarsh2102> icey: heh, yeah, we're having this sorted in #ubuntu-release, in case you're interested/
[12:06] <icey> thanks for the pointer utkarsh2102 - always fun to watch :-D
[12:06] <icey> now it's just a waiting game :)
[12:06] <utkarsh2102> yep!
[17:15] <PaulePanter> Hi. On Ubuntun 18.04 (Bionic Beaver), there is a package linux-image-kvm depending on linux-image-4.15.0-1008-kvm, but that has files from 2018.
[17:15] <PaulePanter> What is the correct package for QEMU/KVM?
[17:16] <PaulePanter> linux-image-virtual?
[17:17] <PaulePanter> Also not it: -rw------- 1 root root  8249080 Apr 24  2018 vmlinuz-4.15.0-20-generic
[17:17] <sdeziel> PaulePanter: linux-image-virtual should work well
[17:18] <sdeziel> PaulePanter: have you run 'apt update' recently?
[17:18] <sdeziel> PaulePanter: https://packages.ubuntu.com/bionic-updates/linux-image-virtual shows <IP_ADDRESS>.131
[17:20] <PaulePanter> I guess, I am missing bionic-updates in my sources.list.
[17:20] <PaulePanter> sdeziel: Sorry for the noise.
[17:20] <sdeziel> PaulePanter: even -security should have it though
[17:21] <PaulePanter> I didn’t have that either.
[17:22] <PaulePanter> Tried to manually install Ubuntu into a VM using adapted grml-debootstrap, which only supports Debian until now. I forgot about these separate lines.
[17:22] <PaulePanter> What’s the add-apt-repository chant for that?
[17:24] <PaulePanter> apt-add-repository 'deb https://debian.charite.de/ubuntu bionic-updates main' would also do that.
[17:26] <tomreyn> PaulePanter: grep -o '^ *[^#]*' /etc/apt/sources.list      on an 18.04 system i have here: https://termbin.com/ygt8
[17:27] <tomreyn> that's a desktop, but shouldn't matter. backports would normally be disabled.
[17:27] <PaulePanter> tomreyn: Thank you. I’ll pick the appropriate ones from these.
[17:28] <tomreyn> you're welcome
[20:01] <PaulePanter> Hi. The package *procps* seems to make some assumptions, which are not true for *linux-image-kvm* for example, causing `systemd-sysctl.service` to fail.
[20:01] <PaulePanter> https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1931630
[20:25] <sdeziel> I'm not sure why that -kvm flavor was built without CONFIG_MAGIC_SYSRQ contrary to other flavors
[20:35] <stgraber> sdeziel: we've seen a LOT of kernel config issues with -kvm, 99% of the time, it's just human error, some change falling through the cracks
[20:35] <stgraber> sdeziel: feel free to file a bug against linux-kvm asking for it to be aligned with -generic, that's what I've done every time I've hit one of those
[20:36] <stgraber> (efi, nft, netfilter and a couple more configs were also misaligned with generic causing some issues in the past)
[20:37] <sdeziel> yeah, that matches my very short experience with this flavor
[20:37] <sdeziel> PaulePanter: you might want to move the bug to linux-kvm asking for it to be aligned with the other flavors
[20:55] <Phibs> anyone know what the benefit of using the 'aws' named kernels on EC2 vs say just regular 5.8 ?
[22:07] <bigpod> Phibs: i think the named kernels are optimised for the specific providers and might even include some stuff that otherwise might not be available in general use kernel
[22:07] <Phibs> nod
[22:07] <Phibs> just curious