[09:47] <lordievader> Good morning.
[11:49] <BluesKaj> Hiyas all
[17:38] <TriJetScud> is the current ubuntu 15.04 compatible with old style init scripts?
[17:38] <TriJetScud> systemd wise that is
[19:32] <rww> TriJetScud: does "old style" mean upstart or sysvinit
[19:33] <TriJetScud> upstart and sysvinit scripts
[19:33] <rww> I think upstart no, sysvinit yes
[19:33] <rww> not 100% sure though, I haven't looked at how it's implemented in Ubuntu much yet
[19:34] <TriJetScud> well yeah, azure users are going to be in for a nasty surprise next month then
[22:21] <Daekdroom> Did anyone else start getting A2DP (bluetooth audio) issues recently in Vivid?
[22:24] <Daekdroom> Hm. Restarting the bluetooth service fixed it for now.
[22:24] <Daekdroom> But I've never had to do that before.
[23:06] <danielbrazilian> hello guys i don't know why this happened again, the mouse cursor wouldn't appear just now when i turned the notebook on, then i only turned off and turned on again and it is working again, that is annoying please can anyone help me to fix that issue?
[23:07] <danielbrazilian> i'm running ubuntu mate 15.04 64bit
[23:09] <brendand> danielbrazilian, i have the same issue!
[23:09] <brendand> danielbrazilian, it only happens with the trackpad though
[23:10] <brendand> danielbrazilian, external mouse always works
[23:10] <danielbrazilian> mine doesn't
[23:10] <danielbrazilian> both stays the same brendand
[23:11] <brendand> danielbrazilian, mmm. maybe a different issue then
[23:11] <danielbrazilian> it fixed after a reboot
[23:11] <danielbrazilian> but then it happened again
[23:11] <danielbrazilian> i am thinking of going back to lts
[23:12] <danielbrazilian> brendand, that is just annoying


