[00:19] <cousteau> there seems to be a problem with an update of the package "upstart" (you're probably already aware, but just in case)
[00:20] <cousteau> seems to be due to a dependency problem; the version of libc6 required doesn't match the one available on maverick
[00:27] <TheMuso> Gah was about to reply, and then he logged off...
[00:32] <SpamapS> I hate when people do that :-/
[00:41] <psusi> cjwatson, I just found breakage from the dropping of the no 'p' partition separator patch.. the installer is still not using the 'p'.  any idea where that code would be?
[00:42] <cjwatson> psusi: depends which bit of the installer.  most of it should just come from parted.  it would be easier to diagnose given a bug with syslog and partman
[00:42] <cjwatson> psusi: (we're in incompatible timezones, debugging by IRC probably won't be hugely useful - about to go to bed)
[00:43] <psusi> hrm... k... I'll take a look at partman and I'm pretty sure we dropped the patch from parted too, but I'll check
[00:43] <cjwatson> we dropped the parted patch, yes
[00:44] <cjwatson> there are various bits and pieces where it could be - it would be easier to debug from a log than to try to enumerate them all, I suspect :)
[00:45] <psusi> k... I'll take a look at the logs and file a bug
[01:56] <psusi> I had a dog and his name was bingo
[02:01] <sladen> cjwatson: just got that keyboard question x4 again on upgrade
[02:04] <cjwatson> sladen: bug with logs please, can't debug it by irc
[02:04] <cjwatson> I'll see a bug if you file it
[02:04] <cjwatson> don't suppose you happened to be running with DEBCONF_DEBUG=developer
[02:13] <kees> SpamapS: argh, how did upstart 0.6.6-4 get promoted from -proposed but eglibc 2.12.1-0ubuntu10.2  did not? now the archive is broken.
[02:19] <cjwatson> if somebody validates bug 504198 on maverick then it'll be easy to promote
[02:19] <cjwatson> (and yes, this shouldn't have happened)
[02:35] <psusi> cjwatson, found the problem and fixed it.  Hopefully you can upload it in the morning in time for alpha 2: bug #711616
[03:02] <Laibsch> I am the Debian maintainer of the pastebinit package.  I'm preparing a new upstream release.  Some file were moved from /etc/ to /usr/ (see https://bugs.launchpad.net/ubuntu/+bug/621923).  I compiled and test-installed the package locally, but unfortunately, the files in /etc are not removed. http://paste.debian.net/106271/ What do I need to do to achieve the removal of these files?
[03:05] <RAOF> Laibsch: Have you performed the requisite supplications in preinst/postinst?
[03:05] <Laibsch> nope
[03:05] <Laibsch> Can you tell me more?
[03:05] <Laibsch> or give an example package I can go by?
[03:06] <RAOF> http://wiki.debian.org/DpkgConffileHandling
[03:06] <Laibsch> thanks
[03:07] <RAOF> And, obviously, use the dpkg-maintscript-helper stuff.
[03:08] <Laibsch> My machines are lucid
[03:08] <Laibsch> dpkg seems to be too old on them
[03:09] <RAOF> Correct, unless we patched that in :(
[03:53] <achiang> if i'm hacking on a source package and modify debian/control so as not to build a specific binary package, can i simply comment out all the lines in the binary-package.install file, or do i need to remove the .install file completely?
[03:54] <broder> achiang: if the package is no longer listed in debian/control, i don't think you have to do anything to the .install file
[03:56] <RAOF> You may have to do something to the rules file, if it explicitly references the package you've commented out.
[03:58] <achiang> broder: RAOF: both make sense, thank you. :)
[03:58] <achiang> RAOF: hm, indeed, there is a reference in the rules file to the udeb
[03:59] <Laibsch1> I've read a bit about the conf file issue.  I'm starting to wonder whether the pastebin definitions are config files or not.
[04:00] <Laibsch1> pastebinit has one for per supported pastebin where information is stored how to send text to that pastebin
[04:00] <Laibsch1> these files used to reside in /etc/pastebin.d/ but we're in the process of moving them to /usr/share/pastebin
[04:00] <Laibsch1> are these config files or not?
[04:00] <RAOF> If you've installed them under /etc/ then they've been considered dpkg conffiles, and you'll need to do the magic dance.
[04:01] <Laibsch1> I understand that
[04:01] <Laibsch1> But I'm starting to wonder if they are config files (and should stay where they are) or whether they are not config file
[04:01] <Laibsch1> s
[04:01] <Laibsch1> they somehow configure the program
[04:02] <RAOF> It depends on how complex you want the program to be.
[04:02] <Laibsch1> hm, what do you mean?
[04:02] <Laibsch1> from the next release, the program will read from both /etc and /usr
[04:02] <RAOF> It seems to me that a totally acceptable solution would be to ship the default providers in /usr/share/hello-I'm-a-provider, and allow the user to define new ones in /etc/pastebin.d
[04:02] <Laibsch1> I'm starting to have doubts that this is really the right thing
[04:02] <Laibsch1> OK
[04:03] <broder> rich set of defaults + user overrideability is a great model
[04:03] <Laibsch1> RAOF, what you describe is what will ship in the next release
[04:03] <achiang> RAOF: http://pastebin.ubuntu.com/561246/ -- what do those two lines mean? in the sense that the first line specifies -plibx11-6, but the second line seems to negate it?
[04:03] <achiang> RAOF: my confusion stems from the fact that i think the first line should call dh_makeshlibs on the libx11-6 package *and* make it depend on the udeb
[04:03] <Laibsch1> broder: actually, the program reads from three locations /usr/, /etc and dotfile in $HOME
[04:04] <broder> Laibsch1: even better in my book :)
[04:04] <RAOF> broder: Oh, yes.  Xserver configuration is much much nicer now that we can throw snippets into /usr/share/X11/xorg.conf.d, and have users put stuff in /etc/X11/xorg.conf.d to override.
[04:04] <Laibsch1> OK, thanks.  So, I will keep this
[04:04] <Laibsch1> now need to figure out the magic dance in a way that is supported in lucid (my main system for all machines) and acceptable for experimental
[04:04] <RAOF> achiang: The first says “run makeshlibs on the libx11-6 package”, the second says “run makeshlibs on everything *but* the libx11-6 package”.
[04:05]  * Laibsch1 goes back to read the wiki
[04:06] <broder> Laibsch: if you can test in a pbuilder or schroot and use dpkg-maintscript-helper, that's probably better
[04:06] <Laibsch> I still need to have lucid support
[04:06] <achiang> RAOF: i see. so if i'm no longer building the udeb, i can just remove the --add-udeb= arg from that line, but still need to keep both lines to run makeshlibs both on the package and *not* on the package?
[04:06] <Laibsch> or I will upload a package that I cannot use myself.  Now where would the point be in that? ;-)
[04:07] <RAOF> achiang: You could also just remove the first line and the “-Nlibx11-6” from the second line.
[04:08] <achiang> RAOF: duh. that makes much more sense. thank you
[04:33] <achiang> does anyone know if we use libgtk2.0-0-udeb in our installer? or is that just a graphical d-i thing?
[04:33] <broder> achiang: to the best of my knowledge, it would be a d-i thing. ubiquity feeds code from udebs into some of its backend stuff, but the runtime environment is all "normal" packages
[04:35] <achiang> broder: ok, thank you. i am backporting maverick's libgtk2.0 to lucid, and there are versioned B-D on a bunch of libraries, but they *all* look related to udeb / installer-type things
[05:23] <micahg> kees: BTW, new upstart wouldn't install w/out eglibc
[07:41] <didrocks> good morning
[08:03] <sk-ruby> Hi, getting errors while connecting remote MS SQL server from my Ubuntu 10.10...check http://pastie.org/1520778
[08:04] <sk-ruby> any help would be appreciated
[08:04] <micahg> sk-ruby: you might want to try #ubuntu-server or #ubuntu as this channel is for development
[08:04] <kees> micahg: i know, which is why i was crying :( the archive is broken until eglibc gets promoted :(
[08:05] <micahg> kees: why is that broke?  Isn't apt DTRT?
[08:05] <kees> well, not broken. just that upstart is suddenly uninstallable
[08:06] <kees> i am up too late :)
[08:06] <micahg> kees: me too :)
[08:06] <micahg> kees: I also forget most people don't use aptitude which does nice things like tell you not to break your system
[08:07] <mvo> well, apt and update-manager should do the same
[08:07] <sk-ruby> micahg: thank you
[08:07] <mvo> kees: *ick*
[08:07] <micahg> mvo: sorry, that came out wrong (2AM here :))
[08:07] <mvo> micahg: no offense taken, no worries ;)
[08:09] <micahg> mvo: are there any plans for "suggestions" in update-manager like aptitude?
[08:09] <pitti> Good morning
[08:09] <micahg> good morning pitti
[08:10] <mvo> micahg: suggestions for alternative solution?
[08:10] <micahg> pitti: I've looked for that checkrdepends tool and I cannot find it
[08:11] <micahg> mvo: like how to resolve conflicts if packages cannot be installed
[08:11] <pitti> micahg: ah, I thought it was in lp:ubuntu-archive-tools, but apparently it's only on cocoplum
[08:11] <mvo> micahg: not in the near future, while useful its not easy to find a good UI for this so that its useful for non-powerusers I think
[08:12] <micahg> pitti: ah, ok :), is there anything proprietary about it, maybe it could go in one of the tools branches?
[08:12] <pitti> micahg: http://people.canonical.com/~pitti/scripts/checkrdepends
[08:12] <mvo> micahg: but there are some plans to improve the apt resolver :)
[08:12] <micahg> mvo: yeah, I was just thinking about that as well
[08:12] <pitti> micahg: no, nothing proprietary, but it is currently written to require a local mirror
[08:13] <pitti> micahg: shouldn't be too hard to change it to use urllib.open() instead, though
[08:13] <micahg> pitti: ooh, sounds like a nice mini-python project for me to learn on
[08:15] <micahg> pitti: thanks
[08:15] <micahg> pitti: oh, should I file a metabug to resolve the gcc-4.3 rdepends?
[08:17] <pitti> if we want to get rid of it, sure
[08:17] <pitti> easier for tracking
[08:19] <micahg> pitti: ok, I'll do that then, thanks, BTW, would you be able to accept thunderbird-locales in maverick-proposed?
[08:20] <pitti> micahg: yes, I'll try to have another SRU run today
[08:20] <micahg> pitti: ok, thanks, I can try to ask for testing at the Xubuntu meeting on Thursday then
[08:35] <dholbach> good morning
[08:49] <pitti> bryceh, RAOF: is bug 696957 fixed in natty already?
[08:50] <pitti> ah, description says so, nevermind; closing natty task
[09:14] <\sh> is there a "non recommended way" to re-enable closed source nvidia drivers for natty, for the newest xorg, somehow...
[09:55] <cjwatson> achiang: only graphical d-i; currently, we build it but don't use it
[09:56] <cjwatson> achiang: (though I'd like to use it at some point)
[09:56] <tjaalton> we could revisit it for 11.10? the X stack should at least be ready for it
[09:58] <cjwatson> AFAIK the images work, but (a) they haven't had any significant branding effort (b) they're a fair bit bigger and this presents CD size issues :-/
[09:58] <cjwatson> might put them on the DVD or something
[10:01] <tjaalton> right
[12:53] <achiang> cjwatson: thanks
[14:35] <mterry> @pilot in
[14:45] <corecode> hi
[14:46] <corecode> how am i supposed to build packages from bzr that have a quilt patch queue?
[14:46] <corecode> debuild tells me:
[14:47] <corecode> ah, nm.
[14:47] <corecode> it was for the src package
[15:51] <barry> cjwatson: any chance you can sponsor this: https://code.launchpad.net/~barry/ubuntu/natty/libvigraimpex/bug-711468/+merge/48237
[15:51] <cjwatson> barry: I can, it needs to be after alpha-2 though I think
[15:52] <barry> cjwatson: ah, right, thanks
[15:52] <barry> it's the last main package w/python depends that fails to install afaict
[15:54] <cjwatson> barry: I think I actually demoted it :)
[15:54] <cjwatson> python-vigra | 1.7.0+dfsg-7ubuntu4 | natty/universe | amd64, armel, i386, powerpc
[15:55] <cjwatson> it wasn't actually directly needed - it was pulled in by an arcane quirk of germinate
[15:56] <barry> cjwatson: even better! :)  it'll still be good to fix (and a rebuild alone should do it), but less critical
[15:56] <cjwatson> right, I'll leave this in my browser until Thu/Fri and merge it then
[15:57] <barry> thanks!
[16:13] <JontheEchidna> mvo: ping
[16:15] <mvo> JontheEchidna: in a meeting, but otherwise hello :)
[16:15] <JontheEchidna> mvo: oh, ok. :) I was just wondering if there was currently a way to use the Icon: field of packages in extras.ubuntu.com
[16:15] <JontheEchidna> to actually get the icon
[16:16] <JontheEchidna> the thumbnail-url and screenshot-url fields seem pretty straightforward
[16:17] <mvo> JontheEchidna: there is support for icon-url
[16:17] <mvo> JontheEchidna: then it will fetch it dynamically, that should even be documented somewere, tremolux, do you have a link?
[16:20] <JontheEchidna> otherwise it was pretty easy to add support for extras.ubuntu.com apps: http://i.imgur.com/VNQO1.png
[16:20] <tremolux> JontheEchidna, mvo: hiya, info here: https://wiki.ubuntu.com/PostReleaseApps/Metadata
[16:21] <JontheEchidna> yeah, I saw that page, but looking at the suspendend-sentence package the Icon: field doesn't give a url
[16:21] <barry> skaet: for natty alpha 2 release notes, you may want to mention that all main packages should now be built for and installable with python 2.7 (at least afaik).  please request bug reports for any incompatibilities folks find
[16:22] <skaet> barry, okie, adding now.
[16:22] <skaet> thanks!
[16:22] <barry> skaet: i've looked at build failures and installation failures, but there's no way to know if a package is actually run-time compatible unless people actually use them
[16:22] <barry> skaet: thanks.  please ask folks to add the 'python27' tag to any bug reports
[16:24] <skaet> barry,  will do.
[16:25] <stgraber> mvo, JontheEchidna: If that's about suspended-sentence, I saw that we have a typo in the icon name field (after uploading the package obviously ...) so that might be why it's not showing up
[16:26] <JontheEchidna> suspended-stentence? I saw that too. I'm just wondering where my app should grab the icon from
[16:30] <tremolux> JontheEchidna: so, in the current scheme, the icons are published by LP to the following directory: http://extras.ubuntu.com/meta/
[16:30] <JontheEchidna> ok, that's exactly what I needed. Thanks :)
[16:31] <tremolux> JontheEchidna: you're welcome!  yeah, it's pretty well-hidden (tho not on purpose)  :)
[16:35] <tremolux> JontheEchidna: I just added that info to the wiki page  :)
[16:35] <JontheEchidna> thanks :)
[16:47] <mvo> thanks tremolux!
[16:47] <tremolux> mvo: sure thing  :)
[17:03] <\sh> micahg: ZF 1.11.3 is coming
[17:56] <micahg> \sh: thanks
[18:06] <barry> @pilot in
[18:06] <ev> kees: regarding bug 710582, can you elaborate on why its bad use of assert macros?
[18:07] <\sh> micahg: zf 1.11.3 just reached natty...your turn ;)
[18:07] <kees> ev: assert() is fine. webkit's insane way to die isn't helpful for debugging. if it actually used "assert" the reason would be capture, the backtrace would be sensible, etc.
[18:07] <kees> *captured
[18:08] <ev> kees: ah, that's what I thought, just wanted to clarify
[18:08]  * kees nods
[18:08] <kees> it's not security-bad, it's just terribly ugly and unhelpful. :)
[18:08] <kees> also, libraries should avoid assert() at all costs
[18:08] <ev> indeed
[18:10] <barry> mtaylor: hi.  are you still piloting today too?  can you tell me what you're looking at so we don't step on each other's toes?
[18:14] <barry> mterry: ^^
[18:15] <mterry> barry, I was about to pilot off
[18:15] <mterry> in fact...
[18:15] <mterry> @pilot off
[18:15] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[18:15] <mterry> @pilot out
[18:15] <barry> mterry: cool, np.  i'll take over from here
[18:43] <mvo> cjwatson: hints on what I can do about bug #712029 are appreciated, not urgend, I will read scrollback (hints how to get grub going and what might cause the issue, I suspect its the subvolume @ that causes the issue)
[21:09] <ari-tczew> is currently filled a bug against nvidia -> latest xserver ?
[21:43] <TheMuso> ari-tczew: Its known that the current AMD and NVIDIA drivers in the archive do not work with the new X server. It requires NVIDIA/AMD to release new drivers.
[21:45] <ari-tczew> TheMuso: OK, thanks for info.
[21:45] <RoAkSoAx> ari-tczew: you have a broken X or a bad resolution that you can't change?
[21:47] <ari-tczew> RoAkSoAx: I can't boot natty on 2.6.38 kernel, so I removed it and now I'm running 2.6.37-12 kernel on default driver. I can change resolution and now it's native for my monitor 1440x900.
[21:48] <RoAkSoAx> ari-tczew: I couldn't boot either with latest kernel and nvidia drivers. So I dropped to root prompt (recovery mode), installed xserver-xorg, which deleted the nvidia driver, and it booted. but the resolution was not right. Had to do sopme tricks to get it fixed
[21:49] <ari-tczew> RoAkSoAx: What's your
[21:49] <ari-tczew> uname -r right now?
[21:49] <RoAkSoAx> ari-tczew: 2.6.38-1-generic
[21:49] <ari-tczew> RoAkSoAx: Use 2.6.37-12
[21:50] <ari-tczew> You can change then resolution and even dualview.
[21:50] <RoAkSoAx> ari-tczew: with nvidia drivers?
[21:50] <ari-tczew> note: without nvidia, default driver (vesa?)
[21:51] <RoAkSoAx> ari-tczew: oh ok!! nah I'm fine with 2.6.38 now! fixed the resolution problem already I just have an ISO with HDMI... but since it is nvidia.. it was expected
[21:51] <ari-tczew> RoAkSoAx: Do you know how can I check which driver is natty running ATM?
[21:51] <kklimonda> ari-tczew: check /var/log/Xorg.0.log
[21:54] <ari-tczew> kklimonda: Thanks. If I'm correct, it says nv with NOVEAU. Odd.
[22:39] <ari-tczew> barry: around?
[22:54] <barry> ari-tczew: i am
[23:00] <ari-tczew> barry: could you look on bug 712136
[23:01] <barry> ari-tczew: sure
[23:09] <kklimonda> any idea if the new queue for debian is being processed at this time?
[23:12] <barry> kklimonda: do you mean syncs from debian?  not for natty right now since we're frozen for alpha2, but iirc, even after that it's by request only for the rest of the cycle
[23:13] <ari-tczew> I guess kklimonda is thinking about flow of packages in Debian, not natty.
[23:13]  * micahg is guessing he means this: http://ftp-master.debian.org/new/
[23:13] <kklimonda> barry: no, I'm talking about the NEW queue for debian - I'm interested in few packages that are still in their NEW queue and I can see they haven't yet been processed by ftp masters.
[23:14] <barry> ah
[23:14] <micahg> DktrKranz: ^^^
[23:14] <kklimonda> so I'm wondering if the reason for that is the close proximity to the squeeze release, or are they always being slow :)
[23:14] <micahg> kklimonda: before it was said the NEW processing would be slower during the freeze
[23:17] <cjwatson> I would expect ftpmasters to have better things to do right now
[23:17] <kklimonda> micahg: any idea if I can download packages from the new queue?
[23:17] <cjwatson> but it's not long until the release
[23:18] <cjwatson> packages in NEW haven't been vetted for redistributability, so I believe Debian would consider it a legal problem to allow you to download things from it
[23:18] <ari-tczew> barry: any ideas for my question?
[23:19] <barry>  
[23:19] <barry> ERC> ari-tczew: do you mean "timeout: 255 seconds
[23:19] <barry> ERC> ari-tczew: do you mean "
[23:19]  * barry curses cut-n-paste
[23:19] <barry> ari-tczew: do you mean "Please get in touch with someone expierence with python to add support for python 2.7." ?
[23:19] <ari-tczew> barry: nope, support for python 2.7 in bug 712136
[23:19] <ari-tczew> yes
[23:20] <barry> ari-tczew: yep, i'm looking at that right now
[23:26] <micahg> barry: are we dropping python 2.6 or keeping it until the next LTS (or no decision yet)?
[23:26] <barry> micahg: no decision yet.  i did post a message on ubuntu-devel looking for feedback and got radio silence ;)
[23:27] <micahg> barry: I remember the Launchpad people were big advocates of keeping it around until the LTS
[23:27] <barry> they are :)
[23:27] <kklimonda> by until do you mean removing 2.6 in the next LTS, or after LTS?
[23:27] <barry> micahg: if you have any thoughts, a follow up on the mlist would be great
[23:28]  * kklimonda has some thoughts actually..
[23:28] <kklimonda> lets see if I can dig the message out of archive :)
[23:28] <micahg> barry: unfortunately, I know very little about the python stack, so all I have to contribute is hearsay
[23:30] <kklimonda> bah, can't find the email when I need it ;)
[23:31] <kklimonda> barry: do you remember the subject of the email about whether to keep python 2.6 or not for the next lts?
[23:32] <micahg> barry: I don't see it, was it moderated?
[23:33] <kklimonda> I do remember reading it
[23:33] <kklimonda> but I can't find it now :)
[23:36] <barry> kklimonda: yeah, i can't either!  maybe it didn't make it to the list
[23:38] <barry> the subject is "Analysis of packages and their Python support"
[23:39] <micahg> didn't see it
[23:39] <barry> dated 2011-01-24
[23:40] <barry> i don't see it on gmane either.  i guess that explains why i haven't gotten any responses :(
[23:41] <barry> how very odd.  i'm going afk for dinner but i guess i'll resend when i get back
[23:41] <kklimonda> hmm.. nothing, but I do remember this topic being brought somewhere and that LP people were advocating keeping python 2.6 around.. maybe it was discussed here?
[23:41] <barry> kklimonda: could have been
[23:42] <micahg> kklimonda: probably was discussed at UDS as well
[23:42] <kklimonda> *nods* also possible