[03:31] <pitti> Good morning
[05:47] <cc11rocks> I know Java, and am sorta learning HTML and Scala (learning it through learning the Play! Framework). Can my programming skills be used to help Ubuntu's bugs?
[05:49] <ailo> infinity: Hi, we at Ubuntu Studio would like to fix bug #1029685, by merging jackd2 from debian.
[05:56] <TheMuso> ailo: Has anybody done the merge yet, or would you like it done?
[05:57] <cc11rocks> Will anyone answer my question? I believe I could possibly be of help to the dev. team
[06:02] <spm> cc11rocks: in general terms, if you find a bug that interests you to fix, go for it. submit a merge proposal/patch and go find the next one. rinse and repeat.
[06:03] <cc11rocks> spm : I want to know how to get started. I just found https://wiki.ubuntu.com/UbuntuDevelopment/GettingSetUp and https://wiki.ubuntu.com/Bugs/HowToFix
[06:03] <cc11rocks> I have to look through the code for the problem area(s) myself,or is that done for me?
[06:04] <cc11rocks> And most of it is in C, C++, JS, or what?
[06:04] <spm> it depends on whatever the package in question was written in. all the above and then some, would be the answer.
[06:06] <spm> https://wiki.ubuntu.com/MOTU/Contact may be of value to help; if you're looking at fixing packages
[06:06] <ScottK> A lot of it depends on self motivation.
[06:07] <cc11rocks> Okay, thanks
[06:07] <ScottK> People are glad to help and answer questions, but a lot of us are volunteers who don't have a whole lot of spare time for this either.
[06:07] <cc11rocks> if I have issues/troubles, you guys will help me or no?
[06:07] <ScottK> People will help you.
[06:08] <ScottK> If you're trying to contribute, people will see that an help.
[06:08] <cc11rocks> Okay, thanks. I'm a HS student (4th year into computing, 1.5~2 years into programming, 6 month 100% reliant on GNU/Linux)
[06:09] <cc11rocks> But I'm busy too. Taking many college classes and I have a job. No clue how much I'll be able to help out
[06:09] <SpamapS> interesting.. Chrome 21.0.1180.57-r14 crashes sporadically when trying to upload images to my blog
[06:09] <ScottK> Every little bit heps and everyone has to start somewhere.
[06:10] <ScottK> heps/helps
[06:10] <cc11rocks> Okay, thank you :)
[06:11] <ailo> TheMuso: Don't think it's done yet, but yes, would like to have it done :).
[06:12] <infinity> ailo: Looks like a simple enough merge.
[06:13] <ailo> infinity: Yep
[06:13] <infinity> ailo: I'll just knock that off right now.
[06:13] <ailo> Great
[06:14] <TheMuso> ailo: I can take care of it, I try and keep an eye on jack at least, because its somewhat a part of the alsa/pulse/general audio stack.
[06:14] <infinity> TheMuso: Too late, but you can take the next one. :P
[06:14] <TheMuso> infinity: Thanks.
[06:19]  * infinity fixed up his previous patch to be more upstreamable while he's at it.
[11:04] <cjwatson> janimo: Any particular reason ubuntu-archive is subscribed to bug 1025716, bug 1025719, and bug 1025720?  There seems to be no clear action for us to take on those, and when there are packages to review they'll show up in the NEW queue - we don't need to be subscribed to bugs for those
[13:20] <seb128> slangasek, hey
[13:21] <seb128> slangasek, I'm updating freetype, how do you make the orig tarball? just copy the 3 upstream .bz2 in a freetype-<version> dir and tar czf that?
[13:22] <tumbleweed> I thought tarball-in-tarball was dying out :(
[13:51] <ogra_> cjwatson, dingaling
[13:52] <ogra_> cjwatson, we're fiddling with arm preseeding over here in lex., is there a way to make partman not show the waring about not being able to install to the install media ?
[13:53] <ogra_> oh, seems we just found it ... (priority=critical) nevermind
[14:13] <kwoot> can somebody please tell me how the gtk-bookmarks file is generated/copied upon first login so I can customize my roll-out. A link or pointer works too :-)
[14:16] <kwoot> anyone? please?
[14:49] <janimo> cjwatson, sorry I probably meant to subscribe the SRU team not the archive admins on those bugs and also knew that NEW is handled by archive and slipped
[14:52] <cjwatson> janimo: shall I flip the subscription over to ubuntu-sru on all three, then?
[14:53] <janimo> cjohnston, they are known about by slangasek and infinity so probably just unsubscribing archive is enough
[14:53] <janimo> steve has been reviewing them
[14:54] <cjwatson> Hm, I'll unsubscribe archive then, but I'd prefer not to assume that any one sru team member is on the hook
[14:55] <cjwatson> So if it's supposed to be an sru team thing then I think I should subscribe sru
[15:03] <ogasawara> @pilot in
[15:48] <smoser> if i have a file "raw-disk.img.tar.gz" which is basically 'dd if=/dev/sda of=raw-disk.img && tar -Sczf raw-disk.img.tar.gz raw-disk.img'
[15:48] <smoser> what woudl be the fastest way to get that back onto the disk.
[15:49] <smoser> tar -xvzf raw-disk.img.tar.gz --to-stdout | sudo dd bs=1M of=/dev/vda
[15:49] <smoser> that works, but slow.
[15:51] <smoser> as it is writing all the zeros that were sparsed.
[15:53] <smoser> i know that alexbligh knows this
[15:53] <smoser> and is probably laughing at me for finally wanting to do it.
[15:57] <ogra_> smoser, in any case increase the blocksize to something more sane (4M or so at least)
[15:57] <smoser> well, yeah, but even then, its just a lot of zeros
[15:58] <stgraber> 1~/win 61
[15:58] <stgraber> oops
[16:01] <slangasek> seb128: there's a 'get-orig-source' target in debian/rules that you can use, passing ver= to specify the upstream version
[16:01] <slangasek> seb128: but why is it urgent to update freetype?
[16:03] <seb128> slangasek, it's not urgent but I got the merge done and it's ready to upload
[16:04] <seb128> slangasek, I though it would help, it seems foundation is having an hard time to keep up with merges on Debian and updates...
[16:04] <seb128> slangasek, is that reason why quantal should be behind Debian testing in versions?
[16:13] <slangasek> seb128: behind testing, no, but you were asking about new upstream versions of freetype and that's what I was trying to understand
[16:14] <slangasek> seb128: you're TIL on the freetype package in quantal so I'm happy for you to do the Debian merge... if you're going beyond that I'd like to know why (not to veto it, but to understand what's happening)
[16:15] <seb128> slangasek, well, we had 2.4.8, Debian has 2.4.9, upstream is 2.4.10, I figured that if I updated it I could as well go to the current version
[16:16] <seb128> slangasek, what's is happening? nothing special, I just don't get why we wouldn't update to the current stable, we do keep up with current versions for most sources, is that one any special?
[16:18] <slangasek> seb128: well, you may recall from past discussions that freetype upstream releases do not have a good success rate at being regression-free ;)  but as I said, I'm not trying to veto anything here, just understand the reasons
[16:18] <seb128> slangasek, we (desktop) also started to push our "use the current versions when it makes sense (i.e when the new versions seem to be an improvement or fixes quite some issues)"
[16:18] <seb128> slangasek, http://people.canonical.com/~platform/desktop/versions.html has lot of red ;-) (that's our outdated sources for components on the CD)
[16:19] <slangasek> right, is that why the plymouth bug keeps getting pings :)
[16:21] <seb128> slangasek, right, robert_ancell has a strong opinion that we should actively maintain the packages we have on the CD, at least by keeping up with upstream updates when possible, he convinced me should do some efforts in this direction (though I would stay away from easy to break and hard to test stuff like plymouth)
[16:22] <slangasek> yes, there's no way in hell I intend for us to tackle another plymouth merge this late in the cycle because we have no way to regression-test and nobody has pointed me to anything it's known to fix for us
[16:23] <cjwatson> at least some of the Debian versions on that page are in experimental only ...
[16:23] <cjwatson> (some for extremely good reasons, e.g. perl)
[16:24] <seb128> cjwatson, right, currently Debian is a bit difficult to track with the freeze, some maintainer use experimental for things they would usually upload to unstable
[16:24] <cjwatson> but some are very deliberate :)
[16:24] <seb128> the page is just an indicator in any case, it shows up things we might not notice otherwise
[16:24] <seb128> it's not a "must update everything showing up there"
[16:25] <seb128> ideally we would have an easy way to add comments and all lines should be green or have a rational of why we prefer to not update
[16:26] <seb128> well at least that's what we aim at for http://people.canonical.com/~platform/desktop/desktop.html (the desktop set)
[16:27] <ScottK> MoM has comments, although it doesn't look at Experimental.
[16:28] <jdstrand> seb128: fyi, seems there is a bug in the script: libxml2 is up to date, yet it is yellow
[16:28] <seb128> ScottK, it doesn't look at upstream versions either I think?
[16:28] <jdstrand> seb128: oh, actually I lied
[16:28] <seb128> jdstrand, ;-)
[16:29] <ScottK> seb128: True, just Debian.
[16:29] <jdstrand> seb128: I didn't notice we were behind Debian. nm! :)
[16:30] <seb128> jdstrand, in fact the revision we are behind fixes a CVE
[16:30] <seb128> http://packages.qa.debian.org/libx/libxml2/news/20120722T130328Z.html
[16:30] <seb128>    * Fix entities local buffers size problems
[16:30] <seb128>    CVE-2012-2807, Closes: #679280.
[16:30] <seb128> we should maybe merge it ;-)
[16:32] <seb128> jdstrand, in fact we can sync it, let me build and check it works fine and do that
[16:33] <Chipzz> smoser: why did you use a tar archive in the first place? plain gzip/bzip2 would have done fine too
[16:36] <slangasek> Chipzz: because there's no such thing as a sparse gzip file
[16:37] <Chipzz> slangasek: oh, does tar know about sparse files then? didn't know
[16:37] <slangasek> yes
[16:37] <Chipzz> slangasek: but does dd produce sparse files?
[16:37] <slangasek> no
[16:38] <Chipzz> then there's no point regardless (assuming he used dd to create the image)
[16:38] <slangasek> but it's still useful to ensure that the img, if unpacked, doesn't take forever writing zeroes
[16:38] <slangasek> he didn't
[16:38] <slangasek> oh, in this case maybe he did :)
[16:38] <slangasek> (I was assuming this was an official cloud image, which is *not* created with dd)
[16:39] <Chipzz> mkisofs etc would create sparse files?
[16:39] <slangasek> but yeah, there's no good way to bypass the extraction of zeroes when it comes time to write it to a disk or any other sort of stream-based operation
[16:40] <slangasek> cloud images aren't ISOs
[16:40] <Chipzz> just shows how little I know :)
[16:40] <utlemming> Chipzz: take a look at cloud-images.ubuntu.com
[16:40] <utlemming> Chipzz: they are published as qcow2 or tar.gz files generally
[16:43] <Chipzz> bit disappointing gzip doesn't know about sparse files
[16:44] <Chipzz> but I suppose since it's been around that long, it's hard to extend the format
[16:44] <Guest6741> :q
[16:44] <slangasek> it's not disappointing at all
[16:44] <slangasek> gzip is the wrong tool
[16:44] <slangasek> gzip handles streams, not files
[16:45] <Chipzz> bzip2 handles files if I'm not mistaken though (in the sense that bzip2 archives can be seeked)
[16:47] <Chipzz> utlemming: but that doesn't say how they're created though
[16:47] <slangasek> smoser: to your original question, I can't see any way to speed up the copy; you would need tools that were aware of the actual structure of the data in order to skip the sparse sections, which would mean writing a custom tool just for extracting
[16:47] <utlemming> Cipzz: what do you mean by created? we use live-build to build them
[16:49] <Chipzz> how the contents of the disk image were put into a file. but I'm reading up on the qcow format now
[16:51] <utlemming> Chipzz: we build the images using sparse raw file as a loop device. From there, we put a filesystem on it, and then use live-build to populate it.
[16:52] <utlemming> Chipzz: after that, we convert the sparse raw file to a qcow2 container
[16:52] <Chipzz> I see :)
[16:52] <smoser> slangasek, right. and you need to know if the zeros that are in the sparse are necessary to data
[16:53] <smoser> because skipping writing to a device is going to mean reading that block later will give whatever garbage was there.
[16:53] <smoser> so yeah, i dont see a really easy way.
[16:53] <slangasek> smoser: that would be an interesting assumption on the part of some other software if so, since the sparse regions are by definition uninitialized
[16:53] <smoser> slangasek, clearly not.
[16:53] <smoser> there exist zeros in your files.
[16:53] <slangasek> no... there exist uninitialized regions, which are represented as zeroes when read, by convention :-)
[16:53] <smoser> and if i just ignore all zeros when i copy, and then skip them (leaving whatever was there) when i write, you've lost data.
[16:54] <slangasek> if you *write* zeroes to a sparse region, it immediately ceases to be sparse
[16:54] <slangasek> anyway, the conclusion stands - no shortcuts available sorry :)
[18:46] <MrDHat> If i develop an app using Qt on Fedora will it work on Ubuntu?
[19:07] <ScottK> It should.
[19:15] <MrDHat> Do these distro have any specific api's?
[19:17] <ScottK> In general if you use the standard Qt APIs it should be supportable ~everywhere.
[19:18] <ScottK> Distros may add things, but it's generally better to develop portable code and only worry about O/S or distro specific stuff as a last resort.
[19:27] <ogra_> hggdh, https://code.launchpad.net/~ogra/+junk/bamboo-feeder
[19:32] <scientes> xubuntu-desktop depends nvidia-common WTF is this shit!
[19:35] <infinity> scientes: That was very constructive feedback.
[19:36] <scientes> sry
[19:36] <scientes> its circular with nvidia-installer-cleanup
[19:37] <scientes> and its conflicts with nvidia-common
[19:48] <micahg> scientes: that's been fixed for quantal
[19:48] <micahg> scientes: err...the nvidia depends has been removed I mea
[19:48] <micahg> *mean
[19:53] <scientes> ok, thanks
[19:54] <scientes> i just didn't install that, via manual tweaking in aptitude
[20:05] <Sarvatt> scientes: installing debian nvidia blob packages on ubuntu is a recipe for disaster, the packages are extremely different (nvidia-installer-cleanup isn't in ubuntu..)
[20:06] <scientes> Sarvatt, nvidia broke on my hardware shortly before precise, so i have to make sure not to install it
[20:07] <scientes> (the ubuntu way)
[21:47] <infinity> Oh look, something is trying to pull half of KDE into main again...
[21:48] <ogra_> that will make the kde'ers happy :)
[21:48] <infinity> Looks like appmenu-qt grew a ton of KDE build-deps.
[21:51] <micahg> Debian had some extra build dependencies that we didn't have
[21:51] <infinity> "some"
[21:51] <micahg> maybe they're spurious
[21:52] <debfx> that package shouldn't have been synced anyway
[21:52] <infinity> Blame seb.
[21:52] <infinity> Who isn't around for me to yell at. :P
[21:54] <micahg> right, it undoes what was done in oneiric to prevent it from pulling in Qt
[21:54] <infinity> Given that the only meaningful diff is in the changelog and debian/control, I assume just reducing the build-deps again will fix it.
[21:55] <micahg> infinity: I think you have to add back the shlibs override stuff to get the desired effect
[21:55] <infinity> Oh, and yes, the odd abuse of dpkg-shlibdeps.
[21:55] <infinity> micahg: Well, two different desired effects.
[21:55] <infinity> micahg: One is about pulling QT or not, the other is about pulling KDE into main.
[21:56] <micahg> the "abuse" is documented :)
[21:56] <infinity> micahg: The QT thing is obsolete, I think.
[21:56] <infinity> micahg: In that we used to not have QT in the desktop tasks, but now it's in all of them.
[21:56] <micahg> Xubuntu doesn't have it
[21:57] <infinity> (At least, all of the ones that also have appmenu-qt)
[21:57] <infinity> micahg: See above. :P
[21:57] <ogra_> well, once we drop unity-2d it will be gone again :P
[21:57] <scientes> ^
[21:57] <ogra_> (not that i have seen *any* llvmpipe tests yet)
[21:58] <micahg> ogra_: no, U1
[21:58] <ogra_> oh, U1 pulls in Qt ?
[21:58] <infinity> Yeahp.
[21:58] <micahg> ogra_: it's written in it now :P
[21:58] <ogra_> oh, right because they relied on the fact that its there because of unity-2d
[21:58]  * ogra_ remembers the discussion in orlando
[21:59] <infinity> I have no issues with QT being on many/most of the desktops anyway.
[21:59] <infinity> It's just the KDE migration mess here that's annoying.
[21:59] <infinity> So, if all those build-deps are unnecessary, that's an easy fix.
[21:59]  * infinity will play.
[21:59] <micahg> well, if they're really unnecessary, they should be dropped in Debian as well...
[21:59] <debfx> yes, they are unused
[21:59] <debfx> I'll fix it in Debian
[22:00] <infinity> debfx: Oh, lovely.
[22:00] <infinity> debfx: That would be kdelibs-bin, kdelibs5-dev, and kde-workspace-dev?
[22:01] <infinity> debfx: (Although, the libx ones may be unnecessary too)
[22:02] <infinity> I think that's the first time I've used pitti's SVG rendering of component-mismatches instead of the text version.
[22:02] <infinity> It really does a good job of assigning blame. :P
[22:04] <debfx> yes, the ones we had in the Ubuntu package - qt4-qmake are enough
[22:05] <infinity> debfx: Are you going to be uploading that to Debian nowish, so we can sync later?
[22:05] <infinity> (If not, I'll temporarily fix it in Ubuntu, and we can sync over it when you fix it in Debian)
[22:10] <debfx> better to fix it in Ubuntu first
[22:10] <infinity> debfx: Alright, will do right now.
[22:14] <infinity> debfx: For bonus points, I'll test this in a sid sbuild to make sure it's not somehow broken on Debian, and you can just copy the diff wholesale.
[22:14] <debfx> hm the package also needs some build flags love
[22:18]  * ogra_ grumbles in xnox' direction ... seems our pandas suddenly go into an endless loop trying to configure raid
[22:18] <ogra_> and funnily there isnt even a "go back" option as d-i usually has
[22:19] <slangasek> using which installer?
[22:19] <ogra_> d-i
[22:19] <ogra_> the screen just has yes and no ...
[22:19] <ogra_> selecting no gets the same screen back up ...
[22:20] <ogra_> and we're not brave enough to try "yes" :P
[22:20] <slangasek> quantal?
[22:20] <ogra_> yup
[22:20] <infinity> debfx: Uploaded to Ubuntu, and it's all good on sid too, with this diff: http://paste.ubuntu.com/1127941/
[22:20] <slangasek> what's the exact wording?
[22:21] <ogra_> hehe, sweet ...
[22:21] <hggdh> here it is: http://pastebin.ubuntu.com/1127944/
[22:21] <ogra_> paste coming
[22:21]  * ogra_ loves our new setup here 
[22:21] <hggdh> paste above :-)
[22:22] <slangasek> why are you afraid to choose "Yes"? :)
[22:22] <infinity> Well, "yes" seems to imply they're then going to configure some RAID, which they may not have wanted.
[22:23] <infinity> Seems like some odd flowcharting.
[22:23] <slangasek> I don't know how they got to this prompt
[22:23] <slangasek> but the worst case with "yes" is that you have to reboot and start over
[22:23] <slangasek> anyway, I have no idea why you'd be landing at this screen without explicitly selecting raid
[22:23] <slangasek> (or preseeding it)
[22:24] <ogra_> well, we're not actually "afraid" its a test system that gets installed over and over anyway ...
[22:24] <infinity> Though, <no> just repeating the question doesn't seem helpful.  Should probably go back to partman...
[22:24] <ogra_> though getting this screen is weird, i definiteyl did several installs on this same disk today already
[22:25] <slangasek> I also don't see that this is xnox's doing
[22:25] <ogra_> without seeing this message (completely preseeded automatic install, it shouldnt even ask .... we use priority=critical)
[22:25] <ogra_> infinity, xactly
[22:25] <slangasek> he's uploaded partman-lvm, but not partman-md
[22:26] <ogra_> we just had the disk here ... looks normal (std partitioning as defined in the preseed and used in the installations before)
[22:27] <slangasek> is it reproducible if you reboot?
[22:27] <ogra_> great, "yes" then gets us to "create a MD device"
[22:27] <ogra_> but at least there is a go back button now
[22:28] <ogra_> slangasek, well, not rebooted yet, hggdh is still inspecting from a d-i shell
[22:28] <slangasek> I think you should reboot
[22:28] <slangasek> if you can't reproduce it, blame cosmic rays and move on
[22:29] <ogra_> heh, ok
[22:29] <hggdh> I am a firm believer in cosmic rays
[22:29] <debfx> infinity: unfortunately the git repository permissions are wrong so I can't push it
[22:29] <ogra_> the bad thing is that this device is supposed to install unattended
[22:29] <infinity> debfx: Well, it's not world-ending in Debian anyway, so when it gets fixed, it gets fixed.
[22:29] <ogra_> if it hangs like that someone will have to touch it manually
[22:31] <ogra_> restarting the install (will take 10min until the bamboo-feeder dd'ed the image to sd and rebooted)
[22:35] <hggdh> d-i started
[22:38] <ogra_> hmm, this time the partitioner sits at "scanning disks" ... and doesnt seem to move ....
[22:39] <ogra_> ah, just took a while
[22:39] <hggdh> cosmic rays
[22:39] <ogra_> slangasek, ^^^
[22:39] <ogra_> but its still bad for fully automated installs indeed
[22:40] <hggdh> and there is still the no way to cancel the raid install
[22:40] <slangasek> what's still bad?
[22:40] <ogra_> slangasek, that there can be a case where it asks
[22:40] <slangasek> a one-time nonreproducible failure really could be a flipped bit somewhere
[22:40] <hggdh> well, this is actually another problem, and I will try to repeat
[22:41] <hggdh> (at home)
[22:41] <ogra_> which will make the whole thing sit there until someone comes and logs in via serial to release it ....
[22:41] <ogra_> not really helpful for unattented installs ...
[22:42] <slangasek> well, file a bug against the atmosphere
[22:42] <hggdh> :-)
[22:42] <ogra_> LOL
[22:42] <slangasek> it shouldn't let these ions through to mess up our code :)
[22:42] <hggdh> slangasek: actually, I agree that going to raid was cosmic rays. What I want to check is if there is, or not, a way to cancel the raid commit
[22:42] <ogra_> was probably a lack of bamboo in the bamboo-feeder, i guess we need to make sure there is always enough for all pandas
[22:43] <slangasek> yeah, that part could be a real bug
[22:44] <hggdh> thanks, folks, we have to disconnect for the shuttle
[22:45]  * ogra_ packs his toys
[22:46]  * slangasek waves