The meaning of Vcs-* fields

[Teemu Likonen]

Hi

I do not maintain any official Debian package nor I'm a Debian developer 
but I'm interested in some of the Debian's technical points anyway.

About these new Vcs-* fields in debian/control: it's not clear to me 
where the URLs should be pointing at. Are they meant to point to the 
upstream VCS where the actual development happens, so that users can 
checkout the upstream trunk (?) directory easily? Or should the Vcs-* 
URLs point to the Debian _metadata_ which is maintained by the 
package's official Debian maintainer? (Basically by 'metadata' I mean 
the 'debian' directory.)

I do maintain some unofficial packages which - of course - I can do 
anything I want with, but I also want to do things right, so I'd 
appreciate your help in this.


This is a good opportunity to thank the Debian developer community for 
this excellent operating system as well as many excellent tools it 
accompanies. I've had quite a lot of work recently, mostly not related 
to computers, and it's great to have a tool (i.e. Debian 4.0) that I 
can trust. Thank you guys!


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: The meaning of Vcs-* fields

[Teemu Likonen]

Andreas Tille kirjoitti:

> On Sat, 26 Jan 2008, Teemu Likonen wrote:
> > I do maintain some unofficial packages which - of course - I can do
> > anything I want with, but I also want to do things right, so I'd
> > appreciate your help in this.
>
> May I ask for the sake of interest what unofficial packages you
> are maintaining?  Sometimes it makes sense to publish your work
> for a wider audience.

You may. Actually "my" packages have already been published in Debian. 
I'm one of the upstream authors of Finnish spell-checking system Voikko 
(small part of it). Voikko's upstream developers maintained early 
Debian packages in purpose to help us to test the software and gain 
more testers from larger audience. For some time those packages were 
for end users too.

Now Timo Jyrinki is maintaining the official Debian and Ubuntu packages 
for Voikko (see aptitude search '~mjyrinki'). To help testing we still 
have the Debian-specific data in Voikko's upstream svn repositories. So 
those are the unofficial "packages" I still maintain. Timo Jyrinki is 
keeping touch with us and does a great job in spreading Voikko around 
Debian and Ubuntu world. Thanks Timo if you're reading this. :)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Teemu Likonen]

Lars Wirzenius kirjoitti:

> On to, 2008-01-31 at 09:19 +0100, sean finney wrote:
> > is there any reason why this issue couldn't be solved by amending
> > policy (or just simply patching dpkg-source) to require that
> > "debian/rules patch" (or some less commonly used name if we're
> > worried about existing implementations of this rule) is called as
> > part of the unpacking process or a source package? just a
> > thought...
>
> That would be one possible way of implementing it. I'd be satisfied
> with that, and it's in the spirit of the way Debian tries to
> standardize on interfaces that don't unduly limit implementation.

To add up to this suggestion:

If some patch system is used, there would be mandatory targets 
like "patch", "patch-new" and "patch-save" in the debian/rules. These 
can probably be included from /usr/share/quilt/quilt.make 
or /usr/share/dpatch/dpatch.make or similar. Also a target 
like "unpack" must be available if upstream sources are in compressed 
form inside the orig.tar.gz.

If debian/patches directory exists (or the patch system is detected some 
way or another), "dpkg-source -x" would run "debian/rules patch" with 
output like "Applying Debian-specific patches from 
debian/patches...done". If upstream source package is in compressed 
form inside the orig.tar.gz, then the "patch" target must depend 
on "unpack" target which unpacks and prepares the upstream stuff to 
patchable and editable source form.

After applying the patch series, "dpkg-source -x" would say something 
user-friendly like "To add new modifications, first run 'debian/rules 
patch-new', then edit files and finally run 'debian/rules patch-save'." 
The "patch-new" target would prepare a new patch to the end of the 
series and take a snapshot copy from the current source tree. 
The "patch-save" target diffs all the modifications agaist the snapshot 
and adds them to this new patch. The "patch-new"-edit-"patch-save" 
round can be repeated many times if one wants to create separate 
patches.

Would this work? :)

As Lars said, a build-depend for a patch tool is not enough. Tools must 
be available when running "dpkg-source -x" so maybe dpkg-source needs 
to check patch system's availability when it detects some patch system 
being used.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Teemu Likonen]

Charles Plessy kirjoitti:

