[04:19] <qwebirc62607> Hey all. I just install ubuntu 11.04, and installed mythbuntu for mythtv. I've tried the shipped version, 2.4 version and 2.5 version and in each has the same problem of seeking causing audio static on occasion. It doesn't happen everytime, but most times I'll get loud static and lose the sound. Does anyone ran into this problem?
[04:20] <qwebirc62607> Wow fail english... Has anyone ran into this problem?
[04:27] <qwebirc62607> I seemed to have fixed it by forcing 48khz or something in the audio menu. I remember reading about that earlier when I was researching it. Have a good night.
[05:35] <mycosys> anyone got some great idea on troubleshooting why netbios seems to be nonfunctional? 10.04lts +0.24fixes
[11:27] <hot_wheelz> Hi tgm4883
[13:53] <dewman> is there any tricks to getting composite video to work? I want to grab a few shows from my cable box....
[13:54] <dewman> not sure if I should be using the s-video input or the rca cables...Or does it matter for quality?
[14:26] <mycosys> had any help dewman?
[14:26] <mycosys> what kind of gpu are you using?
[14:29] <dewman> mycosys, I am using this one, currently it is set up to capture analog cable... http://www.linuxtv.org/wiki/index.php/Pinnacle_PCTV_HD_Card_%28800i%29
[14:29] <Zinn> [www.linuxtv.org] Pinnacle PCTV HD Card (800i) - LinuxTVWiki
[14:30] <mycosys> thats not a gpu
[14:30] <mycosys> oh, composite in
[14:30] <mycosys> is 11:30 pm and it has been a long day
[14:31] <dewman> o you meant.... video card... ;)
[14:31] <dewman> video card is a geforce 8500 gt
[14:33] <mycosys> looks like a bad idea to use that for composite
[14:34] <dewman> hmm... I didnt really care about quality, I was just looking to grab a few shows for my little ones. (blues clues, etc....)
[14:34] <mycosys> not about quality - will load down ur cpu like crazy
[14:34] <dewman> because of the raw video correct?
[14:37] <mycosys> yup - is a basic framegrabber
[14:38] <mycosys> hardware is cheap as chips in hong kong isnt it? why not grab a cheap card with mpeg encoder on board?
[14:38] <mycosys> you have heaps o places there dont u dewman
[14:39] <dewman> ha, i live in the middle of a field in MI,USA
[14:39] <mycosys> also - remember hearin of some issues with v4l1 style capture - ot sure of specifics - may be realated to that
[14:40] <mycosys> fenton michigan, ok
[14:40] <mycosys> then newegg ftw lol
[14:40] <dewman> the card has been working pretty good for grabbing cable. just hit the year mark a few days ago.... =)
[14:41] <mycosys> one of the hauppauge cards with encoder on it if u wanna record from ur cable box
[14:41] <dewman> yeah, wife doesnt let me spend to much on new toys...Unless it will make it "better" for her....LOL...Which, in this case it would..
[14:41] <mycosys> there is a wiki on what ur doin http://www.mythtv.org/wiki/Recording_Digital_Cable
[14:41] <Zinn> [www.mythtv.org] Recording Digital Cable - MythTV Official Wiki
[14:42] <mycosys> the HDPVR is popular apparently
[14:42] <mycosys> *HD HR
[14:42] <mycosys> HDPVR lol
[14:42] <dewman> yeah, I tried the firewire thing, it works good, except when your watching tv, and it changes the channel on you... ;)
[14:42] <mycosys> that isnt for firewire
[14:43] <mycosys> option 4 of 6 is firewire
[14:44] <dewman> right, I was just throwing out what I have tried in the past. =)
[14:45] <mycosys> http://www.linuxtv.org/wiki/index.php/Hauppauge#Analog_Devices the old Hauppauge PVR-150/250/350 should be pretty much throwaways on ebay now
[14:45] <Zinn> [www.linuxtv.org] Hauppauge - LinuxTVWiki
[14:48] <dewman> I thought I read somewhere that there where some variants of the 150, I think there is a few models that are junk...I cant remember though.
[14:48] <mycosys> dunno
[14:49] <mycosys> long as they work with linux lol
[14:51] <mycosys> the hvr-2250 is another option, dual hybrid card, should be working
[16:05] <mycosys> !repo
[16:05] <Zinn> The Mythbuntu team provides updates for MythTV and Mythbuntu package using the Mythbuntu Repos http://mythbuntu.org/repos


[00:36] <canthus13> wow.  How about there?
[05:25] <BiosElement> Ahh can't complain
[05:25] <BiosElement> Just trying to get some projects done for once after my last little mess
[14:18] <thafreak> Can anyone recommend a cheap usb dongle that's atleast 1.2 compliant and works with linux?
[14:20] <paultag> for what? WiFi? Bluetooth? :)
[14:58] <canthus13> paultag: a USB dongle. you know.. a thingie that plugs into your USB port and gives you a USB port.
[14:58]  * canthus13 paid 10 cents for his.
[14:59] <canthus13> ...also known as a USB extension.
[15:04] <paultag> canthus13: hahaha
[15:08] <thafreak> oops
[15:08] <thafreak> haha yeah bluetooth
[15:08] <thafreak> want to use a bluetooth headseat for voip
[15:09] <thafreak> seems the dongle i had is only 1.1 and doesn't work with headsets :(
[15:35] <canthus13> thafreak: I got a cheap no-name bluetooth dongle for like <2 bucks including shipping from china.. works fine.
[15:41] <canthus13> Bluetooth dongles are pretty simple.
[15:44] <canthus13> My dongle worked with headsets. my problem was syncing was iffy.. dunno if it was the dongle, the headset, or linux. :/
[15:44]  * canthus13 is thinking linux 'coz it wo uld get confused about where the output should be directed.
[17:38] <thafreak> huh, another recruiter called
[17:39] <thafreak> "sales" engineer position...lots of traveling, but *base* salary is 110K....
[17:41] <jandrusk> If your single that might work.
[17:46] <thafreak> yeah, not single, complete opposite...
[17:46] <Unit193> ...Double?
[17:46] <Unit193> :P
[17:47] <thafreak> nah, married, plus kids
[17:47] <thafreak> plus wife is pregnant
[17:47] <thafreak> so more kids
[17:47] <thafreak> :/
[17:49] <paultag> thafreak: you get get that salery programming
[17:50] <paultag> it's not hard to break 100K if you know how to swing it
[17:50] <thafreak> where in ohio
[17:50] <paultag> oh not in Ohio, no
[17:50] <thafreak> and i know those people
[17:50] <thafreak> they work like 60hours a week
[17:50] <paultag> perhaps if you were a hotshot at urbancode or something
[17:50] <thafreak> might rather travel 2 or 3 days, and hang out at home the rest
[17:51] <thafreak> urbancode?
[17:56]  * canthus13 has a friend who codes primarily in ruby, being approached for 200k+ positions... he's 20 years old. o.O
[17:57] <paultag> canthus13: yeah, that happens :)
[17:58] <paultag> thafreak: it's in cleveland
[17:58] <thafreak> your mom approaches 200K....
[17:58] <thafreak> kilos that is
[17:58] <thafreak> BURN
[18:00] <canthus13> paultag: He dropped out of high school. :/
[18:00] <thafreak> and 110 was just the base salary, commission gets paid on top...well a percent of the salesperson's commission
[18:00] <canthus13> thafreak: that would be fun. :)
[18:10] <thafreak> and stock options
[18:32] <canthus13> stock options. :/ depending on the company they might be worth less than no benefits at all. :/
[18:56] <yano> stock options can be a waste of money
[21:10] <Unit193> Boom, it's official, jrgifford put me on it. ;) https://wiki.ubuntu.com/Membership/RegionalBoards/Americas
[21:10] <jrgifford> W000T! Only took you what. 6 months?
[21:11] <jrgifford> AHH YEAH. You and Christ Druif. I *need* to be at this meeting for sure.
[21:11] <jrgifford> *Chris
[21:11] <Unit193> Meh, you can forget about the first person... :P


[08:22] <handsome_feng> Hi, jbicha, I found that the daily iso pull in the gnome-shell again, and the germinate-output shows that ukui-settings-daemon -> libnotify4 -> gnome-shell in desktop-common, but mate iso is clean although mate-settings-daemon alse depends libnotify, do you have any idea about this?


[09:37] <Saz> hii there
[09:54] <Saz>   well...i started working at computer store - in Africa. My boss wants to move from pirated XP/Vista to Ubuntu so that he doesnt get into trouble. The general clientele are more microsoft familiar. What i need help with is how to promote ubuntu over XP/Vista & aid them in understanding how ubuntu works without confusing them. Furthemore, how to get additional applcaitions which will spice up their experience with ubuntu


