Re: motd handling in jessie

[Riley Baird]

On 24/01/15 15:18, Russ Allbery wrote:
> Josh Triplett  writes:
> 
>> Please, no.  Under normal circumstances, the only dynamic bit of the
>> motd comes from uname, and only changes on reboot; updating it via cron
>> just wastes cycles and adds noise to syslog.
> 
>> I'm not particularly convinced that even the existing uname line has
>> much value.  So what about this: why don't we move all of that machinery
>> to an update-motd package or similar (priority optional), which can hook
>> into PAM as desired to display its message, and have the default motd of
>> the base system be completely static, with nothing run at boot *or*
>> login?
> 
> I do feel like we're losing some value by not showing users the uname
> information by default, and I'd like to still see us update that at boot.
> I certainly agree that running shell code from PAM by default is not a
> good idea.
> 
> That said, by far the best way to handle MOTD is to write out a static
> file using whatever configuration management system you're using, based on
> all the information that it gathers about the system (via something like
> ohai or facter).  That lets you flesh out the MOTD with lots of details
> that are actually interesting.  But that's not something Debian needs to
> be doing; each site can handle that.

Sort of off topic, but as far as I can tell, the historical purpose of
MOTD was to send a message to all users of a system. Is it still used
for this? Are there other uses of it?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54c34bb4.4010...@bitmessage.ch

Bug#776127: ITP: slimjet -- Fast, smart and powerful browser based on Blink

[Stephen Cheng]

Package: wnpp
Severity: wishlist
Owner: Stephen Cheng 

* Package name: slimjet
  Version : 2.1.6.0
  Upstream Author : FlashPeak Inc 
* URL : http://www.slimjet.com/
* License : Proprietary/Free to use and redistribute
  Programming Lang: C++
  Description : Fast, smart and powerful browser based on Blink

 Slimjet is a fast, smart and powerful web browser based on the Blink engine. 
It is built on top of the Chromium open source project, on which Google chrome 
is also based. Slimjet integrates a lot of powerful and convenient features to 
help users maximize their online productivity. Slimjet also includes many 
options and settings so that users can customize the browser to best suit their 
own personal preference.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150124063124.4962.43813.reportbug@debian.homelan

Bug#776123: ITP: truffle-dsl-processor -- Java library that helps writing Truffle nodes in a concise and efficient way

[Miguel Landaeta]

Package: wnpp
Severity: wishlist
Owner: Miguel Landaeta 

* Package name: truffle-dsl-processor
  Version : 0.6
  Upstream Author : Oracle, Inc.
* URL : http://openjdk.java.net/projects/graal
* License : GPL-2, with the Classpath Exception
  Programming Lang: Java
  Description : Java library that helps writing Truffle nodes in a concise 
and efficient way

 Truffle DSL uses annotations on classes, fields, and methods, from
 which an annotation processor infers further classes. It relieves the
 programmer from having to write the boiler plate code, and allows
 her to concentrate on implementing the semantics.
 .
 Truffle is essentially a language for modeling and implementing
 languages using Java as a base. This means that a programmer can use
 the existing Java's standard libraries, debug infrastructure,
 memory management, and productivity tools to implement an own language.

I'm packaging this as a dependency of jruby 9.0.0.0.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Re: motd handling in jessie

[Russ Allbery]

Josh Triplett  writes:

> Please, no.  Under normal circumstances, the only dynamic bit of the
> motd comes from uname, and only changes on reboot; updating it via cron
> just wastes cycles and adds noise to syslog.

> I'm not particularly convinced that even the existing uname line has
> much value.  So what about this: why don't we move all of that machinery
> to an update-motd package or similar (priority optional), which can hook
> into PAM as desired to display its message, and have the default motd of
> the base system be completely static, with nothing run at boot *or*
> login?

I do feel like we're losing some value by not showing users the uname
information by default, and I'd like to still see us update that at boot.
I certainly agree that running shell code from PAM by default is not a
good idea.