> Le Thu, Jan 31, 2008 at 11:51:05PM +1100, Ben Finney a écrit :
> > I'm *not* happy to need to run some target with arbitrary commands
> > in the 'debian/rules' file, just to allow me to examine the source.
> > A big part of the reason for unpacking the source could be to find
> > out what's in there *before* executing any part of it.
>
> I do not know if it would be reasonnable to extend the scope of the
> discussion to third-party packages. For the packages distributed by
> Debian, there are quite many safety guards that should make people
> think that it is not unsafe to run 'debian/rules patch' (for the
> moment it has not been proposed to go through another mechanism).

Hmm, does dpkg-source need to automatically apply any patches at all? It 
could just detect that a patch system is in use and inform the user 
that there are some patches which can be applied by 
running "debian/rules patch". This information is just to help users; 
technically it's irrelevant.

To me it seems quite clear that some kind of "debian/rules patch-new" + 
edit source + "debian/rules patch-save" round is needed to make 
non-maintainers' modifications easy when the package utilizes a patch 
system. Modifications need to act nicely with the patch series and what 
those modifications actually are must be marked somehow; hence my 
suggestion about patch-new and patch-save (or similar) rules. This 
keeps them from being specific to any particular patch system and 
non-maintainers' don't necessarily need to learn new patch management 
tools. Of course such rules can be helpful for maintainers' too.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Teemu Likonen]

In this message I'm only speaking about the orig.tar.gz+diff.gz and 
patches-as-separate-files approach and its possible standardization. 
I'm not very familiar with VCS brances approach.

Most of these thoughts have already been given by different people in 
this thread. I just collect (some of) them together to one message with 
a real life example.


Raphael Hertzog kirjoitti:

> Some questions/problems:
>
> 1/ it seems that we agree that patches should be applied by default
> during unpack of the source archive. This means that dpkg-source
> might want to know which patches are currently applied (or we could
> get strange results while building the package with patches
> unapplied)... do we use the same format than quilt for that (.pc
> directory AFAIK)?

Standardizing the patch format would be quite elegant. It would probably 
be the safest way to apply debian/patches/ automatically. Such a 
behaviour may not be suitable for all packages and maintainers, though. 
I take the vim package as an example. I'm not speaking behalf of Vim 
maintainers; these are just my personal thoughts.

The upstream of Vim provides source packages and a set of numbered 
patches meant to be applied to the source tree. The Debian vim package 
(orig.tar.gz+diff.gz) contains the following files and directories 
(among many others):