[00:27] <Drakeson> is there a guideline or some such that explains what the client-side-decorations patch (against libgtk2.0) does and what APIs have changed?
[02:16] <SoftwareExplorer> I bzr get'ed the softwareproperties source and fixed two depreciation warnings. Then I did a commit, but now I'm a little confused how I would publish my branch to launchpad. My launchpad username is erik-b-andersen.
[02:31] <CynthiaG> SoftwareExplorer: Do you have a branch?
[02:32] <CynthiaG> Registered for yourself on Launchpad, I mean.
[02:32] <wgrant> SoftwareExplorer: You can just say 'bzr push lp:~erik-b-andersen/softwareproperties/SOME-DESCRIPTIVE-NAME'
[02:34] <SoftwareExplorer> I do have a launchpad account. I think I figured out how to do the bzr push thing. (Thanks wgrant for the advice though) Now I'm wondering what the official process is to get my branch merged.
[02:35] <CynthiaG> go to your branch page and hit "propose for merge", then link it to the bug reports it's meant to fix
[02:36] <SoftwareExplorer> CynthiaG: I didn't report a bug, I just noticed the bug and thought I might be able to fix it since it was in python, got the source and fixed it. Should I try to find a bug or file one?
[02:37] <CynthiaG> for such things as warnings, I don't know if you should file a bug or just propose the merge
[02:38] <CynthiaG> post about it on ubuntu-devel-discuss or wait here ~7 hours for someone at Canonical to be there (Euro timezone and start of the work week)
[02:39] <SoftwareExplorer> CynthiaG: What would happen if I propose a merge. Then if I find a bug can't I just mark my branch as fixing it?
[02:40] <CynthiaG> you could do that
[02:40] <CynthiaG> in the bug report, there's also a "link to a branch" option, so you would hit that and add a comment saying "the linked branch fixes this bug"
[02:40] <SoftwareExplorer> CynthiaG: Ok, thanks. I think that's what I'll do then.
[02:41] <CynthiaG> SoftwareExplorer: mk :)
[02:41] <CynthiaG> Wait a minute
[02:42] <CynthiaG> Do you mean "if I find a bug" about the DeprecationWarning, or "if I find a bug" about anything related to softwareproperties?
[02:42] <SoftwareExplorer> CynthiaG:I meant if I find a bug about the two depreciation warnings.
[02:43] <CynthiaG> ok, good - that was just me getting confused a bit
[05:09] <andersk> Are new Debian packages being synced into Maverick automatically, or only updated existing packages?
[05:10] <ScottK> andersk: New ones too, but it's a seperate process that is done less frequently.
[06:43] <hagabaka> Is anyone associated with x-edgers? I am trying to enable r300 gallium on ubuntu using https://launchpad.net/~xorg-edgers/+archive/ppa/ , but after installing the packages and restarting, glxinfo still doesn't say anything about gallium.
[06:48] <Sarvatt> hagabaka: #ubuntu-x
[06:50] <Sarvatt> i run the ppa, will help you out over in that channel
[07:49] <CynthiaG> I just tried the Maverick daily from 2010-06-11 to speed-test it, and the laptop won't boot it :(
[08:00] <mneptok> CynthiaG: #ubuntu+1 please
[08:00] <CynthiaG> Well, this was on-continuous-topic from my prior development on the LiveCD optimisations
[08:00] <CynthiaG> Sorry though
[08:07] <mneptok> CynthiaG: are you looking for support, or to debug it yourself and submit a fix?
[08:08] <CynthiaG> I'm not looking to do anything, because in the time it took me between downloading the daily and trying it out, things may have changed
[08:08] <lifeless> mneptok: CynthiaG is doing dev
[08:08] <lifeless> mneptok: for all that it sounded a bit +1ish :P
[08:08] <CynthiaG> if you want to take a look at what I'm doing, see bug 589629 :)
[08:09] <CynthiaG> cjwatson gave the daily builds the bootchart package, and I was starting Maverick-20100611 to see that
[08:09] <CynthiaG> unfortunately it didn't start
[08:09] <mneptok> CynthiaG: there's no need for that. your initial comment is precisely the kind of support questions -devel gets, and shouldn't.
[08:09] <CynthiaG> Am I off to a bad start in here then?
[08:10] <mneptok> CynthiaG: not in the least.
[08:10] <CynthiaG> Cool :)
[08:11] <mneptok> CynthiaG: there's coffee, donuts, and some half-baked x86 assembly on the table in the corner. help yourself. ;)
[08:11] <CynthiaG> And now re-reading the mksquashfs order file, I see that I have a gnome-specific entry in there; I ideally want this optimisation to work equally well in gnome, kde and xfce :\
[08:11] <pitti> Good morning
[08:12] <CynthiaG> I'm not that fond of coffee :) Thanks for the donuts and the x86 assembly, though! Careful, however, because I might want to optimise it with SSE2 :P
[08:12] <CynthiaG> Good morning pitti
[08:13] <pitti> lifeless: because we switched over to lp:ubuntu/pm-utils-powersave-policy and dropped the custom branch
[08:13] <mneptok> CynthiaG: pfffft ... all the cool kids use PNI
[08:14] <dholbach> good morning
[08:15] <CynthiaG> mneptok: then I must not be a cool kid :) and AcronymFinder isn't helping much with this one
[08:26] <hrw> morning
[08:35] <lifeless> pitti: so the vcs-bzr line should say lp:ubuntu/pm-utils-powersave-policy
[08:35] <lifeless> pitti: it *still has* a vcs location, doesn't it ?
[08:35] <pitti> lifeless: but that's the implied default anyway?
[08:36] <lifeless> pitti: not AFAIK
[08:36] <lifeless> pitti: apt-get source looks at the header
[08:36] <pitti> all packages are supposed to be available like that
[08:36] <pitti> well, many aren't, but that's a bug, not by design
[08:37] <lifeless> pitti: I know, but partner etc won't be
[08:37] <pitti> right
[08:37] <lifeless> pitti: was dropping the header discussed at UDS? I think this needs more thought if it wasn't.
[08:37] <pitti> I don't think it was
[08:38] <pitti> but for packages where we never had a custom branch and just started using the canonoical one we didn't add it either
[08:38] <lifeless> pitti: I'm quite sure our toolchain doesn't default to lp:ubuntu
[08:38] <pitti> apt-get source doesn't, right
[08:38] <lifeless> pitti: could you raise this on ubuntu-devel/u-d-d, or would you like me to ?
[08:39] <pitti> OTOH modifying all packages with a valid import to have a vcs-bzr: seems like a huge effort
[08:40] <pitti> lifeless: sure, go ahead
[08:40] <pitti> but there must be a better way than adding a canonical vcs-bzr everywhere
[08:40] <pitti> unmodified packages have vcs-* from Debian, etc.
[08:41] <pitti> it'd probably be more elegant if a branch could somehow be marked as "valid" or "being used" by a developer, and apt-get source could check that
[08:41] <pitti> a lot of auto-imports are obsolete/broken, those wouldn't be marked then
[08:41] <pitti> OTOH this could be automated as well
[08:41] <pitti> debian/changelog first line -> match version on LP
[08:43] <pitti> lifeless: FYI, for the particular case of pm-utils-p-p it doesn't really matter, the pacakge will be obsoleted by the next pm-utils upload
[08:56] <pitti> cjwatson: WDYT about http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/casper/maverick/revision/817 ? please feel free to revert if you don't like it
[08:57] <lifeless> pitti: well we can look at a script ;)
[08:58] <lifeless> pitti: checkout; commit; done, for branch in lp:ubuntu/
[08:58] <lifeless> pitti: and the unmodified vcs-bzr from Debian is a really interesting thing to consider.
[09:00] <CynthiaG> not much improvement. should a 6-second improvement on boot over 2 minutes be pursued?
[09:18] <pitti> CynthiaG: two minute boot time sounds like a bug on itself
[09:19] <pitti> CynthiaG: I have the slowest possible hard disk on earth and it takes 50s for me (including logging into gdm and ecryptfs)
[09:19] <CynthiaG> pitti: even despite the commonly-known weakness ... oh wait
[09:19] <CynthiaG> you're talking about hard drives
[09:19] <CynthiaG> I'm talking about the LiveCD itself
[09:19] <pitti> ah, I see
[09:19] <CynthiaG> "even despite the commonly-known weakness ... of CD drives when it comes to seeking"
[09:20] <CynthiaG> boot is very noisy, even after changing the order of files around
[09:21] <pitti> CynthiaG: 6 s> I'd say it depends on how much effort it is; a two-minute fix in one package sounds like worth it; reengineering 30 packages for it doesn't
[09:22] <CynthiaG> pitti: it's about bug 589629, which I've been testing lately. It affects one file in livecd-rootfs, plus cjwatson's reordering of the squash file within the ISO so it falls to the end (edge) of the disc
[09:24] <mneptok> CynthiaG: PNI = Prescott New Instructions = SSE3
[09:25] <CynthiaG> mneptok: Ah :) I knew SSE3, but not PNI
[09:25] <mneptok> :)
[10:08] <lool> doko_: Around?
[10:22] <cjwatson> pitti: casper change is fine by me - wasn't there a bug report asking for that, in fact?
[10:24] <pitti> cjwatson: I tried to look at https://edge.launchpad.net/ubuntu/+source/casper/+bugs?batch=300 but didn't spot it
[11:31] <apw> can someone remind me which package had the volume key 'sticky-ness' work arounds in it
[11:34] <ScottK> pitti: Would you please rescore kdebase-workspace kdeedu (only affects ia64)?
[11:39] <cjwatson> apw: does the omap support in linux/maverick supersede the linux-ti-omap source package?  should we be removing linux-ti-omap from maverick, and rebuilding d-i against the omap flavour of linux?
[11:41] <apw> cjwatson, i believe that to be correct yes, let me confirm with ogra
[11:49] <pitti> ScottK: done
[12:03] <apw> cjwatson, yes we should be dropping the separate omap source package in maverick
[12:17] <Q-FUNK> doko_: so you feel that the real issue is with the eglibc build scripts then?
[12:18] <Q-FUNK> doko_: the discussion on the FC bugzilla is convoluted, but did I uderstand this right that eglicb's build scripts are simply more efficient than average at passing optimization flags all the way down to GAS than most other libraries?
[12:36] <pitti> cjwatson: ok, new langpack-locales with using archive and updated scripts uploaded; works fine here, let's see what breaks :)
[12:40] <cjwatson> pitti: cool, thanks!
[13:02] <buxy> cjwatson, seb128: http://lists.debian.org/1276511250.4912.18.camel@seb128-laptop
[13:02] <seb128> buxy, ?
[13:02] <buxy> do you know what kind changes are needed and if/when they can be done?
[13:03] <seb128> buxy, the cdbs changes we have?
[13:03] <buxy> you make it sound like a big blocker
[13:03] <seb128> well, a reason for having diff over debian at least
[13:03] <seb128> right know if works well with cdbs when gnome.mk is used
[13:03] <seb128> because we modify the cdbs gnome.mk in ubuntu for what we need
[13:03] <seb128> which means no source change to do
[13:03] <seb128> but we can't do that with dh7
[13:04] <seb128> there is no standard include we can change this way
[13:04] <seb128> the code there basically do a few things like adding gettext domain to desktop entries
[13:04] <seb128> or cleaning gconf schemas
[13:05] <buxy> seb128: can you open some official launchpad bug and make sure someone is going to offer a solution for dh7 too?
[13:06] <seb128> buxy, we have a workitems from UDS for this already
[13:06] <seb128> so it's tracked
[13:06] <seb128> I'm just not sure how we can solve that in an elegant way though
[13:07] <buxy> "dh --with gnome"
[13:07] <seb128> buxy, one issue I've there is that changing the packaging system is not required when you take something packaged from Ubuntu and upload to Debian
[13:07] <seb128> buxy, well that would require having a sort of "gnome" debian would use for something yes
[13:07] <seb128> then to modify that rules in ubuntu
[13:07] <seb128> or to add a diff in ubuntu "--with gnome"
[13:08] <buxy> seb128: even if only an empty placeholder in debian for a start, I think it's fine
[13:09] <buxy> also I have submitted wishlist bugs against dh to be able to add new sequences without modifying the rules (just modifying the environment)
[13:09] <seb128> ok
[13:09] <buxy> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570935
[13:10] <buxy> seb128: can you give me a pointer to the work item in question?
[13:16] <seb128> buxy, I don't find it now, I think it was in the desktop team workflow changes for maverick discussion we had which didn't get converted in a proper spec, I will have it filed today and give you the bug number
[13:16] <buxy> seb128: thanks
[13:51] <mdeslaur> hmm...while running lucid, "update-manager -d" doesn't give me the update to maverick button...does anyone know why that is?
[13:56] <soren> win 8
[13:56] <zul> mdeslaur: did you talk nicely to it?
[13:57] <mdeslaur> soren: win 9, I win
[13:57] <mdeslaur> zul: I whispered into it's ear
[14:01] <pitti> hm, doesn't work here either
[14:02] <pitti> I bet it's because mvo is on holiday
[14:04] <cjwatson> I imagine it needs somebody to create an entry in the meta-release file
[14:05] <cjwatson> (on changelogs.ubuntu.com)
[15:28] <ogra> Keybuk, hey ... i recently get ureadahead OOM messages on boot with omap beagleboards (it boots fine otherwise and there isnt anything out of ram post-boot) any idea what that could be ?
[15:33] <smoser> hi. i'm looking to pull in a new package 'ebsmount'.  it comes from turnkey linux, it has a (easily removable) dependency on "turnkey-pylib".
[15:33] <smoser> i'd like to remove that dependency and have support from the upstream to do it (replacing it with code in ebsmount itself)
[15:34] <smoser> mostly i just don't want to pull the package in. i'm wondering how dirty that seems to other people and if i should just bite the bullet and pull in both, and file both MIR eventually (as I want them into cloud utils)
[15:34] <smoser> s/cloud utils/cloud images/
[16:18] <Keybuk> ogra: yeah, the kernel picks on ureadahead sometimes
[16:40] <hrw> hi
[17:49] <qense> directhex: Could you take a look at bug #592706, if you have some spare time?
[17:55] <directhex> qense, without looking in detail, it looks like the indicator-application C ABI has changed
[17:56] <seif_> tedg, u there?
[17:56] <seif_> i need u with indicator appler
[17:56] <seif_> applet
[17:56] <tedg> seif_, Yup.  What's up?
[17:56] <seif_> hmmmmm
[17:56] <seif_>  i need a custom applet
[17:56] <pitti> mr_pouit: I'd like to package the current xfce4-power-manager (with upower support), and alongside this https://edge.launchpad.net/libxfce4ui (new requirement; I understand this supersedes the old libxfce4gui)
[17:56] <tedg> seif_, Perhaps #ayatana is a better channel for that though.
[17:56] <seif_> how do i do that
[17:56] <seif_> ok
[17:57] <pitti> mr_pouit: whom should I coordinate with for this?
[18:06] <kees> pitti: I think 587055's eglibc version is going to collide with -security
[18:08] <kees> pitti: or... i am confused and the bug title confused me
[18:14] <mr_pouit> pitti: you want to package it for maverick?
[18:32] <mr_pouit> pitti: anyway, there's already a package in the xubuntu-dev ppa. But it requires libxfce4ui, which is still a development release, so I would rather not put it in an ubuntu release
[19:04] <akheron> I'm using cowbuilder-dist on karmic and trying to build a lucid package; the builder cannot install debhelper, what's wrong?
[19:04] <akheron> is it not possible to build for newer ubuntu versions with cow/pbuilder-dist?
[19:08] <Chipzz> smoser: I just googled ebsmount and looked at its page
[19:09] <Chipzz> now while I don't know the implementation details
[19:09] <Chipzz> that configfile is just... it smells like an fstab line, it quacks like an fstab line, but it's a configfile?
[19:09] <Chipzz> pls tell me I shouldn't facepalm? :P
[19:10] <smoser> config file ?
[19:10] <smoser> ebsmount.conf is not a fstab entry, no.
[19:10] <Chipzz> http://www.turnkeylinux.org/blog/ebsmount , Default configuration
[19:10] <Chipzz> I know it's not
[19:11] <Chipzz> but from how that config file looks, it sounds like it should be?
[19:11] <smoser> the basic intent of the package is to take action on attach or detach of a volume
[19:12] <smoser> its udev rules and then something that implements the hook.
[19:12] <Chipzz> I know I should look at the source code first, but when I see sth like that I pre-emptively take out my biggest cluebat :P
[19:12] <Chipzz> that just looks... horribly misguided
[19:13] <smoser> thats reasonable, yeah.  but it is intended to provide "autorun" like function for EBS devices.
[19:15] <smoser> i'm working with the upstream folks to  make it better.  and we're not opposed to input.
[19:19] <Chipzz> wait, what?
[19:19] <Chipzz> I looked over the biggest SNAFU it appears
[19:19] <Chipzz> "Once a filesystem is mounted, EBSmount will execute scripts located in MOUNTPOINT/.ebsmount in alpha-numeric ordering."
 In its simplest form, the user might want to symlink the mountpoint to a more accessible path, for example:"
