[03:03] <pitti> ok, so is everybody familiar with the current structure of locales?
[03:04] <Kamion> ish
[03:05] <pitti> ok, let's summarize it for the others to read
[03:05] <pitti> previously, package 'locales' shipped all locale definitions; /etc/locale.gen selected the ones which were compiled and available in the system
[03:05] <pitti> now, 'locales' only ships helper scripts, keyboard stuff, etc., but not the locale definitions any more
[03:06] <pitti> and the locale definitions are shipped in the respective langpacks
[03:06] <pitti> langpack postinst/prerm generates/removes the compiled locales now
[03:07] <pitti> this way we can update them after release and, more important, handle them with Rosetta
[03:07] <pitti> that was the way as described by LocalesThatDontSuck
[03:07] <pitti> unfortunately it turns out that they suck differently now
[03:07] <pitti> oh, mvo, you were away
[03:07] <pitti> jbailey, doko, Mithrandir: please ack that you read the summary
[03:07] <mvo> pitti: can you /msg me the scrollback?
[03:08] <jbailey> pitti: ack
[03:08] <doko> pitti: how often is the locale data updated (from your experience)
[03:08] <jbailey> doko: Do you mean from Belocs?
[03:08] <pitti> in breezy we did it a couple of times
[03:08] <pitti> but we didn't ship belocs locales (too late for testing)
[03:08] <pitti> so it would have been better to update more of them
[03:08] <jbailey> doko: Belocs upstream takes a steady stream of patches into their repository.  Not that fast, but occasionally.
[03:09] <Mithrandir> mvo: done
[03:09] <Mithrandir> pitti: read the summary, yes
[03:09] <doko> I mwan, how often are files touched in /usr/share/i18n/locales ?
[03:09] <pitti> so AFAICS we now have three problems:
[03:09] <doko> #s/mwan/mean/
[03:09] <pitti> 1) locales cannot be generated without installing a langpack
[03:09] <pitti> 2) some test suites currently use external locale definitions
[03:10] <pitti> 3) d-i needs locales as well
[03:10] <pitti> seriously, 2) seems like a non-issue to me, but doko wants them back
[03:10] <Mithrandir> I guess the live cd usecase is an instance of 1)?
[03:10] <pitti> 1) is inconvenient
[03:10] <pitti> and 3)  is a real problem
[03:10] <pitti> Mithrandir: right, 1 or 3, whatever
[03:10] <pitti> jbailey: what was the primary reason to ship them in the langpacks instead of 'locales'?
[03:10] <doko> pitti: please don't take 2) too lightly ...
[03:11] <Kamion> by 3) I assume you mean the localechooser build process
[03:11] <jbailey> pitti: As in, why did we split them out?
[03:11] <pitti> doko: somebody still needs to convince me that a static expected output tested against dynamic external data makes sense :)
[03:11] <pitti> jbailey: yes
[03:11] <Kamion> the rest of d-i's problems are due to 1) (namely, if you don't have network access and the language pack isn't on the CD, you can't even get the locale installed so you're doomed to a zillion perl errors on install)
[03:11] <pitti> Kamion: well, that, and that CDs which do not ship the langpack for  the locale the user selects are broken
[03:11] <Kamion> and you'll probably get wrong collation order etc.
[03:12] <doko> pitti: ohh, I don't include glibc and binutils in the gcc testsuite as well. do you think I should?
[03:12] <Kamion> pitti: right, I think that's more or less what I said?
[03:12] <pitti> Kamion: yes, didn't get that line early enough :)
[03:12] <Mithrandir> so 1) and 3) are really the same problem?
[03:12] <pitti> yes, probably
[03:12] <Kamion> Mithrandir: related, anyway
[03:12] <Mithrandir> or 3) is a subinstance of 1)
[03:12] <pitti> so it all comes down to shipping a locales definitions in 'locales' again
[03:13] <jbailey_> Lagging a sec, X hung on me.
[03:13] <pitti> unless anyone has a different great idea?
[03:13] <Mithrandir> just making perl, etc shut up about not being able to set locale is possible, but it doesn't solve the problem, it just hides the symptoms.
[03:13] <pitti> jbailey_: so which use case would break if we put the locale sources back into 'locales'?
[03:13] <doko> pitti: so why not have a second folder for /usr/share/i18n/locales, which you can install updated locale data, and which is search first?
[03:14] <pitti> doko: that's another option
[03:14] <Kamion> Mithrandir: indeed, and I'm concerned that we don't generally test the case where setlocale() fails, at least not on the level of "will your desktop work properly"
[03:14] <pitti> but that would mean to keep the locales data in two different sorts of packages, which I don't like
[03:14] <doko> then you can ship the locale data in locales, and update them in rosetta
[03:15] <Kamion> I'd much rather be able to assert that setlocale() will never fail immediately after a standard installation
[03:15] <pitti> right, that seems easiest
[03:15] <Mithrandir> I think the approach with shipping locale data in locales is fine, but we want it generated from the belocs data?
[03:15] <jbailey_> pitti: The idea of having them split was two fold.  1) Genearting new languages in the future in Rosetta is then an isolated problem.  It doesn't need to affect other languages.
[03:15] <pitti> so my question is what the primary reason was for splitting them out to langpacks in the first place
[03:16] <jbailey_> 2) As we get more and more languages, it means more systems are carrying around baggage that they don't need.  We expect folks to install language packs anyway for all of their language components, so they then have the locale data present.
[03:16] <doko> jbailey_: yes, but you can overcome this kind of problem with a second folder, which is searched
[03:16] <pitti> hm, with a central location we need to update locales for every locale update, right, but that shouln't bite too hard?
[03:16] <doko> jbailey_: /usr/share/i18n/locales is 750k compressed
[03:16] <Kamion> there's another option which sort of addresses jbailey's baggage objections, although I don't like it for other reasons; still I might as well throw it out there
[03:16] <doko> pitti: it's the only package built from the source package
[03:17] <Kamion> create a udeb with all the locale data and have the installer copy in just the relevant locale
[03:17] <jbailey_> What problem are we trying to solve here?  I think I missed that when my X died.
[03:17] <pitti> doko: right, nowadays (was previously in libc, which hurted)
[03:17] <Kamion> it does mean that the locale file is owned by no package
[03:17] <Mithrandir> Kamion: doesn't solve the live cd problem, though.
[03:17] <Kamion> 14:11 < Kamion> the rest of d-i's problems are due to 1) (namely, if you don't have network access and the language pack isn't on the CD, you can't even get the locale installed so you're doomed to a zillion
[03:17] <Kamion>                 perl errors on install)
[03:17] <Kamion> 14:14 < Kamion> Mithrandir: indeed, and I'm concerned that we don't generally test the case where setlocale() fails, at least not on the level of "will your desktop work properly"
[03:17] <Kamion> jbailey_: ^-- basically that
[03:17] <Kamion> (imho)
[03:18] <doko> Kamion: and these files are installed during the installation?
[03:18] <Kamion> and there's an analogous problem on the live CD
[03:18] <Kamion> doko: yes, but as Mithrandir says it wouldn't solve the similar live CD problem anyway
[03:18] <ogra> for edubuntu its more than perl errors, it breaks the complete install ...
[03:18] <jbailey_> Is it correct for us to offer the locales as an installation option that aren't on the CD anyway?
[03:18] <Kamion> jbailey_: not having the locale your environment variables say you do is a fair bit worse than not having any text
[03:19] <jbailey_> It seems like it's a confusing thing to pick, say, French Canadian and not have the resulting system be in French Canadian.
[03:19] <Kamion> jbailey_: yes; very few languages fit on the CD
[03:19] <Kamion> I really don't want to strip our language offering down to that level
[03:19] <pitti> jbailey_: I think so, language-selector can fix things up after installation
[03:19] <Mithrandir> jbailey_: sure, especially since you can set LC_CTYPE to your local locale even though you don't want messages in that locale..
[03:19] <jbailey_> Right, that's what I mean.  We generally expect people to be able to cope with English on the installed system.  I'm wondering if just having locales available on the CD is a bandaid solution.
[03:19] <Kamion> and also localechooser doesn't have access to the contents of the CD yet
[03:20] <Kamion> jbailey_: having the locale data for all languages on the CD has worked fine up until now
[03:21] <jbailey> Hmm
[03:21] <Kamion> as ogra says, not having a locale breaks various package maintainer scripts too
[03:21] <pitti> yes, it looks totally ridiculous, but it works
[03:21] <jbailey> Right, I agree that we shouldn't set a locale to something that's even not available.
[03:21] <jbailey> It breaks things like printing in incredible subtle ways.
[03:21] <Kamion> there's a case for saying that those maintainer scripts are buggy, but (a) the specific case in question is actually kind of non-obvious, (b) we don't test that scenario much
[03:22] <jbailey> (like perl spew winding up in the middle of postscript output)
[03:23] <jbailey> I'm just wondering if the right solution is to delay the whole language conversation until install time when the user has to deal with it anyway.
[03:23] <Kamion> If you look at it from the point of view of a user who was using a supported language from warty->breezy (which is most users - I think we support >> 60% of the globe even without good support for the Indics), it seems like a cut-and-dried regression
[03:23] <pitti> ok, so does anybody see a problem with that: we rebuild all langpacks without locales, stuff all locales back to 'locales'
[03:23] <Kamion> jbailey: we don't have time for that sort of major reengineering in dapper, I'm afraid
[03:23] <pitti> and we keep the locale installation/removal in the langpack postinst/prerm to avoid the conffile?
[03:23] <jbailey> Kamion: I don't think labelling it as a 'regression' is valid here.
[03:24] <Kamion> jbailey: I do, judging from my bugs
[03:24] <jbailey> We break things all the time when chasing feature goals.  People are expected to read the release notes for system changes.
[03:24] <jbailey> This isn't new.
[03:24] <Kamion> Sure, breakage during development is fine, but this *will* be a regression come release.
[03:24] <pitti> btw, NB that this doesn't affect upgrades so much
[03:24] <jbailey> How so?  The release notes say "Install your language pack"
[03:24] <pitti> just mainly new installs
[03:24] <Kamion> in the installer, so of course not many developers care
[03:24] <pitti> since locales for upgraded systems won't automatically be removed
[03:24] <Kamion> jbailey: Edubuntu doesn't even *install*
[03:25] <doko> pitti: when you talk about locale data, you only mean /usr/share/i18n/locales ?
[03:25] <jbailey> Ihave a side concern about applications relying on locale data for their testsuite, I'd like to visit that after.
[03:25] <Kamion> jbailey: also, I'm concerned that the initial desktop is not going to look great if the locale isn't there
[03:26] <Kamion> for such a release note to be a valid get-out, stuff has to work right until you can install the language pack
[03:26] <jbailey> Kamion: If you're expecting that you've installed the system in French, and it comes up in English, it's already not great.
[03:26] <jbailey> I agree that we might not have time to reengineer this or dapper.
[03:26] <Kamion> jbailey: seriously, this has been fine up until now, and we just made it lots worse
[03:26] <jbailey> But I really do wonder if perhaps another question can be gotten rid of from the installer by punting it to runtime.
[03:26] <Kamion> I really don't accept that this is somehow not a regression because we can push more of the job of the installer onto the user
[03:27] <jbailey> I don't buy the argument "It's been fine up until now" as an argument to reverse it in the long term.
[03:27] <jbailey> It needs to really be "The solution is wrong because of FOO"
[03:27] <jbailey> I'm trying to ask whether or not the solution is right, and we just need to do the reenginneering.
[03:27] <Mithrandir> jbailey_: in the (fairly common) case that the user has a network connection, she won't see it come up in English, she'll see it in French because the langpack has been downloaded.
[03:27] <jbailey> Separate from the question of whether this whole thing is right for dapper.
[03:27] <Kamion> OK, the solution is wrong because it makes it unnecessarily difficult for the installer to construct a minimally working system in the locale you requested in the absence of network access
[03:27] <jbailey> Mithrandir: Err.. Really?  My dekstops all came up in English.
[03:28] <Kamion> and it requires slow network access during install even if you *do* have network access
[03:28] <Kamion> language packs aren't small
[03:28] <jbailey> Right, I'll buy those as reasonable arguments then.
[03:28] <ogra> especially in edubuntu, where i have gnome and kde langpacks this is a pain
[03:29] <pitti> jbailey: french is shipped on the isntall CDs, just not on the live ones
[03:29] <Kamion> ogra: the installer only needs to install the base langpack, so that isn't so bad
[03:29] <jbailey> pitti: hmm.  I should check why it didn't work on my ppc installation sometime, then.
[03:29] <pitti> jbailey: yes, that's a bit frightening; if you select the correct language in the installer, it should work
[03:29] <ogra> Kamion, KDE-de is somewhere around 20-30MB
[03:30] <pitti> ogra: uncompressed?
[03:30] <ogra> nope
[03:30] <pitti> ogra: the compressed deb should be around 4 MB
[03:30] <ogra> all the stuff that gets downloaded
[03:30] <pitti> anyway, it's still huge
[03:30] <ogra> yup
[03:30] <pitti> ogra: ah, that's language-support-de, for sure
[03:31] <Kamion> Note that most of our live CDs only have English
[03:32] <ogra> i wasnt talking about the liveCD ...
[03:32] <Kamion> yeah, I know, just saying
[03:32] <jbailey> Is there a threshold at which we should revisit this?
[03:32] <jbailey> I know that the belocs locales are larger in their source form than the glibc locales one are, just because there's so many more of them.
[03:32] <Kamion> basically if the live CD can't get at the locale, we need to make sure that the entire desktop works even in an incorrect locale until such time as you can run the language selector
[03:32] <jbailey> I don't know off hand how much more they are.
[03:33] <jbailey> But at some point, I'd assume that Rosetta will be pumping out new ones with updates and changes every week or so.
[03:33] <jbailey> And as people add more languages, I don't know how big it will get.
[03:33] <Kamion> There's a limit to how much we can do with those in the installer / live CD context anyway ...
[03:33] <pitti> we can still update the locales package with that approach
[03:34] <jbailey> Yup.  I'm just considering size-wise.
[03:34] <jbailey> Like, if it hits a meg, do we suddenly care?  Is there another piece that we need to watch for?
[03:35] <jbailey> (In mirror hit time for stable updates, etc)
[03:35] <pitti> hm, one meg of new data would require us to double the number of locale definitions - that's certainly a lot
[03:35] <Kamion> if it overflows the CD, we care, but that sounds like a very long way off
[03:36] <jbailey> Right, but it might be a threshold at which someone notices and says "Hey, let's think about this", etc.
[03:36] <jbailey> Okay, cool.  Measured that way is fine, too.
[03:36] <Kamion> I'd say if it's << language pack size
[03:36] <Kamion> let me start again
[03:36] <Kamion> I'd say if it's < language pack size, then we're probably OK, considering that language packs are updated (more?) regularly, there are loads more of them, and they're bigger
[03:36] <Kamion> like, an average language pack
[03:38] <jbailey> And I guess relative to langpack updates, updating the locales packages for folks on a regular basis won't be bad either.
[03:38] <pitti> right
[03:38] <pitti> but locales-updates is a bit too much for my taste
[03:38] <pitti> so we should always update the whole lot
[03:38] <jbailey> Yes, I think so.
[03:39] <jbailey> It can still be generated by the same method you use now.
[03:39] <Kamion> pitti: do you have a rough planned schedule for dapper locales/langpack updates?
[03:39] <jbailey> And just generate a whole new package each time.
[03:39] <pitti> Kamion: I'm still desperately wiating for Rosetta
[03:39] <Kamion> mm, understood
[03:39] <pitti> Kamion: but I can update the packs with buildd data at any time
[03:40] <pitti> so, if we say we need locales centralized by tomorrow, I'll build new packs and update locales very soon
[03:40] <jbailey> pitti: jordi and daf each seemed a bit surprised that updates with rosetta had any problem.  It might be worth poking a bit harder.
[03:40] <Kamion> if I manage to arrange for netboot installations to install from breezy-updates, then at least netboot installs will have current locales from the beginning
[03:40] <pitti> not sure how soon, my head is exploding (bad cold), but I'll manage
[03:40] <Mithrandir> pitti: it's blocking a part of me, but I'm on VAC from Wednesday, so not a lot of hurry from me.
[03:40] <Mithrandir> just a slight urgency.
[03:41] <jbailey> I have an ongoing concern about packages build-dep'ing on locales for their testsuites.
[03:41] <jbailey> I think it's still a mistake.
[03:41] <pitti> ok, so shall we do that then? centralize locales again?
[03:42] <pitti> jbailey: I agree, but that's pretty orthogonal, I think
[03:42] <jbailey> pitti: Right.  It's more the "now that we're centralising, this becomes an issue again"
[03:42] <pitti> the centralized file has the disadvantage that we probably need /etc/locale.gen back, or not?
[03:43] <pitti> of course we could also add a 'generate only this locale' function to localedef
[03:43] <pitti> but that wouldn't be updated with locales updates
[03:44] <jbailey> Nothing static should be provided outside of the locales definition, since glibc has no knowledge of those locales.
[03:44] <pitti> jbailey: sorry, I don't understand that
[03:45] <jbailey> perhaps I misunderstood you then too.
[03:45] <pitti> Currently I call localedef manually to generate a test locale (I need a latin1 one for testing)
[03:45] <jbailey> What are you saying wouldn't get updated and might need to?
[03:46] <pitti> that works fine, but when that locale is updated, nothing will rebuild it since it isn't mentioned in any config file
[03:46] <pitti> we got rid of /etc/locale.def, right?
[03:46] <jbailey> Oh, I see.
[03:46] <pitti> and /v/l/locales/supported.d will not mention manually generated locales
[03:46] <pitti> unless we teach locale-def to add a 'local' file there
[03:46] <Kamion> it could, if locale-gen added one ... what you said
[03:47] <Kamion> that's another good point, we have to honour people's requests for legacy locales
[03:48] <Kamion> language packs don't do that because they only generate UTF-8 locales
[03:48] <jbailey> Kamion: How legacy?  We drop old locales that don't make any sense anymore (Like where countries dissapear, etc.)
[03:48] <pitti> so we could put all non-UTF8 locales to supported.d/local during the upgrade from the breezy locales package?
[03:48] <Kamion> jbailey: legacy as in non-UTF-8
[03:51] <pitti> ok, so far this all sounds like that there is only one solution that would not break too bad for now - locales back to 'locales', new langpacks without them, add legacy and local feature to locale-def
[03:51] <pitti> does anybody still have a concern? The discussion seems to die down a bit
[03:52] <doko> pitti: could you summarize?
[03:52] <pitti> I just did
[03:52] <pitti> locales back to 'locales', new langpacks without them, add legacy and local feature to locale-def
[03:52] <jbailey> Just that I'd like to work with someone who knows a bit more about custom locales to help me make sure that the localedef hack does what they need.
[03:53] <pitti> so new langpacks would stil automaticaly handle locales
[03:53] <pitti> jbailey: I think it should be in locale-gen
[03:53] <Kamion> jbailey: I think it should be a locale-gen hack (high-level) rather than a localedef hack (low-level)
[03:53] <doko> pitti: what is "legacy and local feature"?
[03:53] <pitti> doko: when upgrading from breezy, we put all locales not covered by langpacks to /var/lib/locales/supported.d/local
[03:53] <jbailey> Ah, okay.  I was confused when you said locale-def =)
[03:54] <doko> pitti: thanks
[03:54] <pitti> doko: similarly, if you want to generate zh_CN.UTF-8 locally for testing, you don't need to install the zh langpack
[03:54] <pitti> but just do sth like 'sudo locale-gen zh_CN.UTF-8'
[03:54] <pitti> since this is mainly a developer feature, I think that's ok
[03:54] <doko> pitti: let me re-ask: it's not enought to install locales for generating a locale?
[03:54] <pitti> normal users won't care about locales
[03:54] <Kamion> yeah, I have a bunch of locales lying around for man-db testing, similarly
[03:55] <Kamion> which are in just about every encoding under the sun
[03:55] <pitti> doko: right now not, but we have to change that
[03:55] <doko> pittI: ok, thanks for clarifying. so we avoid changing other packages ...
[03:55] <Kamion> doko: just installing the locales package won't generate all possible locales, if that's what you're asking
[03:55] <jbailey> pitti, doko: Right, but that's what I'm saying shouldn't be done for testsuites.
[03:55] <pitti> langpacks install would do --keep-existing, locales upgrade would regenerate them all, right?
[03:55] <pitti> right
[03:56] <pitti> test suites should have synthetic local locales
[03:56] <jbailey> testsuites should not *count* on the data in the locales being consistant from one upload to the next.
[03:56] <Kamion> same as it's been since BenC redid the locales package in Nov 2000
[03:56] <pitti> yep
[03:56] <doko> Kamion: true. but I am able to generate them myself with a b-d on locales (and only that b-d)
[03:56] <Kamion> doko: right
[03:56] <jbailey> You'll already find that in the Belocs locales that things like colation orders have changed for almost all western european locales.
[03:56] <pitti> doko: but that does not prove anything
[03:57] <pitti> doko: python wants to test that a locale with a particular date format spits out that date format; not that the date format in German is 14.01.2005
[03:57] <doko> pitti: ?
[03:57] <pitti> test suites want to test correct output for known input
[03:57] <pitti> not test assumptions about external locale data
[03:58] <pitti> e. g. above date format (it actually changes), or the assumption that 'german' is latin-1
[03:58] <pitti> etc.
[03:58] <doko> jbailey: well, then at least you can ping upstream to adopt their test suites
[03:58] <pitti> right
[03:58] <jbailey> doko: No! It's still a mistake.
[03:58] <jbailey> Because it can still change often.
[03:59] <jbailey> There's no promises around consistancy of that format.
[03:59] <jbailey> s/format/definition/
[03:59] <jbailey> Like right now, de_DE is different on our setup than other glibc based setups.
[03:59] <pitti> ok, that's another discussion
[03:59] <pitti> very interesting, but different
[03:59] <jbailey> pitti: It wsa one of the three concerns you mentioned originally.
[03:59] <pitti> jbailey: right
[04:00] <pitti> jbailey: what I wanted to ask you is, do you see a major drawback with above plan?
[04:00] <pitti> since decentralizing was a major step that had its reasons
[04:00] <doko> jbailey: you won't convince upstream to ship locale data, because they got all they need for windows and mac with the system. why has linux to be an exception?
[04:00] <jbailey> pitti: Nope.  It still leads us to the two goals I really care about 1) I don't want to have to think about locales. 2) I want Rosetta to think about locales.
[04:01] <jbailey> pitti: The separateing into langpacks was a just a logical extension of the rosetta idea that didn't work out.
[04:01] <pitti> right, I agree
[04:01] <jbailey> doko: I suspect you're wrong on that, especially since it actually lets them test what they want to test.
[04:02] <pitti> doko: then they either don't test on windows, or it's similarly broken
[04:02] <jbailey> doko: I wouldn't ship whole locales, I would ship locale fragments that are designed to test particular i18n features.
[04:02] <pitti> ok, thank you for that first part. sounds like a plan. I'll see to implement it ASAP
[04:04] <Kamion> ok, sounds good, thanks all
[04:04] <mvo> thanks
[04:04] <doko> fine, let's delay the test discussion for dapper+1 ...
[04:04] <pitti> doko: oh, spank upstream, tell'em to fix it, kthxbye :)
[04:05] <jbailey> I think it's not so much, delay the test discussion as, it's not a bug when it breaks.
[04:06] <jbailey> And if you try to fix it upstream, they may point out to you that on their systems it works fine.
[04:06] <jbailey> And that's not a bug either.
[04:06] <doko> pitti: unfortunately you have to address this with every upstream ...
[04:07] <pitti> well, with everyone that tests locales
[04:07] <pitti> it seems that you have the honor of maintaining the majority of these :)
[04:07] <pitti> anyway, it's not something we have to fix in a hurry


