[01:31] bdrung: "* Bump Standards-Version to 3.8.4 (no changes needed)." <-- udt. I hope you bumped it to 3.9.4. [01:33] cody-somerville: are you DM/DD or just maintainer for catfish? [01:40] just maintainer I believe [01:40] hrm, ok [04:26] 'evening gentlemen [04:26] so hmm guys... what would the deadline be for my Ecere release to make it into Raring? [04:28] I was thinking I could make a pre-release first to integarate it and then the official release a week later? [04:30] ESphynx: Mar 7 for new features, bug fixes until a couple days before release [04:31] micahg: yes... so, could I release say, 0.44.09 before March 7, and then 0.44.1 a week or so later? [04:32] sure, as long as the new version has no features (and I'd shoot for a bit before the 7th as you need sponsorship to Debian and Ubuntu) [04:32] I'm going to have the 64 bit support ready, but not all the testing/bug/fixes tweaks that I want in 0.44.1 [04:33] still not clean on what constitutes a 'feature' :P is this as strict as for SRUs? ;) [04:33] clear* [04:34] new functionality [04:34] new library SONAME [04:34] https://wiki.ubuntu.com/FeatureFreeze [04:34] ah well there won't be no new library for sure [04:34] a lot of the things might have to do with the Windows installer in fact [04:35] but for example... [ ] Switch to OpenGL if opening 3DS from commandline [04:35] would that be OK? ;) [04:35] or say... [ ] Edit/Copy/Paste buttons in toolbar [04:36] (I have this list of things I'd like to get done before 0.44.1 ... they're all minor tweaks and enhancements or bug fixes) [04:36] if there was already opengl available and you're switching a default, that might have passed before, idk about now; if the buttons were there before, it's UI freeze, if they weren't feature freeze [04:36] tthe buttons were not there [04:37] so, I'd say new buttons are functionality unless the functionality was previously there [04:37] there;s already opengl mode in the IDE, but it's not enabled unless you switched to it... i want to auto switch to it if you launch the ide with .3ds model filename to open [04:37] micahg: well the editor's cut/copy/paste functionality was already there :P just no buttons for it [04:38] but these are just examples ( I got a long to do list we won't go one by one :P ) [04:40] it's just that 1. I want to make sure this release makes it into Raring 2. I want to fix as many things as possible for this release (to me adding missing cut/copy/paste or not seeing your model when you open it 'cuz you're not in OpenGL mode these are bugs ) [04:40] IANA release team member [04:41] ah =) [04:41] so I have to err on the side of caution [04:41] anyways, I'll try to squeeze as much done as possible [04:42] and then we'll just have to see if the official 0.44 is included or not [04:42] micahg: did you or xnox ever got the chance to look at the SRU ? :) [04:42] nope, I'm a bit behind on Ubuntu work [04:42] ah :( [04:43] actual 64 bit support is working now :P except for the boostrapping (working on that this weekend) [04:43] I also greatly improved the Android support last night =) [04:58] micahg: So if something gets in unstable by say the 5th, could it get synced over to Raring? [04:59] sure [05:01] micahg: 5th is a good date? 11.59pm EST / 5th? ;) [05:01] hmm but I'd need to have the package uploaded before right ? [05:01] damn time :P [05:01] been rushing on this :| [05:01] say, Monday night EST? :) [05:02] should be fine, you only need 6-12 hours to be able to sync from Debian usually [05:02] if I dput it to mentors? :) [05:02] well, I can only help on the Ubuntu side [05:02] hopefully xnox is around :P [05:02] that's why I wanted to plan ahead with you guys ;) don't wanna miss the boat [05:02] micahg: Thank you! [05:52] ESphynx: Personally (and I am a member of the release team) I'd prefer to see you land something a day after feature freeze and ask for an exception and land crap right at the deadline. FFe's are generally approved somewhat liberally right after FF. [05:55] ScottK: k, thanks. even a week later? [05:55] Time is not your friend. [05:55] It's not a step function, but we do get more strict over time. [05:55] hehe :) mind you i wasn't going to be crap, just more time for testing and fixing :) [05:56] Don't take this as "Oh, I have more time, so I can add X, Y, and Z". === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [07:24] good morning === vibhav is now known as Guest98376 [07:51] good morning === almaisan-away is now known as al-maisan === bambee is now known as rperier === Guest98376 is now known as vibhav === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [12:00] ScottK: yes, to 3.9.4 [12:05] * tumbleweed doesn't know why I'm rambling about UDS on ubuntu-devl. I just feel I have to say something... [12:15] tumbleweed, what surpises me is that nobody seems to have read the last paragraph of jonos mail ... its not set in stone [12:15] ogra: of course - maybe that just reminds us that nothing is? [12:16] I don't get this UDS. I don't feel the urge to submit any blueprints (and it doesn't look like anyone else has either) [12:17] I assume it's happening because we want to discuss specific things, but nobody has said what tehy are [12:17] we'll see how it turns out, for now the most important bit is that we need to do planning on a shorter schedule and need the community to participate [12:18] i personally expect physical UDSes again in the future (probably one per LTS or so) but the need for quicker planning cycles is there and we need the community for it [12:19] and thats only possible to something like a virtual one [12:21] it'd easier to engage the community if we felt like we had a clue what was going on [12:21] I don't === Marce_ is now known as Marce === fabo_ is now known as fabo === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === kloeri_ is now known as kloeri === soren__ is now known as soren === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [13:41] ogra_: I read it. It's set in stone for the next two UDS (what would have been one). It would be better if it were at least explained why the sudden need for more planning cycles. [13:42] slangasek has done that to some degree [13:42] ScottK, tabler and phone ecosystem velocity [13:42] *tablet [13:42] That's a category, not a reason. [13:42] I mean it's suddenly so urgent we have to have a UDS in a week? [13:43] What happened we couldn't have had this discussion in a timely manner? [13:43] and there's still nothing scheduled [13:45] having schedule available only the day before the UDS is a shame [13:46] err, did anyone say that the schedule will only be available the day before it? [13:46] I mean, of course UDS schedules change all the time, but surely topics should be appearing? [13:46] where are the gearing up for UDS threads on ubuntu-devel? [13:47] "Since we're short on time we'll probably select the talks on Monday" — Jorge Castro [13:47] mitya57: That's plenaries, not the actual sessions. [13:47] sessions aren't "talks" anyway [13:48] ok, taking my words back then [13:48] ScottK, i can only speculate myself here but i think the distance between the two would have become to small [13:48] (i totally agree that a one week notice is crap btw, but we also werent notified internally earlier than you) [13:49] Do we at least know the time range — i.e. will it be whole day, or European day, or American? [13:50] http://fridge.ubuntu.com/2013/02/26/ubuntu-developer-summits-now-online-and-every-three-months/ [13:50] ogra_: But it's at least the case for you that it's your job to show up, so there's one set of conflicts you don't have. I think most people who work for !canonical can't just do that. [13:51] ScottK, yeah, agreed, i'm not thrilled at all, but i see that we need shorter cycvcles and cant do 4 UDSes per year [13:51] Personally, I already have work commitments that preclude participation. [13:51] o_O I see the timeslots changed from starting @ 4pm UTC to 2pm [13:51] great, evening-night here in Russia [13:52] ogra_: I thought the cycles were already too short to get things done in (re scott's rolling proposal a while ago) [13:52] ogra_: If we need shorter development cycles, let's have that discussion first. It seems to me that the changes to UDS might follow a discussion on release velocity, not preceed it. [13:53] we dont need shorter developemnt cycles but shorter planning cycles [13:54] anyway, I suspect that if we need 4 UDSs a year, there should be a mix of physical and virtual (and possibly the UDSs should be more specific, but that risks dividing the project) [13:54] If we execute on a six month periodic, why would be need to replan the release? [13:57] tumbleweed, right, and nobody said there would never be a ohysical UDS again, jono explicitly said it will be reviewed afterwards [13:58] I think many of the effects it'll have on the project won't be visible in the short-term [13:58] right === bambee is now known as rperier === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [15:11] Laney, ScottK, micahg: hey, I just filed bug 1135860 to update the lxc backport in precise following an sru that just landed in quantal. I wasn't sure whether this was done automatically or not, so figured it wouldn't hurt to file a new backport request. [15:11] bug 1135860 in Precise Backports "Please backport lxc 0.8.0~rc1-4ubuntu39.12.10.2 (universe) from quantal-updates" [Undecided,New] https://launchpad.net/bugs/1135860 [15:11] it's not done automatically. [15:14] stgraber: Done. [15:14] ScottK: thanks! [15:58] @all - having a little bit of confusion with makefiles and pdebuild (20 hours of banging my head against a wall).. the issue seems to be that the DESTDIR is not being passed to the makefile.. so when i attempt to do cp $(DESTDIR) etc, it gives a permission denied error.. but i cant understand why it wouldnt be passed. Any help at all on this would be greatly appreciated [16:11] ScottK: "What happened we couldn't have had this discussion in a timely manner?" - well, some of the designs have been embargoed internally up until this month [16:12] so yeah, hard to have a public discussion about those before now [16:12] (designs+architectures) [16:12] slangasek: Right, but they were known, so that fact that we should have the discussion was certainly known and discussable. [16:12] I understand it may not have been possible to have the actual "UDS" sooner, but it could have been planned out and announced sooner. [16:13] ah, well, as to that, I can only say that businesses don't always make their decisions on a 6-month cadence [16:33] ScottK: Laney: I think we should try to leverage some of the autopkgtest stuff for backports to make backporting newer versions easier [16:34] if we can backport newer stuff to LTSs with less difficulty, LTS only becomes less bad [16:36] Not really. [16:36] AFAICT, Kubuntu is totally screwed. [16:37] well, that's why I didn't say good as we still have the problem of having a new stack that will receive updates [16:38] "a new stack"? [16:38] Xubuntu isn't as screwed as it doesn't have an upstream with a proper 6 month cadence, but yeah, Kubuntu will be screwed [16:38] Laney: KDE, Xfce, GNOME new series [16:39] *major series [16:39] oh, not a backports thing [16:40] Laney: right, I meant as a release [16:41] mmm [16:41] not sure what the flavour story is with all this [16:42] Laney: well, without security support from Canonical, intermediate releases are almost useless [16:42] right [16:42] but it's not really going to be viable to tell people to use the rolling release if they want (say) the latest KDE [16:42] worse than useless in fact, dangerous [16:43] right, the only hope would be to backport the entire KDE stack to the LTS [16:44] or Xfce or GNOME [16:44] transitions in -backports? :) [16:45] No. === al-maisan is now known as almaisan-away [16:45] There's no way I'm testing all the kd4libs rdepends. [16:45] * Laney sniggers [16:45] ScottK: right, that's why I think we should try to leverage autopkgtest [16:46] No, my best thought is LTS + per KDE release PPA. [16:46] I suspect the argument is going to go along the lines of the rolling release has good enough quality so you shouldn't be too scared of telling people to use it if they want new stuff [16:46] Of course by the current rules, that can't be a release. [16:47] you could block all of KDE in -proposed and then release it when it's ready [16:47] Or we could remove everything that doesn't have external rdepends from the archive and make KDE PPA only. [16:47] that would be a shame IMHO [16:48] I agree, but then this isn't my idea. [16:49] the proposal basically turns Ubuntu into Debian + corporate backing [16:50] * micahg wonders if maybe we should look into moving upstream.... [16:50] time based releases :-) [16:50] but we'd be stuck with the same problem, security support [16:50] Laney: right, that too :) [16:50] I'd like to think that something can be worked out with flavours [16:50] even if releasing stops being an option [16:51] probably a good v(shudder)UDS topic [16:51] if people can make it, of course [16:51] flavours can make intermediate releases, sure, but without security support, there's no value the releases as you can't tell regular users to run them [16:52] Laney: however, we don't know if that's what's on the table until teh vUDS, because nobody is saying what sessions are scheduled [16:52] I don't know either, but we'll surely be able to schedule stuff [16:53] if it comes to it, well, it's just a hangout -- JFDI [16:53] micahg: It's why I'm thinking about how to make the rolling release work better (migration blocks etc) [16:54] if the focus is on daily (continuing) quality then in theory it might be more ok for people to run that [16:55] foxx: sorry, we all seem to be too tied up in wondering what Canonical is up to, to answer you. Can you pastebin a build log? [16:55] Laney: I JFhave_other_plans_already. [16:55] yeah I get that [16:56] tumbleweed: sure 1 sec [16:56] not being a flavour lead I'd find it hard to know what would work for you and your users [16:58] (with JFDI I was just referring to the fact that it's not required to stick to any official schedule if it's not working out, not trying to dismiss any difficulties caused by the short notice) [16:58] the other problem with rolling release is the tremendous amount of bandwidth needed for constant updates [17:00] at least that problem is solvable with debdelta [17:00] * tumbleweed has locals who are dying for Ubuntu debdelta [17:00] yeah and pdiffs too [17:00] the indices aren't small either [17:00] I think someone even wrangled a server, but he's not quite clued up enough to generate debdeltas [17:01] and even if the software isn't broken by an update, there could be tremendous UI changes which could disorient users [17:01] yeah, users like to get change on their own terms (well, when tehy admit to liking chaneg at all) [17:01] * tumbleweed -> pub [17:01] that's what a release upgrade or opt-in backport is for :) [17:03] tumbleweed: done - http://pastebin.com/En7k3Mrt [17:03] (makefile and debian/rules included at the bottom) [17:04] you'll also see an 'env' dump being executed in the Makefile.. of which you'll prob notice DESTDIR is not in that list lol [17:08] Laney: "you could block all of KDE in -proposed and then release it when it's ready" - contrary to the stated purpose of, and works at cross-purposes to the goals of, -proposed as we've deployed it [17:08] fwiw [17:09] I was thinking it's somewhat like what was done for the alpha which was just releases [17:09] s/s$/d/ [17:11] Yes, but that was just two days. [17:11] * slangasek nods [17:12] Right. [17:12] the other problem is how do you get testing if it's stuck in -proposed...part of the value of the development release is being able to catch important bugs before end users are exposed [17:12] well, that's moreso a problem with the proposal in general [17:15] right [17:18] It was merely the first thing I thought of ... [17:19] foxx: you're doing stuff in all that should happen install (you only get DESTDIR in install) [18:07] tumbleweed: sorry for the slow reply, was afk. could you point out where im doing stuff in 'all'? from what i could tell, it was in 'install' [18:08] oh wait, is this because i didnt include an 'all:' at the top? (retrying with that in now) [18:10] IT WORKS [18:10] just because i didnt put 'all:' at the top before install [18:11] tumbleweed: thank you so much, i was pulling my damn hair out with this.. debian packaging/makefile is not very noob friendly :( [18:18] Hmm, so if raring-updates is used to roll then there's another potential place to block migrations for flavours [18:21] I'm sure there's potential to use phased updates here somehow too === almaisan-away is now known as al-maisan [19:02] too much mail to catch up on today, with these UDS changes & now suggestions of rolling releases [19:04] * ajmitch really lives in the wrong timezone to discuss stuff on irc [19:09] do you? [19:09] IRC is eternal [19:10] wtf irc has concept of time? :X [19:10] ajmitch: turn off your timestamps [19:11] it does when you want to talk to people as a discussion is happening [20:19] * Laney wibbles ajmitch [20:19] what do you think? [20:22] that it could maybe work for main, but universe quality will possibly suffer, since we're still using those terms :) [20:22] and by main, I should say the ubuntu desktop & not kubuntu, etc [20:23] Laney: I guess I won't be able to buy you a beer at UDS now :( [20:23] I hope we'll still have LTSUDS [20:23] @ Dunedin? [20:24] ajmitch: Kubuntu hasn't been in main since 12.10 [20:25] micahg: right, but the release changes would affect it still as ScottK has pointed out [20:25] Laney: nowhere big enough here for that [20:25] it'll affect anyone producing images [20:25] ajmitch's living room? [20:25] yep, I was just using it as an example [20:25] break out sessions in the bathroom [20:29] * ajmitch doubts he'll be making it to the 3AM UDS sessions next week [20:32] perhaps UDS should run for 48 hours straight with no interrupts [20:33] that'd be fun [20:33] * Laney sends a rambly mail in which he disproves his own proposed scheme [20:33] rambly [20:33] err [20:33] the community team did a 24 hour thing a few months ago, I don't think they got an awful lot done [20:35] lifeless: when is beer-o-clock in a 48-hour straight UDS? [20:36] micahg: every 6th hour [20:39] Laney: I commented in the blueprint about a second britney migration setup [20:39] yeah, just saw [20:39] * ajmitch looks [20:39] when I started writing that email I thought it was a cool idea [20:40] then I started thinking it was less cool [20:40] and now I'm just confused === al-maisan is now known as almaisan-away [20:40] so this is where we start to get more like debian testing [20:40] it → my "use blocks" idea [20:41] where packages can be removed from testing but stay in unstable, unlike our current system [20:41] I suppose they do manage to do that with testing [20:41] but you don't get e.g. the whole of a KDE alpha uploaded to unstable then blocked [20:41] that's what experimental is for (now there's an idea!) [20:42] * micahg sees laney asking for -proposed-proposed.... [20:42] time to rename the ubuntu suites to match debian [20:42] ajmitch: why can't we pick our own movie? [20:43] hah, maybe [20:43] micahg: I mean stable/testing/unstable, don't need to use sid :) [20:43] proposed-proposed which is *blocked* by default [20:43] and you explicitly unblock stuff when you want it to go p-p → p → u → r [20:43] actually, it would probably need to be -updates-proposed [20:43] * Laney overengineers [20:44] no, wouldn't work because you want users to use these alphas [20:44] which is an antigoal for proposd [20:44] hrm, was thinking akin to experimental [20:44] yeah, so not proposed-proposed and no automatic migration then [20:44] * micahg ponders -experimental [20:44] NotAutomatic? [20:44] yeah [20:45] yeah that works really well with our buildds [20:45] just upgrade sbuild, it won't take long [20:45] * micahg eyes rolling backports as possible crack den [20:45] micahg: next you'll be wanting crack-of-the-day grumpy groundhog [20:45] heh [20:46] * micahg wants winter to be over already [20:46] who needs releases when you can build from upstream trunk each day [20:46] ajmitch: +1 [20:47] ajmitch: daily is a little slow [20:47] * micahg waits for ajmitch to make quantum computing affordable allowing everyone to use gentoo style build on the fly for everything [20:48] micahg: but this wasn't my suggestion :) [20:48] https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/GrumpyGroundhog [20:48] heh [20:48] if our tests are good enough! [20:49] we already started doing it with the autolanding business [20:49] yep, and that's because the upstream there has a trunk which is meant to be usable at all times [20:52] interesting === murthy_ is now known as murthy === mapreri_ is now known as mapreri [22:03] hurray got raring running, finally [22:13] so, im a long time user of debian/ubuntu, but first time ive ever done any package maintenance.. is it just me, or does a shitton of work go into package maintenance? ive been working on a single package for three whole days now [22:13] it can keep one busy, it can get easier as time goes on [22:14] hmm - now that ive started playing with it, it feels like all the magic has gone [22:14] and instead has been replaced by spahghetti makefile code :( [22:14] the beginning always takes time [22:14] it's like lots of things - pieces will fall into place with experience [22:15] but depending on the package it can stay a lot of work even when the beginning is done, others are simpler [22:15] got it.. would it have helped if i had prior makefile experience? as in this was the first time id ever made/modified a makefile too [22:15] most likely, yes [22:17] well, my first attempt is now finished.. its basically a build wrapper for Atlassian Bamboo.. theres a script that detects and downloads their latest release, then does all the necessary prep/build work, and spits out a deb file.. if i was to put this on github, would someone here mind taking a quick look and give feedback on things i could improve on? ideally id like to contribute more [22:17] packages and improve my skills on this [22:18] (it works as well, amazingly lol) [22:18] isn'T bamboo commercial? [22:18] sadly yes.. as far as i know, this means it wont make it into the official package tree right? [22:19] yes [22:19] I didn't even know you could download it without an evaluation license [22:19] yeah they changed their system around.. downloads are now public, and u input your license key after install [22:19] my idea for this script was so their devs could just run it, and then provide a 'deb' download option for their customers [22:20] although, it does some nasty hacks.. like placing everything into /opt [22:20] purely because splitting the package out into /usr /var /etc components would have heavily broken it, and fixing would have been... difficult [22:21] opt is a ok place for non free stuff, I think all the stuff you can buy in software center is put there too [22:21] i assume this is heavily frowned upon? [22:21] ahh [22:21] excellent [22:24] foxx: I can do in minutes what once took me hours, so it gets better. [22:24] lol ok - guess its like anything, with practise etc [22:27] * micahg has to try to find some time before feature freeze to help with haskell [22:27] s/haskell/ghc/ [22:28] * Laney too [22:28] I suppose there's a good chance that feature freeze soon might not mean what it currently does though [22:28] ScottK: Can I assume we can get a little more time with the ghc migration since it's not seeded? [22:28] (with proper paperwork filed of course) [22:28] I'm assuming feature freeze will be cancelled. [22:28] * ajmitch looks forward to having everyone try & cram stuff in for an LTS feature freeze [22:28] ah, right [22:29] hmm, question.. in the event that a package install fails for some reason (say it fails to add a user).. and then you try and remove but the postrm fails because it cant remove the user (as it didnt get added to begin with).. at the moment i have to manually useradd to then perform the --purge.. is there a better way to force things like this? i.e. so even if it encounters errors it will [22:29] still remove? [22:30] or does that really fall under the category of user choice, rather than trickery in postrm? [22:31] Don't remove the user on purge. [22:31] ajmitch: nobody has even mentioned what will happen to the rolling release closer to LTS release... [22:32] ScottK: oh, i thought purge was meant to remove everything, including /var/lib data? [22:32] It's almost impossible to be certain a particular user doesn't own any files on the file system, so if you remove it, weirdness ensues. [22:32] tumbleweed: you mean whether the LTS will be branched off & frozen while uplaods still happen for the rolling release? [22:32] Remove all the data, sure, but not the user. [22:32] This is a matter on which there is some debate, but that seems safest. [22:33] okay got it.. what about if i reinstall the package and the user exists... should i just force adduser to ignore user exist errors? [22:33] tumbleweed: maybe I think of things in debian terms too much [22:33] ajmitch: no, I'm thinking in Debian terms here too [22:34] "rolling people" don't like Debian freezes [22:36] stopping automatic migrations from -proposed for an LTS freeze would probably annoy people who want their rolling updates [22:37] I wouldn't be surprised if it was a slowing rather than a block (FeatureFreeze style) [22:37] you just stop the "monthly migration" in the current proposal, but the question would be where can you find the equivalent of t-p-u [22:38] foxx: Yes. [22:39] micahg: Maybe we start uploading to proposed-proposed in that timeframe. [22:40] Actually they could branch off the release into a new derived release at FF if they wanted. [22:40] thanks @all for the advice :) [22:41] ScottK: and then your developers go off and don't work on stabalisation [22:41] tumbleweed: like debian? :) [22:41] and Ubuntu too I suspect [22:41] tumbleweed: It's already perfect according to Rick so no problem. [22:41] yeah it's easy enough for people to just work on stuff & upload while the archive is frozen [22:42] ScottK: it's ok, we've got UDS to discuss it [22:42] if people are not recommending our regular releases to people doesn't that mean even our polished releases aren't stable enough? [22:42] I've always recommended regular releases. [22:42] ajmitch: discuss, but not significantly influence, I suspect [22:43] I don't find the LTS releases significantly different regarding stability. [22:43] neither [22:43] I only prefer them because they have a longer shelf life [22:44] perhaps they're more stable over time as they've had more resources put in for SRUs [22:44] My wife has precise and i have one old desktop running lucid as it won't run newer. [22:44] Other than that, all the desktops/laptops are precise. [22:44] * micahg wonders why ScottK has a SPARC desktop... :P [22:44] err quantal. [22:44] No, sparc last worked on hardy. [22:45] * ajmitch has a lucid desktop at work, and an old laptop still running hardy :) [22:45] I thought sparc last installed on hardy [22:45] It's an old, old intel video chip. [22:45] i740? [22:45] Sparc last installed on gutsy and last worked on hardy. [22:45] i845, I think. [22:45] ajmitch: you know you have about 2 months to upgrade your hardy machine before it's forgotten, right? :) [22:45] It's one of the ones that they dropped support for on 10.10. [22:46] micahg: considering that the laptop needs some pressure applied to the case to power it on if you're lucky, I'm not overly worried about it [22:47] micahg: I have a worrying number of hardy boxes in production - migrating off them won't happen in the next 2 months, either (can't afford DB downtime) [22:47] 540 days uptime, not bad for a laptop with a dead battery [22:49] does anyone know of any reason "/usr/share/debconf/frontend /var/lib/dpkg/info/atlassian-bamboo.postinst configure" would hang in the event of the init.d script calling a nohup command which backgrounds itself? [22:50] is this because i should be using start-stop-daemon and re-writing the init.d for the project, rather than just 1 line wrapping? [22:50] You should be using start-stop-daemon [22:50] tumbleweed: well, the response to that is, why wasn't a migration planned over the last year? :) [22:50] but no need to answer [22:50] it's a common problem [22:51] * micahg heard rumors of etch boxes lying around somewhere in production [22:51] thankfully I migrated off my old debian boxes late last year :) [22:51] * tumbleweed has one of those, too :P [22:51] I have one hardy box. I need to buy new hardware to replace it. [22:51] ScottK: is it normal to have to re-implement an entire init.d, despite the upstream package already containing a semi working one? [22:51] micahg: only rumours? [22:51] Yes. [22:51] lol ffs [22:51] im assuming this is what you guys meant by "some are easy, some arent" [22:52] Well there's a ~standard template you can use. [22:52] daemons certainly belong to the not easy category [22:52] oh, do you have the url? i looked around for "init.d lsb template" but had no luck [22:52] ajmitch: I haven't confirmed anything :) [22:52] oh, is this it? http://www.thegeekstuff.com/2012/03/lsbinit-script/ [22:53] http://paste.debian.net/238955/ is an example [22:53] perfect, thank you [22:53] foxx: /etc/init.d/skeleton [22:54] ahh there we go.. how the hell did i not spot that, thanks [22:54] huh, I've never seen that before either :) [22:54] because you write upstart jobs instead? :) [22:55] actually I will be for the user session stuff [22:55] because you don't work with daemon spawn? :D [22:55] to both of you :P [22:55] micahg: the real answer is, OS releases end up being tied into entire software stack renewal [22:55] Laney: fair enough, but less useful right now if you want a package for debian [22:56] yeah I'd just copy something similar and modify it [22:56] same as for most of the rest of the packaging bits really [22:57] tumbleweed: right, also most companies don't have proper test suites for their applications, so it's not just a 2-4 week qualification for a HW migration but 6-12 months [22:57] does anything use upstart user sessions right now? [22:58] tumbleweed: oh, hrm, you said software, not HW [22:58] i think stgraber only uploaded the first (test) package today [22:58] so no [22:58] okay, here's a question.. ive recently taken inspiration from http://synack.me/blog/deploying-code-with-packages which is basically deploying internal releases (such as python webapps) as .deb files on bare machines.. is this an exceptionally bad idea? the releases will sometimes contain an entire debian chroot, a bunch of compiled binaries etc [22:58] micahg: yes, sw. that said, the only reason we run anything on precise is that some new hardware didn't support lucid :P [22:58] personally i really liked the idea, but not sure if its considered abuse [22:58] Laney: the PPA has been there for the past two weeks, but yeah, nothing's in the archive yet [22:59] right, in archive is what I meant [22:59] foxx: well, of course, it's not something we'd do in a distro, but it doesn't sound so crazy [23:00] foxx: I would have preferred my company doing that rather than spending a year writing a new deployment system (but that was fun, too) [23:00] heh [23:00] yeah that was part of my thought process.. "why reinvent the wheel" [23:00] * micahg is looking forward to lucid/oneiric desktop EOL [23:00] Atlassian Bamboo release workflow combined with saltstack and some bash scripts for automating [23:01] though less so than before [23:01] micahg: lucid desktop goes EOL pretty soon, doesn't it? [23:01] having less supported releases is an obvious win [23:01] * ajmitch should upgrade his desktop at work [23:02] ajmitch: about the same time as hardy server [23:02] good thing I don't have one of those :) [23:03] * Laney 's server is squeeze [23:03] * foxx uses squeeze everywhere [23:04] yeah, I must squeeze -> wheezy [23:04] (and should probably work on wheezy RC bugs too) [23:04] i think we have some ancient routers still running etch too lol [23:04] * jtaylor should also upgrade his work desktop, fedora 11 ... [23:04] * foxx has a feeling hes the only person in here that uses windows as a desktop :/ [23:04] yeah this wheezy freeze feels like it's been dragging on [23:05] my workplace uses fedora as its supported linux desktop, thats just brilliant,by the time IT verified the current release its EOL :( [23:05] hah [23:05] how long do fedora support their releases for? [23:05] 1 or 1.5 years I think [23:06] mm [23:06] Laney: run for DPL & get wheezy released [23:06]