That said, by far the best way to handle MOTD is to write out a static
file using whatever configuration management system you're using, based on
all the information that it gathers about the system (via something like
ohai or facter).  That lets you flesh out the MOTD with lots of details
that are actually interesting.  But that's not something Debian needs to
be doing; each site can handle that.

-- 
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: https://lists.debian.org/878ugs7qw6@hope.eyrie.org

Bug#776122: ITP: truffle -- multi-language framework for executing dynamic languages

[Miguel Landaeta]

Package: wnpp
Severity: wishlist
Owner: Miguel Landaeta 

* Package name: truffle
  Version : 0.6
  Upstream Author : Oracle, Inc.
* URL : http://openjdk.java.net/projects/graal
* License : GPL-2, with the Classpath Exception
  Programming Lang: Java
  Description : multi-language framework for executing dynamic languages

 Truffle is a language abstract syntax tree interpreter which
 allow it to implement languages on top of the Graal framework.
 .
 To implement a language using Truffle you write an AST for your
 language and add methods to interpret (perform the action of) each
 node.
 .
 Graal is an Oracle project aiming to implement a high performance
 Java dynamic compiler and interpreter.

I'm packaging truffle because is a dependency of upcoming jruby
9.0.0.0.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Re: New pre-depends: python pre-depends python-minimal

[Scott Kitterman]

On Monday, November 24, 2014 03:15:51 Wouter Verhelst wrote:

OK.  I'm back on this again.

> On Sun, Nov 23, 2014 at 03:29:29PM -0500, Scott Kitterman wrote:
> > On Sunday, November 23, 2014 13:41:47 Wouter Verhelst wrote:
> > > As I understand the situation, that won't solve your problem.
> > > 
> > > If python pre-depends on python-minimal (and the rest of the
> > > dependencies
> > > stay in place), then you have the following situation:
> > > 
> > > - python2.7-minimal and python-minimal are unpacked (in undefined order)
> > > - python2.7-minimal is configured
> > > - python-minimal is configured
> > > - python can now be unpacked
> > > 
> > > As such, rather than fixing your problem, it would make matters worse;
> > > today it sometimes fails, depending on the exact decisions that apt and
> > > dpkg take when installing packages. With a pre-depends, it would
> > > *always* fail on new installs, because python would then not be
> > > *allowed* to be unpacked if python2.7-minimal isn't on the system, whose
> > > postinst would fail, which would forbid the installation of python (the
> > > step necessary to configure python2.7-minimal).
> > > 
> > > It looks to me like the only solution here is to split off whatever it
> > > is that python2.7-minimal needs from the python package into a separate
> > > package, and have python2.7-minimal depend on that separate package.
> > > Call it "python-base" or "python-common" or something.
> > 
> > Why would python-minimal be configured at unpack time for python?  AIUI,
> > the pre-depends would just require python-minimal to be unpacked prior to
> > configure, not unpack.
> 
> No, that's what a regular depends does. A pre-depends requires a package
> to be configured before unpack.
> 
> Policy 7.2:
> 
>  "This field is like Depends, except that it also forces dpkg to
>   complete installation of the packages named before even starting the
>   installation of the package which declares the pre-dependency, as
>   follows:
> 
>   When a package declaring a pre-dependency is about to be unpacked the
>   pre-dependency can be satisfied if the depended-on package is either
>   fully configured, or [special case for upgrade rather than install]"
> 
> > Did you mean python can now be configured?
> > 
> > I think pre-depends would solve the problem at hand,
> 
> Unless I misunderstand the situation and your proposed solution, it most
> certainly will not.
> 
> If what you mean is:
> 
> python pre-depends python-minimal
> python-minimal depends python2.7-minimal
> 
> Then a pre-depends is *not* what you need. If you mean something else, a
> Pre-Depends is probably still not what you need, because the cases in
> which a Pre-Depends is useful are actually pretty rare (I suspect that's
> why policy tells you to ask on this list before using it...). They are
> limited to two cases:
> 
> - Your preinst (as opposed to your postinst) wants to use something that
>   is *not* in the set of Essential packages, or
> - Your package wants to install files in a "special" directory which
>   only exists in a "working" state if another package was installed
>   first (e.g., multiarch-support)
> 
> > but I'm also interested in feedback on the alternative proposed in the
> > bug:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769106#31
> 
> As long as an installation of python2.7-minimal without python2.7 will
> not break if the "rtinstall" script isn't run, that really looks like an
> alternate proposal of my "python-base"/"python-common" suggestion.
> 
> What you need is for any scripts or binaries which you run in your
> postinst to be installed by packages that are either available in the
> Essential set, or in the set of packages that you depend on, directly or
> indirectly, through a depends or pre-depends. As long as you follow that
> rule, you're safe. A _reverse_ dependency (i.e., a package that depends
> on _your_ package) cannot safely provide a script or binary to be used
> in your postinst; and it does not matter whether you're using Depends or
> Pre-Depends in that case, because for postinst there is no difference.
> 
> Regards,

