Re: Migrating (finally?) from Tcl/Tk 8.4 to something newer.

[Paul Wise]

On Fri, Dec 30, 2011 at 7:43 PM, Andrew Shadura  wrote:

> Currently in unstable there are around 30 packages which depend on
> Tcl/Tk 8.4, which is quite old itself despite the fact that updates are
> still released for it. Tcl/Tk 8.5 is available for more than 4 years,
> Tcl/Tk 8.6 is coming soon, so I think it may be the time to deprecate
> Tcl/Tk 8.4 finally.

This is being tracked here:

http://wiki.debian.org/Teams/DebianTclTk/UpgradeDefaultTclTkTo85

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/caktje6f91zvt6sx9-5mbdh+qze40vipc8fdamkkv815wfhx...@mail.gmail.com

Re: new in dd

[Paul Wise]

On Fri, Dec 30, 2011 at 7:45 PM, vangelis wrote:

> I want to join a group in wnpp list to test my self helping developing so i 
> can start slowly.
> How can i do that?

I'm not sure how to answer your question, but maybe one of these links helps:

http://www.debian.org/devel/wnpp/
http://wnpp.debian.net/
http://lists.debian.org/debian-wnpp/
http://wiki.debian.org/WNPP
http://manpages.debian.net/cgi-bin/man.cgi?query=wnpp-alert

PS: please don't use HTML mail on Debian lists:

http://www.debian.org/MailingLists/#codeofconduct

--
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/caktje6gey8gaal0+q-rquwgk6mgx-jm7egsqyog4mlz6dz7...@mail.gmail.com

Bug#653813: ITP: edgar -- The Legend of Edgar platform game

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
Owner: Joseph Nahmias 

* Package name: edgar
  Version : 0.94
  Upstream Author : Richard Sweeney 
* URL : http://www.parallelrealities.co.uk/p/legend-of-edgar.html
* License : GPL2+
  Programming Lang: C
  Description : The Legend of Edgar platform game

 The Legend of Edgar is a platform game where the hero must explore a vast
 world, find items, solve puzzles, defeat powerful enemies, complete
 mini-quests in order to save his father who has been kidnapped.
 .
 Includes support for joystick or joypad and configurable keyboard
 support.



-- 
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/20111231040937.15630.18762.report...@wakko.nahmias.net

Re: from / to /usr/: a summary

[Russ Allbery]

Fernando Lemos  writes:
> Enrico Weigelt  wrote:

>> ACK. Sometimes upstreams doing really stange things (maybe because they
>> dont have any package management in mind), that should be fixed.  If
>> upstream doesnt do those fixes, distros have to catch in.

Sometimes, I think Red Hat makes some of these design decisions because
RPM's handling of configuration files sucks.  If it had always behaved
like dpkg, I wonder if they wouldn't use designs that honor configuration
files somewhat more.

> Are you guys applying for maintainership for this huge delta you want to
> introduce between upstream and us? Are you becoming new, reputable
> upstreams for that forked software? If not, please refrain from telling
> people what to do.

This, however, is a really good point, and is the thing that keeps running
through the back of my head reading this thread.  There seems to be a lot
of sentiment that people wish udev (in particular) would work differently
and better integrate with a split / and /usr with only / being mounted
during boot.

But it's worth keeping in mind 2.1.1 of the constitution: you can't make
people in the project do work they don't want to do.  Clearly, Marco is
not interested in maintaining this sort of substantial fork of upstream
udev.  In fact, one of his primary points in this discussion is that this
is a ton of work for (at least in his opinion, and I think he has a
credible prima facie case, if not a universally persuasive one) somewhat
marginal benefit and it's not work he's interested in doing.  People can't
just tell him "no, you have to go do that work"; if it's so important to
Debian to go a different direction than udev's upstream, that means Debian
will need to fork it, which probably means *someone in this thread* is
going to have to fork it.  So who's volunteering to be the new udev
upstream?  (And, really, don't we have enough work to do that isn't
getting done because we don't have enough people?)

Note that Steve's point, namely that he (if I'm reading him right) thinks
that the upstream changes are being overstated and that upstream's
direction isn't actually going to cause problems for us, is an entirely
separate one and not something I'm addressing in the above.  And is
certainly something to explore before we start arguing over who's going to
fork something that may not be an issue at all.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87fwg1e5x5@windlord.stanford.edu

Re: from / to /usr/: a summary

[Josh Triplett]

Enrico Weigelt wrote:
> * Adam Borowski  schrieb:
> > On Fri, Dec 30, 2011 at 02:47:38PM +0100, Marco d'Itri wrote:
> > > On Dec 30, Carlos Alberto Lopez Perez  wrote:
> > > 
> > > > I think that stephan is right here. Every package using files in /etc
> > > It DOES NOT MATTER who is right, some upstreams have decided otherwise.
> > > At least udev, systemd and next month module-init-tools do override the 
> > > configuration files in /usr/lib/ with the configuration files in /etc/.
> > > Deal with it.
> > 
> > Then udev and systemd are broken.
> > 
> > You're introducing a dangerous inconsistency that's going to bite people.
> 
> ACK. Sometimes upstreams doing really stange things (maybe because
> they dont have any package management in mind), that should be fixed.
> If upstream doesnt do those fixes, distros have to catch in.