[17:14] <pleia2> dsmythies: re: openstack guide, I'm pretty sure it's the separate guide that they've been developing, not a part of the server guide, which is why I asked on list
[17:20] <pleia2> the patch you mention doesn't actually talk about openstack directly, it's more about virtualization in general


[01:09] <teward> i have a 14.04 installation and i want it to not suspend when the screen is closed.  setting it to those settings in power management doesn't appear to be doing it.  How do I go about setting those settings?
[02:58] <qwebirc84252> if a liveCD  is inside a CDRW drive and neither the OS nor the eject button is making the CD eject, what can I do to make the CD drive eject the CD (unload the tray)?
[03:00] <holstein> i will shutdown, and try the button at machine boot
[03:00] <iynque> There’s usually a paperclip-sized hole to stick a paperclip in.
[03:00] <holstein> sometimes, there is a little button you can get to with a paper clip..
[03:00] <iynque> ^^^
[03:02] <qwebirc84252> this CDRW is really old - like 15 years old.
[03:03] <qwebirc84252> i don't see the pinhole size hole to put the pin in.
[03:03] <holstein> probably has the hole, then.. the older ones did
[03:03] <holstein> its usually near the eject button..
[03:03] <qwebirc84252> i tried at machine boot but that does not work.
[03:03] <holstein> anyways, if its 15 years old, i may just take it apart, forcefully, remove my media, and trash it..
[03:04] <qwebirc84252> i keep all of my electronics ;-)
[03:04] <qwebirc84252> 4ever
[03:04] <holstein> sure.. you can keep it, then, after you break it apart, and recover the media
[03:05] <holstein> or, just put it on the shelf "as-is" with the media still in it
[03:05] <iynque> heh
[03:05] <holstein> anyways,  dont put any more discs in it..
[03:06] <iynque> You could try searching the specific drive for a manual or something. It might reveal how to open it when stuck.
[03:06] <qwebirc84252> its strange because I have a 16-year old CDROM drive and I see the pinhole on that, but the newer 15-year old CDRW drive does not..
[03:06] <holstein> lol.. i wouldnt refer to either of those as 'newer'...
[03:07] <qwebirc84252> its all relative
[03:07] <holstein> anyways, i wouldnt over think it.. you can try and pry the front cover off, and see if its got a forceful eject, or, ask the company that created it, if they are still around..
[03:09] <iynque> searching for manuals often still works after companies/support disappear. …even if the manual was never online :D
[03:09] <iynque> I’ve found booklets from old cameras, etc.
[03:10] <qwebirc84252> why do some drives have the pinholes and others dont .... shouldn't all of that have been standardized and made mandatory?
[03:10] <holstein> hardware can be created many different ways..
[03:10] <iynque> Meh… including an ‘emergency release’ is admitting you might need one :P
[03:10] <holstein> they dont have them anymore..
[03:11] <holstein> i dont install optical drives on machines anymore.
[03:13] <qwebirc84252> well, i'm trying to make use of this almost 16-year old machine for recording TV with a tuner card, and this drive used to work until continuous reading from the drive seemed to have caused it to ?malfunction internally?  is this possible?  - causing permanent damage to the drive?
[03:13] <holstein> qwebirc84252: that drive is quite old.. nothing about lubuntu will be able to prevent it from opening. but, if you cant get it to open at boot, before the OS loads, its likely just stuck in there, and failing
[03:14] <holstein> the ones that i have heard that are failing sound like that. if the question is "did the lubuntu iso break my optical drive?" i have never experienced that..
[03:17] <qwebirc84252> right, but by stuck, do you mean it is physical issue of the CD preventing drive opening ..  because I don't think this is the case, since it was reading from the drive right before this problem occured, unless the spinning of the CD caused it to get physically stuck.
[03:17] <qwebirc84252> I suspect that the drive somehow overwrote the firmware or the memory on which the firmware is stored has gone bad, but I know nothing about how such electronics work..  so that is a wild guess.
[03:17] <holstein> i dont think so
[03:17] <holstein> i have found, with the several drives i have that fit that description, that they just failed..
[03:18] <qwebirc84252> which do you think is "not so"...  physical issue or firmware issue?
[03:18] <holstein> but, you can ask the company that created it how to check the firmware. i fyou feel that is the issue
[03:18] <holstein> qwebirc84252: i do not think you have a firmware issue on that old defice
[03:18] <holstein> device*
[03:18] <holstein> i think its old, and failing.. as, many of mine are, of that age
[03:19] <qwebirc84252> oh, so then u think the CD has phsyically caused the tray from ejecting due to some phsyical jam?
[03:19] <holstein> qwebirc84252: i do *not* think it has anything to do with the disk
[03:21] <qwebirc84252> by "drive failing", how exactly does this happen?   power failure?  electronics damaged?  ..???
[03:21] <holstein> i have gotten old, recycled hardware, of that "vintage" out, and the disks, any disk, will sound like its spinning up and down.. sometimes, i will wait on them, and something will install
[03:21] <holstein> if i have another, i just get another one out, and trash that one
[03:21] <holstein> they are old, and fail.. parts fail, that, im sure one can repair.. or, have repaired. at quite a bit more than the device is worth
[03:22] <holstein> qwebirc84252: they get old.. they spin fast, and have moving parts.. *all* drives will fail..
[03:22] <qwebirc84252> right, but I'm now all out of optical IDE drives, and this is the only one I was hoping to reboot with.
[03:22] <holstein> qwebirc84252: what have i done? i have used the plop live iso, in a dying drive, to boot a USB stick on legacy hardware
[03:22] <qwebirc84252> the other CDROM IDE drive does not allow me to boot using another copy of the livecd for some reason
[03:23] <holstein> i'll venture a guest, its related to its age..
[03:23] <holstein> a guess*
[03:23] <qwebirc84252> the standard boot error message of OS not found...
[03:24] <holstein> right.. i have see those, back when i was dealing with that.. the best stratedgy i could come up with was, just have a lot of spare parts, and keep moving
[03:24] <holstein> try different jumper settings, and bios settings. try booting USB with plop.. etc
[03:24] <qwebirc84252> were old (~1999) CDROM drives incapable of acting as boot devices?
[03:24] <holstein> qwebirc84252: it'll be more about the configuration inside the machine, and the bios
[03:25] <holstein> there were jumpers.. and the cables can be bad.. the connectors..
[03:25] <qwebirc84252> when I get to the BIOS menu, the SYSTEM INFORMATION tab actually recognizes the device, but yet its not able to boot from it...
[03:26] <qwebirc84252> so jumpers at the wrong slot can prevent booting?
[03:26] <holstein> ok.. what *can* it boot from?
[03:26] <holstein> i dont know what is preventing boot, friend. i dont have that hardware here. im just saying, i would try *all* combinations, and just try other drives, since, i have other parts laying around
[03:26] <qwebirc84252> itit used to be able to boot from the CDRW drive in fact,just this morning, before constant reading from the CDRW drive caused it to go bad...
[03:26] <holstein> i mean, if you dug this out of the trash, anything can be wrong with it
[03:27] <holstein> qwebirc84252: i dont think that has been, in my opinion, and findings, what caused the drive to fail.. but, rather, a symptom of it failing
[03:28] <holstein> you are saying "the drive was spinning up and down, reading the iso, and that broke it.." and im saying "the drives, when they are failing, can sound like they are spinning up and down.."
[03:30] <holstein> anyways, what would i do? get something you know used to boot on that hardware.. even if its an old windows install iso..
[03:30] <qwebirc84252> no, it succesffully loaded the lubuntu splash and everything...
[03:31] <qwebirc84252> splash screen
[03:31] <holstein> cool. so, enjoy!. thats what its supposed to do..
[03:31] <qwebirc84252> right, but failed after that..
[03:31] <holstein> what failed after what?
[03:31] <qwebirc84252> right after
[03:31] <holstein> anyways, there are other iso's..
[03:32] <holstein> !mini
[03:32] <holstein> you can get the smallest iso, and read less from it, getting the installation going, *then* add lubuntu/lxde or whatever
[03:32] <qwebirc84252> right after splash screen loaded, constant reading from drive, waited for 15+ minutes with drive constantly reading (drive read light constantly on).
[03:32] <holstein> lol
[03:32] <holstein> i have waited *hours* on older hardware like that
[03:33] <holstein> you can try the smaller iso, though.. and you should get less reading from it..
[03:33] <holstein> sounds like, what i would expect from older hardware that is failing..
[03:35] <qwebirc84252> is the minimal cd a live cd that allows access to ubuntu repositories for additoinal installing while in live mode?
[03:35] <holstein> the minimal iso, is as i, and the link describe.. its small, and minimal. it will not read much from the optical drive
[03:35] <holstein> the end result is the same..
[03:35] <qwebirc84252> because I do not want to install anything (in fact I do not even have an IDE disk on that machine to install to)..  i just want to run with the functionality of the live cd in live mode.
[03:36] <holstein> qwebirc84252: is *is* ubuntu.. so, yes..  access to the same ubuntu repositories.. official ubuntu
[03:36] <qwebirc84252> right, but is the minimal cd a live cd, or is it only for installing?
[03:36] <holstein> qwebirc84252: its not a live iso
[03:36] <holstein> i dont think you will want to run live iso's like that on older hardware
[03:37] <holstein> but, if i were, i would look at puppy or something that loads in ram
[03:37] <qwebirc84252> with the "toram" option, all of the livecds contents are copied to ram, making the speed much more tolerable.
[03:37] <holstein> qwebirc84252: cool.. enjoy!
[03:38] <holstein> the lubuntu iso's are really not for that, though, are they?
[03:38] <holstein> its a matter of getting the proper tool corrrect? since, you are having issues with the tools?
[03:39] <holstein> anyways, the live iso's here are more about checking the hardware support, or recovery.. etc
[03:39] <qwebirc84252> but minimal will not help me since it is not live, and other minimal distros like DSL, TCL, puppy etc. do not come preloaded with the tv tuner drivers for my tuner card (and in some cases not even the dvb-apps) so that I could record TV while loaded into the live mode.
[03:39] <holstein> but, you are welcome to try and use them as you want.. i would want a "better" live media.. plop, and using the live iso from usb
[03:40] <holstein> qwebirc84252: sure.. so, dont use the minimal.. and, again, you can install to usb, and make whatever you you need with an actual install
[03:40] <holstein> nothing you are doing needs, or, will benefit from running live..
[03:40] <qwebirc84252> the live media are also very useful if you do not want to spend the time nor the disk(s) installing onto, and just want a fast solution to getting much OS functionlity.
[03:40] <holstein> you would think?
[03:41] <holstein> but, its actually just a matter, again, of meeting the needs. and if it were, you would be off using it..
[03:41] <holstein> i can do an install in about 7 minutes, and add all that software in a few after that
[03:41] <ianorlin> holstein: I think it depends on the speed of disks you are writing to
[03:42] <qwebirc84252> again, its not really about the install time, I also like the ability of loading everything into RAM for fastest access times, given the super-old hardware.
[03:42] <holstein> qwebirc84252: do it.. to the "toram" option on the installed OS
[03:43] <qwebirc84252> plop is proprietary software.  is there a free-software alternatie...?
[03:43] <qwebirc84252> alternative*
[03:44] <ianorlin> qwebirc84252: are you using coreboot  if not your bios code to boot from usb might be nonfree unless uefi has some wierd open source project with horrible coding starndards behind it
[03:44] <ianorlin> as I don't think the code to boot from usb on bios is free
[03:45] <holstein> there are many ways to implment booting usb on legacy hardware..
[03:45] <qwebirc84252> that's true...  bios is not free, but still, i'm sure there should be some FS alternative... there is almost always some FS alternative for everything nowadays
[03:45] <holstein> check around for whatever it is you seek.. when i want to boot usb on legacy hardware, i use plop, and it works great
[03:46] <holstein> https://help.ubuntu.com/community/BootFromUSB if grub is acceptable..
[03:48] <qwebirc84252> so, with the grub floppy, it is possible to boot into liveUSB?
[03:49] <holstein> try it, and see
[03:49] <holstein> nothing about lubuntu is preventing you from booting it as you need, or, care to implement
[03:49] <holstein> when i read about what you are trying to do, i would personally just do a normal install to an internal drive, and have the machine up and running soon
[03:51] <ianorlin> argh I really don't like setting up grub manually that way that is not fun for me and could probably improve the lubuntu manual a lot in the time I spend tweaking somethign taht fiddly
[04:12] <qwebirc84252> holstein:  correct me if im wrong but it seems like SBM is a FS alternattiv to PLOP:  https://help.ubuntu.com/community/SmartBootManager  ?
[10:32] <work_alkisg> qwebirc84252: I haven't read all the chat, but if you're trying to install *ubuntu to an old pc that doesn't have a cdrom and can't boot from usb, this one-line netbooting method will do it:
[10:32] <work_alkisg> https://wiki.ubuntu.com/LiveCDNetboot#Automation_script
[10:33] <alkisg> You do need another pc in the house though, to host the .iso via the network (with one command)
[13:11] <pmatulis_> anyone here running wily getting double icons in the indicator applets thingy?
[13:31] <holstein> qwebirc84252: try it, and see, friend...
[13:39] <krytarik> pmatulis_: LP bug 1488660.
[13:47] <pmatulis_> krytarik: thanks
[14:14] <Namete> hi
[14:14] <Namete> i tried to post a problem in the forums and i keep getting banned
[14:15] <Namete> i have a problem on Lubuntu
[14:15] <Namete> can anyone help me?
[14:16] <Namete> no?
[14:16] <Namete> just another sad irc chat :))
[14:16] <Namete> ubuntu comunity suck big time
[14:23] <NOOB> why you figgure banned all the times
[14:23] <NOOB> ???
[14:23] <NOOB> mysterious
[21:15] <TaZeR> hey does lubuntu use LXQT yet or is there an option to?
[21:16] <TaZeR> oh nvm just read news "Work continues on integrating LXQt into Lubuntu, but we'll likely not see it released until 16.10 (Y cycle). If you're curious about development, check out the blueprints. "
[21:16] <TaZeR> cant wait!
[21:16] <vikingredwolf> :)
[21:16] <vikingredwolf> we're anxious too
[21:16] <vikingredwolf> but I'm afraid we need to wait
[21:17] <vikingredwolf> PPAs are being re-built so using them will result in a bad outcome for your system
[21:17] <vikingredwolf> don't worry, TaZeR, you'll see the news :)
[21:17] <TaZeR> awesome