[19:20]  * Chipzz facepalms moar
[19:21] <ion> Haha
[19:21] <Chipzz> is. that. not. what. udev. is. supposed. to. do.
[19:21] <Chipzz> ???????
[19:21] <Chipzz> this makes me want to shoot ppl, and I haven't even looked at the source code yet
[19:22] <Chipzz> so basically anyone with write-access to the root of that fs can root your system on the next reboot
[19:22] <Chipzz> congrats, you just made yourself one hell of a security hole
[19:23] <kees> that's ... not in Ubuntu, right?
[19:24] <Chipzz> no, but smoser was proposing it
[19:26] <Chipzz> smoser: pls note that having write access to the root of the fs is not unlikely (I'm guessing)
[19:27] <Chipzz> since we're talking about EBS, it's very like you'll want to mount the partition as, say, /srv for your ftp daemon or apache
[19:27] <cjwatson> kees: if you have a chance to review bug 582189, I'd really appreciate it; I'm pretty close to being blocked on it
[19:27] <Chipzz> now assume your ftp daemon has a bug, you have sloppy permissions, ftp daemon gets exploited and dumps a file in that special dir
[19:28] <Chipzz> next reboot you're rooted
[19:28] <Chipzz> privilege escalation
[19:28] <kees> cjwatson: yup, was going to do an MIR pass today
[19:29] <cjwatson> thanks
[19:35] <smoser> Chipzz, i had realized that that should be disabled by default.
[19:37] <smoser> we'll have to address that somehow.
[19:38] <smoser> regarding "thats what udev is for".. yes, there are udev rules that invoke the mount behavior. the package installs them.
[19:39] <smoser> i completely understand your concerns. i'm interested in suggestions on how to make things safer, yet still provide some of that functionality.
[19:42] <Chipzz> smoser: udev can create symlinks so you have stable device nodes to mount
[19:42] <Chipzz> not sure how exactly ebs works, but it seems that's what should be done
[19:43] <smoser> you're suggesting via udev ?
[19:43] <smoser> the intent is largly to simplify that, and do something with no effort from the user.
[19:43] <Chipzz> like I said, I don't know the exact implementation, but yes
[19:44] <Chipzz> are you serious?
[19:44] <Chipzz> you're proposing opening up a gigantic security hole for the sake of user convenience?
[19:44] <Chipzz> this software is supposed to be installed on a server
[19:45] <Chipzz> if you're administering a server, you're supposed to have some amount of clue
[19:45] <Chipzz> "convenience" should be a non-issue
[19:45] <smoser> i absolutely dont want to open a huge security hole.
[19:45] <smoser> and agree, that as it is, it is open to exploit.
[19:46] <ion> Personally, i’d rather have Upstart run the arbitrary set of commands i want to happen when a certain partition is mounted.
[19:46] <smoser> that said the argument of "this is for a server, some things are difficult" is not valid.
[19:47] <Chipzz> I'm not a udev expert, but may I suggest you talk to Keybuk? He can probably help you beat this piece of missoftware into a usable shape
[19:47] <ion> start on mounted MOUNTPOINT=/foo, task, exec touch /foo/bar
[19:47] <Chipzz> although from what I read on that page, you're probably better off starting from scratch
[19:48] <Chipzz> not much to salvage I figure
[19:51] <smoser> Chipzz, thanks for your input
[19:51] <Chipzz> smoser: really, mount/fstab/udev provide all the pieces of the puzzle
[19:52] <qense> upower detects brightness keys?
[19:52] <smoser> i agree completely.
[19:52] <Chipzz> it just seems upstream lacked the necessary insight and made a kludge of it
[19:52] <smoser> there really isn't much there.  except a bit of config and udev rules written to call something.
[19:53] <smoser> but saying the pieces provide all the functionality doesn't mean that its obvious how to put them together, and the upstream package intent is to put them together for easier use.
[19:53] <smoser> ie, awk, ls, find provide all the functionality for 'du'.
[19:53] <smoser> "upstream" is using those tools.
[19:54] <Chipzz> and opening a gigantic security hole, and depending on python which probably isn't necessary at all, in the progress
[19:55] <smoser> i hardly find "depending on python" to be a concern.
[19:55] <Chipzz> it may be for debian
[19:55] <Chipzz> where you can have a very minimal install without a lot of packages
[19:56] <Chipzz> in case you would ever want to get this functionality into debian
[19:57] <smoser> i find the security concerns more than reasonable, but i'm not teribly concerned aobut a python dependency.
[19:57] <smoser> apt-cache show ubuntu-minimal | grep python
[19:58] <smoser> i'm being serious, though, thank you for your input.
[19:58] <Chipzz> yw
[19:59] <Chipzz> (if depending on python is not a concern to you, maybe the extra package is. but you already mentioned it is :))
[20:00] <ScottK> smoser: python isn't in minimal in Debian, so it is more of a concern there.
[20:00] <Chipzz> btw, I think your comparison to du is the wrong way around :)
[20:01] <Chipzz> smoser: that's exactly what what upstream is doing - implementing du on top of awk, ls, etc...
[20:01] <smoser> thats what i was saying.
[20:02] <smoser> that you were arguing "you have the tools to write 'du', why would you want to include that package itself"
[20:02] <Chipzz> it should just depend on coreutils instead
[20:03] <Chipzz> nevermind, enoughof this conversation already :)
[20:03] <Chipzz> it's 9PM and I'm tired :)
[20:03] <Janey0305> Do Yall know ubuntu?
[20:04] <Chipzz> I think there's room for one last facepalm though ;P
[20:04] <ion> Never heard.
[20:04] <Janey0305> ubuntu/linux
[20:04] <Janey0305> Nobody knows
[20:04] <Janey0305> ?
[20:04] <Chipzz> don't you mean gnu/ubuntu? :)
[20:04] <ion> I don’t think so.
[20:04]  * Chipzz runs :)
[20:04] <Janey0305> Well does anybody know a computer expert
[20:05] <Janey0305> I can chat with
[20:05] <Janey0305> FOR FREE!
[20:05] <Janey0305> lol.
[20:05] <Janey0305> cause I have a issue with sims 2
[20:05] <Janey0305> and i really wanna play it
[20:05] <Chipzz> yes, they're in #windows ;P
[20:05] <Janey0305> but I cant
[20:05] <Janey0305> where do I find that?
[20:06] <Janey0305> im new on here
[20:07] <Chipzz> Janey0305: this channel is about the development of ubuntu, it's not for user support
[20:07] <Chipzz> for user support, if your question is even related to ubuntu, pls join #ubuntu
[20:10] <dobey> anyone around that can do a quick REVU uh, review?
[20:15]  * lamont needs the name of a package uploaded/synced to maverick in the last 2 hours, and doesn't want to dig through his email... anyone got a name?
[20:16] <ion> Does http://blog.gmane.org/gmane.linux.ubuntu.devel.changes.maverick help?
[20:17] <ScottK> lamont: https://launchpad.net/ubuntu/maverick/+source/userconfig/0.9.0-0ubuntu5
[20:17] <lamont> yep. thanks all
[20:50] <pygi> cjwatson, I would have really appreciated at least a poke on bugs like this:
[20:50] <pygi> https://bugs.launchpad.net/ubuntu/+source/libisoburn/+bug/582189
[20:50] <pygi> I know that you all laughed when I recommend those a few years ago, but yea....
[20:52] <pygi> *sigh*
[20:52] <pygi> I'd recommend communicating with upstream in the future if possible :-/
[21:00] <JanC> pygi: that's not really a bug, but just a task/proposal to move those packages from universe to main inside ubuntu?
[21:00] <pygi> JanC, yes, whatever you call it
[21:01] <antonpiatek> Anyone know if there is a way to extract a single file from a source package (without unpacking the entire archive)?
[21:03] <james_w> antonpiatek: there isn't really, as you may have to patch the file, overwrite it with one from elsewhere etc.
[21:04] <james_w> it's not as easy as just poking inside an archive
[21:04] <antonpiatek> james_w, thanks - thought it might be like that
[21:04] <JanC> well, you can extract the unpatched file of course
[21:10] <mathiaz> jcastro: hi!
[21:10] <mathiaz> jcastro: working on bug 471468
[21:11] <mathiaz> jcastro: I've created and linked the bug to the upstream bug tracker
[21:11] <mathiaz> jcastro: what do you recommend to set the Ubuntu bug status to?
[21:11] <mathiaz> jcastro: Fix committed?
[21:12] <jcastro> mathiaz: I would just leave it triaged until you sync next
[21:12] <jcastro> you haven't really committed it to ubuntu per se
[21:13] <mathiaz> jcastro: right - in that case it wouldn't be a sync since it's not reported to Debian, but rather the upstream tracker
[21:13] <mathiaz> jcastro: right - i seem to recall that the desktop team was doing something similar
[21:13] <jcastro> do you get it directly from upstream or from debian?
[21:13] <mathiaz> jcastro: hm - what do you refer to by *it* ?
[21:14] <jcastro> nagios I mean
[21:14] <mathiaz> jcastro: ah - nagios is a package in debian
[21:14] <mathiaz> jcastro: (is that what you meant?)
[21:14] <jcastro> Do you get nagios from debian or do we package it directly from upstream?
[21:15] <mathiaz> jcastro: we get nagios from Debian
[21:16] <jcastro> right, so I think leaving the Ubuntu task "triaged" until the next time it gets synced from Debian that includes that fix makes the most sense
[21:18] <jcastro> mathiaz: basically, how you have it now
[21:23] <mathiaz> jcastro: ok - how do you unsubscribe the review team?
[21:23] <mathiaz> jcastro: (since the patch has been reviewed)
[21:24] <jcastro> mathiaz: I think only someone from the review team can unsub them
[21:24] <mathiaz> jcastro: https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide
[21:25] <mathiaz> jcastro: ^^ says to not unsubscribe the team
[21:25] <jcastro> nigelb: what do we do now?
[21:25] <jcastro> mathiaz: let's just ask him, heh
[21:29] <mathiaz> jcastro: I've read https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide
[21:29] <mathiaz> jcastro: It seems clear to me what needs to be done
[21:52] <mathiaz> bdmurray: hi
[21:53] <mathiaz> bdmurray: is there an API in LP that lists the packages for which a team is a bug contact for?
[21:54] <bdmurray> mathiaz: could you give me an example of a bug contact for a package?
[21:54] <mathiaz> bdmurray: or screen scraping https://bugs.launchpad.net/~ubuntu-server/+packagebugs is still the only option?
[21:55] <mathiaz> bdmurray: ubuntu-server is a bug contact for the apache2 (src) package
[21:55] <mathiaz> bdmurray: I'm working on the following WI: Write script to automatically match ubuntu-server bug contact packagelist with ubuntu-server package set
[21:56] <mathiaz> bdmurray: from https://blueprints.launchpad.net/ubuntu/+spec/server-maverick-uds-seed-review
[21:56] <mathiaz> bdmurray: the goal is to use the packagesset list as the list of bugs the ubuntu-server team should be a bug contact for
[21:57] <mathiaz> bdmurray: may be (or may be not) LP should do that automatically
[21:57] <mathiaz> bdmurray: but for now I'd like to write a script that does that semi-automatically
[21:59] <bdmurray> mathiaz: if you had a list of packages I believe you could just use addBugSubscription for all of them and it would do the right thing wrt to subscribing you to new ones
[22:00] <mathiaz> bdmurray: I can already get a list of packages (using the packagesets API)
[22:00] <mathiaz> bdmurray: however I'd also like to prune the list
[22:00] <mathiaz> bdmurray: ie remove packages that are *not* in the package set
[22:00] <mathiaz> bdmurray: to do that I'd like to have the list of packages the ubuntu-server team is currently a bug contact for
[22:00] <bdmurray> mathiaz: right, well you can't yet move from people to all of their subscriptions
[22:01] <mathiaz> bdmurray: ok - I'll keep screen scraping https://bugs.launchpad.net/~ubuntu-server/+packagebugs
[22:01] <mathiaz> bdmurray: is there a bug filed about adding such an API call?
[22:01] <mathiaz> bdmurray: if not - where should I filed it?
[22:01] <bdmurray> mathiaz: I'm looking
[22:02] <bdmurray> mathiaz: I'm pretty sure bug 331039 covers it
[22:02] <mathiaz> bdmurray: agreed - thanks for the info!
[22:11] <mathiaz> bdmurray: I've looked at https://bugs.edge.launchpad.net/~ubuntu-server/+patches
[22:11] <mathiaz> bdmurray: this is really cool!
[22:11] <mathiaz> bdmurray: how do you select the list of bugs?
[22:12] <mathiaz> bdmurray: are you using the list of packages to which the team is a bug contact?
[22:12] <bdmurray> mathiaz: yes
[22:12] <mathiaz> bdmurray: \o/
[22:12] <mathiaz> bdmurray: another reason to get the packageset synced with the bug contact packages
[22:13] <ajmitch> hopefully exposing IPerson.getBugSubscriberPackages() is enough
[22:14] <bdmurray> mathiaz: I'm not sure where the term 'bug contact' comes from.  I think of it a subscription to bugs about that package.
[22:16] <CynthiaG> The bug contact for a package is the person or team which is automatically marked as subscribed to all bug mail about the package
[22:16] <CynthiaG> Other people may be subscribed to bug mail, but the bug contact is always subscribed
[22:16] <bdmurray> I don't believe there is a singular bug contact though
[22:17] <CynthiaG> Well, different packages and Launchpad projects are going to have different bug contacts yeah
[22:17] <bdmurray> For example https://edge.launchpad.net/ubuntu/+source/apache2 contains multiple bug subscriptions
[22:18] <CynthiaG> None of those are the bug contact
[22:19] <CynthiaG> Oh. Perhaps "bug supervisor" is meant here.
[22:19] <CynthiaG> And "security contact", the person or team notified of private security-related bugs for the package
[22:19] <CynthiaG> bdmurray, mathiaz: ^
[22:25] <CynthiaG> Never mind, bug 331039 *is* about all subscribers to bugs for a certain package, not the "bug contact"
[22:25] <CynthiaG> +packagebugs, etc.
[22:26] <CynthiaG> so for https://launchpad.net/ubuntu/+source/apache2 you would be scraping https://bugs.launchpad.net/ubuntu/+source/apache2/+packagebugs , since the API has nothing about this
[22:26] <CynthiaG> no, wait. you'd be scraping /~USERNAME/+packagebugs
[22:30] <ajmitch> the fix is to extend the API for it :)
[22:31] <CynthiaG> I think there was just confusion over the term 'bug contact' though
[22:31] <ajmitch> this started off at where we are, asking if there was an API equivalent of +packagebugs
[23:48] <mathiaz> kees: hi!
[23:49] <mathiaz> kees: do you have script or know of a lP page that given a source package gives the list of binary packages with their component (main, universe,...)?
[23:50] <kees> mathiaz: I feel like you asked me this in the past.  :)
[23:54] <kees> mathiaz: http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/annotate/head:/security-tools/bin-details
[23:54] <mathiaz> kees: great - thanks!
[23:54] <kees> mathiaz: np :
[23:54] <kees> )
[23:55] <mneptok> the question so nice you ask it twice.
[23:55] <kees> mneptok: heh.
[23:56] <ajmitch> mathiaz: btw, I found there was a branch for that +packagebugs API issue created a few hours ago, so it might get into LP sometime :)
[23:56] <mathiaz> ajmitch: right - I noticed that as well
[23:56] <mathiaz> ajmitch: thanks for linking the branch to the bug
[23:57] <ajmitch> np, I stumbled across it when figuring out how to implement it myself