That's not the case here.  In the original bug [1], the situation is that 
during jessie development texlive-music gained a dependency on python, so on 
upgrade, python gets installed.  As part of that installation, the 
public_modules.rtinstall hook gets run as part of the python2.7-minimal 
postinstall.

For the post-install script to succeed, both python and python-minimal need to 
be unpacked.  They don't need to be installed.  Also from policy 7.2:

> A Depends field takes effect only when a package is to be configured. It
> does not prevent a package being on the system in an unconfigured state
> while its dependencies are unsatisfied, ...

That's the case we have here.  python has been unpacked, but not configured, so 
it'd dependency on python-minimal is irrelevant.  Later in 7.2, it goes on to 
say:

> Pre-Depends This field is li

Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

[Ben Hutchings]

On Wed, 2015-01-21 at 17:07 +1300, Chris Bannister wrote:
> On Mon, Jan 19, 2015 at 01:03:52AM +, Ben Hutchings wrote:
> > On Mon, 2015-01-19 at 08:37 +0800, Paul Wise wrote:
> > > On Mon, Jan 19, 2015 at 8:06 AM, Don Armstrong wrote:
> > > 
> > > > I'm going to put together a bit more firm of a proposal in the next few
> > > > weeks, but I think that basically everything but nnn-done@ and
> > > > nnn-submitter@ should be no different from mailing nnn@, and until I
> > > > allow submitters to opt out of e-mail, mailing nnn-submitter@ should be
> > > > no different from e-mailing nnn@ either.
> > > 
> > > I'd very much appreciate the ability to not be auto-subscribed to
> > > every bug so please do implement the opt-out thing, preferably before
> > > this change is rolled out.
> > > 
> > > Personally, I think subscriptions should work like this:
> > > 
> > > The default should be to auto-subscribe submitters and contributors to 
> > > bugs.
> > [...]
> > 
> > No, this would turn the BTS into a (worse) spam vector.
> 
> If a user submits a bug report then doesn't it make sense that the user
> would want to be able to be kept informed of any progress updates?

Yes, but we don't know whether to believe that address.

> Or an option in reportbug to do so, turned on by default. It could put
> an X- header in the email.
> 
> That way users of reportbug can choose to be 'spammed' or not.

This is still unconfirmed opt-in
.

Ben.

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.


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

Bug#776109: ITP: python-oslo-log -- OpenStack logging configuration library

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-oslo-log
  Version : 0.1.0
  Upstream Author : OpenStack Development Mailing List 