[07:29] <kfupmer[m]> .
[11:02] <Iamthehuman1> day #34 on US and still going strong .. I've almost internalized what needs to be restarted after the TB3 cable accidentally comes off (the external sound card is in an USB port on the doc). Thank you for the awesome work, keep going
[11:04] <Iamthehuman1> *on the dock, 'scuse my dysscribia


[12:04] <JustCurious> Hello, I am doing some tests with Ubuntu 12.04 (EOL version), I am trying to install the newest kernel (3.4), this is, the newest kernel for that version. I've downloaded the kernel .deb on http://kernel.ubuntu.com/~kernel-ppa/mainline/ and I've installed them (amd64), but when I reboot it freezes, so I have to restart and pick start Ubuntu with the current kernel, 3.13.0-32. :-( Any idea please?
[12:09] <oerheks> As it is EOL, out of support, why should we answer?
[12:10] <JustCurious> no, of course you should not
[12:10] <JustCurious> maybe it's the wrong chan to ask
[12:11] <oerheks> anyway, you need 3 packages, and install them the correct way https://wiki.ubuntu.com/Kernel/MainlineBuilds#Installing_upstream_kernels_.28manually.29
[12:15] <JustCurious> thanks
[12:15] <JustCurious> I've installed them already


[15:42] <greg-g> hope all of you are doing well with all of this shit
[15:43] <Scary_Gu1> https://babylonbee.com/news/nations-nerds-wake-up-in-utopia-where-everyone-stays-inside-sports-canceled-social-interaction-forbidden
[15:44] <Scary_Gu1> I'm peachy :D
[15:47] <cmaloney> Heh
[15:59] <_stink_> greg-g: how's CA?
[16:00] <greg-g> _stink_: bars and such are closed down as of yesterday, school is out this week, but most likely for longer
[16:00] <greg-g> no TP to be found :)
[16:01] <greg-g> and my bidet delivery is delayed!
[16:01] <_stink_> table flip!
[16:02] <_stink_> you probably heard that bars/eateries are closed for dine-in in MI
[16:02] <_stink_> as of today
[16:02] <_stink_> i am looking at 4 weeks of WFH with the kids here
[16:02] <_stink_> wife's situation is unclear
[16:03] <jrwren> its day 3 and my family is already at each others throats.
[16:07] <Scary_Gu1> Still can get in the car and go for a nice drive at least
[16:24] <jrwren> i'm lucky to live within walking distance of 3 nice wooded parks, but even those get boring, so I'm looking forward to driving to other parks for roaming wooded trails.
[16:36] <cmaloney> https://gettogether.community/events/4724/coffee-house-coders-regular-meeting/
[16:37] <cmaloney> We're meeting online on Wednesday
[16:37] <jrwren> oh fun!
[16:37] <cmaloney> and for the forseeable future
[17:16] <_stink_> works better for me :D
[17:42] <greg-g> setting up a jitsi? :P
[17:43] <cmaloney> Why, yes. :)
[17:45] <Scary_Gu1> https://i.4cdn.org/pol/1584378841264.jpg for those who don't want to click on it, it says "a couple of weeks of isolation with the family, what could go wrong?" and has a photo of Jack and the family driving up to The Overlook Hotel
[18:07] <cmaloney> Yeah, saw that one
[18:27] <_stink_> hah
[18:40] <greg-g> perfect
[18:41] <greg-g> tbh, we thought about doing a camping trip during this :) but we have too much house stuff to do to really take time away from home, sadly
[18:41] <greg-g> I saw ri<tab> (what?! not here?!) is doing that. took the trailer out with the boy for a trip south
[18:45] <cmaloney> yeah, ri<tab> darted off so I think we have non-Canonical folks only in here
[18:45] <cmaloney> or former Canonical
[21:37] <mrgoodcat> rsvp'd
[21:37] <mrgoodcat> haven't done chc in a while
[21:42] <cmaloney> Awesome! Welcome back. :)


