[02:44] <acm> hallo. anybody is up who read the ubuntu-devel mailinglist? so, i would like to know some more detail about "branch for the team or each debian directory". what's include in the debian directory?
[02:45] <acm> only changes of the debian upstream or changes in ubuntu upstream and debian?
[02:45] <LaserJock> the actual debian/ directory
[02:45] <LaserJock> which holds all the packaging information
[02:46] <acm> the actual debian/ dir can also be called upstream?
[02:47] <LaserJock> well, kinda
[02:48] <LaserJock> Debian is upstream for most Ubuntu packages
[02:48] <LaserJock> but upstream is also the actual software authors
[02:48] <acm> ah ok. also for gutsy?
[02:49] <LaserJock> yes for gutsy
[02:50] <LaserJock> so you have to often look at the context of the statement to figure out what "upstream" is being talked about
[02:51] <acm> so network-manager confuse me looking at https://code.launchpad.net/network-manager/. which is upstream for the current developing of gutsy? one of the ubuntu core dev-team?
[02:51] <LaserJock> no
[02:51] <LaserJock> upstream is where we get the packaging/software from
[02:52] <crimsun> (https://code.launchpad.net/~vcs-imports/network-manager/main)
[02:53] <LaserJock> acm: the "main" branch is the vcs import
[02:53] <LaserJock> that's the code that comes from the authors
[02:55] <LaserJock> then it looks like upstream.0.6.x branch holds the released source code form the Network Manager authors
[02:55] <LaserJock> and the other "Ubuntu Core Development Team" branches hold our source package
[02:56] <acm> everybody who develop patches does not apply to this branch?
[02:56] <LaserJock> so basically upstream + debian/ directory
[02:56] <acm> ah
[02:56] <acm> ok
[02:56] <LaserJock> well, if the person is a member of the Core Development team they can make changes to that branch
[02:57] <LaserJock> otherwise they need to get somebody to merge it in for them
[02:57] <acm> yes. thats clear.
[02:57] <acm> '
[02:58] <LaserJock> sometimes the Ubuntu branches will just be the debian/ directory and sometimes it's the whole source package
[03:01] <acm> so upstream.0.6.x would be the right source package (for network-manager) to make changes that could be included in the next ubuntu release 7.10
[03:01] <LaserJock> no
[03:01] <LaserJock> upstream.0.6.x has just the upstream source
[03:02] <LaserJock> I think ubuntu.0.6.x would be the one to make changes in
[03:03] <LaserJock> or gnome.ubuntu.0.6.x if it's for the gnome applet package
[03:03] <LaserJock> at least that's how it looks to me
[03:03] <acm> :)
[03:04] <acm> ok thanks
[03:06] <acm> last question :). what is about the branch of Alexander Sack?
[03:06] <LaserJock> that is his personal branch
[05:54] <asac> you can use ubuntu.0.6.x to do changes
[05:54] <asac> for nm
[05:54] <asac> but please use the patch system
[05:55] <asac> OTOH, just modifying the tree and use the diff of those trees to create the patch might be quite efficient :)
[05:56] <asac> lamont: acm ^^
[05:56] <asac> lamont: unping
[07:01] <calc> asac: here?
[07:57] <Fujitsu> ] ] ] \
[07:57] <Fujitsu> Oops.
[08:26] <superm1> does anyone know what package creates the initial /etc/X11/default-display-manager?
[08:26] <superm1> it's appearing that its got a problem of setting the wrong contents for a fresh install from debootstrap for gdm
[08:26] <stdin> probably your ?DM package
[08:26] <superm1> alright i'll pull the gdm sources and check there then.  thanks
[08:26] <stdin> reconfiguring gdm would rewrite it
[08:27] <superm1> its a matter of /usr/bin/ or /usr/sbin
[08:27] <superm1> and it's taking the wrong of the two
[08:58] <superm1> it does appear to be a bug that was introduced, in seb128's absence, could someone else on core-dev sponsor bug 129017 then?
[08:58] <ubotu> Launchpad bug 129017 in gdm "incorrect gdm/daemon_name template" [Undecided,Confirmed]  https://launchpad.net/bugs/129017
[09:32] <siretart> superm1: I've seen that bug on a friends laptop as well!
[09:32] <superm1> siretart, i wasn't sure what it was at first, i've been seeing it in my daily mythbuntu builds
[09:33] <superm1> and just got annoyed enough that it needed to be figured out :)
[09:47] <fabbione> hey guys
[09:59] <siretart> hi fabbione
[11:41] <revilodraw> hi, i just got banned from #ubuntu for making a joke that wasnt even bad... how do i get unbanned?
[11:41] <stdin> revilodraw: #ubuntu-ops
[11:42] <elkbuntu> revilodraw, i have private messaged you. please join #ubuntu-ops or register to continue the discussion
[11:59] <geser> seb128: thanks for processing sync request on a saturday night
[12:27] <seb128> geser: you're welcome ;)
[12:28] <seb128> geser: I was quickly looking on something and I figured I would do the syncs in the same time since there was not so many of them
[12:29] <Hobbsee> heya seb128
[12:30] <Hobbsee> didnt know you were here today :)
[12:30] <seb128> hey Hobbsee
[01:02] <GyrosGeier> doko, better channel. :-)
[01:03] <GyrosGeier> doko, currently the libssp-default patch is applied if the host is Ubuntu
[01:04] <GyrosGeier> doko, it might make sense to switch that to "target is Ubuntu"
[01:04] <GyrosGeier> doko, or, alternatively, to not patch this into the compiler but rather modify the specs file after the fact, as I do with uclibc-toolchain
[01:04] <doko> we don't have a configuration for a "target distribution"
[01:05] <GyrosGeier> which is why option 2 sounds more sane to me
[01:06] <GyrosGeier> would you be interested in a patch that does that?
[01:07] <doko> that doesn't help for building the compiler itself
[01:07] <GyrosGeier> it does if the target libc does not have libssp built in
[01:08] <GyrosGeier> because after stage 2, -fstack-protector is in effect (as it should be), but libssp is not built yet
[01:08] <GyrosGeier> hmm#
[01:08] <GyrosGeier> wait
[01:08] <GyrosGeier> I see what you mean
[01:09] <GyrosGeier> right, it doesn't help
[01:09] <GyrosGeier> so what would be needed is either building libssp first
[01:10] <GyrosGeier> (I think it should be safe to build libssp with ssp enabled, but I need to check)
[01:10] <GyrosGeier> or build-depending on the target libssp for cross builds
[01:12] <GyrosGeier> (which would also require checking whether libc provides libssp, and adding -lssp to the default libs if not)
[01:15] <mdke> seb128: hiya. Saw your post about bzr. Were you thinking of including gnome-user-docs in the move? I've arranged a vcs-import of svn trunk at https://code.launchpad.net/~vcs-imports/gnome-user-docs/trunk, and would be interested in finding out how to use it to make some ubuntu-specific changes and maybe host the packaging
[01:16] <mdke> seb128: I was going to start reading the docs on the wiki about maintaining packages in bzr, would be grateful for your input
[02:03] <seb128> mdke: I'm not an expert about packaging in bzr, I'm trying to get some ideas on the topic
[02:03] <mdke> seb128: ok, I'll follow the thread. I've read the wiki page, it's pretty difficult to understand the best way to do it
[02:03] <seb128> mdke: I don't think having gnome-user-docs in ubuntu-desktop is a good idea, we will give commit access to the people of the team and I don't think the same group of people will work on it
[02:03] <mdke> seb128: right
[02:04] <mdke> so ~ubuntu-docs then, I guess
[02:05] <seb128> right
[02:05] <seb128> for the documentation is might make sense to have everything in bzr and not only the debian dir
[02:05] <mdke> I was thinking the same. That would allow us to customise the docs directly rather than write patches
[02:05] <mdke> seb128: but I don't know how that would work with Debian changes (if there are some)
[02:12] <seb128> mdke: you would have a debian branch and an ubuntu one and merge when there is an update
[02:14] <mdke> seb128: you mean a branch for the debian directory and merge from Debian upstream, and a branch for ubuntu with the documents and merge from Gnome upstream?
[02:15] <seb128> not trivial with the 3 versions, I'm not the best person to ask
[02:15] <seb128> maybe mail ubuntu-devel-discuss about it
[02:15] <mdke> sorry if I'm being slow, i've never used bzr
[02:15] <mdke> ok thanks
[03:32] <pygi> hey seb128
[03:32] <seb128> hi pygi
[03:32] <pygi> seb128, in a few days, all brasero-related functionality bugs will be closed, yay :)
[03:33] <seb128> cool
[03:33] <pygi> I've saw you uploaded experimental patch for n-c-b
[03:35] <pygi> s/saw/seen
[03:35] <seb128> pygi: "experimental"?
[03:36] <seb128> pygi: I don't think there is anything experimental in the ncb patches, is it?
[03:36] <pygi> seb128, I meant not tested :)
[03:37] <seb128> do you insinuate that I don't test changes before uploading?
[03:37] <pygi> ergh, no
[03:37] <pygi> when did I say that?
[03:37] <seb128> I don't know where you want to go but you should better ask directly your question if there is one
[03:37] <seb128> "I meant not tested"
[03:37] <pygi> no question, just saying I saw the upload
[03:37] <seb128> k
[03:37] <pygi> sorry if you got it any other way
[03:37] <seb128> and why do you think it's not tested?
[03:38] <seb128> I did test it!
[03:38] <pygi> oh well, then not in upstream tree yet :P
[03:38] <seb128> right
[03:38] <seb128> I knew that
[03:38] <seb128> are you just pointing it, or do you have any comment about that patch? ;)
[03:39] <seb128> I'm not sure where you want to go
[03:39] <pygi> seb128, I didn't had the time to look at the patch =)
[03:39] <pygi> well, nowhere really :P
[03:39] <seb128> k
[03:39] <pygi> Just saying I saw the upload :)
[03:39] <seb128> because I also uploaded a GTK+ patch today
[03:39] <pygi> Nice to see some fixes =)
[03:39] <seb128> ;)
[03:42] <pygi> ergh, even the upgrade didn't go well
[03:43] <pygi> o well, lets see what a reboot will say
[03:43] <pygi> brb
[08:30] <soren> iwj: Do you have an opinion on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421344 ?
[09:16] <asac> calc: you still need me?
[09:22] <calc> asac: i was just going to ask how the wifi stuff was progressing
[09:22] <asac> well ... for ipw we have not yet founda  solution
[09:22] <asac> we know that the reason is that assocation on driver level appears to take ages
[09:23] <calc> asac: oh?
[09:23] <calc> asac: so its a driver issue?
[09:23] <asac> well at least wpa supplicant doesn't do anything in the meantime
[09:23] <asac> well wpasupplicant might be able to deal better with disassociate events from driver
[09:23] <asac> i need to get some ipw hardware
[09:24] <calc> hmm ok
[09:24] <asac> otherwise, I cannot really proceed
[09:24] <calc> from what i have been told the driver in feisty and gutsy is the same revision
[09:24] <calc> so if something changed it would have to be outside the driver that caused it to show up, if there is a bug in the driver
[09:25] <asac> hmm at least for 2100:
[09:25] <asac> (gutsy)asac@hector:~$ apt-cache show ipw2100-source | grep Version
[09:25] <asac> Version: 1.2.2-2
[09:25] <asac> asac@hector:~$ apt-cache show ipw2100-source | grep Version
[09:25] <asac> Version: 1.2.1-2
[09:25] <asac> second one is feisty
[09:25] <calc> hmm yea
[09:25] <asac> for ieee80211-source its the same version
[09:25] <asac> Version: 1.1.6-4
[09:25] <calc> BenC: said the 3945 driver was the same in both
[09:26] <asac> yeah is probably right then
[09:26] <calc> though i haven't verified that myself
[09:26] <asac> maybe you or stgraber can test feisty wpasupplicant in gutsy ... like we did back a few days
[09:26] <asac> and see if time till assocation goes down
[09:27] <calc> yea, i'll try to remember to look into that tomorrow, i'm pretty busy today :\
[09:27] <ScottK> calc: Any word on OOO refusing to start?
[09:28] <calc> ScottK: it seems to be more widespread than ooo, from what i read on a bug report it appears glib broke abi compatibility without proper versioning
[09:28] <calc> it breaks various kde stuff as well from what i recall
[09:28] <ScottK> Ah.  So it's glib
[09:28] <ScottK> Konqueror is suffering with Flash too.
[09:28] <calc> ScottK: either glib or gtk, it was a few days ago when i read the bug reports
[09:29] <calc> i didn't realize it at the time the reason i probably don't see the issue is i have ooo 2.3 installed on my box
[09:29] <ScottK> Well I'd heard gtk, but there's a new one and no change.
[09:29] <calc> ScottK: yea its probably glib
[09:29] <calc> the ooo bug is attached to glib as well
[09:29] <ScottK> OK.
[09:30] <ScottK> Sounds like lots of fun.
[09:30] <calc> when i finally get 2.3 uploaded it will be resolved for ooo, but breaking abi isn't a good thing, probably breaks other things people haven't reported yet as well
[09:30] <nixternal> hehe
[09:31] <ScottK> nixternal laughs because he is suffering too.
[09:31] <nixternal> I just found it funny because calc is probably getting asked a few times a day about OOo..I know he breathed a small sigh of relief when he found out the problem was elsewhere :)
[09:33] <ScottK> In the scheme of things this isn't so bad.  I just had to go get ice for my laptop because of a kernel regression that makes the fan not work.
[09:34] <calc> nixternal: well i knew it had to be elsewhere immediately since i hadn't done an upload in over a week and it just started breaking everywhere, lol
[09:34] <Amaranth> Does OOo use some things in gtk that aren't really supposed to be public in order to do its 'integration'?
[09:34] <calc> Amaranth: no idea
[09:35] <calc> Amaranth: it has a bit of source to look through ~ 3gb worth
[09:35] <Amaranth> I know there are some things you can poke at in gtk+ that aren't guaranteed to be API/ABI stable
[09:35] <calc> Amaranth: though the fact it is breaking other things as well points towards glib/gtk
[09:35] <Amaranth> Might have been the tooltips stuff
[09:35] <calc> Amaranth: someone that knows a lot about glib should probably check the diff between when it worked and broke
[09:36] <Amaranth> a member in a struct changed name and is always NULL now and some things used that (but shouldn't have)
[09:36] <Amaranth> i know it broke pygtk
[09:37] <nixternal> it broke notify-send as well :(
[09:37] <calc> Amaranth: ah thats interesting, its possible that the things that broke used the same member
[09:38] <calc> if that is the case then 2.3 is fixed
[09:38] <calc> because it works fine for me
[09:38] <ScottK> When are you rolling 2.3 out for Gutsy?
[09:38] <calc> asap
[09:39] <calc> i'm merging debian/ubuntu debian dir right now and rewriting bits so its easier to keep merged
[09:39] <Amaranth> yeah afaik it crashed apps that didn't expect it to be NULL and made them fail to build
[09:39] <calc> there is an issue of gcj-4.2 running out of memory during build though so i had to disable java support right now
[09:39] <calc> doko: mentioned that it was supposed to be fixed (iirc)
[09:43] <doko> calc: it is fixed
[09:47] <calc> doko: i upgraded and it still failed yesterday, i think i will try completely regenerating my chroot then
[09:48] <doko> calc: what version of libc6 do you have?
[09:48] <calc> 2.6-4ubuntu2
[09:55] <doko> calc: that should be ok, maybe work on i386 for now.
[10:09] <calc> doko: i was doing the compile on i386, so i'll try redoing the chroot and building again later tonight