The numerous upstreams which follow this model introduced it
specifically *because* of distributions and package management, which
they specifically had in mind as a design constraint.  The "search path"
behavior, along with the consistent use of .d directories, allows a
clean distinction between upstream configuration, vendor/distribution
configuration (any changes Debian wants to make to the defaults),
sysadmin overrides of the defaults, and sysadmin configuration building
on the defaults, without forcing sysadmins to perform manual three-way
merges every time they upgrade.

The upstream defaults live outside of /etc specifically because *they
don't normally represent configuration intended for the sysadmin to
change*.

Before udev moved the default rules to /lib/udev, udev received a large
number of bug reports caused by an incorrect set of udev rules in /etc.
Sysadmins would make a local hack and then not accept new upstream rule
changes, or packages would delete outdated rules but the conffiles would
stick around and break things, or various other fun and exciting
brokenness.  Almost all of those bug reports went away once udev moved
the default location of distro-installed rules to /lib/udev/rules.d
rather than /etc/udev/rules.d.

- Josh Triplett


-- 
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/20111231035432.GA15712@leaf

Re: Conffiles

[Russ Allbery]

Josh Triplett  writes:
> Enrico Weigelt wrote:

>> I have a general objection against putting (default) configs outside
>> /etc at all. The main problem is, on updates, defaults might silently
>> change, without operators used to look at /etc and comparing current
>> config with new defaults.

> By default, dpkg will silently upgrade unmodified conffiles to the
> current version, without prompting the user at all.  If you've modified
> the conffile, dpkg will prompt you to find out if you want to keep your
> modified version, upgrade to the new upstream version, see a diff, or
> run a shell; dpkg will default to keeping your modified version.

> So, unless you've changed a configuration file, you already won't get a
> prompt on configuration upgrades.

But right now with configuration in /etc if you have changed *any*
configuration setting, you then get prompted for *all* configuration
changes in the package, which I think is Enrico's point.  And I agree, I
kind of like that behavior.  Configuration settings can interact in
unexpected ways, so if I've had to customize the configuration, I kind of
like knowing when other defaults change.  They may affect the thing I had
to customize.

> If the configuration upgrade might matter to sysadmins, the Debian
> package should provide an upgrade note in NEWS.Debian, or upstream
> should provide a note in NEWS (which I wish apt-listchanges could show,
> at least when it follows a standard format).

Upstream's NEWS generally has *way* too much noise to expect people to
look at it by default.  NEWS.Debian isn't a horrible solution, but it
doesn't provide a way of saying "no, don't apply this change but still
continue with the package installation," which I think you need for
configuration files.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87k45de69a@windlord.stanford.edu

Re: from / to /usr/: a summary

[Fernando Lemos]

On Sat, Dec 31, 2011 at 12:59 AM, Enrico Weigelt  wrote:
> * Adam Borowski  schrieb:
>> On Fri, Dec 30, 2011 at 02:47:38PM +0100, Marco d'Itri wrote:
>> > On Dec 30, Carlos Alberto Lopez Perez  wrote:
>> >
>> > > I think that stephan is right here. Every package using files in /etc
>> > It DOES NOT MATTER who is right, some upstreams have decided otherwise.
>> > At least udev, systemd and next month module-init-tools do override the
>> > configuration files in /usr/lib/ with the configuration files in /etc/.
>> > Deal with it.
>>
>> Then udev and systemd are broken.
>>
>> You're introducing a dangerous inconsistency that's going to bite people.
>>
>
> ACK. Sometimes upstreams doing really stange things (maybe because
> they dont have any package management in mind), that should be fixed.
> If upstream doesnt do those fixes, distros have to catch in.
>
> Look, the purpose of distros is to provide an consistent, robust
> and mainainable environment. Sometimes the distro maintainers
> have to bite in the bitter apple and cleanup upstreams's dirt.

Are you guys applying for maintainership for this huge delta you want
to introduce between upstream and us? Are you becoming new, reputable
upstreams for that forked software? If not, please refrain from
telling people what to do.

Regards,


-- 
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/CANVYNa92t4N5zrWm=UX=PO1f19X=ykqvyb9szdo1cq7bhrk...@mail.gmail.com

Re: Conffiles (was: from / to /usr/: a summary)

[Josh Triplett]

Enrico Weigelt wrote:
> * Tanguy Ortolo  schrieb:
> > I think having the default configuration values written in a default
> > configuration file under /usr is better than having them harcoded, since
> > it makes it really easier to determine what these defaults are. But not
> > shipping the user configuration file, I do not know, that seems ugly
> > somehow. At least the possibility to write a configuration file should
> > be documented, ideally with a manpage.
> 
> I have a general objection against putting (default) configs
> outside /etc at all. The main problem is, on updates, defaults
> might silently change, without operators used to look at /etc
> and comparing current config with new defaults.

By default, dpkg will silently upgrade unmodified conffiles to the
current version, without prompting the user at all.  If you've modified
the conffile, dpkg will prompt you to find out if you want to keep your
modified version, upgrade to the new upstream version, see a diff, or
run a shell; dpkg will default to keeping your modified version.

So, unless you've changed a configuration file, you already won't get a
prompt on configuration upgrades.  If the configuration upgrade might
matter to sysadmins, the Debian package should provide an upgrade note
in NEWS.Debian, or upstream should provide a note in NEWS (which I wish
apt-listchanges could show, at least when it follows a standard format).

