[00:09] ok [00:09] so what is git for 'bzr pull --overwrite'? :) [00:10] mwhudson: “git reset --hard $ORIGIN/$BRANCH” (generally origin/master) [00:10] After having run “git fetch $ORIGIN”, obviously. [00:11] RAOF: so i need to add the repo i want to blat over mine as a remote first? [00:11] right [00:11] Yes. As far as I know, the git doesn't have a concept of ‘just pull from this repository please’ [00:12] i wonder what it's doing now [00:12] What have you asked it to do? :) [00:13] git fetch git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git [00:14] ah now it's doing things [00:14] I have no idea what it's going to do :) [00:15] I don't *think* it's going to do what you expect, though. [00:16] i think it fetched the objects from that repo into mine [00:17] and nothing else [00:17] That seems both unusally helpful and unusually obvious for git. [00:18] i could only tell this by running diff -r on the copy of the cloned repo i made before doing anything :) [00:18] I don't suppose git branch -a shows some new remote branches? [00:19] nope [00:20] so how do i add the branches from a remote? [00:21] is it just [00:21] git remote add natty git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git [00:21] git fetch natty [00:21] ? [00:21] maybe git fetch natty master ? [00:22] mwhudson: git remote add natty as you wrote [00:23] then use git branch -r to see what natty remote branches there are. [00:23] To create a local mirror of a remote branch, you can do git checkout -b natty-master natty/master [00:23] Which will create a local branch called natty-master which tracks natty/master [00:24] git branch -r just says [00:24] origin/HEAD -> origin/master [00:24] origin/master [00:25] Did you add natty as a remote? [00:25] yes [00:25] ok then you want to run git fetch natty [00:25] ah ok [00:25] that was running while i ran git branch -r [00:25] now it's completed a bunch more stuff has appeared [00:28] ah now arararagh i don't know which patch tjaalton backported [00:28] oh phew, it's here: http://people.canonical.com/~lexical/bugs/lp791752/ [00:38] git 1 : 0 mwhudson [00:49] ok building [01:19] ah hum, i changed the version of the packaging [01:19] which broke the build [01:20] ah i changed the version of the packaged, but not something else [01:20] mwhudson: btw, #ubuntu-kernel usually gets this stuff :> [01:20] ah point [03:05] ok. why the !@#$ does pastebin.ubuntu.com require me to log in to download a paste as text? [03:05] regretting ever having sent user to that url for support :( [03:05] what silly silly silly idea [03:06] agh. requires whitelisting session cookies too [03:06] and doesn't work in w3m [03:06] geez [03:13] nemo: It was a simple solution to the very real problem of people distributing large binary files (like ISOs and movies) in raw pastebins. [03:16] A size limit wasn’t? :-) [03:19] ion: amen brother [03:20] somehow everyone else manages [03:53] ion: Size limits don't help. It's trivial to split an ISO into thousands of chunks and shove them into a bunch of bins. [03:53] ion: And yes, this happens. A lot. [03:53] um [03:54] if someone is willing to go to all that trouble to distribute an ISO [03:54] they can also trivially extract base64 bits from your pastebin without the raw thing [03:54] nemo: This isn't theoretical. If it was, no one would care. [03:54] so that makes the annoyingness pointless [03:54] nemo: The difference is that your assertion is theory, mine is fact. :P [03:55] nemo: (I don't disagree with your theory, but that's not the real-world data we've seen) [03:55] heh [03:55] I bet you're the dude who instituted this :) [03:55] Nope. [03:55] But I'm fairly familiar with it nonetheless. [03:56] ok. so you somehow ran into someone who was both clever and determined enough to split an iso into 10,000 pastebins, and do it in a way that would evade abuse detection, but too stupid to handle scraping [03:56] ahhh well [03:56] at least there's a reason for it [03:57] I'll just use pastebin.com [03:57] thanks for explaining though [03:57] seeya! [04:19] Good morning [04:34] SpamapS, RAOF: I'll be on vacation the next two weeks; can you handle SRUs during that time? [04:36] pitti: Good morning! I guess we can, yes. I'll just punch down the queue more often. [04:38] RAOF: also, I think it's time for you to be able to twiddle the buttons yourself [04:38] RAOF: WDYT? [04:38] pitti: Also, I had an SRU-calibration question: bug #744929. From past behaviour I'd expect that to be accepted as an SRU, but I think it is too close to “core infrastructure” and too far from “serious regression” to fit the criteria. [04:38] Launchpad bug 744929 in gnome-keyring (Ubuntu Natty) "After auto-login, prompted to unlock keyring multiple times" [Low,Triaged] https://launchpad.net/bugs/744929 [04:39] that's https://launchpadlibrarian.net/72725131/dont-prompt-multiple-times-rebased.patch, right? [04:40] YEah. [04:41] It looks reasonably safe. It's just touching what I'd regard to be core infrastructure to fix a bug that doesn't seriously undermine the usability of the desktop. [04:41] it certainly sounds like a regression, but it's indeed not a showstopper [04:41] admittedly 4 identical password prompts suck a bit, but it seems there aren't so many dupes [04:42] I think this highlights a difference between accepted practice and what we've got written on wiki.ubuntu.com/StableReleaseUpdates. [04:42] RAOF: TBH I'm a bit on the edge there; I probably would have accepted it, but I guess my treshold is now pretty low after so many years [04:42] so I actually do appreciate a little more rigor in the process [04:44] I'd probably accept it, FWIW. I'm okay with any "obviously correct" bugfixes that don't change expected interfaces. Ish. [04:44] (But it's pretty case-by-case, which is why it's hard to codify such things in a policy) [04:45] Right. As I said, from past behaviour I'd expect that to be accepted. But were we to go by what's written on StableReleaseUpdates, I don't think it would be accepted. [04:45] Which means we should either update the documentation for what is acceptable in an SRU, or become stricter :) [04:46] Or accept that the docs reference the baseline level of "strictness", and as people get more comfortable with the spirit of the law, they can make a few borderline judgements? [04:47] Like I said, it's really hard to codify "acceptable updates" without erring on the side of caution. [04:47] Cause accidentally going the other way is ungood. [04:47] I agree [04:47] and while each single of these patches might be acceptable, I'm still a bit uncomfortable about the sheer number of updates that we do this way [04:48] some of them will eventually wreak havoc [04:48] and when looking at the kernel updates, this already happens all the time :) [04:48] Well, I'm also personally less inclined to fix every little bug in non-LTS releases too. [04:48] Kernels are quite special :) [04:48] Whereas pushing well-tested and very correct patches to LTSes makes me happy. [04:49] (Given that I'm one of the people who does, in fact, run then for years) [04:49] RAOF: so if you want to reject this particular update because it doesn't fit the risk/benefit ratio, I think that's a very justifyable position [04:49] infinity: +1 [04:50] infinity: I have an 8.04 machine around here some place [04:50] StevenK: My co-lo machine is still hardy too. [04:51] (Though, if mainlined Xen on 3.0 in oneiric proves stable, I might be tempted to upgrade pre-LTS..) [05:18] good morning [05:21] Oh, oh! It's a didrocks! [05:21] Morning didrocks :) [05:21] hey RAOF ;) [05:25] When's the NBN going to deliver a fibre connection to my home, damnit? Uploading 150Mb worth of evolution core to launchpad takes too long! :) [05:29] RAOF: retrace it locally. [05:30] lifeless: That's effort. Whereas I've got so much practice bitching about upload speed it's near effortless :P [05:31] except for the whole uploading thing [05:32] Eh. That's computerised effort. [05:35] …unless the upload 503s mere seconds before completing, of course. [05:40] ewll [05:40] to lp ? [05:40] that means it completed but the insert boomed [05:40] or the server instance was restarted [05:40] did you get the OOPS id ? [05:41] Apport doesn't give one; it hadn't opened the “please wait while we process your data” page yet. [05:45] apport bug then [06:03] pitti: I'm still not clear on kernel SRU's .. [06:04] SpamapS: for accepting it's actually quite easy now [06:04] ugh.. TwinView is totally busted right now [06:04] SpamapS: https://bugs.launchpad.net/~ubuntu-sru/+assignedbugs?field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED [06:04] SpamapS: that's the list of assigned SRU tasks, by the new kernel workflow [06:04] SpamapS: if there are promote-to-proposed tasks, you exercise the corresponding copy-proposed-kernel invocations from pending-sru.html and close the tasks [06:05] SpamapS: the main thing to watch out is to include all the -meta, -lbm etc. in the copying when there's an ABI bump [06:05] SpamapS: for releaseing a kernel to -security/-updates you need cocoplum access, as launchpad still times out when using launchpadlib [06:05] i. e. this part needs to be done by slangasek or cjwatson [06:07] Ok, any gotchyas other than the -meta and -lbm packages? [06:07] not really [06:07] we stopped running sru-accept.py on them, the bot/kernel team does that now [06:07] (with different verbiage etc.) [06:07] SpamapS: it's very mechanical on our end now [06:09] Ok, I'll give them a shot when I can. [06:09] SpamapS: we just went through a round for all releases, so I don't expect further updates until next week [06:09] pitti: I think we'll be able to keep the ship running.. we may even keep it from running aground. ;) [06:09] SpamapS: skaet also did copy-proposed-kernel already, so she can help/explain as well [06:09] lol [06:09] thanks :) [06:12] now to figure out why my twinview is refusing to show any windows [06:17] SpamapS: I'm happy to help with -security/-updates kernel magic too, if required. [06:37] pitti, re 799754, what about autologin? ubiquity still would be writing out to /etc/lightdm/lightdm.conf, so if it's not a conffile that might be trouble [06:41] infinity: how deep does the 'use lucid-updates during debootstrap' change go, do you think? [06:44] lifeless: Well, debootstrap isn't "deep" to start with, but mirror-handling and deb-fetching isn't particularly abstracted, so the change would touch several instances of shockingly-similar code. [06:45] lifeless: And, in the process, you'd also fix a longstanding bug that if there are two versions of a package available in the same Packages file, debootstrap just picks the first one it hits. :P [06:45] lifeless: (Which obviously would need to be fixed, to actually pick the highest version) [06:46] just trying to assess whether I can explain to francis why I'm hacking on debootstrap :P [06:47] lifeless: It's something I always wanted to do if I found the tuits, and I could even potentially block time off later in this cycle to get David to agree to let me do it, but it's not something I could commit to right now. [06:47] good morning [06:47] lifeless: So, if you can make it happen, please do. [06:47] heh :P [06:47] lxc is good for yak shaving apparently [06:51] superm1: ubiquity shouldn't modify lightdm.conf as long as it _is_ a conffile [06:52] superm1: but mythbuntu-default-settings and friends would install their's before ubiquity, so that should work? [06:53] lifeless: debootstrap actually already has preliminary support for multiple archives. Where that falls short for us is that we use "pockets", which means some ugly s/$dist/\1-{updates,security,proposed}/ all over the place. [07:00] awesome.. so nvidia driver multi-monitor is completely broken on oneiric at the moment. :-/ [07:00] and nouveau is refusing to recognize my NV96 [07:01] pitti, yeah that would work as long as all packages installed it as a conffile [07:01] superm1: why a conffile? [07:01] my point was that ubiquity does modify that file in terms of changing automatic login [07:01] for gdm it did the same for custom.conf [07:02] I don't think it should be; multiple packages shipping the same conffile is icky to get right, as they'll cause conffile prompts [07:02] superm1: custom.conf was not a conffile [07:02] pitti: Multiple packages shipping the same conffile is just wrong, wrong, wrong. [07:02] and ubiquity modifying lightdm.conf conffile is nasty and shoudln't be done [07:02] infinity: my point [07:02] SpamapS: nouveau doesn't recognise your nv96? Got a pastebin of dmesg+/var/log/Xorg.0.log there? [07:02] pitti, so what should the right solution be here? [07:02] superm1: You might be confusing "conffile" (dpkg-managed files) and "config file" here? [07:03] superm1: *-default-settings should install a config file if it's not there already [07:03] yes i think so [07:03] how do you install something in /etc that isn't dpkg managed then? [07:03] superm1: A non-conffile config file that is created in maintainer scripts is the only way to have multiple packages play willy-nilly with the same file. [07:03] superm1: like, ship it in /usr/share/mythbuntu-default-settings/lightdm.conf and copy that to /etc/lightdm/ in postinst if not present already [07:03] oh right [07:03] okay that makes much more sense then [07:03] then ubiquity can apply as much seddery on it as it wants [07:04] and FWIW, yay for having so great names for config files vs. conffiles (which are also config files, of course) [07:05] Yeah, it's muddy. :P [07:05] so what I really ment was a non-conffile config file [07:05] But we still require everyone to know debian-policy, right? :) [07:05] (tell that to any non-DD and they will just stare at you in disbelief) [07:06] pitti: Well, you can scrap the "conffile" thing and say "non-dpkg-managed config file", which probably gets the point across better. [07:06] good idea [07:06] yeah if i read that i probably wouldn't have scratched my head as hard [07:06] RAOF: hrm, I don't think I do.. I've just reinstalled nvidia drivers.. really tired of fighting such a silly issue. [07:07] * SpamapS is installing XFCE to see if it fares better than Unity [07:07] superm1: anyway, with that sorted out, it would work in exactly the same way as with gdm's custom.conf [07:07] SpamapS: don't you guys all just plain X with a single xterm and byobu anyway? :-) [07:07] the "servity" desktop [07:08] pitti: kirkland is always trying to get me to use byobu. Not exactly my cup of tea. ;) [07:08] if I had it my way, I'd run the *stable* release of Ubuntu [07:08] but c'est la vie.. we must dog food [07:09] byobu is way too many bells and whistled (and constant pointless forking!) for a real CLI hack. [07:09] s/whistled/whistles/ [07:09] infinity: I believe kirkland has been working on making the monitors resident... so they just work via pipes. [07:09] SpamapS: Still, who needs monitors? [07:10] Hold on, I had a great quote for just this occasion... [07:10] I'm with you.. but kirkland has put so much work into it.. I try to give it a fair shake whenever there's a major development. [07:10] < ron> procmeter3 does kind of look like the classic "I wanted to write a program, but don't actually have anything useful I want to do with computers" application [07:10] That one. [07:10] :-D [07:12] * micahg remembers evoking that comment a couple days ago [07:12] micahg: It was worth saving. [07:13] * SpamapS feels lost [07:13] lovely quoet [07:13] *quote [07:13] this giant 22" monitor on my desk just black.. :-/ [07:14] * SpamapS ponders kde for a nanosecond [07:19] I think KDE would be ok if I could get over the hump. And learn to ignore options. === smb` is now known as smb [07:23] well xfce will be fine until they fix unity [07:25] lol, willy- illy [07:25] nilly* [07:25] :( [07:32] RAOF: have a look at https://launchpad.net/ubuntu/natty/+queue?queue_state=1 [07:33] RAOF: of course I just processed all your ack'ed uploads some two hours ago, so there's nothing acceptable left right now [07:33] RAOF: unless you want to accept strongswan [07:33] RAOF: often I allow people to test the proposed package and fix oneiric in parallel, I just don't move these to -updates [07:33] it's not something I like to do, or happens often, but if you want to try :) [07:34] Stronswan was the one I tentatively NAK'ed based on 3.0 (quilt) stylistic, right? [07:34] RAOF: no, that was w-scan or so, I already rejected it [07:34] RAOF: strongswan was delayed because a part needs fixing in oneiric [07:34] queuediff says Strongswan was the one not fully fixed in oneiric. [07:34] wow, queuediff says that? [07:35] No, but it does open the bug :) [07:36] …which reminds me that I should have set the Ubuntu task back from fix released :) [07:36] infinity: did you ever see a build failure like https://launchpadlibrarian.net/75531471/buildlog_ubuntu-oneiric-i386.libreoffice_1%3A3.4.1-1ubuntu1~ppa2_FAILEDTOBUILD.txt.gz ? [07:36] So, we *could* reject the gnome-keyring upload. [07:37] After installing, the following source dependencies are still unsatisfied: [07:37] libstlport4.6-dev(still installed) [07:37] Source-dependencies not satisfied; skipping libreoffice [07:37] RAOF: that's a lot less fun, though [07:37] Sweetshark: ^ FYI [07:37] pitti: Build-conflict. [07:38] Sweetshark: ^ oh, do you have a build-conflicts: there? [07:38] pitti: One of the build-deps is pulling in a build-conflict: Kaboom. [07:38] infinity: curious that it only happens on i386 [07:38] infinity: thanks! [07:40] RAOF: another thing you can do now is running sru-release; there is a natty package which can go [07:40] foolscap. [07:41] yeah, and pithos [07:41] Hasn't pithos been there only 7 days? [07:42] lifeless: 802985 is surely moot now because the oneiric kernel is now 3.0.0 not 3.0, and AFAIK lucid's libc6.preinst will have no problem with that [07:42] lifeless: it's still a design issue, so the bug should stay open, but I see no reason why it should block you in any way [07:43] cjwatson: Oh, it was just choking on format, not on kvers != 2.6? I didn't look. [07:44] pitti: nah, thats not curious. stlport is only kept on i386 for binary compatibility with C++ extensions (a whole insanity of its own). amd64 dodged that bullet by means of the grace of late birth. [07:44] pitti: Have I somehow managed to project a “SRUs stay in -proposed for at least 10 days” policy where there is none? [07:44] RAOF: it's 7 days :) [07:45] I blame the lack of a decimal calendar. [07:45] infinity: yep [07:46] 0.8 week [07:46] pitti: So, that'd be ‘sru-release natty pithos foolscap’ to move those into -updates, right? [07:46] RAOF: actually, I don't see the 7 days on thehw iki page [07:46] RAOF: right [07:46] RAOF: please open the associated bugs before, and check that they are fixed in oneiric [07:46] infinity: lp:ubuntu/eglibc r157 was all that was needed to fix it; and having a 3.0.0 kernel on the host should do just as well [07:46] RAOF: and that there are no late comments about "OMGbroken" [07:47] RAOF: I think at one point it was 10 days; there was a time when I had that in my head too [07:47] I had always believed that the maturing period was on the wiki [07:47] pitti: apropos OMGbroken. 3.3.3 in SRU seems to be just that (lost its themeing). [07:48] Sweetshark: yeah, I saw :( [07:48] Heh. Pithos hasn't been fixed in oneiric yet. [07:48] pitti: I think it is now [07:48] cjwatson: well I had a bug on lxc-create duped on it overnight [07:48] ah, "After one week of maturing in -proposed" [07:48] I searched for "7", "10", and "days" [07:48] pitti: Im building it again to see, what the heck went wrong there. [07:48] RAOF: ^ [07:48] lifeless: I bet they're still running a slightly old oneiric kernel. just tell them to upgrade [07:49] I've looked at the debootstrap change required; I know the code as well as most and it's still fairly scary [07:49] cjwatson: I'm upgrading now [07:49] although this is only in the "special cases" [07:49] so I'm a lot more comfortable with leaving it alone for the moment :) [07:49] pitti: Yeah, but that's only in the special-cases :) [07:49] Anyway, pithos isn't a candidate because it's not yet fixed in oneiric. [07:49] the business of merging Packages files and taking the highest version will be the fiddly bit [07:50] RAOF: ah, it's at https://wiki.ubuntu.com/ArchiveAdministration#Stable_release_updates [07:50] cjwatson: Yeah, and that's the bug I want to fix ANYWAY. [07:50] and probably needs to go in the pkgdetails code (which has two implementations, one in debootstrap and one in base-installer, and they need to be kept in sync interface-wise) [07:50] cjwatson: (Nevermind the multiple Packages merging, which is a feature request, but the long-standing bug of not picking the highest version) [07:51] yep [07:51] RAOF: which is out of date wrt. "sru-pending", updating now [07:51] cjwatson: Hugely annoying when bootstrapping sid with more than one version of some packages publishes. [07:51] I agree it's a problem, but not blocking everyone on it would be pretty good [07:51] published* [07:53] RAOF: probably best to remove that entire paragraph, and fix the SRU page instead [07:53] pitti: Aha. Anyway, I'll send foolscap off to -updates, as that *has* been fixed in oneiric and no one's claimed that it set their dog on fire. [07:54] * cjwatson irritated to discover he made an archive mistake that he'd have told anyone else off for making [07:54] grr [07:54] pitti: And maybe leave a link. [07:54] RAOF: yeah, doing [07:54] cjwatson: Which one? [07:54] cjwatson: The by-hand stuff? [07:55] d-i not copied to -updates properly, yeah [07:55] did somebody do that for me? timestamped yesterday [07:55] S'ok, dist-upgrader hadn't been copied since before the LAST point release too. [07:55] Clearly, people need to be re-educated on by-hand. [07:55] *cough* [07:55] was that you? [07:55] And yeah, I fixed it for you. [07:56] cool. thanks and sorry. [07:56] S'all good. [07:56] Might want to check dist-upgrader in other releases, I only did lucid. [07:56] Who knows what bugs we've fixed and never released! [07:58] hello I like new gwibber but is there any chance that 5 minute update time limit will be reduced? thanks [07:58] RAOF: docs updated [07:58] RAOF: sru-release worked? [07:59] Yup. [07:59] Whoop whoop! [07:59] nice [07:59] oh, my server came back, brg === pitti_ is now known as pitti [08:00] published hardy-updates debian-installer properly [08:01] pitti: Will you have time to give colord a once-over & upload to Debian, or shall I troll for other sponsors? [08:01] RAOF: no guarantees, I'm afraid; need to get some stuff done before my holidays and a3 [08:02] cjwatson: Hahaha. Seriously? [08:02] infinity: you're right, there's a bunch of other stuff that needs proper publication in -updates. I'll look at it after the next publisher run [08:02] cjwatson: Yeah, it might be time for a mail to the list. ;) [08:02] infinity: yeah :-/ [08:02] lrwxrwxrwx 1 lp_publish lp_publish 19 Apr 6 2010 /srv/launchpad.net/ubuntu-archive/ubuntu/dists/hardy-proposed/main/installer-i386/current -> 20070308ubuntu40.14 [08:02] pitti: That's fine. Trolling for sponsors it is! [08:02] lrwxrwxrwx 1 lp_publish lp_publish 19 Jul 20 08:00 /srv/launchpad.net/ubuntu-archive/ubuntu/dists/hardy-updates/main/installer-i386/current -> 20070308ubuntu40.14 [08:02] infinity: um, well - I suspect the fault is largely mine [08:02] cjwatson: You can totally do it while the publisher is running. Do your work in dists.new and race the clock. [08:02] I've certainly at least been *around* when these were copied [08:03] infinity: oh, sure, I documented how to do that in ArchiveAdministration even :-) [08:03] infinity: but I prefer not to if there's no wild rush [08:03] cjwatson: want me to add a warning to sru-release when you run it on debian-instsaller? it should at least point to the part of ArchiveAdministration which explains how to do it [08:03] pitti: yes please [08:03] pitti: And ditto for update-manager. [08:03] infinity: uh, wasn't even aware of that one [08:04] pitti: No one seems to be, from the state of the archive. :P [08:07] committed [08:10] pitti, infinity: thanks for the stlport tip. For once, it wasnt me who broke it this time. [08:10] Sweetshark: Always nice to be able to pass the buck. :) [08:10] dholbach, hi *waves* [08:10] heya Amoz [08:11] dholbach, I was thinking about brainstorm.ubuntu.com... [08:11] it's the old style 8-D [08:13] Amoz, might be worth talking to these people about it: https://launchpad.net/~brainstorm-admins/+members#active [08:13] infinity: in the rare occurances where I didnt bork it myself ;) [08:13] cjwatson: Do we know if dist-upgrader actually correctly looks at ${dist}-updates? If so, I think we've been, quite embarassingly, missing a lot of fixes to update-manager. :/ [08:13] cjwatson: (note that lucid-updates had *no* dist-upgrader directories until I copied the ones from -proposed yesterday) [08:14] dholbach, is there a more "prioritized" website somewhere with the old style? [08:14] Amoz, might be worth asking in #ubuntu-website [08:16] infinity: its using the url from http://changelogs.ubuntu.com/meta-release [08:17] infinity: often I did manually update it to point to the right version in -proposed (right as in the version that is also in updates). but having this correct by copying would be really good [08:18] mvo: Ahh, I see. So, you've been working around our failure. Excellent. :) [08:18] dholbach, ah, of course.. [08:18] mvo: But yes, we really should be moving them properly for you and having you reference -updates. [08:18] infinity: great! [08:18] Amoz, I'll try to sort out the license/copyright stuff for the packaging guide thing today [08:20] dholbach, niiiice [08:35] hm, what did I misunderstand about bash's regexps? why is [[ "aaaa" =~ "a*" ]] false? [08:35] i don't suppose you need to escape the *? [08:35] no, and I alraedy tried that [08:36] [[ "aaaa" =~ "aaaa" ]] works, but anythign more complex than that just fails on me :/ [08:36] ah, [[ "aaaa" =~ a* ]] [08:36] no quotes [08:36] yeah [08:36] so seems quotes are special in [[ ]] [08:36] perhaps only special on the right side of =~ [08:37] Quotes are special all over shell. [08:37] Anything in quotes is immediately a string. [08:37] > Any part of the pattern may be quoted to force it to be matched as a string [08:37] You'll see the same problem when testing for numeric equality. [08:37] ok, thanks [08:38] now I just need to figure out where X="pitti/ppa"; [[ "$x" =~ [[:alnum:]-]+/[[:alnum:]-]+ ]] goes wrong [08:38] well, i would have assumed like pitti the second argument to =~ was a string [08:38] aside from the first X being uppercase? [08:39] *headdesk* [08:39] *cough* [08:39] poolie: shame on me :) [08:39] :) any time [08:39] some problems are deceptively easy === alex__ is now known as Amoz [09:03] wgrant: did you filed a bug for the failed import at https://code.launchpad.net/~wgrant/lintian/master [09:04] wgrant: i like to setup a daily build for lintian, but this code import fails [09:09] poolie: this is why I avoid bash [[ ]] - its behaviour is totally nonintuitive [09:09] better to use expr IMO [09:09] or case [09:09] case $string in pattern) ... ;; esac [09:09] it does seems like a layer violation that it changes the quoting rules [09:09] but, sh is full of them [09:09] i would tend to use case too [09:09] though, can you use regexps? [09:10] sure, but this is yet a new set of quoting rules :-) [09:10] no, but globs are often enough [09:10] tumbleweed: do you have done something to fix bug #801945? [09:10] Launchpad bug 801945 in ubuntu-dev-tools (Ubuntu) "[backportpackage] Fails to backport local .dsc file" [High,New] https://launchpad.net/bugs/801945 [09:10] actually, i would tend to use zsh globs in personal use scripts [09:10] cjwatson: ok, the oneiric cd for some reason hadn't installed linux-generic [09:10] you can use regexps in expr [09:10] cjwatson: so kernel upgrades were not happening automatically [09:10] life that's odd [09:11] poolie: the other reason I avoid [[ ]] is that much of my shell code has to run in plain POSIX sh [09:11] right [09:11] and it's easier for me to be in the habit of just writing in POSIX sh all the time === zyga-afk is now known as zyga [09:11]