[00:01] slangasek: it does ignore stuff that is unknown / not bzr add'ed. Running in merge-upstream mode? These are the two cases I know when it ignores upstream changes. [00:01] [BUILDDEB] [00:01] split = True [00:01] xnox: thanks for the hint [00:01] ha. so it does have them, in the tarball =) === cpg is now known as cpg|away === mspencer_ is now known as mdspencer === fisted is now known as Guest43294 === jk-- is now known as jk- === RAOF_ is now known as RAOF === fisted_ is now known as fisted === fisted is now known as Guest21723 === patr|ck_ is now known as patr|ck === cpg|away is now known as cpg === shadeslayer_ is now known as shadeslayer [05:27] Good morning [05:50] hrm, mysqld is segfaulting during the php test suite === Ursinha_ is now known as Ursinha === rsalveti_ is now known as rsalveti === chilicuil_away is now known as chilicuil [06:12] Any bzr-git maestros in here? [06:14] shoot.. thats not a segfault.. its hitting an ASSERT.. whoops.. gotta turn those back off [06:26] RAOF: Oh hai. [06:26] RAOF: I'm not a bzr-git guy at all, but I totally need to hijack you to tell you that my laptop hates you. [06:26] RAOF: I've been getting those GPU lockup dialogs (after long freezes) several times a day. [06:27] RAOF: Do those actually go anywhere that gets read? :) [06:27] If you send them up they'll end up on the X team's workqueue. [06:27] * pitti is suffering from bug 1081009, that might be your's? [06:27] Launchpad bug 1081009 in xserver-xorg-video-intel (Ubuntu) "[arrandale] GPU lockup IPEHR: 0x02000022" [High,Incomplete] https://launchpad.net/bugs/1081009 [06:27] I've sent maybe 10 or so. [06:27] https://bugs.freedesktop.org/show_bug.cgi?id=55984 is seeing some action [06:28] Freedesktop bug 55984 in DRM/Intel "[ilk regression] gpu hangs on ironlake with 3.6 + -next + -fixes code" [Normal,Needinfo] [06:28] pitti: The symptoms definitely sound like mine. [06:28] although I'm not quite sure whether this was triaged right, Arrandale != Ironlake [06:28] and it's definitively unnerving; I'm running the quantal kernel [06:29] I'm running raring kernel and userspace. [06:29] I'm running raring userspace, but with this lockup the raring kernel is by and large useless for me [06:29] It only started for me a few days ago, after some dist-upgradery. [06:29] I need to reboot every hour or so, losing the last piece of work [06:29] for me it precisely started with the introduction of 3.77 [06:29] 3.7 [06:29] pitti: I don't need to reboot, I find VT switching out and back fixes it. [06:29] lucky you [06:29] not for me [06:30] Heh. [06:30] not even shutting down lightdm and restarting [06:30] So, almost the same. :P [06:30] But I'm on different hardware. [06:30] infinity: yeah, so I think you'rs is the fd.o one [06:30] but that actually also talks about two different issues, and the "other" one seems to be mine [06:31] I don't speak codenames, so I don't know what an Ironlake is. [06:31] But it's a Sandybridge CPU with Intel HD whatever graphics. [06:31] it's an iron. in a lake. [06:31] jk-: You're so remarkably helpful. [06:31] infinity: yeah, so sandybridge is the chipset generation after mine (arrandale) [06:31] infinity: Your *Sandybridge* is seeing problems? My Sandybridge, obviously, is absolutely stable. [06:31] infinity: I'm not quite sure about the ordering of ironlake [06:32] and I thought all those X freezes and pipeline underruns were a thing of the distant past :( [06:32] * pitti still remembers the long hours of testing various watermark heuristic patches [06:32] RAOF: my *sandybridge* is seeing problems too. [06:33] it's like every other raring user has this problem except the X.org team :) [06:33] RAOF: but i suspect it's got a lot to do with a stupid bios. [06:33] The funny thing is, I switched from discrete graphics to Intel on advice that the drivers were more solid. :P [06:33] Though, this is actually one of those silly hybrids, I could switch it in the BIOS and go nvidia for a while. [06:33] http://www.bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/totals-raring-workqueue is what's on the X team's easy workqueue. [06:33] RAOF: last time I looked this was actually be the #1 raring problem on errors.u.c. [06:33] infinity: Is https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1041790 what you're seeing? [06:33] Launchpad bug 1041790 in xserver-xorg-video-intel (Ubuntu) "[sandybridge-m-gt2] GPU lockup IPEHR: 0x0b160001 IPEHR: 0x0b140001" [Medium,Confirmed] [06:33] infinity: they had been for years really [06:34] infinity: they are more solid though. just not completely foolproof. [06:34] RAOF: I don't remember what error codes I was getting. Is that saved anywhere? [06:34] you should have some files in /var/crash/ [06:34] I get proper dumps, anyway [06:34] Oh yes, I have tons of them. [06:35] RAOF: Yep, that's the one. [06:36] So, you could probably be all switch-to-SNA to get around the problem. [06:36] (base)adconrad@cthulhu:/var/crash$ sudo grep 0b140001 * | wc -l [06:36] 3272 [06:36] *doh* [06:37] RAOF: Speak slowly, I'm a toolchain guy. What's an SNA? [06:37] infinity: It's the shiny new acceleration architecture for Intel. [06:37] is it really spelled out like that? :) [06:37] Though, the comments in that bug about SNA sucking differently don't instill confidence. [06:38] Oh, yeah. [06:38] I might just hit the BIOS and turn the nvidia battery-eater back on, and switch to nouveau for a while. [06:38] A fine choice! [06:38] * pitti sobs a little; I haven't had X problems since karmic or so [06:39] * infinity hasn't had X problems since he used to live with daniels. [06:39] And back then, the X problems were forced on me. :P [06:39] "Here, try this" ... "ARGH!" [06:44] RAOF: So, I'm not one to generally jump on the "omg, revert" bandwagon, but perhaps reverting to the Q version for now might be sane? [06:44] RAOF: Or does that present ABI problems that mean reverting a whole stack of crap? [06:44] Or API problems, rather, ABI's no big deal, we'd be rebuilding. [06:45] Or is it actually a kernel bug, and reverting the X driver won't make a lick of difference? [06:49] the X drivers didn't actually change in raring that much [06:49] so reverting the bits in the kernel ought to work, given that raring userspace works just fine on a quantla kernel [06:50] and given how everyone complains about this, it might not be the worst idea [06:51] pitti: I suspect "reverting the kernel" is a bit more troublesome, unless someone's already isolated a small and self-contained (set of) commit(s) to revert? [06:51] pitti: If so, find a kernel team member in your timezone (say, smb) and, for the love of god, make it happen. :) [06:52] it might actually be easier/possible to DKMSify quantal's i915? [06:52] at least back then I built the i915 module out of an otherwise unbuilt kernel tree [06:52] not sure how many dependencies it grew by now === smb` is now known as smb [07:46] * smb tries not to look too awake yet [07:54] * xnox my sandybridge locks up. TTY7 -> TTY1 -> TTY7 unfreezes it usually and then I get the popup "we detected it froze. Did you need a hard reset?" [07:54] xnox: was discussed some two hours ago already [07:54] xnox: Yeah, that's exactly how it works for me. pitti's not so lucky, VT switching doesn't fix him. [07:54] xnox: bug 1041790 [07:54] Launchpad bug 1041790 in xserver-xorg-video-intel (Ubuntu) "[sandybridge-m-gt2] GPU lockup IPEHR: 0x0b160001 IPEHR: 0x0b140001" [Medium,Confirmed] https://launchpad.net/bugs/1041790 [07:55] I see =) [07:55] * xnox just woke up and reading backscroll. [07:55] pitti: thanks for merging adt wrapper. Is it "deployed" to jenkins as well? [07:55] xnox: yes [07:56] pitti: awesome, thanks. [08:00] good morning [08:05] morning =) [08:05] i've now upgraded my snb laptop to raring as well, so if there are issues with the kernel they'll get sorted out ;) [08:07] pitti: oops, did I mix arrandale and ironlake.. [08:11] indicator-messages | 12.10.5-0ubuntu2 | raring | armel [08:11] is that normal that armel is still listed in rmadison? ^ [08:11] didrocks: Yes, we'll clean it up. [08:11] didrocks: ftpmaster still has the index files (but not the debs) for armel, that's all. [08:12] didrocks: And rmadison works off Packages/Sources files. [08:12] * xnox wonders if there are lonely armel raring boxes trying to upgrade..... [08:12] infinity: ok, thanks for confirming :) [08:24] does anyone know anything new about bug 965371? somewhere in the bug it says this was fixed in quantal, but on my quantal server I still see the same problem with pylplib [08:24] Launchpad bug 965371 in openssl (Ubuntu Precise) "HTTPS requests fail on sites which immediately close the connection if TLS 1.1 negotiation is attempted, on Ubuntu 12.04" [Medium,Triaged] https://launchpad.net/bugs/965371 [08:32] dholbach: Somewhere between mdeslaur and cjwatson you may find someone who knows the state of that mess. [08:33] dholbach: It seems that any way we try to fix it, we just break another weird corner case in the process. [08:34] I'll go through the entire comments in the bug again - maybe I find a workaround for mine :/ [08:40] dholbach, hey! i think the patch on https://bugs.launchpad.net/ubuntu/+source/hplip/+bug/1069324 looks good, but i don't have any rights - so how can i help out? [08:40] Launchpad bug 1069324 in hplip (Ubuntu) "diagnose_queues.py crashed with NameError in su_sudo(): global name 'utils' is not defined" [Medium,Triaged] [08:41] tkamppeter__, ^ do you think you could help out with this? [08:41] brendand, tkamppeter__ is our local printing expert :) [08:53] infinity: cjwatson: backlogging on yesterday's discussion [08:54] infinity: cjwatson: slangasek: so the automatic upload is checking the current version [08:55] like this night, it blocked because of upload out of trunk [08:55] so the archive is authorative [08:55] see https://jenkins.qa.ubuntu.com/view/cu2d/view/Indicators%20Head/job/cu2d-indicators-head-1.1prepare-appmenu-gtk/ [08:55] and particularly the artefact: https://jenkins.qa.ubuntu.com/view/cu2d/view/Indicators%20Head/job/cu2d-indicators-head-1.1prepare-appmenu-gtk/lastSuccessfulBuild/artifact/upload_out_of_trunk_appmenu-gtk_12.10.3daily12.11.28-0ubuntu2.xml [08:56] the issue there is that there was a distro patch (inline apparently?) that wasn't submitted/committed upstream [08:56] and when doing the bootstrap, this patch didn't show up [08:57] so it's only an issue with bootstrapping, we missed it apparently (cyphermox did the bootstrap and as there was no debian/patches…) === mcclurmc_away is now known as mcclurmc [09:16] so, just a head's up, this was merged only in the packaging branch, not upstream. Then it seems that cyphermox bzr merge the packaging branch upstream, but then, did a bzr revert debian/ (which is fine for new files as we don't want to have configure in the upstream repo, but not for modified one)… [09:16] so human error for the bootstrap, as it can happen for a manual merge and inline patch === henrix_ is now known as henrix === Tonio_ is now known as Tonio_aw [09:34] dholbach: So, I know you just sent an email shaming us all into patch piloting mor vigorously, but I was thinking I'd spend the better part of my piloting day tomorrow clearing out the SRU queues instead. We're about 80 uploads deep and climbing, and I suspect my time would be better spent there, before piloting even more patches that will land in upload queues that are stagnating. :P [09:34] infinity, works for me [09:34] I don't want to shame anyone [09:35] it's just that we need to do it and it will be good for us :) [09:35] infinity, +1 [09:35] mvo: Any reason you don't rev VERSION in softwarecenter/version.py when you tag/release? [09:35] mvo: My local copy is at 5.5.1.1 (because I revved it), but bzr trunk is still sitting at 5.3.7 :P [09:36] pitti: ok I checked, the chipset is arrandale, but the "graphics media hub" is ironlake, so the upstream bug is the correct one for this case I think [09:36] tjaalton: ah, thanks [09:36] pitti: so you could try i915.i915_enable_rc6=0 with it [09:36] the raring kernel [09:36] dholbach: I'll still check in with the bot and respond to people pinging on IRC for specific help, but yeah, I think my time will be better spent trying to reduce the upload queues so that puloted SRU patches aren't a month behind after they're uploaded. :) [09:37] * dholbach hugs infinity [09:37] s/puloted/piloted/ [09:37] tjaalton: $ sudo cat /sys/module/i915/parameters/i915_enable_rc6 [09:37] -1 [09:37] tjaalton: does that mean "enabled"? (I thought rc6 doesn't work with my chipset) [09:37] tjaalton: but I'll try it [09:38] hmm don't know what that value means. with the quantal kernel it was disabled for sure [09:38] then turned on in 3.7(?) and later disabled again [09:38] ah right -- that is the quantal kernel [09:38] I'll check if it's already in the next rc [09:39] pitti: /usr/lib/python2.7/dist-packages/bzrlib/plugins/dbus/activity.py:122: PyGIDeprecationWarning: MainLoop is deprecated; use GLib.MainLoop instead [09:39] xnox: yep; it needs GObject.MainLoop → GLib.MainLoop [09:40] infinity: no (good) reason, no, its autogenerated on build but bzr-buildpackage builds outside of the tree, so no good reason [09:40] infinity: thanks for your build fix btw :) [09:40] pitti: ack. It will annoy me enough to eventually make me upload a fix =) [09:42] pitti: looks like it's not in 3.7 yet, pinging upstream [09:42] tjaalton: where "it's" == ? [09:42] pitti: ah, the patch to revert rc6 for ironlake :) [09:42] ah [09:43] disables it again [09:43] tjaalton: so that should fix my crashes, but not infinity's and xnox' hangs? [09:43] but the kernel option I gave does the same when you have a chance to test it [09:43] pitti: yeah, probably doesn't change it for them [09:43] err, definitely doesn't [09:43] yep, I will; but I'm deep in a debugging session in a VM, so it'll be an hour or two until I can reboot [09:43] but probably fixes it for you :) [09:43] thanks for the hint! [09:44] sure thing, take your time and don't do anything critical in case it blows up on you :) [09:45] about the other hang, we've been discussing whether to use sna by default.. [09:46] I'll push -intel 2.20.14 to see if it fixes the issues some folks on the bug were seeing with sna [09:46] tjaalton: Is that my sandbridge bug? [09:46] infinity: yes [09:46] sandy, too. [09:46] tjaalton: it seems to trigger when I'm putting the machine under high load, such as creating VMs [09:47] tjaalton: Awesome. I shall upgrade and let you know if I stop seeing hangs over a day or two. [09:47] tjaalton: so I'll exercise it that way [09:47] tjaalton: I've been getting them every hour or two over the last few days, so shouldn't take long to confirm. [09:47] infinity: ok, I'll prepare & upload in a bit [09:47] right, I hope to see them myself on my t420s [09:47] This is also a T420s, so your odds are good. [09:48] great! :) [09:48] pitti: yeah that'd make sense [09:48] infinity: btw, which bios version do you have? [09:49] tjaalton: Happened with both 1.31 and 1.35 (I upgraded to see if things would improve) [09:50] infinity: I'm still on 1.30, all attempts to boot the update cd have failed so far.. was thinking if you happen to force pcie_aspm to save a watt [09:50] here it causes issues with the drive [09:50] tjaalton: Do you have your BIOS set to UEFI only? The update CD will only boot in Legacy. I found that out after an hour of head->desk. [09:51] oh === Steven_ is now known as [HacknamStyle]St [09:51] I'm not sure actually.. === [HacknamStyle]St is now known as [HS]Steven [09:52] seems to be using legacy only, so it's not that [09:53] tjaalton, do you mean ALPM for the drive issue or ASPM? [09:53] cking: the one you suggested :) [09:53] can't remember which one it was [09:54] tjaalton, ALPM for the HDD, in which case yes, it may give issues [09:54] so my machine seemed to work fine for a while, then I started getting i/o-errors [09:55] that's why I've been trying to update the bios to see if it would help [09:55] tjaalton, it may be more of a controller/drive combo issue [09:56] Hrm, I have controller/drive issues on my T420s, though not leading to errors or corruption. [09:56] It's just abnormally slow. [09:56] Compared to my older T61 with a similar (but older) drive. [09:56] yeah, I have an ocz agility 3 ssd on it [09:57] cking: Do you have any clever ideas on diagnosing "my disk performance seems to be crap"? [09:57] infinity, what kind of disk performance issues are you seeing? [09:57] I just opted to put 16G of RAM in it and do everything in tmpfses. [09:58] cking: Just... Slow. Heavy reads and writes are both lousy. So, startup of large applications, or long dpkg runs. [09:58] cking: Updating a chroot takes longer on my laptop than it does on my Panda with a USB disk attached. [09:58] cking: And it's pretty clearly disk I/O, cause it's blinding fast in tmpfses. [09:59] infinity, we are in the process of looking at a bunch of I/O performance issues [09:59] infinity: which fs? [09:59] tjaalton: ext4 [09:59] but it's taking forever to tease out [09:59] hasn't it been crap for many years already? [09:59] I can't remember a time when doing an rsync or copying large files hasn't brought my system to a crawl [10:00] cking: To be clear, it also doesn't seem to be vfs or filesystem, since my old T61, with a very similar setup, is much, much faster. [10:00] (load goes to 5 or 10, and everything feels like tar) [10:00] cking: Both are 2.5in 7200 RPM drives, though I'd expect the newer/denser one in the new laptop to be a smidge faster, rather than a ton slower. [10:01] (I haven't tried swapping drives yet, I may do that at some point as a data point, but I'm assuming it's the controller, or the driver for said controller) [10:04] infinity, well swapping drives is the first step to sanity checking thus [10:04] cking: *nod* ... Agreed. Just haven't found the time to take a screwdriver to both machines. [10:05] Though, I suppose once I do, I have a spare 2.5in SATA drive floating around that I can plug into a random ARM board. [10:05] That's a win, right? :P [10:05] :-) [10:06] * apw idly wonders if command queueing is enabled on the controller [10:06] I have a plethora of rather large 2.5in PATA drives kicking around, I wonder if adaptors are cheap enough to be worth driving to the store. [10:06] apw: Don't we enable that by default on anything built after, like, 2002? [10:06] oh we should indd [10:06] (And how can I find out? hdparm?) [10:06] indeed, but you never know [10:06] hdparm [10:07] What's the "show me everything you know about this drive" flag? [10:09] /dev/sda: [10:09] queue_depth = 31 [10:09] I assume that also means it's enabled? [10:09] didrocks: OK, so can you fix it so that the same sanity check is applied to bootstrapping? I'm sure we'll be doing plenty more bootstrapping, and it would be helpful for it to be robust. [10:11] cjwatson: yeah, well, we always have modified files (because of autogenerated changelog), so what I'm doing now is to go over all the indicator stack and bzr branch && bzr merge packaging -> look at what files were modified [10:11] infinity, mine has "* Native Command Queueing (NCQ)" in the capabilities list [10:11] Special-casing the changelog would be fine, of course [10:11] cjwatson: until now, I only spotted one project where the tests were commented downstream, so we definitively don't want to poick that :) [10:11] changelog, news and so on [10:12] cjwatson: I'm documenting the bootstrapping procedure with this [10:12] err, commands/fatures that is [10:12] and will write a checker [10:12] thank you [10:12] ogra-cb: Ahh, in -I? Yeah, mine too. [10:12] thanks, sorry for this oversight (but at least, the daemon picked it once you uploaded the fix) [10:13] right in -I [10:13] my fault, I should have picked it during reviewing cyphermox's bootstrap merge [10:13] (but it didn't appear on the diff of course as it was reverted) [10:13] well, it should still be autochecked immediately before copy, to minimise the race condition [10:14] cjwatson: I'm checking the version, if the version lies in the vcs? what do you mean? [10:15] the issue there was that a version claimed to be that version in the vcs wasn't exactly (and can't be on a bootstrap because of all those autogenerated files we don't have anymore) [10:22] didrocks: You must not trust the VCS for this purpose - you *must* double-check against the archive [10:22] The VCS is what we intend to ship to users, but the archive is what we *are* shipping [10:23] I'm much less concerned about differences in autogenerated files than I am in you checking that the version in the changelog is what you expect it to be [10:24] cjwatson: I'm trying to think of a way of doing that automatically, like apt-get source the previous version, rebuilding the previous vcs version (in addition to the current one) and diffing? ignoring some autogenerated/modified file [10:24] This is analogous (though obviously not identical) to auto-sync checking for an "ubuntu" substring in versions and refusing to ever overwrite [10:25] The problem at hand isn't that the contents aren't what you expect - it's that there's a whole new upload in the archive you don't know about [10:25] You can spot that with a simple version check [10:25] what do you mean? I do a version check, see the files above ^ [10:25] Err - then how did last night's breakage happen? [10:25] ok, let me explain again :) [10:26] So, I'm doing a version check twice [10:26] one at the very beginning of the process and one at the end [10:26] if the vcs doesn't have in debian/changelog the latest version published into distro, the component is ignored [10:27] for instance, after you uploaded the -0ubuntu2 yesterday evening, this night run published: https://jenkins.qa.ubuntu.com/view/cu2d/view/Indicators%20Head/job/cu2d-indicators-head-1.1prepare-appmenu-gtk/lastSuccessfulBuild/artifact/upload_out_of_trunk_appmenu-gtk_12.10.3daily12.11.28-0ubuntu2.xml [10:27] which marked the appemnu-gtk job as instable https://jenkins.qa.ubuntu.com/view/cu2d/view/Indicators%20Head/job/cu2d-indicators-head-1.1prepare-appmenu-gtk/ [10:27] this is to avoid this overwrite [10:27] unstable* [10:27] * cjwatson looks at the changelogs [10:27] Oh, so this was actually a human mismerge? [10:27] so what happens here is because of the bootstrap [10:27] right [10:28] I understand now [10:28] the vcs claimed to be at that version [10:28] when some local modification weren't committed [10:28] In that case I don't see this as a failure of the autopackaging/autouploading tools [10:28] A human committer screwed up [10:28] yeah, like when we merge from debian for instance === tkamppeter__ is now known as tkamppeter [10:28] it's a similar case of failure [10:28] A human committer screwed up, but a human uploader would have noticed, I'd like to think. Maybe not. [10:29] Right. I thought that the problem was that the upload had been entirely disregarded [10:29] Cause upload time is (traditionally) when you diff against the previous archive version to see if you buggered it. [10:29] infinity: Mismerges happen and reach the archive rather a lot [10:29] cjwatson: Sure, they do. Not arguing that they don't. [10:29] infinity, if you mismerge you probably mis-dput as well [10:29] cjwatson: ah, not at all [10:29] mdeslaur, pitti : sent a summary to the debian bug for the cupsd privilege escalation. I suspect mdeslaur's solution + hindering HTTP POST might be the only solution we have… [10:29] I'm still just very wary of the idea that sufficiently complex machinery can replace a real person giving a pass/fail on tagging/rolling a release. [10:30] infinity, those are not releases, they are daily snapshots [10:30] and this kind of this will only happen at bootstrap, (or if a merge from distro backported isn't properly done) [10:30] dholbach, no problem, I can apply the patch. I have to make an HPLIP upload to Raring anyway as there is a new release. [10:30] but I guess that an upload on distro will be noticed and the diff should be low enough so that the reviewer spot it [10:30] seb128: terminology [10:30] seb128: They're daily snapshots being released to users. That's a release. [10:31] * pitti remembers more than one buggered mis-merge upload that was done manually :( [10:31] brendand, ^ [10:31] thanks tkamppeter [10:31] pitti, I have a problem with setting permissions on a file of the cups-filters package. [10:31] cjwatson: so indicator stack is cleaned, I'm checking the last one, oif (but the other 25 projects enabled are cleaned, the only guilty was appmenu-gtk) [10:31] (i. e. reading debdiffs before upload is a great habit!) [10:32] tkamppeter: what are you trying to do? [10:32] OdyX: thanks [10:32] pitti: Yes, one I keep trying to get people to do. :P [10:33] infinity, well, most uploaders probably trust the content of the packaging vcses as well and don't bother a debdiff and read it before building/pushing ... so it's not much different, the checking is just done at commit time and not upload time === Tonio_aw is now known as Tonio_ [10:34] pitti, in debian/rules, in the binary-post-install/cups-filters:: section I do "chmod 700 debian/$(cdbs_curpkg)/usr/lib/cups/backend/serial" and in the resulting package /usr/lib/cups/backend/serial has still standard 755 permissions. [10:34] seb128: I was thinking of the cases where a new upstream version was done in UDD with only bumping debian/changelog, but not bzr merge-import (i. e. diff.gz reverted the newer version to the older one again) [10:34] seb128: I'd argue that those people are wrong, and codifying that as best practise is also wrong. :P [10:34] the autogenerated debian/patches/.patch doesn't help, of course [10:34] seb128: I was once caught out by ubiquity (it embeds other source packages on upload, but not in the VCS), so these days I do `pull-lp-source $pkg` and compare the debdiff of what i am about to upload. [10:34] tkamppeter: I bet that's done before dh_fixperms runs [10:35] pitti, right, I'm just saying that for normal day to day work (like doing a new version update in ubuntu), people tend to work, bzr diff, review the diff, upload, build, test, dput (without doing a debdiff) [10:35] tkamppeter: so you need to tell dh_fixperms to -Xserial [10:35] tkamppeter: move away from cdbs … :) . That and dh_fixperms indeed. [10:35] I do a lot of development in VCSes, but because the archive and source packages are authoritative, I always debdiff prev.dsc new.dsc before uploading. [10:35] xnox, you have more discipline than me then ;-) [10:35] seb128: "people" - I *never* do that [10:35] seb128: Which "people" are these? [10:35] * pitti always checks debdiffs [10:35] pitti, formerly, in the cups package it worked, was dh_fixperms only a recent addition? [10:35] OdyX: not really cdbs specific :) [10:35] seb128: And can we get them (you?) to stop? [10:35] I always always always debdiff before upload and tell people I sponsor to do the same [10:36] It's saved me from innumerable mistakes [10:36] pitti, how can I suppress dh_fixperms or make an exception for the mentioned file. [10:36] seb128: you do check debdiff when sponsoring? so why not do the same for your own uploads?! [10:36] It saves me from a lot of large mistakes, it also saves me from introducing annoying cruft here and there. [10:36] tkamppeter: so with cdbs it's DH_FIXPERMS_ARGS=-Xserial [10:36] tkamppeter: with dh7 you override it as normal and supply the argument [10:36] Even when I'm doing mass rebuild-only uploads and the like, the homemade scripts I use for that present me with a debdiff before I say yes [10:36] tkamppeter: no, dh_fixperms has existed for ages [10:37] tkamppeter: as I said; -X is a general debhelper option to ignore a file [10:37] xnox, because I read the diff before commiting to the vcs [10:37] infinity: (debian/patches/debian_changes *cough*) [10:37] seb128: ok. but that is racy, until we build out of VCS without uploading source packages. [10:37] The number of times I've commited a sane diff to a VCS then proceeded to produce a slightly insane source package is rather large. [10:38] infinity, well, if you know you can't get stuff done right :p [10:38] most of the time it is fine, until it isn't. =))))) [10:38] * seb128 hides [10:38] (joking) [10:38] seb128: says the man who's repeatedly dropped patches that were in the archive? :P [10:38] xnox, well, it's also that double checking takes time and sometime you have ETOOMANYTHINGS todo [10:39] A debdiff would easily show you "hey, I remember changing this thing, but I sure didn't drop fix_arm_again_argh.patch, I wonder what that's about." [10:40] if we want "debdiff and ack before upload" to be standard maybe we should have dput to do the debdiff and let you say y/n... [10:40] The checks are hardcoded into my fingers, and I still seem to get lots of uploads done, so ;-) [10:40] cjwatson: Pfft, you're pretty underrepresented every release in tumbleweed's pie chart of doom. [10:41] well, it's just that I never felt a strong need to get the diff a second way after checking it using the vcs [10:41] but maybe I'm wrong [10:41] in practice it didn't bite me too much so far so I never felt the need to change that [10:41] I honestly think you are, based on my experience of the two disagreeing from time to time [10:41] seb128: But the VCS diff != the package diff, especially if you have auto-generated files you don't check in, and also because the archive may have changes your VCS doesn't. [10:42] seb128: And if you think it hasn't bitten you, maybe the people who've had to unrevert things you've reverted in the past haven't yelled loudly enough. :) [10:42] I'm not saying I read every line of the debdiff, but I do skim it and check for files I wasn't expecting and the like [10:42] well I do debdiff in non trivial updates [10:42] or in merges [10:42] * xnox was bitten by not checking debdiff, don't want to be there again [10:43] yeah, usually the kind of errors that you make is not in the fine details, but more like "debian/control was autogenerated and I forgot to change control.in", or "debian/patches/ added/dropped an unexpected one" [10:43] infinity, if you didn't bother commiting your change to the vcs you have a blame for that as well [10:43] It's your responsibility to double-check that you aren't reverting stuff by accident. [10:43] seb128: No. I really don't. The VCS isn't authoritative, the VCS isn't authoritative and, also, the VCS isn't authoritative. [10:43] This goes for all uploaders. [10:43] infinity: (but you do cause pain to people who actually use it) [10:44] infinity, that's called "let's not bother to do my change properly and let's create work for others", not being a good citizen either... [10:44] seb128: I do try to check in more and more these days (though, the number of packages in the archive that have a VCS-* that I can't commit to is irksome), but that doesn't change that the archive is authoritative. [10:44] infinity, the archive being authoritative is not a valid reason to not bother doing the change properly and get them in the vcs if there is one [10:44] seb128: I could turn your statement right around for you, when your failure to merge the archive changes means people need to re-fix the same things. *shrug* [10:45] seb128: The difference is that when infinity gets this wrong it doesn't undo your work. [10:45] When you get this wrong it undoes other people's work. [10:45] That's clearly worse. [10:45] seb128: The VCS being your preferred workflow is not a valid reason to not diff against the archive to avoid reverts. QED. [10:46] infinity: -intel 2.20.14 uploaded. I'll give sna a go as well [10:46] cjwatson, well, I'm not trying to rank it, I'm just saying that ignoring the Vcs and let others deal with the work of founding the diff and getting it including is not correct either [10:46] (This would all be solved if we built directly from VCS tags, but we don't. And as long as we don't, people need to stop pretending their preferred workflow is also "the only way to upload correctly") [10:46] xnox: metacity on openjdk> I think there was some talk about MIRing something like twm instead [10:46] tjaalton: <3 [10:46] Sure. But it is not justification for pretending such things don't exist [10:46] xnox: I though openjdk just needed _a_ WM, not necessarily one as complex as metacity [10:46] cjwatson, oh, I don't, and I agree it's the responsability of the uploader to check that no archive change gets reverted [10:46] seb128: Hey, I tried to commit to software-center earlier today, and couldn't. This sort of thing frustrates me. :P [10:47] seb128: (mvo added me to the team, right after merging my changes from the archive, though. So, he did it right, and now I can do it his brand of right) [10:47] cjwatson, I just disagree on the fact that the archive being authoritative should be a right to bypass the Vcs and a way to dump the work on other [10:47] seb128: We're not saying it should [10:47] pitti: I have now finished downloading the source package. It can use metacity or twm. And it seems like it is used in the check target. [10:47] infinity's position sounds like "anyone should be able to just upload to the archive and not have to bother if the source is maintained in a Vcs" [10:48] but maybe I read him wrongly [10:48] Although I would say that you don't have a lot of experience of trying to do work across the whole archive, and running into the huge number of misconfigured VCSes [10:48] sorry if that's the case [10:48] pitti: i wonder if it is sufficient to move that bit to DEP-8 and not have either metacity nor twm in main. [10:48] infinity and I both do [10:48] xnox: twm is in universe, but putting it into main if we can drop metacity from main sounds like a good trade [10:48] pitti: the check won't run on non x86 platforms though =( [10:48] And that surely colours our outlook [10:48] seb128: I don't personally just upload willy-nilly without checking for a VCS-* field. On the other hand, your statement is more or less true. Archive uploads are the One True Source for the packages, like it or not. [10:49] cjwatson, well, if the Vcs is misconfigured it's the responsability of whoever is handling the Vcs and the package indeed [10:49] seb128: So, my position isn't as caustic as you make it out, I still try to find the maintainer's preferred methods. [10:49] seb128: which doesn't help, if the core-dev doesn't have write access to it. [10:49] seb128: Sure. But when you're uploading 500 packages and run into 100 of these ... [10:49] (Or whatever) [10:49] (And yeah, it annoys me to no end when someone bitches me out for not committing to a VCS I can't commit to) [10:50] Also, I won't commit to a VCS-* for a 100-package rebuild run or something. [10:50] xnox, a vcs for a package in the archive should allow commit from the people who can upload [10:50] (Though, I also don't care if those no-change changelogs get lost) [10:50] seb128: hahahahaha. I would love that to be close to true [10:50] infinity: if the only uploaded diff is a ubuntu1.1 no-change rebuild, I admittedly often don't bother grabbing the diff and committing it, I just overwrite it [10:50] (as recently seen with some py3.3 rebuilds) [10:50] cjwatson, I said "should" ;-) [10:50] cjwatson, infinity, from a diffent colored outlook; if you don't have commit access to the vcs; why don't you ask for sponsorship from the person who has? [10:51] seb128: ps branches? =) [10:51] seb128: Actually, I don't wildly care if it's commitable IF I also know that the people who maintain the package will integrate uploads. [10:51] diwic: When trying to complete a transition involving 500 packages? [10:51] Sure, if you don't mind it taking 5x longer [10:51]