[04:38] <pitti_> Good morning
[04:45] <RAOF> pitti: Good morning!
[04:46] <Mirv> hello
[04:46] <czajkowski> aloha
[04:46] <pitti> bonjour tout le monde !
[04:47]  * TheMuso waves.
[04:48] <czajkowski> Happy Friday :)
[04:49] <TheMuso> Indeed, and happy bug fix day too. ;)
[04:49] <TheMuso> Well, maybe not fix, but workaround.
[04:55] <desrt> friday already?
[04:55] <desrt> dear lord
[04:55]  * desrt needs to go to bed
[05:05] <pitti> night desrt
[06:02] <didrocks> Mirv: hey! how are you?
[06:04] <didrocks> Mirv: small question on qtsystems: you don't handle the transition from the previous version (with binary packaging containing both the library and the qtdeclaratives one) and the new one with separated binary packages? (I'm fine with that, just in case you published those, some people will maybe be surprised by the upgrade)
[06:04] <didrocks> Mirv: otherwise ack on qtsystem, I can sponsor and new it
[06:04] <didrocks> Mirv: do I have anything else in my queue for you?
[06:05] <didrocks> Mirv: FYI, relaunching unity with "check with whole ppa" so that the tests are taking the latest xorg-server for testing
[06:54] <Mirv> didrocks: hello. right, it's not handling PPA version, but realistically not many have used that inofficial module.
[06:54] <Mirv> (or handling so that PPA version users would get the QML modules)
[06:55] <Mirv> didrocks: the other was lp:~kubuntu-packagers/kubuntu-packaging/qtfeedback-opensource-src + https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2/+files/qtfeedback-opensource-src_5.0%7Egit20130529.orig.tar.gz (reviewed by Ken so far)
[06:55] <Mirv> didrocks: and then handling of the ubuntu-html5-theme https://code.launchpad.net/~timo-jyrinki/cupstream2distro-config/enable_ubuntu-html5-theme_daily/+merge/172958
[06:56] <Mirv> I think that's it for now, I'm waiting for renato to test the new qtpim snapshot and the qtbase patches I just rebased have not been tested either yet, so those shouldn't be sponsored yet
[06:58] <didrocks> Mirv: ok, so I'm sponsoring qtsystems for now
[06:58] <didrocks> Mirv: then, preNEWing ubuntu-html5-theme
[06:59] <didrocks> if good, approving your branch and letting you deploy
[06:59] <didrocks> finally reviewing qtfeedback
[06:59] <didrocks> Mirv: meanwhile, you are handling the dailies?
[07:00] <jibel> good morning
[07:00] <didrocks> salut jibel!
[07:01] <jibel> Bonjour didrocks
[07:01] <Mirv> didrocks: yes, handling those, I was meaning to ask about unity armhf build failure though, does https://launchpadlibrarian.net/144210298/buildlog_ubuntu-saucy-armhf.unity_7.0.2%2B13.10.20130705-0ubuntu1_FAILEDTOBUILD.txt.gz look random failure since the code should be the same you successfully build yesterday evening?
[07:02] <Mirv> or is it because more X got in and now unity fails because of that
[07:02] <didrocks> Mirv: maybe just retry a build in launchpad? (it seems to be a random one)
[07:02] <Mirv> ok.. right LP build retry is cheap
[07:02] <didrocks> Mirv: then, if you relaunch the stack with "check with whole ppa" or "foo" for package, it won't rebuild it
[07:02] <didrocks> Mirv: just taking into account its status
[07:03] <Mirv> yep, I know
[07:03] <didrocks> Mirv: ubuntu-html5-theme will be used by qtcreator, am I right?
[07:06] <didrocks> Mirv: hum, ubuntu-html5-theme should be LGPL, not LGPL3+
[07:08] <Mirv> didrocks: not directly / necessarily, but yes it's depended by qtcreator-plugin-ubuntu. LGPL to be similarly licensed to the plugin, right?
[07:09] <didrocks> Mirv: yeah, we don't do +
[07:09] <didrocks> Mirv: I'll do a MP shortly
[07:09] <didrocks> there are other changes as well
[07:09] <Mirv> ok.. thank you. one thing I was wondering whether to put some sort of license file separately to the img folder, just a text for example to specify that those are CC-BY-SA, since it's only mentioned in debian/copyright now
[07:10] <didrocks> Mirv: yeah, we generally do that
[07:10] <didrocks> it's not mandatory, but we can
[07:10] <didrocks> I have one handy IIRC, one sec
[07:12] <didrocks> hum, it's a CC:BY-SA 2
[07:12] <didrocks> well, let's forget about it for now
[07:14] <didrocks> hum, interestingly those themes includes jquery
[07:21] <mlankhorst> the waiting is on unity now
[07:21] <Mirv> didrocks: one of the examples only, right?
[07:27] <didrocks> Mirv: yep
[07:28] <didrocks> Mirv: do you have the autopilot tests passing for you?
[07:28] <didrocks> for ubuntu-html5-theme?
[07:28] <Mirv> didrocks: yes, they passed
[07:29] <Mirv> 3 tests OK
[07:29] <didrocks> Mirv: ah, it's a bad dep
[07:29] <didrocks> Mirv: the autopilot ones needs the examples
[07:30]  * didrocks fixes
[07:32] <didrocks> Mirv: there is no upstream merger setup, right?
[07:33] <Mirv> didrocks: there is, https://code.launchpad.net/~ubuntu-html5-theme-devs/ubuntu-html5-theme/ambiance
[07:34] <Mirv> daily builds go to SDK Release PPA
[07:34] <didrocks> oh, it's already in stacks/head/sdk.cfg
[07:34] <didrocks> ok
[07:34] <Mirv> yep. or actually, not going to the PPA it seems, but still already there.
[07:35] <didrocks> Mirv: let me add a bootstrap commit as well so that we don't list every commit from rev 1
[07:37] <Mirv> ok
[07:38] <didrocks> Mirv: here we go: https://code.launchpad.net/~didrocks/ubuntu-html5-theme/clean-package/+merge/173147 :)
[07:39] <didrocks> https://code.launchpad.net/~timo-jyrinki/cupstream2distro-config/enable_ubuntu-html5-theme_daily/+merge/172958 approved meanwhile, please deploy once it's merged
[07:39]  * didrocks refreshes the whitelist on the archive admin machine
[07:40] <didrocks> done
[07:40] <Mirv> ok, doing one more rebuild and approving then
[07:40] <didrocks> great :)
[07:40] <didrocks> ok, so now qtfeedback
[07:47] <didrocks> Mirv: qtfeedback5-dev is multiarched
[07:47] <didrocks> it needs I guess:
[07:47] <didrocks> Multi-Arch: same
[07:47] <didrocks> Pre-Depends: ${misc:Pre-Depends}
[07:47] <didrocks> (not the private-dev though)
[07:51] <Mirv> didrocks: ok, fixing
[07:52] <didrocks> Mirv: examples/hapticsquare/hapticbutton.* is LGPL, with blabla, clause, not BSD3 and same for doc/src/snippets/qtfeedbackdocsample/qtfeedbackdocsample.cpp
[07:52] <didrocks> Mirv: apart from that, looks good :)
[07:52] <didrocks> oh sorry
[07:52] <didrocks> one additional stenza in the end :p
[07:52] <Mirv> :)
[07:52] <Mirv> pushed the multiarch change
[07:52] <didrocks> Mirv: perfect then! :)
[07:52]  * didrocks pulls
[07:53] <didrocks> Mirv: thanks! sponsoring as well
[07:53] <Mirv> thanks!
[07:53] <didrocks> (and then NEWing in distro)
[07:56] <seb128> good morning desktopers!
[07:56] <seb128> hey didrocks, Mirv
[07:56] <seb128> qtsystems \o/
[07:56] <didrocks> hey seb128!
[07:56] <didrocks> seb128: and qtfeedback, even if you don't care :p
[07:56] <didrocks> and ubuntu-html5-theme under dailies! :)
[07:56] <seb128> didrocks, don't care about this one :p
[07:56] <Mirv> hey seb128
[07:57] <didrocks> seb128: I preNEWed it FYI, if you see it in NEW
[07:57] <Mirv> seb128: were you planning to sponsor that https://code.launchpad.net/~mitya57/ubuntu/saucy/qtdeclarative-opensource-src/merge/+merge/172054 ?
[07:57] <didrocks> Mirv: maybe we should try just a rebuild of the sdk stack with ubuntu-html5-theme once you deployed the change?
[07:57] <seb128> Mirv, I can do, I didn't have a lock on it but I was planning to if nobody else was beating me to it
[07:57] <Mirv> that looks good, but qtwebkit will probably not go in as is, it probably has the same DPR problem that I had earlier
[07:57] <didrocks> to be done and NEWed before the week-end :)
[07:57] <seb128> Mirv, I will do it this morning
[07:57] <Mirv> didrocks: yes, I will check how it goes
[07:57] <Mirv> seb128: ok, thank you
[07:58] <seb128> didrocks, Mirv: unity tests seem to be happy, that's with the new xorg right?
[07:59] <Mirv> seb128: the tests run yesterday evening were fine, today there was a arm build failure and a rebuild is ongoing in case it was a random failure, at https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4771564
[07:59] <seb128> looks at http://<IP_ADDRESS>:8080/job/autopilot-saucy-daily_release/335/testReport/
[07:59] <seb128> Mirv, ok, thanks
[07:59] <seb128> Mirv, do you have the build log of the build that failed?
[07:59] <Mirv> and then running checks again if the rebuild is fine, after which it can be considered to be published
[08:00] <Mirv> seb128: doh, not anymore, didrocks glanced at it as well
[08:00] <seb128> ok, let's see what the new try gives
[08:00] <lan3y> morning
[08:01] <didrocks> Mirv: it passed this time?
[08:01] <Laney> hrm
[08:01] <Mirv> didrocks: still running
[08:01] <seb128> Laney, good morning ... what was the n3y about? ;-)
[08:01] <seb128> Laney, good morning ... what was the n3y about? ;-)
[08:01] <Laney> must have gotten disconnected overnight
[08:01] <Laney> happy friday!
[08:02] <didrocks> Mirv: ok, maybe we can start the tests meanwhile to not loose time (as i386 is built), mind running with check with whole ppa to dist-upgrade and getting new xorg?
[08:02] <didrocks> happy Friday Laney!
[08:02] <Mirv> didrocks: ok, doing
[08:02] <didrocks> thanks ;)
[08:02] <Mirv> (and makes sense)
[08:02] <didrocks> Mirv: that will be an issue I guess if one day we start running the tests on slower archs to build…
[08:02] <didrocks> (like on the phone, so need to wait for armhf to be available)
[08:03] <seb128> Laney, happy friday! ;-)
[08:03] <didrocks> ok, unity - armhf build seems to have gone further in the build than where it failed
[08:06] <Mirv> didrocks: any idea why ubuntu-html5-theme fails trying to fetch revision 57 (the neweest revision is 56)?
[08:06] <Mirv> and yes, redeployed and issues a run now
[08:07] <Mirv> didrocks: should the bootstrap have been '55' instead of '56'?
[08:07] <Mirv> (the code has last_upstream_rev + 1)
[08:08] <didrocks> oh oh oh, you're rgith
[08:08] <didrocks> right*
[08:08] <didrocks> I should have set 55…
[08:09] <didrocks> Mirv: let me do a dummy commit if you don't mind? (changing the rev would be the same anyway)
[08:11] <Mirv> didrocks: ok!
[08:11] <didrocks> Mirv: ok, you can relaunch now, sorry for that :)
[08:11] <Mirv> thanks, np!
[08:23] <pitti> bonjour didrocks, seb128, et Laney
[08:23] <pitti> hey Mirv
[08:24] <pitti> Laney: hm, I got disconnected as well; perhaps it was freenode and not our proxies then
[08:24] <seb128> pitti, salut, ca va bien ?
[08:24] <Laney> I tend to blame freenode rather than my VPS provider in such situations :P
[08:24] <pitti> seb128: oui, merci
[08:24] <Laney> ps. hey, happy friday!
[08:24] <Laney> got good weekend plans?
[08:24] <pitti> seb128: et toi ? as-tu l'été maintenant ?
[08:24] <Mirv> hei pitti
[08:25] <seb128> pitti, ça va, non ... mais normalement l'été arrive cette après-midi ou demain
[08:25] <seb128> et toi ?
[08:25] <pitti> Laney: aye, a wedding from a friend of mien
[08:25]  * seb128 plans to enjoy the nice weather this w.e (if the forecast is correct)
[08:25] <pitti> seb128: 20 degrees and dry, what more can I ask for..
[08:25] <seb128> oh, maybe try to watch the wimbledon's final on sunday
[08:26] <seb128> (try because I'm not sure they are going to broadcast on public channels here and I'm not subscribed to the privates that have the rights)
[08:27] <Laney> forecast 26 and 27 here(!)
[08:28] <seb128> nice!
[08:28] <seb128> same here ;-)
[08:30] <Laney> bah, what's up with update-apt-xapian-index
[08:32] <Laney> bug #1118888
[08:32] <ubot2`> Launchpad bug 1118888 in apt-xapian-index (Ubuntu) "/usr/sbin/update-apt-xapian-index crashes daily" [Undecided,Confirmed] https://launchpad.net/bugs/1118888
[08:32] <Laney> broke cdimage builds and i got it on dist-upgrade too
[08:33] <darkxst> seb128, hi
[08:33] <seb128> where is mvo? hidding? :p
[08:33] <seb128> darkxst, hey
[08:33] <darkxst> I uploaded g-s-d 3.8 with a slightly patched g-c-c 3.6 to ppa:darkxst/gsd38
[08:34] <darkxst> ibus is disabled and no keyboard indicator
[08:34] <darkxst> lid close actions for power panel are gone
[08:35] <darkxst> otherwise everything else should work like, screenshots, media keys and automount helper
[08:37] <Laney> bug #1038429
[08:37] <ubot2`> Launchpad bug 1038429 in software-center (Ubuntu) "update-software-center crashed with order (MRO) for bases SafeConfigParser, object in __new__()" [Medium,Confirmed] https://launchpad.net/bugs/1038429
[08:38] <Laney> indeed something pulled python-configparser in with this dist-upgrade
[08:42] <seb128> Laney, right, I got that one installed as well
[08:42] <seb128> darkxst, why is the lid action dropped?
[08:43] <darkxst> seb128, I think the settings are dropped from g-s-d
[08:43] <seb128> hum, we need to add them back then
[08:45] <darkxst> seb128, https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=58cb4eee64bbd8ca43111b1f80fdaacde8ad5f12
[08:45] <darkxst> but I suppose there is more than that
[08:46] <Laney> didn't it move to logind?
[08:47] <seb128> Laney, the suspend/hibernate did, but isn't g-s-d supposed to keep inhibitors to prevent suspend in case it's needed?
[08:47] <seb128> or is there equivalent config options for logind?
[08:47] <seb128> pitti, ^
[08:49] <pitti> seb128: sorry, missing the original question
[08:49] <pitti> oh, question from darkxst?
[08:49] <seb128> pitti, in a logind world, can we configure what to do on lid close?
[08:49] <seb128> like suspend if on battery, don't if on a/c
[08:49] <pitti> seb128: sure; didn't I fix that like two weeks ago?
[08:50] <Laney> It's about the 3.8 upstream behaviour
[08:50] <pitti> seb128: the g-c-c UI and gsettings keys are supposed to work
[08:50] <pitti> ah
[08:50] <pitti> does 3.8 remove the lid config behaviour from g-c-c?
[08:50] <pitti> apparently so
[08:51] <seb128> pitti, well, part of the lid config was an Ubuntu patch to start
[08:51] <seb128> but yeah, they removed some of the keys
[08:51] <seb128> e.g https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=58cb4eee64bbd8ca43111b1f80fdaacde8ad5f12
[08:51] <pitti> seb128, darkxst: there's /etc/systemd/logind.conf for its default behaviour for lid switches, but that's not supposed to be for UIs, but for what happens on VTs or if nobody is logged in
[08:57] <darkxst> I disabled the lid close patch from g-c-c 3.6 because the keys don't exist anymore
[08:57] <seb128> Laney, do you watch emails for merge requests or do you prefer IRC pings? ;-) (on system settings)
[08:57] <seb128> darkxst, we should probably revert those changes...
[08:57] <Laney> I do see the emails but I don't always do them straight away
[08:57] <Laney> so every now and again I check lp
[08:58] <seb128> Laney, well, no hurry, I can wait some hours ;-)
[08:58] <Laney> I want to address the review comments on CrossFadeImage first
[08:58] <seb128> Laney, just send one using the newly landed qtsystem to get the disk space
[08:58] <pitti> darkxst: yeah, my patch to 3.6 was because 3.6 doesn't yet get along with the current logind behaviour; it's not needed for 3.8
[08:58] <Laney> cool!
[08:58] <seb128> Laney, wfm, good luck with that ;-)
[08:58] <pitti> darkxst: so it seems gnome 3.8 just dropped teh configurability of that :(
[08:59] <darkxst> pitti, for now just looking g-s-d 3.8 with g-c-c 3.6
[08:59] <pitti> darkxst: hm, then you will have the config panel for that which won't do anything?
[09:00] <pitti> darkxst: doesn't that crash on the missing gsettings keys?
[09:00] <darkxst> pitti, yes
[09:00] <darkxst> pitti, no I disabled the patch
[09:00] <pitti> darkxst: ah, you reverted 58cb4e?
[09:00] <pitti> that'd do it
[09:00] <seb128> he dropped the g-c-c patch that add the config UI rather I think
[09:00] <darkxst> pitti, the ubuntu patch that add lid close boxes
[09:00] <seb128> (those UI are an ubuntu patch)
[09:00] <pitti> aah
[09:00] <pitti> I forgot about that
[09:00] <seb128> but we added the patch for a reason
[09:01] <Laney> so I can see why gnome may have dropped it if they didn't have UI for it
[09:01] <seb128> we want that configurability...
[09:01] <pitti> but yeah, there was some discussion with upstream about making that configurable as our users got angry about removing it
[09:01] <mlankhorst> seb128: but I think the xorg side is ready now, just waiting for unity
[09:01] <seb128> mlankhorst, unity is still building on armhf: https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4771564
[09:01] <mlankhorst> ok
[09:01] <darkxst> seb128, pitti : so, how do we handle that w/ logind?
[09:02] <pitti> darkxst: what is "that"?
[09:02] <Laney> seb128: Just quickly looking at the diff - surely you can avoid repeating that division so much :P
[09:02] <seb128> mlankhorst, btw looking at our versions page, how come we are behind debian on libx11/libxrandr/libxcb versions?
[09:02] <darkxst> pitti, lid close action
[09:02] <pitti> darkxst: I guess you just disable our g-c-c patch to add configurability for it, and drop the g-s-d patch for inhibiting logind
[09:03] <seb128> Laney, the getFormattedSize function? I just moved that, it was already in :p
[09:03] <pitti> darkxst: with upstream g-s-d 3.8 and current logind it should just work and suspend on lid close
[09:03] <seb128> Laney, I copied the function from the qtsystem example ... but I can change it if wanted ;-)
[09:03] <darkxst> pitti, that is exactly what I have done
[09:03] <Laney> doing / 1000 loads of times on the same value seems like it could be optimised
[09:03] <Mirv> unity autopilot tests failed again, a diff compared to the one run 4 hours ago: http://pastebin.ubuntu.com/5846095/
[09:03] <mlankhorst> seb128: I didn't want to update everything at once, so I mostly waited for new x1.14 first.
[09:03] <seb128> pitti, darkxst: I don't want suspend on lid close!
[09:03] <seb128> mlankhorst, ok
[09:04] <Mirv> seb128: unity AP ^
[09:04] <pitti> seb128: well, it's what gnome 3.8 does, so for ubuntu-gnome that seems right?
[09:04] <Mirv> seem preview navigation related
[09:04] <seb128> Mirv, shrug, seems like an issue with the dash previews :/
[09:04] <pitti> seb128: are we talking about ubuntu-gnome here, or about updating ubuntu's g-s-d to 3.8?
[09:04] <seb128> pitti, updating g-s-d to 3.8 in saucy (which darkxst is working on)
[09:05] <pitti> seb128: aaah -- I assumed we talked about ubuntu-gnome
[09:05] <seb128> pitti, well, Ubuntu GNOME wants the new version and they build from the archive
[09:05] <seb128> so they need it in the archive...
[09:05] <pitti> seb128: well, we certainly do want to forward-port our UI patch then, and revert the g-s-d patches which dropped these keys?
[09:05] <Mirv> didrocks: do you think yet another autopilot run should be tried? http://pastebin.ubuntu.com/5846095/ - compared green run 4:05:34 to this failed one 8:03:06
[09:05] <seb128> pitti, right, the initial question was "is there a new way to do that with logind, or should we revert the drop in g-s-d"
[09:06] <pitti> seb128: logind can't and won't read gsettings
[09:06] <didrocks> Mirv: hum, the failures seem to be on both configuration though? weird that flacky tests are failing the same way at the same time
[09:06] <seb128> pitti, so it's still g-s-d that should "play" with inhibitors?
[09:06] <pitti> seb128: we can globally disable it in logind.conf of course, but otherwise it should be under g-s-d's control
[09:06] <didrocks> Mirv: oh, it can be that the network connexion is suddenly bad in the QA datacenter?
[09:06] <pitti> seb128: yes
[09:06] <didrocks> jibel_: does this sound possible? ^
[09:06] <seb128> ok, makes sense
[09:06] <seb128> pitti, thanks
[09:06] <didrocks> (as it's the previews)
[09:06] <Mirv> ah, the previews are slow when network throttles, true
[09:06] <pitti> seb128: the logind suspend on lid is really supposed to just be a fallback if there is no session running (VT, lightdm)
[09:06] <seb128> didrocks, Mirv: where are the screencasts of those?
[09:07] <pitti> seb128: (same with the power button)
[09:07] <didrocks> seb128: no more screencast by now for unity tests
[09:07] <seb128> didrocks, that's why I couldn't find them yesterday :p
[09:07] <didrocks> seb128: this is what makes the machine exploding (recordmydesktop)
[09:07] <seb128> pitti, alright, that works for me, thanks!!
[09:07] <didrocks> jibel_ looked for better setting than "take 8G of ram)
[09:07] <seb128> darkxst, so we need to revert the feature drop in g-s-d and re-enable the g-c-c patch
[09:08] <didrocks> Mirv: let's wait for jibel's feedback?
[09:08] <Mirv> ok
[09:08] <darkxst> seb128, ok
[09:09] <Mirv> good to know, I was also wondering where the screencasts went
[09:09] <seb128> darkxst, thanks for the work on that btw! ;-)
[09:09] <darkxst> np
[09:09] <didrocks> Mirv: yeah, rdm sucks and fragment all the mem :/
[09:09] <didrocks> that's what made the dbus hang and so on…
[09:09] <didrocks> (it's still enable for other tests)
[09:10] <didrocks> but we need to find better settings than what the QA team picked
[09:10] <didrocks> (in autopilot)
[09:12] <jibel> didrocks, I don't see any connectivity issue in the lab
[09:13] <didrocks> jibel: all the previews failed on both config
[09:13] <didrocks> same build ran previously
[09:13] <didrocks> it can be the server as well
[09:13] <didrocks> Mirv: maybe try relaunching? (you need to stop the build monitoring first)
[09:13] <didrocks> Mirv: and let's blame the server? :p
[09:14] <jibel> didrocks, maybe there was but it is no more
[09:14]  * pitti uploads pkg-create-dbgsym to ignore the transitional unity-2d-dbg and thus produce proper dbgsym again
[09:14] <didrocks> ok, let's see the new run :)
[09:14] <pitti> seb128, didrocks ^ FYI
[09:14] <didrocks> thanks pitti!
[09:14] <pitti> it's a heuristic hack, but *shrug*
[09:15] <pitti> it depends on those packages having "transitional" anywhere in their description
[09:15] <pitti> (as I can't inspect their contents)
[09:16] <Mirv> didrocks: ok
[09:18] <Mirv> here we go again. maybe during this the arm build also finishes.
[09:18] <seb128> pitti, great!
[09:18] <jibel> didrocks, as for OOM, systems have been running for 24h running unity testsuite several time and the state of the systems is good. That confirms recordmydesktop was the problem
[09:19] <seb128> jibel, we miss the recording though, we have no idea what's happening with the previous there :/
[09:20] <pitti> Schroedinger's test!
[09:20] <seb128> hehe
[09:21] <jibel> seb128, I understand that, but using rmd kills the systems, if you know an alternative to rmd that push less pressure on the test host, I'm happy to patch autopilot
[09:21] <seb128> jibel, hum, but I don't... ;-)
[09:22] <Laney> there are alternatives like kazam but I don't know how they stack up
[09:24] <pitti> jibel: is that the giant memory leak you talked about which doesn't ever go away even with module unloading etc?
[09:24] <jibel> pitti, not a leak but memory fragmentation
[09:25]  * didrocks pulled a new version of cupstream2distro, if you see any prepare/publish job failing. (I've patched the existing .project files to be compatible)
[09:25] <didrocks> seb128: Mirv, FYI ^
[09:25] <seb128> didrocks, ok
[09:26] <jibel> pitti, but yes, after a run of unity with rmd enabled there are ~4GB of RAM that are never reallocated
[09:26] <seb128> didrocks, Mirv: unity armhf build worked \o/ (well, it's building the debs)
[09:26] <didrocks> seb128: phew!
[09:26] <seb128> " Built successfully"
[09:26] <seb128> \o/
[09:32] <jibel> a solution could be to run without rmd and when a test fail re-run it with rmd. there is the case of unstable tests but we can either find a way to mark them unstable or just mark them failed.
[09:37] <Mirv> \o/
[09:54] <Riddell> didrocks: don't you love us any more? :(
[09:55] <didrocks> Riddell: too many FTBFS in my inbox from that ppa, and TBH, I don't really use that team perms
[09:55] <didrocks> Riddell: still having access to ~kubuntu-packagers, right?
[09:56] <didrocks> (yep, through core-dev)
[09:56] <Riddell> yeah you're still elite :)
[09:57] <didrocks> ahah :)
[09:58] <seb128> Laney, I opened https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1198116 for info
[09:58] <ubot2`> Ubuntu bug 1198116 in Ubuntu UI Toolkit "[ListItems] Recent update changed the ListItem.Base margins" [Undecided,New]
[09:58] <seb128> Laney, I find the buttons (e.g "Check for updates" in the about panel) a bit too big since the update
[09:59]  * Laney goes blind at the orange buttons
[09:59] <Laney> well noticed
[09:59] <seb128> that as well...
[09:59] <Laney> that's design btw
[09:59] <Laney> I filed a bug on that and it got closed as invalid
[09:59] <seb128> the orange or the margin?
[09:59] <Laney> orange
[09:59] <seb128> :-(
[10:00] <seb128> you combine the small margin and the orange and you get "in your face" buttons :/
[10:50] <Mirv> the dash preview tests still failed :( http://pastebin.ubuntu.com/5846307/ (compared to the last fail)
[10:50] <Mirv> and some new tests as well, pretty random some of them
[10:53] <seb128> Mirv, did you try to run the preview tests locally?
[11:00] <davmor2> Hey guy on Saucy I noticed that recently software updater is only showing it's icon in the launcher for the initial window after it is displaying a python logo instead http://ubuntuone.com/2ou2Mr66aE9feaFUT2UHuF
[11:00] <Mirv> seb128: not yet, have to telco now, will try later with english locale (often useful)
[11:24] <Mirv> seb128: yep, seems to work locally with both the previous build and this one
[11:25] <seb128> so why does it fail on the jenkins :/
[11:26] <Mirv> meanwhile, ubuntu-html5-theme built but autopilot tests fail, I see the problem and trying to fix it shortly
[12:15] <didrocks> Mirv: want me to review your ubuntu-html5-theme branch (for the AP test) if you have any handy?
[12:16] <Mirv> didrocks: not yet, I'll ping if needing (alex is soon awake as well)
[12:18] <didrocks> ok :)
[12:46] <mlankhorst> booo, why are some libs still not m-a: same in saucy
[12:46] <mlankhorst> it makes it hard to coinstall all the gstreamer0.10 plugins
[12:53] <czajkowski> is this her first?
[12:53] <czajkowski> bah
[14:04] <jbicha> mpt: what does "Require my password when switching screen on" mean in the first screenshot of https://wiki.ubuntu.com/SecurityAndPrivacySettings
[14:05] <seb128> jbicha, hey, it's likely "lock on idle"?
[14:05] <seb128> e.g after idle time: turn off the screen and lock it
[14:06] <mpt> jbicha, I actually don't remember
[14:06] <mpt> Maybe it's "Returning from screen saver"?
[14:06] <jbicha> ok, I'm wanting to move the Screen Lock ON|OFF and Lock after _ minutes settings there too since gnome-control-center 3.8 moves those settings to their own privacy panel
[14:08] <mpt> Makes sense
[14:08] <mpt> (so long as screensaver settings themselves are a disaster, at least)
[14:09] <mpt> jbicha, what does "Screen Lock ON|OFF" do?
[14:10] <jbicha> org.gnome.desktop.screensaver lock-enabled
[14:11] <mpt> Is that equivalent to "Require my password when returning from screen saver"?
[14:11] <jbicha> yes I believe so
[14:11] <mpt> Overuse of on/off switches strikes again :-]
[14:13] <jbicha> well you can do nearly whatever you like what panel now since it's independent of gnome-control-center
[14:13] <mpt> right
[14:13] <mpt> So a "Returning from screen saver" checkbox at the bottom of that group would make sense
[14:14] <mpt> And then the time setting below that, perhaps?
[14:14] <mpt> though not indented, since it's not actually dependent
[15:34] <seb128> Laney, https://code.launchpad.net/~seb128/ubuntu-system-settings/serial-not-available/+merge/173229 (fyi)
[15:34] <seb128> kenvandine, you forgot to change the MR status?
[15:35] <Laney> cheers
[15:35] <Laney> that crossfadeimage stuff swallowed most of this day :/
[15:37] <kenvandine> seb128, no i didn't
[15:37] <kenvandine> was waiting for CI
[15:37] <kenvandine> https://code.launchpad.net/~ken-vandine/signon-plugin-oauth2/arches/+merge/173233
[15:37] <kenvandine> seb128, can you review that?
[15:38] <kenvandine> i need that to land so i can unblock cjwatson
[15:38] <Laney> I thought we were letting stuff just fail to build / depwait on ppc
[15:39] <kenvandine> Laney, long story :)
[15:40] <seb128> kenvandine, ok, approved on the basis that I trust you :p
[15:40] <seb128> kenvandine, you need to change the status I can't
[15:41] <jbicha> will there be an updated Unity today or will it wait for Monday?
[15:41] <didrocks> jbicha: we are trying hard to get one passing tests
[15:41] <seb128> jbicha, why?
[15:41] <didrocks> jbicha: but we maybe have a clue that enabling -proposed block things
[15:41] <seb128> jbicha, do you need something?
[15:41] <jodh> desrt: I'm looking at the doc for the d-conf "changed" signal which states, "Appending each item in changes to prefix will give the absolute path of each changed item."
[15:41] <jodh> desrt: presumably, that should say to stick a '/' between the prefix and each changes item right?
[15:41] <jbicha> no, I used -proposed to try the new X and I don't feel like adding a PPA to get Unity back
[15:42] <jbicha> I'm also fine with Unity staying in -proposed over the weekend
[15:42] <seb128> jbicha, it's likely what will happen
[15:45] <Laney> dobey: Did you see the bug I assigned to you? Reckon you'll be able to get to it?
[15:45] <dobey> what bug?
[15:46] <Laney> https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/1038429
[15:46] <ubot2`> Ubuntu bug 1038429 in software-center (Ubuntu Saucy) "update-software-center crashed with order (MRO) for bases SafeConfigParser, object in __new__()" [Critical,Confirmed]
[16:17] <seb128> ok, just pushed another mr, and on that note time for some exercice
[16:17] <seb128> be back in an hours to read scrollback/clean emails and stuff and then calling it a week
[16:17] <seb128> having a good w.e for those who will be off by then ;-)
[16:21] <didrocks> see you later seb128!
[16:21] <didrocks> Laney: so, I'm trying now unity + new xorg from proposed without dist-upgrading
[16:21] <didrocks> as we were impacted by this software-center issue
[16:22] <didrocks> I hope to get the results in ~20 minutes
[16:22] <didrocks> if good, I'm going to publish unity into proposed
[16:22] <didrocks> a shame that we lost maybe the whole day of publishing unity due to software-center :/
[16:22] <didrocks> bregma: pstolowski: dednick: FYI ^ (I'll keep you posted)
[16:23] <bregma> sweet
[16:23] <pstolowski> didrocks: thanks
[16:23] <didrocks> the result on intel is promissing
[16:23] <didrocks> 6 failures
[16:23] <Laney> cool
[16:23]  * didrocks waits and stare at ati
[16:23] <Laney> I hope the s-c fix can be done today ...
[16:24]  * didrocks hopes as well, as long as previews are default for the desktop, people will notice :p
[16:25] <Laney> didn't get any confirmation it's being worked though
[16:26] <pstolowski> didrocks: people will notice previews for apps are now super fast and will be happy :)
[16:26] <didrocks> pstolowski: ahah, true! :)
[16:26] <didrocks> bregma: my only positive ":)" with this day for unity lost is that we found brandon's regression that we won't have noticed I guess otherwise…
[16:27] <bregma> he's been sent back to the drawing board on that one
[16:27] <didrocks> heh
[16:30] <didrocks> pstolowski: bregma: ati: 9 failures
[16:30] <didrocks> ok, so publishing unity into proposed
[16:30] <pstolowski> \o/
[16:30] <Laney> on a FRIDAY EVENING!
[16:30] <didrocks> Laney: on a f*** friday evening :)
[16:31] <Laney> funn
[16:31] <Laney> :P
[16:31] <didrocks> Laney: with the amount of run it had, I'm trustful :)
[16:31] <Laney> sounds like we've both had a day of tussles then
[16:31]  * Laney glares at qt/qml
[16:31] <pstolowski> that mean weekend! :) have a nice one and see you!
[16:31] <didrocks> Laney: well, s/day/days/ TBH
[16:32] <didrocks> pstolowski: have a nice one as well :)
[16:46] <didrocks> bregma: Laney: unity published FYI
[16:46] <Laney> great!
[16:46]  * bregma goes to upgrade
[16:46] <didrocks> Laney: not sure if you want to unblock that from proposed
[16:46] <didrocks> bregma: wait for a publisher cycle maybe :p
[16:47] <Laney> I'll test dist-upgrade it and probably just do it if so
[16:47] <mlankhorst> oh finally unblock time then? :P
[16:49] <Laney> muhahah
[16:49] <Laney> grrrrrrrr
[16:49] <Laney> I wonder if it'll be hard to port indicator-applet
[17:01]  * didrocks waves good evening and enjoy a nice week-end!
[18:09] <jbicha> you guys know indicator-datetime is broken right?
[19:07] <seb128> jbicha, no, how so?
[19:08] <jbicha> seb128: bug 1197647
[19:08] <ubot2`> Launchpad bug 1197647 in indicator-datetime (Ubuntu) "Date & Time applet in control center does not start" [High,Confirmed] https://launchpad.net/bugs/1197647
[19:09] <seb128> jbicha, hum, fun
[19:10] <seb128> larsu, ^ friday indicator breakage
[19:11] <kenvandine> we just love friday breakage
[19:13] <seb128> seems so
[19:38] <desrt> jodh: no.  it is written as it is to be read.
[21:43] <larsu> jbicha: indicator-datetime installs the panel into /usr/lib/x86_64
[21:43] <larsu> g-c-c doesn't look there
[21:43] <larsu> and instead thinks "this might be an external panel, let's execute its Exec line"
[21:44] <larsu> which is where it loops
[21:45] <jbicha> larsu: ok but what about the missing clock?
[21:45] <czajkowski> clock is not displayed on default clean install on saucy, didnt notice it til I went and added it there
[21:45] <larsu> jbicha: missing clock?!
[21:46] <larsu> jbicha: ah, the clock in the panel. Don't know, I can investigate that. It's probably a different issue though
[21:48] <Guest17995> the datetime panel (libindicator-datetime.so) used to be installed in /usr/lib/control-center-1/panels
[21:48] <larsu> Guest17995: right, I'm trying to find out since when it doesn't anymore
[21:48] <charles> ya
[21:48] <jbicha> czajkowski: um how do you add the clock?
[21:49] <czajkowski> I went to date and time settings
[21:49] <charles> larsu: it's in /usr/lib/contrl-center-1 in stock 13.04
[21:49] <czajkowski> and added it from there
[21:49] <czajkowski> now I'm stuck in some irritating loop under settings
[21:49] <charles> and Makefile.am hasn't changed...
[21:50] <larsu> charles: right, probably the packaging sets libdir differently
[21:50] <larsu> but I can't find when this would have happened
[21:50] <larsu> cyphermox: any idea? ^^
[21:50] <jbicha> czajkowski: when that happens here, I do sudo /usr/bin/gnome-control-center /usr/bin/gnome-control-center2, kill g-c-c and then move it back
[21:50] <charles> not much churn in debian/ either
[21:51] <cyphermox> what?
[21:51] <cyphermox> no idea
[21:53] <larsu> jbicha: killall gnome-control-center works as well
[21:57] <jbicha> larsu: it looks like the build changed between June 19 and June 28
[21:59]  * jbicha looks suspiciously at rev. 229
[22:00] <charles> that's suspicious because it's the only change to data/Makefile.am
[22:00] <larsu> jbicha: ya, that's it
[22:00] <larsu> charles: using libdir now, where before it used pkg-config
[22:01] <charles> larsu: I don't see how that's related to the panel install, though?
[22:02] <larsu> charles: pkg-config was used for gnome-control-center as well...
[22:02] <larsu> which is wrong, because multiarch
[22:03] <charles> oh, ya of course. I'm looking at data/Makefile.am but the bug is in src/Makefile.am
[22:04] <larsu> yep
[22:04] <larsu> so we have two options:
[22:04] <charles> yeah that's it, the line 3 change in src/Makefile.am r229
[22:04] <larsu> (1) de-multiarch indicator-datetime
[22:04] <larsu> (2) teach g-c-c about multi arch panels
[22:05] <larsu> I guess (2) doesn't make sense until g-c-c itself it multiarch
[22:07] <larsu> charles: (1) will be easier for now :)
[22:08] <charles> hmm
[22:09] <charles> so we would replace $(libdir)/control-center-1/panels/ with... what?
[22:09] <jbicha> charles: https://bazaar.launchpad.net/~indicator-applet-developers/indicator-datetime/trunk.13.10/revision/229
[22:09] <charles> you and seb128 and desrt seemed pretty adamant about removing local-install mode
[22:10] <larsu> charles: leave that as is, we should change the *package* to be single arch
[22:10] <charles> jbicha: right. I meant, do we want to revert it and re-introduce that feature that everyone was against, or is there a different change s.t. we avoid reintroducing it
[22:10] <larsu> charles: a multi-arch package that then installs something into /usr/lib is wrong anyway
[22:11] <larsu> jbicha: how düo I make a package single arch? Change "Architecture: any" to ... what?
[22:14] <jbicha> in this case I think you just need to revert the part of that commit you don't want
[22:14] <larsu> jbicha: no, that code was wrong
[22:15] <larsu> installing into /usr/lib/ is the wrong thing for multiarch
[22:45] <Laney> It's not multiarched
[22:46] <Laney> that's Multi-Arch: something in debian/control
[22:46] <Laney> It's because you have debian/compat set to 9 which does this, from debhelper(7):
[22:46] <Laney> Multiarch support. In particular, dh_auto_configure passes multiarch directories to autoconf in --libdir and --libexecdir.
[22:46] <Laney> larsu: ^
[22:50] <Laney> and this being a thing debhelper wants to do in the face of multiarch makes me feel that g-c-c should look in that directory too
[22:52] <Laney> jbicha: where do you see the missing clock?
[23:18] <jbicha> Laney: I don't have a clock in Unity's top right corner, bug 1197647 says I'm not alone
[23:18] <ubot2`> Launchpad bug 1197647 in indicator-datetime (Ubuntu) "Date & Time applet in control center does not start" [High,Confirmed] https://launchpad.net/bugs/1197647
[23:20] <Laney> ah, in unity - don't know then
[23:20] <Laney> I know that indicator-applet doesn't handle the new-style indicators (yet?)
[23:34] <m4n1sh> mpt: when you are free, can you please check your mail


