From itz at buug.org  Tue Dec 11 16:12:25 2012
From: itz at buug.org (Ian Zimmerman)
Date: Tue, 11 Dec 2012 16:12:25 -0800
Subject: [buug] recode vs. iconv
Message-ID: <20121211161225.15431a94.itz@buug.org>

Today I needed to convert some text files from latin1 to plain ascii,
preferably with transcriptions (e.g. ? into ss, ? into ae, and so on).
They were large enough that doing it manually was out of the question,
even in an excellent editor like emacs ;-)  I remembered that recode and
iconv were the two programs potentially suitable for the task.

I tried recode first, but it was a disaster, I couldn't make it work
despite reading the full fine manual (info version) in detail.  It would
simply error out on any non-ascii character unless I gave the --force
option (even when I called it not in-place but as a filter), and then it
would succeed but silently drop some of them without substituting
anything.

On the other hand, iconv worked the first time, when I gave it the
//TRANSLIT option, but it didn't really transcribe my preferred way,
instead it just substituted a single character for each non-ascii one
(? into s, ? into a, ...).

This must be a common need and surely I'm missing the right way to do it?

-- 
Ian Zimmerman
gpg public key: 1024D/C6FF61AD
fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
http://www.gravatar.com/avatar/c66875cda51109f76c6312f4d4743d1e.png
Rule 420: All persons more than eight miles high to leave the court.


From rick at linuxmafia.com  Tue Dec 11 16:48:09 2012
From: rick at linuxmafia.com (Rick Moen)
Date: Tue, 11 Dec 2012 16:48:09 -0800
Subject: [buug] recode vs. iconv
In-Reply-To: <20121211161225.15431a94.itz@buug.org>
References: <20121211161225.15431a94.itz@buug.org>
Message-ID: <20121212004809.GX24835@linuxmafia.com>

Quoting Ian Zimmerman (itz at buug.org):

> Today I needed to convert some text files from latin1 to plain ascii,
> preferably with transcriptions (e.g. ? into ss, ? into ae, and so on).
> They were large enough that doing it manually was out of the question,
> even in an excellent editor like emacs ;-)  I remembered that recode and
> iconv were the two programs potentially suitable for the task.
> 
> I tried recode first, but it was a disaster, I couldn't make it work
> despite reading the full fine manual (info version) in detail.  It would
> simply error out on any non-ascii character unless I gave the --force
> option (even when I called it not in-place but as a filter), and then it
> would succeed but silently drop some of them without substituting
> anything.

Huh!  {glyph of mild puzzlement}

Back when I was chief copyeditor for _Linux Gazette_ magazine, we had
one regular columnist who could not be cured of writing submissions in
Microsoft text editors and _not_ bothering to clean up his (alleged)
ASCII.  At the time, I did this to compensate for the man's inability to
write real plaintext, and it worked every time:

$ recode windows-1257..ASCII lg_bytes.html
$ tidy -cim lg_bytes.html
$ aspell check lg_bytes.html
Then, the inevitable manual line-editing work in vim.  

Anyway, the recode step always did The Right Thing, and never errored
out.

From itz at buug.org  Tue Dec 11 17:16:03 2012
From: itz at buug.org (Ian Zimmerman)
Date: Tue, 11 Dec 2012 17:16:03 -0800
Subject: [buug] recode vs. iconv
In-Reply-To: <20121212004809.GX24835@linuxmafia.com>
References: <20121211161225.15431a94.itz@buug.org>
 <20121212004809.GX24835@linuxmafia.com>
Message-ID: <20121211171603.056bb172.itz@buug.org>

On Tue, 11 Dec 2012 16:48:09 -0800
Rick Moen <rick at linuxmafia.com> wrote:

Ian> Today I needed to convert some text files from latin1 to plain
Ian> ascii, preferably with transcriptions (e.g. ? into ss, ? into ae,
Ian> and so on). They were large enough that doing it manually was out
Ian> of the question, even in an excellent editor like emacs ;-) I
Ian> remembered that recode and iconv were the two programs potentially
Ian> suitable for the task.

Ian> I tried recode first, but it was a disaster, I couldn't make it
Ian> work despite reading the full fine manual (info version) in detail.
Ian> It would simply error out on any non-ascii character unless I gave
Ian> the --force option (even when I called it not in-place but as a
Ian> filter), and then it would succeed but silently drop some of them
Ian> without substituting anything.

Rick> Back when I was chief copyeditor for _Linux Gazette_ magazine, we
Rick> had one regular columnist who could not be cured of writing
Rick> submissions in Microsoft text editors and _not_ bothering to clean
Rick> up his (alleged) ASCII.  At the time, I did this to compensate for
Rick> the man's inability to write real plaintext, and it worked every
Rick> time:

Rick> $ recode windows-1257..ASCII lg_bytes.html 
Rick> $ tidy -cim lg_bytes.html 
Rick> $ aspell check lg_bytes.html

Mine also had CRLF line endings, but I suppose that was the case with
yours as well.

-- 
Ian Zimmerman
gpg public key: 1024D/C6FF61AD
fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
http://www.gravatar.com/avatar/c66875cda51109f76c6312f4d4743d1e.png
Rule 420: All persons more than eight miles high to leave the court.


