[00:17] <lotuspsychje> good morning
[00:26] <M_aD> morning
[00:26] <lotuspsychje> hey there M_aD
[00:26] <M_aD> lotuspsychje: hey
[00:27] <oerheks> :-)
[00:27] <M_aD> you're up early
[00:27] <M_aD> oerheks: hey :)
[00:28] <lotuspsychje> how do you know my timezone M_aD
[00:29] <M_aD> your hostmask shows BE so
[00:29] <lotuspsychje> ohh sneaky lil user eh :p
[00:29] <M_aD> i'm located in Belgium too
[00:29] <lotuspsychje> oh really
[00:29] <M_aD> yep
[00:29] <lotuspsychje> where from
[00:30] <oerheks> Haarlem here.. oh that is NL
[00:30] <M_aD> living not that far from the Dutch border, Maaseik
[00:30] <M_aD> night off from work so trying to relax a bit
[00:30] <lotuspsychje> aha bruges here
[00:31] <M_aD> :)
[00:31] <lotuspsychje> lol oerheks
[01:01] <oerheks> "The file https://github.com/...dataengineering-test.pem possibly contains a ssh private key"  grinn
[01:02] <oerheks> this is not the only github :-D
[01:02] <oerheks> man o man
[01:03] <oerheks> https://twitter.com/leak_scavenger
[01:03] <lotuspsychje> gits are nice tools, but things that used a lot often target of malicious too
[01:04] <lotuspsychje> and it doesnt help, if the user helps the attacker neither :p
[06:15] <ducasse> good morning
[11:55] <amuro> Hi, what is the difference between the telegram-cli in apt and snap?
[11:56] <jeremy31> the snap version is likely newer
[11:56] <jeremy31> will likely take more space
[11:56] <amuro> I installed telegram-cli with snap, but I got this error: bash: /usr/bin/telegram-cli: No such file or directory
[11:56] <amuro> What do I do?
[11:58] <jeremy31> I don't know, not a telegram user
[11:59] <lotuspsychje> amuro: for snap issues, we advice to contact the maintainer, in your case<EMAIL_ADDRESS>[12:09] <amuro> Oh I got it, its snap run telegram-cli
[12:09] <amuro> Sorry, I am new to snap
[12:45] <jeremy31> I wonder how much help freemangordon will get from filing a bug, the module was already modified when the kernel oops came
[12:46] <lotuspsychje> think i missed that support myself jeremy31
[12:46] <lotuspsychje> what was it about exactly
[12:47] <jeremy31> It happened in #ubuntu-kernel
[12:47] <lotuspsychje> ah
[12:48] <jeremy31> with 5.3 kernel, I doubt it will see many changes since it should be EOL soon
[13:09] <tomreyn> jeremy31: oh i hadn't looked that closely. well, yet another expiring bug report then ;)
[13:10] <tomreyn> seems to have filed it as bug 1888128
[13:13] <jeremy31> I see unsigned ath modules
[13:18] <jeremy31> My guess is that they needed to patch ath so that it would work with some of the iwlwifi backport modules
[14:03] <M_aD> morning
[14:03] <M_aD> what was ubuntu based on again... Debian Testing?
[14:12] <jeremy31> Buster/Sid at one time
[15:10] <marcoagpinto> heya
[15:10] <marcoagpinto> >:)
[15:13] <marcoagpinto> I am the demon!
[15:17] <M_aD> pssst.... kindergarten is elsewhere ;)
[15:45] <marcoagpinto> what?!
[15:46] <marcoagpinto> I am the cola demon!
[15:46] <marcoagpinto> :)
[15:49] <daftykins> yeah marcoagpinto doesn't need #ubuntu right now ;)
[15:51] <marcoagpinto> I only know Thunderbird 78 is live and I can't upgrade because it doesn't implement 100% OpenPGP... I will have to wait for 78.2 :)
[15:51] <marcoagpinto> maybe two months
[16:00] <M_aD> that's what -offtopic is for isn't it daftykins? I'm still trying to adjust and get used to all the different channels that we didn't have years ago. Plus i recently returned home to Ubuntu. :)
[16:01] <daftykins> M_aD: it was really a way of remarking on the trolls that frequent freenode support channels :D
[16:01] <daftykins> -offtopic is a cesspit that should be avoided by one and all
[16:16] <jeremy31> I have seen places worse than -offtopic
[16:17] <daftykins> well i didn't realise it was a competition ;)
[16:32] <jeremy31> offtopic is safe for children at most hours


[01:39] <pitux> hello
[01:39] <pitux> any person speak spanish???
[01:39] <pitux> mi english is very bad, sorry
[01:43] <pitux> there are thought a mail list of edubuntu in spanish????
[02:39] <mpt> d'oh
[02:41] <ogra> mpt, ?
[02:49] <mpt> oh, just that I didn't see pitux in time, that's all
[03:55] <mpt_> ogra: Let me know when would be a good time to do the tweaks to the gnome-screensaver unlock dialog (sometime between 10 and 14 hours from now, or between 19 and 22 hours from now, would be ideal)
[03:55] <mpt_> otherwise I could just put a mockup on the wiki
[03:57] <ogra> or mail it :)
[04:05] <mpt_> ok :-)
[04:10] <ogra> i must admit that i havent even looked into the code yet, we dropped gnome-screensaver more than a month ago
[04:10] <ogra> (around UVF)
[07:44] <highvoltage> ogra: i did the rsync, but my md5sum doesn't match the one on the website, is it because my file is called "breezy", and the new one is called edubuntu?
[07:45] <shaga> good morning all
[07:45] <highvoltage> morning shaga
[07:48] <shaga> are there still any good enough flash/java-plugins for amd64 platforum? can you tell straight out?
[07:49] <highvoltage> i don't know.
[07:54] <shaga> okay, I'll find out about it myself once I'm through here in work
[08:02] <highvoltage> okay, it's probably supposed to match these md5sums, but it doesn't either: http://cdimage.ubuntu.com/cdimage/edubuntu/daily/current/MD5SUMS
[08:16] <Burgundavia> shaga, for amd64, there is no Macromedia flash plugin. There are 2 free versions, GPLflash and swfdec (LGPL). Neither work well enough to be replacements for flash
[08:16] <Burgundavia> shaga, as for java, the free java stuff has not produced a web plugin due to not yet having done the security stuff
[08:17] <shaga> okay, thanks very much.. so I'll stick with the x86-version for now still..
[08:20] <shaga> this is not about linux at all(still I'm trying to do this in linux, but it's not the point), but you might know about this. is it possible to go 'back' with firefox without refreshing the page? opera can do that but I just don't support it. ff is quite evil as it does the refresh and jumps on the top of the list you were browsing for example..
[08:21] <shaga> I'm trying to google about as I speak
[08:21] <Burgundavia> shaga, currently not implemented
[08:21] <Burgundavia> FF 1.5 will do that
[08:21] <shaga> as I thought
[08:50] <highvoltage> ogra: yay, my md5 sums match
[09:45] <shaga> could you briefly tell me whats LTSP? should I use "workstation" on a CD boot prompt for my own computer which I use just for fun and have a direct connection to web through dhcp..
[09:50] <Burgundavia> shaga, ltsp allows thin clients to connect to a central server. The thin clients don't do any of the heavy lifting
[09:51] <shaga> oh, that means I should use "workstation" on a prompt for my use
[10:17] <magnon> morning
[10:18] <shaga> good morning
[11:36] <highvoltage> ogra: i got a debconf screen telling me about how the ip address have been set in a preseed file, and that i need to file a bug if i see this dialog. is this a bug?
[01:31] <spacey> JaneW, just booked my flight to canada :>
[01:36] <ogra> spacey, yay !
[01:36] <spacey> :)
[01:44] <ogra> hey jinty  :)
[01:44] <jinty> should we move over here?
[01:44] <ogra> yup
[01:45] <ogra> currently i have some other (packaging) bugs to solve with moodle first...
[01:45] <jinty> as far as one of the moodle developers told me, moodle can authenticate off a web pace
[01:45] <ogra> ah...
[01:45] <jinty> s/pace/page
[01:46] <ogra> the problem is, that i want to leave it up to the user to make the moodle configuration, i only create a blank database and moodle has a 3 step webinterface to create the structure in there
[01:46] <jinty> basically post a form and grep the return HTML (ugh!)
[01:46] <jinty> ok no worries, just passing info along which might be usefull
[01:46] <ogra> i'll investigate if i can set defaults for that interface that point to the schooltool auth
[01:47] <ogra> jinty, i'll come back to you about that, be sure :)
[01:47] <ogra> just let me fix the essential bugs first :)
[01:47] <jinty> he;) I understand
[01:48] <ogra> sabdfl decided yesterday that we want to go with gnome-screensaver, so now i have to fix that one first ... wasnt planned :)
[01:48] <ogra> heh
[01:49] <jinty> how much time to release
[01:49] <ogra> oct 13th
[01:49] <ogra> 4 weeks
[01:49] <jinty> ouch
[01:50] <jinty> good luck then
[01:50] <ogra> its in good condition already, i just have to split out all the screensavers from xscreensaver to make them available for gnome-screensaver
[01:51] <ogra> will you be at UBZ ?
[01:51] <jinty> depends if I am sponsored or not
[01:51] <jinty> though I havn't asked
[01:52] <jinty> but it could be really usefull for me.
[01:52] <ogra> yes, as well as for me...
[01:52] <ogra> since i build a distro around your baby :)
[01:52] <JaneW> spacey: cool
[01:52] <spacey> :)
[01:55] <jinty> ogra: hope you don't do too much building on, as the recent changes in the schooltool unstable branch are, er, extreeme
[01:56] <ogra> jinty, currently we just want to show it to the world... since we target only one classroom for now, its perfect as a scheduling tool :)
[01:57] <spacey> bbl!
[02:16] <jinty> ogra: I am busy building new schooltool packages. Don't you want to send the patch?
[02:18] <ogra> jinty, is during the day enough ?
[02:19] <jinty> perhaps, doko really wants these new packages
[02:21] <ogra> ok, give me 1h
[02:48] <ogra> jinty, mail sent :)
[02:49] <jinty> thanks!, I'll get it in.
[02:57] <JaneW> er how the hell does flint have post right to Ubuntu Announce and I don't?...
[02:58] <ogra> JaneW, nobody has
[02:58] <ogra> JaneW, all posts to announce are moderated
[02:58] <JaneW> but howcome flints message went through and mine didn't :(
[02:59] <ogra> poke jdub :)
[03:03] <JaneW> ogra: omg... read this...
[03:03] <JaneW> At an Edubuntu Summit in July in Australia, educators from every continent came together. Reports from the summit indicate that Edubuntu will soon be found in hundreds of schools across Europe from Sweden to Spain -- in the state of Andalusia the government has chosen Ubuntu Linux for its schools, libraries and all public facilities. In Brazil, Elkner says, more than a million pupils will be using Edubuntu.
[03:04] <ogra> phew
[03:04] <ogra> but any press is good press ;)
[03:05] <JaneW> flint and elkner are like 'pinky and the brain'
[03:05] <ogra> even if its a bit strange what he tells
[03:05] <JaneW> 'What are we going to do tongiht Brain?'
[03:05] <JaneW> 'Same thing we do everynight Pinky....
[03:05] <JaneW> Try to take over the WORLD!'
[03:05] <ogra> hehe
[03:16] <jinty> :)
[03:28] <doko> do I have to know pinky?
[03:29] <doko> hmm, s/pinky/flint/
[03:29] <ogra> doko, nope
[03:29] <ogra> but i'm pretty sure you'll meet him at UBZ
[03:58] <JaneW> ogra: oh yes!
[03:58] <JaneW> doko: he's hard to miss ;)
[03:58] <ogra> hehe
[03:59] <ogra> yes, he takes over every room he is in
[03:59] <ogra> and not only because he's big
[04:05] <highvoltage> JaneW: hi there
[04:05] <JaneW> hello highvoltage
[04:07] <highvoltage> JaneW: get my private messages?
[04:25] <bip> hello ...
[04:26] <bip> is anybody involved with ltsp deployement here ?
[04:32] <jinty> doko: ping (deb-src ftp://<IP_ADDRESS>/pub/schooltool/archives/debian sid main)
[04:32] <jinty> for a new schoolbell package
[04:34] <jinty> could you sponsor it to sid? (needs dpkg-buildpackage options -sa -v1.2.0-2)
[04:45] <doko> jinty: thanks
[04:46] <jinty> schooltool is still coming
[04:49] <doko> jinty: the source still contains the Zope3 source?
[04:49] <jinty> yes, the tarball contains it, but it is not used at all by the packages
[04:50] <jinty> removing it from the tarball was too much of a step for upstream
[04:51] <doko> ok
[04:51] <jinty> see the dirty hack in rules
[04:55] <shaga> oh, seems that it's already time for a beer
[05:04] <JaneW> yep, that's what I am about to do... bye
[05:04] <JaneW> *wave*
[05:09] <shaga> *waves back*
[05:31] <mpt> ogra: Is uninstalling xscreensaver the easiest way of using gnome-screensaver?
[05:32] <ogra> mpt, sorry, the package has an error... just testbuilding the fixed version
[05:32] <ogra> but you should uninstall xscreensaver anyway... and install gnome-screensaver and xscreensaver-data
[05:34] <mpt> ok, ta
[05:43] <mpt> ... and then what? :-)
[05:44] <ogra> then logout and in again to make sure gnome-screensaver is in your session
[05:44] <ogra> now all should work..
[05:45] <mpt> wahaa
[05:45] <ogra> ?
[05:47] <mpt> The "New updates available" balloon appears on top of the screensaver
[05:47] <ogra> yup
[05:47] <mpt> Is that reported?
[05:47] <ogra> i think thats an X error
[05:48] <ogra> yup, there is a bug anywhere for xscreensaver, since it also happens in gnome-screensaver id think its rather X
[05:48] <mpt> a bug somewhere?
[05:48] <ogra> i have to look it up
[05:49] <mpt> sorry, I just wasn't sure whether you meant "there is a bug filed somewhere" or "there isn't a bug filed anywhere"
[05:49] <mpt> English sucks
[05:50] <mpt> if you know it's already reported, then never mind, I won't report it :-)
[05:50] <jsgotangco> JaneW_we: we?
[05:51] <ogra> jsgotangco, she's out...
[05:51] <gand> hello
[05:51] <ogra> mpt, hmm, i cant find the bug...
[05:51] <jsgotangco> ogra: dude, people over here are hyped over edubuntu
[05:51] <jsgotangco> my last presentation was jam packed
[05:52] <ogra> mpt, http://bugzilla.ubuntu.com/show_bug.cgi?id=14944
[05:52] <mpt> thanks ogra
[05:52] <jsgotangco> ogra: i actually won an RHCE training and exam voucher
[05:53] <ogra> WOW
[05:53] <jsgotangco> yeah i was like WTF
[05:54] <jsgotangco> i have till december to use it =)
[05:54] <ogra> cool
[05:55] <jsgotangco> ogra: people love our theme
[05:55] <gand> I've read edubuntu program list with  "Istanbul" (screen session recorder) listed. May I suggest instead "xvidcap" that have also audio recording?
[05:55] <ogra> gand, we have neither in this release and istanbul will have audion in our next one :)
[05:57] <gand> I mean that xvidcap record video and audio in the same time, so you can create a screen tutorial with audio in it
[05:58] <ogra> gand, you will be able to do that with istanbul too, but without using the commandline
[06:00] <gand> Will istanbul have a GUI and audio recording too? (gvidcap has a GUI too) Sorry I'm not update on istanbul.
[06:02] <gand> By the moment Istambul has no audio, will it have audio on next release? I'm looking desperately a screen recorder tool
[06:02] <ogra> istanbul just adds a red button to your notification area, you click it once, it becomes a play button and records your session, you click a second time and the movie appears on your desktop. the author is working on audion recording, it will be ready for dapper (our next release) i think
[06:03] <ogra> gand, gvidcap and xvidcap are in universe you can always install them
[06:03] <gand> nice thank, http://www.freesmug.org/idojo/
[06:03] <gand> yes but I'm on PPC
[06:04] <gand> I've compiled last release of xvidcap from source yesterday, but there are still some problems
[06:05] <gand> I've used "wink" for some screentutorial, but wink is not freesoftware :(
[06:06] <jinty> doko: I have to patch and re-build schoolbell to fix a problem running the schooltool build time tests. Probably by monday.
[06:08] <jinty> still have to do my food money work...
[06:11] <doko> jinty: is there anything I can do?
[06:14] <jinty> the issue is that the schoolbell setup.py does not install the tests/ftests sub-modules by default
[06:15] <jinty> no, I dont think there is much you can do
[06:15] <doko> ok, so installing them by hand should work?
[06:16] <jinty> personally I would just patch setup.py
[06:18] <jinty> actually, I'll give it a try today
[06:18] <jinty> by hand?
[06:21] <doko> just use cp in the rules file
[06:22] <jinty> already made the patch:)
[06:23] <jinty> now to put it upstream
[06:25] <gand> I've dowloaded instanbul source, how can I compile it on PPC, readme is empty!
[06:27] <ogra> err, its in univers, you only need to install it
[06:27] <ogra> universe even
[06:28] <gand> not in PCC universe :(
[06:30] <ogra> oh,m i was assiming you run edubuntu breezy, in hoary it isnt there...
[06:31] <jsgotangco> istanbul is awesome
[06:31] <ogra> yup
[06:32] <gand> is instambul in edubuntu breezy PPC?
[06:32] <ogra> sure
[06:36] <gand> Only install, no live, I've to clear my hoary :)
[06:36] <ogra> just change your sources.list
[06:37] <ogra> after the upgrade install edubuntu-desktop and you got a edubuntu workstation install
[06:39] <gand> sorry, how can I change my sourc.list?
[06:43] <gand>  I just have to add APT line to the repository?
[06:43] <ogra> just change all occurences of hoary to breezy
[06:43] <ogra> then run apt-get update
[06:44] <ogra> then apt-get dist-upgrade
[06:46] <gand> thank, I'm using synaptic package manager, no breezy occurences listed, how can I change currences from hoary to breezy
[06:48] <ogra> you can change the repositorys in the settings menu of synaptic...
[06:49] <gand> Yes I know, I can add a custom repos.; which APT line I've to add?
[06:50] <gand> or also editing file: etc/apt/sources.list
[06:50] <ogra> you dont add anything, edit the ones that are there
[06:50] <ogra> either one
[06:50] <ogra> its the same, synaptic is just the gui fo it...
[06:54] <gand> Sorry but I've only 5.04 repos. listed, no 5.10 listed in the "add" window.
[06:54] <ogra> edit the 5.04 repos
[06:57] <gand> I've to substitute "hoary" word with "breezy" ?
[06:58] <ogra> yes :)
[06:58] <ogra> that makes it a 5.10 repo
[06:59] <gand> thank :)
[07:36] <jinty> doko: ping
[07:37] <doko> pong
[07:38] <jinty> in the reproitory i mentioned earlier there are new schooltool and schoolbell packages
[07:38] <jinty> probably schoolbell needs the same dpkg opts, buit I'm not sure
[07:39] <jinty> I guess I leave it to you from here. But could you ping me as soon as they hit ubuntu?
[07:40] <doko> will do, thanks a lot!
[07:40] <jinty> there is an out of tree schooltool dependency (cando) I need to update then
[07:41] <jinty> ah yes, schooltool -> sid would be nice;)
[07:43] <doko> ? cando ?
[07:44] <jinty> yeah, a grade tracking system built on schooltool;)
[07:45] <jinty> still have to file an ITP
[07:46] <doko> dpkg-genchanges: warning: missing Section for source files
[07:47] <doko> schooltool
[07:47] <doko> just added that to the control file
[07:49] <jinty> which section?
[08:44] <gand> thanks bye, have to reboot.


