[00:22] <lamont> infinity/cjwatson "any soyuz host" is what I was told.
[00:23] <infinity> lamont: Yeah, that seems to be correct. :)
[00:45] <directhex> hm. is it slangasek or pitti whom i was talking to about /usr/share/doc/monofoo issues before jaunty released? i don't remember
[00:45] <slangasek> yes
[00:47] <directhex> i've convinced meebey to allow me to push a solution to clearing symlinks on upgrade to align with debian into the debian packages, on the proviso that i keep those changes strictly to ubuntu-only when building. that much i've done. so now i just want to get the preinst "right".
[00:47] <directhex> iirc you weren't too happy with a blind "if [ -L /usr/share/doc/foo ] then rm -rf"
[00:48] <slangasek> I prefer to have it guarded by a version check
[00:48] <directhex> which is $2, isn't it?
[00:48] <slangasek> also, there was some inconsistent use of quoting conventions
[00:48] <slangasek> yes
[00:48] <slangasek> (I think my comments on this were in the log of the sponsorship bug?)
[00:48] <directhex> let me find the appropriate bug
[00:49] <slangasek> bug #344750?
[00:49] <ubottu> Launchpad bug 344750 in mono "Mono /usr/share/doc symlink problem" [Medium,Fix released] https://launchpad.net/bugs/344750
[00:50] <directhex> yeah, just re-reading it
[00:51]  * directhex pulls out dpkg --compare-versions
[01:38] <cjwatson> infinity: for armel, in case you hadn't noticed, note that the kernel is still in NEW - I'm sorting out its overrides now
[01:38] <cjwatson> (I see gcc-4.4 is still building anyway)
[01:52] <infinity> cjwatson: GCC will be at it for a long while still.  But thanks for sorting the kernel.
[01:54] <cjwatson> kernel's accepted now
[03:16] <geiseri_> cjwatson: hrm, how do i make sure my packages file is sorted alphabetically?
[03:16] <geiseri_> sort doesnt seem to cut it on multiple lines
[03:19] <calc> geiseri_: sort-dctrl?
[03:20] <geiseri_> will that work on a Packages file that i generate with apt-ftparchive?
[03:20] <calc> geiseri_: i think so... you can try it anyway
[03:20]  * geiseri_ will
[03:21] <geiseri_> calc: like a dream
=== jcastro_ is now known as jcastro
[03:23] <geiseri_> do i need to make sure all of my Packages files are sorted, or just the one for the installer?
[03:24] <calc> well regular apt-get doesn't need them to be sorted afaik
[03:24] <geiseri_> okay
[03:25] <calc> but i don't know about the installer
[03:25] <geiseri_> cjwatson seemed to think that there was a bug associated with an unsorted Packages file
[03:26] <calc> oh maybe there is, he would more likely know than me :)
[03:27] <geiseri_> well everyone seems to know more than me when it comes to the guts of what is going on in the installer process
[03:27] <geiseri_> :D
[03:28] <calc> i used to know the guts of the installer process back around 2001
[03:28] <calc> heh, but that was pre-Ubuntu and d-i
[03:28] <calc> back with original debian boot-floppies, ugh
[03:28] <geiseri_> haha, well at that point i was still drinking suse coolaid...
[03:29] <geiseri_> i could tell you all sorts of things to do with that installer process :D
[03:29] <geiseri_> the d-i stuff is very slick though from what i can see
[03:30] <geiseri_> and the preseed is also very nice
[03:30] <calc> yea it works much better than the old debian install process anyway :)
[03:31] <geiseri_> well when you spend hours a day doing winders slipstream installers, this is a dream come true :D
[03:32] <geiseri_> crap, even with the sorted package list it still blows up on the setting up of ppoe...
[03:33] <geiseri_> hrm the real error is required package netcfg is not installed
[03:35] <geiseri_> is the order in the Packages file the order udebs are installed on the system, or is that defined somewhere else?
[03:35] <xee> Hi, I had some questions about creating a Ubuntu derivative, is this the correct place to ask?
[03:46] <geiseri_> is there a way to set the order that the install steps are performed?  so that netcfg is installed and running?
[03:57] <geiseri_> how does the debian installer decide what udebs to load and in what order?  Is that what the Packages file does?
[05:19] <ia> hello. i have a question about apport - please, correct me, if i wrong. as far as i understand, if my app provides /usr/share/apport/package-hooks/<my_app>.py file, then, if my app will crash, apport will notify of such crash automatically and offer to send bug report, so i don't need to worry about adding in my app some extra code for bug reporting in crash cases, right?
[05:23] <sbeattie> ia: not quite. apport collection of crash information is only enabled during the development cycle; it's disabled by default for releases.
[05:24] <ia> sbeattie: yep, i know about it. so, in everything else am i right?
[05:25] <sbeattie> ia: apport will do the collection for crashes or if ubuntu-bug is invoked on your software package and offer to submit it to launchpad regardless of whether /usr/share/apport/package-hooks/<my_app>.py exists or not; what adding it lets you do is automatically collect relevant information about your software and attach it to the bug report.
[05:25] <sbeattie> ia: for example, you can attach your app's logfiles or configuration settings, which apport normally would not attach.
[05:27] <sbeattie> ia: does that make sense?
[05:32] <ia> sbeattie: yes :-)
[05:33] <lifeless> ia: note that my_app is actually a package name
[05:33] <lifeless> sometimes the package name differs from your app name, if your app is named generically, or with a name another package already has
[05:40] <mpontillo> Do I understand correctly that when translating software into another language, the goal is to contribute to upstream as much as possible? (rather than cluttering debian/patches?) I'm thinking about how to best fix a bug that requires a change to a user-visible string. It's in the po files, but likely shouldn't have been. (string just "SSH")
[05:43] <lifeless> mpontillo: 'ssh' or 'SSH' ?
[05:43] <lifeless> 'ssh' is a command line tool name, and I'd agree with you, but 'SSH' is more of a noun..
[05:43] <mpontillo> lifeless: "SSH". It's a string in a dialog box. It's "translated" into "SSH" for all languages except one, where it has some additional descriptive text in parentheses.
[05:44] <lifeless> mpontillo: and whats the change you need to make to it to fix the bug?
[05:44] <mpontillo> the bug description asks to change the text "SSH" to "SFTP".
[05:44] <mpontillo> sounds simple enough ;)
[05:45] <lifeless> assuming thats correct, do it ;)
[05:45] <lifeless> if there are po files in the source package, updating their translations would seem appropriate to me. however! be aware that be build translations out of rosetta for Ubuntu main
[05:45] <mpontillo> lifeless: right, so there are two strategies. I could s/SSH/SFTP/ in all the .po files. Or I could just change _("SSH") to "SSH"...
[05:46] <mpontillo> *SFTP.
[05:46] <lifeless> ITYM _("SSH") -> "SFTP"
[05:46] <lifeless> right
[05:46] <lifeless> I'd talk to the author about the _() removal
[05:50] <ia> lifeless: yes, i know it. in fact, as far as i know, if my_app package is not part of ubuntu packages, opening page for bug reporting will looks like https://bugs.launchpad.net/ubuntu/+source/my_app/+filebug but should as https://launchpad.net/my_app/+filebug , right? if am i right, how i can change such behavior? latest version of apport have key for 3rd party software (if run it from terminal), but how i can enable "3rd-party-mode" for apport in my app, i
[05:50] <ia> f it crashes incidentally and apport starts sending bug for this?
[05:50] <mpontillo> lifeless: right. so I'd say that's a good plan, except for one fatal flaw. what if the text (written in Georgian (./po/ka.po:msgstr "SSH (უხიფათო შელი)") says "SFTP". then I'd be making a big mistake!
[05:51] <mpontillo> sigh, I guess that's what I get for trying to pick something easy to learn how bzr package maintenance is done ;)
[05:53] <lifeless> ia: I'm not sure
[05:53] <lifeless> mpontillo: there is a translation today; only the ones that are identical can be machine updated to SFTP
[05:53] <lifeless> mpontillo: the other one you should mark 'fuzzy' and machine update
[05:54] <lifeless> that will indicate it needs review
[05:56] <mpontillo> lifeless: ah, makes sense. where do I go to mark it "fuzzy"? is that directly in the .po file, or on a webapp on Launchpad somewhere? sorry for my ignorance; I've been reading docs, and have found pages on "how to translate", but not the process for manipulating strings as a developer that require translations
[05:57] <lifeless> if you're patching at this level, I'd say the po file
[05:57] <lifeless> but consider mailing rosetta-users, or lp-users or ubuntu-devel or ubuntu-motu for clarification
[06:00] <ia> and another question - could anyone tell me, please, where i can find example snippets (on python and c will be more interesting), which sending crash information, even if crash haven't been occured? I'm talking about implementing "Report a Problem" menu item behavior. Of cource, i can use something like os.system('apport-gtk -f -p my_app'), but i think, that there is a little bit more elegant solution :-)
[06:03] <mpontillo> lifeless: thanks, will do... looking at a .po file, I see there are translation notes in "#" comments (starting with "Translators:", etc) above each line to be translated, and they match /* */ comments above each string. now, I imagine those are all auto-generated, so I wouldn't want to break that process. I'll look around a bit to see how this works...
[06:25] <mpontillo> ia: you could just do "apt-get source gedit", which has the "report a problem" menu item. looks like it calls out to /usr/share/gedit-2/gedit-bugreport, a script referenced by its .desktop.in.in file.
[07:03] <lifeless> TheMuso: I've gotten some time to poke more at my raid signature
[07:03] <lifeless> TheMuso: feedback solicited.
[09:09] <cjwatson> mpontillo: maintainers don't normally edit .po files by hand. See the gettext documentation, but normally you can just edit the original source and then some Makefile will take care of it ...
[09:10] <cjwatson> mpontillo: if you find you need to force it for some reason, then the command to update a .po file from newer source strings in a .pot file is 'msgmerge'
[09:10] <cjwatson> mpontillo: you definitely shouldn't go about marking strings as fuzzy by hand
[09:12] <cjwatson> infinity: artigas and sejong are both stuck building debian-installer, I think because silo.postinst is prompting
[09:25] <infinity> cjwatson: \o/
[09:26] <infinity> cjwatson: Words can't describe how awesome that is...
[09:28] <cjwatson> and yet silo has not changed
[09:29] <cjwatson> since, like, intrepid
[09:29] <cjwatson> oh well, not going to debug it today
[09:29] <infinity> The postinst unconditionally calls silo.conf if it's not an upgrade...
[09:29] <infinity> And I've never had silo installed in the chroots.
[09:29] <infinity> So...
[09:29] <infinity> I'm at a loss.
[09:32] <infinity> Setting up silo (1.4.13a+git20070930-1ubuntu1) ...
[09:32] <infinity> Non-interactive, skipping silo configuration.
[09:32] <infinity> And that's... Not happening anymore?
[09:37] <infinity> cjwatson: Entirely possible that the chroots got their debconf frontend mangled at some point.  Let me kill these off and investigate that theory.
[09:37] <infinity> cjwatson: If that seems to be the case, I'll upload fixed ones and retry the builds.
[09:39]  * infinity scratches his head.
[09:41] <infinity> cjwatson: This is kinda messed up.  Debconf is set correctly, and sbuild exports $ENV{'DEBIAN_FRONTEND'} = "noninteractive"
[09:43] <cjwatson> I don't know of any debconf changes that might break that ...
[09:44] <infinity> cjwatson: It's not a debconf issue.  Debconf isn't even running.
[09:44] <cjwatson> indeed debconf hasn't changed since jaunty anyway :)
[09:44] <infinity> cjwatson: /usr/sbin/siloconfig just checks $ENV{'DEBIAN_FRONTEND'
[09:44] <infinity> }
[09:44] <infinity> And sbuild hasn't changed in eons.
[09:44] <infinity> Grr.
[09:45] <infinity> Certainly not that part of it anyway.
[09:45] <cjwatson> indeed it can hardly be a distro change since intrepid-proposed is breaking too
[09:45] <infinity> Yeah.
[09:45] <infinity> And I assume intrepid-release worked.
[09:46] <infinity> I'm at a loss for it being a buildd change too, though, since they... Haven't changed since the last successful d-i build.
[09:46] <cjwatson> let's check, best not assume sparc worked
[09:46] <infinity> So utterly confused right now.
[09:46] <cjwatson> but yeah, https://edge.launchpad.net/ubuntu/+source/debian-installer/20080522ubuntu28/+build/888434
[09:47] <infinity> And an entirely unrelated failure in jaunty not that long ago.  But silo installed fine.
=== cjwatson changed the topic of #ubuntu-devel to: Archive: open for development! | Ubuntu 9.04 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
[09:50] <infinity> Hrm.  I bet I know what it is.
[09:50] <infinity> cjwatson: Upgraded the buildds from dapper to hardy in that timeframe.
[09:50] <infinity> cjwatson: I *bet* that sudo is no longer allowed the environment leak to the apt call.
[09:50] <infinity> s/allowed/allowing/
[09:55] <lifeless> random question, joining two pipes in shell, I've either forgotten how or its not as easy as it should be
[09:55] <lifeless> (I have to processes A and B, I want all the output from A and then all that from B, to be piped into C)
[09:58] <infinity> cjwatson: Testing a fix.
[09:59] <infinity> cjwatson: (I'm shocked this is the first we've seen of this, if this is what I think it is...)
[09:59] <infinity> cjwatson: Given that the x86 buildds have been hardy for two cycles now.
[10:00] <lifeless> bah, I'm silly. (A; B) | C
[10:01] <lifeless> bai
[10:05] <infinity> cjwatson: Fixed on artigas, cowboying on sejong.  Will commit to rocketfuel when I'm more awake.
[10:06] <infinity> cjwatson: Looks like sudo got a lot more strict about environment leak, and apparently NOTHING ACTUALLY CARED except for silo's postinst. :P
[10:12] <infinity> cjwatson: Of course, your karmic build failed anyway, but not my fault this time. :P
[10:16] <slangasek> so why is siloconfig not using debconf?
[10:17] <infinity> Don't know and don't care?
[10:17] <infinity> Though, I suppose that invoking debconf even just to check for the frontend is still saner than relying on magic environment.
[10:17] <infinity> But whatever.
[10:17] <infinity> Checking DEBIAN_FRONTEND in the environment isn't exactly unheard of. :P
[10:18] <infinity> Just odd that nothing else cared enough to break.
[10:18] <slangasek> sure - four years ago.  These days things are supposed to be using debconf, not just checking the variable. :)
[10:18] <slangasek> that's why nothing else broke :)
[10:19] <infinity> Oh, debconf got promoted to Required somewhere in the last century.  That does make the argument seem saner.
[10:20] <infinity> I'm still living in the distant past where debconf was something "extra" I installed in my chroots. :P
[10:20] <infinity> slangasek: If you want to fix silo, be my guest.  Since we still build for dapper, though, I'm going to keep my sbuild fix. :P
[10:20] <slangasek> no, I don't want to go anywhere near silo :)
[10:21] <infinity> No sense of adventure.
[10:21] <slangasek> I'm afraid I'll fall in and suffocate to death amid the grain
[10:21] <infinity> I find your pun unsatisfactory.
[10:21] <infinity> Perhaps you need sleep?
[10:22] <slangasek> perhaps
[10:23] <infinity> I was tempted to stay up until armel's gcc build was done, but I can just sort all that in the morning...
[10:23] <infinity> cjwatson: Please don't re-auto the armel buildds, even after GCC is in.  The current armel chroot has all sorts of mangling done to it, and I'm going to replace it with something saner in the morning.
[10:24] <infinity> cjwatson: And your intrepid-proposed/sparc debian-installer built happily.
[10:34] <cjwatson> infinity: impressively limited breakage. Thanks
[10:35] <infinity> cjwatson: Yeah, in spite of vorlon's explanation, I'm still surprised that nothing else has exploded due to the variable going poof.
[10:35] <infinity> cjwatson: But, whatever.  I'm happy it hasn't.
[10:36] <cjwatson> I'm not likely to reauto the armel buildds anyway - I'm away until end of Sunday
[10:36] <infinity> cjwatson: Works for me.
[10:37] <mdke> When a point release is issued, does the proper name for a particular release include the point version? So is hardy called 8.04.2 or 8.04?
[10:37] <mdke> the latter still, right?
[10:38] <infinity> mdke: Depends on which proper name you're looking at.
[10:38] <infinity> mdke: Check "lsb_release -a" on a hardy system, for instance.
[10:38] <infinity> Description:    Ubuntu 8.04.2
[10:38] <infinity> Release:        8.04
[10:39] <infinity> mdke: The former is the official name/version, which includes the .2
[10:39] <infinity> mdke: But the release version doesn't increment for the sake of sanity of any tools that might check against that number.
[10:39] <Amaranth> 8.04.2 sounds like it should have been released 2 April 2008 :P
[10:40] <mdke> I see that http://www.ubuntu.com/getubuntu/download uses 8.04
[10:40] <mdke> what I'm looking at is whether, and if so when, in the documentation we should update version numbers
[10:40] <infinity> mdke: In the docs?  Never, IMO.
[10:40] <mdke> in some cases it's essential, because links to isos are broken (the iso has .2 in the name)
[10:41] <infinity> mdke: Any links to download stuff end up symlinked with 8.04->8.04.$current anyway.
[10:41] <mdke> http://cdimage.ubuntu.com/jeos/releases/8.04/release/ubuntu-8.04-jeos-i386.iso doesn't
[10:41] <infinity> mdke: And do docs actually link directly to ISOs, rather than pages listing said ISOs?
[10:41] <mdke> in one place, I think, bug 371773
[10:41] <ubottu> Launchpad bug 371773 in ubuntu-docs "broken iso link on https://help.ubuntu.com/8.04/serverguide/C/jeos-initial-setup.html" [Medium,Triaged] https://launchpad.net/bugs/371773
[10:42] <cjwatson> the directory is symlinked but the ISO basename isn't
[10:42] <infinity> mdke: Yeah, I'd call that a bug in the way the docs are written, IMO...
[10:43] <mdke> perhaps linking to the directory is a better solution, even if it requires the user to do a bit more work
[10:43] <cjwatson> anyway, in general I think of 8.04 as the "series" and 8.04.2 as identifying a specific point
[10:43] <mdke> doing a SRU for the serverguide each time a point release is released is a bit of a pain, especially because it requires translators to redo that particular string too
[10:44] <mdke> or at least running sed over the translations
[10:45] <mdke> infinity: so you'd recommend simply pointing to the directory and telling the user to wget the relevant file from the directory?
[10:46] <infinity> mdke: As much as that's less hand-holdy, I'm seriously failing to see how someone who's expected to understand a CLI-based server with almost nothing installed (JeOS is very minimal) wouldn't be able to sort out an http directory listing.
[10:46] <mdke> yes, I don't think there is a risk that someone could get that wrong
[10:47] <infinity> Oh, there's always a risk.
[10:47] <mdke> heh
[10:47] <infinity> But, I'm in the "let them keep both halves" camp when it's not a desktop/simple use case.
[10:48] <mdke> ok. And it seems clear that generally in other cases, 8.04 should be used
[10:48] <mdke> as the generic name for the distribution
[10:48] <infinity> I see no reason to document 8.04.2 as a version number anywhere, except to name images, and in base-files, no.
[10:49] <infinity> It would be about as silly as the Apache section in the server-guide talking about apache_2.2.8-4ubuntu2, and needing an update on every security release.
[10:49] <infinity> (Well, not quite, but you get the absurdity reduction there, I guess)
[10:49] <mdke> not quite that silly, surely, but I get the point
[10:49] <mdke> :)
[10:50] <mdke> thanks for the assistanced
[10:50] <mdke> -d
=== jussi01 is now known as Tuhina
=== Tuhina is now known as jussi01
=== hunger_t is now known as hunger
[11:26] <popogomomo> one of ubuntu machines on network is throwing tons of dhcp inform packets making entire network slow
[11:26] <popogomomo> how to disable it
[11:27] <popogomomo> i have already disabled ip6 and sytem is using static address
[11:27] <popogomomo> why its throwinhg dhcp inform packets
[11:35] <popogomomo> how do i permanently disable dhcp in ubuntu
[11:35] <popogomomo> how do i permanently disable dhcp in ubuntu
[11:36] <popogomomo> its drwoning my network
[11:36] <Chipzz> popogomomo: wrong channel
[11:36] <popogomomo> i tried in ubuntu channel also
[11:36] <popogomomo> looks like a bug
[11:37] <Chipzz> not getting an answer in #ubuntu doesn't mean this is the place to ask; this is not an overflow channel for #ubuntu
[11:38] <Chipzz> and te fact that it "looks like a bug to you" doesn't make this the right channel either
[12:02] <popogomomo> is there any way stop ubuntu send dhcp infor packets ?
[12:02] <popogomomo> i have removed dhcp client
[12:22] <ia> hello. could anyone, point me, please, at python snippets, which sending crash information, even if crash haven't been occured? I'm talking about implementing "Report a Problem" menu item behavior. Of cource, i can use something like os.system('apport-gtk -f -p my_app'), but i think, that there is a little bit more elegant solution :-) results like this http://www.google.com/search?hl=en&newwindow=1&q=usage+python-apport tells me nothing, but i suppose, tha
[12:22] <ia> t for adding apport support i should write in my py file something like "import apport" and add calls of functions from apport python module, but how exactly i should do this? i will be very appreciate for any clues. and, probably, such information will be very useful for apport's ubuntu wiki page. and excuse me for annoying.
=== ember_ is now known as ember
[13:05] <popogomomo> why dont ububtu dev write utility in java rather slow and wiered python
[13:05] <popogomomo> python sucks
[13:06] <trip0> hmm... that's really subjective
[13:07] <trip0> as a developer who doesn't regularly use either, I can appreciate both
[13:08] <trip0> python syntax requires getting used to... especially if you are coming from a  c style language like java.
[13:09] <popogomomo> i find java more productive and easy
[13:09] <popogomomo> also much more easy to maintain
[13:10] <trip0> both are very productive, 4th gen languages.
[13:10] <trip0> depends on how much experience you have though
[13:11] <trip0> a VB.NET programmer may be more productive in VB than he would in java
[13:12] <popogomomo> quality of code and maintainability is always better in java .......................
[13:12] <popogomomo> also tools like IDE , frameworks impact productivity which is ample in java world
=== kev__ is now known as triple0
=== triple0 is now known as tripzero0
=== asac_ is now known as asac
[14:44] <jdstrand> slangasek, Riddell, kirkland, StevenK: syncbugbot still causing me problems. maybe launchpadbugs needs an update?
[14:45] <jdstrand> slangasek, Riddell, kirkland, StevenK: the problematic lines are:
[14:45] <jdstrand> b.comments.add(Bug.NewComment(text=''.join(output), subject=b.title))
[14:45] <jdstrand> task.set_status("Fix Released")
[14:46] <jdstrand> slangasek, Riddell, kirkland, StevenK: fyi, if you hit this I worked around it by commented those out and closing the bugs manually
[14:46] <jdstrand> slangasek, Riddell, kirkland, StevenK: the problematic lines are: well, I also commented out 'b.commit()' immediately after the above two lines, since there was nothing to commit
[14:47] <jdstrand> s/the problematic lines  are:
[14:47] <jdstrand> meh
[16:13] <kirkland> jdstrand: ah, i hit that too, on Wednesday, was asking about it
[16:14] <kirkland> jdstrand: i tried updating my launchpad cookie, as it was obviously a problem in the launchpad communications
[16:14] <kirkland> jdstrand: i gave up on syncbugbot, and just did the syncs manually
[16:14] <kirkland> jdstrand: and the bug closes
[16:15] <kirkland> jdstrand: i think it might be worth getting pitti  to have a look at it :-)
[16:27] <directhex> slangasek, are you here today? can you give me feedback on a preinst before i commit to git?
=== dwatson is now known as davewatson
[16:59] <jdstrand> kirkland: I think it may be a simple as updating python-launchpadbugs, but we'll see
=== jussi01 is now known as tuhina
[17:00] <kirkland> jdstrand: bdmurray is pretty good with python-launchpadbugs, as I understand it :-)
[17:01] <jdstrand> kirkland: I familiar with it too, the issue isn't the use of it, but rather plb itself is dying
[17:01] <jdstrand> I'm
[17:01] <jdstrand> kirkland: but, we can see on monday
[17:12] <calc> it looks like armel needs to be set back to auto
=== DktrKranz2 is now known as DktrKranz
[17:18] <Q-FUNK> I welcome suggestions for an appropriate package to reassign bug #374140 to. :)
[17:18] <ubottu> Launchpad bug 374140 in upgrade-system "on 8.04 success install cant upgrade to 8.10 because via/openchrome frezz screen" [Undecided,New] https://launchpad.net/bugs/374140
[17:22] <ash211> Q-FUNK: looks like a driver issue to me
[17:22] <ash211> ask the poster for the relevant info in https://wiki.ubuntu.com/X/Reporting
[17:22] <ash211> I think by "frezz" they mean "freeze" :)
[17:23] <Q-FUNK> yup, it indeed looks like one, but it was reported against the entirely wrong package
[17:23] <Q-FUNK> yup
[17:23] <ash211> it's understandable why it went against upgrade-system instead of any driver package
[17:23] <ash211> that's the program the person used right before it messed everything up
[17:24] <ash211> (oh nvm, that's the only bug reported against that package, so it must not do what I think it does)
=== azeem_ is now known as azeem
[17:29] <jdstrand> slangasek, Riddell, kirkland, StevenK, pitti: it just occurred to me that I have some launchpad api code I can steal/use to get syncbugbot working again-- I'll do that first thing on monday
[17:33] <Q-FUNK> ash211: people regurlary report whatever went wrong during an upgrade against package 'upgrade-system', when there instead should be a separate task to report failed upgrades against.
[17:33] <Q-FUNK> this is just one of many such occurences
[17:36] <Q-FUNK> I get a bunch of similar reportes every 6 months, whenever a new ubuntu release comes out - always against package 'upgrade-system'
[18:20] <a|wen> what is the status of libboost1.37 in karmic, can see that it is in main now ... is it okay to use, encouraged to use, or ?
[18:21] <james_w> encouraged
[18:23] <a|wen> okay, thx
[18:35] <calc> a|wen: we will hopefully get boost1.38 working as well to transition to for karmic
[18:36] <a|wen> calc: okay... you are the person to talk to for boost?
[18:44] <calc> a|wen: no, i just looked into it since OOo uses it also
[18:45] <calc> a|wen: debian wasn't to transition off of boost1.37 so it would be good once boost1.38 can actually build to switch to using it
[18:45] <a|wen> calc: okay ... thx for info :)
[18:46] <calc> a|wen: its probably failing to build for us due to using gcc 4.4
[18:46] <a|wen> calc: most likely ... boost 1.35 looks to be busted as well :(
[18:46] <calc> yea
[18:47] <calc> i had to switch OOo to use 1.37 which is why it is in main now
[18:47] <a|wen> calc: okay; then no wonder i can't make it due much
[18:47] <a|wen> do even
[18:48] <calc> they already released 1.39 upstream but still haven't apparently tested it against gcc 4.4 yet
[18:49] <a|wen> we'll see what happens; i'll switch to 1.37 for now as well then
[18:51] <calc> there is at least one patch in their bug tracker to fix gcc 4.4 issues
[18:51] <ScottK> That might be what 1.38 needs.
[18:52] <calc> hopefully the debian boost people package 1.39 soon then we could just jump to that after any needed gcc 4.4 fixups
[18:52] <calc> it was released a week ago
[18:53] <a|wen> 1.37 seems to work "okay" at least
[18:53] <calc> https://svn.boost.org/trac/boost/ticket/3008 <- gcc 4.4 bug i found
[18:54] <a|wen> calc: well, compared to 1.35 it is luxury ... this is the file failing for me on 1.35 http://pastebin.com/f44e80488 :(
[18:54] <calc> heh
[18:55] <LaserJock> ScottK: any chance of having 1.38 or so in -backports?
[18:56]  * calc thinks he knows a way to club OOo into building on i386/lpia
[18:57] <calc> i can just disable gcj entirely, heh :-\
[18:58] <highvoltage> hey LaserJock
[18:59] <LaserJock> highvoltage: hola
=== ScriptRipper_ is now known as ScriptRipper
=== hunger_t is now known as hunger
=== tuhina is now known as jussi01
[19:51] <kklimonda> what was called the utility which manipulates .diff files?
[20:06] <geser> in which way manipulate?
[20:07] <kklimonda> I have a big diff and I'd like to get part of it (only diff for .cc files to be exact)
[20:07] <geser> filterdiff
[20:07] <kklimonda> thanks
[20:47] <Draconicus> I have a small suggestion for the #ubuntu channel's management, and this is the only sane place I can think to present it.
[20:48] <Draconicus> Ever thought of splitting the channel up with freenode managing an automatic redirect based on a user cap?
[20:48] <Draconicus> Like #ubuntu1 #ubuntu2 and #ubuntu3 - you already have an overflow channel, but #ubuntu remains massively overpopulated and very difficult to work in. There are plenty of assistants to go around these days.
[20:49] <Draconicus> I'm sure I'm not the first to suggest this... Perhaps it's futile to try.
[20:56] <LaserJock> Draconicus: I think #ubuntu-irc might be a better place
[20:56] <Draconicus> Oho. Sorry. :P
[21:02] <Nafallo> LaserJock: #ubuntu isn't a loco channel, no :-)
[21:02] <Nafallo> LaserJock: #ubuntu-ops
[21:42] <slangasek> jdstrand: hrm, it's still not working for you?  works fine here - you know that you need a cookie for !edge, right?
[21:43] <slangasek> jdstrand: anyway, launchpadlib isn't really an option, you can't sanely run launchpadlib stuff remotely...
[22:02] <kklimonda> #ubuntu-irc will be a better place for this discussion
=== vorian is now known as heHATEme
=== edsoncanto is now known as ecanto
=== tkamppeter__ is now known as tkamppeter
=== kklimonda_ is now known as kklimonda