[00:08] <RoAkSoAx> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for  http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
[00:08] <RoAkSoAx> kirkland: in a bit will be uploading testdrive
[00:20] <kirkland> RoAkSoAx: cool
[00:20] <kirkland> RoAkSoAx: i'll blog the notifier thing ;-)
[00:20] <kirkland> RoAkSoAx: that's going to be great!
[00:21] <RoAkSoAx> kirkland: indeed!! also jcastro requested to add quicklist support for available isos for Unity
[00:22] <kirkland> RoAkSoAx: cool
[00:23] <RoAkSoAx> kirkland: uploaded. Should be building soon
[00:23] <kirkland> RoAkSoAx: \o/
[00:52] <RoAkSoAx> kirkland: alrighty it is build, not yet published though. What's gonna happen, is that around 5 seconds after you first started it will check if there are any available ISO's and display the notification if it does/. Otherwise will continue check every 1 hour for now. Later on I'll make that configurable
[00:52] <kirkland> RoAkSoAx: that's totally awesome!
[00:52] <RoAkSoAx> kirkland: let me know, as always, if how it goes :D.
[00:53] <RoAkSoAx> im gonna go grab something to eat in the meanwhile
=== jjohansen is now known as jj-afk
=== ogra_ is now known as ogra
=== SolidLiq is now known as solid_liq
=== dendro-afk is now known as dendrobates
[02:00] <psusi> hallyn, you recently changed multipath-tools to use 'path' instead of 'p' to separate base device from partition number.  why is this?  Where do these rules come from about what to separate with?  dmraid has been using 'p' for some time, but Curtis Gedak ( gparted maintainer ) has told me that it should only add the p if the base name already ends in a number
=== kenvandine_ is now known as kenvandine
[02:04] <hallyn> psusi: using path instead of p comes from the debian packages
[02:04] <psusi> hallyn, ohh, so they added the patch and you just merged it?  any idea why?  it seems it will screw things up...
[02:06] <psusi> there are several components that all seem to be building the names differently when they should be agreeing... kpartx adds 'p' only if the last character of the base name is a digit... recent versions of dmraid always add the p, and now it seems that this init script got changed to tell kpartx to use part instead of p... it doesn't make sense
=== dendrobates is now known as dendro-afk
[02:13] <RoAkSoAx> kirkland: still around?
[02:14] <hallyn> psusi: no they didn't add the patch.  They don't use that rule
[02:15] <psusi> hallyn, so what did you mean it comes from the debian packages?  why was it changed from p to part?
[02:15] <hallyn> psusi: the p had come from me by mistake.  debian uses part
[02:15] <hallyn> see for instance debian/kpartx.udev in lp:debian/experimental/multipath-tools
[02:15] <kirkland> RoAkSoAx: halfway here
[02:15] <psusi> hallyn, why?  upstream kpartx and dmraid just use the letter p
[02:16] <RoAkSoAx> kirkland: quick thingy: I'm planning to add something like this additionally to the MessagingIndicator: http://me.roaksoax.com/notify.png What do you think?
[02:17] <kirkland> RoAkSoAx: looks great
[02:17] <hallyn> psusi: I don't know why.  because it looks less SunOS4.x-y ?
[02:17] <hallyn> psusi: but I just wanted to make it consistent
[02:17] <RoAkSoAx> kirkland: cool, will do in the next release then
[02:18] <psusi> hallyn, that's my problem... I am seeing 4 different programs that all have a different way of doing it now which messes things up... they need to all agree
[02:18] <hallyn> psusi: my change was just to the initramfs/local-top script wasn't it?
[02:18] <psusi> hallyn, sounds like it
[02:18] <hallyn> psusi: yes, they need agree
[02:18] <hallyn> psusi: I wonder where is the best place to get all the relevant people together
[02:18] <psusi> email :)
[02:19] <kirkland> RoAkSoAx: just upload again ;-)
[02:19] <hallyn> psusi: but which list?
[02:19] <psusi> I'm working up a message to dm-devel right now... probably should figure out a few more places to add to the Cc
[02:19] <psusi> maybe the debian maintainer of multipath-tools?
[02:19] <hallyn> sounds good.
[02:20] <psusi> it seems that gparted likes the method upstream kpartx uses of adding just a p and only if the base name ends in a digit.. it goes so far as to explicitly tell dmraid to NOT use any character rather than letting the new versions always add the 'p'
[02:21] <psusi> I guess I'll include Curtis as well then...
[02:21] <psusi> you want on it?
[02:21] <hallyn> yup, i personally coudl care less, but I know that if you install a multipath lucid system, it will use -partX right now
[02:21] <hallyn> well, i'm on dm-devel, but wouldn't mind a copy to make sure i don't miss it
[02:22] <psusi> what's your addy?
[02:22] <hallyn> (i'm pretty ruthless with mailing list email in the morning)
[02:22] <hallyn> serge.hallyn@ubuntu.com
[02:22] <hallyn> thanks
=== dendro-afk is now known as dendrobates
=== rsalveti` is now known as rsalveti
[03:09] <tomreyn> hi
[03:09] <tomreyn> with this backtrace, which package do i file a bug against?       http://paste.ubuntu.com/567540/
[03:10] <hallyn> pulseaudio?
[03:11] <tomreyn> ah so not libopenal1
[03:12] <hallyn> no, yeah, i'd start with libopenal1
[03:12] <hallyn> openal-soft is the name of the package looks like
[03:14] <tomreyn> I have no package of the name "openal-soft" installed, though
[03:14] <tomreyn> maybe that's the upstream name
[03:17] <RAOF> That's the source package name; it generates libopenal1
[03:19] <tomreyn> thanks guys/gals
[03:28] <yellowblue> sup niggas im true gangsta
[03:28] <yellowblue> !ops
=== mbiebl_ is now known as mbiebl
[06:10] <robertzaccour> can i attatch a video to a bug report?
[06:10] <robertzaccour> I want people to see exactly what I'm experiencing here
[06:11] <persia> robertzaccour, You could, but folks may not want to download it: you'd do better to try to describe in detail, perhaps with before and after screenshots or similar.
[06:11] <robertzaccour> well I'm reporting compiz and gtk-recordMyDesktop not playing well together
[06:12] <robertzaccour> whenever I do a screen recording with compiz on, it totally bugs out
[06:12] <robertzaccour> some apps like docky require compiz. both docky and gtk-recordMyDesktop are in the repos
[06:15] <robertzaccour> Whenever I do a screen recording with gtk-recordMyDesktop and compiz running at the same time, which it does by default, The recording is always very buggy and still-framed for the most part and crazy mixes of coloring. Some applications (that are in the repos) require compiz to run properly e.x. docky. Since compiz and gtk-recordMyDesktop are both in the repos, I do believe this qualifies as a bug.
[06:23] <persia> Ah, yes, in that case, attaching the result video may be useful :)
[06:24] <robertzaccour> persia, its been a few minutes since i clicked submit but with the video attatched, and its still not paged over
[06:24] <robertzaccour> oh it just did good
[06:25] <robertzaccour> #719818
[06:32] <mneptok> !bug 719818
[06:32] <ubottu> Launchpad bug 719818 in compiz (Ubuntu) "compiz doesn't play well with gtk-recordMyDesktop" [Undecided,New] https://launchpad.net/bugs/719818
[06:32] <mneptok> taa-daa!
[06:34] <robertzaccour> mneptok, :) now i know thanks
[06:38] <ikonia> robertzaccour: it may do you well to read the topic of this channel
[06:38] <ikonia> robertzaccour: this channel is not for bug reporting or support
[06:38] <robertzaccour> I have a feeling I might just be screwed based on my GPU. No issues in windows so I figured it might be fixable
[06:39] <robertzaccour> ikonia, maybe someone here knows how to fix drivers? This is a developers channel
[06:39] <ikonia> robertzaccour: no, I just said, this is not a support or bug channel, it's a development discussion channel
[06:40] <robertzaccour> you remind me of a youtube comment tracker
[06:41] <persia> ikonia, Maybe nice to redirect to -bugs for this sort of thing?
[06:41] <ikonia> persia: I told him to read the topic
[06:41] <ikonia> the topic tells him where to go
[06:41] <ikonia> he found it
[06:42] <persia> I suppose.
[06:42] <ikonia> the guy wasted hours in #ubuntu not listening to help yesterday *UK time*, he needs to stop randomly doing things and start listening
[06:43] <persia> Ah.  The background makes all clear :)
[06:54] <pitti> kees: maxsize> it's not any more actually; just if I change it, people might get dpkg conffile questions a lot..
[07:03] <kees> pitti: but you'll have to do an update for rc to enable apport, yes?
[07:04] <pitti> kees: "disable", yes
[07:05] <kees> couldn't you fold it into that?
[07:06] <pitti> kees: I could change it at any time, but that doesn't change the fact that the conffile in the RC would suddenly change for upgraders who ever touched it
[07:06] <pitti> I guess it's a pain we have to take at some point
[07:06] <pitti> or I could actually make it work again :)
[07:08] <kees> no, I don't like maxsize. :)
[07:08] <kees> I like 3/4 memory, though the error could be improved.
[07:09] <kees> pitti: this all stems from me looking at bug 718635
[07:09] <ubottu> Launchpad bug 718635 in apport (Ubuntu) "Error message "Your computer does not have enough free memory" when core dump or stacktrace failed to be created is misleading" [Low,Incomplete] https://launchpad.net/bugs/718635
[07:10] <persia> Does apport consider cache/buffers free when calculating "free memory" for that purpose?
[07:15] <kees> persia: yup
[07:15] <kees> persia: see my later comments showing the calculation
[07:15] <kees> slangasek: should bug 716703 be counted on the arm porting jam?
[07:15] <ubottu> Launchpad bug 716703 in chromium-browser (Ubuntu Natty) "chromium-browser not built PIE on ARM" [Medium,Confirmed] https://launchpad.net/bugs/716703
[07:15] <persia> Ah, cool.
[07:15] <pitti> persia: it looks at /proc/meminfo, and uses (MemFree + Cached - Writeback) * 1024 * 3/4 as a limit
[07:16] <slangasek> kees: yes - it's there on the list
[07:16] <kees> slangasek: oh, so it is! I hadn't noticed the tag get added
[07:17] <kees> persia, pitti: actually, I guess it doesn't subtract buffers
=== tkamppeter_ is now known as tkamppeter
[07:40] <dholbach> good morning
=== hunger_ is now known as hunger
=== jj-afk is now known as jjohansen
[08:00] <didrocks> good morning
[08:02] <iqbal> anyone use lammp?
[08:02] <iqbal> i have a problem
[08:02] <iqbal> no lampp folder in /opt
[08:03] <iqbal> but apache php and phpmyadmin run
[08:03] <iqbal> morning didrocks
[08:04] <didrocks> morning iqbal
[08:05] <iqbal> are you install lampp on ubuntu
[08:05] <iqbal> ?
[08:21] <poolie> vila, hi, i'm just updating https://dev.launchpad.net/LEP/BuildFromBranchIntoPrimary and am going to circulate it later
[08:21] <poolie> if you would care to look over it now and point out any questions that would be nice
[08:22]  * vila reads
=== smb` is now known as smb
=== MacSlow is now known as MacSlow|afk
[08:31] <vila> poolie: I had some notes and after re-reading they still seem valid: http://paste.ubuntu.com/567571/
[08:32] <vila> grr, no line breaks
[08:32] <poolie> it's ok
[08:32] <vila> http://paste.ubuntu.com/567573/
[08:40] <poolie> by 'build based on a revision property' you mean at commit time you'd say whether it should be built or not?
[08:40] <poolie> interesting idea
[08:40] <vila> yes
[08:41] <poolie> if that's when we want to make the decision, we could equally well say that if there is a changelog entry it will build
[08:41] <vila> one way or another, the dev decides what should be built, istm he knows that when he commits or he can still decide after the fact by doing a changeless commit and pushing it
[08:43] <poolie> either that or an api call
[08:43] <vila> there may be a grey area if he ``push --overwrite`` though but that could guarded against with append_revisions_only
[08:43] <poolie> probably doing it off the commit is cleaner
[08:43] <vila> and trackable
[08:44] <vila> and gives if we can find a place to put the revid in the build artifact we also get a way to retrieve the source
[08:44] <vila> s/gives//
[08:45] <GunnarHj> Hi all,
[08:45] <GunnarHj> Suddenly I have no longer web access to lp:language-selector. Anybody who can tell why? Maybe somebody who don't want me to propose more mergers...
[08:45] <vila> note to self: add a semaphore between writer and reviewer when chatting
[09:05] <ricotz> diwic, hi :), will alsa 1.0.24 be in natty?
[09:07] <diwic> ricotz, that's the plan
[09:07] <diwic> ricotz, do you have any personal preference, and why?
[09:14] <ricotz> diwic, currently i dont really need it, but i am running your ppa packages without any complains, and since the last alsa upstream is one year old, it should just be updated
=== smb` is now known as smb
[09:31] <diwic> ricotz, ok, yesterday I realized that I forgot to include alsa-driver as well, I'll package that today or tomorrow hopefully
[09:34] <ricotz> diwic, great, perhaps it is usefull to use dh-autoreconf to avoid shipping a relibtoolize patches, but this might be coordinated with debian maintainer
[09:35] <diwic> ricotz, something like that - how to package autotools is a complete science :-/
[09:35] <diwic> ricotz, but I'm all for skipping large crazy diffs
[09:40] <ricotz> diwic, shouldnt be so hard adding it, i havent looked at the alsa packaging lately, did you talk to jordi mallach yet?
[09:40] <diwic> ricotz, I talked to the pkg-alsa-devel ML, Elimar has answered but not Jordi
[09:42] <ricotz> diwic, you can find him in #debian-gnome on oftc
[09:46] <jibel> latest util-linux in Natty looks broken, bug 719754 , anyone taking care of it ?
[09:46] <ubottu> Launchpad bug 719754 in util-linux (Ubuntu) "package mount 2.17.2-3.3ubuntu4 failed to install/upgrade: subprocess new pre-installation script returned error exit status 127" [Critical,Triaged] https://launchpad.net/bugs/719754
[09:49] <jibel> lool, ^
[09:52] <mdz> pitti, is it appropriate to submit new devices to media-player-info these days? my phone isn't listed
[09:54] <lool> jibel: uploading, thanks
[09:55] <RAOF> mdz: I'm pretty sure that's still used by applications; it uses udev rules and I think banshee uses that info.
[09:56] <mdz> RAOF, yes, it's definitely still active, but every few months or so it seems there is a new Right Way to Do It :-)
[09:57] <RAOF> Too true!
[10:06] <apw> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for  http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: apw
[10:06] <mdz> howdy apw
[10:07] <apw> morning
=== MacSlow|afk is now known as MacSlow
[10:19] <pitti> mdz: yes, of course; usually to https://bugs.freedesktop.org/enter_bug.cgi?product=media-player-info (launchpad works as well, though)
[10:19] <mdz> pitti, thanks!
[10:49] <apw> pitti, i think you looked at the UDF DVD issue -- bug 635499
[10:49] <ubottu> Launchpad bug 635499 in linux (Ubuntu) "[Maverick, Lucid] Does not show UDF contents" [Undecided,Confirmed] https://launchpad.net/bugs/635499
[10:50] <apw> specifically it seems that later version of windows are using rrr on directories ...
[10:50] <apw> looking at the spec it appears we are actually doing what is mandated by the spec
[10:50] <apw> ie, the are 'wrong'
[10:52] <apw> (the disks are mastered incorrectly) ... now do we want to override that for RO media ?
[10:53] <pitti> argh, that sounds tricky -- can we add permissions in mount options as well? or just remove them a la fmask, dmask?
[10:53] <apw> pitti, you can override all permissions for a directory for instance yes
[10:53] <pitti> ah, mode= and dmode=, I didn't know about that one
[10:54] <apw> pitti, yeah we have a hammer for it.  udf appears to be a format which can be used on writable media in theory; though i have never heard of doing it
[10:54] <apw> so if we are doing somethign like that then we might want to do it for 'read only' 'removable' media only or something
[10:54] <pitti> apw: I did actually; isn't that what you would usually do on packet writing CDs/DVDs?
[10:54] <pitti> you can't use iso9660 on them
[10:55] <apw> that is possible, packet writing is mentioned, though i was thinking of real 'rewriable' metia such as hard-drives which are mentioned in this spec too
[10:55] <apw> pitti, so i'll write up what the spec says, to confirm that us failing to read a 444 directory is what the disk asked us to do
[10:56] <apw> i guess the logical thing to do is do it in udev or something?
[10:56] <pitti> apw: mode/dmode isn't documented yet in mount(8) as it seems; but apparenlty it has worked for a while now
[10:56] <apw> udisks even
[10:56]  * dholbach hugs apw
[10:56] <pitti> apw: udisks, yes
[10:56] <apw> dholbach, thanks :)
[10:56] <dholbach> thank YOU :)
[10:57] <pitti> apw: I guess having 0400 for files is not a big problem, so we don't need to fiddle with "mode"?
[10:58] <apw> pitti, if my reading of this bug is right, it seems to be 'worked with disks made before vista' and not since
[10:59] <apw> its actually sounding like 'newer versions of UDF now support permissions bits'
[11:00] <apw> pitti, hmm seems there is a bug in windows as the spec (which mentions windows specifically and how it implements permissions) it says that the execute bit should be honoured for directories only on windows ... hrm
[11:01] <pitti> apw: that sounds confusing -- it shoudl be honoured on the system that gets them wrong?
[11:02] <apw> yeah, as permissions on the disk are pretty unix'ey in semantics there is a table of how to map them in various OSs and specifically how they should be mapped to local permissions
[11:02] <apw> and that says "file execute" is ignored on windows as there is no mapping for it, but directory execute is mapped and 'Enforced'
[11:02] <apw> clearly not in reality of course else the disk would be the same there
=== diwic is now known as diwic_afk
[11:09] <apw> pitti, ok i've pushd in the spec information, should i move it back to udisks do you thnk ?
[11:09] <pitti> apw: thanks for the spec additions; I'll keep it on my radar and discuss with upstream for a fix in udisks
[11:24] <apw> pitti, ack and thanks ...
=== cjwatson changed the topic of #ubuntu-devel to: Archive: all uploads failing, LP team aware | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: apw
[11:32] <cjwatson> if you get reject messages like http://paste.ubuntu.com/567617/, the LP team is on it
[11:38] <Laney> does it affect all uploads?
[11:38] <Laney> oh, /me didn't see the topic change
[11:49] <ogra> cjwatson, http://people.canonical.com/~ubuntu-archive/component-mismatches.txt shows libqtbamf1 and libqtgconf1 binaries arent promoted, i only seeded unity-2d as the toplevel package, do i need to seed the launcher explicitly to get them into main or is that just a promotion issue ?
[11:51] <cjwatson> that output is telling you that you got it right
[11:51] <cjwatson> and that we just haven't promoted them yet
[11:51] <cjwatson> I've promoted them now
[11:52] <ogra> k, i thought so, just wanted to be sure its not something missing on my side
[11:52] <ogra> thanks :)
[11:52] <ogra> hmm, though it seems i need to seed unity-2d-default-settings. as transitional package it doesnt get pulled in by anything
[11:53] <pitti> ogra: unity-2d-default-settings only exists in natty, why do we need it as a transitional packages? just for alpha-2 installs?
[11:54] <ogra> pitti, for upgrades for people that had the maverick PPA
[11:54] <pitti> ah
[11:54] <pitti> ogra: they won't get unity-2d otherwise?
[11:54] <ogra> though i think we should probably just do the transition there
[11:54] <ogra> they will indeed
[11:54] <pitti> ogra: I'd assume that "unity-2d" would be in the PPA as well then
[11:55] <pitti> then natty's unity-2d could just conflicts/replaces: unity-2d-default-settings, to get it cleaned up on upgrade, and the package could go away entirely
[11:55] <ogra> it is, and has the right breaks/replaces in natty
[11:55] <pitti> Breaks: unity-2d-default-settings (<= 0.4)
[11:56] <pitti> that should probably be bumped then
[11:56] <ogra> i have to try an upgrade if everything in natty is in order to make sure everything is right
[11:56] <ogra> PPA has 0.4
[11:56] <pitti> ogra: I mean, if you want to ditch the unity-2d-default-settings transitional package entirely in natty, you'd need to bump the breaks/replaces version
[11:56] <ogra> ah, yeah
[11:57] <ogra> will do that with the next upload and after a test upgrade
=== kmos1 is now known as Kmos
=== MacSlow is now known as MacSlow|lunch
=== cjwatson changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: apw
[12:23] <cjwatson> (uploads fixed, thanks wgrant)
=== diwic_afk is now known as diwic
[12:27] <wgrant> cjwatson: Only yours was affected, FWIW.
[12:27] <cjwatson> odd!
[12:28] <cjwatson> oh, just nobody else uploaded in the relevant time window?
[12:28] <wgrant> Right.
=== shadeslayer_ is now known as shadeslayer
[13:25] <seb128> cjwatson, did you read any recent issue with dpkg triggers?
[13:27] <seb128> cjwatson, I'm trying to make sense of a issue which started being reported recently where the gdk pixbuf svg loader doesn't work on new installs
[13:29] <seb128> neither gdk-pixbuf or librsvg got an recent upload and the gdk loaders index is built in the libgdk-pixbuf postinst or refresh by a trigger when a loader is installed
[13:29] <seb128> but it seems the svg loader is missing from the index somehow
[13:29] <seb128> not sure how that could happen out of having the trigger not triggering
[13:30] <cjwatson> the only issues I've heard of are ones where some package management frontends don't give apt/dpkg a terminal, which tends to result in triggers failing when they try to output anything
[13:30] <cjwatson> but that causes hard failures, not didn't-trigger
[13:30] <seb128> hum k
[13:40] <seb128> cjwatson, ok, I think I found a clue on the livfs build log
[13:40] <seb128> "libpixbufloader-svg.so: libGL.so.1: cannot open shared object file: No such file or directory"
[13:42] <seb128> seems that's because the libgdk postinst is configured first and the libGL ldconfig is not done yet
=== zyga is now known as zyga-afk
[13:43] <seb128> what is the right way to deal with that? use a pre-depends to ensure libGL's ldconfig call is set before the libgdk-pixbuf install?
[13:44] <cjwatson> pre-depends would be wrong.  that causes configuration to happen before another package is *unpacked*
[13:45] <cjwatson> anyway, it has no effect on triggers, which is what's happening here
[13:45] <cjwatson> I'd suggest changing libGL to do 'LDCONFIG_NOTRIGGER=y ldconfig'
[13:45] <cjwatson> (whatever package provides it)
[13:46] <cjwatson> with a comment saying that we need to force this to happen immediately so that other packages are happy, or some such
[13:46] <pitti> barry: may I prod you about the computer-janitor pygi branch again? I just updated it to yesterday's upload, so it merges cleanly again
[13:47] <seb128> cjwatson, well, in that case the call which fails is the libgdk-pixbuf-2 post installation script one
[13:47] <seb128> cjwatson, so the pre-depends would fix it but there would still be the trigger case to be buggy, I think it's better to do what you suggest, thanks
[13:47] <seb128> tjaalton, bryceh, Sarvatt: ^
[13:50] <cjwatson> seb128: pre-depends wouldn't fix it because pre-depends on package A doesn't wait for triggers pulled by A to have happened
=== MacSlow|lunch is now known as MacSlow
[13:52] <seb128> cjwatson, right, but it would assure the package is configured first, which is needed if that's the post install script which calls ldconfig?
[13:53] <cjwatson> seb128: the postinst calls ldconfig, but ldconfig is a wrapper script nowadays; when called from a maintainer script, it normally only pulls the trigger and returns immediately
[13:53] <seb128> cjwatson, or do we assure that the libgl ldconfig is done before the gdkpixbuf package is configured?
[13:54] <cjwatson> if it needs to actually do ldconfig work immediately, that's what LDCONFIG_NOTRIGGER=y is for
[13:54] <seb128> cjwatson, I got that, we need 'LDCONFIG_NOTRIGGER=y' and a way to assure the postinst for libgl is called first?
[13:54] <cjwatson> Depends would be sufficient for that
[13:54] <cjwatson> Pre-Depends just gets in other things' way
[13:55] <cjwatson> actually, though, I suspect you don't need Depends
[13:55] <cjwatson> I think the reason that ldconfig needs to be forcibly called here is that various things divert libGL.so.1
[13:55] <cjwatson> which means that the cache is invalidated
[13:56] <cjwatson> my suspicion is that there is no need for a Depends - all we need to do is ensure that anything that diverts a library and installs a replacement version of it calls LDCONFIG_NOTRIGGER=y ldconfig
[13:56] <cjwatson> that way, you get one version of libGL or the other, not an error message
[13:56] <seb128> cjwatson, ok, I though that it was not assured that Depends would be configured before the binary which Depends on those
[13:56] <cjwatson> it's not, but you don't need that, that's what I'm saying
[13:57] <seb128> well libGL is not in /usr/lib
[13:57] <cjwatson> at least I don't think so
[13:57] <seb128> it's a special dir, which is why it doesn't find it until ldconfig is called
[13:57] <seb128> the ldconfig needs to happen before libgdk-pixbuf's postinst is called
=== zyga-afk is now known as zyga
[13:58] <cjwatson> hmm, libgl1-mesa-glx.postinst already uses LDCONFIG_NOTRIGGER=y
[13:58] <seb128> but it's run after the libgdk-pixbuf configuration...
[13:58] <seb128> so when libgdk-pixbuf postinst runs the ldconfig is not right
[13:58] <seb128> so it doesn't find the lib
[13:58] <cjwatson> yes I know, I'm thinking out loud :)
[13:58] <seb128> which is why I thoguh it would need a pre-depends
[13:59] <cjwatson> pre-depends => pointless, forget it please
[13:59] <seb128> ok
[13:59] <cjwatson> Depends is enough unless it's circular
[13:59] <seb128> should the libgdk-pixbuf call ldconfig before doing the gdk-pixbuf update?
[13:59] <cjwatson> which it wouldn't be here
[14:00] <seb128> hum, it already does it
[14:00] <cjwatson> looking at this, I think Depends: libgl1 would be enough
[14:00] <cjwatson> it's a bit nasty
[14:00] <cjwatson> you get to choose between:
[14:00] <cjwatson>  (1) artificial Depends: libgl1, to force the ldconfig cache to be brought up to date
[14:01] <cjwatson>  (2) artificial 'LDCONFIG_NOTRIGGER=y ldconfig' in libgdk-pixbuf2.0-0.postinst, to cope with the fact that the ldconfig cache may not be up to date
[14:02] <seb128> well, gdk-pixbuf shouldn't bring libgl, I can see some people not wanting it
[14:02] <seb128> let's go for (2)
[14:02] <seb128> cjwatson, thanks
[14:02] <cjwatson> does libpixbufloader-svg.so dlopen libGL?
[14:02] <seb128> yes
[14:03] <cjwatson> that would explain the lack of an explicit dependency there
[14:03] <seb128> would a librsvg2-common (which has the svg loader) depends on libgl work as well?
[14:04] <cjwatson> it would, but wouldn't that have the same "people might not want it" thing?
[14:04] <cjwatson> you could put (2) in librsvg2-common as an alternative, I suppose
[14:06] <cjwatson> on pre-depends: it should only be used when you need some other package's postinst to have run before your package's preinst, or in rare cases before unpacking your package's filesystem tarball (creating users/groups)
[14:07] <cjwatson> the problem with using it as a hammer to force other kinds of ordering is that it slows everything down by splitting things up into multiple dpkg runs, and it can create unresolvable loops
[14:07] <cjwatson> (because Depends can be circular, but Pre-Depends can't)
[14:08] <cjwatson> you can get particularly nasty Pre-Depends/Conflicts loops too
[14:08] <seb128> ok
[14:08] <cjwatson> so it's best to just confine its use to where it's necessary for stuff run in the preinst
[14:08] <seb128> is there a way to say "this binary postinst should run before my postinst"?
[14:08] <cjwatson> Depends
[14:08] <cjwatson> as long as it isn't circular, that will do it
[14:08] <seb128> ok, I though the unpackaging and configure order was not assured by depends
[14:09] <cjwatson> A Depends: B says exactly that B must be configured (postinst run) before A
[14:09] <seb128> that depends just assured that what you depends on will be installed
[14:09] <cjwatson> before A is configured
[14:09] <seb128> but not in which order
[14:09] <cjwatson> Depends says nothing about unpack order
[14:09] <cjwatson> but it very definitely says something about configure order
[14:09] <seb128> ok, so issues I had in the past was with unpack orders
[14:09] <seb128> I should re-read that part of the debian policy, it has been a while
[14:09] <seb128> cjwatson, thanks!
[14:09] <cjwatson> np :)
=== hggdh_ is now known as hggdh
[14:31] <smoser> stgraber, ping
[14:42] <stgraber> smoser: pong
[14:43] <smoser> http://www.stgraber.org/2010/12/08/want-your-own-edubuntu-weblive/ "Installation is relatively trivial, just follow the README file in the branch.".  but "ls: cannot access README: No such file or directory"
[14:44] <stgraber> smoser: there's a README in the drupal-vmmanager branch, for the daemon part, there's packages for lucid, maverick and natty in my experimental ppa
[14:45] <smoser> i was looking at lp:vmmanager
=== sconklin-gone is now known as sconklin
[14:56] <sconklin> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: apw, sconklin
[14:57] <apw> dholbach, you'll be pleased to know that the kernel bugs with patches backlog has been reduced from 99 -> 89 today, from 120 when the patch pilot activities started ... and the oldest not responded bug is down from 221 weeks to 66 weeks
[15:02] <apw> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: sconklin
[15:02] <apw> sconklin, have fun !
=== herton is now known as herton_lunch
[15:11]  * ScottK pokes at lamont about postfix 2.8.0.
[15:13] <barry> pitti: sorry i haven't had time to review your branch yet.  but i will do that today for sure
[15:33] <dholbach> apw, rock and roll!
=== schmidtm_ is now known as schmidtm
=== dendrobates is now known as dendro-afk
=== diwic is now known as diwic_afk
=== bjf[afk] is now known as bjf
=== herton_lunch is now known as herton
=== doko__ is now known as doko
=== csurbhi1 is now known as csurbhi_
[16:32]  * csurbhi_ shall be back later
=== beuno is now known as beuno-lunch
[16:59] <GunnarHj> tedg: Hi Ted, are you there?
[16:59] <tedg> GunnarHj, I'm in a phone call...  so kinda :)
[17:01] <GunnarHj> tedg: Ok. Saw that you changed the status of https://launchpad.net/bugs/636693 to "Opinion" again. Could we talk about it, please? (after your phone call...)
[17:01] <ubottu> Error: Could not parse data returned by Ubuntu: list.index(x): x not in list (https://launchpad.net/bugs/636693)
[17:06] <superm1> pitti, it appears scour doesn't touch svg's at all right? bug 719735 seems really odd because the file is OK in the orig.tar.gz, but got busted in the binary deb somehow
[17:06] <ubottu> Launchpad bug 719735 in dell-recovery (Ubuntu) "dell-recovery crashed with GError in __init__(): Couldn't recognize the image file format for file '/usr/share/pixmaps/dell-dvd.svg'" [Undecided,New] https://launchpad.net/bugs/719735
[17:07] <pitti> superm1: it does touch svgs
[17:08] <superm1> any thoughts on how that could have happened then?
[17:11] <superm1> hmm actually it seems the binary deb itself is fine - there's an issue with opening svg's on natty then, i just checked with kent and it's not showing other svg's either properly
[17:14] <hyperair> how does one retry a build in launchpad?
[17:14] <hyperair> for a package that's not a PPA?
[17:15] <ScottK> hyperair: The same was as a PPA, but you have to have upload rights for the package.  What do you need retried?
[17:16] <hyperair> ScottK: gnu-smalltalk.
[17:16] <hyperair> ScottK: i don't see a rebuild button, and it seems to be in universe
[17:16] <ScottK> hyperair: Link me to the build page.
[17:17] <hyperair> https://launchpad.net/ubuntu/+source/gnu-smalltalk/3.2-1/+buildjob/1735324
[17:17] <hyperair> someone was complaining about the lack of an amd64 package in ubuntu
[17:17] <Laney> you probably need to do a no-change SRU for that (as it's in release)
[17:17] <hyperair> i see.
[17:20] <hyperair> Laney: so should i make two uploads (natty and maverick-proposed), or should i just make one to maverick-proposed and have it copied forward?
[17:20] <Laney> you can do the latter
[17:20] <dupondje> could somebody check https://bugs.launchpad.net/ubuntu/+source/gtk-vnc/+bug/711442 plz. Need to get the patch in Natty :)
[17:20] <ubottu> Ubuntu bug 711442 in vinagre (Ubuntu) "vinagre crashed with SIGSEGV in g_socket_send()" [Medium,New]
[17:20] <Laney> if the versions are equal then it will be copied when it is accepted into proposed
[17:20] <hyperair> oh nice
=== sforshee is now known as sforshee-lunch
[17:48] <seb128> dupondje, you should subscribe ubuntu-sponsors if you want a patch reviewed and sponsored
=== beuno-lunch is now known as beuno
[17:51] <ScottK> hyperair: I'd upload to Natty, make sure it builds OK and then do the SRU.
[17:52] <ScottK> It doesn't have a retry button because it doesn't have a natty build record.
=== deryck is now known as deryck[lunch]
[18:25] <dupondje> seb128: done
[18:27] <seb128> dupondje, thanks
[18:27] <dupondje> its a cherrypicked patch btw, so should be quite safe :)
=== deryck[lunch] is now known as deryck
=== sforshee-lunch is now known as sforshee
[19:10] <ari-tczew> cjwatson: there is a diff which could go into lilo by merging -10 revision: http://paste.ubuntu.com/567798/ what do you think, is it worth to merging?
[19:16] <ari-tczew> TheMuso: is alsa 1.0.24 going to be in natty?
[19:45] <ari-tczew> doko: do you know whether Debian is going to use gcc 4.6.* ?
=== dendro-afk is now known as dendrobates
=== ivanka is now known as ivanka-train
[20:30] <kees> ari-tczew: yes.
[20:30] <TheMuso> ari-tczew: Yes, thats the plan.
[20:30] <ari-tczew> kees: yes for?
[20:30] <kees> ari-tczew: using gcc-4.6 in Debian
[20:31] <ari-tczew> kees: ok
[20:31] <mvo> csurbhi_: hey, I think we can mark the n-btfs-support implemented for this cycle
[20:31] <kees> TheMuso: I find it very strange that we both unidled in this channel at exactly the same time. :)
[20:31] <TheMuso> kees: Yeah thought the same when I saw your reply.
[20:34] <ari-tczew> kees, TheMuso: in the first minute I thought that my connection is busy :-)
[20:49]  * mneptok starts the "Kess and TheMuso are acutally THE SAME PERSON" rumor
[20:50] <mneptok> Kees, even.
[20:50] <kees> hehe
=== diwic_afk is now known as diwic
[21:00] <tedg> GunnarHj, Unstacking... are you still around?
=== dendrobates is now known as dendro-afk
[21:20] <fatninja> Jordan_U : I'm here.
[21:20] <Jordan_U> fatninja: What experience do you have with programming in general?
[21:20] <fatninja> Hm
[21:21] <fatninja> Jordan_U : I'm a college student in first year in Computer Science, so it's not that good.
[21:22] <fatninja> The interesting thing is, that after I run Wubi and restart to complete instalation everything works with Ubuntu just fine, after the first restart
[21:22] <fatninja> It simply doesn't work, at first I thought that it cannot mount the NTFS Partition that I use
[21:22] <fatninja> but if the loader couldn't do that, then it couldn't complete the instalation
[21:23] <Jordan_U> fatninja: Then to be honest Wubi is probably not the best project to start contributing with. Especially this particular set of bugs will probablyy require working with many programming languages and advanced concepts.
[21:25] <fatninja> I see..
[21:26] <fatninja> Too bad NTFS isn't like HFS+ Extended, I can't resize it ...
[21:27] <micahg> fatninja: you can resize ntfs
[21:27] <fatninja> micahg that's what I said .
[21:31] <mneptok> HFS. *snort*
[21:40] <Jordan_U> fatninja: You should be able to resize hfsplus.
[21:42] <sconklin> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
=== dendro-afk is now known as dendrobates
=== kentb is now known as kentb-mtg
=== dendrobates is now known as dendro-afk
=== sconklin is now known as sconklin-gone