- Josh Triplett


-- 
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/20111231033650.GA15689@leaf

Re: from / to /usr/: a summary

[Enrico Weigelt]

* Adam Borowski  schrieb:
> On Fri, Dec 30, 2011 at 02:47:38PM +0100, Marco d'Itri wrote:
> > On Dec 30, Carlos Alberto Lopez Perez  wrote:
> > 
> > > I think that stephan is right here. Every package using files in /etc
> > It DOES NOT MATTER who is right, some upstreams have decided otherwise.
> > At least udev, systemd and next month module-init-tools do override the 
> > configuration files in /usr/lib/ with the configuration files in /etc/.
> > Deal with it.
> 
> Then udev and systemd are broken.
> 
> You're introducing a dangerous inconsistency that's going to bite people.
> 

ACK. Sometimes upstreams doing really stange things (maybe because
they dont have any package management in mind), that should be fixed.
If upstream doesnt do those fixes, distros have to catch in.

Look, the purpose of distros is to provide an consistent, robust
and mainainable environment. Sometimes the distro maintainers
have to bite in the bitter apple and cleanup upstreams's dirt.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--


-- 
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/20111231025922.gd30...@mailgate.onlinehome-server.info

Re: from / to /usr/: a summary

[Enrico Weigelt]

* Tanguy Ortolo  schrieb:
> Enrico Weigelt, 2011-12-30 06:21+0100:
> > Which packages ship files in /var ?
> 
> Many install directories there. And one of my packages, dokuwiki, also
> installs files under /var/lib/dokuwiki/lib/{plugins,tpl}. These files
> define the default set of bundled plugins and templates, and I install
> them there so that the user can add other plugins or templates, which is
> a very common case for DokuWiki administrators since one of the major
> advantages of this wiki engine is its rich set of available plugins.

IMHO this is completely wrong, those files should be under
/usr/lib/... or maybe even /usr/share/... as they're not
dynamic data.

I'd split off package install and instance deployment
(as soon as you want several dokuwiki instances on one
host, that will be needed anyways).


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--


-- 
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/20111231025510.gc30...@mailgate.onlinehome-server.info

Re: from / to /usr/: a summary

[Enrico Weigelt]

* Carlos Alberto Lopez Perez  schrieb:

> I think that stephan is right here. Every package using files in /etc
> should ship this files in the package in order to let the admin know
> what package each file belongs to. Its very ugly to do a "dpkg -S
> /etc/xxx" and get a no path found.
> 
> If some package is not doing this I think is a mistake and should be fixed.

ACK. And it's then the job of the package manager to handle
the config files properly (eg. not simply overwriting them
on on updates, instead put them to some proper location
where the admin or an admin-tool can pick them up)


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--


-- 
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/20111231024734.gb30...@mailgate.onlinehome-server.info

Re: Conffiles (was: from / to /usr/: a summary)

[Enrico Weigelt]

* Tanguy Ortolo  schrieb:

> I think having the default configuration values written in a default
> configuration file under /usr is better than having them harcoded, since
> it makes it really easier to determine what these defaults are. But not
> shipping the user configuration file, I do not know, that seems ugly
> somehow. At least the possibility to write a configuration file should
> be documented, ideally with a manpage.

I have a general objection against putting (default) configs
outside /etc at all. The main problem is, on updates, defaults
might silently change, without operators used to look at /etc
and comparing current config with new defaults.

Not sure how Debian handles this, but Gentoo's etc-update
mechanism has shown to be very handy.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--


-- 
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/20111231024024.ga30...@mailgate.onlinehome-server.info

Re: Evaristo

[Dean Evans]

On Sat, 31 Dec 2011 00:51:18 +
810d4rk <810d...@gmail.com> wrote:

> Hi to all, is anyone interested in evaristo?
> 

If you're interested in packaging evaristo for Debian you should have a
look at http://wiki.debian.org/HowToPackageForDebian and file an ITP
(Intent To Package) [0].

If you do not wish to package evaristo, but think someone else may be
interesting in packaging it, you should file a RFP (Request For
Package) [0].

[0] http://www.debian.org/devel/wnpp/

Thanks,
Dean


-- 
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/20111231151917.7d79673a@sidspace

Re: Evaristo

[810d4rk]

The free GPL licensed version could be included in the repos, what do you think?
http://sourceforge.net/projects/evaristo/


On 31/12/2011, 810d4rk <810d...@gmail.com> wrote:
> Hi to all, is anyone interested in evaristo?
>
> Evaristo is an ERP solution written in Java (2 tier), though only
> available in Portuguese, since version 4 is fully internationalizable.
> It requires a PostgreSQL database in order to store the data.
> DGCI certification is required for the use in commercial activities in
> PT, the commercial version is certified by DGCI.
>
> --
> Thanks
>


-- 
Thanks


-- 
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/CAAVfQjkydwNyqpGsarKeNgwsMutTuiR1qxVL42keTq7=p12...@mail.gmail.com

Evaristo

[810d4rk]

Hi to all, is anyone interested in evaristo?

Evaristo is an ERP solution written in Java (2 tier), though only
available in Portuguese, since version 4 is fully internationalizable.
It requires a PostgreSQL database in order to store the data.
DGCI certification is required for the use in commercial activities in
PT, the commercial version is certified by DGCI.

