[02:57] <bluefoxicy> why is my / ext3?
[02:57] <bluefoxicy> ~$ cat /etc/fstab |grep ext4
[02:57] <bluefoxicy> UUID=10f59859-5e33-4277-a7d2-323447f54df7 /               ext4    defaults,errors=remount-ro,relatime 0       1
[02:57] <bluefoxicy> UUID=b574cf52-432a-4c2a-8742-effe21dbf760 /home           ext4    defaults,relatime        0       2
[02:58] <bluefoxicy> ~$ cat /proc/mounts |grep ext3
[02:58] <bluefoxicy> /dev/disk/by-uuid/10f59859-5e33-4277-a7d2-323447f54df7 / ext3 rw,relatime,errors=remount-ro,data=ordered 0 0
[03:09] <TheMuso> /c/c
[07:30] <ogra> urgh, wha there a decision in debian to use /srv by default across the board ?
[07:30] <ogra> *was
[07:30] <TheMuso> ogra: For what?
[07:31] <ogra> well, tftpd-hpa defaults to it for tftp serving with the latest release
[07:31] <ogra> i was wondering if there is a general change
[07:31] <ogra> which would surprise me
[07:32] <TheMuso> ah ok
[07:32] <liw> that sounds like an excellent question for #debian-devel :)
[07:32] <ogra> gah, bug 84615
[07:34] <pitti> Good morning
[07:34] <ogra> the evil thing in tftpd-hpa is that they changed *both* defaults, it runs standalone now *and* not from inetd anymore ...
[07:35] <ogra> given that it doesnt carry a config file but was configured in inetd.conf thats pretty bad
[07:40] <StevenK> ogra: /srv == win
[07:40] <ogra> no
[07:41] <ogra> StevenK, so apache should use /srv/www now ?
[07:41] <liw> I prefer /srv/http, but I also think it's a local admin decision; http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
[07:42] <StevenK> ogra: Well, I actually configure Apache to pull from directories underneath /srv
[07:42]  * ogra wonders what all the admins out there would say if it suddenly did, breaking all the setups that use the default config :P
[07:42] <StevenK> But yes, what liw said. It's a local admin decision.
[07:42] <ogra> right
[07:42] <ogra> and the directory should stay clear from defults
[07:42] <ogra> *defaults
[07:43] <StevenK> ogra: I'm unsure about if the default should be somewhere under /var, or what it currently has, under /srv
[07:44] <ogra> var is variable system data, isnt it ?
[07:45] <liw> "However /srv should always exist on FHS compliant systems and should be used as the default location for such data."
[07:45] <StevenK> ogra: And /srv is data that is served by the system, so ...
[07:45] <ogra> srv is a nice concept to give admins more freedom, but essentially i think system default setups shuld stay out of it
[07:45] <liw> the FHS is clear that /srv should be the default location
[07:46] <ogra> "The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done."
[07:46]  * ogra doesnt find that clear or even thought to the end
[07:47] <liw> I'm sure the FHS committee would accept reasonable arguments for change
[07:47] <ogra> an you think i would move people to a consensus ?
[07:47] <liw> certainly
[07:47] <ogra> looks to me like it was argued on before and there simply was no agreement
[07:48] <liw> if nothing else, you could push them all to dislike you and so have a consensus to vote against you? :)
[07:48] <StevenK> Hah
[07:48] <ogra> which reads to me like "no real *standard* could be defined"
[07:49] <liw> I haven't studied the history /srv, but I assume this happened the way fhs and similar standards are developed
[07:49] <ogra> well, to me a standard means there is "agreement how we all do it" ...
[07:49] <liw> i.e., people felt that /var was a bad location for things like http web roots (read: not easily shareable between hosts) and proposed a change
[07:50] <liw> so as a first step, /srv was invented and then the committee will wait a few years to see if it gets popular and if so, how it gets used
[07:50] <liw> before they make further changes
[07:50] <ogra> right, i dont say thats bad ... as long as there is a clear definition how /srv has to look like
[07:50] <ogra> else you end up with per distro chaos ... that defeats the purpose of easy portability
[07:51] <ogra> and given that there is no such definition yet it should not be used for default setups imho
[07:52] <liw> *shrug* the standard won't (and shouldn't) encode a structure before it has been tried in practice
[07:52] <ogra> heh, catch 22 ?
[07:53] <liw> not really, as long as people don't insist the FHS tell them in detail the location of every file and distros have a little bit of courage to try new things occasionally :)
[07:53] <ogra> i dont want to be told about files in detail ... but a rough definition about the substructure would be helpful
[07:54] <liw> I'm sure you'll find it in a future version of the fhs
[07:54] <liw> meanwhile, you can help decide what is the best substructure :)
[07:55] <ogra> well, the by protocol approach is fine with me ...
[07:55] <ogra> in my specific case i'm just running into a prob with tftpd-hpa which changes two setups at the same time
[07:56] <ogra> it ignored the former configuration (inetd.conf) and at the same time switches its default path
[07:56] <liw> that'd probably be a bug in that package
[07:56] <ogra> *ignores
[08:31] <Hobbsee> X really doesn't handle two monitors of different aspect ratios well, does it?
[08:32] <Hobbsee> gdm keeps throwing itself against the wall when you try
[08:32] <ogra> it does fo my monitor
[08:32] <lifeless> Hobbsee: that may have more to do with gdm
[08:32] <liw> X might. gdm perhaps doesn't.
[08:32] <Hobbsee> hm, could well be gdm
[08:32] <pitti> Hobbsee: is it similar to https://bugs.freedesktop.org/show_bug.cgi?id=22580 ?
[08:33] <ogra> (1900x1200 plus 1280x800 if i attach it to my laptop)
[08:33] <Hobbsee> (and 1024x768 looks painful on a 21.5 inch 16:9 monitor, incidently)
[08:33] <pitti> no, it's recent X trying to be too clever
[08:34] <Hobbsee> pitti: ah yes, i see that too
[08:34] <pitti> I have an internal LVDS (docked, closed, ignored) and an external TFT
[08:34] <pitti> and X comes up at 1024x768 on both now
[08:34] <Hobbsee> (when mirroring the display)
[08:34] <Hobbsee> yep
[08:35] <Hobbsee> turning off mirror mode lets you select the higher resolutions, though
[08:35] <pitti> sure, in my X session I can do the right thign (disable LVDS, use native resolution on DVI)
[08:35] <Hobbsee> just when you actually log out and back in to use them, gdm blows up
[08:35] <pitti> doesn't blow up here, but keeps switching modes
[08:36]  * ogra can use his 24" monitor just fine with the laptop, but X dies horribly if i attach my 42" TV
[08:39] <StevenK> Argh, now the blocking on ocaml transition is causing headaches for the rpm transition
[08:40] <ogra> Riddell, pitti, bug 190905says dnsmasq is in main, i dont see it there ?
[08:41] <pitti>    dnsmasq |     2.49-1 |        karmic | source
[08:41] <ogra> oh, ok
[08:41] <StevenK> ogra: The source is, the binary isn;t
[08:41] <pitti> ogra: dnsmasq-base is in main, the full dnsmasq binary isn't
[08:41] <StevenK> s/;/'/
[08:41] <pitti> nothing needs it
[08:44] <StevenK> Oh, bah, it's worse.
[08:45] <StevenK> Anything requiring dose2 can't be built since libdose2-ocaml can't be installed since librpm4.4 and librpm0 conflict, and I can't sync dose2 since it's blacklisted since the Debian ocaml maintainers don't want karmic transitioning.
[09:13] <directhex> Hobbsee, depends on how your graphics driver decides to present them
[09:13] <directhex> Hobbsee, at work i have a 1600x1200 secondary and 1920x1200 primary. gdm displays only on the primary
[09:14] <StevenK> pitti: So, would it be a bad thing to merge ekiga from Debian? (They have 3.2.5, and we have 3.2.0)
[09:24] <Hobbsee> directhex: right.  It dosent' seem to be having a problem displaying only on one monitor - just both resolutions are wrong
[09:24] <directhex> i don't have that issue
[09:25] <directhex> vertical res matches though, if that makes a diff
[09:33] <\sh> moins
[09:34] <\sh> evand: WTF is a "Ubiquity Contributor Agreement"? (And I think you mean Ubiquity as in live cd installer)
[09:40] <\sh> and why should someone sign this when the source is GPL2 and all contributions to this source are falling under that license, too?
[09:41]  * ogra points \sh to http://vdict.com/ubiquity,7,0,0.html
[09:42] <ogra> "omnipresent" :)
[09:43] <\sh> ogra: and what does it have to do with a) licensing a software and b) signing another document which grants the same rights? (minus this very strange patent paragraph)
[09:43] <ogra> it means that you agree this license applies *across the board*
[09:43] <ogra> i would say
[09:44] <ogra> (some native speaker may correct me)
[09:45] <ogra> s/license/agreement/
[09:46] <evand> \sh: yes, ubiquity the live CD installer.  It's a requirement per http://www.canonical.com/contributors .  My understanding of the reasons we require people to sign it are the two I outlined in that email.  I can put you in touch with a lawyer who can better elaborate on the details if you don't find my explanation sufficient.
[09:47] <ogra> oh
[09:47]  * ogra didnt know we had that 
[09:47] <ogra> (for ubiquity)
[09:48] <\sh> evand: so what you are saying is: if someone is using the software, which I contributed to, not according to the GPL2 license, you will hunt them down like gplviolations?
[09:48] <\sh> s/you/Canonical/?
[09:49] <kamaln> Hi, can i discuss Ubuntu package development here?
[09:49] <evand> \sh: I think that's a question better put to our legal counsel.  I have a very limited understanding of the law and the plans of our legal department.
[09:50] <\sh> evand: please...would you forward this to your legal department? I really don't understand the usecase behind such an agreement :)
[09:52] <evand> \sh: If you could ask specific questions to Amanda (who's email address I'm about to private message you), I'd greatly appreciate it.  If I just send her an email myself saying your confused on why this is necessary, that leaves having to formulate an unnecessarily broad answer.
[09:52] <evand> that leaves her*
[09:52] <maxb> kamaln: You can, but be aware that this channel is primarily concerned with packages in the 'main' component - For 'universe' packages, including new packages, #ubuntu-motu is more appropriate
[09:52] <\sh> evand: will do
[09:53] <evand> \sh: Thanks, and apologies for the confusion.
[09:53] <evand> Legal issues are not my strong suit.
[09:53] <\sh> evand: no problem...:)
[09:54] <kamaln> maxb: what is meant my 'main' component..? Infact, I am developing a new package..so is it better to approach #ubuntu-motu
[09:54] <pitti> StevenK: not at all
[09:55] <maxb> kamaln: All new packages start out in 'universe', so yes, #ubuntu-motu is the right place
[09:56] <evand> kamaln: https://wiki.ubuntu.com/UbuntuDevelopers should help to explain the difference between motu and core-dev (this channel).
[09:57] <kamaln> evand: thanks..:-)
[10:01] <cjwatson> \sh: the FSF does exactly the same thing for contributions to GNU projects, FWIW
[10:06] <directhex> copyright assignment?
[10:09] <azeem> cjwatson: I believe the FSF explicitely says it will only license the assigned copyright under FLOSS licenses/GPL
[10:09] <cjwatson> well, yes, that's true. I meant copyright assignment in general
[10:10] <cjwatson> directhex: only for a few projects that we started, not for the whole of Ubuntu or anything, don't worry
[10:10] <azeem> (just mentioning, because you said "exactly the same thing"
[10:10] <azeem> )
[10:10] <\sh> cjwatson: so, I could give my copyrights to another entity (which is the FSF), why should I do that?
[10:11] <directhex> i believe a common alternative is to allow non-assignment as long as contributions are MIT/X11
[10:11] <cjwatson> the usual reason for copyright assignment is that it means that in case of violation it's actually possible to pursue violators; in many jurisdictions one cannot bring a case unless one has standing
[10:11] <directhex> \sh, essentially because it makes it easier for them to fight legal battles, as they cal claim to be the infringed party in disputes.
[10:12] <directhex> \sh, or you can have severe problems when you DON'T, e.g. parts of scummvm are unrelicensable as their author died
[10:12] <directhex> \sh, as it happens, your reasoning is why the Go-OO patchset for OpenOffice.org exists
[10:14] <\sh> directhex: well, for that I have a last will where I can state what will happen to my copyrights, software or IP...
[10:15] <directhex> can, or do?
[10:16] <cjwatson> mm. I've actually had that problem myself in the past, I didn't really want to contact a developer's widow and say "excuse me, exactly what pedantic things can I do with your late husband's code"
[10:16] <\sh> directhex: I have ... I just need to add things every year I survived
[10:16] <cjwatson> seems ... tasteless somehow
[10:16] <directhex> cjwatson, very. but what's the alternative?
[10:17] <\sh> cjwatson: actually it's that situation companies do with people taking over someones property
[10:17] <directhex> cjwatson, the scummvm case is significant as it prevented proper resolution of a gpl violation problem
[10:18] <cjwatson> fortunately in the case at hand it basically worked out that I didn't need to worry about it for various reasons
[10:18] <directhex> afaik apache requires assignment too
[10:18] <directhex> a housemate received legal paperwork from the foundation when we were undergrads
[10:18] <\sh> actually most of the software which are in our archives and we contributed some self-made patches needs such an assignment then
[10:19] <cjwatson> depends where the patches go, but you'll certainly find that many upstream contributions require assignments, yes
[10:19]  * cjwatson is in the process of getting assignments sorted out for findutils, parted, grub2, and something else I've forgotten
[10:20] <directhex> i think there's some generally held legal minimum patchiness level required to say "this patch counts as a proper contribution and needs proper licensing"
[10:20] <directhex> i'm pretty sure i'm not in MythTV's AUTHORS file
[10:20] <cjwatson> it's subjective, I have seen such things stated but never a clear legal opinion on it
[10:21] <directhex> sounds like something waiting for case law
[10:21] <james_w> I've seen people say "this isn't a patch, but if you go to foo.c and change the comparison on line 95 this bug will go away. Can I avoid signing a copyright assignment please?"
[10:23] <directhex> technically that statement is true
[10:24] <liw> the threshold for what is copyrightable (and what is too trivial to be copyrightable) varies betwen jurisdictions, and sometimes within them too
[10:24] <liw> on the whole, copyright law is screwed up all over the world
[10:25] <\sh> well, if those assignments has a paragraph like: "A company/organization which violates the authors/contributors license will be sued by Us [where "Us" is someone else company/organization] to enforce the given license of the author/contributor. Any monetary solution to this charge will be shared among the Law Company, the author of the software and all contributors" this would make sense to me (not that I want any blood money)
[10:26] <\sh> btw..I just had a karmic problem unlocking the screensaver...it just waited there forever
[10:27] <cjwatson> me too last night, I was wondering if it was due to not having restarted after an upgrade
[10:27] <cjwatson> I had to kill gnome-screensaver
[10:28] <\sh> it was after todays update...and there was no restart required according to non-existent "Restart required notifier" :)
[10:33] <dpm> StevenK: regarding fbreader, I'd like to reply to upstream. Seeing that it will not be promoted to main, I'm guessing that the i18n work will not be done?
[11:20] <\sh> hmm...what does "You have N broken packages on your system. Please use the "broken" filter to detect them"? (Dialogbox of update-manager, without any hint where to set the "broken" filter)
[11:21] <azeem> maybe that's a message from synaptic
[11:22] <\sh> azeem: as it follows the "Install updates" of update-manager...I can't tell...but this message is very strange and will confuse people, at least it confuses me
[11:23] <\sh> and now, update-manager won't close after updating all selected packages..hmmm
[11:24] <\sh> now it's gone...after 1:30 mins
[11:40] <Laney> does sync blacklist block even manual syncs? I thought it was just for autosync
[11:41] <cjwatson> only autosyncs
[11:41] <cjwatson> err, wait, maybe not
[11:41] <Laney> or is autosync just a loop over the manual procedure?
[11:41] <cjwatson> no, manual syncs too actually. But anyone who can do a manual sync can edit the blacklist ...
[11:41] <Laney> sure
[11:42] <directhex> Laney, if you were me, would you 0ubuntu1 xsp and mono-tools?
[11:42] <Laney> getting emails from bug 387943
[11:42] <cjwatson> basically just a loop with a bit of extra reporting
[11:42] <Laney> directhex: what's the delay?
[11:42] <directhex> Laney, binary NEW
[11:43] <Laney> I'd wait
[11:43] <Laney> binary NEW isn't too slow, is it?
[11:43] <cjwatson> but in that case the blacklist is there for a reason and removing it does seem to merit some discussion
[11:43] <james_w> binary NEW in Debian?
[11:43] <directhex> james_w, aye
[11:43] <james_w> I didn't think they had one?
[11:43] <cjwatson> it's probably just that ftpmasters are at debconf :)
[11:43] <cjwatson> they do
[11:43] <directhex> james_w, binary NEW in ubuntu requires only beatings and/or beer
[11:44] <directhex> james_w, the ftp-master page doesn't distinguish - the ftpmasters actually do though
[11:44] <james_w> and that would indicate that the source was published, and so we could sync. Or do I misunderstand the process?
[11:44] <directhex> james_w, you may not access files uploaded to NEW
[11:44] <cjwatson> if the new binary packages went together with a source upload, then the whole upload stays in NEW
[11:44] <james_w> yeah
[11:44] <directhex> james_w, as some kind of defence against undistributable source. or somesuch
[11:45] <james_w> an "new-binary NEW"
[11:45] <cjwatson> the queue never splits up .changes
[11:45] <james_w> "ah", I mean
[11:45] <james_w> I get it now
[11:46] <directhex> short version: long wait time
[12:06] <directhex> if openprinting-ppds contains an obsolete ppd-drop from a printer vendor, what's the best way to get it updated?
[12:08] <mvo_> \sh: uh, that is indeed confusing - could you mail me your /var/log/apt/term.log please?
[12:13]  * directhex dances in circles, goes to file a bug, notices it just goes to tkamppeter anyway
[12:39] <tkamppeter> directhex, which PPDs are obsolete?
[12:40] <directhex> tkamppeter, kyocera. i can get a precise list of models if you give me a few mins
[12:41] <tkamppeter> directhex, OK.
[12:41] <tkamppeter> directhex: Unfortunately, I did not get Kyocera PPDs for years, so there are probably missing a lot.
[12:42] <directhex> how odd, there are more PPDs on here than in Kyocera's download
[12:43] <tkamppeter> directhex, can you tell me where I can find Kyocera's download?
[12:43] <tkamppeter> It can be that Kyocera does not have arbitrary old models in their download and the oldest models on OpenPrinting are perhaps older.
[12:44] <directhex> +Kyocera_FS-1118MFP_en.ppd
[12:45] <directhex> +Kyocera_FS-C5015N_en.ppd
[12:45] <directhex> +Kyocera_FS-C5025N_en.ppd
[12:45] <directhex> +Kyocera_FS-C8100DN_en.PPD
[12:45] <directhex> +Kyocera_KM-1820_en.ppd
[12:45] <directhex> +Kyocera_KM-C2520_en.PPD
[12:45] <directhex> +Kyocera_KM-C3225_en.PPD
[12:45] <directhex> +Kyocera_KM-C3232_en.PPD
[12:45] <directhex> those are the additions
[12:45] <ScottK> cjwatson: I did verify the debian-cd change you merged for me fixed the background problem on the Kubuntu Netbook ISO.  Thanks agian.
[12:46] <tkamppeter> directhex: are you listing the models which are missing in Kyocera's download or the ones which are missing on OpenPrinting?
[12:46] <directhex> tkamppeter, the latter
[12:47] <tkamppeter> So these are the newest models which need to get added?
[12:47] <tkamppeter> directhex: And where can I download the PPDs?
[12:47] <directhex> seems there are also some minor changes to old ones
[12:47] <cjwatson> ScottK: oh good
[12:47] <directhex> tkamppeter, bottom of http://www.kyocerasupport.co.uk/index/download_center.false.driver.FS1118MFP._.EN.html has a link
[12:48] <StevenK> cjwatson: Well, I'd like to remove dose2 from the blacklist, just so I can get this librpm4.4 mess cleaned up.
[12:49] <cjwatson> but won't it basically pull in the whole ocaml mess?
[12:49] <cjwatson> I thought that was the point of blacklisting all that stuff
[12:49] <StevenK> I'm just about to check that
[12:49] <Laney> I think we should go ahead with the transition anyway
[12:49] <cjwatson> i.e. I thought there were source changes in there that relied on the new ocaml
[12:49] <Laney> (OCaml)
[12:50] <StevenK> cjwatson: My other thought was doing -3~ubuntu1 which is -3, without the new ocaml
[12:50] <ogra> god, thses gpm popups are annoying
[12:50] <ogra> *these
[12:50] <Laney> it doesn't seem so bad, and there's a nice tool for helping with it
[12:50] <liw> ogra, hm?
[12:51] <ogra> liw, i get "your battery is fully charged" or "... discharging" as popunders since some days
[12:51] <liw> ogra, ugh
[12:51] <ogra> *huge* popunders with three buttons in a row
[12:52] <StevenK> Well, I wonder if Debian has completed the transition.
[12:52] <StevenK> It's been a month, after all.
[12:52] <StevenK> If they have, compiling a list of stuff to sync should be fairly simple.
[12:53] <tkamppeter> directhex: The PPDs are under MIT license, so I can update OpenPrinting ...
[12:54] <directhex> tkamppeter, i wouldn't have bugged you if they weren't Free :po
[12:54] <directhex> :p
[12:55] <tkamppeter> directhex, with OpenPrinting updated, Ubuntu Jaunty and higher would simply directly get them from OpenPrinting.
[12:55] <Laney> StevenK: They have, apart from one sourc epackage (see mail to u-d-d)
[12:56] <tkamppeter> directhex, about free licenses of PPDs, you can inform me about all PPDs offered for use with Linux, independent whether they are free or not, as in some cases I can contact the manufacturer.
[12:56] <StevenK> Laney: Ah, but it seems like they want to keep 3.11.0 in Karmic, and have 3.11.1 in Karmic+1
[12:56] <StevenK> Which makes me go argh
[12:57] <directhex> tkamppeter, i don't generally look at this stuff, unless an engineer appears out of nowhere to take my laserjet away & put an unsupported-in-jaunty kyocera 1118 in its place
[12:57] <Laney> well he asked if we should do the transition, and I said that I think we probably could and should
[12:58] <StevenK> I agree that we should, it makes headaches like the one I just found go away
[12:58] <tkamppeter> If the PPDs are redistributable but not free software (only vernatim redistribution) I can at least put them up on OpenPrinting, in the foomatic-db-nonfree package, and that is enough for Ubuntu auto-downloading the PPDs. If they are free, they get into foomatic-db and so also into Ubuntu.
[12:58] <Laney> StevenK: would be good if you could say as much in that thread then
[12:58] <directhex> tkamppeter, the only other printers i have access to generally are a Brother (so i get that frustrating ERROR problem on most print jobs) and a Toshiba (which works fine)
[12:59] <directhex> tkamppeter, i did get to tell a Canon salesperson they were smoking crack once, though, thanks to their laughable loonicks support
[13:01] <ogra> seb128, is ssh support in gvfs known to be broken atm ? my nautilus crashes if i try to sftp mount people.canonical.com
[13:02] <seb128> ogra, do you have ubuntuone-client-gnome installed?
[13:02] <Laney> WFM (tm)
[13:03] <seb128> ogra, ubuntuone is known to make nautilus crash at the moment so if you have it yes it's known
[13:04] <ogra> well, could i not ? its seeded :)
[13:04] <ogra> so yes, i have
[13:04] <ogra> thanks
[13:04] <seb128> ogra, you're welcome
[13:05] <seb128> ogra, nobody force you to have ubuntu-desktop installed, I don't ;-)
[13:05] <ogra> i want to eat our own dogfood ;)
[13:21] <ogra> kirkland, around ?
[13:25] <cjwatson> ogra: (ubuntuone's only a recommendation, you can remove it and still have ubuntu-desktop installed)
[13:26] <ogra> cjwatson, yeah indeed
[13:26] <ogra> given that my invite timed out anyway, i should probably do that
[13:43] <lool> ScottK: I think you tried pinging me over the WE but I forgot to go back to you
[14:04] <SteveA> I know suspend / hibernate is fragile generally... it was working find on this laptop running jaunty.  Now, with karmic, suspend and hibernate don't work.  The screen goes dark for a while when I ask it to suspend then a minute or so later I get the "enter password to close the screensaver" screen.
[14:04] <SteveA> should I file a bug?  against what package?
[14:04] <ogra> likely the kernel
[14:18] <hyperair> is anyone here familiar with gdk_window_get_frame_extents?
[14:20] <hyperair> hmm no wait, that's not the problem here.
[14:28] <hyperair> hmm for some reason my panel isn't a dock.
[14:30] <james_w> is there someone else doing NEW at the moment?
[14:33] <james_w> jdstrand: you perhaps?
[14:33] <jdstrand> james_w: I was trying to get to a few before slangasek came online, yes-- are you doing mondays now?
[14:33] <james_w> yeah, myself and slangasek split the day
[14:34] <james_w> I've no problem with you doing some though :-)
[14:34] <james_w> I'm just not sure what danger there is of collisions
[14:34] <jdstrand> james_w: I plan to do ltsp-cluster-lbagent, moovida* and qemu-kvm
[14:34] <james_w> great, thanks
[14:34] <james_w> I'll go for lunch
[14:35] <james_w> give me a shout once you're done and I'll do the rest
[14:35] <jdstrand> james_w: ok
[14:35] <james_w> thanks
[14:35] <jdstrand> np
[14:37] <Laney> does the i386 buildd call build-indep directly?
[14:39] <geser> Laney: IIRC it calls build while the other call build-arch (but better look at a build log to be sure)
[14:41] <stvo> window splitv
[14:42] <stvo> sry
[14:45] <pitti> hey stvo
[14:45] <pitti> stvo: trying weechat? :-)
[14:46] <ogra> pitti, is stvo who i think he is ?
[14:47]  * pitti engages long-distance brain reader
[14:47] <ogra> haha
[14:47] <pitti> ogra: confirmed with 89.234 probability
[14:47] <ogra> lol
[14:47] <stvo> lol
[14:47] <ogra> hi stvo, great to see you here
[14:47] <stvo> thx
[14:48] <stvo> ogra I'm testing your arm chroot
[14:48] <stvo> environment
[14:49] <ogra> nice :)
[14:49] <ogra> note that its not 100% reliable but good for poking around ... some syscalls are likely missing
[14:52] <kirkland> ogra: howdy!
[14:53] <ogra> kirkland, lool told me you migh be working on a spec that implements something like https://wiki.ubuntu.com/ARM/BuildEABIChroot
[14:53] <ogra> if thats true, is there any chance we see it in karmic ?
[14:54] <lool> ogra: No, kirkland is working on getting us qemu updates though
[14:54] <ogra> (i'm referring to the binfmt setup by default)
[14:54] <ogra> ah
[14:54] <lool> 11:49 < lool> I'm sure this can all be done when we refresh our qemu
[14:54] <lool> 11:49 < lool> I think kirkland has a spec on this
[14:55] <ogra> then i misunderstood the "all" in that sentence :)
[14:55] <kirkland> lool: ogra: hmm, i'm working on getting the new qemu-kvm project into karmic
[14:55] <kirkland> this project is the merger of the qemu and kvm code
[14:55] <lool> kirkland: Is this based on qemu 0.11?
[14:55] <kirkland> qemu plus the kvm acceleration bits
[14:56] <kirkland> lool: that's the target
[14:56] <kirkland> lool: 0.11 just hit Release Candidate
[14:56] <lool> Cool
[14:56] <ogra> cool, that at least gets us the eabi patches
[14:56] <kirkland> lool: that will make it into karmic
[14:57] <kirkland> lool: it was targeted at alpha3, but upstream slipped a little
[15:03] <jdstrand> james_w: I'm done
[15:03] <pitti> hah, fighting for sync karma? :-)
[15:04] <jdstrand> who me? nah, I just couldn't get to archive much on Friday
[15:04] <james_w> thanks jdstrand
[15:04] <jdstrand> sure :)
[15:15] <directhex> yay for james_w, one step closer to mono 2.4.2 in karmic
[15:31] <ScottK> lool: Thanks for checking back, it got taken care of already.
[15:38] <Ampelbein> hi there. whom should I poke when a NBS' dependencies is zeroed? In that case it's libgnokii3 where all dependencies on that are eliminated now.
[15:38] <Ampelbein> or is there some kind of automagic NBS removal?
[15:41] <james_w> Ampelbein: manual-automatic :-)
[15:43] <Ampelbein> james_w: so I poke you and you do it? sweet! ;-)
[15:44] <james_w> I've not done it yet
[15:44] <james_w> we'll see if I get down that far on the list today
[15:45] <Ampelbein> no worries... thank you for the info.
[15:48] <lool> kirkland: Ack I heard that during the release meeting
[15:49] <lool> kirkland: (ogra was rolling his own qemu 0.10 + patches to get some better ARM EABI support and was interested in having that in ubuntu which is why I pointed him at you)
[15:49] <lool> I'm using tip + patches
[15:50] <kirkland> lool: for tip, are you aware of https://edge.launchpad.net/~ubuntu-virt/+archive/virt-daily-upstream ?
[15:50] <ogra> well, there is more than the patches ... but if our qemu-arm could support eabi that would be a major step forward
[15:50] <ogra> i would still like to have a package i can easily install that enables binfmt
[15:51] <ogra> and disables it on package removal respectively
[15:52] <kirkland> ogra: lool: any reason why these patches aren't upstream in qemu?  we have a friendly qemu maintainer, we sponsored him to barcelona uds
[15:53] <ogra> kirkland, the patches are apparently
[15:53] <ogra> just not in our package
[15:53] <kirkland> ogra: oh, great
[15:53] <kirkland> ogra: then this will sort itself out very shortly
[15:53] <kirkland> ogra: in the mean time, see: https://edge.launchpad.net/~ubuntu-virt/+archive/virt-daily-upstream
[15:53] <kirkland> ogra: 0.11.50 is building there
[15:54] <ogra> nice
[15:54] <ogra> i'll try it out soon
[15:57] <andresmujica> do we have an ubuntu java or eclipse channel?
[15:58] <ogra> lool, kirkland, though for the chroot bits i would still need a statically build binary
[15:58] <ogra> just strikes me ...
[15:58] <lool> kirkland: I am aware of the PPA; thanks; I build tip by hand because I apply some non-mergeable patches on top of qemu
[15:58] <ogra> *built
[15:59] <ogra> kirkland, do you think it would be possible to roll a qemu-arm-static into our package ?
[16:00] <kirkland> lool: gotcha, good to know
[16:00] <kirkland> ogra: hrm, i don't see why not ...  do you have a diff that does this?
[16:01] <kirkland> ogra: curious, just wondering... why do you need a static build of that binary?
[16:01] <ogra> no, my package is totally badly built with its own copy of the qemu source and the patch inline
[16:01] <lool> ScottK: Cool, so these perl libs should soon be installable?
[16:02] <ogra> kirkland, what i do is: apply the eabi patches, build it statically, enable the interpreter in binfmt-support to match the magic of any armel binaries ... then i roll an armel chroot ... to exec armel binaries *inside* that chroot i need the x86 qemu ...
[16:03] <ogra> kirkland, which indeed wouldnt find its libs *in* the chroot
[16:03] <kirkland> ogra: right
[16:03] <ogra> with the static version i can just chroot into my bootstrapped root and move on
[16:04] <ScottK> lool: Right.  Thanks for the reminder (ugh).  No, it was another issue.
[16:04] <ogra> its extremely convenient
[16:04]  * ScottK looks into it.
[16:04] <lool> Eh :)
[16:04] <kirkland> ogra: agreed
[16:05] <lool> So it's libcompress-raw-zlib-perl which I can't upgrade due to the dep of libio-compress-zlib-perl
[16:07] <ogra> kirkland, in my package i essentially just do "./configure --prefix=/usr --target-list=arm-linux-user --static" in debian/rules, but i guess thats not proper enough for the actual package in the archive
[16:08] <kirkland> ogra: right, let me think on this some
[16:08] <kirkland> ogra: i'll talk to upstream too
[16:09] <ogra> thanks :)
[16:09] <kirkland> ogra: i might be able to add a binary package to the source package
[16:09] <kirkland> ogra: qemu-arm-static or something
[16:09] <kirkland> ogra: or qemu-static
[16:09] <kirkland> ogra: and just publish that one to universe?
[16:09] <ogra> that would be cool since it could also carry the proper postinst and prerm bits for binfmt
[16:09] <ogra> universe is totally fine
[16:10] <kirkland> ogra: would you open a wishlist bug against qemu to capture this?
[16:10] <ogra> yeah
[16:10] <kirkland> ogra: i'm tracking down a nasty ecryptfs right now
[16:10] <kirkland> ogra: so i guarantee i'm going to forget this otherwise :-D
[16:10] <ogra> no hurry
[16:20] <ogra> kirkland, bug 401782 is yours
[16:21] <kirkland> ogra: thank you sir!
[16:21] <ogra> no, thank you ! :)
[16:22] <kirkland> ogra: thank me when I finish the work :-)
[16:23] <ogra> heh
[16:23] <ogra> well, until then my hackish ppa package will do :)
[16:39] <ScottK> lool: They've combined several perl modules into one.  This is non-trivial.
[17:25] <RainCT> Keybuk: Hey. How does this look? http://revu.ubuntuwire.com/~rainct/mom.html
[17:26] <Keybuk> cute
[17:28] <cjwatson> RainCT: I'm sure it's not the point, but your data is perplexing - you seem to be using the primary UID on the signing key for "Last Uploader", rather than, say, Changed-By if it matches one of the UIDs on the key ...
[17:30] <RainCT> cjwatson: Seems like it's just running gpg and looking at the "Good signature from X" line. But hey, that's not my code! :)
[17:30] <Keybuk> cjwatson: patches welcome
[17:31] <Keybuk> cjwatson: in fact, I think you may have _written_ this patch in the first place ;-)
[17:31] <cjwatson> Keybuk: oh, I didn't think current MoM acted this way ...
[17:32] <cjwatson> I don't remember doing so? but that doesn't mean a whole lot
[17:32] <RainCT> Keybuk: The (new design) code is up on lp:~rainct/merge-o-matic/redesign for your merging pleasure :)
[17:33] <Keybuk> Jo Shields <directhex@ubuntu.com>
[17:33] <Keybuk> Uploader: Colin Watson <cjwatson@flatline.org.uk>
[17:33] <Keybuk> (e.g. from current MoM output)
[17:34] <cjwatson> definitely wasn't me who wrote that patch, I don't recognise that code at all
[17:35] <Keybuk> RainCT: though that's a good point
[17:35] <Keybuk> RainCT: your code drops the distinction
[17:35] <cjwatson> anyway, current MoM doesn't act this way because for the upload in question changer == uploader
[17:35] <Keybuk> current MoM shows both the Changed-By *and* Uploader when different
[17:36] <Keybuk> yours only shows the Uploader
[17:36] <Keybuk> (who is generally a sponsor, not the person who made the change)
[17:36] <cjwatson> right
[17:36] <Keybuk> RainCT: looks like you haven't touched manual-status.py yet?  Would be good to have that in the same form
[17:36] <RainCT> Keybuk: Oops, right. My test with a single package isn't that helpful :)
[17:37] <Keybuk> RainCT: other than that it looks good
[17:37] <Keybuk> so if you can fix those two things, I'll be more than happy
[17:38] <RainCT> Keybuk: uhm, hat is that manual-status.py thing?
[17:44] <Keybuk> RainCT: produces https://merges.ubuntu.com/{main,universe,restricted,multiverse}-manual.html
[17:48] <andresmu1ica> i've lost X output completely with latest gdm update in karmic...  :/
[17:58] <pitti> andresmu1ica: "x output"?
[17:59] <andresmujica> pitti: black screen with everything working.. give a minute i've downgraded to gdm 2.26 and recovered X output.. upgrading again to confirm or deny it...
[18:03] <RainCT> Keybuk: can you please check if the uploader is displayed now?
[18:17] <andresmujica> pitti: not related to gdm, it seems a bug with kernel 2.6.31-1-generic it gives no X output .. but as we already passed it there's no problem at all.
[18:46] <kirkland> karmic sound issues?  i'm getting momentary pauses during mp3 playback;  tried numerous different players and sources
[18:47] <kirkland> dtchen: ^
[19:01] <ogra> kirkland, i had mine play at double speed on the weekend ... reboot fixed it
[19:02] <kirkland> ogra: heh
[19:02] <kirkland> ogra: i've rebooted a few times recenty
[19:02] <ogra> upgraded too ?
[19:03] <ogra> i first did an upgrade (which didnt ask for reboot) ...
[19:03] <ogra> and after the reboot it was actually working fine ...
[19:03] <ogra> i had the issue in all players, even tried mplayer and xine
[19:08] <RainCT> Keybuk: Should work now, but I can't test manual-status.py myself
[19:17] <slangasek> james_w: fwiw, it's perfectly fine for archive admins to sync packages directly instead of filing sync requests. :)
[19:18] <james_w> :-)
[19:18] <infinity> (Unless you really want a review or something)
[19:18] <infinity> (But then I'd take that OOB and just get it done quickly)
[19:50] <directhex> is ubuntu-meta maintained someplace in bzr?
[20:22] <slangasek> directhex: no, since most of the contents are autogenerated there hasn't been much need
[20:52] <rtg_> slangasek, do you have a moment to review my proposed addition of rfkill to wireless-tools ? http://kernel.ubuntu.com/~rtg/wireless-tools.diff
[20:58] <slangasek> rtg_: <squint> the diff looks fine, but why in the world is this now being done via a control device instead of via /sys?
[20:59] <slangasek> that really seems like a step backwards
[21:00] <rtg_> slangasek, it can be done both ways, but I guess /dev/rfkill is the preferred method for setting/retrieving state for all wireless devices.
[21:00] <slangasek> no, it can't be done both ways :)
[21:00] <slangasek> not in 2.6.31 - someone broke the /sys interface
[21:00] <rtg_> I thought it just moved
[21:01] <slangasek> well, they broke two things - 1) there's no longer a link to the rfkill interface from the /sys/class/net tree, 2) trying to toggle any rfkill interfaces through sys fails with "Operation not permitted"
[21:03] <nxvl> james_w: is there something in bazaar like svn debcommit?
[21:03] <rtg_> slangasek, for the acpi-support package the rfkill application should be sufficient for controlling rfkill state. do you want me to pursue what is wrong with the sysfs interface?
[21:04] <james_w> nxvl: what does that do?
[21:04] <rtg_> instead
[21:04] <nxvl> james_w: commits the changes and generates the comment from the changelog
[21:04] <james_w> debcommit doesn't do what you want?
[21:04]  * nxvl tries
[21:05] <nxvl> james_w: yes it does
[21:05]  * nxvl HUGS james_w 
[21:05] <slangasek> rtg_: well, I'm getting a little sick of the interface moving every single release, and the acpi-support compatibility code becoming increasingly baroque :/
[21:06] <slangasek> rtg_: I thought the previous /sys interface was a very sensible one, and it seems like a bug to me that it's changed again
[21:07] <rtg_> slangasek, as well that may be, there is little I can do about it.
[21:07] <slangasek> rtg_: who's working on this stuff upstream?  maybe I can rant at them directly :)
[21:07] <slangasek> (anyway, surely it /is/ a bug that you can't change the state via /sys at all anymore?)
[21:08] <rtg_> slangasek, Johannes Burg is the guy that rewrote rfkill. I guess he'd be the best place to start. Perhaps on the linux-wireless@vger.kernel.org list.
[21:08] <rtg_> s/Burg/Berg/
[21:08] <slangasek> rewrote - bah :)
[21:09] <slangasek> ok, I'll see what comes of prodding, thanks
[21:09] <rtg_> slangasek, well, the original version did had some serious problems from what I understand.
[21:19] <bannaN> I could be interested in contributing in the development of ubuntu, where do i start? What kind of skill-level is required?
[21:19] <azeem> bannaN: ask in #ubuntu-motu
[21:20] <cjwatson> bannaN: http://wiki.ubuntu.com/ContributeToUbuntu
[21:23] <bannaN> Kindy dont know where to start, who to ask, and how to join, and what kind of work-tasks is available for a person with my knowledge
[21:29] <cjwatson> bannaN: right, it's complicated (and we don't know either, because it depends so much on your interests and experience), which is why I gave you a page full of links that you can go and read :-)
[21:32] <bannaN> cjwatson: hehe, yeah, what i had in mind was maybe bugfixing, testing or something like that, dont know whats possible in the begining, and how tasks are asigned
[21:36] <cjwatson> bannaN: with some exceptions (for instance, people employed to work on Ubuntu often have things assigned to them), people generally take things for themselves rather than waiting to be asked
[21:36] <cjwatson> the process for fixing bugs is to find some bugs you think are interesting and send patches! :-) And http://wiki.ubuntu.com/SponsorshipProcess if you want to get those patches reviewed in a timely fashion
[22:01] <BUGabundo> hey dear devs
[22:01] <BUGabundo> pitti: were you who broke gtk on karmic with that patch for gfvs?
[22:04] <seb128_> BUGabundo, gtk and gvfs are really different things
[22:04] <BUGabundo> yeah I know
[22:04] <BUGabundo> just gluing some pieces
[22:04] <BUGabundo> haven't got my listchanges to work yet, after format
[22:04] <seb128_> BUGabundo, not really gluing no, gvfs has no user inferface and don't use gtk
[22:04] <BUGabundo> so knolage may be incomplete :)
[22:04] <seb128_> BUGabundo, and gtk doesn't use gvfs either
[22:05] <seb128_> BUGabundo, rather than trying to guess you should better describe your issue
[22:05] <BUGabundo> seb128_: not a single icon anywhere on my system
[22:05] <BUGabundo> err
[22:05] <BUGabundo> not _my_. any karmic, updated
[22:06] <seb128_> ?
[22:06] <BUGabundo> yofel: what was the package you mentioned?
[22:06] <yofel> seb128_: .xsession-errors tells us that it can't recognize the picture format
[22:06] <yofel> of the icon theme
[22:06] <seb128_> BUGabundo, "any", works for me
[22:06] <BUGabundo> seb128_: yes, really. no app icons, not icons on pidgin, on firefox, nothing
[22:06] <BUGabundo> just boxes with red cross
[22:06] <yofel> seb128_: like for example: ** (gnome-terminal:13296): CRITICAL **: failed to load icon 'lpi-translate': Format der Bilddatei unbekannt
[22:07] <seb128_> having english errors would be a good start
[22:07] <yofel> it's something along of: unknown picture format
[22:07] <BUGabundo> let me pastebin mine
[22:08] <BUGabundo> its in english
[22:08] <BUGabundo> $ pastebinit .xsession-errors
[22:08] <BUGabundo> http://paste.ubuntu.com/223031/
[22:09] <seb128_> BUGabundo, did you open a bug using apport?
[22:09] <BUGabundo> not yet
[22:09] <BUGabundo> I just came online
[22:10] <BUGabundo> and yofel confimed it, so I though I would ask around
[22:10] <seb128_> BUGabundo, what architecture do you use?
[22:10] <BUGabundo> before putting it on LP with no package
[22:10] <BUGabundo> x64
[22:10] <seb128_> yofel, you?
[22:11] <yofel> seb128_: yes, updated my system a few minutes before BUGabundo came and have the same issue
[22:11] <BUGabundo> hey kenvandine
[22:11] <seb128_> yofel, the question was "what arch do you use"?
[22:11] <yofel> oh, sry - amd64
[22:11] <BUGabundo> ahah
[22:12] <seb128_> k, could be amd64 specific
[22:12] <giles> yofel: I tuned in
[22:12] <BUGabundo> seb128_: package so I can file it ?
[22:12] <BUGabundo> humm notify OSD is gone too LOL
[22:12] <seb128_> BUGabundo, gtk+2.0
[22:12] <yofel> giles: what's your cpu-arch? x86 or x64?
[22:12] <BUGabundo> at least Volume one
[22:13] <BUGabundo> seb128_: Package gtk+2.0 does not exist
[22:13] <Ampelbein> BUGabundo: ? https://bugs.edge.launchpad.net/ubuntu/+source/gtk+2.0
[22:13] <seb128_> libgtk2.0-0 if you want a binary package rather
[22:13] <giles> yofel: x64
[22:13] <BUGabundo> Ampelbein: tell that to my apport :)
[22:13] <seb128_> the issue seems amd64 specific
[22:13] <seb128_> I've no amd64 config to work on that though
[22:14] <BUGabundo> uploading now
[22:15] <BUGabundo> The collected information can be sent to the developers to improve the
[22:15] <BUGabundo> application. This might take a few minutes.
[22:15] <BUGabundo> ............................................................................................................................................................................
[22:15] <BUGabundo> never seen apport take soooooooo long
[22:16] <BUGabundo> I think it jammed :(
[22:19] <BUGabundo> back
[22:19] <BUGabundo> sorry, lost wifi
[22:20] <seb128_> BUGabundo, do you have a  /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so ?
[22:21] <BUGabundo> $ ls  /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so
[22:21] <BUGabundo> -rw-r--r-- 1 root root 23K 2009-07-20 18:12 /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so
[22:22] <seb128_> BUGabundo, ok, the amd64 build lacks the png loader for some reason
[22:22] <BUGabundo> https://bugs.edge.launchpad.net/ubuntu/+source/gtk+2.0/+bug/401938
[22:22] <BUGabundo> yofel: giles: feel free to sub
[22:23] <yofel> seb128_: the svg one is missing as well i think
[22:24] <BUGabundo> ohhh the bot is lagged 1min
[22:27] <BUGabundo> can someone set that to confirm, please?
[22:27] <seb128_> BUGabundo, what difference does it make?
[22:27] <yofel> BUGabundo: seb128_ did that already?
[22:27] <BUGabundo> ok
[22:27] <seb128_> BUGabundo, I did for the record, still need debugging from somebody on amd64
[22:28] <BUGabundo> seb128_: tells us what you ned
[22:28] <BUGabundo> *need
[22:28] <BUGabundo> I'm here to help :)
[22:28] <BUGabundo> ahahah
[22:28] <BUGabundo> and he left :\\\
[22:29] <cody-somerville> pitti, Whats holding up the gdm changes we agreed on?
[22:30] <cody-somerville> slangasek, ^^
[22:31] <cody-somerville> slangasek, We're quickly running out of time and the Xubuntu CDs are still oversized pending the changes to gdm
[22:31] <slangasek> cody-somerville: I'm not on the desktop team, I wouldn't know
[22:32] <slangasek> cody-somerville: is there a bug report open for this?
[22:32] <cody-somerville> slangasek, There was but it seems to be closed, trying to find it
[22:33]  * BUGabundo slaps seb128 connection
[22:33] <seb128> BUGabundo, what is required is somebody having access to an amd64 box and a clue about autotools and libtool to debug
[22:34] <BUGabundo> I have the 1st
[22:34] <BUGabundo> not the 2nd
[22:34] <BUGabundo> let me fetch someone from +1
[22:34] <giles> seb128: need debug info from somebody on amd64?
[22:34] <seb128> giles, not really, rather need somebody able to debug the issue
[22:35] <giles> which issue?
[22:35] <seb128> giles, ie giving me informations will not likely lead somewhere, I've no real clue about the issue seems to be something due to libtool
[22:35] <seb128> giles, cf bug #401938
[22:35] <seb128> "libtool: relink: gcc -shared .libs/io-png.o -lpng12 -L/build/buildd/gtk+2.0-2.17.5/debian/install/shared/usr/lib -L/usr/lib -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lm -Wl,-Bsymbolic-functions -Wl,-soname -Wl,libpixbufloader-png.so -o .libs/libpixbufloader-png.so
[22:35] <seb128> /usr/bin/ld: cannot find -lgdk_pixbuf-2.0
[22:35] <seb128> collect2: ld returned 1 exit status"
[22:35] <cody-somerville> slangasek, LP #396321, LP#400901, LP #400094
[22:36] <cody-somerville> slangasek, I'm going to create a new master bug report to include all the details.
[22:37] <slangasek> cody-somerville: isn't bug #400901 that?
[22:37] <seb128> anybody on karmic amd64 who could give a build try to gtk+2.0?
[22:38] <seb128> to see if the build issue mentioned before and breaking png loading is a random glitch or a real error?
[22:38] <cody-somerville> slangasek, I'm going to modify 400901
[22:38] <giles> seb128: i could
[22:38] <seb128> giles, thanks
[22:39] <yofel> seb128: I'm building it too
[22:40] <seb128> thanks
[22:40]  * BUGabundo is looking :)
[22:46] <cody-somerville> slangasek, updated and milestoned
[22:50] <pitti> cody-somerville: ah, did you update your branch and merge request? didn't get a mail about it
[22:50] <seb128> pitti, hey
[22:50] <pitti> hey all
[22:51] <seb128> pitti, I expect bug #401938 to quickly become an issue
[22:51] <BUGabundo> hey pitti
[22:51]  * BUGabundo is always finding HIGH bugs for seb128 :)
[22:51] <seb128> pitti, just to let you know if you look at milestoned issues this week
[22:51] <pitti> seb128: oh, thanks; indeed, I'm the alpha-3 RM this week, so I have to care :)
[22:51] <cody-somerville> pitti, Sorry, I thought you were just going to make the changes. I'd be happy to update my branch for you.
[22:51] <seb128> BUGabundo, you seem to enjoy when users are in trouble
[22:52] <pitti> cody-somerville: I don't really know the appropriate xubuntu alternatives, and you said it also needs some patches for not hardcoding metacity, etc.?
[22:52] <cody-somerville> pitti, Sounds good to me. I'll do that this evening.
[22:52] <pitti> seb128: hm, I'm on amd64, and my icons are just fine
[22:52] <pitti> didn't update to new gtk yet, though
[22:53] <pitti> the most annoying thing is gnome-keyring ssh being broken (not exporting the env var)
[22:53] <seb128> pitti, well it's clear from the build log that the png loader didn't build on amd64
[22:53] <pitti> but just like so many of those, I guess it's a gdm bug again :/
[22:53] <seb128> pitti, didn't notice that there and gnome-keyring didn't change for some weeks
[22:54] <BUGabundo> seb128: no pleasure here. but I'm an alpha tester, so I've been finding many bugs over the years, helping to put them on BTSs, triaging, alerting users... the usual
[22:54] <pitti> seb128: yeah, SSH_AUTH_SOCK=/tmp/keyring-tYQTmS/socket.ssh ssh ... works
[22:54] <pitti> seb128: bit too late right now, but I'll give a go at that amd64 thing tomorrow morning
[22:54] <seb128> pitti, the environment export is a dbus thing I think
[22:54]  * pitti dist-upgrade
[22:54] <seb128> pitti, thanks, it's not the end of the world it's only icons
[22:55] <pitti> ah, there comes a new gtk
[22:55] <seb128> pitti, I just hate autotools and I've no amd64 box to look at what's going on
[22:55] <seb128> pitti, and I don't know enough about libtool to guess what is wrong without logs and access to a build
[22:55] <seb128> could be a race and work on next build, dunno
[22:56] <slangasek> directhex: monodevelop-boo appears to be in need of a fakesync, due to mismatched .orig.tar.gz md5sum
[22:57] <directhex> slangasek, is it? i believe the fakesync part, but i don't remember doing anything to break it recently
[22:59] <BUGabundo> ok my work here is done. thanks
[22:59]  * pitti cd /bed, good night
[22:59] <BUGabundo> bye pitti
[23:03] <yofel> seb128: the png loader built fine when just running ./configure && make - debuild and pbuilder are still running
[23:04] <seb128> yofel, ok thanks
[23:09] <directhex> of course, i apparently broke sid, so what do _I_ know?
[23:10] <directhex> oh, there's the problem, monodevelop-boo is missing from our tracker
[23:10] <directhex> wgrant, poke poke
[23:11] <directhex> mmm, still hasn't had a new upload since april
[23:12] <directhex> slangasek, was your comment simply regarding the funny version number? if so, a fakesync is fine, but i'm not sure what it would achieve given the packages are identical anyway
[23:14] <wgrant> directhex: Hi.
[23:14] <slangasek> directhex: no, the packages aren't identical, there's a build-dep on libgtksourceview2.0-cil
[23:15] <directhex> wgrant, can you manually add packages to an MDT page?
[23:15] <wgrant> directhex: I can.
[23:15] <directhex> slangasek, really? how silly
[23:15] <wgrant> directhex: But let's see if there's a more general way to get that one too...
[23:16] <directhex> wgrant, well, most of monodevelop* is with meebey as sole maintainer, not group maintained (according to control, anyway - not in reality)
[23:16] <wgrant> directhex: So, we only grab packages with one of the three mono maintainers right now.
[23:16] <directhex> slangasek, so a fakesync to universe just involves uploading a signed source package using our orig and their diff, yes?
[23:17] <wgrant> I guess I'll just add this explicitly now.
[23:17] <directhex> wgrant, sorry!
[23:17] <slangasek> directhex: yes
[23:17] <directhex> slangasek, okay, give me a minute. my first direct archive upload. eeks!
[23:19] <wgrant> directhex: It be there now.
[23:20] <directhex> tee hee, that makes things slightly more convenient:  -- Jo Shields <directhex@apebox.org>  Wed, 08 Apr 2009 22:42:33 +0100
[23:20] <directhex> wgrant, coolness. ta!
[23:22] <directhex> ehm... i take it i need to manually specify an upload distro in dput.cf? it's not bright enough to deal with "unstable -> karmic"?
[23:23] <Laney> it comes set up with ubuntu as default I think
[23:23] <Laney> (you should change this)
[23:23] <Laney> you do need to change the release in the changelog though
[23:24] <wgrant> Isn't one meant to add an XbuildY changelog entry for a fakesync?
[23:25] <seb128> wgrant, not if the tarball is different
[23:25] <seb128> wgrant, otherwise it will be tried by the auto-syncer and break
[23:25] <yofel> seb128: the debuild and pbuilder builds built without error too
[23:25] <directhex> Laney, you change the release in changelog for a fakesync?
[23:25] <seb128> yofel, and the png loader is built?
[23:26] <wgrant> seb128: But it is meant to be autosynced.
[23:26] <yofel> seb128: according to 'dpkg -L libgtk2.0-0' yes
[23:26] <seb128> wgrant, well, if the orig.tar.gz is different that's not going to happen
[23:26] <wgrant> seb128: It will when Debian uploads a new upstream.
[23:27] <wgrant> And until then the autosyncer will just not do anything.
[23:27] <seb128> wgrant, right, but we have no way to say to the auto-synced "it's a buildn version but try only next upstream version and not next revision"
[23:27] <Laney> directhex: yes sir, otherwise it will be rejected afaik
[23:27] <seb128> wgrant, it will break at each run until you sort it
[23:27] <wgrant> seb128: I see.
[23:27] <seb128> wgrant, 0.8-1build1 will try to autosync 0.8-2
[23:27] <wgrant> directhex: Soyuz works out the upload series by looking in the .changes, which is generated from the changelog.
[23:28] <directhex> Laney, can you suggest a fakesync changelog to read, to make myself feel better?
[23:28] <seb128> wgrant, and that will break the sync run on a md5sum mistmatch error
[23:28] <seb128> directhex, http://people.canonical.com/~pitti/scripts/syncpackage
[23:28] <Laney> directhex: I might have done one for one of the debuggers
[23:29] <seb128> directhex, in fact that's to do a real sync yourself so ignore it
[23:29] <Laney> but, just change the release to karmic
[23:29] <Laney> 0ubuntu1 the version number
[23:29] <seb128> directhex, basically get debian source, edit changelog to change unstable to karmic, build, sign, upload
[23:29] <directhex> Laney, that's a 0ubuntu1, not a fakesync, no?
[23:29] <wgrant> seb128: I see a lot of build1 fakesyncs
[23:30] <Laney> seb128: I thought that was what was just being discussed
[23:30] <seb128> wgrant, right, when the orig.tar.gz doesn't mismatch so next sync will work
[23:30] <Laney> erm
[23:30] <Laney> directhex: *
[23:30] <seb128> wgrant, that's what we do for rebuilds since we don't have bin-nmu
[23:30] <wgrant> seb128: No, these are for mismatched orig.tar.gzs.
[23:30] <seb128> wgrant, ie a package is in sync and need a rebuild you use build1 so next sync get it
[23:30] <wgrant> No.
[23:30] <directhex> seb128, good, binNMU is the work of the devil
[23:30] <Laney> I would 0ubuntu1 it to avoid it being autosynced
[23:30] <seb128> wgrant, well that's wrong and that will create issue during the next autosync run
[23:31] <seb128> wgrant, give me names ;-)
[23:31] <wgrant> seb128: A few of these were by archive admins...
[23:31] <wgrant> So I somehow think they are doing it the right way.
[23:31] <seb128> wgrant, can you give me an example?
[23:31] <wgrant> https://lists.ubuntu.com/archives/karmic-changes/2009-June/002294.html
[23:31] <directhex> Laney, not an issue, since the package  won't need to be changed until the next upstream release
[23:31] <directhex> *cough*
[23:31]  * Laney blinks
[23:31] <seb128> wgrant, archive admin have access to the autosync filters so they can put things on the ignore list if they want
[23:32] <directhex> meh, close enough for government work. where'd i put that dput...
[23:32] <seb128> but I think it's easy using an ubuntu<n> versioning
[23:32] <seb128> wgrant, I will check with pitti tomorrow
[23:33] <cjwatson> I think build1 plus a blacklist entry is fine
[23:33] <seb128> he probably added the source to the don't sync list
[23:33] <seb128> cjwatson, well it's extra archive admin work compared to using 0ubuntu1 and asking for a sync later
[23:33] <cjwatson> I'm not sure it actually is extra work; manual syncs are work too
[23:33] <cjwatson> and about the same amount, tiny either way
[23:34] <seb128> that's maybe because I don't check for packages on the list often
[23:34] <cjwatson> anyway, /me -> sleep -> debconf
[23:34] <seb128> ie if I'm doing sync those are likely to stay on the "do not sync" list for a while
[23:34] <seb128> ie, it's not trivial to know when to drop them from the list
[23:36] <seb128> yofel, ok thanks, I've a uploaded a no change rebuild version
[23:36] <seb128> let's see how it works
[23:37] <yofel> seb128: after installing my self-build .deb files everythings ok again
[23:38] <seb128> yofel, ok, good, I've no explanation about the issue
[23:39] <dupondje> i'm trying to compile it here also, checking if it works also
[23:39] <seb128> I've uploaded a new revision
[23:39] <seb128> it will have built in 16 minutes or so
[23:39] <seb128> let's see how that one goes
[23:39] <dupondje> good thing :)
[23:43] <NoelJB> seb128: I understand that you just posted the fix.  Thank you for the very prompt response.  :-)  [sometimes a "thank you" is the only currency in Open Source]
[23:44] <dupondje> its not a real fix tho, its just a reupload to rebuild it
[23:44] <seb128> NoelJB, thanks, dunno if that build will work, I don't know why the previous one had the issue
[23:53] <seb128> ok, new gtk built correctly now and fixes the issue
[23:54] <yofel> seb128: thanks :)
[23:55] <seb128> yofel, thank you for testing and reporting the issue early