From rick at linuxmafia.com  Tue Dec 11 17:29:01 2012
From: rick at linuxmafia.com (Rick Moen)
Date: Tue, 11 Dec 2012 17:29:01 -0800
Subject: [buug] recode vs. iconv
In-Reply-To: <20121211171603.056bb172.itz@buug.org>
References: <20121211161225.15431a94.itz@buug.org>
 <20121212004809.GX24835@linuxmafia.com>
 <20121211171603.056bb172.itz@buug.org>
Message-ID: <20121212012901.GY24835@linuxmafia.com>

Quoting Ian Zimmerman (itz at buug.org):

> Mine also had CRLF line endings, but I suppose that was the case with
> yours as well.

Those files definitely did.  Neither recode, nor tidy, nor vim had a
problem, FWIW.

From itz at buug.org  Tue Dec 11 21:21:49 2012
From: itz at buug.org (Ian Zimmerman)
Date: Tue, 11 Dec 2012 21:21:49 -0800
Subject: [buug] recode vs. iconv
In-Reply-To: <20121212012901.GY24835@linuxmafia.com>
References: <20121211161225.15431a94.itz@buug.org>
 <20121212004809.GX24835@linuxmafia.com>
 <20121211171603.056bb172.itz@buug.org>
 <20121212012901.GY24835@linuxmafia.com>
Message-ID: <20121211212149.0b2be847.itz@buug.org>

Turns out there a whole thicket of issues here.

First, I lied when I said using iconv was the solution.  It converted
_most_ of the latin1 letters but not some of the more exotic ones, like
"?".  It replaced the latter with question marks :-(  As the program
(and the underlying part of libc) was written by Uli Drepper I wonder if
it just converts the characters used in German and gives up on the
others.

I also lied when I said I read the whole recode manual.  When I went
over it I had already read the debian-written manpage, so I skipped the
Invoking section where the options are documented.  Fail!  The manpage
is out of date.  It omits the -x option, and it doesn't mention the
"unification" of recode and iconv which is rather important.  This:

recode latin1..ascii < foo.txt > /dev/null

fails on the first non-ascii character, while this:

recode -x: latin1..ascii < foo.txt > /dev/null

"succeeds" - but then it is a rather slower version of cat.

I think this unification happened after your experience with recode.

The only package in debian that did something really close to what I
wanted was cstocs.  I like its Czech-specific features too :) so I am
glad I have learned about it.

But we sure have cooler icons and transparent windows now :(

-- 
Ian Zimmerman
gpg public key: 1024D/C6FF61AD
fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
http://www.gravatar.com/avatar/c66875cda51109f76c6312f4d4743d1e.png
Rule 420: All persons more than eight miles high to leave the court.


From nkj at iaminsane.com  Wed Dec 12 06:28:53 2012
From: nkj at iaminsane.com (Nick Jennings)
Date: Wed, 12 Dec 2012 15:28:53 +0100
Subject: [buug] recode vs. iconv
In-Reply-To: <20121211212149.0b2be847.itz@buug.org>
References: <20121211161225.15431a94.itz@buug.org>
 <20121212004809.GX24835@linuxmafia.com>
 <20121211171603.056bb172.itz@buug.org> <20121212012901.GY24835@linuxmafia.com>
 <20121211212149.0b2be847.itz@buug.org>
Message-ID: <CAJL4WtYLh3m=rM22CszTyUzosRTxvdpwM5nuOFfP=LqC1Z64PQ@mail.gmail.com>

On Wed, Dec 12, 2012 at 6:21 AM, Ian Zimmerman <itz at buug.org> wrote:
> I like its Czech-specific features too :) so I am
> glad I have learned about it.

u??m se ?esk?! :)


From itz at buug.org  Wed Dec 12 09:16:24 2012
From: itz at buug.org (Ian Zimmerman)
Date: Wed, 12 Dec 2012 09:16:24 -0800
Subject: [buug] recode vs. iconv
In-Reply-To: <CAJL4WtYLh3m=rM22CszTyUzosRTxvdpwM5nuOFfP=LqC1Z64PQ@mail.gmail.com>
References: <20121211161225.15431a94.itz@buug.org>
 <20121212004809.GX24835@linuxmafia.com>
 <20121211171603.056bb172.itz@buug.org>
 <20121212012901.GY24835@linuxmafia.com>
 <20121211212149.0b2be847.itz@buug.org>
 <CAJL4WtYLh3m=rM22CszTyUzosRTxvdpwM5nuOFfP=LqC1Z64PQ@mail.gmail.com>
Message-ID: <20121212091624.1f929f44.itz@buug.org>

On Wed, 12 Dec 2012 15:28:53 +0100
Nick Jennings <nkj at iaminsane.com> wrote:

Ian> I like its Czech-specific features too :) so I am glad I have
Ian> learned about it.

Nick> u??m se ?esk?! :)

The last accent is wrong.  Morphologically "?esky" is an adverb, not a
noun or adjective.

-- 
Ian Zimmerman
gpg public key: 1024D/C6FF61AD
fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
http://www.gravatar.com/avatar/c66875cda51109f76c6312f4d4743d1e.png
Rule 420: All persons more than eight miles high to leave the court.