-- 
Thanks


-- 
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/CAAVfQj=_02=DfYjiDjxKyG91FmtjUQ4wcquv=db1x1-zy7m...@mail.gmail.com

Re: from / to /usr/: a summary

[Josh Triplett]

> Josh Triplett, 2011-12-30 16:09+0100:
> > A de-facto standard has already emerged for how to ship the standard
> > configuration in /usr/lib and handle overrides,
> 
> I do not think this is a de facto standard at all yet. What pieces of
> software use apply it? The length of that list should be compared to the
> order of magnitude of something like $(ls -1 /etc | wc -l) on a typical
> system before assuming that this has become the standard.

I didn't say that it had become as common as just having files in /etc;
I just suggested that programs which put their defaults outside of /etc
and allow overrides via /etc seem to follow a common approach which
makes them easy to find and override.

A quick check turned up the following software following the "/usr/lib
with /etc override" approach just on my own system:

- pm-utils
- PolicyKit
- ConsoleKit
- Parts of iceweasel
- Parts of Xorg
- systemd and its various helper components
- udev (modulo it currently using /lib rather than /usr/lib, but that
  kind of thing started this whole thread in the first place)

The following packages have the same semantics, but use /usr/share
rather than /usr/lib, presumably because they don't consider their
default configurations architecture-specific:

- initramfs-tools
- TeX/LaTeX
- angband
- menu
- insserv
- defoma
- terminfo
- XKB
- calendar

My search also turned up a pile of other packages which *almost* manage
to follow this standard (default configuration in
/usr/{lib,share}/$package/ with overrides in /etc/$package/), but use
slight variations on naming between the files/directories in /usr and
the files/directories in /etc.  Those kinds of inconsistencies really
ought to get fixed.

> The fact that a given piece of software is new or written by Lennart
> or whoever does not make its behaviour standard at all. The existence
> of a recommendation from IETF, LSB or XDG does, however.

I said "de-facto standard" for a reason; that means precisely the
opposite of standards produced by the organizations you mentioned.

- Josh Triplett


-- 
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/20111231000954.GA11680@leaf

Re: Linux Mint 12 in Debian?

[Josselin Mouette]

Le vendredi 30 décembre 2011 à 19:20 +0100, Svante Signell a écrit : 
> I'm very reluctant to upgrade to gnome3, I have it on one box, and
> don't like it. I want workspaces related to different tasks, like
> programming, web browsing, watching a video, listening to music, etc.
> That could involve e.g. having terminals, etc running on each
> workspace. Does this hinder several instances of a terminal, web
> browser, etc, to be launched?

You can launch several instances of whatever you like. It’s just the
behavior of dock icons to raise existing windows instead of opening a
new one, but of course you can do it.

> Look like there is a gnome-session-fallback similar to gnome 2
> available. Can it be installed safely, instead of gnome-session? 

Yes. This is the “GNOME classic” session, that uses metacity and
gnome-panel.

> Does it use the features of gnome-shell?

No.

> > (Also, I don’t get the “tablet” mention. One of the weaknesses of GNOME
> > Shell compared to e.g. Unity is precisely its behavior on tablets -
> > which is why this is something upstream is working on.)
> 
> Please clarify!

GNOME Shell is not the best interface for a touchscreen. It was designed
for keyboard & mouse.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


signature.asc
Description: This is a digitally signed message part

Re: Linux Mint 12 in Debian?

[Teus Benschop]

On 12/30/2011 07:20 PM, Svante Signell wrote:
> I'm very reluctant to upgrade to gnome3, I have it on one box, and
> don't like it. I want workspaces related to different tasks, like
> programming, web browsing, watching a video, listening to music, etc.
> That could involve e.g. having terminals, etc running on each
> workspace. Does this hinder several instances of a terminal, web
> browser, etc, to be launched?

I did a switch to Gnome 3, and did not know how to work with it, then
switched back to Gnome 2, tried Xfce, decided that these also have their
shortcomings, and then decided to go ahead with Gnome 3. I read the
Gnome Cheatsheet [1], practised the keyboard shortcuts, and am now a
happy Gnome 3 user, and have not looked back even once.

[1] http://live.gnome.org/GnomeShell/CheatSheet

If somebody wants to have more than one instance of, say, the Terminal,
this is easily accomplished by doing a Ctrl mouse click instead of a
normal click.

Using the keyboard, going to the Terminal again, what I usually do is this:
Press the Windows (system) key.
Type Te
Enter - to start the terminal.
Ctrl-Enter - to start a second instance of the terminal.
Using the keyboard is fast.

Teus.


-- 
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/4efe0436.5050...@gmail.com

Re: Linux Mint 12 in Debian?

[Svante Signell]

On Tue, 2011-11-29 at 00:09 +0100, Josselin Mouette wrote:
> Le lundi 28 novembre 2011  19:56 +0100, Svante Signell a crit : 
> > As many people (including me) are very disappointed in gnome3, switching
> > from a very configurable desktop environment in gnome2 to a almost not
> > configurable tablet one, is there any chance that Debian could supply
> > the Mint version too, with many goodies from gnome3 and a gnome2
> > look-and-feel?