[00:00] <jml> mwhudson: I had a little trouble with it yesterday.
[00:00] <mwhudson> jml: oh, ok
[00:00] <mwhudson> jml: i thought you were clone('null:') ing
[00:00] <mwhudson> or am i out of date
[00:01] <jml> mwhudson: that was my second pass at a solution
[00:02] <jml> mwhudson: after I couldn't find the repo format controls for create_branch, ISTR
[00:02] <spiv> jml: tried sprout('null:')? :)
[00:02] <mwhudson> spiv: blows up with looms and weaves
[00:02] <spiv> Oh, really?
[00:02] <jml> spiv: clone('null:') works great except for looms & weaves. haven't tried sprout
[00:02] <spiv> I'm not totally shocked by looms failing, weaves surprises me though.
[00:03] <mwhudson> spiv: it might be a null:/None thing
[00:03] <jml> spiv: weaves raises... RepositoryUpgradeRequired if you force no working trees...
[00:03] <jml> and NoSuchRevision if you pass 'null:' without caring about working trees.
[00:04] <spiv> Interesting.
[00:04] <jml> None works, but I didn't check that the new branch was empty
[00:04] <jml> (it might have just cloned the whole thing)
[00:05] <jml> when I found out that looms failed I gave up and moved on to fixing bugs.
[00:05] <jam> spiv: Is poolie not around?
[00:06] <jml> spiv: anyway, what were you going to suggest?
[00:06] <spiv> jam: not that I've seen
[00:06] <jam> jml: "b = bzrlib.branch.Branch.open('foo'), b.clone(NULL_REVISION)" ?
[00:07] <jml> jam: rather than bzrdir.clone?
[00:07] <jml> interesting.
[00:07] <jam> jml: well, it is something to try
[00:07] <jam> Looms is a bug in looms
[00:07] <jml> jam: yeah.
[00:07] <jam> and I don't care about weaves :)
[00:07] <jam> jml: you can also "bzr uncommit -r 1"
[00:07] <jam> And I *think* "bzr uncommit -r 0"
[00:08] <jam> but I'm not sure about '0'
[00:08] <jml> jam: I'm not sure if I'm allowed to not care about weaves yet.
[00:08] <jam> jml: alternatively
[00:08] <jam> bzrdir._format.initialize('target')
[00:08] <jam> bzrdir.repository_format.initialize(target_bzrdir)
[00:08] <jam> bzrdir.branch_format.initialize(target_bzrdir)
[00:08] <jam> Go back to the raw Format objects
[00:09] <jam> and tell them to create something new
[00:09] <jam> It may not work on pre-metadir, though.
[00:09] <mwhudson> with appropriate care for Remote*
[00:09] <jam> And I don't have much of an idea about looms
[00:09] <jam> spiv: ok, so no standup today? Was there one last night? I felt like I missed it, but didn't see any actual chatter
[00:10] <jml> jam, spiv: thanks. I'll have a play.
[00:10] <jml> maybe I'll end up patching loom or something.
[00:10] <poolie> hello jam, spiv, sorry i'm late
[00:11] <spiv> poolie: hello
[00:11] <spiv> jam: not so far, but now poolie is here it'd be good to do one...
[00:12] <spiv> poolie: standup?
[00:12] <poolie> sounds good
[00:12] <jam> jml: though you are right, I don't think Branch5/6 (regardless of looms/weaves) truly supported cloning at the NULL_REVISION
[00:13] <jml> *nod*
[00:13] <spiv> jam: So about landing my trivial -Dhpss fix on the 1.7 branch...
[00:13] <spiv> jam: what should I do with the NEWS entry?  Start a bzr 1.7rc2 section?
[00:13] <jam> spiv: I'm trying to land it now
[00:13] <jam> look at PQM
[00:14] <jam> PQM is backed up by a merge from vila
[00:14] <spiv> jam: ah.
[00:14] <jam> which says "success" but is still stuck
[00:15] <spiv> jam: ok, I'll wait for that to sort itself out then :)
[00:15] <spiv> jam: thanks
[00:33] <thumper> is there a bzrtools coming soon that won't be tried to be removed with bzr 1.7rc from the PPA?
[00:45] <abentley> thumper: I'll release bzrtools 1.7 tonight.
[00:46] <thumper> abentley: cool
[00:58] <Gioacchino> good night
[01:47] <jml> can someone land my http smartserver tweaks patch please?
[01:58] <spiv> jml: If someone unwedges pqm I will...
[02:00] <poolie> i don't see stubub yet
[02:00] <poolie> stub
[02:00] <poolie> i'll ask steve-in-canberra
[02:03] <jml> poolie: Steve-in-London, I think you'll find
[04:39] <Yasumoto> Hey guys, is there a way to get just the files when you're making a new branch, rather than all the files inside a folder?
[04:40] <RAOF> Yasumoto: I'm not entirely sure what you're asking for.  Are you saying that, rather than 'bzr branch foo bar' branching 'foo' into a 'bar' directory, you'd like to branch 'foo' into the current directory?
[04:44] <Yasumoto> RAOF: actually, I may be asking about bzr branch foo bar
[04:45] <Yasumoto> (a friend and I are learning how to use bzr for an assignment together)
[04:46] <Yasumoto> cool, thanks RAOF! :)
[04:49] <RAOF> Heh!  Remember, 'bzr help <command>' often contains useful information, and 'bzr help commands' will list all the commands :)
[04:51] <Yasumoto> ooh, cool
[04:51] <Yasumoto> thank you
[05:08]  * jml writes a function that does get_stacked_on_url that return None when there isn't one.
[05:42] <poolie> jml, yeah, i'm not sure if that was the best api
[05:42] <poolie> to raise an error
[05:42] <poolie> spiv, how's it going?
[05:43] <poolie> i'm still trying to get my desktop back up :-/
[05:43] <jml> poolie: well, the advantage of the current API is that I *can* write such a wrapper.
[05:43] <jml> poolie: if it returned None and I wanted rich errors raised, I'd be in trouble.
[05:43] <poolie> hm
[05:44] <poolie> if it returned None for more than one case, yes
[05:44] <spiv> poolie: pretty well.  I came across a vim window that reminded that I had a fix for a TooManyConcurrentRequests bug, so I finished that and fired it off.
[05:44] <jml> right. So I'm returning None if it's NotStacked as well as if one of the formats doesn't support stacking.
[05:45] <jml> because for most of what I'm doing the two are equivalent.
[05:45] <poolie> ok, good
[05:45]  * jml heads out
[05:45] <poolie> spiv, can you send your startup-time branch too (if you didn't already)
[05:46]  * spiv re-reads what he actually did in that branch to make sure there's nothing outrageous...
[05:51] <Yasumoto> hey guys, my friend's trying to push a branch onto launchpad (he just made an account!) but we're having issues with the windows client
[05:51] <poolie> hi Yasumoto
[05:51] <poolie> what specifically
[05:52] <Yasumoto> we found some bugs ( https://bugs.edge.launchpad.net/bzr/+bug/198092 ) about bzr launch-pad login
[05:52] <Yasumoto> but it's saying Autentication type (password) not permitted.
[05:53] <Yasumoto> bzr: ERROR: Connection Error: Unable to authenticate to SSH host as<EMAIL_ADDRESS>Bad authentication type (allowed_types=['publickey'])
[05:54] <Yasumoto> we're about to try it from cygwin..
[05:56] <spiv> Yasumoto: Launchpad's code hosting only allows publickey auth
[05:57] <spiv> Yasumoto: so you need to add an SSH public key to your Launchpad account
[05:57] <spiv> Yasumoto: https://launchpad.net/people/+me/+editsshkeys
[05:57] <Yasumoto> spiv: yeah, we've got the public key on launchpad
[05:58] <Yasumoto> hm, now in cygwin
[05:59] <Yasumoto> 1 sec
[06:01] <Yasumoto> hm, so I've got the private key in ~/.ssh/id_rsa and the public key in ~/.ssh/id_rsa.pub
[06:02] <Yasumoto> and it's giving us "bzr: ERROR: [Errno 0] Error"
[06:02] <spiv> Does "sft -v<EMAIL_ADDRESS>show that it is using the key?
[06:03] <spiv> Er,
[06:03] <spiv> "sftp" rather than "sft"
[06:03] <spiv> Also, can you pastebin the traceback in your ~/.bzr.log file corresponding to the "Errno 0" error?
[06:04] <Yasumoto> spiv: good call on the sftp, it looks like it's giving us permissions errors
[06:04] <Yasumoto> it's ignoring the private key
[06:04] <Yasumoto> we'll change those, 1 sec
[06:07] <Yasumoto> hm
[06:07] <Yasumoto> it's connecting now
[06:08] <Yasumoto> however it's not accepting his passphrase
[06:11] <Yasumoto> spiv: thanks for your help, by the way :)
[06:12] <Yasumoto> he's playing around with things a bit for now, I'll let you know if we make progress
[06:27] <TheMuso> .c
[06:57] <vila> Good morning bazaar (with a special thought for pqm)
[07:14] <AfC> If you have a file added & committed to a branch, and later add a pattern to .bzrignore which happens to match it, it will still be governed as a versioned file, correct?
[07:21] <vila> AfC: yes
[07:21] <jml> hello everyone.
[07:21] <vila> hi jml
[07:22] <jml> I would like to suggest that autopack speed become the #1 most important bzr issue.
[07:22] <jml> kthxbye
[07:22] <jml> vila: hello. how's things?
[07:23] <vila> jml: very very good :) Except for the fact that pqm is so proud of my last submission that it don't want to let it go (which is embarassing :)
[07:23] <jml> ha!
[07:23] <vila> especially for jam and spiv who are trying to get *their* submissions accepted :)
[07:24] <vila> pqm: stop thinking, I don't want it to be merged in the 1.7 branch, go go go
[07:26] <poolie> hee hee
[07:26] <poolie> is it still stuck?
[08:21] <vila> poolie: pqm unstuck and my submission was even accepted. Did anybody diagnose the root cause ?
[08:24] <poolie> vila, stub killed a stuck ssh process
[08:24] <poolie> he didn't tell me what process it was specifically
[08:26] <vila> poolie: thks for feedback, I think pqm is just feeling anxious when it hears us talking about running the test suite on multiple platforms, someone should reassure it... I tried to be more gentle next time though
[08:27] <poolie> heh
[08:59] <spiv> Turns out it wasn't so hard to cut down the round trips of an empty push.
[09:02] <poolie> :-)
[09:02] <poolie> yay
[09:02] <poolie> guilhembi, hello
[09:04] <guilhembi> hello poolie
[09:06] <guilhembi> vila: Bonjour; do you have time for a short question regarding "'bzr missing' does not show merged revisions" ?
[09:06] <vila> guilhembi: sure
[09:07] <guilhembi> vila: Thanks. You said, "fix committed", but, so, what does "bzr missing" show now? output similar to "bzr log" indented revisions?
[09:07] <vila> yes
[09:08]  * guilhembi rushes to try that
[09:08] <vila> you can try with the associated branch
[09:08]  * guilhembi is evil, he tries with another branch
[09:09] <vila> guilhembi: feedback welcome about response times since this makes missing O(history) when --include-merges is used (but work will continue to remove that)
[09:11] <poolie> guilhembi, when he said 'with that branch' he meant the fix is in the branch connected to that bug
[09:12] <poolie> i think it's not in trunk yet
[09:12] <guilhembi> sigh
[09:13] <vila> poolie, guilhembi : poolie is right, tweaks were required, I'm working on it right now
[09:14] <vila> guilhembi: sry, I misunderstood you, I thought you meant that you will merge my fix in your private bzr
[09:14] <spiv> I think I just found a bug we really ought to fix before 1.7 :(
[09:15] <vila> so 'fix committed' means that the fix is available somewhere (often in the branch associated with the bug), while 'fix released' means that the patch has been merged to bzr.dev and the series indicates in which released version the fix is available
[09:16] <guilhembi> vila: but there is time between merge into bzr.dev and building of a release,
[09:16] <guilhembi> in this time window what is the status of the bug?
[09:17] <vila> 'fix released'
[09:17] <guilhembi> vila: isn't this misleading?
[09:17] <guilhembi> 'fix released' though not yet in a release?
[09:18] <poolie> yes
[09:18] <vila> yes, it is
[09:18] <poolie> the bug statuses are not quite labelled right
[09:18] <poolie> spiv, want to call me?
[09:20] <spiv> poolie: just about to finish mailing the list with details
[09:20] <poolie> ok
[09:20] <spiv> poolie: short answer: https://bugs.edge.launchpad.net/bzr/+bug/269214
[09:20] <poolie> thanks for finding it
[09:21] <vila> For me, 'fix released' means 'this bug is available beginning with the milestone indicated'. If that milestone points to a release "in the work" it means the fix is available in bzr.dev only or in a release candidate if one exists at that point
[09:21] <spiv> Well, John and someone on the list noticed it really, I just happened to put a couple of pieces together.
[09:22] <guilhembi> vila: I tested --include-merges on a pair of MySQL branches and it looks like working
[09:23] <spiv> poolie: mail sent.   Hmm, sounds good :)
[11:11] <dereine> is there something like codespaces for bazaar?
[11:11] <lifeless> what is a codespaces
[11:13] <james_w> dereine: you might want to look at launchpad.net
[11:14] <dereine> mh opensource...
[11:14] <dereine> i would like to publish it but...
[11:14] <dereine> but thanks for the typ
[12:19] <frk2> can somebody help me out with the lp protocol please?
[12:20] <frk2> mine seems to skip the http_proxy variable completely
[12:20] <frk2> is there an alternate way i can access my launchpad bazaar repo
[12:22] <james_w> frk2: "bzr launchpad-login <your lp id>" will make it use bzr+ssh://
[12:23] <frk2> im doing bzr push lp:~fkhan/+junk/test
[12:23] <frk2> seems like its throwing an exception on python xmlrpc lib
[12:24] <james_w> bug 186920 for the proxy issue I think
[12:24] <james_w> using launchpad-login should make it avoid this
[12:24] <frk2> is there a work around?
[12:25] <frk2> my dns works fine
[12:37] <frk2> i have worked around it by using bzr+ssh://bazaar.launchpad.net
[12:37] <frk2> that works
[12:37] <frk2> however it says no such user on launchpad
[12:37] <hsn_> http://pastebin.ca/1200966 you know why shelve doesnt work,  i need to create some directory?
[12:37] <frk2> my local username is not the same as my lp username
[12:41] <frk2> am i being retarded here?
[12:41] <james_w> frk2: run "bzr launchpad-login <your lp username>" and then continue using "lp:"
[12:41] <james_w> hsn_: you'll need to put it somewhere other than pastebin.ca if you would like me to look at it, I can't access that site
[12:42] <frk2> james_w, connection refused - same problem
[12:42] <james_w> frk2: "no such user"?
[12:42] <frk2> the exception happens in python xmlrpclib
[12:43] <frk2> no, the earlier problem with lp:
[12:43] <frk2> i am being a proxy
[12:43] <frk2> behind
[12:43] <james_w> but you've run "launchpad-login"?
[12:43] <frk2> yes
[12:43] <james_w> odd
[12:43] <james_w> does the end of the backtrace have "httplib.py"?
[12:43] <frk2> yes
[12:44] <frk2> i read somewhere that using lp makes bzr do a xmlrpc lookup
[12:44] <frk2> which is not proxiable
[12:44] <james_w> ah, true
[12:44] <james_w> use<EMAIL_ADDRESS>then
[12:45] <frk2> :)
[12:45] <frk2> thats all i was looking for
[12:45] <frk2> thanks!
[12:46] <frk2> done. just trying out bazaar- looks way cooler than svn which is what im using now
[12:48] <hsn_> is there way to do bzr up --dry-run?
[12:53] <Peng_> james_w: You can't access pastebin.ca?
[12:56] <james_w> Peng_: nope
[12:58] <Peng_> james_w: Hmm. It has AAAA records. Maybe you have messed up IPv6 support?
[12:58] <james_w> maybe
[12:58] <james_w> I don't know how I would have "messed it up"
[12:59] <james_w> It resolves to an IP, and traceroute shows that packets get part way there, but just die after a few hops
[12:59] <Peng_> Oh. Never mind then.
[14:09] <vila> hmmm, pqm... what's the problem with merging lp: branches ?
[14:10]  * vila refuses to believe that pqm has anything against him :D
[14:11] <vila> Anybody knows someone with a 'stub' nick ?
[14:11] <vila> poolie said previously: vila, stub killed a stuck ssh process
[14:12] <james_w> stub doesn't seem to be around at the moment
[14:12] <vila> when it occured this morning (i.e. ~6 hours ago)
[14:13] <vila> james_w: if you find him somewhere, tell him that pqm is wedged againg and will be again since I already have another submission in the queue
[14:13] <james_w> he may well be done for the day
[14:13] <james_w> John or Aaron will probably know who else has the power.
[14:13] <vila> damn, do *you* someone that can acces pqm ?
[14:13] <vila> james_w: ok
[14:14] <vila> abentley, jam: pqm needs more love ^
[14:14] <abentley> vila: I don't have any particular power.
[14:15] <vila> abentley: I know, but may be you know someone who has ?
[14:16] <abentley> vila: The LOSAs have the power, but they don't have a detailed understanding of PQM.  What's the isue?
[14:17] <vila> A submission blocked pqm this morning and stub killed a stuck ssh process
[14:17] <vila> An other submission is now blocking it and I have a third one in the queue
[14:18] <abentley> vila: blocking how?
[14:18] <vila> Displaying: success: merge lp:~vila/bzr/bzr.integration/ http://bazaar-vcs.org/bzr/bzr.dev
[14:18] <vila> i.e. the merge seems to have occured but nothing happens
[14:19] <abentley> vila: Has the branch actually been updated?
[14:19] <vila> Not after the submission
[14:20] <vila> if you look at http://pqm.bazaar-vcs.org/ you'll see that I use two different branches, one for each submission
[14:20] <abentley> vila: Okay.  Are you on irc.canonical.com?
[14:20] <abentley> vila: No, I meant has bzr.dev been updated?
[14:20] <vila> abentley: no. I can't
[14:20] <vila> abentley: no, bzr.dev doesn't look updated
[14:21] <abentley> Okay.
[14:21] <vila> Checked. Not updated
[14:22] <vila> The only cause I can think of is that I use 'lp:' urls where others use 'http:' urls
[14:22] <vila> But I shoot in the dark...
[14:25] <abentley> vila, meet mthaddon.  He is working on unblocking PQM.
[14:25] <mthaddon> abentley, should be okay now
[14:25] <vila> abentley: thanks a ton
[14:26] <vila> mthaddon: hi
[14:26] <abentley> mthaddon: Thanks.
[14:26] <vila> mthaddon: hmm, you're fast, its working again :D
[14:26] <mthaddon> cool
[14:26] <vila> mthaddon: but I bet it will block again in about 1 hour
[14:27] <vila> the current submission should be ok, but the next one should trigger the same problem
[14:27] <abentley> vila: Don't be pessimistic.  Maybe it will block sooner :-)
[14:27] <vila> abentley: lol
[14:27] <abentley> Anyhow, it's worth confirming the behavior.
[14:28] <vila> I hate it when I tickle a bug but have no idea where to look to isolate it...
[14:29] <vila> mthaddon: what did you do to unblock it ?
[14:29] <abentley> vila: It looks like killing the process prevented your last submission from merging, as we feared.
[14:29] <mthaddon> vila, killed the process
[14:29] <vila> strange, this morning killing it make it complete successfully
[14:30] <abentley> mthaddon: What version of bzr is running on that box?
[14:30] <mthaddon> abentley, we're using bzr 1.6 for that PQM instance
[14:31] <vila> 1.6 or 1.6.1 ?
[14:31] <abentley> mthaddon: There were some performance regressions with 1.6.0.
[14:31] <abentley> So this may be related.
[14:32] <mthaddon> ah, interesting
[14:33] <vila> abentley: and I were lucky this morning because we wait longer before killing it ?
[14:33] <abentley> vila: yes, seems plausible.
[14:34] <abentley> mthaddon: Is it possible to update that box to 1.6.1?
[14:36] <mthaddon> abentley, lifeless has typically been responsible for that, and last time I did it I broke things, so I'd rather have him to that (as much to approve it as anything else)
[14:36] <mthaddon> s/him to that/him do that/
[14:38] <abentley> mthaddon: Well, it probably blocks merging 'till Sunday, but I guess we can live with it.
[14:39] <mthaddon> bzr 1.6 has been on there for a while, I believe... any idea why it's suddenly become a blocker?
[14:41] <vila> mthaddon: If I knew I'll be working around it instead of annoying you :-/
[14:42] <vila> My last submissions have blocked pqm, I have no idea why
[14:43] <vila> My last submission *before* that problem was  around 2008-09-01
[14:43] <vila> Except upgrading bzr.dev, I fail to see what I changed
[14:47] <grutte_pier> vila: remember the discussion about the webdav stuff (when I had nick Jakob, which apparently was registered).....
[14:47] <grutte_pier> well.... webdav is on, but only for one directory where systemadmin has some svn repos
[14:47] <vila> astro.rug.nl ?
[14:47] <grutte_pier> :(
[14:47] <grutte_pier> yep
[14:47] <vila> that explains it I think
[14:47] <grutte_pier> so I have to think of something else :P
[14:48] <vila> try the smart server instead, the performances ought to be better now and far better tomorrow :)
[14:52] <grutte_pier> but the whole thing is that I want others to access the repo, with the smart server they need access to the system right?
[14:53] <grutte_pier> the sysadmin will never setup accounts for people not physically working at the institute, I'm sure
[16:21] <hsn_> so its simple do: date(256) + XYZ year
[16:22] <hsn_> ECHANN
[16:30] <vila> grutte_pier: sry, my window was iconified :-/
[16:31] <vila> It you setup a smart server, you can then use .htaccess to define your own users/pass (if your server allows that)
[16:31] <fta> is there a way to cherry pick dis-joined revisions while merging ?
[16:31] <fta> something like -r 274..275,283..285 ?
[16:33] <vila> mthaddon: the pending submission passed, did you something ?
[16:33] <mthaddon> nope
[16:33] <vila> wow, now that's weird, the one you killed have indeed been merged to bzr.dev
[16:33] <vila> mthaddon: ok, thanks for confirming and the help, I'll see with jam and lifeless
[16:33] <mthaddon> cool
[16:34] <vila> and will refrain from submitting until then :-D
[16:58] <james_w> vila: sorry, I obviously don't know my http error codes :-)
[17:10] <vila> james_w: hehe, don't worry. as mentioned, I had to check too :)
[18:02] <fm> hi i cannot get bzr 1.6.1 or 1.7rc1 to work with python 2.6b3. see https://bugzilla.novell.com/show_bug.cgi?id=425644 any idea?
[18:03] <fm> that is 1.5 the later fail with "TypeError: object.__init__() takes no parameters"
[18:26] <james_w> hey fm
[18:26] <james_w> fm: please run "python -c 'from gzip import U32'"
[18:26] <james_w> fm: or python2.6 as necessary
[18:30] <fm> james_w: ImportError: cannot import name U32
[18:34] <fm> james_w: there are the following python packages on opensuse factory: http://pastebin.com/mc80b808
[18:38] <fm> james_w: both my problems seem to be on windows too http://www.python.org/dev/buildbot/community/all/x86 Windows 2003 trunk/builds/66/step-bzr dev/0
[18:48] <james_w> fm: it looks to me like there is something wrong with python 1.6
[18:51] <fm> james_w: how can I debug this?
[18:51] <james_w> fm: well, the failure you reported showed that it can be reproduced with just python
[18:52] <james_w> so I would find out what changed in python to make that go away, as it probably shouldn't have
[18:52] <fm> the ""TypeError: object.__init__() takes no parameters" seems to be caused by http://bugs.python.org/file2323/new_init_strict.patch
[18:57] <pcc1> how do I merge a merge-directive into a repository without a working tree?  currently getting the error message 'bzr: ERROR: No WorkingTree exists for "file:///..."'
[18:58] <james_w> pcc1: you can't, you need a tree to merge it with
[19:25] <_fm_> james_w: u32 was removed http://svn.python.org/view/python/trunk/Lib/gzip.py?rev=61821&r1=61813&r2=61821
[19:26] <james_w> _fm_: that sucks, and may not be intentional
[19:27] <james_w> _fm_: you should find out if it is and request it to be restored if not
[19:28] <_fm_> i am just asking in #python
[19:32] <beuno> Verterok, ping
[19:33] <Verterok> beuno: pong
[19:50]  * mvo wonders what he can do about " TooManyConcurrentRequests: The medium '<bzrlib.smart.medium.SmartSSHClientMedium object at 0x893616c>' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request."
[19:51] <james_w> hey mvo
[19:51] <mvo> hey james_w
[19:51] <james_w> that's normally a secondary error, indicating something else went wrong, and things went from bad to worse as it tried to unwind
[19:51] <james_w> what operation were you doing?
[19:51] <mvo> a commit
[19:52] <james_w> hmm
[19:52] <james_w> I'm not sure what that would be
[19:52]  * mvo tries again
[19:52] <james_w> are you using a lightweight checkout?
[19:52] <mvo> I don't think so
[19:53] <james_w> you could try "bzr unbind; bzr commit; bzr push; bzr bind; then
[19:59] <AmanicA> fwiw, Andrew send in a patch today about: "
[19:59] <AmanicA> This small change fixes one of the remaining causes of TooManyConcurrentRequests
[19:59] <AmanicA> errors.  "bzr pull" and "bzr merge"
[19:59] <AmanicA> "
[19:59] <AmanicA> so maybe this might be fixed in bzr.dev already, or this patch of andrew might help...
[20:00] <AmanicA> For details, see: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20080912022408.GA9671%40steerpike.home.puzzling.org%3E
[20:10] <james_w> AmanicA: thanks, but I don't think that code path is involved here
[20:10] <AmanicA> cool, it was just a stab in the dark..
[20:11] <james_w> yeah, I was hoping it was that one :-)
[20:41] <ryanakca> Is there a bzr command to view what would be pulled before pulling it?
[20:41] <Peng_> ryanakca: "bzr missing"
[20:42] <Peng_> (Well, it'll also show anything that would be pushed if you pushed, but there are arguments to change that.)
[20:42] <ryanakca> Peng_: ok, thanks
[21:27] <ryanakca> Peng_: hmm... could you make it show ``bzr diff'' for those files?
[21:28] <Odd_Bloke> ryanakca: Look at revspecs, there'll be 'branch' or 'ancestor' or something which'll work.
[21:28] <Odd_Bloke> bzr diff -r branch:<REMOTE> or something.
[21:28] <ryanakca> nevermind, I tihnk I found it, bzr diff --new=ARG where ARG is the new branch
[22:03] <_amanica_> does anybody know why serverside hooks work with bzr:// but not bzr+http://
[22:03] <Kilroo> So does the Bazaar community pretty much have everything -except- a forum?
[22:04] <uws> a forum is for degenerate beings
[22:04] <uws> sorry, did i actually say that? ;)
[22:04] <_amanica_> whell theres answers..
[22:04] <_amanica_> https://answers.launchpad.net/bzr
[22:05] <Kilroo> Pft. I happen to like fora, er, Mathilda.
[22:05] <uws> Kilroo: who's Mathilda/ :)
[22:06] <Kilroo> Sorry, I was reading the quotes page. :D
[22:06] <Kilroo> Hm...thanks, _amanica_. That looks somewhat promising.
[22:07] <Kilroo> For some reason it still feels more like I'm intruding on people than I usually feel on a forum...
[22:07] <Peng_> That's true..bzr doesn't have a forum.    You have a point.
[22:43] <Kilroo> Either you've seen that thread since anyone posted to it, or you haven't.
[22:44] <Peng_> Or your session has expired, so it assumes you've seen the thread.
[22:44] <Peng_> (Vanilla averts that, but it's not all that great otherwise.)
[22:44] <Kilroo> I can't think of a forum that does that.
[22:45] <Peng_> phpBB, but maybe it's improved more recently.
[22:45] <Peng_> Or, what do you mean?
[22:45] <Kilroo> Far as I know, on phpBB, if you're not logged in it assumes you haven't read anything except maybe what's in session. If you are logged in it doesn't have to guess.
[22:47] <Peng_> Hmm... It seems Loggerhead's pages lack a DOCTYPE or charset declaration.
[22:48] <Kilroo> Maybe I should give mailing lists a try. I'm sure there must be something out there that lets you read an entire thread of messages from a mailing list at once, in chronological order regardless of reply forking, and paginated. I'd be surprised if it can correct for screwy distributions of > characters in multi-quoted responses from people with different numbers of columns in their mail clients though.
[22:49] <Kilroo> It's all a matter of taste anyhow.
[22:49] <fullermd> Quite.  I'd hate to read in chronological order.
[22:50] <Kilroo> In some cases I like to have the option to toggle it, but I don't like being forced to have things show in tree order, and I absolutely despise having to read one post at a time.
[22:51] <fullermd> But no forum will ever have an interface as customizable as my mail client, and couldn't come within 2 orders of magnitude of the responsiveness.
[22:51] <Kilroo> True enough.
[22:51] <fullermd> Heck, I can dispose of a whole mailbox in the time it takes to load one forum thread.
[22:52] <LarstiQ> Kilroo: a problem with a forum for bzr would be that afaik not a lot of knowledgeable people would read it
[22:52] <LarstiQ> Kilroo: I for one wouldn't.
[22:52] <fullermd> KKKKK<center><space>jjjiKKKl<enter>  *done*
[22:52] <Kilroo> It does begin to sound that way.
[22:52] <LarstiQ> Kilroo: now, you could try gmane
[22:53] <LarstiQ> Kilroo: that may come closer to your tastes?
[22:53] <Kilroo> Not particularly.
[22:54] <Kilroo> That is, it's better than many things I've seen.
[22:54] <Kilroo> However, if gmane suited me, I'd be happy using a mail client.
[22:54] <LarstiQ> Kilroo: I acknowledge there are users (in general, not sure for bzr) who would benefit from a forum
[22:55] <LarstiQ> but we'd need to have some people to put effort in it to set it up
[22:56] <LarstiQ> Kilroo: if you're willing to learn about bzr and act as a bridge between the fora and the rest, you're welcome to set one up ;)
[22:57] <Kilroo> And then it would only really be any help for people like me who would like a forum and don't like a mailing list, and even then only as much help as the people who would like a forum enough to post to it...and then the experts either have to spend time on both, or have to choose which one to follow.
[22:57] <LarstiQ> exactly
[22:57] <LarstiQ> so I feel starting up a forum none of us will use would be a disservice to users wanting to use it
[22:58] <Kilroo> Long story short, a forum would probably be more trouble to the community than it's worth, and there just isn't a medium for asking the kinds of questions I have where I don't feel like I'm intruding on people's time.
[22:58]  * LarstiQ nods at Kilroo
[22:58] <LarstiQ> Kilroo: except, you're free to ask those questions
[22:58] <Kilroo> I was about to say...why I feel less like I'm intruding by posting a forum thread than by starting a thread on a mailing list or posting a question to the answers thing, I do not know.
[22:58] <fullermd> In high theory, there's no reason a forum and a mailing list can't 2-way gateway each other.  There are a number of impedance mismatches, though, on levels 6-8.
[22:59] <LarstiQ> Kilroo: how about asking on irc?
[22:59] <Kilroo> I also have never figured out why I feel less like I'm intruding by having an off-topic conversation on IRC than by asking stupid questions.
[22:59] <Kilroo> I think it's #ubuntu's fault.
[22:59] <LarstiQ> :)
[23:00]  * fullermd riffles through the definion of IRC for any mention of "topic"...
[23:00] <Peng_> Posting on a mailing list feels more intrusive to me than a forum. I think.
[23:00]  * LarstiQ nods
[23:00] <Peng_> I don't start many threads on forums.
[23:00] <LarstiQ> but that's the great thing about mailing lists :)
[23:00] <Peng_> So I'm not really sure.
[23:00] <LarstiQ> Peng_: how would you compare the thresholds of irc and fora?
[23:01] <Kilroo> I guess I think of a mailing list as being sort of like a forum where everyone who's registered is subscribed to the entire thing.
[23:01] <Kilroo> And now I'm trying to remember which forum software it is where you could do that. Invision Power Board I think. Not sure of any others that support that.
[23:01] <LarstiQ> Kilroo: that is a difference. NNTP has a more granular subscription model.
[23:02] <Peng_> LarstiQ: I don't know. I usually lurk in IRC channels for 3 months before asking anything. Or I join, ask a question, everybody ignores me, and I leave. :)
[23:02] <LarstiQ> Kilroo: btw, do you actually have a question yet?
[23:02] <Kilroo> Oh yeah, the question.
[23:02] <Peng_> Kilroo: What do you mean by "subscription"? Most forums have email alerts and stuff. IPB's may be better though.
[23:03] <Peng_> Kilroo: Sorry, you've used up all your time today. Come back and ask tomorrow. ;)
[23:03] <LarstiQ> Peng_: with a mailing list, you can't selectively watch a particular thread, you get everything
[23:03] <Peng_> LarstiQ: Oh, that's ture.
[23:03] <Peng_> true*
[23:03] <LarstiQ> lukcily, my email client deals with that just fine, and I usually want to see everything.
[23:04] <Peng_> Which client?
[23:04] <LarstiQ> mutt
[23:04] <Kilroo> Actually I'm probably going to come back next week. See, I have a (very vague) idea of what I want to do, but I haven't tried anything yet to see if it'll work, and I don't like asking "hey, can I do this?" without "Here's what I tried so far..."
[23:05] <fullermd> Well, you already asked _half_ the question...
[23:05] <Peng_> Kilroo: Well now I'm curious.
[23:05] <Peng_> LarstiQ: O
[23:05] <Peng_> h
[23:05] <LarstiQ> Kilroo: I'll take your reluctance for that as credit and won't be bothered by you not having tried anything yet :)
[23:05]  * Peng_ can't type right now.
[23:06] <Kilroo> as an aside...Peng_: If I'm  remembering right, with IPB you can subscribe to the thread, the subforum, or the entire board. With most other packages I don't think I've ever seen a way to subscribe to anything but the thread.
[23:08] <Kilroo> Ok, you've convinced me. The basic gist is this: I'm working with a team that currently has no source control at all...nor even a real development server. I'm trying to figure out whether there's a way of using bzr with the production server as a dumb server that doesn't require something ridiculously complicated, but yields more benefit than just having everyone keep history on their local working copies.
[23:09] <Kilroo> And I'm having trouble even grasping what I mean by that because the only thing I've ever used before was an old version of Sourcesafe.
[23:09] <LarstiQ> bzr doesn't require any extra software on machines you publish your changes on, just file (sftp/ftp/etc) access will do
[23:10] <Kilroo> It would be relatively simple if not for the fact that I cannot guarantee adoption of bzr across the board
[23:10] <Kilroo> which means that for example people in other departments might be making changes and pushing them directly via FTP.
[23:10] <LarstiQ> Kilroo: would adoption be hindered by wanting another solution, or just general aversion to version control?
[23:13] <Kilroo> larstiq: There are three obstacles. One, I'm not even sure how to get the word out to everyone who currently has FTP access. Two, I suspect the powers that be would want to sit on it for a while before making it a standard, even if everyone who would need to switch understood what was happening. Three, we're actually supposed to be moving to Subversion...but for some odd reason doing this is taking months. Lots of them.
[23:13] <LarstiQ> Kilroo: I see.
[23:14]  * fullermd suggests electroshock.
[23:14] <LarstiQ> fullermd: tsk :)
[23:14] <fullermd> What?  Hot pokers aren't called for until week 2...
[23:14] <LarstiQ> Kilroo: so multiple people are collaborating on the same source now without any version control, across departements?
[23:14] <Kilroo> Yyyyep.
[23:14] <LarstiQ> nice.
[23:15] <Kilroo> Well, I take that back.
[23:15] <fullermd> See?  Electroshock would be more merciful   :p
[23:15] <Kilroo> Some of them are using lock files with Dreamweaver.
[23:15] <LarstiQ> Kilroo: aah, web work?
[23:15] <Kilroo> But not all of them are, I don't think anyone hesitates to override the lock, and those of us who use Eclipse instead tend not to notice the lock files at all.
[23:16] <Kilroo> larstiq, yep...mostly php.
[23:16] <LarstiQ> Kilroo: you don't need to get everyone onboard at the same time
[23:17] <LarstiQ> Kilroo: granted, things will be harder untill you do
[23:17]  * fullermd uses bzr to manage piles of PHP code, and occasionally has to deal with Dreamweaver droppings.
[23:18] <LarstiQ> Kilroo: do you work directly on the server, or is there a syncing step to your workstation before you make a change, make a change, and then upload it again?
[23:19] <Kilroo> Larstiq: Some people work directly on the server. On occasion, I actually have, myself, for quick fixes. Usually, though, what I do is download the remote files if I think there have been any changes to them, make changes to my local files, and then upload.
[23:20] <LarstiQ> Kilroo: right, so if someone doesn't sync, there is the possibility for overriding others work?
[23:20] <Kilroo> Larstiq: Yes.
[23:20] <LarstiQ> I see.
[23:22] <LarstiQ> Kilroo: what you could do, is start locally using it. 'bzr init; bzr add; bzr ci' your local copy, and then use bzr as you would normally. When you sync from remote, make sure you have no uncommitted changes, sync, and do a commit (possibly add first for new files) as bzr ci -m 'changes made by others'
[23:22] <LarstiQ> Kilroo: now, that will only give you versioning locally, and ideally you'd like to collaborate with others
[23:23] <Kilroo> Hmm
[23:23] <LarstiQ> but it at least gives you some of the benefits
[23:23] <Kilroo> Yeah
[23:23] <LarstiQ> and no one else has to know that you're using bzr
[23:24] <LarstiQ> from there on, you could expand it to whomever is interested
[23:24] <Kilroo> that's pretty much what I had in mind, actually, except I was having trouble wrapping my head around the entire process.
[23:24] <fullermd> I think an important step in the process is to never, ever let the idea works its way into your head that a VCS is a deployment mechanism...
[23:24] <LarstiQ> fullermd: right, but we have `bzr upload` for that
[23:25] <LarstiQ> Kilroo: which is a plugin btw, you can find it on http://bazaar-vcs.org/BzrPlugins
[23:25] <Kilroo> I've seen it. It confused me a little.
[23:25] <LarstiQ> Kilroo: I need to go to bed now, we can talk about how to use bzr with others another time, or someone else can help you.
[23:25] <fullermd> I stick with my belief that it's a bad idea in general, and imposes uncomfortable constraints on you even when it technically works perfectly.
[23:26] <Kilroo> Thanks for your help, LarstiQ
[23:26] <LarstiQ> Kilroo: how did it confuse you?
[23:26] <LarstiQ> fullermd: you think `bzr upload` is a bad idea?
[23:27] <Kilroo> Basically, I'm not sure I understand how bzr-upload differs from making a lightweight checkout and putting it on the production server.
[23:27] <LarstiQ> fullermd: it only works if deployment means having a copy of your tree somewhere
[23:27] <LarstiQ> Kilroo: the difference is in where the updating happens
[23:27] <LarstiQ> Kilroo: with the lightweight checkout, you would need to update it on the server everytime you want it to, well, be up to date.
[23:28] <LarstiQ> Kilroo: and then you'd need to have bzr on the server
[23:28] <fullermd> A capability is rarely a bad idea.  Only the use of it   :)
[23:28] <LarstiQ> Kilroo: with bzr-upload, you're just uploading the files that are in your working tree, no bzr required on the server, no cron, no nothing
[23:29] <LarstiQ> fullermd: don't evade my question :P
[23:29] <Kilroo> Well, actually what I meant was making a lightweight checkout and then uploading the result. But I see what you mean.
[23:29] <LarstiQ> Kilroo: convenience.
[23:30] <fullermd> I don't think I was evading it.  The biggest drawback of having the tool available is that people are more likely to use it, and I think that mechanism is a tool whose value increases the less it's used.
[23:31] <Kilroo> Anyhow, thanks again for all your help. I need to go eat now. I think I have a good notion of what to do now, though.
[23:31] <LarstiQ> I see, fair enough.
[23:31] <fullermd> It ties the deployment process into the committing process, and the versioned tree shape to the deployed tree shape, and I think both of those are bad things.
[23:31] <LarstiQ> fullermd: aah, good arguments.
[23:31]  * Peng_ uses a VCS as a deployment tool. Cough.
[23:31] <Kilroo> That makes sense to me, fullermd
[23:32] <fullermd> And I'm crankier with it than it deserves, because I can't understand how so many people immediately jump to the assumption that it's a good idea.
[23:32] <Kilroo> but then, so does being able to deploy FROM version control.
[23:32] <fullermd> I mean, I used a VCS for over a year before the thought first occured to me, and after a half hour of setting it up once, I figured out it was a bazooka pointed at my foot   :p
[23:32] <LarstiQ> fullermd: it's lightweight.
[23:33] <Peng_> Yeah, that's why I do it. I don't have any complex needs, and it means I don't have to learn any new tools.
[23:33] <Peng_> I only have one server anyway. (Well, two, but they don't share anything.)
[23:33] <LarstiQ> fullermd: and I've been using it the last couple of days to deploy an oracle install script, for that it worked nicely.
[23:34] <Kilroo> My ideal notion is to have VCS, and everyone works with VCS, and then pushing to production consists of taking the current production branch in VCS and putting it on the production server. Hopefully by means of some scripted process.
[23:34] <fullermd> My deployment process is generally a stack of Makefiles.  And my deployed tree shapes _never_ mirror the tree in VCS.
[23:34] <fullermd> At the least, the deployed tree is a subset of what's in the VCS (e.g., things like database manglement scripts, don't go in a live environment).  And there's usually more differences.
[23:34]  * LarstiQ nods at fullermd
[23:35] <Kilroo> I'm not sure you can really do that so much in web development.
[23:35] <LarstiQ> fullermd: you use a heavier deployment process, bzr-upload doesn't add anything there.
[23:35] <Kilroo> Actually I take that back.
[23:35]  * fullermd does web development   :p
[23:35] <LarstiQ> Kilroo: zc.buildout!
[23:35] <Kilroo> Because I immediately thought of four ways that I could.
[23:36] <fullermd> ('course, I don't do it, by royal decree, when I don't have real access to the server.  I changed double and a half time any time I have to touch FTP)
[23:36] <LarstiQ> Kilroo: an aside, do you use sftp or ftp?
[23:37] <LarstiQ> bzr is much happier with sftp
[23:37] <fullermd> I guess it boils down to I don't think bzr-upload is evil or bad or broken, I just think it [the general workflow, not the specific tool] is used too often by reflex or whim, rather than really thinking through how the workflow should best be.
[23:37] <LarstiQ> fullermd: right, I can agree to that.
[23:37] <fullermd> Of course, that doesn't put it in rareified company   :p
[23:38] <Kilroo> Let me rephrase: I don't think it would be possibly for the company where I work to have the deployed tree be a different shape from the development tree without massive changes to the way most things are done.
[23:39] <Kilroo> Granted, some of those changes would probably be beneficial. I personally don't like having any php file that isn't supposed to be accessed directly by the web live in a folder underneath the document root.
[23:39] <Kilroo> Larstiq: ftp, unfortunately.
[23:40] <Kilroo> I'm not sure what that business with the document root has to do with what I was talking about in the previous sentence, either.
[23:40] <Kilroo> I think I'm too hungry to think.
[23:40] <Kilroo> I'm going to go eat dinner. Thank you again for all your help.
[23:40] <fullermd> Food is not the answer.
[23:40] <fullermd> Food is the question.  "Yes" is the answer.
[23:40] <Kilroo> Amen to that.
[23:42] <LarstiQ> and I'll detach, ciao
[23:43] <fullermd> Mwahaha.  And I'll stage a coup while you're all distracted.