[00:10] <psusi> does anyone know of a decent software design spec/overview for libata?
[01:20] <Sebboh> Hi.  I'm using the guide at https://help.ubuntu.com/community/Kernel/Compile .  I'm building on a PowerPC, I've got the Maverick kernel source via git, and I've modified a source file to get around a won't-fix bug for powerpc.  I haven't done this in a while, and last time I did was on Debian.  I'd use make menuconfig to build a .config.. About halfway through that guide, it says to execute "AUTOBUILD=1 fakeroot debian/rules binary-debs".
[01:25] <Sebboh> Also, this guide refers to a few things that don't exist in this source tree, like "To build one of the custom flavours (found in debian/binary-custom.d/), use: ..."  There is no such directory.  Did that stuff move somewhere else?
[01:28] <Sebboh> Oh, a better example: "If you just want to update one architecture, run: debian/scripts/misc/oldconfig ARCH"...  No such file.  But I really want to do that.  How?
[01:36] <Sebboh> debian/rules editconfigs didn't prompt me for powerpc.  I'm just trying random things here.. :P
[03:40] <Sebboh> ok, forget my previous question..
[03:40] <Sebboh> How can I use my own .config for a kernel build?  I'm following this guide: https://help.ubuntu.com/community/Kernel/Compile .. Whenever I put a .config in the kernel source root, the build process complains that I should run make mrproper. I've read that this means there are extra files, great.  How do I shove my .config into this new debian.master/config flavour system?
[10:08] <jussi> right, Im trying to find someone I met at UDS - I left a bottle of salmiakki with him...
[10:15] <amitk> jussi: riku?
[10:15] <jussi> amitk: no, I think his name was Lee - was the saturday night :=)
[10:15] <amitk> lag: ^
[14:36] <lag> Hi jussi
[14:37] <lag> What can I do for you?
[15:13] <smoser> smb, around ?
[15:13] <smb> smoser, masybe 25% (currently sitting in talks at LPC)
[15:14] <smoser> i'm wondering if you woudl think that bug 667656 is a dupe of bug 567334 and/or bug 666211
[15:14] <ubot2> Launchpad bug 667656 in linux (Ubuntu) "soft-crash: task flush blocked for more than 120 seconds (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/667656
[15:14] <ubot2> Launchpad bug 567334 in linux (Ubuntu) (and 1 other project) "blocked tasks delay cloud-init for 240 seconds (affects: 2) (heat: 33)" [Medium,Triaged] https://launchpad.net/bugs/567334
[15:14] <ubot2> Launchpad bug 666211 in linux (Ubuntu) "maverick on ec2 64bit ext4 deadlock (affects: 3) (heat: 26)" [High,Confirmed] https://launchpad.net/bugs/666211
[15:14] <smoser> or if its just symtoms (the blocked tasks that are the same)
[15:15] <smb> smoser, blocked tasks would at least be different to the boot crash I guess
[15:15] <smb> Depends on whether there is a crash visible
[15:15] <smb> For some time, and I am not sure what kernels where used for the task blocked cases, there
[15:15] <smb> was some chance that this was related to poor writeback performance
[15:16] <smb> smoser, If possible we should get reconfirmation with the latest kernel currently in proposed (for Lucid)
[15:17] <smoser> ok. so i'll leave them un-duped for the moment.  bug 667656 is the only one with a actual crash.
[15:17] <ubot2> Launchpad bug 667656 in linux (Ubuntu) "soft-crash: task flush blocked for more than 120 seconds (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/667656
[15:17] <smoser> none of those are lucid, smb
[15:17] <smb> Ok, so at least there should be not that critical writeback problems in Maverick
[15:18] <smb> smoser, jj just started a SRU for the intel_idle option to be disabled
[15:18] <smoser> some people are suspecting that its ext4 related, which could be why you'd see them on maverick but not lucid.
[15:18] <smoser> maverick ec2 images have ext4, lucid have ext3
[15:18] <smoser> smoser, in the -virtual kernel ?
[15:19] <smb> One might do ext3 to compare, but I would need to check on the tracebacks of the task blocked bugs to say more
[15:19] <smb> and that likely will not be before next week
[15:23] <smoser> smb, so what do you think about the random kernel message timestamps ?
[15:24] <smoser> ie, apparent time travel both forward and backward by months at a time
[15:29] <smb> smoser, It would be interesting to know what clocksource is used in those cases (should be somewhere in /sys/devices/system/clocksource). So could be a bad timer there or something related to c-states handling.
[15:29] <smb> But as said, being at a conference I won't spend too much time to think on those things now
[15:29] <smoser> smb, fair enough. thanks for your time, htough.
[15:43] <komputes> Can a kernel engineer please have a look at Bug #670181 ?
[15:43] <ubot2> Launchpad bug 670181 in linux (Ubuntu) "Dell Precision M6300 SD Card Reader (Ricoh R5C592 memory stick) Will Not Mount After Upgrade To 10.10 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/670181
[16:06] <tgardner> apw, you gonna push natty?
[16:13] <smb> tgardner, He may when he stops looking disgusted
[16:29] <simar> Hey anybody have idea of progress in this very old issue. Should I forward it upstream
[16:30] <simar> Bug #372090
[16:30] <ubot2> Launchpad bug 372090 in linux (Ubuntu) "AlpsPS/2 ALPS GlidePoint gets stuck and is generally unresponsive. (affects: 4) (dups: 1) (heat: 28)" [Low,Confirmed] https://launchpad.net/bugs/372090
[16:58] <robtow> Has anyone gotten Ubuntu 10.10, kernel 2.6.35-22-generic to work with a Dell e6510 WITHOUT an Nvidia card? I can boot 10.10 with kernel 2.6.31-22-generic; but 2.6.25-22-generic gives the message: "22.2344991 Intel ips 0000:00:1f.6: failed to get i915 symbols, graphics turbo disabled" - then it boots, but with no X. Adding nomodeset to boot params doesn't help.
[17:04] <apw> tgardner, all pushed and uploaded
[18:56] <sconklin> Sarvatt: you about?
[19:36] <bullgard4> '$ sudo make menuconfig' > Linux Kernel v. <IP_ADDRESS>+drm33.7 Configuration > i915 driver > Enable modesetting on intel by default. Where can I find a not too short introductory article about "modesetting"?
[19:54] <tgardner> apw, armel build broke when you re-enabled CONFIG_GPIO_PCH when merging the ports config.
[19:54] <apw> tgardner, no it broke when the patch you applied after the one which disabled it, reenabled it
[19:54] <apw> but that isn't your fault, something screwey is going on
[19:55] <apw> i am trying to turn it off, and it won't stay turned off right now
[19:55] <tgardner> hmm, I thought it got tuned on in 'UBUNTU: [Config] move powerpc over from ports to distro'
[19:55] <tgardner> glp