I'm very reluctant to upgrade to gnome3, I have it on one box, and
don't like it. I want workspaces related to different tasks, like
programming, web browsing, watching a video, listening to music, etc.
That could involve e.g. having terminals, etc running on each
workspace. Does this hinder several instances of a terminal, web
browser, etc, to be launched?

> The Mint extensions for GNOME Shell look interesting, although I’m not
> into nostalgic retrofeatures. Feel free to package them, people on
> #debian-gnome can give you advice on this matter.

Look like there is a gnome-session-fallback similar to gnome 2
available. Can it be installed safely, instead of gnome-session? Does it
use the features of gnome-shell? Other alternatives, execept Linux Mint,
including most of gnome, xfce4? 

> (Also, I don’t get the “tablet” mention. One of the weaknesses of GNOME
> Shell compared to e.g. Unity is precisely its behavior on tablets -
> which is why this is something upstream is working on.)

Please clarify!



-- 
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/1325269251.30246.13.ca...@hp.my.own.domain

Re: iw: priority should be "optional"

[Ben Hutchings]

On Fri, 2011-12-30 at 06:56 -0800, Josh Triplett wrote:
> Ben Hutchings wrote:
> > On Sat, 2010-07-31 at 16:56 -0500, Jonathan Nieder wrote:
> > > Package: iw
> > > Version: 0.9.19-1
> > > Severity: important
> > > Justification: policy §2.5
> > > 
> > > aircrack-ng depends on iw, but the former is optional and the latter of
> > > priority "extra".  Please bump up the priority of iw to optional to
> > > match.
> > [...]
> > 
> > I see that this change is pending.
> > 
> > However, I would go further and suggest that iw should be standard, as
> > should crda and ethtool.
> 
> "standard" as in "installed by default on all new Debian systems,
> whether they have a wireless card or not"?  What benefit would that
> provide?

None for those without a wireless card.  You could make a similar
argument against telnet, whois or info (which is 'important'!) - I don't
believe most people use them.

> I do think we should migrate from wireless-tools to iw.  For iw, I'd
> suggest taking the same approach currently used by wireless-tools: have
> d-i install them if needed, and otherwise let dependencies (or users)
> pull them in when needed.  (This assumes that the existing users of
> wireless-tools understand how to use iw; if not, they need fixing.)
> 
> The description of the crda package doesn't really make it obvious why
> users might want it.  To enable wifi frequencies that some locales don't
> permit, such as channels 12-14?  That seems worthy of a Recommends at
> most, and quite possibly just a Suggests.

The description isn't great.

The permitted power levels and some other parameters also vary between
countries.

> As for ethtool, what rationale do you propose for having it installed on
> all systems, even granting the assumption that most useful systems have
> a network device of some kind?  What makes it necessary to have
> available without first running apt{-get,itude} install ethtool or
> installing a package which depends on it?  What package with priority
> standard wants to use it, or why do you expect that most admins will
> need to run it?

You may well need to run it because your network is broken (-i, -p, -t
options).

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein


signature.asc
Description: This is a digitally signed message part

Re: from / to /usr/: a summary

[Tanguy Ortolo]

Josh Triplett, 2011-12-30 16:09+0100:
> A de-facto standard has already emerged for how to ship the standard
> configuration in /usr/lib and handle overrides,

I do not think this is a de facto standard at all yet. What pieces of
software use apply it? The length of that list should be compared to the
order of magnitude of something like $(ls -1 /etc | wc -l) on a typical
system before assuming that this has become the standard. The fact that
a given piece of software is new or written by Lennart or whoever does not make 
its
behaviour standard at all. The existence of a recommendation from IETF,
LSB or XDG does, however.

-- 
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Maintainer
 \_


-- 
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/jdkmvg$uut$1...@dough.gmane.org

Re: iw: priority should be "optional"

[Stefan Lippers-Hollmann]

Hi

On Friday 30 December 2011, Josh Triplett wrote:
> Ben Hutchings wrote:
> > On Sat, 2010-07-31 at 16:56 -0500, Jonathan Nieder wrote:
> > > Package: iw
> > > Version: 0.9.19-1
> > > Severity: important
> > > Justification: policy §2.5
> > > 
> > > aircrack-ng depends on iw, but the former is optional and the latter of
> > > priority "extra".  Please bump up the priority of iw to optional to
> > > match.
[...]
> The description of the crda package doesn't really make it obvious why
> users might want it.  To enable wifi frequencies that some locales don't
> permit, such as channels 12-14?  That seems worthy of a Recommends at
> most, and quite possibly just a Suggests.

Channel 12-14 in the 2.4 GHz and most (basically all) of 5 GHz, due to 
only small overlaps between FCC (US), ETSI (EU) and JP (Japan) and 
DFS[1] requirements; DFS support in mainline is still a work in 
(active) progress. An overview for the regulatory subsystem of the 
linux kernel (there is active cooperation with FreeBSD particularly in 
regards to DFS) is available under [2].

crda/ iw and wireless-regdb are basically required to apply the 
regulatory settings for modern wlan cards, both acting about regulatory
hints stored in the card's EEPROM/ OTP or, as intersection, received
through IEEE 802.11d from the access point and/ or based upon the local
configuration[3].

Regards
Stefan Lippers-Hollmann

