=== luciano_ is now known as virusuy
[03:58] <cdbs> BlackZ: did I mark the merge for myself?
[03:58] <cdbs> Okay, Lorenzo isn't here
[04:10] <kaushal> hi
[04:10] <kaushal> I have been updating local ubuntu mirror using debmirror since last saturday it has just reached 29%. is there a way to populate it quicker ?
[04:11] <micahg> kaushal: use a faster mirror?
[04:11] <kaushal> micahg: shall i pastebin the deb mirror script ?
[04:12] <micahg> kaushal: it's normal for things to be a little slow right after release
[04:12] <kaushal> ok
[04:13] <kaushal> It takes almost close to 10 days to get it populated whenever there is a new release
[04:13] <kaushal> Any workaround ?
[04:13] <kaushal> micahg: I am using in.archive.ubuntu.com
[04:14] <kaushal> server=in.archive.ubuntu.com
[04:14] <micahg> kaushal: that's in the canonical DC, a local mirror might be faster
[04:14] <kaushal> DC mean Data Center
[04:14] <micahg> yes
[04:14] <kaushal> local mirror ?
[04:15] <kaushal> not sure i understand that
[04:15] <micahg> kaushal: geo-local
[04:15] <kaushal> Mumbai, India
[04:16] <micahg> kaushal: https://launchpad.net/ubuntu/+archivemirrors
[04:18] <kaushal> https://launchpad.net/ubuntu/+mirror/ftp.iitb.ac.in-archive
[04:18] <kaushal> Last update unknown
[04:18] <kaushal> so what would be the server=...... value ?
[04:21] <kaushal> Net::FTP: Bad hostname 'ftp://ftp.iitb.ac.in/distributions/ubuntu/archives/'
[04:22] <kaushal> Net::FTP: Bad hostname 'ftp://ftp.iitb.ac.in'
[04:22] <micahg> kaushal: get rid of ftp://
[04:23]  * ScottK generally believes in that.
[04:23] <micahg> +1
[04:30] <kaushal> [0%] Getting: dists/hardy-security/Release... dists/hardy-security/Release failed 500 read timeout
[04:31] <kaushal> micahg: wierd
[04:33] <kaushal> micahg: Any clue ?
[04:33] <micahg> kaushal: nope, no idea
[04:33] <micahg> there's a new debmirror in unstable :)
[04:34] <kaushal> http://pastebin.ubuntu.com/602600/
[04:37] <micahg> kaushal: you need the rest of the path to the ubuntu repo
[04:37] <micahg> ftp.iitb.ac.in/distributions/ubuntu/archives/
[04:42] <kaushal> ok
[04:46] <kaushal> micahg: Thanks
[04:48] <kaushal> micahg: much appreciated
[04:48] <kaushal> always helpful
[04:48] <kaushal> :)
[04:48] <kaushal> I love it
=== yofel_ is now known as yofel
[08:52] <dupondje> Hi. Some small question about a merge. debdiff included should be from debian version vs ubuntu merged version? Or previous ubuntu version vs merged version?
[08:54] <tumbleweed> from the new debian version. From the previous ubuntu version too, if that's more readable.
[09:13] <geser> for me the Debian→Ubuntu debdiffs are easier to check as I can better see what delta is still there and if it matches the changelog entry
[09:44] <Rhonda> I wonder why bug #565182 never was forwarded to Debian   *sigh*
[09:44] <ubottu> Launchpad bug 565182 in Irssi "security regression: SSL CN check breaks IRC proxy" [Undecided,New] https://launchpad.net/bugs/565182
[09:45]  * Rhonda . o O ( and which the mentioned security update was )
[09:46] <Rhonda> Ah, found it
=== hannesw_ is now known as hannesw
[09:48] <Rhonda> Ah. Got considered as minor issues.
[10:38] <Rhonda> nigelb: can the upstream bug you added in bug #493048 get linked somehow?
[10:38] <ubottu> Launchpad bug 493048 in irssi (Ubuntu) "Tab-completion of channel names cannot be properly used with /join in irssi" [Low,Triaged] https://launchpad.net/bugs/493048
[10:38] <nigelb> Rhonda: no. that tracker doesn't work wwith LP :\
[10:51] <Rhonda> No flyspray support in LP?
[10:52] <Rhonda> It's not as if that would be such an uncommon bug tracker, to be honest …  *sigh*
[10:52] <Rhonda> It's even packaged for Ubuntu  :P
[10:53] <Rhonda> Erm, or not. what the, I thought it was
[10:53] <Rhonda> in dapper only, last time
[11:02] <nigelb> Yeah, I remember doing that a while back.
[11:06] <Laney> looks removed
[11:08] <Rhonda> is
[12:05] <G> is there a good guide for someone to look at regarding maintaining packages under Bazaar? (Merging, proposing bugfixes etc)
[12:15] <geser> G: try https://wiki.ubuntu.com/DistributedDevelopment/Documentation
[12:16] <G> geser: thanks
[12:16] <Rhonda> G: specificly, https://wiki.ubuntu.com/UbuntuDevelopment#Revision%20control%20%28Bazaar%29
[12:16] <Rhonda> And the links from there
[12:16] <G> Rhonda: thanks
[12:34] <Rhonda> Looking for backports ACKs for Bug #734731
[12:34] <ubottu> Launchpad bug 734731 in lucid-backports "Please backport irssi (0.8.15-2ubuntu1/main)" [Undecided,New] https://launchpad.net/bugs/734731
[12:34]  * Rhonda . o O ( also looking for endorsements for my PPU application: https://wiki.ubuntu.com/GerfriedFuchs/DeveloperApplication )
[12:46] <Rhonda> uhm …
[12:47] <Rhonda> Is launchpad having troubles with debbugs?
[12:47] <Rhonda> Actually I wonder why bug #511912 still does show up in my bug list, shouldn't it get hidden because it's set to wontfix?
[12:47] <ubottu> Launchpad bug 511912 in irssi (Debian) "Make a menu item for Irssi" [Unknown,New] https://launchpad.net/bugs/511912
=== Quintasan_ is now known as Quintasan
[12:48] <Rhonda> And why does it claim the debbugs number is invalid?
[12:51] <ScottK> Rhonda: re backports, commented in the bug.
[12:52]  * Rhonda . o O ( I need to make my matcher urxvt extension smarter so that bug numbers in here go to LP and not the Debian BTS … )
[12:54] <Rhonda> ScottK: -2 contains a fix for a crash. Actually, I just uploaded -3 to Debian which would even reduce the ubuntu diff (pulling two patches from it), and add another fix. :)
[12:54] <ScottK> Rhonda: Sounds like we should do an SRU for maverick and than backport that.
[12:55] <Rhonda> Right, the patch actually should be acceptable as SRU indeed.
[12:55] <ScottK> How about if we backport 1ubuntu1 from maverick to lucid now and then update the backport once the SRU is done?
[12:57] <Rhonda> Would work, yes. There are some fixes in 0.8.15 that people should be able to receive in an easy way.
[12:57] <ScottK> I'll mark up the bug and approve it then.
[12:58] <ScottK> Please ping me again after the SRU is in -updates and we'll do it again.
[12:59] <ScottK> Rhonda: It shows up in your bug list due to the Debian task being open.
[12:59] <Rhonda> Which it isn't, thus the question wether there are issues with debbugs.
[13:00] <Rhonda> But I think this has to be taken up to the launchpad people. What was the channel again?
[13:02] <ScottK> Rhonda: It's #launchpad.
[13:03] <dupondje> Hi, can somebody give his opinion on my patch in https://bugs.launchpad.net/ubuntu/+source/toonloop/+bug/775588
[13:03] <ubottu> Ubuntu bug 775588 in toonloop (Ubuntu) "Merge toonloop 2.0.6-1 (universe) from Debian unstable (main)" [Wishlist,New]
[13:17] <G> sorry, potentially silly question, merge includes a new patch to fix a FTBFS issue, if I commit while the new patch is 'quilt push'ed, then if I debcommit, then the changes the patch makes will be committed to the Ubuntu bzr branch,  (from my understanding) is this correct, or should the first commit of the new patch, be with it bzr pop'd back to the last previously commited patch
[13:20] <paultag> G: the commited files should be patched, otherwise it will complain
[13:20] <paultag> last I checked anyway
[13:20] <paultag> :)
[13:21] <tumbleweed> for source format 3.0, patches should be applied. For source format 1.0 + quilt, they shouldn't be
[13:21] <highvoltage> good morning
[13:21] <tumbleweed> highvoltage: hi
[13:21] <G> paultag: so : bzr diff -r tag:<lastdebiantag> should include the changes I made to the files for the patch, plus debian/patches/foo.patch
[13:22] <G> tumbleweed: okay, yep debian/source/format says 3.0
[13:22] <paultag> G: my bzr know-how is crap, I use git :)
[13:22] <G> so I commit both sets of changes
[13:22] <tumbleweed> G: that diff should include the current ubuntu delta
[13:22] <tumbleweed> nothing else
[13:22] <tumbleweed> (err and stuff in .pc)
[13:22] <highvoltage> tumbleweed: got my visa approved just in time, so at least I'll make it to uds this time :)
[13:22] <tumbleweed> highvoltage: well done :)
[13:24] <G> tumbleweed: the debdiff atm looks like: http://pastebin.com/PjMNQe6N
[13:26] <G> so I'm guessing that's what you mean abotu current ubuntu delta
[13:36] <tumbleweed> G: I'd revert all the po stuff, it isn't relevant
[13:36] <G> tumbleweed: yep, I'd been looking at that
[13:37] <G> tumbleweed: but as far as committing .pc/applied_patches, configure.in (modifications) etc, that is correct?
[13:42] <tumbleweed> G: yes it's ugly, but it's correct
[13:42] <tumbleweed> the po changes are probably just due to the package not cleaning properly
[13:43] <Laney> you can put unapply-patches in debian/source/local-options to not have them applied in the VCS
[13:46] <tumbleweed> Laney: I wouldn't want to do that in UDD. Part of the aim of UDD is uniformity.
[13:46] <dupondje> Can somebody give his opinion on my patch in https://bugs.launchpad.net/ubuntu/+source/toonloop/+bug/775588
[13:46] <ubottu> Ubuntu bug 775588 in toonloop (Ubuntu) "Merge toonloop 2.0.6-1 (universe) from Debian unstable (main)" [Wishlist,New]
[13:47] <G> tumbleweed: thanks for the help
[13:47] <G> tumbleweed: pushing my branch now :)
[13:47] <Laney> I would like to have it uniformly applied everywhere indeed
[13:47] <Laney> looms would be even better
[13:47] <tumbleweed> Laney: +1 to both of those
[13:47] <G> so, if I'm taking the UDD appreach, do I just do a merge proposal, and subscribe ubuntu-sponsors to one of the bugs that I'm fixing?
[13:48] <tumbleweed> G: no need to subscribe ubuntu-sponsors
[13:48] <tumbleweed> the merge proposal will be picked up by the sponsorship queue
[13:48] <G> oh just merge-proposal
[13:55] <G> tumbleweed: done, thanks
[13:56] <G> I take it the bugs should all be 'In Progress' too (does assignment matter, i.e. if they are assigned/unassigned etc?)
[14:02] <tumbleweed> G: when you are getting sponsorship via merge proposal, it doesn't matter. When using a bug with ubuntu-sponsors subscribed, it should be New/Confirmed, with no assignees.
[14:03] <tumbleweed> it doesn't matter too much, but the status may be used by anyone reviewing it, to make it clear that more work is required
[14:03] <G> tumbleweed: okay
[15:03] <udienz> G: hello
[15:04] <udienz> you can take zabbix merge, sorry for delay
[17:25] <stlsaint> hey would learning the packaging process thru using a chroot as build environment be good or would a live install server better?
[17:26] <stlsaint> hyperair: o/
[17:26] <hyperair> stlsaint: \o
[17:27] <stlsaint> hyperair: hey would learning the packaging process thru using a chroot as build environment be good or would a live install server better?
[17:28] <hyperair> stlsaint: i build my things in a chroot.
[17:28] <hyperair> stlsaint: something like pbuilder/cowbuilder or sbuild would be good.
[17:30] <stlsaint> hyperair: if i want to build for ubuntu would lubuntu server as a well environment
[17:30] <hyperair> stlsaint: at the core, ubuntu and lubuntu are no different.
[17:30] <hyperair> stlsaint: lubuntu is ubuntu with a different set of packages installed.
[17:31] <stlsaint> hyperair: yea thats what i understood as much, just wanting to make sure before i start off, thanks for the info
[17:31] <hyperair> np
[17:31] <hyperair> and good luck. =)
[17:31] <stlsaint> thanks mate
[17:32] <dupondje> Can somebody give his opinion on my patch in https://bugs.launchpad.net/ubuntu/+source/toonloop/+bug/775588
[17:32] <ubottu> Ubuntu bug 775588 in toonloop (Ubuntu) "Merge toonloop 2.0.6-1 (universe) from Debian unstable (main)" [Wishlist,New]
[17:46] <geser> dupondje: looks good (from a formal point, didn't check if your changes are correct but they look ok)
=== medberry is now known as med_out
[19:56] <dupondje> geser: thanks for checking
[20:04] <tumbleweed> dupondje: you can just subscribe sponsors, and somone will get to it soonish
[20:13] <Rhonda> huhm
[20:14] <Rhonda> where does the software center take the icons from?
[20:14] <Rhonda> Because I got a report that wesnoth doesn't has one in there.
[20:14] <highvoltage> from the cloud
[20:14] <highvoltage> (sorry just kidding)
[20:18] <Rhonda> *sigh* :)
=== med_out is now known as medberry
[20:29] <geser> Rhonda: hmm, an .xpm for wesnoth is included in app-install-data and the Icon entry in the .desktop file for wesnoth mentions it
[20:30] <quadrispro> hi guys
[20:30] <Rhonda> geser: .xpm? .png
[20:31] <geser> /usr/share/app-install/icons/wesnoth-1.8-icon.xpm and /usr/share/app-install/icons/wesnoth-1.8_editor-icon.xpm
[20:31] <Rhonda> grep Icon /usr/share/applications/wesnoth-1.8.desktop
[20:31] <Rhonda> Icon=wesnoth-1.8-icon
[20:31] <Rhonda> hmm
[20:31] <Rhonda> ah
[20:32] <Rhonda> so not /usr/share/icons/wesnoth-1.8-icon.png
[20:32] <Rhonda> But nevertheless, why isn't it displayed?
[20:32] <geser> the same Icon entry in /usr/share/app-install/desktop/wesnoth-1.8.desktop
[20:35] <Rhonda> geser: So you have no clue neither? :)
[20:35] <geser> no
[20:39] <geser> Rhonda: I tried editing /usr/share/app-install/desktop/wesnoth-1.8.desktop and appended ".xpm" to the Icon and after a "update-software-center" I have an icon visible
[20:41] <geser> but I don't understand why it's needed as the .desktop file for zsnes doesn't contain a file extension either and also only has a .xpm file and it works there
[20:51] <geser> Rhonda: might be the "." in the Icon name as renaming the icon to wesnoth-18-icon.xpm and updating the .desktop file (without adding an extension) works too
[20:58] <Rhonda> geser: Hmmmm
[20:58] <geser> Rhonda: might be bug 745942
[20:58] <ubottu> Launchpad bug 745942 in software-center (Ubuntu) "Icons not displayed for paid apps with a . in their package name" [Undecided,Confirmed] https://launchpad.net/bugs/745942
[20:58] <Rhonda> AH
[20:58] <Rhonda> Thanks for finding that one :)
[21:26] <c2tarun> need some help with the merge. there is a package atom4_4.1-4ubuntu1 in our archive, the change in it is included in its new debian version atom4_4.1-5. To check whether its a sync and not merge what should I check?
[21:30] <geser> c2tarun: test-build in oneiric
[21:31] <c2tarun> geser: can you help me in understanding this file a bit please http://paste.ubuntu.com/602971/
[21:31] <c2tarun> geser: I should keep the Maintainer as Ubuntu Developers?
[21:32] <geser> c2tarun: yes, keep Maintainer and XSBC-Original-Maintainer from the Ubuntu part and Build-Depends and Standards-Version from the Debian part
[21:33] <c2tarun> geser: got it :) just for confirmation, can you please check this control file http://paste.ubuntu.com/602972/
[21:33] <geser> this happens when a change couldn't get applied during a merge because the surrounding context changed
[21:34] <geser> looks good
[21:36] <geser> c2tarun: do you still have other changes left? because if the Maintainer change is the only one left -> sync instead of a merge
[21:37] <c2tarun> geser: the changes made in ubuntu version is included in the latest debian version. I can show you the patch files
[21:38] <c2tarun> geser: here is ubuntu1.patch file http://paste.ubuntu.com/602974/ and here is debian patch file http://paste.ubuntu.com/602975/
[21:39] <geser> as the Ubuntu delta is part of a bigger patch in Debian, this should be a sync
[21:39] <geser> if it builds in oneiric of course
[21:39] <c2tarun> geser: yeah, trying to build it on oneiric now.
[21:43] <c2tarun> geser: can you please look at this error http://paste.ubuntu.com/602978/
[21:45] <c2tarun> geser: it is due to upstream I guess. :/
[21:46] <geser> https://wiki.ubuntu.com/CompilerFlags#Ignoring%20return%20code%20of%20write%28%29
[21:56] <c2tarun> geser: this is the code fragment that is causing the problem http://paste.kde.org/49753/ according to document should I change it to http://paste.kde.org/49759/ ?
[21:57] <c2tarun> geser: well I should declare written as well. anything apart from that?
[22:02] <geser> c2tarun: "count" and "buf" need to be replaced with the proper values, you might need to set them before the do {} loops as you modify them inside the loops
[22:02] <geser> c2tarun: perhaps slangasek can help you a little bit on how to apply his template from the wiki page
[22:02]  * geser is going to bed
[22:03] <slangasek> my template?
[22:03] <c2tarun> slangasek: hey :) can you help me with this error?
[22:04] <slangasek> oh, did I write that?  hmm :)
[22:04] <geser> slangasek: https://wiki.ubuntu.com/CompilerFlags#Ignoring%20return%20code%20of%20write%28%29 contains thanks to you
[22:04] <slangasek> yeah, that rings a bell
[22:07] <c2tarun> slangasek: what changes should I make?
[22:12] <slangasek> c2tarun: cooking an untested patch now
[22:12] <c2tarun> slangasek: ok.
[22:21] <c2tarun> slangasek: ping
[22:22] <slangasek> c2tarun: see if this builds for you? http://paste.ubuntu.com/602994/
[22:23] <c2tarun> slangasek: one more help please, that package is not following any patching system, so should I introduce a patchsystem or I should simply apply and then generate a diff?
[22:24] <slangasek> c2tarun: there are existing changes to the upstream source, so I would just apply it directly
[22:28] <c2tarun> slangasek: its not building, here is the error log http://paste.ubuntu.com/602999/
[22:29] <slangasek> c2tarun: erm.  that's with the patch applied?
[22:29] <slangasek> well, the line number changed, so I guess so
[22:29] <slangasek> but that's strange, gcc is being even more picky than necessary
[22:30] <c2tarun> slangasek: yeah that is with the patch.
[22:31] <slangasek> sorry, I don't have more time to look at this right now; if you use that template from the wiki page (requires declaring a few more variables in advance), that will fix it reliably
[22:33] <c2tarun> slangasek: but I dont know what are those variables for?
[22:33] <c2tarun> slangasek: should I simply declare them and use them?
[22:33] <c2tarun> slangasek: and what should I mention in /* Handle error */ part?
[22:34] <slangasek> these are precisely the questions that I don't have time to look at just now, sorry... :)
[22:34] <slangasek> perhaps someone else is around who speaks C and has time to look at it
[22:35] <geser> c2tarun: you could try to assign the return value to a variable before checking the result with assert from slangasek's patch
[22:36] <geser> something like "ssize_t unused;", "unused = write(fd, &m.x, sizeof(m.x));", "assert(unused > 0);". perhaps that makes gcc happy
[22:36]  * c2tarun trying
[22:39] <c2tarun> geser: well against expectations it worked :)
[22:39] <c2tarun> wow...
[22:42] <c2tarun> geser: I guess this calls for a merge now?
[22:43] <geser> it's not a typical merge as we have no old Ubuntu delta to preserve but a new one, but yes you can call it "merge"