From nick at silverbucket.net  Wed Dec 12 10:52:22 2012
From: nick at silverbucket.net (Nick Jennings)
Date: Wed, 12 Dec 2012 19:52:22 +0100
Subject: [buug] recode vs. iconv
In-Reply-To: <20121212091624.1f929f44.itz@buug.org>
References: <20121211161225.15431a94.itz@buug.org>
 <20121212004809.GX24835@linuxmafia.com>
 <20121211171603.056bb172.itz@buug.org> <20121212012901.GY24835@linuxmafia.com>
 <20121211212149.0b2be847.itz@buug.org>
 <CAJL4WtYLh3m=rM22CszTyUzosRTxvdpwM5nuOFfP=LqC1Z64PQ@mail.gmail.com>
 <20121212091624.1f929f44.itz@buug.org>
Message-ID: <CAJL4WtZOr7D3NVLYmAyPxvASWCiR=eViXkYNAJik32LZQ5Z2dQ@mail.gmail.com>

On Wed, Dec 12, 2012 at 6:16 PM, Ian Zimmerman <itz at buug.org> wrote:
> On Wed, 12 Dec 2012 15:28:53 +0100
> Nick Jennings <nkj at iaminsane.com> wrote:
>
> Ian> I like its Czech-specific features too :) so I am glad I have
> Ian> learned about it.
>
> Nick> u??m se ?esk?! :)
>
> The last accent is wrong.  Morphologically "?esky" is an adverb, not a
> noun or adjective.