# Upstream tarballs:
vim-7.1/upstream/tarballs/vim-7.1-extra.tar.gz
vim-7.1/upstream/tarballs/vim-7.1-lang.tar.gz
vim-7.1/upstream/tarballs/vim-7.1.tar.bz2
# Upstream patches:
vim-7.1/upstream/patches/7.1.???
# Vim maintainers' patches managed with quilt:
vim-7.1/patches/*.diff

Before the package is actually built, "debian/rules extract" first 
extracts the upstream tarballs, then applies all the upstream patches 
and finally applies Vim maintainers' quilt-managed patches. To me this 
seems to be very good way to handle debianized vim package. Upstream 
archives and patches are as the upstream provides them and the Debian 
part is separate from them.

Now, if all the patches should be automatically applied 
by "dpkg-source -x", packages like vim should move all the upstream 
patches to debian/patches/ directory as well as distribute the upstream 
tarballs in extracted form inside the orig.tar.gz. Now doubt this is 
possible but I think Vim maintainers' way is quite elegant to this 
package.

But, if there were not any "standard Debian patch format" (maybe only a 
recommended way) but a standard interface for (un)applying patches, 
then it would be possible to handle varying situations. Let's say 
that "debian/rules patch" would be the standard way. Then the vim 
package's "debian/rules" could provide the 'patch' target which 
extracts all the three tarballs, applies the upstream and downstream 
patches and hence provides the ready-to-edit source form.

I agree with others that "debian/rules patch" shouldn't be run 
automatically. It is a security risk to execute code from inside the 
package the moment it is extracted. So maybe patches shouldn't be 
automatically applied. I think it's not necessary. If there were easy 
and standard way of doing so (like "debian/rules patch"), then 
non-maintainers' job is not too difficult.

It seems clear that with packages like vim it's not possible to just 
edit the source code and run dpkg-buildpackage. It's very likely to 
lead to conflicting patch files. (The current vim package in Sid 
applies 241 upstream patches and 34 Debian patches.) A non-maintainer 
who wishes to fix a bug in such a package should either need to learn 
the patch system used by the maintainers or use some not-yet-defined 
standard interface for adding modifications.

The standard interface for modifications could be provided by some 
external tool or a target like "debian/rules patch-new". I guess the 
basic procedure for such tool(s) is to 1) ensure that all the patches 
are applied (e.g. run "debian/rules patch"), 2) take a snapshot from 
the source tree, 3) allow free editing, 4) make a diff of changes and 
add it to the end of the patch series. I think it would be an advantage 
if this procedure could be repeated so that separate logical patches 
could be added.

If the standard interface for applying patches and making additional 
modifications is provided through "debian/rules" then I think the 
needed makefile targets in most situations could be included from some 
standard include file like /usr/share/quilt/quilt.make. Only in special 
cases the maintainers would need to provide the targets themselves.

This is how it seems to me. (Not all my original ideas, though.)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Kernel 2.6.25 broke iPod support for me, but who to bug?

[Teemu Likonen]

Frank Lichtenheld wrote:

> I traced the error back to a change in kernel 2.6.25: Apparently vfat
> file system can now become case sensitive in some cases
> ("FAT: utf8 is not a recommended IO charset for FAT filesystems,
> filesystem will be case sensitive!") 

> - kernel: I find it unlikely that the mentioned change was done without
>   a good reason given its obvious behavioural change. So I guess the
>   chances that it can be reversed are slim. But I might be wrong?

I have described one aspect of this issue in the bug report #417324:

"linux-2.6: UTF-8 is the system-wide default encoding in Debian but
kernel's filesystem modules use ISO-8859-1"

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=417324

In short: VFAT filesystem stores long filenames _always_ in UTF-16.
Since Debian doesn't use UTF-16, filename strings must always be
converted to some other encoding (and that's the option we give to mount
or to kernel at compile time). Debian's default is UTF-8 so the obvious
default for kernel's filesystem modules is also UTF-8. As you noticed,
the change was introduced in the Debian kernel 2.6.25.

There have been serious filename issues before the change. By default
Debian Etch (excluding KDE) writes complete garbage to VFAT filenames
(only ASCII characters work). Etch also interprets beyond-ASCII
filenames in VFAT wrong if they were written by a correctly configured
system (MS Windows, for example). I described the conversion problems in
#417324.

BTW, I'm using shortname=mixed succesfully here.

(I'm not a subscriber to -devel, so please Cc me, thanks.)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?

[Teemu Likonen]

Ben Finney (2008-10-21 17:37 +1100):

> That's not the point being made: As I understand Manoj's point, it is
> that tagging a bug ‘lenny-ignore’ is an active decision that a
> particular bug, even if it represents a DFSG violation, will not be
> considered in the decision to release.
>
> To that extent, it *is* making the decision that it is acceptable to
> release Debian with DFSG-violating works, in advance of the decision
> to actually release.

OK guys, please. As a random Debian user may I suggest that you stop
investigating _who_ is violating DFSG and instead focus on _what_ things
are the cause of violating DFSG. I guess we know about the "what" part
already and that part exists in Sid too. So I think you should do

apt-get source linux-2.6

and go fix the issues you are concerned about - or help testing the
fixes provided by others (I might do some testing too). And perhaps the
users whose hardware won't be supported anymore appreciate some help on
how to work around their problem. (It looks like this includes me.)

Anyway, thanks for all the DDs and Debian community for this
mostly-pretty-good operating system.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [DRAFT] resolving DFSG violations

[Teemu Likonen]

Thadeu Lima de Souza Cascardo (2008-10-28 16:07 -0200) wrote:

> On Tue, Oct 28, 2008 at 06:01:45PM +0100, David Weinehall wrote:
>> Throwing out the firmware doesn't help our users, it makes things
>> worse for our users. And our users are our number one priority.
>
> Is it not providing them the best free/libre operating system?

Perhaps so, but it has also become quite clear that different people
have different goals and different definitions for software freedom. The
Social Contract means different things to different people. Therefore
it's a good paper to back up one's own views, whatever they are.

 1. Debian will remain 100% free

[...] We will never make the system require the use of a
non-free component.

The "system" doesn't require non-free components; it's just some users
and their hardware that does. Debian cares about the "system".

 4. Our priorities are our users and free software

We will be guided by the needs of our users and the free
software community. We will place their interests first in our
priorities. [...]

Probably everybody has an opinion about what "our users" and the "free
software community" needs. By definition, "our users" are people who use
Debian. If they stop using Debian (perhaps because they don't like it or
it doesn't work in their machine) they are not our users anymore so
those people don't count. In the end Debian developers can just think
that "what I need is also the need of our users." :-)

I'm not ranting. I'm actually very happy and "passionate moderate"[1]
Debian user. Thanks you, everyone.

--
 1. http://lkml.org/lkml/2006/9/27/414


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DFSG violations in Lenny: Summarizing the choices

[Teemu Likonen]

Ben Finney (2008-11-09 10:54 +1100) wrote:

> We don't distribute non-free *anything* in Debian. That's what our
> users are promised, at any rate.

Yes, this claim has been repeated many times, but as a thought-exercise
let us be more concrete: who exactly are those users who have been
promised? I mean, we know what the DFSG paper says but what and where is
the group of people (users) who got that promise and are deeply in their
hearts relying on Debian to keep it *in the context of firmwares*?

As far as I know, none of us have made a survey for Debian users and
studied how they want this "promise" to be applied when it comes to
firmware blobs. Neither have I. So when discussing this matter I'd say
that it's a lot more *honest* to point directly to the words and
sentences in the DFSG paper than to some supposed group of people who is
supposed to rely on some supposed promise. Argumentation based on
"general opinion" is not valid unless one has some facts what this
general opinion is.

(I'm sorry for the following religious reference in this
international and multi-cultural community but this is only a side
note. As you know, some people have the Bible as their guide. In
many ways it's a very good guide - in my opinion - but at the same
time I think it's a really bad guide if you take every bit in the
book literally and refuse to consider the current reality [which is
always social construction]. Firmware blobs didn't exist when Jesus
lived, and I believe most Debian users understand this.)

I like the point Theodore Ts'o made about what is or isn't "going to
help make the world a better place." In my opinion being too extremist
doesn't serve one's wider goals (if such thing exist) but the person
himself.

I don't care what category firmware blobs are in Debian (non-free or
whatever), but I think firmware which is separated from hardware is
definitely not evil. They are even a good thing, and therefore
*hardware* which can be supported through free drivers should be
supported out-of-the-box by the Debian installer.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: First call for votes for the Lenny release GR

[Teemu Likonen]

Manoj Srivastava (2008-12-17 17:02 -0600) wrote:

> If there is sufficient support, we could also scrap the
>  current vote, change our ballot, add options to it, or something, and
>  restart the vote, but that would need a strong grass roots support (I
>  do not think the secretary has the power to do so).

I don't know if non-developers' opinions count but since from the
outside Debian seems to be pretty much an open community I'll voice my
opinion anyway.

I've been following the firmware and voting discussion very closely and
I think that changing and restarting the vote would _definitely_ be the
right thing. In a democratic decision-making it's too dangerous to
conduct a ballot which (many) people can't trust. I think this is
clearly the case here: many seemingly intelligent people with good
arguments are unhappy with the ballot, how it is organized etc., and
will likely have hard time trusting the results. This ballot may
potentially cause damage for Debian.

So, no matter whose "fault" the current situation is or who has the
constitutional power to do what. I think the most important thing is to
act towards maintaining people's trust to the decision-making process.
May I suggest restarting the discussion and vote? Please?


(Just an opinion from a happy Debian Lenny user. Thank you for creating
and working for such a great operating system.)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Is The number of stable users dropping fast?

[Teemu Likonen]

Petter Reinholdtsen (2008-12-21 14:38 +0100) wrote:

> [Florian Weimer]
>> This doesn't appear in the per-architecture statistics. Are you sure
>> you got your numbers correct?

> As you can see, the number of submissions have dropped the last month.
> Not by much so far, but it used to increase every week.

Maybe we want to look at the bigger picture. This is a graph about the
number of installations of popularity-contest package from the release
of Etch to this day:

http://qa.debian.org/popcon-graph.php?packages=popularity-contest&show_installed=on&from_date=2007-04-08&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

(Obviously this is does not make distinction between stable, testing and
unstable.)

This time frame tells or suggests that Debian's popularity increased
very much after Etch release and it has remained about the same after
March/April 2008. It's too early to make any estimations from the last
month.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#457839: general: Many man pages display shell quotes ` and ' wrong in Unicode environment

[Teemu Likonen]

Package: general
Severity: normal

In Unix/Linux shells the Ascii apostrophe (') is used as single
quotation mark. The grave accent (`) is used as command substitution
mark. In many man pages these are displayed wrong because they have
different meaning in groff code.

In groff code the non-escaped grave accent (`) is logical (English) left
single quotation mark. In Unicode environment (e.g. UTF-8 terminal or
Postscript) it is displayed as U+2018 LEFT SINGLE QUOTATION MARK. In
non-Unicode environment it is displayed as U+0060 GRAVE ACCENT.

Similarly, in groff code the non-escaped Ascii apostrophe and single
quote (') is logical (English) apostrophe and right single quotation
mark. In Unicode environment it is displayed as U+2019 RIGHT SINGLE
QUOTATION MARK and in non-Unicode environment as U+0027 APOSTROPHE.

So, the Ascii grave accent (`) and Ascii apostrophe (') must never be
used to describe shell syntax in groff code. Instead the shell grave
accent (`command` substitution) mark must be "\(ga" and the shell single
quote (' ') must be "\(aq". The following table shows how different
marks display in different environments:

groff  Unicode   non-Unicode

''
``
\(aq   ' '
\(ga   ` `
\` ` `
\' ´ ' (in ASCII)


This is mainly a problem on the upstream side. The fix for this would be
to encourage upstream developers to check the man pages they author and
change ` marks to \(ga (when they are used in shell syntax) and ' marks
to \(aq (again, only when they are used in shell syntax).

Bug#457839: general: Many man pages display shell quotes ` and ' wrong in Unicode environment

[Teemu Likonen]

Russ Allbery kirjoitti:

> Note that it only does this in verbatim text and in C<> blocks, so
> people who use 'text' or `text' in general text in POD will still get
> the Unicode quotes.  I think this is the correct behavior, but I'm
> always open to further suggestions.  (I'm upstream for Pod::Man.)

It's kind of nice to have real English single quotes is general text 
(`these' produce real quotes). They print nicely in PostScript for 
example. But yes, this causes some problems if a man page writer - be 
it a machine or human - is not aware of the difference between English 
quotes and shell quotes. There is logical difference even if they 
happen to appear the same on some systems. It's very easy to write 
something like this to man page's general text: "The string can be 
enclosed in single (') quotes." And now we have English right single 
quotation mark (and apostrophe) in man page, not a shell single quote.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Which spell checkers to include by default?

[Teemu Likonen]

(I just subscribed to this list and tried to construct the References
field manually. I Hope it won't broke threads.)


Petter Reinholdtsen wrote:

[Luca Capello]
> > It seems that I cannot find a comparison of the differences spell
> > checkers.  Please, could you enlighten me on why hunspell should be
> > a better default one?
>
> I can only refer to the knowledge I have gotten from those I know that
> work on spell checkers.  The features of spell checkers is normally
> how well they handle word transformations, concatenations and
> proposals.

You made good points on what spell-checkers are _technically_ better.
I don't know them very well myself but I understand that many of them
are not suitable for synthetic and agglutinative languages like
Finno-Ugric languages. Hunspell seems to be, though, as it was
originally designed for Hungarian.

(For Finnish we even need a completely unique system Voikko which is
used through libvoikko1 and programs depending on it, see 'aptitude
search ~Dlibvoikko1'.)

But I think this is not the main point when deciding the _default_
spell-checker for Debian. A spell-checker may be technically superior to
others but if it's not supported by many languages (i.e. no dictionary
packages) it may not be good default and standard install. I have no
opinion about this myself. Finnish users use Voikko anyway and it is
installed through the Finnish environment task (or desktop task, I don't
remember). I think the question of default spell-checker is more
practical than technical; it has to be considered from supported
languages' point of view.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to make Debian more attractive for users

[Teemu Likonen]

* 2010-07-22 08:11 (UTC), j. jj wrote:

> To attract more people to debian, some particular features are need to
> show to the world.

Debian's attractiveness (or perhaps the lack of it) is probably a sum of
several different things. I think one of those things is the front page
. The page may implicitly suggest that there is
nothing happening in the project. It looks almost always the same,
almost like one of those abandoned projects.

I understand the "patched are welcome" nature of the project but there
has already been an example implementations for the front page. A couple
of years back there was lengthy discussion which even made me feel that
now it's really happening, the front page will change soon, but still
nothing. Were do those suggestions go?

On the other hand, Debian seems to be attractive as a meta distribution.
I heard that of a couple of distros which were previously based on
Ubuntu switched to base their work on Debian directly. That said, I'm a
normal end-user myself and I definitely see Debian as a great end-user
Desktop distro too.

-- 
Feel free to Cc me your replies if you want to make sure I'll notice
them. I can't read all the list mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877hknzykn@mithlond.arda

Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling

[Teemu Likonen]

* 2010-07-25 12:54 (+0200), Marc Haber wrote:

> stable = release
> testing = current
> unstable = development

I like these. They describe the three distributions well and "current"
might encourage more users than "testing". Advertising "constantly
usable" and trendy "rolling release" would surely help.


-- 
Feel free to Cc me your replies if you want to make sure I'll notice
them. I can't read all the list mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zkxfjuld@mithlond.arda

Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling

[Teemu Likonen]

* 2010-07-26 08:13 (+0200), Raphael Hertzog wrote:

>> * 2010-07-25 12:54 (+0200), Marc Haber wrote:
>>> stable = release
>>> testing = current
>>> unstable = development

> I would not introduce "release" but just keep "stable", it describes
> the distribution well.

Yes, that's it: stable - current - development. Now, who will proceed to
make the change? :-) (I can't, I'm not a DD.)


-- 
Feel free to Cc me your replies if you want to make sure I'll notice
them. I can't read all the list mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y6cy2xiu@mithlond.arda

Re: How to make Debian more attractive for users

[Teemu Likonen]

* 2010-07-23 00:27 (+0900), Charles Plessy wrote:

> Le Thu, Jul 22, 2010 at 11:54:16AM +0300, Teemu Likonen a écrit :
>> Debian's attractiveness (or perhaps the lack of it) is probably a sum
>> of several different things. I think one of those things is the front
>> page <http://www.debian.org>. The page may implicitly suggest that
>> there is nothing happening in the project. It looks almost always the
>> same, almost like one of those abandoned projects.
>> 
>> I understand the "patched are welcome" nature of the project but
>> there has already been an example implementations for the front page.
>> A couple of years back there was lengthy discussion which even made
>> me feel that now it's really happening, the front page will change
>> soon, but still nothing. Were do those suggestions go?

> in my opinion, it is not only a question of design, but of
> infrastructure. For me, the combination of CVS and WML finally eroded
> all my motivation over the years for keeping some life in the pages
> under /devel/debian-med. I would welcome any change of VCS and
> language, even if it means losing the history or rewriting the pages
> from scratch.

Yes, sometimes it's not enough to send patches to an established
project. Indeed starting a different (web) project, possibly with
different infrastructure, may be needed if one wants to change things.

Well, I don't understand much about web programming myself so this is
just talk.

-- 
Feel free to Cc me your replies if you want to make sure I'll notice
them. I can't read all the list mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ocdqeipl@mithlond.arda

Re: ignoring the CoC in regards to cc:s (Re: Can we ship sources of a PDF file in the Debian diff?

[Teemu Likonen]

On 2009-04-29 07:46 (+0200), Adeodato Simó wrote:

> + Frank Lin PIAT (Tue, 28 Apr 2009 22:54:07 +0200):
>> If the sender of the previous email is subscribed to the list:

>> If the sender of the previous mail was NOT subscribed to the list.

> And how does one (or their MUA) know which of these is the case?

Yes, nobody knows (nor cares to spend time to find out) who are
subscribed and who are not. People join and leave all the time. People
read mailing lists different ways: some receive email as a subscriber,
some read the list through a mail to news gateway (like Gmane[1]), some
join to a discussion through an email-based bug tracker or web-based
mailing-list archive. Sometimes mails are cross-posted to several lists.

My opinion is that "reply to all" is the only way to manage different
situations reliably and without endless discussion and hassle about the
MUA configuration, email standards, Reply-Tos, Mail-Followup-Tos etc.
While I think the CoC in Debian lists is "broken" I don't have problems
obeying it myself and configuring my MUA to handle it easily.

---
 1. http://gmane.org/
http://dir.gmane.org/gmane.linux.debian.devel.general


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Moving /tmp to tmpfs makes it useless

[Teemu Likonen]

* Toni Mueller [2012-06-02 13:46:19 +0200] wrote:

> My suggested fix for this problem is to install a ~/tmp upon account
> creation, and set the TEMP environment variable in, say,
> /etc/environments. That *should* fix up all cases except for rogue
> applications that don't honour $TEMP. We can then proceed to fix these
> over time, while not demanding too many changes to the general setup.

As a simple Debian user my suggestion is to not "fix" non-problems. /tmp
on a regular disk is not a problem. It works. It has been working nicely
many years. It's the best default.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y5o5zz5p@mithlond.arda

Re: emacs23 and/or emacs24 in Wheezy?

[Teemu Likonen]

Jean-Christophe Dubacq [2012-07-26 07:47:28 +0200] wrote:

> And AucTeX does not work with emacs24. Even following some indications
> in the bug reports I didn't succeed in having it work, so I
> uninstalled it.

Just a note that Emacs 24 has its own package manager now (M-x
list-packages) and a working AucTeX can be downloaded with it. I've been
using it several months and have not seen problems. I also use
self-compiled upstream Emacs 24.1.

I understand that Debian packages are a different thing. Just wanted to
make this point about upstream.


pgpZjIBh0WNzr.pgp
Description: PGP signature

Re: network-manager as default? No!

[Teemu Likonen]

* 2011-04-06T16:45:03+02:00 * Heiko Schlittermann wrote:

> Stanislav Maslovski  (Sun Apr 3
> 12:37:26 2011):
>> On Sun, Apr 03, 2011 at 10:11:03AM +0200, martin f krafft wrote:
>>> But if network-manager would become default and ifupdown an optional
>>> replacement, I would question Debian's capacity to make technically
>>> excellent decisions and wonder, how much we have been dragged along
>>> by "user-friendly distros" and slid off the track.
>> 
>> I agree. If that happens I will seriously think about moving to
>> another distro (I have been using Debian since around 1999). Or maybe
>> to a *BSD.
>
> Using Debian (and partly supporting it) since about 1996: as soon as
> the network manager and similar tools become the default, it will be
> Debian's last days on my and our customers machines.

There is a pretty good technical discussion going on about this subject
at the very moment. If you have useful information to add to that
discussion please share it. Stating that "if you do this, I'm gonna
leave" does not help. Technical information is more useful. Someone who
really understands how different alternatives work could add valuable
information and opinions to the discussion. You know, everyone wants to
make Debian better and there is this usual challenge of having different
tools with different advantages and disadvantages. How to combine as
much advantages as possible?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sjtvqssw@mithlond.arda

Re: getting rid of "testing"

[Teemu Likonen]

Ian Jackson [2019-06-25 11:09:06+01:00] wrote:

> ~Ansgar writes ("getting rid of "testing""):
>>   deb http://deb.debian.org/debian debian11 main
>>   deb http://security.debian.org/debian-security debian11-security main

> Yes, please, absolutely.  And this should be the default.

> The syntax "debian11" is precisely right.  Please don't add a hyphen
> to it, as hyphens are already used for separating things like
> -security.

> For now, the `debian11' can be an alias.

As a mere user I'd say this is the best approach: add debian10, debian
11 etc. alias or perhaps later make it the proper name.

My first Debian was Woody. I remember that Sarge was after that, then
Etch or Lenny (I think), but it all started to blur at that time. Now I
know that I'm using Debian 9 but don't remember its name. I don't
remember what was the name of the previous version.

I think it's best to use version numbers for communication with users
and to configure Debian (like sources.list).

Anyway, thank you for this excellent operating system.

-- 
/// Teemu Likonen   <https://github.com/tlikonen> //
// PGP: 4E1055DC84E9DFF613D78557719D69D324539450 ///


signature.asc
Description: PGP signature

Re: Has anyone else perceived this email as spam?

[Teemu Likonen]

MAD [2019-08-23T08:31:37-03] wrote:

> Subject: Re: Has anyone else perceived this email as spam?

It is spam. Unfortunately your message was spam too because you quoted
the spam message. People's mail clients and mail servers have spam
filters which are trained automatically (and manually) and it is
possible that you got counted as a spam sender because your message had
spam content. I manually marked your message as spam to make Bogofilter
know about the content. I think you should not resend spam in email
form. If you need to refer to a spam content publish it somewhere else
in the internet.

-- 
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tliko...@iki.fi
/  https://keybase.io/tlikonen  https://github.com/tlikonen


signature.asc
Description: PGP signature

Re: Deprecation of /etc/alternatives?

[Teemu Likonen]

* 2023-12-23 15:34:49+0100, Gioele Barabucci wrote:

> While we are on the topic of alternatives, I hope to see the
> maintscript-based /etc/alternatives paradigm deprecated in favor of
> the package-based X-is-X paradigm introduced by `python-is-python3`.

I hope not. For example, as a user it is nice to execute a single
command (update-alternatives) to get a high priority alternative for
"editor". I use my locally built /usr/local/bin/emacs as the editor.

/etc/alternatives/editor -> /usr/local/bin/emacs

Building custom deb packages, so that they play nicely together with
official packages, is more difficult for users. "update-alternatives" is
just one command.

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462


signature.asc
Description: PGP signature

Re: Deprecation of /etc/alternatives?

[Teemu Likonen]

* 2023-12-25 13:26:40+0100, ans...@43-1.org wrote:

> On Mon, 2023-12-25 at 09:29 +0200, Teemu Likonen wrote:
>> I hope not. For example, as a user it is nice to execute a single
>> command (update-alternatives) to get a high priority alternative for
>> "editor". I use my locally built /usr/local/bin/emacs as the editor.

> Users should just set the VISUAL environment variable.

I mean as a user (not developer) of Debian.

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462


signature.asc
Description: PGP signature

Re: The "which -s" flag

[Teemu Likonen]

* 2020-08-14 00:55:03+02, Erik Gustafsson wrote:

> To make my Debian installation compatible with "which -s" I have made a
> merge request for this
> https://salsa.debian.org/debian/debianutils/-/merge_requests/6/diffs

Reviewed-by: me, a random debian user.

But perhaps you should mention the "-s" flag in the usage:

?) puts "Usage: $0 [-a] args"; exit 2 ;;

Like "[-as]" maybe.

-- 
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450


signature.asc
Description: PGP signature

Re: Convenient access to Debian keyrings

[Teemu Likonen]

Sean Whitton [2017-04-01 15:40:17-07] wrote:

> Currently, I have mutt pass `--keyring /usr/share/keyrings/...` for each
> of the keyrings, so that I can verify signatures on e-mails.  It would
> be more natural to just add `keyring /usr/share/keyrings/...` to
> ~/.gnupg/gpg.conf, but when I tried this I often got errors from gpg
> trying to write to the keyrings in /usr/share/keyrings.  Is there some
> way to mark a keyring as read-only?

Perhaps --primary-keyring will help because it marks one keyring for use
with key-importing commands. I haven't tried it but it would seem that
all other keyrings are then read-only.

~/.gnupg/gpg.conf:

primary-keyring ~/.gnupg/pubring.kbx
keyring /usr/share/...
keyring /usr/share/...
keyring /usr/share/...


-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///


signature.asc
Description: PGP signature

Laptop reboot and suspend

[Teemu Likonen]

Florian Lohoff [2017-04-05 07:55:29+02] wrote:

> I have a very different perception - It is so rare that i reboot my
> notebook which travels with me all day that everytime i do i have
> troubles remembering the 30+ character Luks passphrase. I
> suspend/resume multiple times a day and thats my current uptime:
>
>  07:49:26 up 22 days, 20:04,  4 users,  load average: 0.00, 0.05, 0.17

That also means that you have had your encrypted LUKS partitions open
for almost 23 days. My laptop's (Apple Macbook Air) suspend-resume works
well with Debian 8 but I shut it down when traveling through risky
places because I want to have my data encrypted (can't use gpg
separately for all valuable data).

I suggest posting follow-ups to debian-user list (Cc'd) and dropping
-devel.

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///


signature.asc
Description: PGP signature

Re: Thinking about a "jessie and a half" release

[Teemu Likonen]

Steve McIntyre [2016-07-04 14:01:03+01] wrote:

> it might be useful to do a "jessie and a half" release, [...] That's
> *basically* just like a normal jessie release, but with a few key
> updates:
>
>  * backports kernel
>  * rebuilt d-i to match that kernel
>  * X drivers
>  * ... (other things that might be needed for consistency)

A short version: I have a "Skylake" chip and motherboard. Debian 8.5
installation worked with the normal 3.16 kernel except that bug #785149
caused trouble with Grub. CPU's built-in graphics work badly with X
window system, even with kernel 4.5.

A long version: I managed to install Debian 8.5 (netinstall) to my new
Skylake machine (MSI Z170A Gaming Pro motherboard + Intel Core i7-6700K
processor). The installation worked fine with kernel 3.16 (network and
DVI-connected monitor). Before doing anything serious I upgraded the
kernel 4.5 from backports (now 4.6).

Problem 1: Debian 8.5 installer couldn't install Grub to /dev/nvme0n1xx
device (NVME M.2 SSD) and the error message didn't say anything useful.
I went through without Grub (I was using expert install mode). I booted
again the installer, chose rescue/recovery mode, chrooted to the new
install and installed grub manually. Then it worked. The issue is
reported as #785149 and there has been some work on it.

Problem 2: CPU's built-in graphics work badly. I tried with kernel 4.5
and with kernel option i915.preliminary_hw_support=1 (as someone
suggested). Couldn't start X window system. Fortunately I have better
graphics card so I don't care that much about the built-in one. Skylake
graphics probably need some yet unreleased kernel version.

> all rolled up with a small installer image build (netinst, maybe
> DVD#1).

I wish it were a standard practice to create new netinst images with
backported kernels. (Even though my actual problems were with
installer's Grub stage.)

-- 
/// Teemu Likonen   - .-..   <https://github.com/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///


signature.asc
Description: PGP signature