[1] http://wireless.kernel.org/en/developers/DFS
[2] http://wireless.kernel.org/en/developers/Regulatory/
[3] /etc/default/crda

http://anonscm.debian.org/gitweb/?p=kernel/crda.git;a=blob;f=debian/crda.default


signature.asc
Description: This is a digitally signed message part.

Re: from / to /usr/: a summary

[Josh Triplett]

Stephan Seitz wrote:
> Every package which will accept a configuration file in /etc should ship
> such a file in /etc, even if it contains only comments. In this way, you
> know the name(s) of the configuration file(s) and the subdirectory in
> /etc where they belong.

A de-facto standard has already emerged for how to ship the standard
configuration in /usr/lib and handle overrides, which makes it quite
straightforward to find configuration files in a package, add new
configuration files, or override the standard configuration files:
packages read /etc/$dir before /usr/lib/$dir, and /etc/$dir/$foo.conf
overrides /usr/lib/$dir/$foo.conf.  If you want to override
/usr/lib/$dir/$foo.conf, copy it to /etc/$dir/$foo.conf and start
editing.

- Josh Triplett


-- 
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/20111230150916.GA8957@leaf

Re: iw: priority should be "optional"

[Josh Triplett]

Ben Hutchings wrote:
> On Sat, 2010-07-31 at 16:56 -0500, Jonathan Nieder wrote:
> > Package: iw
> > Version: 0.9.19-1
> > Severity: important
> > Justification: policy §2.5
> > 
> > aircrack-ng depends on iw, but the former is optional and the latter of
> > priority "extra".  Please bump up the priority of iw to optional to
> > match.
> [...]
> 
> I see that this change is pending.
> 
> However, I would go further and suggest that iw should be standard, as
> should crda and ethtool.

"standard" as in "installed by default on all new Debian systems,
whether they have a wireless card or not"?  What benefit would that
provide?

I do think we should migrate from wireless-tools to iw.  For iw, I'd
suggest taking the same approach currently used by wireless-tools: have
d-i install them if needed, and otherwise let dependencies (or users)
pull them in when needed.  (This assumes that the existing users of
wireless-tools understand how to use iw; if not, they need fixing.)

The description of the crda package doesn't really make it obvious why
users might want it.  To enable wifi frequencies that some locales don't
permit, such as channels 12-14?  That seems worthy of a Recommends at
most, and quite possibly just a Suggests.

As for ethtool, what rationale do you propose for having it installed on
all systems, even granting the assumption that most useful systems have
a network device of some kind?  What makes it necessary to have
available without first running apt{-get,itude} install ethtool or
installing a package which depends on it?  What package with priority
standard wants to use it, or why do you expect that most admins will
need to run it?

- Josh Triplett


--
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/20111230145603.GA8777@leaf

Re: [pkg-wpa-devel] Bug#591102: iw: priority should be "optional"

[Ben Hutchings]