[12:28] <zul> hola
[12:33] <Kamion> bddebian: no - use -v
[12:34] <Spads> jdub: unpong
[12:37] <bddebian> Kamion: Thx
[04:07] <Hobbsee> morning all
[04:12] <rodarvus> hi Hobbsee
[04:13] <Hobbsee> rodarvus: i'm looking at the upgrades.  sure you didnt breka anything?  :P
[04:14] <rodarvus> anyone with an amd64 edgy installation willing to test-build qemu for me?
[04:14] <rodarvus> Hobbsee, nah, not yet :)
[04:14] <rodarvus> but I have a full weekend in front of me!
[04:15] <Hobbsee> rodarvus: hehehe....
[04:15] <Hobbsee> rodarvus: should i get my long pointy stick out?
[04:15] <Hobbsee> rodarvus: and polish it up, all ready to use on the people who break things?
[04:18] <bluefoxicy> Hobbsee:  it's more fun to bludgeon people repeatedly with a blunt stick than it is to drive a pointy stick into them
[04:18] <Hobbsee> bluefoxicy: well....if that's your preference, yes
[04:18] <bluefoxicy> they don't stop moving as fast
[04:19] <bluefoxicy> (in fact people are much more useful when they're still breathing and not full of holes)
[04:20] <Hobbsee> hah
[04:23] <ajmitch> rodarvus: I can build qemu if you like
[04:23] <ajmitch> you have an updated source package available?
[04:23] <rodarvus> yup
[04:23] <rodarvus> just finished building it on i386
[04:23] <rodarvus> didn't tested it yet, though :D
[04:24] <ajmitch> it builds, ship it :)
[04:24] <rodarvus> yeah!
[04:24] <rodarvus> let me just dogfood it a little while before uploading
[04:24] <ajmitch> ok
[04:24] <ajmitch> still want me to do a test amd64 build before you subject the archives to it?
[04:27] <rodarvus> amazing, it works.
[04:27] <rodarvus> ajmitch, I'm uploading it now, will hand you the url in a second
[04:27] <rodarvus> ajmitch, yes, please do
[04:28] <ajmitch> ok
[04:28] <rodarvus> (uploading to people.ubuntu.com, I mean :) )
[04:29] <rodarvus> ajmitch, http://people.ubuntu.com/~rodarvus/packages/qemu/
[04:29] <jdub> mdz: ping
[04:30] <ajmitch> yep, got it
[04:30] <rodarvus> thanks!
[04:32] <ajmitch> jdub: what did you need to convince me of for beaglefs?
[04:32] <jdub> ajmitch: wasn't sure if you wanted to maintain it long term
[04:32] <ajmitch> fine by me
[04:32] <jdub> sweet, thanks
[04:40] <jdub> mdz, doko: ping (rrdtool)
[04:45] <ajmitch> rodarvus: qemu built fine
[04:46] <rodarvus> ajmitch, nice, I'll upload it - thanks a lot for the test-build!
[04:54] <rodarvus> qemu uploaded
[04:54] <rodarvus> I call it a day
[04:54] <rodarvus> good night all
[04:55] <rodarvus> ?
[04:55] <rodarvus> anyhow
[04:55] <Fujitsu> trackballs in Debian has `xlibmesa-gl-dev | libgl-dev, libglu1-xorg-dev | libglu-dev', while Ubuntu has `libgl1-mesa-dev | libgl-dev, libglu1-mesa-dev | libglu-dev'
[04:55] <Fujitsu> Which is correct?
[04:56] <Fujitsu> I haven't seen this libglu1-xorg-dev dependency before...
[04:56] <crimsun> Debian is.
[04:56] <crimsun> we now have a libglu1-xorg-dev that depends on libglu1-mesa-dev
[04:57] <Fujitsu> OK, thanks.
[04:57] <Hobbsee> Fujitsu: you're doing trackballs?
[04:58] <Fujitsu> Hobbsee, yes, like I did a couple of weeks ago.
[04:58] <Hobbsee> Fujitsu: cool, okay
[04:58] <jdub> tseng: ping
[05:05] <mournahan> need help, dapper hard freezes 2-3 times daily and cant find any solution
[05:06] <Hobbsee> mournahan: --> #ubuntu
[05:06] <Hobbsee> mournahan: read the /topic
[05:07] <mournahan> no help there, thought try here
[05:07] <mournahan> sorry
[07:03] <tseng> jdub: hello
[07:39] <Flowking> And here i thought everyone was  useless for a while... until someone cool or i step aside sessie james will be ontop (Naah:)
[07:41] <Flowking> Cheers all .. each and everyone of you could potentially be just as cool as i am!!!
[07:41] <Flowking> I love you all
[07:43] <Flowking> Ill be coding for you even though crap stinks.. WE DO NOT CARE
[07:43] <Flowking> :=)
[07:43] <Flowking> 10 meters of snow... wont hinder me
[07:43] <Flowking> Ill be the breast coder :=)
[07:44] <Flowking> PCB.. find any coder better atm ?.. we need a trackrecord
[07:44] <Flowking> linus.. yeah.. but he is just GOOD
[07:45] <Flowking> :)
[07:45] <Flowking> So "Machine head- A thousand lies" ?
[07:45] <Flowking> Awesome
[07:46] <Flowking> Its all about rebooting the brain until the next time CRAZY BRAIN!!!
[07:46] <Flowking> :)
[07:48] <Flowking> I could be at a thing called "Hedesunda sommar party" or something....
[07:48] <Flowking> Sexxi
[07:48] <Flowking> :)
[07:52] <Flowking> Sorry Awesome hogs.... want me to lead.. no thats illegal nowdays too "Infringement or some shit!"
[07:52] <neuralis> Flowking: you're trolling and flooding; please leave.
[07:52] <Flowking> So, No i cant even teach you how to COMPUTE
[07:52] <tseng> neuralis: good luck with that.
[07:52] <Flowking> ssh
[07:53] <Flowking> neuralis: you see how HHHG will affect the gilted aswell ?
[07:54] <Flowking> neuralis: "The rage to Overcome" "Machine Head"
[07:54] <Flowking> Keep an open mind and youll be Be
[07:55] <Flowking> neuralis: download some of that man.. really good to be coding to
[07:56] <Flowking> Relaxing
[07:57] <Flowking> neuralis: is it sexxi or do you have a slow pipe (Zap Brannagan:)
[07:58] <neuralis> -- Ignoring ALL from Flowking/*
[07:58] <Flowking> Alternatively youve been swallowed by a small dog
[07:58] <tseng> lilo: ah thank goodness
[07:58] <lilo> orientation?
[07:58] <Flowking> MORON
[07:58] <lilo> tseng: flowking?
[07:58] <Flowking> You dont rock
[07:58] <tseng> lilo: yes.
[07:58] <neuralis> lilo: i just paged you.
[07:59] <neuralis> lilo: thanks.
[07:59] <lilo> neuralis: *nod* got it
[07:59] <tseng> lilo: *hugs*
[08:00] <lilo> tseng: np
[08:00] <LaserJock> sweet
[08:01] <LaserJock> thanks lilo
[08:01] <Kamion> thanks, that was quick
[08:01] <lilo> my job
[08:01] <lilo> glad to help
[10:26] <kagou> hi
[10:26] <kagou> who or where can i discuss about fridge.ubuntu ?
[10:28] <jdub> kagou: you can mail fridge-devel@lists
[10:28] <jdub> kagou: or see #ubuntu-fridge (if there's anyone still in it)
[10:28] <kagou> jdub: :p ok thanks
[10:30] <Nafallo> jdub: hi! did you get me e-mail about changed feed for the planet? :-)
[10:30] <Nafallo> (months ago *I think*
[10:30] <jdub> Nafallo: hrm, i just went through a bunch - can you send again?
[10:31] <Nafallo> okidoki.
[10:31] <kagou> mattw: around ?
[10:31] <HrdwrBoB> erm
[10:31] <Nafallo> sent :-)
[10:31] <HrdwrBoB> is there any way to bootstrap a 64bit install form a 32bit install easily?
[10:41] <jdub> Nafallo: got it
[10:41] <jdub> thanks
[10:41] <Nafallo> no, thank you! :-)
[10:43] <jdub> NO THANK YOU!
[10:44] <Nafallo> hihi :-)
[10:44] <infinity> HrdwrBoB: If you're running a 64-bit kernel, you should be able to build a 64-bit chroot from 32-bit userland.
[10:44] <infinity> HrdwrBoB: If it's a 32-bit kernel, then you have no way of running 64-bit binaries, so it gets tougher.
[10:44] <HrdwrBoB> infinity: yeah, I'm not, so I just copied a 64 bit kernel on it
[10:45] <HrdwrBoB> and It'll be easy from there
[10:58] <Hobbsee> evening all
[11:50] <Kamion> BenC: you don't appear to be subscribed to linux-source-2.6.17 bugmail
[11:51] <Kamion> drat, need one more upload before dapper.1
[11:52] <janimo> Kamion: hi, I did not teste dapper releases so far because they were oversized
[11:52] <janimo> the 08.04 is the first testable one
[11:52] <Kamion> nod
[11:52] <janimo> it's only oversized on the PPC I have to check that too
[11:53] <janimo> besides rosetta updates and other base system changes there were only two extremely small package fixes in xubuntu
[11:53] <janimo> so in theory all should go well
[11:53] <Kamion> yeah, noticed when going through the changes last night
[11:53] <janimo> but will need  testing anyway
[11:53] <Kamion> would be nice to test ubiquity in the context of xubuntu, though
[11:53] <janimo> right
[11:54] <Kamion> powerpc should probably be fixed by removing language packs
[11:54] <Kamion> language packs have grown a bit since dapper
[11:54] <janimo> right, although I am not sure what changed since dapper. did some components get added?
[11:54] <janimo> ah ok.
[11:55] <Kamion> the size increase of the xubuntu desktop CD is about what I'd expect
[11:55] <Kamion> want me to take care of it? I have the figures to hand
[11:55] <janimo> oh, I confused things. the edgy dailies were oversized on all archs, and this is the first daily for dapper.1
[11:55] <Kamion> aaaaactually
[11:56] <janimo> sure if it's not much trouble, thanks
[11:56] <Kamion> no need to remove bits - that build was hit by a sort of a debian-cd bug
[11:56] <Kamion> which allocated ~5MB too much space for the HFS hybrid metadata on powerpc
[11:57] <Kamion> I'll do full rebuilds of everything soon, which should clear that up. Do you have a tester ready to go now? If so I can do you first.
[11:57] <janimo> I need to check
[11:57] <janimo> as it's 3h download from here I may find someone with better bandwidth
[11:57] <janimo> and inclination to test
[11:58] <Kamion> nod, 2/3h per image for me too
[11:58] <doko> Kamion, pitti: Is there still time for a dapper-security upload for the CD images?
[11:59] <janimo> Kamion: but yes if you rebuild I can start downloading and test today
[11:59] <Kamion> doko: something that goes on the live CD? I'd hoped I was done with the live filesystem builds
[11:59] <Kamion> doko: details (in /msg if need be)
[11:59] <janimo> is the 386 image changing as well since yesterdays or just the PPC?
[11:59] <Kamion> janimo: I need to update gfxboot-theme-ubuntu's translations, so all CD images will be rebuilt
[11:59] <janimo> as I may start the dl now otherwise
[11:59] <janimo> ok
[11:59] <janimo> Gloubiboulga: hi
[11:59] <Kamion> but you can rsync, it won't be a huge change
[11:59] <Kamion> you know the rsync runes?
[11:59] <janimo> right
[12:00] <janimo> I hope  I have themin bash history :)
[12:00] <janimo> unless the URLs changed since dapper
[12:00] <janimo> it should be ok
[12:00] <janimo> btw uploads to edgy are stil ok at this point no?
[12:01] <Kamion> stick dapper/ in before daily or daily-live
[12:01] <Kamion> I needed to be able to build dapper and edgy in parallel so that's changed a bit
[12:01] <Kamion> edgy> sure
[12:02] <Kamion> doko: after the point release, please
[12:02] <Kamion> doko: (sorry, but the cut has to come somewhere, and after I've spent three hours doing livefs builds seems like a plausible place)
[12:03] <doko> Kamion: sure
[12:03] <Kamion> I'll let you know if we'll need a rebuild for other reasons
[12:06] <Gloubiboulga> hi janimo
[12:06] <Gloubiboulga> hi all :)
[12:06] <ajmitch> hello Gloubiboulga
[12:06] <janimo> Gloubiboulga: seems we'll have 6.06.1 candidates in a few hours
[12:07] <janimo> I am downloading yesterdays image now
[12:07] <Kamion>  msgid "Start Ubuntu in safe ^graphics mode"
[12:07] <Kamion> +msgstr "Paleisti Ubuntu VESA ^grafiniu reimu"
[12:07] <Kamion> interesting telepathy from the Lithuanian translator there :)
[12:07] <Gloubiboulga> janimo, ok, I have to leave now, but I'll test images tonight
[12:26] <Nafallo> hehe
[12:52] <Kamion> scheisse, I do need a livefs rebuild due to the publisher crash
[12:52] <Kamion> going to make it as fast as possible though - the relevant source is publishing now
[12:54] <StevenK> Ahhh, that'd be why my new upload is not being published.
[12:54] <StevenK> Hopefully my upload didn't kill it.
[12:54] <Kamion> no, not any upload's fault
[12:54] <StevenK> Kay.
[12:55] <Kamion> long story related to the point release, but it's being sorted now
[12:55] <StevenK> Right.
[12:55] <Kamion> what was your upload? I'll check for it
[12:56] <StevenK> libapache-mod-jk 1:1.2.18-1ubuntu1
[12:56] <StevenK> Kamion: Thanks
[12:56] <Kamion> 10:51:12 DEBUG   Added /srv/launchpad.net/ubuntu-archive/ubuntu/pool/universe/liba/libapache-mod-jk/libapache-mod-jk_1.2.18-1ubuntu1.diff.gz from library
[12:56] <Kamion> 10:51:12 DEBUG   Added /srv/launchpad.net/ubuntu-archive/ubuntu/pool/universe/liba/libapache-mod-jk/libapache-mod-jk_1.2.18-1ubuntu1.dsc from library
[12:56] <Kamion> 10:51:12 DEBUG   Added /srv/launchpad.net/ubuntu-archive/ubuntu/pool/universe/liba/libapache-mod-jk/libapache-mod-jk_1.2.18.orig.tar.gz from library
[12:56] <Kamion> yep, being published now
[12:56] <StevenK> Cool, thanks.
[01:07] <pygi> sivang, poke
[02:19] <Riddell> Kamion: I'm uploading a new kubuntu-meta to dapper-updates with a langpack removed from powerpc, could you approve when it arrives
[02:19] <Kamion> Riddell: yes, but hang on
[02:19] <Kamion> Riddell: are you looking at the powerpc live CD?
[02:20] <Riddell> Kamion: yes
[02:20] <Kamion> Riddell: that's affected by a debian-cd bug - please wait until the build I just did arrives on the mirrors and base numbers on that
[02:21] <Riddell> ok
[02:21] <Kamion> Riddell: also I believe that all architectures are slightly too big at the moment
[02:21] <Kamion> I realise there's no .OVERSIZED file
[02:21] <Riddell> http://cdimage.ubuntu.com/kubuntu/dapper/daily-live/20060805/  ?
[02:21] <Kamion> but recent information suggests that some software gets unhappy if the image is over 700 MB
[02:21] <Riddell> powerpc has .OVERSIZED
[02:21] <Kamion> i.e. 734003200
[02:21] <Kamion> bytes
[02:21] <Kamion> yes, powerpc is clearly over, although less far over than in 20060804
[02:22] <Riddell> but i386 is also over for some software?
[02:22] <Kamion> my figures are 440320 bytes for amd64, 1208320 bytes for i386, 4100096 bytes for powerpc
[02:22] <Kamion> I think so
[02:23] <Riddell> ok, I'll trim some more
[02:31] <doko> Riddell, Kamion: OOo will shrink by 1.6 mb for the next upload to edgy, but maybe too late for knot-2
[02:32] <Kamion> ok, thanks
[02:33] <Kamion> not sure when I'm doing knot-2, may not squeeze it in before I go on holiday
[02:43] <Kamion> sfllaw: it would be good if you could check over DebuggingUbiquity for the usual patterns when splitting off misfiled bugs
[02:52] <Riddell> Kamion: kubuntu-meta uploaded
[02:54] <ogra> Kamion, do you build edubuntu as well, or do i need to ?
[02:54] <Kamion> I'm just sorting out Edubuntu now - powerpc was a bit oversized
[02:54] <Kamion> I took out KDE language packs for pt de fr
[02:55] <ogra> thanks
[02:55] <Kamion> so at least they'll still get the desktop translations
[02:55] <ogra> hmm, i only saw oversizedness on the liveCD
[02:56] <Kamion> yes, I meant the live CD
[02:56] <ogra> and according to your comment on kubuntu ppc live i thought i'd wait for the next build to see if its really to big
[02:57] <ogra> but if you already removed them , then its fine :)
[03:01] <Kamion> I did a rebuild just before fiddling with the seeds, to test that
[03:01] <ogra> ok
[03:01] <Kamion> I knew it wouldn't quite rescue all the space though
[03:04] <ogra> hmm, why doesnt dash know my environment ? $UID is empty :/
[03:06] <Kamion> ogra: edubuntu-meta update will probably fail in edgy; I'm working on fixing it in germinate
[03:06] <Kamion> ogra: let me know if it becomes urgent
[03:07] <ogra> depends how near knot-2 is :)
[03:08] <pygi> bye all
[03:08] <Kamion> should definitely have it sorted before then
[03:08] <Kamion> fixing the corresponding dapper breakage now
[03:08] <ogra> ok
[03:09] <Kamion> and shuffling the publisher byhand again
[03:15] <Kamion> ogra: actually, no, edgy works fine, and the dapper breakage is probably my bad due to a seed merge
[03:19] <ogra> is it the server seed ?
[03:19] <ogra> the edubuntu one is still trivially small and doesnt change usually
[03:21] <Kamion> kind of, it's broken inheritance in STRUCTURE
[03:30] <bddebian> Howdy
[03:35] <Kamion> right, kubuntu-meta accepted, edubuntu seeds fixed, edubuntu-meta uploaded/accepted, publisher running
[03:36] <Kamion> ogra: sorry for the spurious edubuntu-meta upload attempt to edgy and consequent reject
[03:37] <ogra> dont worry :)
[03:59] <pitti> Hobbsee: hi
[03:59] <Hobbsee> heya pitti!
[04:00] <pitti> Hobbsee: did you see the u-d mail about sponsoring?
[04:00] <Hobbsee> pitti: not yet.  i'm on the digest
[04:07] <TheMuso> pitti: I was actually working with crimsun today. I used the script to upload a debdiff, and he found it teedious to have to extract, save, and apply the debdiff by hand. He can probably tell you more about it/
[04:07] <pitti> TheMuso: yes, we can also write a script which does the gpg, apt-get source, patch, debuild -S -k automatically
[04:08] <TheMuso> Right.
[04:21] <janimo> pitti, congrats for leading the security charts :)
[04:27] <pitti> hey janimo, thanks :)
[05:15] <Kamion> kubuntu/edubuntu livefses building
[05:15] <Kamion> xubuntu will follow too
[05:21] <mdz> Kamion: are these candidates for testing?
[05:37] <Kamion> mdz: yes
[05:38] <Kamion> Ubuntu alternate and desktop built, ready for testing
[05:40] <mdz> ok
[05:40] <mdz> Kamion: 20060805?
[05:42] <Kamion> yes
[05:42] <Kamion> (for both)
[05:43] <Kamion> derivatives may have different build numbers
[05:43] <Kamion> (for anyone else watching)
[05:43] <Kamion> kubuntu alternate and desktop building
[05:43] <mdz> Kamion: do you have a list of what has changed and so most needs testing?
[05:44] <Kamion> mdz: http://wiki.ubuntu.com/DapperPointOneAnnouncement has most of the changes
[05:44] <mdz> which installer cases, which apps
[05:44] <Kamion> although in the case of the desktop it's kind of "well, most of GNOME changed"
[05:45] <mdz> Kamion: s/including a large memory leak/including a fix for.../ I think ;-)
[05:45] <Kamion> I caught most of the significant installer changes there, though
[05:45] <Kamion> hah, yes
[05:45] <Kamion> (fixed)
[05:46] <Kamion> mdz: is the style of that announcement ok? I chose the changelog style because I thought it would be useful to reassure certifiers about what we're messing with
[05:46] <Kamion> but the detailed list of changes could be split off if you want
[05:46] <mdz> I think we can remove the paragraph which says that 6.06.1 is the first long-term release
[05:46] <mdz> the first sentence anyway
[05:47] <mdz> or change it to refer back to 6.06 LTS
[05:47] <Kamion> makes sense
[05:47] <Lure> any reason that we have both ruby and ruby1.8 packages in edgy (both 1.8.x)?
[05:47] <Treenaks> (universe totem-{xine,gstreamer}-firefox-plugin broke because of the totem upgrade)
[05:48] <Kamion> mdz: changed
[05:48] <Kamion> Lure: apt-cache show ruby
[05:48] <mdz> I'll tweak a bit while I wait for downloads
[05:48] <mdz> oh, you still have it locked
[05:48] <Kamion> it's saving slothfully
[05:49] <Kamion> should be unlocked now
[05:51] <Lure> Kamion: thanks (metapackage or so...)
[05:52] <mdz> Kamion: do you have a quick statistic for the total number of package updates applied on the CD?
[05:52] <mdz> source packages that is
[05:55] <Kamion> not trivially - I can come up with one though
[05:58] <mdz> gar, desktop is still vaguely unstable
[06:01] <mdz> I think we can safely say "over 200"
[06:02] <Kamion> now let's remember how join(1) works
[06:02] <Kamion> unstable?
[06:03] <Kamion> mdz: in terms of binaries, 516 on dapper-alternate-i386.iso are updated
[06:04] <Kamion> sources, give me a minute
[06:05] <mdz> Kamion: I'm comfortable with "over 200", honestly
[06:05] <mdz> there have been more than that many uploads to dapper-changes since release
[06:05] <Kamion> mdz: 21 sources from -security, 330 sources from -updates
[06:06] <Kamion> (I was already mostly done)
[06:06] <mdz> ok, over 300 then
[06:06] <mdz> that includes langpacks I assume?
[06:06] <mdz> those weren't on -changes
[06:06] <Kamion> everything, that's comparing grep-dctrl -nsFilename with pool/*/*/*/*.*deb basically
[06:07] <Kamion> 62 of those 330 are language-(pack|support)
[06:07] <Kamion> oh, yeah, kubuntu alternate and desktop ready for testing :)
[06:08] <Kamion> edubuntu livefs still building, slow thing
[06:08] <Kamion> mdz: unstable desktop -> dapper or edgy?
[06:10] <mdz> Kamion: edgy
[06:11] <Kamion> oh, good. well, not good, but YKWIM
[06:11] <mdz> bug #54726
[06:11] <Ubugtu> Malone bug 54726 in xserver-xorg-video-ati "Random freezes in X" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54726
[06:11] <janimo> Kamion: should  the two xubuntu changes be mentioned as well in that announcement?
[06:11] <Kamion> janimo: yes, I'll add them
[06:11] <janimo> ok, thanks
[06:11] <Kamion> janimo: I was doing the changelist before I decided it was reasonable to just have one announcement
[06:12] <mdz> I'd need to swap in an identical video card to be sure about whether it's a hardware issue
[06:12] <mdz> rsync is taking ages, only getting ~40kb/sec
[06:15] <janimo> Gloubiboulga: I tested the image in qemu burning real CD now. Did it work for you?
[06:15] <mdz> Kamion: ETA 3-4 hours here, you doing any better?
[06:15] <Kamion> janimo: reload, see if that makes sense?
[06:16] <Kamion> mdz: desktop i386 ETA 1:24 allegedly, but amd64 came down a lot faster than that
[06:16] <Kamion> of course I'm *cough* rsyncing off lithium from pure habit
[06:16] <Kamion> really must stop doing that
[06:16] <bddebian> *cough* speaking of syncs *cough* ;-P
[06:16] <Kamion> but every time I'm reminded of it it's when other people's rsyncs are slow, so ...
[06:16] <bddebian> Heya Gloubiboulga
[06:17] <Gloubiboulga> janimo: I'm using the live cd
[06:17] <Gloubiboulga> and installing
[06:17] <bddebian> Kamion: No worries, I'm just not sure what's left at this point :-)
[06:17] <janimo> Kamion: yes, looks good.
[06:17] <Kamion> janimo: thanks
[06:18] <Kamion> I'll reorder that list at some point to be better-categorised rather than in rough date order of uploads
[06:21] <mdz> bddebian: if you're concerned about whether it'll break the live CD, I believe that's built using the dapper version of squashfs-tools, and if you want to warn the person responsible for that, that's infinity
[06:21] <Lure> if a package suggests/recomends (but not depends) on something from multiverse, can it still be in universe?
[06:21] <mdz> bddebian: (PS: your post is <24 hours old and it's Saturday :-P)
[06:21] <mdz> Lure: suggests, yes, recommends, not really
[06:21] <Kamion> Lure: suggests yes, for recommends it'd probably be a judgement call
[06:21] <Kamion> snap
[06:21] <Kamion> (ish)
[06:21] <Kamion> recommends should be increasingly like depends
[06:22] <Lure> Kamion: I suspect due to aptitiude behaviour to install as depends?
[06:22] <Lure> Kamion: any special procedure to move something from multiverse -> universe (when Depends are fixed)?
[06:23] <Kamion> you have the causality the wrong way round, but yes
[06:23] <Kamion> aptitude behaves that way because we want to be able to use recommends more effectively
[06:23] <Kamion> Lure: file bug on package, subscribe (*don't assign*) ubuntu-archive team
[06:24] <Lure> Kamion: ok, will get fixed package uploaded first by MOTU and then I will file request. Thanks!
[06:26] <bddebian> mdz: Well as usual I started on IRC first but I see your point, sorry
[06:27] <mdz> it's edgy, upload first and ask questions later
[06:27] <bddebian> Well I don't want to get in "trouble" again :-)
[06:27] <mdz> but I wonder what squashfs is doing in universe
[06:30] <mdz> Kamion: do you still hope to get some bug references from the GNOME team for the announcement?
[06:30] <mdz> I expect we'd have to call them up on Saturday
[06:32] <Kamion> mdz: I think I might well just go through the uploads again; won't take that long
[06:32] <Kamion> it was late last night and I was just doing a first pass
[06:43] <Kamion> ogra: edubuntu alternate and desktop ready for testing
[06:45] <janimo> Kamion: is running the 386 iso on amd64 considered a valid use case? Desktop works but ubiquity crashes
[06:45] <Kamion> yes, that's valid
[06:45] <Kamion> can I have a bug with the crash dump and the logs please?
[06:45] <janimo> I'll file a report then
[06:46] <janimo>  /var/log/installer/syslog right?
[06:46] <Kamion> all those listed in the crash dialog
[06:47] <Kamion> I'm assuming it crashed in such a way as to pop up a dialog with a traceback
[06:47] <janimo> right
[06:47] <Kamion> I'll probably only fix it now for the point release if it's a regression from dapper
[06:48] <janimo> sure, it probably is not
[06:48] <janimo> havent tried dapper on this box yet
[06:48] <Kamion> it should be easy enough for me to tell
[06:49] <janimo> going offline for a while since I only have one eth connection right now
[07:02] <Kamion> ok, who made vim's completion facilities TRULY SCARY
[07:11] <Kamion> janimo: ah, regression :(
[07:12] <Kamion> janimo: so that we don't have to wait for a whole new build cycle, could you apply this to /usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py and try again?
[07:12] <Kamion> -                if fstype is None:
[07:12] <Kamion> janimo: on line 1034
[07:12] <Kamion> +                if fstype is None and device in validate_filesystems:
[07:12] <Kamion> Gloubiboulga: you too
[07:12] <Gloubiboulga> Kamion: ok
[07:13] <Kamion> thanks
[07:17] <Gloubiboulga> it didn't crash with the change
[07:18] <Kamion> does it complete successfully?
[07:18] <Gloubiboulga> It's installing the system now
[07:18] <Kamion> real-world testing > constructed test cases, yet again
[07:19] <Kamion> backporting the change right now
[07:19] <Kamion> janimo: did you get my earlier comments?
[07:19] <janimo> only in LP not on IRC
[07:19] <Kamion> 18:12 < Kamion> -                if fstype is None:
[07:19] <Kamion> 18:12 < Kamion> +                if fstype is None and device in validate_filesystems:
[07:19] <Kamion> could you apply that on line 1034 of /usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py ?
[07:19] <Kamion> and try again
[07:19] <janimo> ok
[07:19] <Kamion> thanks
[07:20] <Kamion> just don't want to have to wait for a whole new build cycle to see if there are any further bugs you encounter
[07:20] <janimo> sure
[07:21] <Kamion> make sure to do the same things in the partitioner as far as you can
[07:23] <janimo> ok got further and is not installing
[07:23] <janimo> now
[07:23] <janimo> sorry :)
[07:24] <janimo> s/not/now/
[07:24] <Kamion> phew
[07:24] <janimo> so hopefully I don;t need to dl and burn a new image either
[07:25] <Kamion> xubuntu daily-live hadn't actually built yet - you were working off an older one
[07:25] <Kamion> I mean in my most recent round of builds
[07:25] <janimo> would be nice (but possibly hard) to have the partitioning steps automatable to run all kinds of random tests on it
[07:26] <Kamion> but if your tests here work, I'm happy to take that as sufficient for the point release provided tests on the final images for other flavours are good
[07:26] <Kamion> there are few enough changees
[07:26] <Kamion> changes
[07:26] <janimo> this was not xubuntu specific right?
[07:26] <Kamion> no
[07:26] <janimo> but the QT interface was not affected?
[07:26] <Kamion> see my explanation in the bug - that's the exact set of circumstances
[07:26] <Kamion> it was
[07:27] <Kamion> I'm fixing both, the code's the same
[07:27] <Kamion> (bit of duplication ...)
[07:27] <janimo> ok, haven;t read all of LP comments yet
[07:27] <Kamion> uploading to dapper-updates now
[07:35] <Kamion> mdz: I'm out tonight - if you're around, could you rebuild all four livefses? otherwise don't worry, I'll do them when I get back and it'll be time enough
[07:36] <Kamion> once ubiquity 1.0.17 binaries arrive
[07:36] <Kamion> alternate install CDs won't need to change, nor will the server CDs that I'm building now, so you can safely continue testing those
[07:37] <Gloubiboulga> Kamion: installation finished here (succesfully it seems)
[07:37] <Kamion> great, thanks
[07:38] <Gloubiboulga> have a nice evening :)
[07:50] <Nafallo> anyone know if Keybuk is on vacation, and in that case for how long?
[08:00] <mdz> Kamion: can do
[08:07] <Nafallo> hmm
[08:08] <Nafallo> cdbs should update the icon cache automatically, right?
[08:09] <Nafallo> if the package has the gnome class, which network-manager doesn't...
[08:14] <Kamion> mdz: thanks
[08:30] <Kamion> ok, I'm off to iwj's for the evening; please do (get a Canonical employee to) phone me on my mobile if there's a point-release-related emergency - I'll obviously be able to get to a computer easily
[08:31] <Nafallo> Kamion: have fun :-)
[08:32] <Nafallo> Kamion: you deserve it :-D
[08:59] <Nafallo> anyone willing to sponsor a trivial change to network-manager? :-)
[08:59] <Nafallo> fixes malone #55334
[08:59] <Ubugtu> Malone bug 55334 in network-manager "nm-applet doesn't start" [Medium,Fix committed]  http://launchpad.net/bugs/55334
[10:32] <bluefoxicy> you know
[10:32] <bluefoxicy> suddenly I don't have DMA on my drive, and I can't turn it on.
[10:40] <Kaleo> Hello bluefoxicy
[10:41] <Kaleo> bugs should be reported on Malone https://launchpad.net/distros/ubuntu/+bugs
[10:41] <Kaleo> and #ubuntu-bugs can help as well
[11:04] <bluefoxicy> mdz:  does anyone use Ctrl+Alt+Backspace?
[11:04] <bluefoxicy> er.  Why the heck did I point that at mdz
[11:14] <Nafallo> pitti: ping


[09:22] <Lion-Simba> Hi all. Is there any command in Upstart to reset job hanging in "stop/killed" status?
[09:22] <Lion-Simba> I'm trying to write my own job file for my service, and it don't work well yet. So, I need to debug it, but now I've stuck with this "stop/killed" state.
[09:31] <ion> Upstart’s current fork-tracking code is preliminary and gets confused easily. You probably used the ‘expect’ stanza claimin a certain style of daemonizing and the behavior of your main process was different. Can you reboot?
[09:32] <ion> http://heh.fi/tmp/workaround-upstart-snafu if not.
[09:33] <ion> ‘# workaround-upstart-snafu n’, where n is the pid ‘status jobname’ says, given that no such process actually exists.
[09:33] <Lion-Simba> Yes, I can. But I'm not very happy to do it every time during development.
[09:35] <ion> If you’re not absolute sure of the forking behavior of the main process, it’s better to make it not fork and not use the ‘expect’ stanza.
[09:35] <ion> ly
[09:36] <Lion-Simba> WOW! I've just started workaround-upstart-snafu without arguments... and it start output a lot of numbers (pids?) and not interruptable by ctrl+c
[09:37] <Lion-Simba> Not quite good behaviour..
[09:38] <ion> pkill -f workaround
[09:38] <ion> I never said it’s a good program. :-) As the name says, it’s a workaround.
[09:38] <Lion-Simba> Ok. It's died. )
[09:39] <Lion-Simba> But... ‘# workaround-upstart-snafu n' not helped.
[09:39] <Lion-Simba> Same numbers.
[09:41] <ion> Updated the file. Now it shouldn’t behave incorrectly when given no parameters.
[09:41] <ion> Exactly what does ‘status jobname’ print?
[09:42] <Lion-Simba> root@dahari:~# status stargazer
[09:42] <Lion-Simba> stargazer stop/killed, process 12148
[09:43] <ion> What does ‘ps -p 12148’ print?
[09:45] <Lion-Simba> Oh. It's over. I used workaround-upstart-snafu 12148 and wait a bit longer, letting it proceed with numbers. :) Now status is stop/waiting. Thank you. :)
[20:03] <cr3> when I run an upstart job on hary, initctl start doesn't return to the shell and just leave me hanging. if I ctrl-c, the process I exec'ed in my upstart job is running fine though


[10:51] <doko_> ScottK: http://paste.ubuntu.com/286360/ didn't look yet. do you have more info in the meantime?
[10:51] <doko_> geser: 3) it does
[10:54] <stani> Can someone make bug https://bugs.launchpad.net/ubuntu/+source/phatch/+bug/448971 public?
[10:54] <stani> sorry I  mean bug https://bugs.launchpad.net/bugs/442466
[10:55] <stani> pochu, ScottK ^
[10:57] <iulian> stani: Done.
[10:58] <stani> julian: Thanks a lot!
[10:58] <iulian> You're welcome.
[10:58]  * iulian -> lunch.
[11:18] <skar> any place where i can read up on applying my patch to a source deb and then building it?
[11:25] <geser> skar: if you don't care about proper integration into the source package: simply apply the patch
[11:25] <geser> and then debuild -b (after installing the build-dependencies, it will complain about missing build-dependencies)
[11:26] <skar> geser: well, i've installed the glibc source deb, and the dir has a dsc, diff and tar.gz file. how do i ask debuild to just unpack, apply patches it has but stop short of building?
[11:26] <geser> skar: dpkg-source -x the_package_you_want_extracted.dsc
[11:28] <geser> I don't know which patch system glibc uses, so I can't tell you how to apply the patches included in the source package. But as long as your patch doesn't collide with other, the order should matter (first yours and the the ones from the package or vice versa)
[11:28] <skar> geser: thanks, now i've got a dir within which some tar.bz2 files and debian dir are present. i still can't find my header file in there which is what i need to patch.
[11:28] <skar> geser: it seems glibc uses quilt.
[11:28] <skar> debian/rules.d/quilt.mk:     @echo -n "Unapplying patches..."
[11:28] <Laney> quilt push -a
[11:30] <geser> Laney: from the message skar typed it sounds like glibc uses tar-in-tar :(
[11:30] <Laney> oh I only read the second line
[11:30] <Laney> indeed that is pain
[11:31] <skar> well, i started debuild, made the process sleep with Ctrl+Z, applied my patch, then resumed the build with fg and it build my new libc fine. but it's ugly.
[11:32] <skar> what i want is cleaner, simpler one which must be what the package maintainers must be using.
[11:35] <skar> geser, Laney: thanks for the tips. any ideas on how to apply the patch, then start the build without overwriting the patched sources again?
[11:37] <geser> skar: there is certainly a cleaner way but as didn't look at the glibc package I can't tell
[11:37] <skar> geser: oh ok. thanks anyway. will study the build process.
[12:42] <RainCT> siretart: thanks, trying it out now
[12:55] <wrapster> http://pastie.org/651337 ; can anyone help me out with this.. Im trying to include a wrapper withing the binutils pkg itself.. strangely the dh_links work fine.. but i get an error like so:
[12:55] <wrapster> cp /usr/sfw/bin/gas debian/binutils/usr/sfw/bin/gas-real
[12:55] <wrapster> cp: cannot create regular file `debian/binutils/usr/sfw/bin/gas-real': No such file or directory
[12:57] <geser> wrapster: check if the target directory exist before you cp into it
[12:58] <funkyHat> I got an error message from rosetta, saying it couldn't import a file because of text encoding problems. Do I need to do anything about this? (my upload was nothing to do with translations)
[12:58] <wrapster> geser: ok thanks.
[12:58] <wrapster> will revert back.
[12:58] <geser> funkyHat: better ask someone familiar with rosetta or translation in #launchpad about it
[12:59] <funkyHat> thanks geser, I've asked in #launchpad
[13:05] <Laibsch> How can I get the grab-merge script to merge from Debian unstable instead of debian testing?
[13:06] <geser> grab-merge download just the files from MoM. And MoM tries merging against Debian unstable
[13:08] <Laibsch> OK
[13:08] <Laibsch> Why is wordpress still at the version in testing ten days after upload?
[13:09] <Laibsch> or in other words
[13:09] <AnAnt> feature freeze
[13:09] <AnAnt> oh
[13:09] <Laibsch> when is MoM going to have 2.8.4-3?
[13:09] <AnAnt> probably in karmic+1
[13:10] <Laibsch> hm, that's not satisfactory
[13:10] <Laibsch> How do I explicitly merge against unstable, then
[13:10] <Laibsch> ?
[13:10] <AnAnt> erm, sorry, I think I answered the wrong question
[13:11] <AnAnt> I thought you meant when will 2.8.4-3 be in Ubuntu
[13:11] <Laibsch> I kind of had the feeling you were a bit off
[13:11] <Laibsch> Although the question somehow is about when 2.8.4-3 will be in Ubuntu ;-)
[13:12] <Laibsch> I'd like to get it merged
[13:14] <geser> Laibsch: then do it by hand: take the package from Debian and apply the Ubuntu delta on it
[13:14] <Laibsch> hm
[13:14] <Laibsch> never done it
[13:15] <Laibsch> I expect a patch conflict at least in  debian/changelog
[13:15] <Laibsch> if not elsewhere as well
[13:16] <geser> than that's a good opportunity to learn it :)
[13:19] <directhex> Laibsch, if the only *needed* delta is changelog, request a sync (the ubuntu changelog will die)
[13:20] <Laibsch> directhex: no, that is not the case
[13:20] <Laibsch> geser: if you give more details, I may fix this package
[13:21] <Laibsch> if not, I may drop the ball on it
[13:32] <geser> Laibsch: I usually go to the PTS page to find all the needed links: http://packages.qa.debian.org/w/wordpress.html
[13:32] <geser> there you will find the link to the .dsc file from unstable which you can pass to dget to download it all
[13:33] <Laibsch> I'm aware of that
[13:33] <geser> and there is also the link to the patch file with all Ubuntu changes
[13:33] <Laibsch> But that doesn't merge things magically
[13:35] <geser> true, but after applying the Ubuntu patch you just need to resolve the conflicts, pretty certain debian/changelog
[13:35] <geser> the advantage MoM has, it does merging the changelog pretty good
[13:35] <geser> other merge conflicts it also leaves to resolve for the merger
[13:36] <Laibsch> true
[13:36] <Laibsch> http://patches.ubuntu.com/w/wordpress/wordpress_2.8.4-1ubuntu1.patch looks like a good way
[13:36] <Laibsch> thanks
[13:36] <wrapster> hi
[13:37] <wrapster> the build came through perfectly but when i install i dont see that wrapper at all..
[13:37] <wrapster> geser: how is it possible that a few lines can be exectued with the remainng are not?
[13:39] <geser> wrapster: what you mean? your wrapper didn't end in the built deb package?
[13:39] <ScottK> doko_: I did see that failure before, but didn't figure it out.
[13:40] <wrapster> geser: no
[13:40] <wrapster> according to that pastie.. a file called gas-real has to exist in /usr/sfw/bin/ ; all i can see is just gas.. and im very sure thats coming from the dh_link
[13:42] <wrapster> geser: well the debian/binutils dir has /usr/sfw/bin/ and gas/gas-real as well.. but dpkg -i <binutils> wont install that at all?
[13:43] <AnAnt> could someone sponsor http://revu.ubuntuwire.com/details.py?package=sabily-xsplash-artwork please ?
[13:44] <joaopinto> hell, can someone sponsor the fix for bug 449502 ?
[13:44] <joaopinto> hello :P
[13:44] <geser> wrapster: if it's in the package then dpkg should also install it
[13:45] <wrapster> geser: then why is it not? coz the dh_link is set up and just 1 line down and it doesnt work...
[13:45] <wrapster> or is my logic wrong thre?
[13:45] <wrapster> here is the story...
[13:46] <geser> wrapster: can you pastebin the contents of the build deb file (dpkg-deb -c)?
[13:47] <wrapster> apparently gas has a -K option (set at runtime) which i want to negate and i had written a wrapper to solve it. first mv gas to gas-real then open a sh script called gas which internally calls gas-real `echo $@ |sed 's/-K//g' ... i thought of doing that.. in the rules file itself so that when pkg is built it will be automatically created...
[13:47] <geser> joaopinto: you might have greater success if you subscribe ubuntu-universe-sponsors to it. on a quick look your fix looks good. did you forward it already to Debian?
[13:48] <joaopinto> geser, I did, but actually I had great  success asking here :)
[13:49] <joaopinto> subscrbing sponsors anyway
[13:49] <wrapster> geser: http://pastie.org/651383
[13:51] <geser> wrapster: does http://pastie.org/651337 still contain you most recent changes?
[13:51] <wrapster> geser: thats the latest
[13:52] <wrapster> mkdir -p debian/binutils/$(TAR_DIR) <before line:16>
[13:52] <geser> wrapster: because there you copy /usr/sfw/bin/gas from the host system (and not from the build) to gas-real. check your build log if cp didn't complain about anything (like missing source file)
[13:53] <wrapster> well actually there is no /usr/sfw/bin/gas until this pkg is installed.
[13:53] <wrapster> i created that as well...
[13:56] <geser> wrapster: I didn't look at dh_link, but I assume it works inside the staging dir from where your package get build it the end but your cp command tries to copy a file from your host system (the one that is currently building the package) and not from that staging dir
[13:56] <wrapster> oh
[13:56] <wrapster> i get that..
[13:57] <wrapster> but the strange thing is if you just cut this out and create a makfile out of this and run.. it works perferctly
[13:57] <wrapster> :(
[13:57] <wrapster> ive tried
[13:57] <geser> hmm
[13:59] <geser> wrapster: and a hint: you could store the wrapper (the shell script) in debian/ (as e.g. gas) and just copy it to its destination instead of creating it in debian/rules (no fighting with escaping needed)
[13:59]  * geser will be back in around 30 min
[13:59] <wrapster> oh cool.. could you elaborate..
[14:18] <wrapster> guys if anyone else was following up  mine and geser conversation could you pls look at this http://pastie.org/651416 and let me know if ive written it right?
[14:22] <skar> geser: hi, got the patch to work fine. all the patches were stored in a debian/patches/i386 dir :) but the build takes very long, due to it building all sorts of locales. any idea to do only certain locales?
[14:24] <geser> wrapster: looks good
[14:24] <geser> skar: sorry, no idea
[14:25] <skar> geser: np. thanks for the tips though. will look into the build process further and dig out where locales list is and change it :)
[14:32] <joaopinto> dholbach, about bug 449177, I was about to fix the FTFBS on the ubuntu package, by chanding debian rules to use automake1.11, I guess that's a btter a fix than build depend on automake1.10
[14:33] <joaopinto> will the sync be performed ?
[14:34] <joaopinto> I remember someone telling me that a sync requires more effot because it requires an archive admin action, unlike a debdiff sponsor
[14:36] <geser> joaopinto: but a sync has the advantage that the package will be auto-synced in karmic+1 instead of appearing on the merge list
[14:36] <joaopinto> ok
[14:37] <joaopinto> so I should file a bug for the Debian package
[14:53] <wrapster> geser: thank you for your idea
[14:59] <wrapster> geser: it did not work!!!
[14:59] <geser> can you explain?
[15:00] <wrapster> geser: http://pastie.org/651466
[15:02] <geser> hmm, did it end in the .deb?
[15:03] <wrapster> geser: again i can see it in debian/binutils/usr/sfw/bin/ but its not while dpkg -i
[15:03] <wrapster> geser: no it did not
[15:04] <geser> can you pastebin all your changes? I want to try it in my karmic pbuilder
[15:04] <wrapster> geser: http://pastie.org/651471
[15:04] <wrapster> one moment.
[15:06] <wrapster> geser: here it is http://pastie.org/651383
[15:07] <wrapster> TAR_DIR= /usr/sfw/bin/
[15:08] <Zelut> if a package provides a symlink which points to a file provided by another package, but said file does not exist, which package is at fault? (ie; which should I report the bug on)?
[15:08] <RainCT> Zelut: That depends whether the file should really be there or not.
[15:10] <Zelut> RainCT: /usr/share/doc/bash/ includes a file 'completion-contrib' which points to ../bash-completion/contrib. There is no contrib file.
[15:15] <wrapster> geser: i created a new rule for this... lets see if it works now.
[15:21] <wrapster> geser: any luck?
[15:21] <geser> wrapster: waiting on the build results
[15:21] <wrapster> geser: ok...
[15:33] <wrapster> geser: what do you think could be wrong ?
[15:34] <wrapster> and is your done?
[15:35] <Zelut> RainCT: I know its just a papercut bug, bug which should I report the issue for?
[15:40] <RainCT> Zelut: I can't say without looking into it
[16:03] <wrapster> geser: is it done?
[16:04] <geser> wrapster: more or less (had to install debhelper as it wasn't listed in build-depends)
[16:04] <wrapster> ok.. i tried creating a new rule didnt help
[16:04] <wrapster> i really dont get it...
[16:07] <geser> wrapster: the build finished, looking into it now
[16:10] <wrapster> geser: btw just so you know.. i have put these cmds under the install target section.
[16:10] <geser> wrapster: I could reproduce your problem
[16:10] <wrapster> and any idea what can be done?
[16:11] <geser> not yet
[16:17] <geser> wrapster: I hope I found it, will let you know when "debian/rules binary" is done building the new deb
[16:18] <wrapster> ok... thanks..
[16:18] <wrapster> im praying it works.
[16:19] <wrapster> geser: also i would like to know if the rules can be tested individually.. so that i can actually narrow down the issue?
[16:19] <wrapster> instead of running buildpkg every time and waiiting for hrs
[16:20] <geser> wrapster: yes, the rules are called in order: clean -> build -> binary (which often depends on install)
[16:21] <geser> you can call debian/rules with the target you need (e.g. once it got build, you can call the binary target several times in case you need to add a fix there)
[16:22] <wrapster> make -f debian/rules <target> ?
[16:22] <geser> but it's a good idea to test-build it at the end from clean, just to be sure you didn't miss anything
[16:22] <geser> wrapster: yes, or debian/rules <target> (it's executable :)
[16:22] <wrapster> ok... so did you narrow down on the issue?
[16:23] <wrapster> this has taken me hrs ... being a newbie .. its very tough
[16:23] <wrapster> :(
[16:23] <geser> wrapster: -rw-r--r-- root/root        56 2009-10-12 15:17 ./usr/sfw/bin/gas (there is a chmod +x missing)
[16:24] <geser> wrapster: the package doesn't use debian/binutils but debian/tmp as a staging dir
[16:24] <wrapster> oh crap.
[16:24] <geser> wrapster: cp debian/gas debian/tmp/usr/sfw/bin/gas
[16:24] <wrapster> how did you figure it out?
[16:25] <wrapster> it will help me also ..
[16:28] <geser> wrapster: there are some variables used within the debian/rules file for the destination, one of them is d_bin (for the binutils package; look around line 33)
[16:29] <geser> wrapster: alternative you could look into the directories below debian/ to check from which your package gets build (as it will have the same contents as the deb)
[16:29] <wrapster> ok i so far had thought that the staging dir is a standar meaning.. debian/<pkgname> would be that.. i didnt know its not so..
[16:31] <geser> wrapster: newer packages use debian/<package> now, but some packages still use debian/tmp (its predecessor)
[16:31] <wrapster> ok.
[16:31] <wrapster> so are you rebuilding .?
[16:31] <wrapster> im trying it out here!!!
[16:43] <wrapster> geser: worked like a charm
[16:43] <wrapster> thanks a ton
[16:45] <\sh> siretart, pingeling....
[17:12] <leonel> how it's called when you want  a newer package for dapper ??
[17:13] <james_w> leonel: backports?
[17:14] <leonel> james_w: but included as official and not in backports?
[17:14] <james_w> SRU?
[17:16] <leonel> have a problem with the dapper  patch for squirrelmail .. bug    446838
[17:26] <ari-tczew> leonel: did you read wiki? https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Packaging
[17:28] <ari-tczew> very poor work
[17:33] <leonel> ari-tczew: why very poor ?
[17:36] <ari-tczew> only in patch2:
[17:36] <ari-tczew> unchanged:
[17:36] <ari-tczew> --- squirrelmail-1.4.13.orig/src/options_order.php
[17:36] <ari-tczew> +++ squirrelmail-1.4.13/src/options_order.php
[17:36] <ari-tczew> wtf?
[17:36] <ari-tczew> where is patch?
[17:39] <leonel> ari-tczew: what debdiff are you looking at ?
[17:41] <ari-tczew> http://launchpadlibrarian.net/33428968/sqjaunty.debdiff
[17:41] <ari-tczew> please compare with this: http://launchpadlibrarian.net/33234876/drupal5_5.18-1.1ubuntu2.debdiff
[17:43] <leonel> drupal  uses  dpatch
[17:43] <leonel> squirrelmail  had no   debian/patches dir
[17:43] <leonel> the previous  patches for squirrelmail where applied  by someone else and did the patching inline
[17:43] <leonel> that's the road I've followed
[17:45] <ari-tczew> leonel: https://wiki.ubuntu.com/PackagingGuide/PatchSystems
[17:45] <leonel> ari-tczew: yes I've read
[17:45] <ari-tczew> I can't believe that squirrelmail can't using patchsystem.
[17:45] <leonel> ari-tczew: I've follow as the previous patches went in
[17:45] <leonel> ari-tczew: this is not my first patch ..
[17:46] <leonel> ari-tczew: even I'm not an expert ..
[17:46] <leonel> ari-tczew: I've did my best  editing 19 files for  5  Ubuntu versions..
[17:48] <ari-tczew> yhym I see
[17:49] <leonel> so what is really wrong so I can fix it ?
[17:50] <ari-tczew> Best work is include a patch to debian/patches
[17:50] <joaopinto> afaik the usual rule is to keep whatever patch system is used on Debian, if it was none, keep it none :P
[17:50] <leonel> so edit  the package to include a patching system ?
[17:51] <ari-tczew> bingo !
[17:51] <sistpoty|work> ari-tczew: nope, what joaopinto wrote
[17:51] <leonel> joaopinto: that's what I've always known
[17:52] <leonel> so that's why as I've said ..  I've followed the patches as ther where comming ..  no patching system in squirrelmail so   patched inline
[17:52] <ari-tczew> maybe you wrong patched files?
[17:52] <ari-tczew> try again
[17:53] <joaopinto> ari-tczew, there is nothing wrong with his approach per the latest discussion about patches management
[17:53] <leonel> ari-tczew: WHAT ???
[17:53] <sistpoty|work> ari-tczew: any changes are in the .diff.gz so recovering from unwanted changes can be done easily
[17:56] <ari-tczew> OK, I'll no long intrude in this case.
[18:02] <ahasenack> hey, is apport in karmic ok? It doesn't catch crashes in python scripts that do not run as root because the crash file can't get written to /var/crash
[18:02] <ahasenack> example: https://pastebin.canonical.com/23217/
[18:02] <ahasenack> ups, wait
[18:02]  * ahasenack switches the pastebin
[18:03] <ahasenack> http://pastebin.ubuntu.com/291714/
[18:06] <ahasenack> hmm, I may have an old version
[18:06]  * ahasenack updates
[18:32] <james_w> ahasenack: what are the permissions on your /var/crash?
[18:35] <ahasenack> james_w: 0700 root:root
[18:35] <james_w> that's why then
[18:35] <ahasenack> james_w: but I'm updating this karmic vm now, it's a few days behind, maybe something changed
[18:35] <james_w> something has changed that
[18:35] <ahasenack> james_w: so what are the original permissions and what sets it?
[18:36] <ahasenack> james_w: oops, wait
[18:36] <ahasenack> james_w: it's 0755, not that it changes much
[18:38] <ahasenack> it's also root:root 0755 in another karmic instance I have, and that one is up-to-date
[18:39] <ahasenack> I wonder if apport is actually a daemon that catches the errors and has write permissions there
[18:39] <ahasenack>  /etc/init.d/apport is an upstart job now, and I don't know how do start or handle these. I know there is nothing like "apport" running right now
[18:44] <james_w> ahasenack: the apport upstrart job creates it
[18:44] <james_w>     mkdir -p -m 1777 /var/crash
[18:44] <ahasenack> james_w: where is that mkdir line? In /etc/init.d/apport?
[18:45] <james_w> /etc/init/apport.conf
[18:45] <ahasenack> ok, I'll reboot the machine and let's see what happens
[18:45] <ahasenack> james_w: is there a way to run these upstart jobs manually like in the "old days"? Like /etc/init.d/apport start
[18:46] <james_w> sudo start apport
[18:46] <james_w> or sudo service apport start
[18:47] <ahasenack> so, just doing that doesn't fix the directory, likely because it's already there
[18:48] <james_w> yeah
[18:48] <james_w> one thing I can see is that update-notifier-common ships the dir
[18:50] <james_w> which it didn't seem to in jaunty
[18:51] <james_w> and so new installs will probably see this
[18:51] <ahasenack> ups, I guess this machine has a problem now
[18:51] <ahasenack> init: mountall post-stop process (942) terminated with status 1
[18:53] <ahasenack> getting a segv
[18:53]  * ahasenack searches launchpad
[21:37]  * jdong kicks thunderbird for not compacting more often
[23:18] <nikolam> hello
[23:19] <nikolam> link https://bugs.launchpad.net/ubuntu/+filebug on launchpad redirects me to ubuntu wiki
[23:19] <nikolam> instead of letting me file a bug
[23:19] <nikolam> so there is a bug about filing bugs on launchpad? :)
[23:19] <joaopinto> nikolam, read the wiki
[23:20] <joaopinto> on the bottom there is a description on how to manually file a bug report
[23:20] <joaopinto> nikolam, is not a bug, is a feature
[23:20] <nikolam> aha..
[23:20] <nikolam> interestin.
[23:20] <nikolam> Maybe that should be explaind on top of the wiki.
[23:21] <nikolam> right noe i am again confused joaopinto
[23:21] <nikolam> i am reading it, but i am not sure how to file a bug
[23:21] <joaopinto> ufff
[23:21] <nikolam> and i filed them many before
[23:22] <joaopinto> http://bugs.launchpad.net/ubuntu/+source/PACKAGENAME/+filebug?no-redirect
[23:22] <joaopinto> nikolam, the goal is to make bug filing restricted to those who can read a page :P
[23:22] <nikolam> i think the goal is to having less bug reports
[23:23] <nikolam> pet example, my bug have nothing to do with apport etc
[23:23] <joaopinto> less unusefull bug reports, yes
[23:23] <micahg> nikolam: the goal is to collect information about the package in question to save back and forth for triagers
[23:23] <joaopinto> nikolam, this is not related to apport, apport is just a tool to make bug reporting easier
[23:24] <nikolam> but what about bugs that have nothing to do with triaging?
[23:24] <joaopinto> nikolam, erm, you are not getting the point
[23:24] <nikolam> Like, request for packaging new package etc
[23:24] <joaopinto> nothing changed, except for the process for opening bugs
[23:24] <joaopinto> nikolam, for those you use the links described on the wiki
[23:25] <nikolam> I would like to have those links inside launchpad, and not only on wiki, thats all.
[23:25] <joaopinto> nikolam, that would defeat the purpose of the change, as it would allow to people filing bugs without providing the required info
[23:26] <nikolam> is this suppost to be right place to file a bug? https://bugs.launchpad.net/ubuntu/+source/PACKAGENAME/+filebug?no-redirect
[23:27] <joaopinto> if you you are going to file a bug against a package, better use, ubuntu-bug package
[23:27] <nikolam> I don`t see point of launchpad as whole if user is requred to manually change link it should be able to click to
[23:27] <joaopinto> if't it's for a project
[23:27] <joaopinto> https://bugs.launchpad.net/ubuntu/+filebug/?no-redirect
[23:27] <joaopinto> nikolam, a user is not required to use launchpad links, it is required to use the "Report bug" function, or to run the ubuntu-bug command
[23:28] <joaopinto> nikolam, why are you complaining if you didn't read the full wiki page yet ?
[23:28] <joaopinto> in this complain time you could have read the page and have a better understanding of the changes
[23:28] <nikolam> joaopinto, i think that there is very small amount of people/users that will EVER read full wiki page
[23:29] <nikolam> And theis conclusion would be.. it doesn`t work.
[23:29] <joaopinto> nikolam, those which are not qualitified to provide the information for a bug or for a process, don't add any benefite to participate in such process
[23:29] <nikolam> I don`t say idea is bad, it is very good one, actally
[23:29] <micahg> guys this discussion is more suited for the #ubuntu-bugs channel
[23:29] <micahg> *people
[23:30] <nikolam> oki :) micahg
[23:30] <nikolam> anyway, we understand , say I understand it now..


[15:23] <morgo> I have a procedure question RE: https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/1154675 (see my last comment).  What do you suggest I do when I believe a bug is ready to close?
[15:23] <ubot2`> Launchpad bug 1154675 in mysql-5.5 (Ubuntu) "Serious regression in replication caused by fix for CVE-2012-4414" [High,Confirmed]
[15:26] <rbasak> morgo: if you believe it's most likely fixed, I think it's fine to explain as you have and then change the bug status to Fix Released. I think others can just reopen if they disagree. Do you have permission to do that, if you try to change the status?
[15:26] <rbasak> morgo: note that the main bug status on the Ubuntu bug task refers to the latest development release (rather than 12.04, for example). In this case that works for this bug.
[15:36] <morgo> rbasak: I don't believe I have permission to close (can't see a link to change status).
[15:38] <morgo> rbasak: I would be happy to request here for status changes if that works for #ubuntu-bugs.  Full disclosure is that I work for upstream of course :)  I don't want anyone to think I'm trying to apply a heavy hand in closing bugs.
[16:34] <rbasak> morgo: thanks - I didn't know what permission you have here. Please do continue to ask here.
[16:34] <rbasak> (I've marked it Fix Released)
[16:41] <morgo> Ack, thanks.
[16:42] <intgr> Hi, which package should I file bugs to for the partition editor in the Ubuntu Server installer? 1278875 in particular.
[16:44] <intgr> partman?
[16:59] <rbasak> intgr: partman-base is the source package I think. I'm not sure if that's the right final target for that bug, but it's better than Ubuntu.
[17:00] <intgr> Ok thanks