[06:33] <pitti> Good morning
[06:34] <pitti> cjwatson: I have to do some more systematic observation, but things like "dch" not updating the timestamp in changelog, or "uupdate" not creating a new entry, but changing the current one
[06:56] <dholbach> good morning
[07:01] <dholbach> https://wiki.ubuntu.com/Packaging/Training in #ubuntu-classroom now
[10:20] <MacSlow> apw, ping
[10:20] <apachelogger> pitti: bug 369733
[10:20] <MacSlow> apw, what do I have to do to recompile http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30-rc3 with intel-kms enabled?
[10:21] <MacSlow> apw, I want to use that under Karmic on a i965-based (intel GMA X3100) laptop
[10:21] <MacSlow> apw, thanks in advance
[10:42] <pitti> MacSlow: try https://help.ubuntu.com/community/Kernel/Compile
[10:43] <MacSlow> hey pitti, I'm already on that page thanks
[10:46] <thekorn> pitti: hi, does ubuntu-bug also have a switch to use staging.lp.net, like APPORT_STAGING for apport-collect?
[10:52] <pitti> thekorn: not right now, I'm afraid
[10:52] <pitti> thekorn: you can temporarily enable it by adding 'staging': '1' to /etc/apport/crashdb.conf's "ubuntu" section
[10:54] <thekorn> pitti: oh, this is cool, will try this, thanks
[11:33] <dpm> pitti: in which language pack are the Firefox translations? language-pack-*-base?
[11:42] <pitti> dpm: yes (not the gnome or kde ones)
[11:44] <dpm> pitti: ok, thanks
[12:52] <eythian> if there's a bug that renders a program useless, and the bug report includes patches and so forth, what's the best way of drawing the attention of someone who can do something about it?
[12:53] <pochu> eythian: subscribe ubuntu-{universe,main}-sponsors, I'd say, and/or ask in #ubuntu-bugs. What's the bug #?
[12:54] <eythian> pochu: #277926
[12:54] <pochu> bug 277926
[12:57] <eythian> pochu: so would that be suitable for subscribing -sponsors too, or does it need to be a debdiff or something?
[13:05] <pochu> eythian: some sponsors require a debdiff, but I think patches are ok too
[13:05] <eythian> pochu: OK, I'll add it and see. I'm sure if there's some interest then we'll at least get feedback.
[13:07] <liw> evand, yo? how do I test usb-creator from the source tree after I've made some modifications?
[13:09] <evand> liw: in trunk there's no way to do that -- you have to debuild; dpkg -i ../usb-creator* .  However, I have changes in another branch where I'm making some large modifications to usb-creator that fix that problem.
[13:09] <liw> evand, hmm... I just found bin/usb-creator
[13:10] <evand> indeed, if you already have it installed you could just add the source directory to your path, though changes to the glade file and scripts/install.py wont be picked up as it uses absolute paths to reference them.
[13:11] <liw> evand, no worries, my desktop machine is there to be trashed by vigorous experimentation :)
[13:11] <evand> heh
[13:13] <evand> I'm going to try to land these changes soon as you're not the first person to mention that they were working on modifications to the code and I don't want to step on the toes of anyone nice enough to make modifications.
[13:14] <liw> evand, just to confirm: usbcreator/backend.py, method copy_progress is what gets called to update the frontend's progress bar, and gtk_frontend.py method progress is where it actually happens for the gtk frontend, right?
[13:15] <evand> yes, at least as far as copy percentage goes.  Progress description updates happen elsewhere.
[13:17] <liw> hmm... whenever I'm mucking about with someone else's code, I start wishing Python had static typing
[13:18] <maxb> If someone's working on usb-creator they might like to take a look at the dd invocation used to create the persistence file
[13:18] <ogra> usb-creator uses dd ? i thought it was all python
[13:18] <maxb> It currently uses count=1 bs=hugenumber, which results in dd attempting to read the entire persistence file's size of /dev/zero into memory
[13:18] <maxb> which is....silly
[13:19] <evand> gah, I thought we fixed that ages ago.
[13:19]  * evand digs
[13:19] <maxb> Well, no the first bug was trying to use bs=1 count=hugenumber :-)
[13:19] <liw> that may be why the progress bar stops for a long while...
[13:19] <maxb> That resulted in literally millions of 1-byte read/writes
[13:19] <maxb> That apparently got fixed to this new and differently broken behaviour
[13:19] <evand> indeed
[13:20] <maxb> Whilst we're on the subject, what's the rationale for allowing you to specify the persistence file size to the granularity of the byte?
[13:20] <maxb> Surely integer numbers of megabytes would be amply expressive
[13:21] <evand> I thought I had made the latter the case already, but perhaps that change was lost.
[13:22] <evand> ah, you're right (quite obviously), the fix for 331327 just broke it in a different way.
[13:23] <evand> I'll push a proper fix that uses a proper block size to -updates.
[13:23] <evand> thanks for calling that to my attention, maxb
[13:23] <evand> err my attention to that
[13:23] <maxb> evand: Do you possibly know why the original change in 0.1.10 was made?
[13:24] <maxb> oops, * 0.1.11
[13:24] <liw> (that should obviously be documented in the bzr commit message ;-)
[13:25] <maxb>   * Internally represent the persistent file size in bytes for greater
[13:25] <maxb>     accuracy.
[13:25] <maxb> evand: Your change, apparently :-)
[13:26] <evand> oh, because at the time I as creating usb disks for the store and it wasn't using the maximum amount of space, but obviously it's silly to need that kind of granularity and really, it's fine if dd tries to write more than it can as that's the last operation in the install routine anyway.
[13:26] <evand> liw: I use debcommit, so in the changelog :)
[13:28] <maxb> "it's fine if dd tries to write more than it can as that's the last operation in the install routine anyway." ... but won't an error break it? And it's not the very last thing, mkfs still needs to run after dd
[13:28] <evand> no, it can ignore the error just fine
[13:29] <evand> a fair point about mkfs, but that will still succeed, assuming it ignores the error on dd
[13:29] <maxb> Is it really useful/correct to do so?
[13:29] <evand> hrm, an equally fair point :)
[13:29] <evand> perhaps I should not worry about the loss of a few bytes
[13:30] <maxb> Personally I'd be in favour of just forcing it to a granularity of 1MB and using that as the dd blocksize
[13:30] <maxb> i.e. just go back to intrepid's behaviour :-)
[13:30] <evand> heh, I agree
[13:30] <evand> will do
[13:30] <liw> me too
[13:31] <maxb> It could be advantageous to keep a few bytes spare on the usbstick anyway, to allow for fiddling with the syslinux files manually, etc.
[13:32] <maxb> Also this satisfies my obsessive-compulsive tendencies of struggling with the slider trying to get it to exactly the number I want :-)
[13:32] <evand> haha
[13:32]  * maxb --> lunch
[13:35] <liw> evand, see #333051 for a remaining time estimator
[13:40] <evand> thanks a bunch liw!
[14:31] <pitti> apw: FYI, I split apport into trunk (lp:apport) and ubuntu (lp:~ubuntu-core-dev/apport/ubuntu), so merge proposals should go to the latter
[14:31] <pitti> apw: (nevermind for the current one, just telling you which branch to work against)
[14:34] <geser> doko: as python-central renames site-packages to dist-packages for pyhton2.6, should we still keep ubuntu changes for the python2.6 transition in packages where dh_pycentral will fix it?
[14:37] <tkamppeter> pitti, hi
[14:37] <pitti> hi tkamppeter
[14:47] <doko> geser: will have a look tomorrow
[14:59] <lesshaste>  my X just spontaneously rebooted with this helpful backtrace (see end of log) http://pastebin.com/f373a4ba0
[15:02] <robertj> hello all, is there a way to tell if a package is a security update or not?
[15:02] <joaopinto> mvo, now that we have http redirect support on apt, are there any plans to adopt a solution like http://mirrorbrain.org ?
[15:03] <jdstrand> robertj: 'apt-cache search <pkg>' will tell you where it came from
[15:03] <jdstrand> oops
[15:03] <joaopinto> robertj, maybe apt-cache policy package , and checking the mirror
[15:03] <jdstrand> apt-cache policy <pkg>
[15:05] <robertj> hacking up an nrpe plugin to alert of security updates only
[15:05] <tkamppeter> In bug 364877, the reporter gets an immediate segfault when he runs /usr/lib/cups/filter/rastertogutenprint.5.2 simply on the command line. Apport does not get triggered automatically, probably because it is a released Jaunty. How can I get an apport crash report generated?
[15:05] <tkamppeter> pitti: ^^
[15:05] <mvo> joaopinto: not right now, also there is some launchpad support for this, there is also a mirorr method in apt that supports dynamic mirror spreading with the help of LP
[15:06] <tkamppeter> pitti, bug 364877
[15:10] <seb128> StevenK: still there?
[15:11] <StevenK> seb128: Ish
[15:11] <seb128> StevenK: are you the one who sent a long list of binaries to universe today?
[15:11] <StevenK> seb128: Yup
[15:11] <seb128> StevenK: why?
[15:12] <seb128> StevenK: you know that the queue default to universe right? ;-)
[15:12] <StevenK> seb128: I wasn't supposed to?
[15:12] <seb128> StevenK: and you sent libxcb binaries to universe which were in main and required by libcairo for example
[15:13] <seb128> StevenK: I guess that was an error for libxcb?
[15:13] <StevenK> Argh. Needs more careful checking of the output of the archive script
[15:13] <seb128> StevenK: ok good, I'm fixing now ;-)
[15:14] <lesshaste> how do I install debug symbols for X?
[15:15] <lesshaste> the backtrace is perhaps not as useful as I had hoped
[15:17] <geser> already tried apport-retrace?
[15:32] <lesshaste> geser: apport doesn't seem to work for me...maybe you could give me a hand getting it to do something please?
[15:33] <Riddell> mvo: are you planning to update dpkg to 1.15 any time soon?
[15:35] <lesshaste> nothing ever appears in /var/crash annoyingly
[15:36] <lesshaste>  cat /etc/default/apport
[15:36] <lesshaste> # set this to 0 to disable apport, or to 1 to enable it
[15:36] <lesshaste> enabled=1
[15:36] <lesshaste> I don't know what else to do?
[15:37] <cjwatson> Riddell: I am
[15:37] <cjwatson> Riddell: I'm waiting for 1.15.1
[15:37] <cjwatson> (as noted in my recent changelog)
[15:38] <cjwatson> Riddell: any particular reason you ask?
[15:38] <lesshaste> I notice https://wiki.ubuntu.com/Apport doesn't mention hardy at all!
[15:40] <Riddell> cjwatson: pkg-kde-tools conflicts with << 1.15 but I can look into how important that is
[15:41] <cjwatson> that's innovative given that Debian unstable doesn't have 1.15 yet!
[15:41] <cjwatson> it's experimental only
[15:42] <cjwatson> oh, you grabbed from experimental
[15:42] <cjwatson> pkgkde-symbolshelper does appear to need the newer code
[15:43] <cjwatson> can it wait until Tuesday when I'm back from holiday? I was hoping to spend some quality time with that merge since it's not at all straightforward but I am part-way into it
[15:44] <Riddell> cjwatson: I can disable the symbolshelper stuff for now
[15:51] <pitti> tkamppeter: for temporarily enabling it, use sudo force_start=1 /etc/init.d/apport start
[16:06] <radix> it's lovely that dput defaults to the ubuntu master archive when I accidentally type "dput foo.changes my-ppa" instead of "dput my-ppa foo.changes"
[16:07] <james_w> radix: you can set-up a new default
[16:07] <james_w> I set it to an unresolvable address so that I don't forget
[16:07] <james_w> but I agree that it's not really a good default for the tool to have
[16:08] <radix> james_w: cool, good to know, I'll do that
[16:09] <james_w> radix: see the end of https://wiki.ubuntu.com/DeveloperGuide/Uploading
[16:09] <james_w> you don't have to use "unspecified" if you want it to upload to your PPA by default or something
[16:10] <tkamppeter> pitti, hi
[16:10] <radix> I guess I'll do the SPECIFY.A.HOST thing, since I upload to a few PPAs
[16:10] <radix> james_w: thanks
[16:10] <james_w> np
[16:11] <pitti> good bye everyone, have a good weekend!
[16:11]  * pitti -> gone until Monday
[16:11] <radix> later pitti
[16:11] <radix> have fun
[16:22] <lesshaste> anyone able to give me a hand installing debug symbols for X?
[17:46] <Riddell> ubuntu-mir: quick look at bug 369918 appreciated, blocking KDE currently
[18:37]  * calc has 10 MIRs to write, ugh
[18:43] <calc> what's worse is these are 10 essentially duplicated packages due to upstream OOo braindamage
[18:44]  * directhex registers a blueprint
[18:44] <directhex> yays!
[18:46] <pochu> how can I debug complete system lockups? X hangs, I can restart it, and when rebooting there's nothing special in dmesg, syslog, kern.log or Xorg.0.log.old
[18:46] <pochu> when it hangs I can't even ssh the machine
[18:46] <hyperair> serial port
[18:47] <hyperair> wait a sec, you can restart X?
[18:48] <pochu> nope
[18:48] <pochu> and there's no serial port
[18:48] <pochu> brand new dell mini 12 :)
[18:48] <pochu> s/can/can't/, bah
[18:48] <pochu> I can't even switch to a tty
[18:49] <ScottK> pochu: You dont happen to have the alarm-clock applet installed do you?
[18:50] <pochu> unless it came installed by default, no
[18:50]  * pochu checks
[18:50] <ScottK> No, it's in Universe.
[18:51] <pochu> yeah, just checked, it's not installed
[18:52] <pochu> this will be a great opportunity to learn how to debug kernel/X lockups, I guess
[18:52]  * pochu tries to be possitive ;)
[18:52] <hyperair> pochu: i think the only real way is serial port
[18:52] <hyperair> pochu: besides um.. firewire?
[18:52] <hyperair> or some other thing getty can work on
[18:56] <pochu> hyperair: it has usb, vga and ethernet :P
[18:56] <pochu> might be bug 301513
[18:56] <pochu> it mentions disabling bluetooth as a workaround
[18:56] <hyperair> then i think it's pretty much impossible to debug
[18:56] <hyperair> it's not a panic is it?
[18:56] <hyperair> it's a hard lock
[18:57] <hyperair> how about UML
[18:57] <hyperair> lol
[18:57] <pochu> if it was a panic I'd see a console with the message, right?
[18:58] <directhex> pitti, if you get a moment, can you take a look at my blueprint for adding dh_clistrip support to pkg-create-dbgsym?
[19:01] <ScottK> directhex: He's away until Monday
[19:02] <directhex> scottK, oh, fair enough. post-release holiday?
[19:14] <pochu> yeah, it's surviving after disabling bluetooth and wifi
[19:15] <pochu> I hope it's not the wifi! :)
[19:16] <pochu> directhex: I guess it's because of this: http://en.wikipedia.org/wiki/International_Workers%27_Day
[19:16] <directhex> oh, yes
[19:24] <pochu> oh noes, it's the wifi
[19:26] <calc> pitti: ping
[19:52] <RainCT> sladen: Hi. I'm working on merging zsync, and there's a chan ge which overrides a guess_gzip_options function to always return "--best". Is that from you? (And if yes, any info on why that's desirable so that I can write it into the changelog?) :)
[19:54] <RainCT> ah.. perhaps because with the offset option there's may be no header to check for the used encoding?
[19:55] <sladen> RainCT: wow.  I haven't touched that for at least a couple of years
[19:55] <RainCT> :)
[19:56] <sladen> RainCT: yeah, so the offset option was added to allow diving directly into a .deb file
[19:57] <sladen> RainCT: when DNS next works for a few seconds, I'll try to have a look at the diff
[19:57] <sladen> I should so have another go and making this work sanely, Fedora are coming out with something
[19:57] <RainCT> sladen: http://paste.ubuntu.com/161635/
[19:59] <RainCT> (also, 208.67.222.222, 208.67.220.220 for OpenDNS ;))
[20:03] <sladen> RainCT: those patches were probably for the semi-private tree that was being hacked on to make apt-sync work
[20:04] <sladen> RainCT: and then which got applied anyway.   --best was probably also added because that is what debian-policy mandates
[20:11] <RainCT> sladen: ok, thanks for the info :)
[20:39] <calc> anyone around doing syncs? i have a batch for OOo 3.1.0
[20:40] <calc> 369937, 369959, 369960, 369961, 369963, 369966, 369968, 369971, 369972, 369974, 369981
[20:41] <calc> the first one is a sync that was a merge, the rest are from experimental so won't happen automatically
[21:19] <ebroder> Wow...that's retarded. erlang-base in Jaunty conflicts with erlang-doc-html because the docs update wasn't uploaded until after DIF
[21:20] <ebroder> What are my chances of getting the current erlang-doc-html in lenny/sid synced into Jaunty as an SRU? Should I get an SRU for erlang tearing out that conflict instead?
[21:45] <sladen> RainCT: I'd leave it in for the moment, but note that it was related to apt-sync work in 2006/2007 and may need reviewing at some point
[21:46] <apw> pitti, ack didn't notice there was two, i think the default is wrong possibly in launchpad
[22:02] <mbana> any I the only one who doesn't like the new notifications in ubuntu?
[22:02] <mbana> can i switch back to the old one
[22:02] <directhex> yeah, change some package for another. i forget the specifics
[22:03] <StevenK> Install notification-daemon rather than notify-osd
[22:10] <Laney> I thought it was gnome-strat<something>-session. Or does that do more?
[22:15] <jdong> Laney: that reverts to as close of a standard upstream gnome session as possible.
[22:15] <Laney> what other changes are there?
[22:15] <Laney> fusa I guess
[22:15] <jdong> Laney: update notifier, ...
[22:15] <Laney> alright
[22:16] <jdong> various things that I find useful but Gentoo users look upon with scornful disdain :)
[22:16] <jdong> I think that's a good summary
[23:25] <pace_t_zulu> can someone help me with building gnome-panel for the purposes of testing a patch for bug #36189
[23:26] <pace_t_zulu> please?
[23:30] <Ampelbein> pace_t_zulu: where are you stuck at?
[23:30] <pace_t_zulu> hi Ampelbein
[23:31] <pace_t_zulu> so i downloaded the gnome panel source w/   "apt-get source gnome-panel"
[23:31] <pace_t_zulu> and i modified a single file
[23:32] <pace_t_zulu> and i got the packaging files w/ "bzr get http://code.launchpad.net/~ubuntu-desktop/gnome-panel/ubuntu"
[23:33] <pace_t_zulu> are the packaging files necessary to building and testing?
[23:33] <pace_t_zulu> do they contain ubuntu-specific info not found in the source code i retrieved w/ apt-get source?
[23:34] <Ampelbein> pace_t_zulu: no, they are used for the official packaging in ubuntu.
[23:34] <pace_t_zulu> ok
[23:34] <Ampelbein> it's basically just the debian/ directory
[23:34] <pace_t_zulu> so i need to debootstrap to chroot for testing?
[23:34] <pace_t_zulu> yes, i see that
[23:35] <Ampelbein> best is to use pbuilder
[23:36] <Ampelbein> https://wiki.ubuntu.com/PbuilderHowto
[23:37] <Ampelbein> pace_t_zulu: btw: gnome-panel uses quilt to manage patches
[23:38] <Ampelbein> https://wiki.ubuntu.com/PackagingGuide/Howtos/Quilt
[23:38] <pace_t_zulu> thank you... i was just about to ask
[23:42] <pace_t_zulu> Ampelbein:  so this pbuilder thing can take a while to setup and configure?
[23:43] <Ampelbein> yeah
[23:58] <pace_t_zulu> Ampelbein:  do you know where the gboolean type is defined?