[04:40] <shawn1> Hello
[04:41] <shawn1> I've been trying to get my GTX 295 and GTX 460 SE to work on my system, but my system seems to be able to detect only half of the GTX 295
[04:41] <shawn1> most times, my xserver won't even start up
[04:41] <shawn1> I've contacted NVIDIA about this issue and have worked with them and they said that it's a kernel problem
[04:41] <ohsix> using noveau?
[04:42] <shawn1> proprietary
[04:42] <ohsix> so the detection of the second card was said to have been a kernel problem
[04:42] <shawn1> yeah
[04:42] <shawn1> because lspci was only showing half of it
[04:42] <shawn1> in the kernel log
[04:43] <ohsix> did they give you any references or just say that it's a kernel problem because of lspci
[04:43] <shawn1> I think it was trying to detect something on the address and it was trying to detect frequencies of 2,142 or up and if it's referring to memory frequency, the GTX 295 is just below 2Ghz
[04:43] <shawn1> uhm
[04:43] <shawn1> m
[06:14] <shadows> I've got a POSIX programming puzzle that I'm trying to work out for Linux, has to do with termios and signals...  what's the appropriate channel to discuss?
[06:15] <shadows> hint it's not school work ;  I have two programs and one of them returns from select() when I access a pseudo terminal, the other does not ;  I can see no clear difference in what each program is actually doing
[06:25] <shadows> oh...  one of the programs *sets* errno
[06:25]  * shadows facepalms
[15:45] <ralphcor> I'm on 10.10 so manually purging old kernels doesn't do a dkms clean-up.  I'd like to know the correct way of doing so.  https://answers.launchpad.net/ubuntu/+source/dkms/+question/185568 hasn't really helped and Google knows little.  I thought a Launchpad Answer might help others Googling in future.
[18:11] <anon^_^> Hi, sorry to bother chan, I was curious if the linux power regression was ever dealt with through a kernel SRU for 11.04 and 11.10
[18:11] <anon^_^> http://www.phoronix.com/scan.php?page=article&item=linux_aspm_solution&num=1


[00:26] <krytarik> Uh oh, just noticed we didn't do a translation sync/upload for the docs.
[03:17] <bluesabre> :(
[10:02] <Unit193> slickymasterWork: That new Core I promised is up, btw.
[10:10] <slickymasterWork> great Unit193, thanks
[10:11] <slickymasterWork> will download it tonight and will report back
[10:11] <slickymasterWork> the download url is the same, right Unit193
[10:11] <slickymasterWork> ?
[10:14] <Unit193> Yep.
[10:14] <slickymasterWork> oki doke
[10:15] <Unit193> base-files is up, looks like I should re-do them, then. :P
[16:44] <willcooke> flocculant, ack
[16:45] <flocculant> :)
[16:46] <flocculant> always a welcome sight :D
[18:47] <flocculant> bluesabre: I've copied pad note stuff to the wiki rn
[18:48] <flocculant> still got stuff to do there below though
[18:56] <flocculant> ochosi: what you want to say about the 'sometime' double network dooby?
[18:59] <flocculant> somnething sort of 'yea we know, not had time to deal with that, you can restart network, panel or plugin to resest if you wish, though it is only an appearance issue at this point'
[19:28] <ochosi> flocculant: yeah that sounds about right :>
[19:28] <flocculant> ochosi: ok - I'll tart it up a bit though :D
[19:28] <flocculant> I'll change yea to Yes :p
[19:28] <ochosi> hehe, i had hoped so
[19:28] <ochosi> :'D
[19:29] <flocculant> is it some sort of race condition?
[19:30] <flocculant> I thought I remembered bluesabre saying 'yea that's going to be great to fix :(' a while back?
[19:31] <ochosi> yeah, i'd classify it as a race condition
[19:31] <flocculant> ok - will sort somethign for the rn soon :)
[19:36] <flocculant> ochosi: I guess I should report that so we've got something to remember in bb :)
[19:37] <ochosi> hehe
[19:37] <knome> flocculant is signing up for the next big brother season?
[19:37] <knome> with ochosi?
[19:37] <knome> :P
[19:37] <knome> that'd be something to see
[19:38] <flocculant> ochosi: Currently at times the panel could show 2 network icons, this appears to be a race condition which we have not been able to rectify in time for release. While this is an appearance issue only as far as we know, you can if you wish restart networking, the affected plugin or the panel. This does not however stop the issue from re-appearing.
[19:39] <ochosi> suggestion "This fixes the issue in your running session but does not prevent the issue from re-appearing."
[19:39] <flocculant> knome: I assume you've got the wordy release announcement all in hand
[19:39] <knome> of course... not
[19:39] <flocculant> ochosi: ack - that sounds better
[19:40] <flocculant> knome: :D
[19:40] <knome> i guess i should work on it "someday" :P
[19:40] <flocculant> :)
[19:40] <knome> ideally before thursday
[19:40] <flocculant> someone should - it won't be me this cycle -- last full week in current job, with the new driver following me around
[19:41] <knome> i should have time on thursday but i'd rather not count on that :P
[19:41] <flocculant> ochosi: what to report this against though?
[19:42] <ochosi> that's the problem, it's not really clear
[19:42] <flocculant> ochosi: :) ok - then I'll just add something to one of the bp's
[19:45] <ochosi> yeah, makes sense so we don't forget
[19:45] <flocculant> ok - added to rn so it's not forgotten this week


[00:25] <tsimonq2> chrisccoulson: Hi there! Any chance you could take a look at fixing bug 1715213 and bug 1715214 for the next uploads? (There's patches that exist and are already in openSUSE, they just need reviewing and cherry picking)
[09:04] <xnox> doko, done, eventually. need to check if that built or not
[09:04]  * xnox ponders if networking is broken at fosdem, or ubuntu bionic is.
[16:32] <FauxDEM> Networking is pretty terrible.
[16:32] <FauxDEM> Very long wait for a DHCP lease, very high latency network in most places.


[07:52] <Bashing-om> 'nuf is enough ..... good Nite good folks
[14:41] <pauljw> Hi everyone
[14:43] <BluesKaj> Hi pauljw
[14:44] <pauljw> hey BluesKaj :)
[16:16] <nicomachus> https://turnoff.us/image/en/dont-share-mutable-state.png
[20:34] <Bashing-om> OK, ready to have fun now . devestation may follow .
[21:01] <nicomachus> that's the best kind of fun
[21:04] <Bashing-om> Uh Huh, and the best part of it .. ubuntu .. always fixable - given time. effort and want to . ( Lord I hope that hard drive has not failed - afraid to look !)
[21:04] <nicomachus> somewhat random: the Linux Foundation is offering 50% training and certification in a bunch of areas for Ubuntu users: http://insights.ubuntu.com/2016/12/15/get-50-off-linux-foundation-training-and-certification/
[21:06] <Bashing-om> Looks like a push is on to get some accredited people in the industry .
[21:12] <nicomachus> we need 'em
[21:12] <Ben64> neat
[21:13] <nicomachus> sent it to my dad, too. He's a network engineer. I think he gets most of his certs through Cisco and Red Hat though.
[21:17] <Ben64> i need to find a linux job
[21:18] <Ben64> everything ive seen lately wants AD


[14:54] <TheBiggerGuycom> Hi, is there anyone who can help me with https://bugs.launchpad.net/upstart/+bug/637172
[15:19] <bvleur> Hi. I'm wondering why a script with "start on started ssh" can launch processes with a lower pid than "sshd"
[15:21] <ashb> bvleur: because pids are fairly random
[15:21] <ashb> and the sshd might well fork
[15:23] <bvleur> okay. fair enough. I've created a script that runs autossh with remote forward to localhost:22. It seems that running it before sshd is up makes the forward fail, so I want to make sure they start in order. PIDs don't tell me the boot order then right?
[19:31] <yaaang> is it possible to use upstart (init, start, etc) as non-root?
[19:32] <yaaang> would like to daemonize & manage processes without requiring root; supervisord seems to fit the bill but i was wondering if i should also take a deeper look at upstart
[19:36] <JanC> yaaang: why not use sudo to manage who can start/stop/etc. system daemons without needing to give them general root access?
[19:37] <yaaang> JanC: that can also restrict to starting/stopping specific services?
[19:38] <JanC> yaaang: yes, see the sudoers manpage for examples
[19:39] <JanC> you can restrict people to specific commands including parameters etc.
[19:40] <JanC> plus, with sudo every time they use this, it will be logged
[19:46] <ion> A future release of Upstart will handle users’ jobs as well.
[19:46] <yaaang> JanC: how does a non-root user add/remove jobs?
[19:47] <yaaang> ion: ah, i see
[19:49] <JanC> you could create a script to add a new job and allow users to use that script with sudo, but of course that has serious security implications
[19:49] <yaaang> JanC: right
[19:50] <JanC> I suppose it wouldn't too difficult to create a system-wide upstart job that looks for user-specific job files though
[19:51] <yaaang> maybe even easier than that is the supervisord route - just let users run their own process management daemons
[19:53] <JanC> I don't know supervisord, but probably it could be that upstart-job  ;)
[19:54] <JanC> at least until upstart grows these features itself