[00:06] <broder> hallyn: ping? around?
[00:08] <broder> actually, unping
[00:09] <broder> we need a better way to keep track of contributors than the changed-by line. it sucks that i can only give one person credit for a change in a way that we can easily collate automatically
[00:12] <broder> anybody with some upstart-fu around? i'm trying to figure out the semantics of calling "stop;" from within an upstart script
[00:22] <User_007> hello, i made some changes in a package source and i want to upload it to my ppa, how can i generate a .changes so i can upload it?
[00:23] <broder> User_007: you can run "bzr bd -S" if you're using a bzr branch, or "debuild -S" otherwise
[00:26] <User_007> broder, i only have the modified code, how do i create a .changes?
[00:27] <broder> User_007: do you mean that you only have a diff, as opposed to a full package?
[00:35] <crossfader> hi
[00:35] <crossfader> ich weiss ja nicht, ob grad jemand da ist, der sich damit auskennt...
[00:36] <broder> !de | crossfader
[00:36] <crossfader> ich will meinem kernel klar machen, dass er das root-fs über nfs zu ist
[00:36] <crossfader> oops
[00:36] <crossfader> sorry
[00:36] <crossfader> joined the wrong channel
[00:36] <broder> no problem :)
[00:36] <crossfader> anyway, meybe you can help me
[00:36] <broder> just wasn't sure whether you spoke english, and the bot's german is better than mine :-P
[00:37] <crossfader> i try to boot my kernel into an nfs root-filesystem
[00:37] <DawnLight> how come user processes are children of init directly? i would expect them to be children of gnome-session of unity or whatever
[00:37] <User_007> broder,  sorry i only have the modified source, i mean, i downloaded the .orig.tar.bz extracted it and made my changes. Can you point me a step-by-step?
[00:38] <broder> User_007: have you looked at http://developer.ubuntu.com/packaging/html/fixing-a-bug.html ? it has a good walkthrough for how to get the source and make a change to it
[00:38] <broder> you need more than just the orig.tar.bz
[00:38] <User_007> thanks, i will read it.
[00:39] <broder> DawnLight: there are a lot of ways that user processes can be started, and lots of reasons that they might end up parented to init. any process whose parents dies, for instance, is automatically reparented
[00:39] <DawnLight> broder, thanks
[00:42] <DawnLight> i want to make a modification in ubuntu that whenever a user's locale is one of the several RTL locales and he tries to log into a unity session, he falls back to unity-2d, instead. where would i insert the code to that?
[00:42] <DawnLight> in unity? in gnome-session?
[00:42] <crossfader> i use the linux 2.6.24-30-generic kernel... as provided most actual kernel in Hardy
[00:43] <crossfader> can i use the kernel-boot-parameter root=/dev/nfs with that kernel? does somebody know?
[00:44] <broder> DawnLight: good question. i'm not really sure. my guess would be either in lightdm, but i don't know
[00:44] <broder> you might want to send mail to ubuntu-desktop and ask for help
[00:45] <broder> crossfader: sorry, i don't know anything about nfs-root. this channel is mostly for development, not support. you should try asking in #ubuntu (or possibly #ubuntu-de - i don't know how occupied that channel is)
[00:45] <stgraber> broder, DawnLight: lightdm would be the wrong place for this, gnome-session sounds better or wherever the current 3d/2d check is. #ubuntu-desktop or<EMAIL_ADDRESS>is probably the best place to ask.
[00:46] <crossfader> thanx broder
[00:46] <crossfader> i try that
[00:46] <crossfader> cu
[00:46] <DawnLight> thanks a lot!
[00:46] <broder> stgraber: hmm, ok. i thought lightdm hooked into that, but *shrug*
[00:49] <stgraber> broder: it does indeed call the nux check and cache it to make login faster but that's on top of the existing gnome-session hook
[00:49]  * broder nods
[00:50] <stgraber> broder: doing it in lightdm would mean the code wouldn't work with LTSP or with KDM which are the biggest reason why the check is currently being done in both lightdm (for speed reason) and gnome-session (if no cached result from lightdm)
[00:50] <broder> got it
[00:52] <stgraber> broder: did you find the answer to your upstart question (related to "stop" IIRC)?
[00:52] <broder> stgraber: nope. i'm trying to evaluate https://code.launchpad.net/~serge-hallyn/ubuntu/precise/bluez/bluez-respawn/+merge/95667
[00:54] <stgraber> patch looks sane
[00:54] <stgraber> stop + exit 0 will have upstart keep the job as stopped and not issue any error message
[00:54] <broder> the stop is in the pre-start, incidentally
[00:54] <stgraber> exit 1 + respawn would likely make upstart try to spawn it again a few times for no good reason
[00:55] <stgraber> yep, that's fine, "stop" is usually done in pre-start to prevent the job from starting
[00:56] <stgraber> I believe hallyn made that change based on what he did in the lxc.conf and lxc-net.conf jobs that have a similar check
[00:56] <broder> cool. i'll go ahead and upload, then
[00:56] <broder> thanks for the help
[00:56] <stgraber> np
[00:58] <slangasek> stgraber, broder: FWIW I don't consider variables like BLUETOOTH_ENABLED to be a very good reason to support /etc/default files
[00:58] <slangasek> I would rather see that cleaned up entirely
[00:59] <slangasek> (I've railed against such /etc/default usage even in Debian where everyone's still using init scripts; and with upstart jobs it's just silly to use such a method to disable jobs)
[01:00] <broder> slangasek: hmm, what's your preferred approach for avoiding regression for users that are currently using the variable?
[01:00] <stgraber> slangasek: well, in this case /etc/default/bluetooth contains a bit more than just that single variable, but I definitely agree we should never introduce a /etc/default/blah file just for that. Though handling the upgrade path is a bit tricky if we want to start removing these.
[01:00] <broder> (it predates bluetooth being an upstart job)
[01:00] <broder> there are also other variables in /etc/default/bluetooth
[01:01] <slangasek> broder: well, I don't consider it a regression in any meaningful sense; but if you care about preserving that admin preference, I'd rather see it converted to an upstart override on upgrade
[01:01] <slangasek> stgraber: yes, /etc/default/bluetooth contains *three* variables for disabling services, two of which are obsolete no-ops ;)
[01:02] <slangasek> ah, no, perhaps the other two aren't obsolete, but they're just unrelated to the current upstart job
[01:03] <stgraber> btw, do we have a tool to easily enable/disable upstart jobs (writting the override file for us) or is that still on the todo?
[01:03] <slangasek> still on the todo
[01:04] <slangasek> but for a one-time upgrade issue, it's easy enough to do echo manual >> /etc/init/bluetooth.conf.override
[01:05] <slangasek> (or is that /etc/init/bluetooth.override?)
[01:05] <broder> bluetooth.override
[01:05]  * slangasek nods
[01:06] <broder> ok, i guess i'll work on adjusting the initscript and adding some upgrade logic, and probably a NEWS.Debian entry?
[01:06] <slangasek> initscript?  maintainer script?
[01:07] <broder> well, removing the variable from the .default file and upstart job
[01:07] <slangasek> right
[01:07] <slangasek> I wouldn't personally bother with a NEWS.Debian, but I guess there's nothing wrong with that
[01:07] <stgraber> right, so have a preinst source /etc/default/bluetooth, if disabled, write the override file (and print something for the user), then ship a new /etc/default/bluetooth without the BLUETOOTH_ENABLED part
[01:07] <slangasek> postinst, not preinst
[01:08] <slangasek> no need to do it before unpacking the new version of the package - that just makes rollbacks more complicated
[01:08] <broder> slangasek: i'd like to leave a note somewhere for people who expect the variable to be there, and if i set a precedent of putting it in the .default file, it makes it harder to delete the .default file if the other 2 variables are ever obsoleted
[01:09] <slangasek> oh, except this is a conffile and we want to avoid a conffile prompt, don't we
[01:09] <stgraber> I guess you could even go as far as checking the checksum of /etc/default/bluetooth with BLUETOOTH_ENABLED=0 to avoid the config update prompt
[01:09] <broder> oh yeah, i'd prefer to avoid the conffile prompt if i can
[01:09] <stgraber> slangasek: right, my understanding was that we need the old /etc/default/bluetooth to do the check, so we need preinst
[01:09] <stgraber> slangasek: (same for the checksuming)
[01:10] <slangasek> broder: sure; my personal inclination would be to just spit a message out about it on stdout when the package is upgraded if this needed to be done and otherwise be silent, but NEWS.Debian isn't clearly a *wrong* thing to do
[01:11]  * broder hates dealing with conffile upgrades
[01:12] <broder> can we just leave it for now and deal during q? :)
[01:12] <slangasek> if you wish ;)
[01:13] <broder> i'm not exceptionally confident in my ability to get this right, and i'd like to focus on getting things out of the sponsorship queue today
[01:13] <slangasek> broder, stgraber: checked bluez source, the other two default vars are no-ops in the current package
[01:14] <slangasek> so that reduces the upgrade logic to preinst: source, check var, write override file, remove conffile
[01:14] <stgraber> I think it'd be best to wait to have a tool to write/remove override files before we start converting things to them. Granted it's very easy to write (just one line) and it's documented in init(5) but I think it could do with a bit more visibility and having a tool to update the override should fix that.
[01:15] <stgraber> so my opinion is that we should keep the current /etc/default/bluetooth for 12.04 and maybe start being aggressive (and consistent) on how to disable the jobs starting in 12.10
[01:15] <slangasek> stgraber: well in that case, I would argue to just drop support for /etc/default/bluetooth from the package entirely *without* a transition to a .override, which is generally what we've done in upstart conversions
[01:15] <stgraber> so that's not just bluetooth but anything using a similar hack (which AFAIK is a fair amount of packages)
[01:16] <slangasek> no, almost all packages that have preserved /etc/default handling when converted to upstart jobs have done so because of non-trivial variables
[01:17] <slangasek> not just for enable/disable handling
[01:17] <broder> i'm inclined to agree with stgraber just because it decreases the flame coefficient
[01:18] <broder> but i will also likely not be writing much/any of the code involved, so that's easy for me to say :-P
[01:18] <slangasek> bluetooth is the package that's inconsistent here
[01:18] <slangasek> bluez rather
[01:18] <slangasek> it's spawning a pre-start script for no reason other than to check whether the service should be started.  That's unidiomatic in upstart, and slows the boot down
[01:20] <broder> is that actually true in practice? i'd expect ureadahead to mostly nullify the impact
[01:20] <broder> (performancewise - i accept that it's unidiomatic)
[01:20] <slangasek> you still have the cpu cost of spawning another shell and doing stuff
[01:20] <slangasek> I'm not saying "this script kills our boot performance" - but boot performance is why on the whole we don't do this
[01:21] <stgraber> slangasek: I see that on my system apport, cryptdisks, irqbalance and qemu-kvm all have kept their ENABLE/DISABLE variables in /etc/default/ when converted to upstart, though indeed most of them have at least another variable coming from the file
[01:22] <stgraber> so I think if we want to make the switch to .override (which is perfectly fine with me, I'm happy to see it used), we should do it consistently for all packages using upstart
[01:22] <stgraber> s/using upstart/shipping an upstart job/
[01:22] <stgraber> and only keep /etc/default/<package> for other variables (if any is left)
[01:23] <slangasek> stgraber: the line I'm drawing is with jobs spawning an extra pre-start process *just* to check whether to start the service.  There are other incremental improvements we can make elsewhere to reduce the use of /etc/default, but they're in general a lot harder
[01:25] <slangasek> cryptdisks and irqbalance parse their files for other variables and do it as part of a 'task' script; apport is a special case because the file is being regularly modified by the package (because we change whether to enable apport at different times in the release cycle); qemu-kvm actually doesn't use it to disable the service at all
[01:27] <stgraber> doing that parsing in a task script sounds wrong to me though, it'll indeed avoid spawning an extra shell but will result in the job marked as running even though it's not
[01:28] <slangasek> I don't think so, not if the job exits non-zero?
[01:28] <stgraber> anyway, I understand your interest in saving a bit of boot time but I'd really much prefer doing something consistent and not have bluetooth be the only one doing it right as I think it'd just confuse our users...
[01:29] <stgraber> if the exit non-zero it should be then marked as stopped indeed and will log a failure
[01:29] <stgraber> the logging a failure part is the one that would be avoided with a check in pre-start + call to stop
[01:30] <stgraber> (though I guess you can call "stop" from the task script too)
[01:38] <slangasek> stgraber: as far as I'm concerned, "doing it right" is to drop the variable from /etc/default/bluetooth, period.
[01:39] <slangasek> whether the maintainer script helpfully migrates that setting to a .override for the user is secondary
[01:39] <slangasek> we never should have been using /etc/default for this in the first place, and there's no justification for carrying it forward with upstart
[01:41] <User_007> broder, i installed bzr, got the branch, made my changes, commited... and now how to make a .changes? (i tried bzr -bd -S and it said -bd is unknow command)
[01:41] <broder> User_007: bzr bd -S - no dash before the bd
[01:41] <User_007> ok
[01:42] <User_007> still unknow
[01:42] <broder> User_007: you may need to install the bzr-builddeb package if you haven't already
[01:42] <User_007> ok
[01:48] <broder> slangasek: ok, say i decided to handle transition the /etc/default variable to an override file in the preinst. do i need to roll that back somewhere in the case of an upgrade failure?
[01:52] <broder> http://paste.ubuntu.com/867621/ is what i have so far
[01:55] <broder> http://wiki.debian.org/MaintainerScripts is kind of short on information on what to do if the unpack fails
[02:07] <mbiebl> broder: I probably wouldn't do it on every upgrade and check if the override file already exists
[02:07] <mbiebl> so you don't overwrite any custom local configuration
[02:08] <broder> mbiebl: ah, sure. good point. let me adjust
[02:13] <broder> mbiebl: ok, i think http://paste.ubuntu.com/867637/ should better handle the .override file existing already
[02:13] <broder> (and it will only run on one upgrade)
[02:19] <User_007> broder, i got some problems with signing the .changes
[02:20] <broder> User_007: if you haven't already created a gpg key, you should probably read through http://developer.ubuntu.com/packaging/html/getting-set-up.html
[02:22] <mbiebl> broder: looking at the Architecture: line, I'm wondering why it doesn't use linux-any
[02:23] <broder> mbiebl: eh, that's not the sort of thing i'd generally introduce as an ubuntu change
[02:25] <User_007> broder, i have already done everithing.... it seems bzr wants to use my computer name (user@computer) to find my gpg key
[02:25] <broder> User_007: it uses the debian/changelog entry to figure out which key to use
[02:25] <broder> so you probably didn't have DEBEMAIL set at the time you created the changelog entry
[02:25] <mbiebl> broder: going to file a bug against the Debian package
[02:25] <User_007> humm
[02:26] <broder> mbiebl: cool, sounds like a good plan. do my changes seem correct to you?
[02:26] <broder> (given slangasek's design goals)
[02:26] <mbiebl> haven't checked the updated pastebin yet
[02:27] <broder> k
[02:34] <User_007> thanks a lot broder !
[02:34] <broder> glad to help :)
[02:34] <User_007> :)
[02:48] <slangasek> broder: if it's done in the preinst, yes, you need to roll it back in the prerm
[02:49] <broder> slangasek: the failed-upgrade case?
[02:49] <slangasek> yep
[02:50] <broder> i guess i need some sort of flagfile to tell if i was the one to edit the override
[02:51] <broder> is there a convention on where i would do that?
[02:57] <micahg> doko: you seemed  to have dropped my fix for icedtea-web with the new upload, someone already has a merge proposal with the same fix as last time, so I"m going to sponsor it
[03:25] <broder> @pilot out
[15:51] <shnatsel> cjwatson: I've patched Casper for elementary OS recently and discovered that recent additions are under-documented. Here's a fix: https://code.launchpad.net/~shnatsel/ubuntu/precise/casper/comments-on-flavour/+merge/95788
[16:37] <fishor> hallo all, i currently have some linker dependensies problems on ubuntu12.04, the problems are with *.la files
[16:37] <fishor> my question is. should actually *.la files be included to the packages or not
[16:38] <fishor> becouse some are missing, some included
[18:46] <PaoloRotolo> Hi all!
[18:51] <Ampelbein> fishor: la files shouldn't be included in new packages. For existing packages they should be removed once no other package references them.
[19:06] <JontheEchidna> on
[19:06] <JontheEchidna> oops
[19:06] <JontheEchidna> (hit konversation w/ my mousepad accidentally mid-typing)
[19:15] <fishor> Ampelbein,  thx.. i trying to compile cheese from source bat there are still some not existing la dependencies. how can i find package with making me troubles
[19:16] <fishor> i mean not existing la is not problem, but why configure script still include it?
[19:16] <Ampelbein> fishor: 'grep "NAME_OF_THE_LA_NOT_FOUND" /usr/include -r'
[19:17] <Ampelbein> fishor: Can you pastebin the error?
[19:27] <fishor> Ampelbein, http://paste.ubuntu.com/868763/
[19:28] <Ampelbein> fishor: try 'grep libatk-1.0.la /usr/lib -r"
[19:35] <Ampelbein> fishor: Btw, I can build cheese fine in current precise.
[20:30] <fishor> Ampelbein, thx... i found the files. thay are not from precise
[21:14] <chromaticwt> will 12.04 be 64 bit?
[21:15] <JanC> chromaticwt: Ubuntu has been available as both 32-bits & 64-bits since 2004...
[21:16] <JanC> and that won't change for 12.04
[21:17] <chromaticwt> wow, I don't know why I didn't realize this.
[21:17] <micahg> it was discussed to make it 64 bit by default
[21:18] <JanC> well, it has been 64-bit by default for servers
[21:19] <JanC> I don't think 64-bit makes sense for desktops right now
[21:20] <JanC> 64-bit kernel + 32-bit userspace might make more sense for most users...
[21:21] <chromaticwt> JanC: If 12.04 is 64 bit by default will I still be able to run all of my favorite apps on it?
[21:22] <JanC> chromaticwt: you can run 32-bit apps on a 64-bit system, so it shouldn't be a problem really
[21:22] <chromaticwt> ok
[21:24] <JanC> but AFAIK the default for 12.04 desktop will still be 32-bit (but with PAE required)
[21:39] <chromaticwt> ok, I noticed that beta1 is available for download, so I'm going to upgrade to 64 bit beta1.
[21:39] <chromaticwt> when 12.04 stable is released will I only need to issue apt-get upgrade to upgrade to the stable release?
[21:40] <micahg> dist-upgrade, but yes
[21:41] <stgraber> yes, if you do upgrades regularly, you'll always be on whatever is the current milestone
[21:41] <stgraber> if you installed alpha-2 and did your updates, you're currently on something a bit newer than beta1
[21:44] <chromaticwt> micahg: I need to do dist-upgrade even when upgrading from beta to release?
[21:44] <JanC> actually, you need to do dist-upgrade even after the release  :P
[21:44] <micahg> chromaticwt: yes, as there will likely be new packages
[21:44] <chromaticwt> ok
[21:44] <JanC> e.g. new kernel packages
[21:45] <micahg> and dist-upgrade is preferable, but you need to be careful during the dev release or you can accidentally remove half your system at some points (update-manager is usually safer)
[21:45] <chromaticwt> ok
[21:45]  * JanC prefers Synaptic  ;)
[21:47] <chromaticwt> so this is my plan. I want to upgrade to beta1 by doing a clean 64 bit install. then I will issue apt-get upgrade to update until release. once 12.04R is released I will use update-manager to upgrade to release.
[21:47] <chromaticwt> I want the most stable system possible. should I just wait until release to upgrade?
[21:47] <chromaticwt> I don't mind testing beta.
[21:47] <chromaticwt> not to flood anymore about this.
[21:48] <JanC> chromaticwt: no reason to use apt-get upgrade if you prefer a GUI...
[21:48] <chromaticwt> JanC: personally I prefer the command line for most tasks.
[21:48] <JanC> well, no need for update-manager to get the final release then  ;)
[21:49] <chromaticwt> JanC: so I should use apt-get dist-upgrade or whatever?
[21:50] <JanC> use apt-get dist-upgrade, but be sure to check what it wants to do before you allow it to remove packages
[21:50] <chromaticwt> ok