Ah, I actually don't have much practice with written Czech, mostly
spoken (since I'm living in Prague these days), so I didn't notice the
subtle difference. Thanks for the clarification.


From pi at berkeley.edu  Wed Dec 12 12:59:20 2012
From: pi at berkeley.edu (Paul Ivanov)
Date: Wed, 12 Dec 2012 12:59:20 -0800
Subject: [buug] recode vs. iconv
In-Reply-To: <20121211212149.0b2be847.itz@buug.org>
References: <20121211161225.15431a94.itz@buug.org>
 <20121212004809.GX24835@linuxmafia.com>
 <20121211171603.056bb172.itz@buug.org>
 <20121212012901.GY24835@linuxmafia.com>
 <20121211212149.0b2be847.itz@buug.org>
Message-ID: <20121212205920.GO4962@HbI-OTOH.berkeley.edu>

Ian Zimmerman, on 2012-12-11 21:21,  wrote:
> But we sure have cooler icons and transparent windows now :(

That's FANTASTIC! Where can I find them? and what about rounded
corners? No one cares if software is actually functional, it just
has to be pretty!

Also, my chosen career is to be a princess, but Justice Sotomayor
tells me I can't be one :(
http://www.youtube.com/watch?v=EHICz5MYxNQ

better,
-- 
Paul Ivanov
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

From Michael.Paoli at cal.berkeley.edu  Mon Dec 17 14:44:50 2012
From: Michael.Paoli at cal.berkeley.edu (Michael Paoli)
Date: Mon, 17 Dec 2012 14:44:50 -0800
Subject: [buug] BALUG: no Dec. meeting & other BALUG news
Message-ID: <20121217144450.17427arcw4pmt6kg@webmail.rawbw.com>

BALUG: no Dec. meeting & other BALUG news

------------------------------

items, details further below:
2012-12 no BALUG meeting; next BALUG meetings 2013-01-15, ...
BALUG "announce" list
past meeting materials (Raspberry Pi, Ubuntu, OpenPhoto, ...)
Twitter https://twitter.com/#!/BALUG_org
volunteering to help BALUG

------------------------------

2012-12 no BALUG meeting in December.  We typically skip December.
Happy Holidays!  We generally meet 3rd Tuesdays, mark your calendars!:
2013-01-15 2013-02-19 2013-03-19 2013-04-16 2013-05-21 2013-06-18
2013-07-16 2013-08-20 2013-09-17 2013-10-15 2013-11-19 ...
http://www.balug.org/#Meetings-upcoming

------------------------------

BALUG "announce" list
Want to be sure and catch important BALUG news/announcements?  It is
also a "low volume" list (generally maximum of 3 emails per month, and
sometimes as few as only one).  Consider subscribing directly so you
receive them in a timely manner and don't miss any such announcements.
http://lists.balug.org/listinfo.cgi/balug-announce-balug.org

------------------------------

past meeting material (Raspberry Pi, Ubuntu, OpenPhoto, ...)

Missed one of our past meetings, or want to see/review the materials
from the meeting?  In some cases presenters provide us with copies of
materials, or we may record a talk/presentation.

These are some of the more recent materials we have:

2012-06-19: Raspberry Pi - Allan Cecil
http://lists.balug.org/pipermail/balug-talk-balug.org/2012-December/004921.html

2012-02-21: OpenPhoto Project - Jaisen Mathai
http://lists.balug.org/pipermail/balug-talk-balug.org/2012-February/004794.html

2012-04-17: Ubuntu 12.04 LTS Precise Pangolin - Grant Bowman &  
Elizabeth Krumbach
http://lists.balug.org/pipermail/balug-talk-balug.org/2012-April/004834.html

Sometimes speakers/presenters also have materials elsewhere - e.g. their
own web sites.  See also the "announce" archives for many of those links.
http://lists.balug.org/pipermail/balug-announce-balug.org/

------------------------------

Twitter - you can also follow BALUG on Twitter:
https://twitter.com/#!/BALUG_org

------------------------------

volunteering to help BALUG

Want to volunteer to help out BALUG?  Quite a variety of opportunities*
Drop us a note at:
balug-contact at balug.org
Or come talk to us at a BALUG meeting.
*e.g.:
o assist on publicity
o assist on speaker coordination/procurement, etc.
o webmastering
o archivist/history/retrieval/etc.
o Linux Systems Administration (e.g. do/assist/learn, with/under some
   quite experienced and skilled Linux systems administrators).
o and other various/miscellaneous tasks BALUG "ought" to be doing or
   would be good to do (feel free to bring ideas!)

------------------------------

Feedback on our publicity/announcements (e.g. contacts or lists where we
should get our information out that we're not presently reaching, or
things we should do differently): publicity-feedback at balug.org

------------------------------

http://www.balug.org/



From Michael.Paoli at cal.berkeley.edu  Thu Dec 20 00:29:33 2012
From: Michael.Paoli at cal.berkeley.edu (Michael Paoli)
Date: Thu, 20 Dec 2012 00:29:33 -0800
Subject: [buug] (more) ISOs (CDs, DVDs, etc.)
Message-ID: <20121220002932.83447l9hz2r51dkw@webmail.rawbw.com>

I've further updated, organized and detailed various ISOs, etc. I have,
including many newer ones, and also many older ones I still have.
I intend to be at today (Thursday)'s BUUG meeting (I typically am
there).  If you see one(s) you're interested in that shows qty
(quantity) 0 (zero), ask in advance, and I may be sure to
bring/burn/copy such image(s).  Details, listing, "inventory", etc.:
http://www.wiki.balug.org/wiki/doku.php?id=balug:cds_and_images_etc


From Michael.Paoli at cal.berkeley.edu  Thu Dec 20 09:15:03 2012
From: Michael.Paoli at cal.berkeley.edu (Michael Paoli)
Date: Thu, 20 Dec 2012 09:15:03 -0800
Subject: [buug] BUUG list policy?
Message-ID: <20121220091503.51884k458kmi0ry8@webmail.rawbw.com>

I recently noticed on:
http://buug.org/mailman/listinfo/buug
That BUUG list policy isn't stated there, however it was
("historically") stated on the list page before the migration of the
list to the balug.org domain:
http://web.archive.org/web/20100630003254/http://www.weak.org/mailman/listinfo/buug
However, list policy is also stated/implied on:
http://www.buug.org/
What's stated there, however, matches neither what was, nor is, on the
list page itself.

Anyway, perhaps we can discuss this at this evening's BUUG meeting a bit
(and/or on list a bit if/as needed), and figure out what the policy
ought to say, and have http://buug.org/mailman/listinfo/buug and
possibly also
http://www.buug.org/
updated so they're consistent.

In the interim, I'd say what's stated on
http://www.buug.org/
takes precedence, as list policy isn't currently stated elsewhere on the
site in any "official" location.


From Michael.Paoli at cal.berkeley.edu  Fri Dec 21 11:43:23 2012
From: Michael.Paoli at cal.berkeley.edu (Michael Paoli)
Date: Fri, 21 Dec 2012 11:43:23 -0800
Subject: [buug] BUUG list policy?
In-Reply-To: <20121220091503.51884k458kmi0ry8@webmail.rawbw.com>
References: <20121220091503.51884k458kmi0ry8@webmail.rawbw.com>
Message-ID: <20121221114323.16552qs9hxnn28sg@webmail.rawbw.com>

BUUG list policy

Well, we did discuss it a bit at the BUUG meeting yesterday.

No need to change descriptions of policy quite yet.  Thought we'd also
mention the general idea(s) on the list, and see if we can reach - if
not consensus, perhaps at least minimal dissent.

So, anyway, at least as proposed rough draft, here's at least
approximately what we've come up with so far.

Put the policy on the list page, not the main page, and have the main
page essentially refer to the list page regarding policy.  This avoids
potential issues of them being inconsistent, or needing to maintain two
separate copies in consistent manner.  So, for main page, perhaps
something like:

--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--
   In addition to meetings, we have a mailing list to communicate. The
   mailing list is open to everyone, regardless of where they live or
   even whether or not they can attend the meetings.<P>

   For list rules/policy and to subscribe to the list, visit the
   <a href="http://buug.org/mailman/listinfo/buug">list information</a>
   page.<P>

   You can also review the
   <a href="http://buug.org/pipermail/buug/">mailing list archives</A>.
--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--

As to list policy proper, most of the discussion was around commercial
postings, unsolicited commercial postings, and job postings.  There was
also good idea of having a "when in doubt, ask" part of policy.

As to job postings, mostly there's desire to avoid lots of postings from
recruiters, agencies, job boards, HR departments, etc. essentially
plastering list with most anything and everything they have - even if
the field/job/location might be relevant.  This also tended to be quite
an issue for many lists and the like, in the dot com boom days - and
such issue(s) might potentially recur in future.  So, there doesn't
seem (at least from those I polled) to be an outright objection to "job
postings", but more like an "inside track" connection.  E.g. if one is
the hiring manager for the position (and would be direct supervisor of
the position), or it is opening for position that would be close peer
in same work area where one works, and one is quite familiar with the
position, then that is - or at least may - generally be okay to post.
But again, not allowing something like HR department or persons within
to post of every Unix/Linux/BSD/etc. or related opening they have that
comes up - even if it's in the Bay Area.  I think the idea there, is to
limit it to folks intimately familiar with the position (and much more
so than HR department, or recruiter, or agency).

As to "commercial" postings, no *unsolicited* commercial postings.  If
it's actually *solicited* - e.g. person(s) specifically ask for and
request the information, that may be "okay" - again, not looking for
"sales pitches" - but rather information, even if from a commercial
source, and *only* when expressly *solicited*.

Anyway, attempting to boil that down into something much more concise
for rules/policy, this is what I come up with for a (rough?) draft:
--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--
Mailing list for the
<A HREF="http://www.buug.org/">Berkeley Unix User group (BUUG)</A>.

An open forum for all things related to Unix.

Note: Unsolicited commercial E-mail is not allowed.
Job postings?  Only if you're intimately familiar with the position, as
in you are the hiring manager and would be direct supervisor for the
position, or it's a close peer position you very regularly do or would
work with and are highly familiar with the position.  Recruiter/agency
doesn't qualify as "intimately familiar", nor does being in HR for the
employer.
Be nice, don't be annoying.
When in doubt, ask first (on the list).

To see the collection of prior postings to the list, visit the
<A HREF="http://buug.org/pipermail/buug/">BUUG Archives</A>.
--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--

Anyway, policy also needn't be "cast in stone", and can be
changed/updated/clarified if/as needed, but also shouldn't be or need to
be changing it willy-nilly.

> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
> Subject: BUUG list policy?
> Date: Thu, 20 Dec 2012 09:15:03 -0800

> I recently noticed on:
> http://buug.org/mailman/listinfo/buug
> That BUUG list policy isn't stated there, however it was
> ("historically") stated on the list page before the migration of the
> list to the balug.org domain:
> http://web.archive.org/web/20100630003254/http://www.weak.org/mailman/listinfo/buug
> However, list policy is also stated/implied on:
> http://www.buug.org/
> What's stated there, however, matches neither what was, nor is, on the
> list page itself.
>
> Anyway, perhaps we can discuss this at this evening's BUUG meeting a bit
> (and/or on list a bit if/as needed), and figure out what the policy
> ought to say, and have http://buug.org/mailman/listinfo/buug and
> possibly also
> http://www.buug.org/
> updated so they're consistent.
>
> In the interim, I'd say what's stated on
> http://www.buug.org/
> takes precedence, as list policy isn't currently stated elsewhere on the
> site in any "official" location.



From Michael.Paoli at cal.berkeley.edu  Sat Dec 22 00:36:53 2012
From: Michael.Paoli at cal.berkeley.edu (Michael Paoli)
Date: Sat, 22 Dec 2012 00:36:53 -0800
Subject: [buug] converting Ubuntu to Xubuntu?
Message-ID: <20121222003653.15976g6xmsvywoco@webmail.rawbw.com>

Question about that was asked at last BUUG meeting[0].  Thought I'd
peek into it a wee bit further.  Most notably, I was curious, does
Xubuntu use the same repositories as Ubuntu?  After all, Kubuntu and
Xubuntu are "just" different flavors/spins of Ubuntu - or at least so
I've presumed.  Well, I didn't have Xubuntu handy, but I did have
readily available Kubuntu ISO[1] ... even if an older[2] one.  So, I
rather quickly and conveniently set up and launched it "live" ("Try
Kubuntu") on a qemu-kvm virtual machine.  And I had a look at the
sources configuration for apt (since {U,Ku,Xu}buntu are .deb dpkg and
apt based, but their installations don't use the Debian repositories).
Well, as far as I can easily tell, at least for
Kubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
it uses in its apt configuration[2]:
deb cdrom:[Kubuntu 10.10 _Maverick Meerkat_ - Release i386  
(20101007)]/ maverick main restricted
deb http://archive.ubuntu.com/ubuntu maverick main restricted
deb-src http://archive.ubuntu.com/ubuntu maverick main restricted
deb http://security.ubuntu.com/ubuntu maverick-security main restricted
deb-src http://security.ubuntu.com/ubuntu maverick-security main restricted
deb http://archive.ubuntu.com/ubuntu maverick-updates main restricted
deb-src http://archive.ubuntu.com/ubuntu maverick-updates main restricted
and that's likely same - or at least same repositories, as
corresponding Ubuntu version:
Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
So, I presume similar likely applies to current Ubuntu and Xubuntu -
e.g. 12.10 or 12.04.x LTS, or any currently supported versions.

So, I'd think, at least theoretically, converting from Ubuntu to Xubuntu
should be relatively feasible with an approach approximately as follows:
o Backup :-) - one will generally always want to be able to
   recover/restore, even if thing(s) go (very) badly.  This includes also
   having suitable recovery/restore boot (e.g. media) options available -
   for fixing, recovery, or restore, as may be needed.
o update - get current installation caught up on security and critical
   bug fix updates, to a currently supported release.  Namely the apt
   sources configuration should still be pointing to a release version
   that's still supported (if not, do the operating system upgrade
   procedures to get there first).  Procedure may be a bit different for
   {U,Ku,Xu}buntu, but typically on Debian to get caught up on security
   and critical bug fix updates, something like:
   # aptitude update
   # aptitude safe-upgrade
o make sure no packages are in broken state or have any broken
   dependency issues, etc.  (The Debian release notes on upgrade
   procedure cover that well, I'd think {U,Ku,Xu}buntu has similar)
o gather and save information on installed packages:
   $ dpkg --get-selections > Ubuntu_dpkg_--get-selections
o boot "live" CD version of Xubuntu corresponding to same version of
   Ubuntu that is installed.  Use, (I presume) "Try Xubuntu".
   That should be done on same system (or highly similar system) where
   Ubuntu is currently installed, mostly notably so automagic hardware
   detection, and any corresponding
   installation/configuration/autoconfiguration of packages will well
   match the target hardware
o likewise save information on installed packages, e.g.:
   $ dpkg --get-selections > Xubuntu_dpkg_--get-selections
o It may be advisable/handy/useful, to also (if feasible), save a copy
   of the whole running live Xubuntu system, or if not that, perhaps at
   least most all its configuration files (e.g. everything under /etc).
   That may come in handy later for analysis/comparison purposes.
o save the apt sources configuration information
o shutdown the Xubuntu live, and reboot the installed Ubuntu
o adjust the configured apt sources as may be necessary to match those
   for Xubuntu (presuming it still uses the same repository).  Most
   notably one may need to change CD-ROM image configuration in the apt
   sources with, (I presume for {U,Ku,Xu}buntu) apt-cdrom
o use dpkg --set-selections to select packages for install that were so
   set on Xubuntu, but not the existing Ubuntu configuration.  Use
   {U,Ku,Xu}buntu's recommended tool(s) to make those updates (I
   don't know if they specify or prefer aptitude, apt-get, synaptic, ...)
   Note that tools like awk(1), sort(1), uniq(1), comm(1), etc. may be
   highly useful here.  E.g. for the aforementioned example saved files,
   for packages marked install on Xubuntu, but not Ubuntu, to produce
   list suitable for dpkg --set-selections (here the leading "> " is PS2
   prompt):
   $ {
   > awk '{if($2=="install")print $1;}' Xubuntu_dpkg_--get-selections |
   > sort -u
   > awk '{if($2=="install")print $1; print $1;}' \
   > Ubuntu_dpkg_--get-selections
   > } | sort | uniq -u | awk '{print $0, "install";}'
   That can then be saved to another file and used for input, or piped
   directly to dpkg --set-selections, but note that for --set-selections,
   one will need to be superuser (root).
o after those packages are installed, likewise produce a list to see
   what packages we earlier noted as installed on Ubuntu but that were
   not installed on Kubuntu (I'll leave how to do that as an exercise
   for the reader).  One will generally want to remove those packages -
   exceptions being packages one either explicitly installed - or
   installed as a dependency, and that have nothing to do with Ubuntu
   vs. Xubuntu (e.g.  random unrelated utility package one installed).
   The --simulate option to aptitude, or similar "preview"
   functionality, can be useful to help ensure one doesn't accidentally
   remove a dependent package, and its reverse dependencies, when such
   was not intended.  apt-cache search rdepends might also be useful to
   aid in determining such dependencies and avoiding inadvertent
   removals.  It may be advisable to also "purge", rather than remove,
   when removing packages - though one could also, and perhaps a bit
   more safely/convenient, remove first, and later purge those packages
   that have been removed (key difference being purge gets rid of
   associated configuration files, whereas remove does not).
o configuration files - the preceding should mostly cover the
   "conversion" and packages and such.  However some configuration files
   may need to be suitably adjusted.  That's where saving such from the
   live Xubuntu, as noted earlier, may come in handy.  There are also
   bits of documentation on The Internet that seem to hint at what
   file(s)[4] may need configuration tweaks.
o There are various documents/writeups on The Internet that seem to
   imply doing the Ubuntu --> Xubuntu conversion is quite doable, though
   potentially a bit hazardous.  One thing I note on most of the
   documents I easily found, is they seem to all give quite static lists
   of packages to add, and remove, to do the conversion - so those may
   only fit a very specific release version, or limited range of
   versions.  The procedure I gave should be more generic in that
   regard, by specifically getting the lists of packages, and suitably
   comparing to determine what's needed, and what should be removed (one
   could also do a list from corresponding live Ubuntu, as that would
   avoid the complication of having additional packages one has already
   installed on one's existing Ubuntu installation).  The documents I
   encountered also failed to mention updating the CD-ROM (or DVD)
   source(s) in the apt configuration.
o Anyway, once that's all done, reboot to ensure things still look good,
   and that should be it.
o Other random bits/caveats:
   o hopefully it's fairly obvious ;-), but don't be running under a
     desktop/GUI environment that uses or depends upon package(s) one is
     in process of removing whilst removing or attempting to remove them.
   o I am *not* an {U,Ku,Xu}buntu expert, these are "just" my educated
     guestimates.
   o I've not tested the proposed procedure.
   o Still, the proposed procedure may be (much) less painful than the
     safer do fresh install, then (carefully) merge data in after that.
     Besides, you do have good backups, right?  And you have tested them
     and your restore procedure (at least enough to be satisfied on
     statistic probability of successful restore/recovery)?
   o knowing how to do things from the command line is good, particularly
     if the desktop environment has non-trivial probability of breaking
     at some point along the way of the conversion procedure.

footnotes/references:
0. BUUG meeting conversation 2012-12-20
1. http://buug.org/pipermail/buug/2012-December/003961.html
2. Kubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
3. script(1):
    Script started on Sat 22 Dec 2012 06:34:54 AM UTC
    To run a command as administrator (user "root"), use "sudo <command>".
    See "man sudo_root" for details.

    ubuntu at ubuntu:~$ PS1='$ '; set -o vi
    $ unalias alert egrep fgrep grep l la ll ls
    $ cd /etc/apt
    $ ls -ond *sources*
    -rw-r--r-- 1 0 1996 2012-12-22 06:28 sources.list
    -rw-r--r-- 1 0 1898 2010-10-07 16:47 sources.list~
    drwxr-xr-x 2 0    3 2010-10-05 14:09 sources.list.d
    $ find sources.list sources.list.d -follow -type f -print
    sources.list
    $ grep '^[      ]*[^    #]' sources.list
    deb cdrom:[Kubuntu 10.10 _Maverick Meerkat_ - Release i386  
(20101007)]/ maverick main restricted
    deb http://archive.ubuntu.com/ubuntu maverick main restricted
    deb-src http://archive.ubuntu.com/ubuntu maverick main restricted
    deb http://security.ubuntu.com/ubuntu maverick-security main restricted
    deb-src http://security.ubuntu.com/ubuntu maverick-security main restricted
    deb http://archive.ubuntu.com/ubuntu maverick-updates main restricted
    deb-src http://archive.ubuntu.com/ubuntu maverick-updates main restricted
    $ exit
    exit

    Script done on Sat 22 Dec 2012 06:37:58 AM UTC
4. https://sites.google.com/site/easylinuxtipsproject/alternative



From Michael.Paoli at cal.berkeley.edu  Sat Dec 22 09:24:11 2012
From: Michael.Paoli at cal.berkeley.edu (Michael Paoli)
Date: Sat, 22 Dec 2012 09:24:11 -0800
Subject: [buug] Fwd: Re:  converting Ubuntu to Xubuntu?
Message-ID: <20121222092411.10953yro8n6y4o2s@webmail.rawbw.com>

There's also Ubuntu Core[1], which may serve as useful comparison reference
point (namely installed packages) or clean, stripped down base from
which to start (roughly analogous to a Debian base installation with
nothing else added).

And, a bit more regarding converting among {U,Ku,Xu}buntu remixes (as
Ubuntu terms them):

forwarded bit/excerpt:

----- Forwarded message from jb at caustic.org -----
     Date: Sat, 22 Dec 2012 01:32:40 -0800
     From: "Johan Beisser" <jb at caustic.org>
  Subject: Re: [buug] converting Ubuntu to Xubuntu?
       To: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>

> From experience, it's rather painless to move from Ubuntu to the  
> other variants.

I moved my generic Gnome based Ubuntu box to using KDE a while back
(Kubuntu), and had no issues tracking it since.

-jb

(sorry for replying directly to you, but this email isn't registered
with the BUUG ML manager, and I've not gotten the motivation together
to update things)

On Sat, Dec 22, 2012 at 12:36 AM, Michael Paoli
<Michael.Paoli at cal.berkeley.edu> wrote:
[2]

----- End forwarded message -----

references/footnotes:
1. https://wiki.ubuntu.com/Core
2. [buug] converting Ubuntu to Xubuntu?:
    http://buug.org/pipermail/buug/2012-December/003964.html



From nick at zork.net  Sat Dec 22 10:34:08 2012
From: nick at zork.net (Nick Moffitt)
Date: Sat, 22 Dec 2012 18:34:08 +0000
Subject: [buug] converting Ubuntu to Xubuntu?
In-Reply-To: <20121222003653.15976g6xmsvywoco@webmail.rawbw.com>
References: <20121222003653.15976g6xmsvywoco@webmail.rawbw.com>
Message-ID: <20121222183408.GG2729@zork.net>

Michael Paoli:
> Well, as far as I can easily tell, at least for
> Kubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
> it uses in its apt configuration[2]:

You will have to switch any apt sources for Ubuntu 10.10 to use
"old-releases.ubuntu.com" as the hostname, because:

	http://fridge.ubuntu.com/2012/04/10/ubuntu-10-10-maverick-meerkat-end-of-life-reached-on-april-10-2012/

-- 
"Forget the damned motor car
and build cities for lovers and friends."
       -- Lewis Mumford

From lyz at princessleia.com  Sat Dec 22 11:36:58 2012
From: lyz at princessleia.com (Elizabeth Krumbach)
Date: Sat, 22 Dec 2012 11:36:58 -0800
Subject: [buug] converting Ubuntu to Xubuntu?
In-Reply-To: <20121222003653.15976g6xmsvywoco@webmail.rawbw.com>
References: <20121222003653.15976g6xmsvywoco@webmail.rawbw.com>
Message-ID: <CABesOu0Ob=TrLiCpwu7-F7p5MkRRu_YGgRLv4-0sQ4TfLMJGYg@mail.gmail.com>

On Sat, Dec 22, 2012 at 12:36 AM, Michael Paoli
<Michael.Paoli at cal.berkeley.edu> wrote:
> Question about that was asked at last BUUG meeting[0].  Thought I'd
> peek into it a wee bit further.  Most notably, I was curious, does
> Xubuntu use the same repositories as Ubuntu?

I'm a member of the Xubuntu project. As you noticed, Ubuntu and the
other recognized flavors do use similar repositories. I can't speak
for Maverick Meerkat (I don't remember, it's EOL and I don't have an
installed version) but in currently supported versions Xubuntu uses
the "universe" repository too. Technically the universe repository is
fully community-supported (like Xubuntu itself is) so security updates
are not guaranteed by Canonical like they would be in "main" and
"restricted" which are the repositories Ubuntu itself uses.

> o There are various documents/writeups on The Internet that seem to
>   imply doing the Ubuntu --> Xubuntu conversion is quite doable, though
>   potentially a bit hazardous.  One thing I note on most of the
>   documents I easily found, is they seem to all give quite static lists
>   of packages to add, and remove, to do the conversion - so those may
>   only fit a very specific release version, or limited range of
>   versions.  The procedure I gave should be more generic in that
>   regard, by specifically getting the lists of packages, and suitably
>   comparing to determine what's needed, and what should be removed (one
>   could also do a list from corresponding live Ubuntu, as that would
>   avoid the complication of having additional packages one has already
>   installed on one's existing Ubuntu installation).  The documents I
>   encountered also failed to mention updating the CD-ROM (or DVD)
>   source(s) in the apt configuration.

This is the online resource that the Xubuntu team recommends since the
author is diligent about updates (tests them, updates for each version
and links to past ones where the release is still supported):

http://www.psychocats.net/ubuntu/purexubuntu

(the one for maverick is here:
http://www.psychocats.net/ubuntu/purexfcemaverick)

Once that command is run, the metapackage to install to get Xubuntu
is: xubuntu-desktop

That said, your recommended procedure sure is the more intelligent,
portable one that's useful beyond just this conversion.

-- 
Elizabeth Krumbach // Lyz // pleia2
http://www.princessleia.com

From rick at linuxmafia.com  Mon Dec 31 19:57:31 2012
From: rick at linuxmafia.com (Rick Moen)
Date: Mon, 31 Dec 2012 19:57:31 -0800
Subject: [buug] BUUG list policy?
In-Reply-To: <20121221114323.16552qs9hxnn28sg@webmail.rawbw.com>
References: <20121220091503.51884k458kmi0ry8@webmail.rawbw.com>
 <20121221114323.16552qs9hxnn28sg@webmail.rawbw.com>
Message-ID: <20130101035731.GE23243@linuxmafia.com>

Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):

> --DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--
> Mailing list for the
> <A HREF="http://www.buug.org/">Berkeley Unix User group (BUUG)</A>.
> 
> An open forum for all things related to Unix.
> 
> Note: Unsolicited commercial E-mail is not allowed.
> Job postings?  Only if you're intimately familiar with the position, as
> in you are the hiring manager and would be direct supervisor for the
> position, or it's a close peer position you very regularly do or would
> work with and are highly familiar with the position.  Recruiter/agency
> doesn't qualify as "intimately familiar", nor does being in HR for the
> employer.
> Be nice, don't be annoying.
> When in doubt, ask first (on the list).
> 
> To see the collection of prior postings to the list, visit the
> <A HREF="http://buug.org/pipermail/buug/">BUUG Archives</A>.
> --DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--DRAFT--

1.  As usual, this is a bit overengineered.
2.  Relatively short as it is, sadly, it's longer than people will 
    read and heed.
3.  To the extent people read policies at all, shorter wording makes 
    them more likely to be taken seriously.  In particular, the 
    draft's item about job postings practically begs readers to 
    assume it somehow doesn't apply to them.  

You should consider what the purpose of the policy wording is.  (There
are multiple possibilities.)

FWIW, recruiters are, God love 'em, statistically the least likely
people on the planet to pay attention to job-posting policies.
Especially convoluted ones.

I note: 

> When in doubt, ask first (on the list).

The people who most need to pay attention to that are by definition the
very least likely to.  So, you're basically reaching _already_ polite and
thoughtful people to tell them 'Oh, by the way, please be polite and
thoughtful.'

> Note: Unsolicited commercial E-mail is not allowed.

Oh, _that's_ super useful.  I'm sure the spammers will be impressed,
because, y'know, they never send it where it's unwanted.  (In this
context, the phrase 'no allowed' basically is devoid of meaning.)