On Fri, 2011-12-30 at 15:16 +0100, Stefan Lippers-Hollmann wrote:
> Hi
> 
> On Friday 30 December 2011, Ben Hutchings wrote:
> > On Sat, 2010-07-31 at 16:56 -0500, Jonathan Nieder wrote:
> > > Package: iw
> > > Version: 0.9.19-1
> > > Severity: important
> > > Justification: policy §2.5
> > > 
> > > aircrack-ng depends on iw, but the former is optional and the latter of
> > > priority "extra".  Please bump up the priority of iw to optional to
> > > match.
> > [...]
> > 
> > I see that this change is pending.
> > 
> > However, I would go further and suggest that iw should be standard, as
> > should crda and ethtool.
> 
> While I basically agree with your reasoning, I'm a bit reluctant to 
> actually promote it to "standard" ("These packages provide a reasonably
> small but not too limited character-mode system. This is what will be 
> installed by default if the user doesn't select anything else.[...]"), 
> given that iw/ crda are not needed on systems without wlan cards 
> (basically all server class systems and a fair chunk of desktops);
[...]

Yes, true.  But if 'standard' is defined too narrowly then there isn't
much of a distinction between 'important' and 'standard'.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein


signature.asc
Description: This is a digitally signed message part

Re: [pkg-wpa-devel] Bug#591102: iw: priority should be "optional"

[Stefan Lippers-Hollmann]

Hi

On Friday 30 December 2011, Ben Hutchings wrote:
> On Sat, 2010-07-31 at 16:56 -0500, Jonathan Nieder wrote:
> > Package: iw
> > Version: 0.9.19-1
> > Severity: important
> > Justification: policy §2.5
> > 
> > aircrack-ng depends on iw, but the former is optional and the latter of
> > priority "extra".  Please bump up the priority of iw to optional to
> > match.
> [...]
> 
> I see that this change is pending.
> 
> However, I would go further and suggest that iw should be standard, as
> should crda and ethtool.

While I basically agree with your reasoning, I'm a bit reluctant to 
actually promote it to "standard" ("These packages provide a reasonably
small but not too limited character-mode system. This is what will be 
installed by default if the user doesn't select anything else.[...]"), 
given that iw/ crda are not needed on systems without wlan cards 
(basically all server class systems and a fair chunk of desktops); even
legacy wlan drivers[1] not based on nl80211 can't make use of either. 
Comparing the situation with wireless-tools (deprecated for modern 
mac80211 based drivers) and wpasupplicant, shows that both packages are
currently regarded "optional" as well, although I do recognize that the
regdom setting is a bit lower level than actually using the wlan.

Regards
Stefan Lippers-Hollmann

[1] The only "common" legacy driver appears to be Intel ipw2100/ 
ipw2200 and perhaps airo/ airo_cs (Cisco/Aironet 34X/35X/4500/4800), 
but affected are also:
- ray_cs (Aviator/Raytheon)
- atmel_{cs,pci} (Atmel at76c50x chipset)
- wl3501_cs (Planet WL3501)
- zd1201 (ZyDAS ZD1201)
- hostap_{cs,plx,pci} (Intersil Prism2/2.5/3)
as well as all staging wlan drivers, given that not being mac80211 
based is the prime reason for them being in staging:
- rtl8187se (RealTek RTL8187SE)
- rtl8192e (RealTek RTL8192E)
- rtl8192u (RealTek RTL8192U)
- rtl8712 (RealTek RTL8712U (RTL8192SU))
- vt6655 (VIA Technologies VT6655)
- vt6656 (VIA Technologies VT6656)


signature.asc
Description: This is a digitally signed message part.

Re: Conffiles (was: from / to /usr/: a summary)

[Adam Borowski]

On Fri, Dec 30, 2011 at 02:00:23PM +, Tanguy Ortolo wrote:
> I think having the default configuration values written in a default
> configuration file under /usr is better than having them harcoded, since
> it makes it really easier to determine what these defaults are.

It's problematic if the defaults rely on the configuration file being
present.  From my experiences, I'd say it's best to ship the file with
everything commented out.

-- 
1KB // Yo momma uses IPv4!


signature.asc
Description: Digital signature

Conffiles (was: from / to /usr/: a summary)

[Tanguy Ortolo]

Carlos Alberto Lopez Perez, 2011-12-30 14:22+0100:
> I think that stephan is right here. Every package using files in /etc
> should ship this files in the package in order to let the admin know
> what package each file belongs to. Its very ugly to do a "dpkg -S
> /etc/xxx" and get a no path found.

Not too problematic as long as that file has a name that make
identification easy.

I think having the default configuration values written in a default
configuration file under /usr is better than having them harcoded, since
it makes it really easier to determine what these defaults are. But not
shipping the user configuration file, I do not know, that seems ugly
somehow. At least the possibility to write a configuration file should
be documented, ideally with a manpage.

-- 
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Maintainer
 \_


-- 
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/jdkg5m$ija$1...@dough.gmane.org

Re: from / to /usr/: a summary

[Adam Borowski]

On Fri, Dec 30, 2011 at 02:47:38PM +0100, Marco d'Itri wrote:
> On Dec 30, Carlos Alberto Lopez Perez  wrote:
> 
> > I think that stephan is right here. Every package using files in /etc
> It DOES NOT MATTER who is right, some upstreams have decided otherwise.
> At least udev, systemd and next month module-init-tools do override the 
> configuration files in /usr/lib/ with the configuration files in /etc/.
> Deal with it.

Then udev and systemd are broken.

You're introducing a dangerous inconsistency that's going to bite people.


> > If some package is not doing this I think is a mistake and should be fixed.
> "Fixing" this creates a serious incompatibility with other 
> distributions, so it is not an option.

Fixing this preserves important consistency within the distribution.

-- 
1KB // Yo momma uses IPv4!


signature.asc
Description: Digital signature

Re: from / to /usr/: a summary

[Marco d'Itri]

On Dec 30, Carlos Alberto Lopez Perez  wrote:

> I think that stephan is right here. Every package using files in /etc
It DOES NOT MATTER who is right, some upstreams have decided otherwise.
At least udev, systemd and next month module-init-tools do override the 
configuration files in /usr/lib/ with the configuration files in /etc/.
Deal with it.

> If some package is not doing this I think is a mistake and should be fixed.
"Fixing" this creates a serious incompatibility with other 
distributions, so it is not an option.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: exFAT fuse driver and the patent situation

[Paul Wise]

You may want to take a look at the Community Distribution Patent
Policy FAQ, prepared for Debian by the SFLC:

http://www.debian.org/reports/patent-faq

IIRC the DPL is working on more patent related stuff too.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/CAKTje6G8-6e++n=sqkxxuv7ep0kwkjvjr4t-bzhugbhvvqi...@mail.gmail.com

Re: iw: priority should be "optional"

[Ben Hutchings]

On Sat, 2010-07-31 at 16:56 -0500, Jonathan Nieder wrote:
> Package: iw
> Version: 0.9.19-1
> Severity: important
> Justification: policy §2.5
> 
> aircrack-ng depends on iw, but the former is optional and the latter of
> priority "extra".  Please bump up the priority of iw to optional to
> match.
[...]

I see that this change is pending.

However, I would go further and suggest that iw should be standard, as
should crda and ethtool.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein


signature.asc
Description: This is a digitally signed message part

Re: from / to /usr/: a summary

[Carlos Alberto Lopez Perez]

On 30/12/11 12:48, Marco d'Itri wrote:
> On Dec 30, Stephan Seitz  wrote:
> 
>> > Every package which will accept a configuration file in /etc should
>> > ship such a file in /etc, even if it contains only comments. In this
> This train has already passed and you lost it, sorry.
> 

I think that stephan is right here. Every package using files in /etc
should ship this files in the package in order to let the admin know
what package each file belongs to. Its very ugly to do a "dpkg -S
/etc/xxx" and get a no path found.

If some package is not doing this I think is a mistake and should be fixed.




-- 
~~~
Carlos Alberto Lopez Perez   http://neutrino.es
Igalia - Free Software Engineeringhttp://www.igalia.com
~~~



signature.asc
Description: OpenPGP digital signature

Re: exFAT fuse driver and the patent situation

[Marco d'Itri]

On Dec 30, Sven Hoexter  wrote:

> due to demand by a coworker I've taken #625611 and started to prepare
> a package for the exFAT fuse driver and the utils package.
Debian, as policy, ignores patents which are not being actively and 
widely enforced.
So feel free to upload.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

new in dd

[vangelis]

  
  
hi folks,
I want to join a group in wnpp list to test my self helping
developing so i can start slowly.
How can i do that?

best regards
gnugr
-- 
  
  

Re: from / to /usr/: a summary

[Marco d'Itri]

On Dec 30, Stephan Seitz  wrote:

> Every package which will accept a configuration file in /etc should
> ship such a file in /etc, even if it contains only comments. In this
This train has already passed and you lost it, sorry.

> And where do you want to put the package information which are
> currently in /var? They do not belong to /usr.
They stay in /var, it does not matter for the interesting use cases.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Migrating (finally?) from Tcl/Tk 8.4 to something newer.

[Andrew Shadura]

Hello,

On Fri, 30 Dec 2011 14:43:29 +0300
Andrew Shadura  wrote:

> So I'd like the maintainers of the packages which still depend on
> Tcl/Tk 8.4 to update their packages to build against/use newer Tcl/Tk
> versions.

Also, I'd like to ask, that if possible, try to fix change the packages
so they don't need source changes to rebuild them against a specific
version of Tcl or Tk.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: from / to /usr/: a summary

[Stephan Seitz]

On Thu, Dec 29, 2011 at 05:36:40PM -0800, Josh Triplett wrote:

top-level directories would look after a move from / to /usr.  Also, the
FHS says nothing about the current approach of overriding files in /usr
with files in /etc, which allows packages to stop shipping configuration
files in /etc that just consist of the default settings.


Every package which will accept a configuration file in /etc should ship 
such a file in /etc, even if it contains only comments. In this way, you 
know the name(s) of the configuration file(s) and the subdirectory in 
/etc where they belong.



such as /bin, /sbin, /lib, /lib32, /lib64, and so on.  However,
consolidating all the package-managed bits in /usr would make it
entirely sensible to share /usr as a single consistent pile of packaged
bits.


And where do you want to put the package information which are currently 
in /var? They do not belong to /usr.


Shade and sweet water!

Stephan

--
| Stephan Seitz E-Mail: s...@fsing.rootsland.net |
| PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html |


signature.asc
Description: Digital signature

Migrating (finally?) from Tcl/Tk 8.4 to something newer.

[Andrew Shadura]

Hello,

Currently in unstable there are around 30 packages which depend on
Tcl/Tk 8.4, which is quite old itself despite the fact that updates are
still released for it. Tcl/Tk 8.5 is available for more than 4 years,
Tcl/Tk 8.6 is coming soon, so I think it may be the time to deprecate
Tcl/Tk 8.4 finally.

I've filed bugs against some packages already, one of them already got
fixed, and also I've prepared two QA uploads to orphaned packages (one
of which is already uploaded, thanks, Paul!)

So I'd like the maintainers of the packages which still depend on
Tcl/Tk 8.4 to update their packages to build against/use newer Tcl/Tk
versions.

I'm going to post here a list with details on packages needing some work
a bit later.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: from / to /usr/: a summary

[Tanguy Ortolo]

Enrico Weigelt, 2011-12-30 06:21+0100:
> Which packages ship files in /var ?

Many install directories there. And one of my packages, dokuwiki, also
installs files under /var/lib/dokuwiki/lib/{plugins,tpl}. These files
define the default set of bundled plugins and templates, and I install
them there so that the user can add other plugins or templates, which is
a very common case for DokuWiki administrators since one of the major
advantages of this wiki engine is its rich set of available plugins.

-- 
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Maintainer
 \_


-- 
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/jdk3gd$4pi$1...@dough.gmane.org

exFAT fuse driver and the patent situation

[Sven Hoexter]

Hi,

(if unsure please CC me on replies, I'm not subscribed to -legal)

due to demand by a coworker I've taken #625611 and started to prepare
a package for the exFAT fuse driver and the utils package.

Currently I hesitate to upload it and place the package on Debian
infrastructure (as in moving it to collab-maint) due to the very
unclear patent situation.
Microsoft seems to actively sell lincenses to commercial enties
using exFAT in their products, so from my point of view it currently
looks a bit problematic to ship exFAT in Debian.
On the other hand we ship a FAT driver in the Kernel and Microsoft
is actively collecting royalties from TomTom and others aswell.


If someone has some more insides of this matter it would be nice
to hear about them before I pester our ftp-master with a final
decision.


Beside that we seem to have no consistent naming scheme for all
those fuse mount helpers which we might want to takle one day.

Cheers,
Sven




signature.asc
Description: Digital signature