[00:25] <spiv> Morning.
[00:40] <poolie> hi there spiv
[02:28] <jeremyw> jam: ping
[03:07] <poolie> maxb: hi, still here?
[07:11] <maxb> poolie: at 3am my time? unlikely :-)
[07:48] <poolie> hi maxb
[07:48] <poolie> i wasn't sure what tz you were in
[08:14] <poolie> maxb, oops, i also had you confused with mkanat
[08:39] <poolie> vila, so, regarding releases
[08:39] <poolie> perhaps we can try to get more clear on what we desire
[08:40] <poolie> high on my list is not wasting time on the release process itself
[08:40]  * vila nods
[08:40] <poolie> which is not to say that all release-type work is a waste; clearly it is useful, but any costs that don't gain an incremental benefit are a waste
[08:41] <poolie> and that's got two parts: wasted actual labor, and also unnecessary delay
[08:41] <vila> agreed
[08:42] <poolie> on the other hand, we don't want to waste our users' time and attention by telling them about something that they can't actually install
[08:42] <poolie> which in practice means its very good for binaries for various platforms to be available when it comes out
[08:42] <vila> yup, that's why I want to change the process a bit so we can ensure we will successfully build the installers the day we announce the source freeze
[08:43] <poolie> that would be good
[08:43] <poolie> i guess really the ideal is to _automatically_ build them as a consequence of deciding to release
[08:43] <poolie> but that seems a bit elusive
[08:43] <vila> for naming reasons, we can't build them *before* freezing, but we can prepare for that and avoid last minute fixes
[08:44] <vila> we are almost there for OSX minus 10.5 machine availability
[08:44] <vila> well, I have one, but I plan to upgrade it to 10.6 soon
[08:45] <vila> we made some significant progress on the windows front too with more people setting up their own environment, but there are still some glitches
[08:46] <vila> thanks to maxb things are also clearer on the debian and Ubuntu fronts but still not fully automated (well as fully as possible, there will always be some manual steps
[08:46] <vila> )
[08:46] <poolie> so what broke in 2.3b1? i haven't read all my mail from the weekend
[08:47] <vila> well, AIUI, for some users, a dll is missing and abort the installation
[08:47] <vila> both GaryvdM and mgz have been hammering on it but I think we still haven't a fix
[08:48] <vila> the number of affected users is also unclear
[08:49] <vila> I'm very tempted to *not* announce 2.3b1 (knowing that ~600 downloads have already occurred so people are testing it anyway) and focus on 2.3b2
[08:49] <vila> OR
[08:49] <vila> announce it with with a warning about this dll bug
[08:50] <poolie> ah, this one
[08:50] <poolie> i think the second is strictly better than the first, isn't it?
[08:50] <vila> 2.3b2 is planned for 2010-10-08 aka next Friday, we can change that to 2010-10-14 instead
[08:50] <poolie> the only down side perhaps being that people may see too many announcements
[08:51] <vila> yup
[08:51] <poolie> we should make sure we have something clear explaining the different series
[08:51] <vila> it's also why I didn't announce 2.0.6 and 2.1.3 on the assumption that the targeted population may be too small
[08:52] <poolie> mm
[08:52] <vila> which in turn raise the question about *how* we should package them (or not)
[08:52] <poolie> i think we should try to do SRUs for them,
[08:52] <poolie> but only if that can be done at a reasonably low cost
[08:52] <vila> for OSX and windows where we (collectively) package more than just bzr-core, it makes sense to focus on 2.2 and 2.3 only
[08:54] <vila> there is bug #525571 for 2.1.3
[08:54] <vila> and bug #582656 for 2.0.6
[08:55] <vila> I don't expect much until maverick is out
[08:56] <vila> oh, and for 2.2.1, based on a  discussion with maxb, I'm preparing a report about test failures differences between 2.2.0, 2.2.1 and 2.2.2 (not yet released :)
[08:58] <vila> which I interrupted yesterday evening, but roughly 2.2.0 and 2.2.1 have the exact same failures but more tests are run for 2.2.1
[09:00] <vila> I still need to check that we have no more failures with 2.2.2 which is a bit more involved as the env is different (running from the installed version as root is required and I encounter some failures I wasn't aware of)
[09:00] <vila> I thought we got them all..
[09:03] <poolie> bug 582656 is worth fixing in old distros
[09:04] <poolie> 525571 is a bit less so, i think, because it probably only comes up with bzr-svn and that's not so hot in karmic
[09:05] <maxb> poolie: Is there anything in 2.0.6 that's important enough to make it worth bothering with SRUing into a release that's only got 7 months to run to EOL anyway?
[09:05] <vila> poolie: indeed, but it seems that SRUs are a more heavy process than ppas... so for Ubuntu we already have an answer which is: use our last stable, 2.2
[09:05] <vila> which kind of converge with the OSX and windows philosophy
[09:06] <poolie> i think SRUs _ought_ to become quite lightweight
[09:06] <poolie> with the microrelease exception etc
[09:06] <poolie> and with maxb's help too
[09:07] <poolie> for 2.0.6 perhaps we should see if anyone actually cares to ask on the bug
[09:07] <vila> yup, I'm proposing to avoid them, just mentioning an alternative
[09:07] <vila> eeeerk
[09:07] <vila> yup, I'm *NOT* proposing to avoid them, just mentioning an alternative
[09:09] <poolie> to avoid what?
[09:09] <vila> SRUs
[09:09] <poolie> ok
[09:11] <vila> maxb: It would be nice if you could make a mail summary about the packaging branches status and what you think about the current process (including debian of course)
[09:11] <poolie> so perhaps for old series, which at the moment means only karmic
[09:11] <poolie> we should just wait for someone to ask for the sru
[09:12] <vila> to trigger 2.0.7 you mean ? Or already for 2.0.6 ?
[09:14] <poolie> but for newer ones, where we care more about pushing the update, i think SRUs are better than packaging them ourselves
[09:14] <poolie> and they should converge more
[09:14] <poolie> maxb asked if it was worth SRUing 2.0.6 and i'm not convinced that there is
[09:19] <vila> well, I'm convinced we can build with no test failures for 2.2 (and of course 2.3) and comply with the MRE rules, but for 2.0 and 2.1, SRUs are still needed, we can wait a couple of weeks for maverick activity to settle a bit and see what ~ubuntu-sru do
[09:20] <poolie> that works for me
[09:20] <poolie> with regard to the betas, i think we should stick with, and stick more closely to, the plan that we will give a limited window to build installers
[09:20] <poolie> and after that announce without them
[09:21] <poolie> but perhaps you should post about this to the list and we can see if people object
[09:21] <vila> yup, I will do that
[09:24] <vila> oh and we haven't bump the 2.3 API yet
[09:26] <poolie> we should do that
[09:26] <vila> poolie: oh, and about releasing from *trunk*, both you and jam mentioned it but it isn't described in releasing.txt (which I followed closely hence the 2.3 pqm branch)
[09:26] <vila> so I think I understand what it means
[09:27] <vila> which is creating the tarball from trunk and create the pqm branch only when... when what ? First RC ? True 2.3.0 ?
[09:28] <vila> in the mean time I will probably just ask a losa to pull --overwrite the pqm branch so no harm has been done
[09:29] <maxb> ooi, why do we have a release structure that requires losa intervention all the time?
[09:29] <vila> maxb: only when we create a new series
[09:29] <maxb> it's still oddly inefficient
[09:31] <poolie> it is
[09:31] <poolie> it would be good to fix that
[09:31] <poolie> it's oddly... distrustful of developers
[09:31] <poolie> which might be a reasonable setup for archive builds
[09:31] <poolie> but in this case seems strange
[09:32] <poolie> i'm glad we enforce test suite checks but i'm not sure it needs to be quite so harsh
[09:32] <poolie> we can reconsider this when we prototype tarmac
[09:32] <maxb> Compared with, say, renaming the ~bzr-pqm user to ~bzr-pqm-daemon, creating a ~bzr-pqm team, renaming the branches back, and adding the ~bzr-pqm-daemon and trusted devs to ~bzr-pqm
[09:32] <poolie> mm
[09:32] <poolie> i don't think that will be quite enough
[09:32] <vila> maxb: that won't give us access to the pqm instance
[09:33] <poolie> because pqm itself needs to be told about the new branches
[09:33] <maxb> oh, I see
[09:33] <poolie> but that's just kind of a bug in pqm, which tarmac may either fix or make tractable
[10:59] <lxsameer_> hi does bazaar allow to clone just a subdirectory under the main repo , and not the whole repo
[11:19] <jelmer> sidnei: Nice blog post, interesting read!
[11:20] <jelmer> lxsameer_: no, it doesn't support partial checkouts.
[11:20] <jelmer> lxsameer_: there are some design docs about it but it hasn't yet been implemented.
[11:20] <lxsameer_> jelmer, is it a DVCS that can do this ?
[11:20] <jelmer> lxsameer_: none of the bigger ones can
[11:21] <lxsameer_> jelmer, :( thanks
[11:22] <Kamping_Kaiser> jelmer: you can do lightweight but not partial, is that correct?
[11:23] <jelmer> Kamping_Kaiser: yep
[11:25] <Kamping_Kaiser> jelmer: thanks for confirming :)
[11:59] <uffiole> hi. Is it fine to rename the main project folder ?
[12:34] <Glenjamin> uffiole: generally, yes
[12:34] <Glenjamin> although you might get related branches trying to point to it, which obviously wont work anymore
[12:43] <Glenjamin> is there any way to undo an update?
[13:00] <uffiole> ok thx , found out it works
[13:00] <uffiole> cu
[13:11] <vila> Glenjamin: It depends on whether you had uncommitted changes or not
[13:11] <vila> before doing the update
[14:05] <codingrobot> how can i go back to a revision nummber X? bzr update -r X and bzr revert -r X doesn't seem to do the job. bzr revno shows the latest rev. number
[14:08] <GaryvdM> codingrobot: update changes the basis tree, so it will show in qlog (not sure how to see this with cli)
[14:09] <GaryvdM> codingrobot: revert leaves the basis tree, so bzr status shows what changes it has made.
[14:11] <codingrobot> what?! i just want to get rid of the changes made in the previous 2 commits
[14:12] <GaryvdM> codingrobot: bzr revert -r -3 ; bzr commit -m "Revert xxxx"
[14:14] <codingrobot> and what is with bzr revno? should i ignore the output?
[14:15] <GaryvdM> codingrobot:  the revno will only increment after you commit.
[14:16] <codingrobot> ok
[14:17] <GaryvdM> revert -r X does not commit the revert, it only modifies  the working tree.
[14:18] <codingrobot> yes, thats how every other scm tool does it, but the revision nr. gets reverted too. thats what confused me a bit.
[14:52] <jam> jeremyw: morning
[14:52] <jam> hi vila
[15:14] <jam> james_w: if you're around, I'd be happy to chat about the merge stuff. I'm writing up another email. It looks like you are inherently criss-cross by the nature of what has happened
[15:15] <james_w> hi jam
[15:15] <james_w> that's quite possible
[15:17] <jam> james_w: just sent
[15:17] <jam> let me know when you get it, since I'd like to chat and refer to those graphs
[15:24] <maxb> james_w: Quick question for you: what do you think about an option for udd import-scripts which downloads source packages into a persistent BASE_DIR/downloads/PACKAGENAME/ instead of the transient BASE_DIR/updates/PACKAGENAME/ directory? It would be helpful for people testing on less-than-amazing internet connections.
[15:25] <james_w> jam: read it
[15:25] <james_w> maxb: I would be fine with that
[15:25] <jam> james_w: so, the next step that I can think of, is trying to figure out if we can fake a common base.
[15:26] <maxb> Great, MP will follow this evening, then
[15:26] <james_w> maxb: great, thanks
[15:26] <james_w> maxb: and I'll review your others today, sorry for the delay
[15:26] <james_w> jam: the "fake" you can do to get to the ideal case you refer to in the email is what we are currently doing as I understand it
[15:27] <jam> james_w: not from what you've said earlier, the issue is that the 3.0-1 import needs to be based on the fake 2.1-1 import
[15:28] <maxb> james_w: No problem, you've amazed me by reviewing part of my initial batch before I'd finished submitting all of them :-)
[15:28] <james_w> heh
[15:29] <james_w> jam: in these cases we don't have A-B-C, or at least those cases weren't the terrible behaviours that led me to this originally
[15:30] <james_w> we have B and C as two descendants of A, and the first thing we do is create a new revision that has B and C as parents, and the contents of whichever is later
[15:30] <jam> sure
[15:30] <jam> but I'm missing the other bits
[15:32] <gmpff> Hi.
[15:32] <gmpff> I'm struggling with a corrupted bzr repo. Any suggestions for where I start reading ?
[15:32] <gmpff> MD5 hashes of one of the pack don't match.
[15:32] <gmpff> s/pack/pack files/
[15:33] <james_w> jam: thanks for your analysis though, it's pretty clear that we can never have a simple merge now
[15:34] <jam> james_w: an open question is whether we can get convergence after another merge
[15:34] <james_w> jam: my immediate concern was getting rid of the "you're in an intermediate state, and you have conflicts you need to resolve, but I can't really tell you where they came from, and I might ask you to solve the same ones again in a minute"
[15:34] <jam> honestly, --weave or a per-file 3-way merge would probably handle the "ask you to solve them again in a minute"
[15:34] <jam> but "where they came from" ?
[15:34] <jam> how does that occur
[15:35] <james_w> because that's a terrible user experience, but if doing the merge the other way leads to "worse" conflicts in the end then that might not be the best idea
[15:35] <james_w> it's more just a phrasing thing in the UI
[15:36] <james_w> it currently says: ('The upstream branches for the merge source and target have '
[15:36] <james_w>             'diverged. Unfortunately, the attempt to fix this problem '
[15:36] <james_w>             'resulted in conflicts. Please resolve these, commit and '
[15:36] <james_w>             're-run the "merge-package" command to finish. '
[15:36] <james_w>             'Alternatively, until you commit you can use "bzr revert" to '
[15:36] <james_w>             'restore the state of the unmerged branch.')
[15:38] <jam> well, it may give you more *honest* conflicts
[15:39] <jam> which is a whole lot better than artificial ones
[15:41] <james_w> yeah
[15:42] <james_w> the main issue is that resolving twice is outside the normal workflow, so it's not comfortable for people, and we describe the problem really badly which doesn't help
[15:43] <james_w> the second issue is that you can end up having to resolve the same conflicts when you do the final merge as you just resolved in that intermediate step, which is frustrating, and leaves people feeling that they did something wrong
[15:59] <jam> james_w: I honestly wonder if you wouldn't find a big advantage to supporting "--weave" as the merge type
[16:00] <james_w> jam: I'm trying to find an example so we can have a go
[16:05] <Glenjamin> vila: yeah, it did.
[16:05] <Glenjamin> I did bzr up, then got conflicts, and wanted to reverse that action
[16:31] <jeremyw> jam: So I've created a very simple repository browser for bzr.   How does it differ from loggerhead?
[16:56] <jam> jeremyw: good to hear, congrats
[16:57]  * GaryvdM waves at jam.
[16:58] <jeremyw> I'm not trying to compete with loggerhead, and the UI is really minimal right now.  I'm writing a tool that needs a VCS agnostic repository browser so I'm writing one.
[16:58] <jeremyw> Let me get you a screenshot.
[17:15] <jeremyw> http://i56.tinypic.com/20urgap.png
[17:15] <jeremyw> That's the root view of the bzr.dev branch.
[17:16] <jeremyw> Very minimal but it does work.  Clicking a file shows contents while clicking a dir drills into that dir.  You can even specify a revno to browse a particular revision.
[17:16] <jeremyw> It was done in a few hours so there isn't much effort into it.
[17:17] <GaryvdM> That's cool.
[17:17] <jeremyw> Eventually, you'd have a nicer UI and more features but for now, I'm going simple to flesh out my ideas.
[17:18] <GaryvdM> Clicking on NEWS probably works, unlike loggerhead..  (/me ducks and runs....)
[17:19] <jeremyw> It's like a frickin' rabbit hole though man.  You get something working and you realize the N things that need to be fixed/added.
[17:19] <jeremyw> Single person teams suck.
[17:20] <GaryvdM> Yhea - I known the feeling.
[17:21] <GaryvdM> Would it not be possible to reuse bits of loggerhead?
[17:24] <jeremyw> Maybe but the idea is to have a VCS agnostic repository browser.
[17:28] <maxb> I have difficulty believing that such a thing is the right way to go. Different VCSes have different peculiarities which need browsing differently
[17:30] <jeremyw> I can see the concern but my plan isn't to have the most feature-rich repository browser, although I'm not sure why I couldn't.  It's about providing a common UI and common features across different VCSes where applicable.
[17:30] <jelmer> maxb: well, loggerhead works against svn, hg and git too :-)
[17:30] <jeremyw> I didnt' know that.
[17:30] <jeremyw> Hmm...
[17:31] <jeremyw> And the real driver behind this is that the repository browser is only a small feature in the overall application.
[17:31] <jeremyw> We'll see.
[17:31] <jelmer> jeremyw: if it's blazingly fast then that's a big benefit over loggerhead though :-)
[17:32] <jeremyw> This really is fast, but I'm not doing as much as loggerhead just yet.  I mean, this is the first working piece.  haha
[17:33] <jeremyw> I think the speed right now is in the simplicity.
[17:34] <jelmer> I don't think loggerhead can really justify its overhead though, it's not that advanced.
[17:39] <jelmer> jeremyw: oh, I should clarify. loggerhead supports git, hg and svn because bzrlib does; it doesn't really have support for anything than bzrlib itself.
[17:39] <jeremyw> jelmer: I got you.  Thanks for the clarification.  :)
[18:46] <jam> james_w: thanks for the brltty link, though looking at it, it just seems like a regular conflicts to me. Specifically, ubuntu was at 4.0-8ubuntu1, but debian had a 4.0-9 before the 4.1-1 stuff. (though 4.0-9 looks a whole lot like the 4.0-8ubuntu1 changes +/- some stuff which is what causes the conflicts)
[18:48] <james_w> right, but you saw the extra step of resolving conflicts?
[18:48] <jam> I did see that merge-package dumps out with a conflict of some sort
[18:48] <jam> is it meant that "upstream tags are new, and upgrading the upstream causes conflicts" ?
[18:49] <jam> in this case, though, why did it need to do the extra merging upstream step?
[18:49] <jam> upstream-4.0 is the direct parent of upstream-4.1
[18:50] <james_w> take a look at the revision graph, it's more complex than that
[18:50] <james_w> the "pristine" branches of the Debian and Ubuntu are diverged
[18:51] <jam> ok, I see that now. but what is "import upstream version 4.0" if not "tag:upstream-4.0"
[18:51] <jam> or put another way
[18:51] <jam> why is there a "Import upstream version 4.0" which *isn't* the upstream-4.0 tag, but the "upstream-4.1" tag is based upon *it* and not "upstream-4.0" ?
[18:52] <jam> though I note that there are *tons* of differences between "Import upstream version 4.0" and what is tagged "upstream-4.0"
[18:52] <james_w> there are two "import upstream version 4.0" revisions, one of which has a slightly misleading commit message, as it isn't really an import, but a "merge" of the existing import in the other distro
[18:53] <jam> so the one that is tagged is the merge of the existing import?
[18:54] <jam> (as far as UI goes, why not just tell the user the tags involved? 'upstream-4.1 conflicted while merging into upstream-4.0', please try to resolve), however even once resolved, how is that communicated to future code?
[18:56] <jam> (or maybe it doesn't as I do see 2 "Prepared upstream tree for merging into target branch" messages)
[20:15] <bialix> C-S: ping
[20:25] <bialix> hmmm, I'm not really sure is it bug? with bzr 2.2.0: `bzr branch lp:bzr-explorer-website` sets parent branch as: bzr+ssh://bazaar.launchpad.net/%2Bbranch/bzr-explorer-website/
[20:25] <bialix> at least it weird
[20:30] <maxb> bialix: It is a recent change in Launchpad
[20:31] <maxb> Now, the SSH server is capable of resolving shortcut lp urls directly
[20:31] <maxb> With the goal of making the initial xml-rpc lookup unnecessary
[20:31] <bialix> ok, but bzr shows me this ugly %2B in URL
[20:32] <maxb> *shrug*, that's URL-encoding for you
[20:32] <bialix> I know, but it's weird anyway
[20:33] <maxb> perhaps ugly, but not weird
[20:33] <bialix> no, it's weird because there is bug somewhere
[20:34] <bialix> if I do `bzr branch lp:~bzr/bzr-explorer-website/trunk` then I end up wth parent branch: bzr+ssh://bazaar.launchpad.net/~bzr/bzr-explorer-website/trunk/
[20:34] <bialix> no %2B!
[20:34] <GaryvdM> Hi bialix.
[20:34] <bialix> heya Gary!
[20:36] <bialix> will poolie be around today/tomorrow (depending on TZ)
[20:36] <Meths> Is the website correct that 2.2.1 is the current stable release?
[20:36] <bialix> ?
[20:36] <bialix> Meths: yes
[20:37] <Meths> Okay, thanks.  (It's not in /topic.)
[20:37] <bialix> Meths: hmmm, yes. jam missed it
[20:38] <bialix> GaryvdM: it will be nice to review and land qdiff related patches
[20:38] <GaryvdM> bialix: Yes - sorry
[20:39] <bialix> GaryvdM: if you will look on them, then https://code.launchpad.net/~dorins/qbzr/qdiff-changes/+merge/34710 should be first; and https://code.launchpad.net/~s-dumbie/qbzr/ench_qdiff/+merge/33986 after that
[20:41] <GaryvdM> I've got a branch that I've been working for 2 months that I really want land. Soon hopefully.
[20:41] <bialix> logrefactoring?
[20:41] <GaryvdM> yip
[20:45] <GaryvdM> bialix: what do you think about this: http://www.youtube.com/watch?v=tMdE4GmFaDQ ?
[20:45] <GaryvdM> from a separate branch
[20:48] <GaryvdM> log refactor landed. :-)
[20:51] <GaryvdM> I hope to use that selection behaviour to fix bug 412035
[20:53] <bialix> GaryvdM: I'm not sure what you asking about that clip on youtube. either you gave ne a wrong link or I've lost my patience to see that asian boy after 1st minute
[20:55] <GaryvdM> bialix: the asian boy is you tube's dumb suggestions
[20:56] <GaryvdM> bialix: If you drag a selection, it only selects revisions that are ansestors of the top revision.
[20:56] <bialix> in qlog?
[20:56] <GaryvdM> Yes
[20:58] <GaryvdM> Changes made by revisions that are not ancestors of the top revision don't show in the diff, so I think it is more accurate.
[20:58] <bialix> I was looking at lp:~dorins/qbzr/qdiff-changes
[20:58] <bialix> it's pretty nice
[20:58]  * GaryvdM looks.
[21:00] <bialix> GaryvdM: once I've used keyboard arrows on your qlog in trunk I've got traceback
[21:00] <bialix> also you made bug labels dark red, why?
[21:01] <bialix> GaryvdM: http://paste.ubuntu.com/506749/
[21:02] <GaryvdM> I did not think I had changed the bug labels
[21:02] <bialix> I think I've pressed right arrow and want to expand merge
[21:03] <bialix> GaryvdM: maybe you don't but the text on the labels now black, it used to be white
[21:03] <GaryvdM> bialix: ok I'll take a look.
[21:04] <GaryvdM> bialix: Please could you check if bug 534963 still exists?
[21:05] <bialix> GaryvdM: re labels http://imagebin.ca/view/xaoMUEv.html
[21:07] <GaryvdM> bialix: One thing I hope you will like is test_loggraphviz.py
[21:08] <bialix> GaryvdM: re bug 534963: I don't have that tree around atm
[21:08] <bialix> maybe it at another computer, I'll check tomorrow
[21:08] <GaryvdM> Ok, thanks
[21:12] <bialix> vila should be happy about test_loggraphviz.py
[21:12] <bialix> your ascii graphs are funny
[21:21] <GaryvdM> bialix: keyboard nav bug fixed, and I think I've fixed the label color.
[21:22]  * bialix is pulling
[21:24] <bialix> GaryvdM: yes, now it's better
[21:24] <bialix> GaryvdM: but I'm not sure what do you mean about dragging
[21:25] <GaryvdM> bialix: the stuff from the vid not landed yet.
[21:26] <bialix> ok
[21:26] <GaryvdM> I think I pushed to lp. /me checks
[21:28] <GaryvdM> lp:~garyvdm/qbzr/log_select
[21:33] <GaryvdM> Hay, did they upgrade the mysql branches.
[22:01]  * GaryvdM pulls out the sketches made together with bialix at uds for qdiff.
[22:01] <GaryvdM> I should try scan them.
[22:03] <GaryvdM> bla - no one we be able to read my handwriting. - Ill draw it in mockups.
[22:16] <sven_oostenbrink> I have a bzr crash on a bunch of files in ./.bzr/repository/indices/ being empty (0 bytes).. Can I remove those files and try again?
[22:16] <sven_oostenbrink> Since these are indices. I suppose they can be recreated again?
[22:24] <sven_oostenbrink> I cant do anything with this repo anymore and I have a crapload of commits ready to push.. :( Anybody who might be able to help out?
[22:24] <maxb> sven_oostenbrink: Last time someone asked this, the response was uncertainty whether they could actually be recreated, and a definite assertion that no code exists to do so
[22:25] <sven_oostenbrink> maxb: as in, Im screwed...
[22:26] <sven_oostenbrink> Besides that, what could be the reason for those files to be empty? I already submitted a crash report, but this is bad for me :(
[22:27] <maxb> Filesystem corruption, perhaps?
[22:28] <sven_oostenbrink> maxb: besides an fsck, the filesystem should be 100% ok,
[22:29] <maxb> I suggest posting to the Bazaar mailing list, to get people more expert than me involved
[22:32] <sven_oostenbrink> maxb: okay, thanks anyway!
[22:39] <lifeless> sven_oostenbrink: did you have a system crash?
[22:40] <lifeless> power failure? removed a hotplug drive without flushing?
[22:40] <sven_oostenbrink> lifeless: mmmmmm, thinking about it.. my laptop froze about... 45 minutes ago.. happens every day these days, some hardware failure I need to look into... mmmmmmm...
[22:40] <lifeless> thats the problem
[22:41] <sven_oostenbrink> but even so, AFAIK, bzr wasnt busy, and AFAIK, kernel should flush on a 5 seconds interval, no?
[22:41] <lifeless> you had file content in your OS buffer
[22:41] <lifeless> sven_oostenbrink: depends on the file system
[22:41] <sven_oostenbrink> lifeless: even so, there is no way to repair that?
[22:41] <lifeless> sven_oostenbrink: and mount options etc. what file system?
[22:41]  * lifeless bets on ect4
[22:41] <sven_oostenbrink> lifeless: bingo... why betting on ext4?
[22:42] <lifeless> sven_oostenbrink: because its very agressive about not writing to disk.
[22:43] <lifeless> during development of it there was a -huge- discussion about this; it was breaking kde and gnome configs in this exact way, *all* the time.
[22:43] <lifeless> sven_oostenbrink: I suggest mailing the list as maxb suggested; you may be lucky and be recoverable.
[22:43] <sven_oostenbrink> lifeless: I guess thats the reason why chromium isnt storing my open pages either after a crash?
[22:43] <lifeless> sven_oostenbrink: after a machine crash? yes.
[22:44] <maxb> sven_oostenbrink: This repository - is it public or private code?
[22:44] <sven_oostenbrink> lifeless: Meh, the WT is still okay, Im creating a new branch, copying the old WT there, and recommitting.. its a bitch, but I can recover..
[22:44] <lifeless> sven_oostenbrink: basically ext4 isn't serialising file system operations for different files from the same process.
[22:44] <sven_oostenbrink> maxb: this specific one is public
[22:44] <lifeless> sven_oostenbrink: application authors then have a choice:
[22:45] <sven_oostenbrink> lifeless: not serializing as in writing out of sequence?
[22:45] <lifeless> yeah
[22:45] <lifeless> the file is 0 bytes long because the rename operation of a tmp file got flushed
[22:45] <maxb> well then, if you provide a tarball of the broken stuff, someone might be willing to poke at it and see if it is reparable
[22:45] <lifeless> but the file content didn't get flushed.
[22:46] <sven_oostenbrink> maxb: Not really needed I guess, Im already recommitting.. I had quite a few non-pushed commits, but thats life :) code is still preserved so
[22:47] <sven_oostenbrink> lifeless: that sounds kind of like cra... No way to work aroud that?
[22:48] <lifeless> sven_oostenbrink: if the pack got flushed, we -may- be able to recreate the index with enough effort, but if the pack didn't get flushed, we're boned.
[22:49] <lifeless> sven_oostenbrink: we could fsync at every little step, but fsync is the wrong hammer (we don't care about temp files being flushed, we care about a barrier approach - we want all ops before X to complete, then we have a small number of critical ops we could fsync on, and then we don't care after that.
[22:49] <lifeless> but user space barriers were slammed on lkml, so :(
[22:50] <lifeless> oh, and fsyncing will destroy performance on ext3
[22:50] <sven_oostenbrink> lifeless: well, again, no biggie.. I mean, having to re-commit this much isnt fun, plus I had multiple commits for single files, so now those multiple commits become one.. its not a huge deal, just an anoyance, Im working on fixing it now
[22:50] <lifeless> sven_oostenbrink: if you're having regular crashes, I suggest lots of backups :(
[22:51] <sven_oostenbrink> lifeless: well, its becomming regular on this @#$*( laptop... I need a new one
[23:01] <peitschie> hi all :)
[23:40] <mkanat> lifeless: The proxy that does load-balancing on launchpad server processes, can it be dropped in front of loggerhead without any changes to it?


[14:15] <mvo_> @time berlin
[15:58]  * mvo_ looks around
[15:58]  * robbiew waves
[15:59] <robbiew> #startmeeting
[15:59] <liw> hi
[15:59] <TheMuso> Hey folks.
[15:59] <robbiew> hmm...Mootbot is broken
[16:00] <Keybuk> I can pretend to be mootbot
[16:00] <robbiew> heh...it's not like this channel isn't logged
[16:00] <robbiew> lol
[16:00] <robbiew> Agenda is here: https://wiki.ubuntu.com/FoundationsTeam/Meetings/2009/0114#Agenda
[16:00] <evand> hi
[16:01] <robbiew> waiting on doko, james_w, slangasek, and cjwatson
[16:01]  * james_w waves
[16:01] <robbiew> :)
[16:01] <doko> hi
[16:01]  * slangasek waves
[16:01] <cjwatson> hi
[16:02] <robbiew> great...folks are here and I don't have to use mootbot :P
[16:02] <TheMuso> heh
[16:02] <robbiew> first topic is Jaunty Alpha 3
[16:02] <robbiew> how's that going?
[16:02]  * TheMuso is kind of glad he is working early today, going to be stinking hot...
[16:03] <robbiew> silence
[16:03] <Keybuk> robbiew: I was very restrained and expressly didn't break things today ;)
[16:03] <Keybuk> I'm going to wait until Friday
[16:04] <robbiew> heh...thanks
[16:04] <cjwatson> one installer glitch (bug 316618) fixed today, which I've asked slangasek to respin for
[16:04] <evand> encrypted home directory support in the desktop installer is broken.  On it, but it may end up being a release note.
[16:04] <liw> I'm holding off a system-cleaner upload until Friday, too; spec for that should be ready, waiting for approval (and package waits for third and last name)
[16:04] <cjwatson> images grossly oversized due to new OOo Java dependencies
[16:04] <slangasek> OOo has us a bit behind schedule, java snuck back into the CD dependencies with the latest upload and that puts us a little oversized
[16:04] <cjwatson> 90M is a little? :-)
[16:05] <robbiew> whoa
[16:05] <robbiew> heh
[16:05] <TheMuso> OUCH!
[16:05] <slangasek> the OOo-l10n build should finish in a few hours at which point we should have some right-sized images again
[16:05] <slangasek> cjwatson: smaller than a DVD!
[16:05] <mvo_> I have a pending upload for update-manager to fix system where nvidia binary drivers got removed during the upgrade
[16:05] <cjwatson> it's the "taller than Ronnie Corbett" competition - you can be very short and still win
[16:05] <slangasek> ah, no - OOo-l10n is already built
[16:06] <slangasek> so I'll start respinning the desktop images now and see where we get
[16:06] <mvo_> and asac and I debugged a upgrade issue with libnspr today
[16:06] <robbiew> so Alpha 3 most likely released sometime Friday evening?
[16:06] <mvo_> I had trouble getting the upgrade tester going, kvm in jaunty is not my friend currently
[16:06] <cjwatson> good news for a3 is that I spent a kind of a skunkworks day doing ext4 support in the installer
[16:06] <slangasek> robbiew: still aiming for Thursday evening
[16:06] <cjwatson> which seems to be popular
[16:07] <robbiew> slangasek: ok, thnx
[16:07] <slangasek> there are already some images posted and ready for validation
[16:07] <Keybuk> cjwatson: I bet Ted still didn't change his wiki page? :p
[16:07] <cjwatson> not last I checked ;-)
[16:07] <robbiew> so moving on, I've been steadily adding to the 9.04 status page
[16:08] <robbiew> https://wiki.canonical.com/UbuntuPlatform/Foundations/9.04
[16:08] <robbiew> should be complete by tomorrow
[16:08] <doko> hmm, are the java deps really needed for OOo?
[16:08] <robbiew> gives me a single point of tracking status...and a place for others to quickly check
[16:09] <slangasek> doko: same as before, I think
[16:09] <slangasek> they crept in now because Tuesday was the first day OOo 3 was on the daily builds
[16:09] <cjwatson> calc uploaded to take them out again
[16:10] <cjwatson> 1:3.0.1~rc1-2ubuntu3
[16:10]  * slangasek nods
[16:10] <cjwatson> mvo_: (kvm in jaunty has been working fine for me, for the record ...)
[16:10] <TheMuso> So does openoffice lose much functionality without those deps?
[16:11] <slangasek> TheMuso: AIUI, the answer is "no moreso than before"
[16:11] <TheMuso> slangasek: Right.
[16:11] <mvo_> cjwatson: it freeze for me when I do a upgrade test (interpid->jaunty) at random places (amd64 host)
[16:11] <cjwatson> ugh. (I'm on i386)
[16:11] <mvo_> cjwatson: usually after ~45min or so :/
[16:11] <james_w> though the mailing list suggests it may be a little more than before
[16:11] <mvo_> cjwatson: aha, I shall try on a i386 machine
[16:12] <evand> amd64 here and no issues with kvm thusfar
[16:12] <cjwatson> OOo certainly isn't full-featured without Java, and people using it substantially are still going to need to be advised to install the openoffice.org metapackage (as before, only maybe just more so)
[16:12] <mvo_> evand: hmm, how strnage. do you use virtio?
[16:12] <cjwatson> but I think it's still at a basic useful level on the CD without Java
[16:14] <slangasek> if nothing else, it's nice to let users only have to download 100MB to get a usable OOo instead of 250MB :)
[16:14] <TheMuso> Agreed.
[16:14] <slangasek> mumble, OOo also hasn't finished building on amd64
[16:14] <calc> TheMuso: you can't search help without java, so some functionality is lost
[16:14] <slangasek> so the current desktop CD build is just a smoketest to see if it sizes right on i386, then
[16:15] <TheMuso> calc: Right.
[16:15] <slangasek> calc: oh, in that case perhaps we should be taking the help packages off the CD instead of breaking the java dep?  or is there a useful non-search mode for help?
[16:15] <evand> mvo_: Possibly.  I certainly do not pass such an option to kvm on the command line but the virtio modules are loaded in the VM
[16:15] <calc> slangasek: i think i may have to take a knife to suitesparse packaging because I have a feeling that demoting lpsolve may break calc
[16:16] <slangasek> (also, are upstream unaware that people have implemented 'searching' before in C? :)
[16:16] <slangasek> calc: hmm, ok
[16:16] <calc> slangasek: it appears there is a lib in suitesparse that isn't currently broken out that could be to allow it to work without pulling all of it in
[16:16] <doko> calc: what are the *additional* bits that require java in 3.0?
[16:16] <calc> slangasek: upstream wrote Java and needs to justify its existence
[16:16] <slangasek> calc: can you file a bug asking for the split, and target it to alpha-4?
[16:17] <calc> doko: i don't have the specific details but help apparently uses lucene for searching which in turn is a java library
[16:17] <slangasek> robbiew: have we derailed sufficiently yet? :)
[16:17] <calc> slangasek: i will once i can look into what it takes, i will probably end up splitting it in the process myself
[16:17] <robbiew> heh...about to jump in ;)
[16:18] <robbiew> but always think a healthy discussion is good, too
[16:18] <robbiew> so there's a link to the targeted bugs for Jaunty in the Agenda...no need to discuss it. however, I would like to briefly chat about http://qa.ubuntu.com/reports/ogasawara/jaunty-buglist.html
[16:19] <robbiew> mvo and cjwatson look lonely on the Foundations list
[16:19] <robbiew> :P
[16:20] <robbiew> perhaps I should assign these to the ubuntu-foundations LP team...then we work them from there
[16:20] <cjwatson> mdz has suggested taking on the 'apport-package' bugs (mostly upgrade bugs) and farming them out, which would flesh it out somewhat
[16:20] <robbiew> similar to what Desktop has done
[16:20] <cjwatson> there are nearly 700 of those in main and restricted
[16:20] <mdz> probably a lot of gardening to be done there
[16:21] <mvo_> I can have a look at those
[16:21] <cjwatson> robbiew: I don't think farming out the existing list will improve matters; personally, I think it would be better to add more to that list that correspond to the expertise of other members of the team
[16:21] <mvo_> (but its probably good to have more people looking at them, there are *many* :)
[16:21] <robbiew> cjwatson: ok
[16:21] <cjwatson> i.e. I think the existing ones are basically appropriately assigned
[16:22] <liw> robbiew, I was looking for instructions about how to deal with bugs for the bug fixing initiative the other day, and tried to get a consensus out of the related discussion on the distro list last year... without much luck :(
[16:22] <Keybuk> those are pretty much all installer + package manager bugs atm
[16:22] <cjwatson> exactly
[16:22] <cjwatson> which is just a reflection of how only me and mvo have been using those tags, I think :)
[16:23] <slangasek> 78552 is an interesting bug to have there, the fact that /sbin/update-grub complains is part of a deliberate transition plan by the Debian maintainers
[16:23] <Keybuk> tags?
[16:23] <robbiew> liw: yes, I'll take that as a ToDo
[16:23] <liw> robbiew, thanks
[16:23] <cjwatson> so, there are a couple of things that tie into the bug-fixing initiative
[16:23] <robbiew> there still seems to be some cloudiness on how we approach this effort
[16:23] <cjwatson> https://wiki.canonical.com/UbuntuPlatform/QA/BugFixing/TeamBugLists describes the different approaches one might take
[16:24] <robbiew> Keybuk: tags defined there ^
[16:24] <cjwatson> number 3 on that list is what corresponds to the jaunty-buglist URL robbiew posted above
[16:24] <cjwatson> i.e. things tagged with qa-jaunty-foundations end up on that list; I've been using that as a way to say "our team ought to be addressing this for jaunty"
[16:25] <Keybuk> would we add these tags if we were intending to address it?
[16:25] <Keybuk> or are they for finding bugs nobody's assigned to, and getting someone assigned to them?
[16:25] <liw> cjwatson, so: add tag to get on that list Leann produces, and assign to a person to get one's name onto the list as well?
[16:25] <cjwatson> there is a separate notion that came up on distro-team, which is the "I'd love to have some time to fix this ancient crufty bug" thing
[16:25] <cjwatson> Martin Pitt proposed the "pet-bug" tag for that
[16:25] <cjwatson> these are confusingly similar notions (IMO), but I think they can be distinguished
[16:26] <robbiew> it would be nice if we had a central point to refer to for the bug fix effort...and maybe https://wiki.canonical.com/UbuntuPlatform/QA/BugFixing/TeamBugLists is it
[16:26] <cjwatson> Keybuk: I would say that if it's something you'd like to fix just because it's been annoying you (wishlist bugs would often fall into this category), then "pet-bug"; if it's something that you think is important and basically it's a disgrace that our team has been slacking at fixing it :-), then "qa-jaunty-foundations"
[16:27] <cjwatson> regardless of whether that means you or somebody else
[16:27] <robbiew> however, things like the "pet-bug" tag aren't documented there...and that's where confusion creeps in
[16:27] <cjwatson> some of my bugs on that list are mistagged because they predated "pet-bug", but I was planning to solve this by fixing the bugs
[16:28]  * slangasek grins
[16:29]  * robbiew will get the "pet-bug" tag stuff added to the TeamBugList page
[16:29] <robbiew> moving on to 8.04.2
[16:29] <robbiew> cjwatson: do you have an ETA for the manifest list?
[16:30] <cjwatson> end of the week
[16:30] <robbiew> ok, thanks
[16:30] <cjwatson> which conveniently coincides with the drop-dead date for updates
[16:30] <robbiew> :)
[16:31] <robbiew> looking at bugs, I see 33...right?
[16:31] <robbiew> milestoned
[16:31] <robbiew> so am I to assume that all 33 will be resolved by release? or that some may get bumped
[16:31] <slangasek> almost everything on there that's not already 'fix committed' are going to be deferred
[16:32] <robbiew> gotcha
[16:32] <robbiew> thnx
[16:32] <robbiew> then moving on
[16:32] <robbiew> reminder for the sponsorship queue :)
[16:33] <robbiew> I realize with Alphas, LTS, Distro Sprint coming...can get pushed to the side
[16:33] <cjwatson> is everyone in the habit of listing their sponsorship activity for the week in their activity report, by now?
[16:33] <james_w> the queue length is quite stable currently, but there are some long standing items that need addressing from what I can see
[16:33] <robbiew> it's either no...or just don't have many people doing it
[16:33] <slangasek> cjwatson: yes
[16:34] <robbiew> heh
[16:34]  * mvo_ tries to do it
[16:34] <james_w> I usually just list "sponsoring", I can't always be bothered to look up the list
[16:34] <cjwatson> I only managed one item this week, which I consider a failure
[16:34] <cjwatson> I do write it down as I go along
[16:34] <robbiew> james_w: that's acceptable
[16:34] <robbiew> I can always look at the list ;)
[16:35]  * mvo_ has done only a small number too (at least compared to the sponsoring masters james_w and dholbach :)
[16:35] <Keybuk> I haven't yet habit-formed checking the sponsoring queue
[16:35] <robbiew> ohh...Keybuk is shamed! lol
[16:35] <TheMuso> I got some in this past week, however I find that by the time I get to it, its usually taken care of, due to the whole time zone thing I think.
[16:35] <TheMuso> Depends on how early I get to it./
[16:36] <robbiew> ok, just want folks to keep it in mind during the week...which is why I always bring it up ;)
[16:36] <slangasek> TheMuso: but... but... your timezone is earlier :)
[16:36] <robbiew> lol
[16:37] <robbiew> next topic is the Objectives Guidance
[16:37] <robbiew> just want to point out that they are only guidelines...so no need to think yours have to be like them
[16:38] <robbiew> I didn't know the PDR tool locks them in stone once submitted and approved
[16:38] <robbiew> so it would be better to have self-development style objectives
[16:38] <robbiew> versus business/project related ones...as those can change
[16:38] <Keybuk> oh, was meaning to mention something
[16:38] <Keybuk> my PDR has gone a bit wibbly
[16:39] <robbiew> wibbly???
[16:39] <robbiew> lol
[16:39] <Keybuk> it seems to think I report to you now
[16:39] <Keybuk> which is fine
[16:39] <Keybuk> but it also seems to think lots of people report to me
[16:39] <robbiew> oh
[16:39] <Keybuk> and, well, that seems to upset it a lot
[16:39] <robbiew> promotion for me!!
[16:39] <robbiew> lol
[16:39] <robbiew> Keybuk: talk to bongrad
[16:39] <Keybuk> yeah
[16:41] <robbiew> anyways, if you have business related goals...and they change along the way, don't worry about it
[16:41] <robbiew> I would expect common sense to prevail, and not meeting that objective would not count against you
[16:41] <robbiew> ;)
[16:42] <robbiew> last thing on my list
[16:42] <robbiew> EC2!
[16:42] <robbiew> :)
[16:42] <robbiew> https://wiki.canonical.com/UbuntuPlatform/Foundations/AmazonEC2
[16:42] <robbiew> I've listed the only idea there, on the main list that will be reviewed tomorrow
[16:42] <robbiew> anyone else have anything?
[16:43] <robbiew> mvo: you had the update testing idea, right?
[16:43] <mvo> robbiew: yes
[16:43] <liw> james_w had an idea too, I think
[16:43] <robbiew> right
[16:43] <james_w> well, it was liw's idea
[16:43] <mvo> robbiew: its a bit cloudy to me still how exactly to do it without using a big amounts of resources on the ec2
[16:43] <robbiew> james_w and mvo: you can directly add to https://wiki.canonical.com/CoP/EngineeringManagement/AmazonEC2
[16:43] <robbiew> mvo: that's ok
[16:43] <james_w> but rebuilds + piuparts + other things
[16:44] <robbiew> mvo: just a brainstorm list at the moment
[16:44] <mvo> I would love to have install/remove testing, that kind of basic testing is already pretty helpful
[16:44] <james_w> mvo: could upgrade tests be run every day without too much handholding?
[16:44] <evand> I'm not sure if it fits the model of EC2, but I've wanted to do automatic installation testing for a while now.
[16:44] <mvo> james_w: absolutely, the thing that run them now is totally non-interactive etc - its just that is uses kvm and not ec2/xen currently
[16:45] <evand> erm, nevermind
[16:45] <james_w> mvo: cool. With an in-amazon mirror it may not be too expensive.
[16:45] <mvo> james_w: yeah, if that can be done, that would be cool
[16:45] <robbiew> fyi - that is being setup
[16:45] <robbiew> in-amazon mirror
[16:45] <mvo> aha, nice
[16:45] <james_w> mvo: I like your kvm test-upgrade my machine thing
[16:46] <mvo> then it should indeed be less pain, if the base image can be cached in-amazon too that means even less resource usage
[16:46] <james_w> mvo: would it be possible ro have some of that without massive amounts of bandwidth being needed between me and ec2?
[16:46] <mvo> james_w: thanks :) evand had this idea to make it even more spectacular by using aufs overlay on the real system
[16:46] <james_w> ooh
[16:46] <mvo> james_w: I have a branch and some code, its a bit scary but it seems to be working
[16:46] <evand> wonderful!
[16:46] <james_w> e.g. upload package list + tarball of /etc/ or something?
[16:47] <mvo> james_w: that is a interessting idea too
[16:47] <mvo> james_w: yeah, that should be doable
[16:47] <robbiew> mvo, james_w, evand: make sure to capture this idea here:  https://wiki.canonical.com/CoP/EngineeringManagement/AmazonEC2
[16:47] <robbiew> under Foundations
[16:47] <james_w> got it open :-)
[16:47] <robbiew> right now, I had a generic "Test Upgrades" line :/
[16:47] <robbiew> sweet
[16:47] <robbiew> james_w: thanks
[16:48] <robbiew> that's all I got.
[16:48] <robbiew> AOB?
[16:48] <james_w> daily packages?
[16:48] <robbiew> sure...the POC, right?
[16:49] <james_w> I'd appreciate suggestions for packages that would be good to have dailies of that aren't going to be too temperamental
[16:49] <james_w> I imagine kernel, firefox, OOo would break too often
[16:49] <cjwatson> I think I mailed a few to Robbie a while back
[16:49] <mvo> james_w: I would love to see compiz here
[16:49] <james_w> I think evolution would be good to have.
[16:49] <james_w> ah, compiz cool.
[16:49] <robbiew> cjwatson: hmm...really?
[16:49]  * robbiew checks
[16:50] <TheMuso> james_w: Don't the kernel team have their own daily build stuff anyway?
[16:50] <cjwatson> just trying to find it
[16:50] <cjwatson> I certainly suggested some constraints that should be applied
[16:50] <robbiew> yes...I remember that
[16:50] <james_w> TheMuso: probably, I don't fancy taking that one on
[16:51] <TheMuso> One could actually be pulseaudio. I was going to do it myself into my PPA, but if we have this daily build spec, then it may be worthwhile doing for that.
[16:51] <TheMuso> Pulseaudio is in git however.
[16:51] <cjwatson> there's a project called 'ubuntu-bleedingedge' that started trying to do this, and it would be a useful banner
[16:51] <cjwatson> it even has some code with an initial proof of concept
[16:51] <james_w> TheMuso: I'll add it to the list, thanks
[16:52] <james_w> thanks cjwatson, I'll check it out
[16:52] <cjwatson> that project seems moribund at the moment, but could be revived
[16:52] <cjwatson> lp:~ubuntu-bleedingedge/bleedingedge/trunk and there's a wiki page
[16:52] <cjwatson> robbiew: Subject: Re: [Fwd: Daily upstream packages (Re: Laptop hotkey support)]
[16:53] <robbiew> cjwatson: ah, thnx
[16:53] <cjwatson> james_w: I'll forward you this mail
[16:53] <james_w> thanks
[16:53] <james_w> as this is Ubuntu-external I'll be starting after feature freeze on it
[16:53] <robbiew> cjwatson: found it ;)
[16:54] <robbiew> james_w: ok, and you mentioned a spec for this right?  Figure we should at least have a documented plan
[16:54] <james_w> yeah, I'll write up a spec, or find an existing one to co-opt
[16:55] <robbiew> ok...just shoot me the link in an email
[16:55] <james_w> sure
[16:55] <robbiew> anything else?  cjwatson: campaign speech for Tech Board? lol
[16:55]  * cjwatson grins
[16:56] <liw> did we skip "Good News"?
[16:56] <robbiew> that is Good News :)
[16:56] <robbiew> liw: on it now
[16:56] <cjwatson> my good news was ext4
[16:56] <robbiew> ah, yes
[16:56] <cjwatson> oh, I'm going through the archive reorg videos now and trying to shore up the spec
[16:56] <liw> my good news for today is that I managed to survive an encounter with a screwdriver
[16:56] <robbiew> liw: lol...what?
[16:57] <cjwatson> I have been a naming fascist and nailed down a single set of nomenclature
[16:57]  * mvo advices liw to stay away from hardware
[16:57] <liw> (had to tweak my desktop machines a bit)
[16:57] <robbiew> cjwatson: name nazi
[16:57] <liw> mvo, I try, I try...
[16:57]  * TheMuso is starting to get the hang of dealing with alsa hda quirks, and maanged to get an Ubuntu originated quirk patch applied upstream, with many more to come hopefully.
[16:58] <cjwatson> (screw "lobes", I went with "layers")
[16:58] <TheMuso> bad news, my typing sucks. :p
[16:58] <robbiew> cjwatson: yeah...lobes was nasty
[16:58] <liw> cjwatson, if you run out of English words, I can send you a Finnish dictionary ;)
[16:58] <cjwatson> and realised that layers are in fact identical to Mark's package sets
[16:58] <cjwatson> so have been trying to make the spec reflect that
[16:59] <robbiew> #endmeeting ....for Keybuck-bot :P
[16:59] <slangasek> I thought it was "cells"
[17:00] <slangasek> ohwell :)
[17:00] <liw> thanks
[17:00]  * mvo likes cells
[17:00] <james_w> thanks all
[17:00] <evand> thanks!
[17:00] <TheMuso> thanks
[17:00] <mvo> thanks
[17:00]  * Keybuk likes pies
[17:00] <robbiew> lol
[17:00] <robbiew> thanks all
[17:00]  * TheMuso goes and syncs ubunt and studio isos.
[17:02]  * heno waves
[17:02]  * ara waves
[17:02] <sbeattie> hey
[17:02]  * ogasawara waves
[17:02] <bdmurray> hello
[17:02]  * sbeattie disappears for a second to replentish his caffiene supply
[17:02] <davmor2> hello everybody
[17:02] <charlie-tca> hello
[17:03] <bdmurray> charlie-tca: hello
[17:03] <pedro_> hello everybody
[17:04]  * schwuk waves
[17:04] <heno> welcome all!
[17:04] <heno> #startmeeting
[17:04] <davmor2> no bot
[17:05] <heno> agenda: https://wiki.ubuntu.com/QATeam/Meetings
[17:05] <heno> * Jaunty spec review
[17:06] <heno> I've updated https://wiki.ubuntu.com/QATeam/RoadMap with Jaunty spec info
[17:06] <schwuk> davmor2: you could pretend to be the bot
[17:06] <heno> There are a few bits missing (ran short of time)
[17:06] <davmor2> schwuk: :P
[17:07] <schwuk> heno: looks good
[17:07] <heno> please add other items you are working on that are not registered as specs to the bottom of that page
[17:08] <heno> and please review it for general sanity
[17:08] <heno> There are still a few specs that need more drafting and approval - please try to get that wrapped up this week
[17:09] <heno> Let's not go through the whole list at this meeting though
[17:09] <heno> we can cover it briefly on the c.c call
[17:10] <heno> instead lets focus on Hardy and Jaunty release testing
[17:10] <heno> * Hardy point release testing
[17:11] <heno> sbeattie: can you give an update on 8.04.2 SRU testing?
[17:11] <heno> esp areas you are blocked and could use some help
[17:12] <sbeattie> sure, I've been working on the base-installer one (bug 306356) which looks good for hardy (and intrepid), but I'd like cjwatson to verify my results, because they didn'tmatch his testcase.
[17:12] <davmor2> I've done some testing on bugs past me by slangasek to help clear those
[17:12] <cjwatson> (one moment, looking)
[17:13] <heno> davmor2: also installer bugs right?
[17:13] <sbeattie> I was also poking at the ntfs-3g one (bug 204133) as it affects wubi, but couldn't reproduce it, so I left a ping asking for soeone affected by it to try testing it out.
[17:13] <davmor2> heno: yes
[17:13] <cr3> regarding the QA roadmap, the blueprints section mentions "Intrepid". shouldn't it mention "Jaunty"?
[17:14] <pedro_> FYI there's an issue with evolution 2.24.3 package; bug 316726, which should be fixed pretty soon
[17:14] <pedro_> 2.24.3 from proposed.
[17:15] <heno> Note - the cut-off for SRU testing is Monday - at that point we start rolling ISOs and testing those
[17:15] <cjwatson> sbeattie: the test case is incorrect in that it leaves it implicit that all tests of proposed d-i component changes need to be run with apt-setup/proposed=true
[17:15] <davmor2> sbeattie: I think that got fixed to a degree
[17:15] <heno> davmor2: have you had a chance to smoke test any hardy ISOs?
[17:15] <sbeattie> ones I could use help with are the hardware specific ones, bug 59695, bug 204483, bug 288859 and bug 267570
[17:15] <bdmurray> sbeattie: I could try the wubi one I guess...
[17:16] <davmor2> heno: I've had a quick look at them once installed for the case I was given
[17:16] <cjwatson> sbeattie: oh, but do you just mean that the host name you saw was different from the test case - us.archive rather than security?
[17:16] <sbeattie> cjwatson: yes, that part.
[17:16] <cjwatson> sbeattie: I think that's a mistake in the test case, yes, and also a not very serious pre-existing bug in base-installer
[17:16] <davmor2> heno: there was an issue with umenu and wubi but that should be fixed in today's image
[17:17] <heno> cr3: could you have a look at sbeattie's hw-specific bugs and see if we have the hardware in Montreal?
[17:18] <sbeattie> cjwatson: hrm, that's what I thought the patch was fixing, that $MIRROR (us.archive) would get used, rather than $SECMIRROR (aka apt-setup/security_host)
[17:18] <cr3> heno: noted
[17:18] <heno> which brings us to ...
[17:18] <heno> * cert lab hw data dump status (schwuk)
[17:19] <cjwatson> sbeattie: oh, err - yeah, you're right. insufficient coffee
[17:19] <sbeattie> cjwatson: no worries, wanted to make sure it wasn't insufficient coffee on my end.
[17:19] <cjwatson> sbeattie: I've corrected the test case. I *think* it passes now given your comments?
[17:20] <sbeattie> cjwatson: yes, I agree, I think it passes.
[17:21] <schwuk> heno: can you add a bit more detail to that?
[17:21] <sbeattie> hardware dump: ogasawara and I were hoping, as an interim thing, if we could get just a raw dump (possibly a tarball) of the current hardware we have in the certification lab, at a more detailed level than just model number, but listing components.
[17:21] <heno> schwuk: are you able to generate a dump of the hardware info from the machines we have that can be searched locally?
[17:22] <heno> stuff that has already been gathered during various testing
[17:22] <schwuk> heno: sure - I'll cook something up
[17:22] <heno> but needs to be mined from the db
[17:22] <sbeattie> schwuk: basically something we can grep for things like pci ids locally, to use in identifying whether we have hw available for testing specific issues.
[17:23] <heno> a tarball with a dir for each system perhaps, with various files in each
[17:23] <bdmurray> sbeattie: I thought cr3 made the database available once
[17:23] <schwuk> sbeattie, heno: sure
[17:23] <heno> we could then use local tools to search
[17:24] <sbeattie> bdmurray: if so, I've forgotten the details. I've access to the website, but there's no easy way to search for whether we have specific hardware through it.
[17:24] <heno> I think extracting it from the raw database is not trivial without knowledge of it's structure
[17:24] <cr3> bdmurray: the database is more complicated to query than flat text files
[17:24] <heno> because of the way results are stored
[17:25] <davmor2> schwuk: can you not sudo lshw -html each device it will give you something like http://www.davmor2.co.uk/64test.html
[17:25] <cr3> davmor2: the information is extracted from the database which contains structured information, so the output will have to be generated based on that information
[17:26] <heno> schwuk: ok, thanks
[17:26] <schwuk> davmor2: we already have the info, we just have to re-constitute it
[17:26] <heno> * Testcase wiki migration; automated scripts
[17:26] <heno> ogasawara and I looked at this yesterday
[17:27] <heno> the structure of the pages we have and want are quite different
[17:27] <davmor2> go on
[17:27] <heno> so writing sensible scripts might be more work than copying the content across
[17:28] <heno> I suggest we get a dump of the pages from IS from the server and paste it in and refactor from there
[17:28] <heno> schwuk: do we have access to the moin data dir?
[17:29] <heno> (on the testcases wiki)
[17:29]  * schwuk checks
[17:29] <heno> that way we would have the attachments and history
[17:30] <ara> heno: if that solutions is possible, it would be great
[17:30] <heno> schwuk: can you coordinate that with IS, getting the dump and getting it uploaded?
[17:30] <schwuk> heno: no. We'll need either an RT to get acces, or the content copied accross
[17:31] <schwuk> heno: sure
[17:31] <heno> davmor2: can we speak tomorrow about the refactoring we need to do afterward?
[17:31] <heno> schwuk: both would be ideal
[17:31] <davmor2> yes no probs
[17:31] <schwuk> Where do we want the pages put?
[17:32] <heno> under their current names
[17:32] <heno> then we can rename from there
[17:33] <heno> that's the end of the agenda
[17:33] <schwuk> So basically the whole of /Testing right?
[17:33] <heno> schwuk: Testing/Cases only
[17:34] <schwuk> heno: Got it.
[17:34] <heno> any other business for the meeting?
[17:34] <davmor2> yes
[17:35] <davmor2> is there a way to stop the dl-ubuntu-test-iso script exiting when it hits an issue with md5sum?
[17:35] <sbeattie> davmor2: yes, one sec
[17:35] <cr3> davmor2: what's this script?
[17:36] <davmor2> Xubuntu is the cause this time but it is in the live which means the alternate section can't be downloaded using it
[17:36] <sbeattie> davmor2: you could turn off verification of md5sums
[17:36] <heno> cr3: used for ISO testing - would be worth looking at for the satellite servers too
[17:36] <davmor2> cr3: it's a script which pulls all the isos
[17:37] <heno> https://wiki.ubuntu.com/Testing/Isoscript
[17:37] <sbeattie> davmor2: give me a bit and I think I can fix it up so that it doesn't abort on the md5sum error.
[17:38] <cr3> heno: the images/archives that need to be tested are communicated to the satellite servers from the web server, so I'm not sure how useful this might be but I'll nonetheless look into the script
[17:38] <davmor2> cr3: I have it as a cron job so I get the latest daily each morning before I sit down to test :)
[17:39] <cr3> davmor2: do you have the latest hardy daily too?
[17:39] <davmor2> yes
[17:39] <davmor2> script does it all :)
[17:40] <cr3> if I run the bzr command on the wiki, I get: bzr: ERROR: Connection error: curl connection error (Problem with the SSL CA cert (path? access rights?))
[17:41] <heno> WFM
[17:41] <heno> ok, let's wrap it up
[17:41] <heno> #endmeeting
[17:41] <schwuk> thanks heno
[17:41] <heno> thanks everyone!
[17:41] <sbeattie> cr3: https://code.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master
[17:41] <ara> thanks!
[17:41] <sbeattie> thanks.
[17:42] <davmor2> cr3: works for me
[17:42] <davmor2> 51 revisions
[17:43] <davmor2> thanks
[17:43] <cr3> this works for me: bzr branch lp:ubuntu-qa-tools
[22:08] <MTecknology> what's the bot in here?