* URL : https://github.com/openstack/oslo.log
* License : Apache-2.0
  Programming Lang: Python
  Description : OpenStack logging configuration library

 OpenStack logging configuration library provides standardized configuration
 for all openstack projects. It also provides custom formatters, handlers and
 support for context specific logging (like resource id's etc).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150124010724.3074.61084.report...@buzig.gplhost.com

Re: motd handling in jessie

[Riley Baird]

>> If we go the update-motd route, I'd like to see the update-motd calls be
>> removed from login (and boot) and instead have the dynamic part of
>> /etc/motd be updated via a cron job.
> 
> Please, no.  Under normal circumstances, the only dynamic bit of the
> motd comes from uname, and only changes on reboot; updating it via cron
> just wastes cycles and adds noise to syslog.
> 
> I'm not particularly convinced that even the existing uname line has
> much value.  So what about this: why don't we move all of that machinery
> to an update-motd package or similar (priority optional), which can hook
> into PAM as desired to display its message, and have the default motd of
> the base system be completely static, with nothing run at boot *or*
> login?

I think that this is a good idea. If the user needs to see the uname,
and they're using a terminal, they'll most likely know the command to enter.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54c2a8b3.7080...@bitmessage.ch

Re: motd handling in jessie

[Josh Triplett]

Michael Biebl wrote:
> I'm also no longer convinced, that running a huge shell machinery (as
> root) during login via PAM is a good idea.

Agreed.

> If we go the update-motd route, I'd like to see the update-motd calls be
> removed from login (and boot) and instead have the dynamic part of
> /etc/motd be updated via a cron job.

Please, no.  Under normal circumstances, the only dynamic bit of the
motd comes from uname, and only changes on reboot; updating it via cron
just wastes cycles and adds noise to syslog.

I'm not particularly convinced that even the existing uname line has
much value.  So what about this: why don't we move all of that machinery
to an update-motd package or similar (priority optional), which can hook
into PAM as desired to display its message, and have the default motd of
the base system be completely static, with nothing run at boot *or*
login?

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150123195009.GA7345@jtriplet-mobl1

Re: comment installer une imprimante canon PIXMA MG2450

[Riley Baird]

On 24/01/15 02:18, bejaoui wrote:
> j ' ai eu des problèmes d' installation de l' imprimante j' arrive télé
> charger les logiciels qu' il faut je vous demande de l' aide merci.

Nous ne parlons pas français.
debian-devel-fre...@lists.debian.org



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54c2a2be.3040...@bitmessage.ch

Bug#776083: ITP: python-nanomsg -- Python library for nanomsg

[Federico Ceratto]

Package: wnpp
Severity: wishlist
Owner: Federico Ceratto 

* Package name: python-nanomsg
  Version : 1.0
  Upstream Author : Tony Simpson 
* URL : https://github.com/tonysimpson/nanomsg-python
* License : MIT
  Programming Lang: Python, C
  Description : Python library for nanomsg

Python interface for the nanomsg library (libnanomsg0)
Supports supported Python2, Python3 and Pypy.
Provides a C extension module to deliver high performance.

The package will be maintained in collab-maint; sponsors and
co-maintainers are very welcome.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150123180538.14239.22750.reportbug@localhost

comment installer une imprimante canon PIXMA MG2450

[bejaoui]

j ' ai eu des problèmes d' installation de l' imprimante j' arrive télé 
charger les logiciels qu' il faut je vous demande de l' aide merci.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54c26637.3010...@laposte.net

Re: motd handling in jessie & beyond

[Matthias Urlichs]

Hi,

Michael Biebl:
> I'm also no longer convinced, that running a huge shell machinery (as
> root) during login via PAM is a good idea.
> 
In fact, I'm convinced that it is _not_ a good idea.

You want to be able to log in as root when the system has problems.
Like, being slow as molasses or almost-out-of-memory.

The fewer code (esp. code which are not in memory anyway)
you run at that time, the better.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: Bug#776003: ITP: swarp -- Resample and co-add together FITS images

[Paul Wise]

On Thu, Jan 22, 2015 at 11:08 PM, Ole Streicher rote:

> * Package name: swarp

This is already in Debian, but is now RFA:

https://bugs.debian.org/776036

I've merged the two bugs and made them an ITA.

-- 
bye,
pabs

https://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: 
https://lists.debian.org/caktje6esrfyummztmytjqo0jx7fcuqcx1gyy5s8mc5qmcrb...@mail.gmail.com