Re: systemd breaking display manager - no way to force?

[Andrei POPESCU]

On Vi, 21 nov 14, 09:45:51, Norbert Preining wrote:
> Hi everyone,
> 
> so here we are, after the freeze, and systemd stubbornly rejects
> to start lightdm, my default display manager, and in turn tries
> to start lxdm, which does not work because it is not selected as
> default display manager. (Bug reported to systemd already)
> 
> Is there *any* way to *force* systemd to start lightdm ...?

I have a hunch the bug is actually in lxdm (specifically the service 
file). It should be simple to verify:

- purge lxdm (remove might do it as well, but just for good measure)
- reconfigure lightdm (to make sure display-manager.service symlink 
  points to lightdm.service)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Bug#769907: general: non-sysvinit init systems are made of fail

[Thomas Goirand]

On 11/19/2014 06:14 PM, Michal Suchanek wrote:
> On 18 November 2014 00:52, Thomas Goirand  wrote:
>> On 11/18/2014 03:50 AM, Michal Suchanek wrote:
>>> With
>>> current sysvinit the serial console is also used as main but
>>> sysvinit-core does not produce any messages on tty0 whatsoever and so
>>> does not mislead the user into thinking that useful boot progress
>>> feedback can be obtained on that terminal.
>>
>> This is because bootlogd only supports a single output at a time, and
>> therefore only outputs on the *last* occurrence of the console= boot
>> parameter. The patch that I pointed to resolves this by adding support
>> for outputting to multiple consoles. If you want it for Wheezy, I have
>> it here (as I use it for my unofficial OpenStack backport repo, it's in
>> that repository):
>>
>> http://archive.gplhost.com/debian/pool/juno-backports/main/s/sysvinit/
>>
> 
> Hello,
> 
> is the key for the juno archive available somewhere?

You can install this:
http://archive.gplhost.com/debian/pool/juno-backports/main/g/gplhost-archive-keyring/gplhost-archive-keyring_20100926-1_all.deb

> bootlogd(8) page does not mention any way to select log console other
> than bootlogd using the kernel commandline to determine console
> device.

Installing it isn't enough, you also need to set the kernel command line
parameter to:

console=tty0 console=ttyS0,115200

Cheers,

Thomas


-- 
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/546ecff0.60...@debian.org

Let's help your Visitors Enable JavaScript with Better Instructions

[javascriptON.com]

Hi there!

We're from a non-profit web project - javascriptON.com - we are showing the 
easy-to-do instructions to enable JavaScript for all popular browsers: Internet 
Explorer, Firefox, Google Chrome, Opera, Safari,... on many platform: Windows, 
Macintosh, Android, iOS,...

DO NOT let your visitors become tired because can not understand why your sites 
do not working properly when JavaScript is DISABLED. Show a friendly alert to 
them then let's help your dear readers enable JavaScript easily & quickly.

TOP 3 PROS you'll love when use our instructions on your websites:

The non-profit project to help your visitors.

We detect visitor's browsers exactly to provide best proper advices. Just type 
http://javascripton.com into address bar then follow our instructions to 
activate JavaScript within 1 minute.

Try It »
Modern and Awesome Layout plus the right guides

Our instructions designed by a modern and awesome layout, to run on many OS 
platforms, your visitors may read our instructions on any mobile platform, any 
tablet or any desktop OS. Very easy to read and quick to follow.

Enjoy Now »
Multilingual Project support local languages

We can easy help your visitors enable JavaScript by their local languages 
because this non-profit web project is multilingual project from many 
supporters. By default, we detect automatically the language of visitors by IP 
addresses to provide proper advices.

See in your Language »
So if you have any site / blog / web portal that uses JavaScript to run, do not 
wait till your visitors enable JavaScript to have the best web experiments on. 
Let's help your value visitors enable JavaScript easily and quickly with 
javascriptON. Do it Now! »

Google Chrome Windows, Mac, Android, iOS

Read our instructions to enable JavaScript in Google Chrome.

Chrome »
Mozilla Firefox Windows, Mac, Android, iOS

Instructions to turn on JavaScript in Mozilla Firefox browser.

Firefox »
Internet Explorer Windows & All versions.

Instructions to activate JavaScript in Internet Explorer.

Microsoft IE »
Opera Windows, Mac, Android, iOS

Learn to turn on JavaScript in Opera browser.

Opera »
Apple Safari Windows, Mac, iOS

How to enable JavaScript in Apple Safari browser.

Safari »
Connect with Us

Facebook @ javascriptON Twitter @ jscripton Google + javascriptON

Contact Info
Website: javascripton.com
Email: i...@javascripton.com

Re: policy regarding redistributable binary files in upstream tarballs

[Russell Stuart]

On Thu, 2014-11-20 at 13:46 +0800, Paul Wise wrote:
> On Thu, Nov 20, 2014 at 1:14 PM, Ben Finney wrote:
> 
> > But a growing number of upstreams disagree, so those upstreams are
> > likely to be actively opposed to your recommendation to patches 
> > which remove non-source files from the VCS repository.
> 
> I wonder about the basis for that disagreement.

In the GNU model the tarball doesn't just provide sources.  It is a
complete packaging system.  It checks for build prerequisites, does the
build, checks for install prerequisites, does the install, and does
uninstall.  It does all that because upstream wants people to use their
project - regardless of whether their distro packages it.  Combine that
with wanting to keep the perquisite list small including things like
minified jquery libraries is exactly the right thing to do.

> Putting all third-party libraries into a separate place (tarball,
> repo, branch or dir).
> 
> Putting all pre-built files into a separate place (tarball, repo,
> branch or dir).

Those suggestions may make things easier for Debian, but they do so by
making life harder for upstream's other users.  That isn't going to
happen, or at least for me it wouldn't.  If my DD alter ego asked my
upstream ego to make things much harder for his other users, he would be
politely told where he could shove his suggestion.

Personally, I think Debian passing judgement on what is upstream
pristine tarballs is over the top.  It's upstream's original work, not
Debian's.  Ideally we are just mirroring it.  (That we often aren't is
part of the problem.)  We should be happy enough to accept their
assurances on having obtained whatever licenses they need for what is in
them. [0]

Admittedly this meshes well with my experience that they are often
fairly lax about what they put in those tarballs.  Their "make
distclean" scripts are often not as good as they could be, which means
all sorts of crap it left lying around. Vim .swp files and compiler
intermediates spring to mind.  I have no idea what license would apply
to a .swp file, but I do know that for all practical purposes it doesn't
matter and I'd rather Debian didn't insist I find out. [1]

That's just me being lazy I guess.  But there is a deeper issue.  For me
it is vital there be an audit trail from the pristine upstream tar ball
to the binaries we distribute. [2]  In pursuing licensing purity we have
been gradually destroying what little of that audit trail we used to
provide.  To put it bluntly: as a DD I do care about licensing, but when
it comes to day job where I have to ensure hundreds of computers are
reliable and secure so the licensing of of tarballs I don't download let
alone use takes a distant second place to security.  So in my view we
are making life difficult for our users on the altar of FSF style
idealism.

Maybe if we were forced to choose between the two that would be right
choice to make.  But technically there are a ways to be FSF idealists
and provide something akin to an audit trail.  So we aren't forced to
choose - but we just deprive our users of the audit trail anyway.  That
is bad.

What follows is something I am sure has been covered before by someone
somewhere, before I started following the project in earnest.  I can't
find it - so I apologise in advance for the repetition.

I start my Linux life as a RedHat user, and I wrote RPM packages for my
own use.  Then about a decade ago I moved to Debian, and of course
started writing Debian packages.  During the transition I was struck by
how much better Debian's binary packaging was compared to RPM, and yet
RPM's source packaging was so much better than Debian's.

To explain why I'll step back a bit.  If I were writing a book on how to
design a packaging system it would start by introducing these 5 steps:

A.  The process is ideally [3] a pure function.  It's input is the
pristine source.  It's output is the binary packages.  So the 1st
step is to obtain the input - the pristine source, and record it
in the output so anyone else can reproduce what you have done.

B.  These inputs are fed to packaging process a program, written by the
packager, that implements the function doing the transformation.
In debian, this is debian/rules.  This function is split into
standardised steps.  The second step is unpacking sources from
whatever format they are in into a build directory. [4]

C.  The third step is to tailor the pristine sources to match the
requirements of the distribution.  This is done in a standardised
way: by applying a series of patches in a well defined format, each
with a clearly documented purpose.

D.  Run the build process as supplied by upstream, but perhaps modified
by step (C).

E.  Collecting the output of the build process into binary packages. [5]

And that is exactly what RPM's did over a decade ago.  Debian mashed
steps (A), (B) and (C) into what could only be described as a mess.

Time has moved on, and things

Bug#770410: ITP: libjson-rpc-cpp -- JSON-RPC 1.0 & 2.0 framework for C++

[Peter Spiess-Knafl]

Package: wnpp
Severity: wishlist
Owner: "Peter Spiess-Knafl" 

* Package name: libjson-rpc-cpp
  Version : 0.4
  Upstream Author : Peter Spiess-Knafl 
* URL : https://github.com/cinemast/libjson-rpc-cpp
* License : MIT/X
  Programming Lang: C++
  Description : JSON-RPC 1.0 & 2.0 framework for C++

libjson-rpc-cpp is a crossplatform JSON-RPC framework for C++ Client
and Server applications. It provides easy to use tools
(e.g. stubgenerators) to implement JSON-RPC applications very
straightforward.

It can generate a fully functional C++ client out of a simple
specification file. For server applications, it can generate
abstract classes which only need to implement the specified
procedures.

To allow simple and easy to use interaction between client and server
HTTP connectors (based on libcurl and libmicrohttpd) are already provided.

I want to package this, because there is no JSON-RPC C++ framework
in debian available yet. I have been asked by many users of this
framework for a debian package.

Since I am the upstream author, I can provide security and bug fixes
very easily.


-- 
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/20141121024514.1907.30782.reportbug@cinemast-ThinkPad-T410s

systemd breaking display manager - no way to force?

[Norbert Preining]

Hi everyone,

so here we are, after the freeze, and systemd stubbornly rejects
to start lightdm, my default display manager, and in turn tries
to start lxdm, which does not work because it is not selected as
default display manager. (Bug reported to systemd already)

Is there *any* way to *force* systemd to start lightdm ...?

I mean, in good old days, well, it was easy, ... now ... systemd
just tells me
Loaded: error (Reason: File exists)
(btw, thanks for telling me *which* file ...)

man page of systemctl does not help

SO we are not supposed to force start something where *I* know it
is ok to start ...???

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
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/20141121004551.gx22...@auth.logic.tuwien.ac.at

Bug#770405: ITP: libbase58 -- library for Bitcoin's base58 encoding

[Dmitry Smirnov]

Package: wnpp
Severity: minor
X-Debbugs-CC: debian-devel@lists.debian.org 
pkg-bitcoin-de...@lists.alioth.debian.org

   Package name: libbase58
Version: 0.1.3
Upstream Author: Luke Dashjr 
URL: https://github.com/luke-jr/libbase58
License: Expat (a.k.a. MIT), public-domain (CC0-1.0)
Description: library for Bitcoin's base58 encoding
 Library for encoding/decoding Base58 and Base58Check.

Vcs-Browser: http://anonscm.debian.org/cgit/pkg-bitcoin/libbase58.git

This library is dependency of new versions of "libblkmaker" and "bfgminer".


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

Work-needing packages report for Nov 21, 2014

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 621 (new: 12)
Total number of packages offered up for adoption: 148 (new: 8)
Total number of packages requested help for: 56 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   atoppatch (#770233), orphaned yesterday
 Description: additional statistical counters for atop
 Reverse Depends: kernel-patch-atopacct
 Installations reported by Popcon: 61

   aumix (#770262), orphaned today
 Reverse Depends: aumix aumix-gtk mpg123-el
 Installations reported by Popcon: 3357

   cvstrac (#770234), orphaned yesterday
 Description: Low-ceremony bug tracker for medium-sized projects
   under CVS
 Installations reported by Popcon: 17

   dhcpcd-dbus (#770080), orphaned 2 days ago
 Description: DBus bindings for dhcpcd
 Reverse Depends: dhcpcd-gtk
 Installations reported by Popcon: 72

   dhcpcd-ui (#770081), orphaned 2 days ago
 Description: GTK+ frontend for dhcpcd and wpa_supplicant
 Installations reported by Popcon: 49

   dhcpcd5 (#770082), orphaned 2 days ago
 Description: DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support
 Reverse Depends: dhcpcd-dbus
 Installations reported by Popcon: 163

   disc-cover (#770260), orphaned today
 Installations reported by Popcon: 152

   larswm (#770235), orphaned yesterday
 Description: Lars Window Manager with tiled windows
 Installations reported by Popcon: 53

   mgdiff (#770236), orphaned yesterday
 Description: xdiff clone
 Installations reported by Popcon: 535

   netrik (#770237), orphaned yesterday
 Description: text mode WWW browser with vi like keybindings
 Installations reported by Popcon: 201

   openresolv (#770083), orphaned 2 days ago
 Description: management framework for resolv.conf
 Installations reported by Popcon: 234

   sipml5 (#769779), orphaned 4 days ago
 Description: JavaScript SIP stack
 Reverse Depends: sipml5-web-phone
 Installations reported by Popcon: 18

609 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   convoy (#769726), offered 5 days ago
 Description: WSGI app for loading multiple files in the same request
 Installations reported by Popcon: 2

   delta (#770371), offered today
 Description: heuristic minimizer of interesting files
 Reverse Depends: creduce
 Installations reported by Popcon: 61

   libpam-alreadyloggedin (#770373), offered today
 Description: PAM module to skip password authentication for logged
   users
 Installations reported by Popcon: 20

   nss-wrapper (#770375), offered today
 Description: NSS wrapper library
 Installations reported by Popcon: 2

   rc (#770372), offered today
 Description: implementation of the AT&T Plan 9 shell
 Installations reported by Popcon: 1437

   sagasu (#770154), offered yesterday
 Description: GNOME tool to find strings in a set of files
 Installations reported by Popcon: 49

   socket-wrapper (#770374), offered today
 Description: socket wrapper library
 Installations reported by Popcon: 2

   topia.termextract (#769724), offered 5 days ago
 Description: Content Term Extraction using POS Tagging
 Installations reported by Popcon: 4

140 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   apt-xapian-index (#567955), requested 1753 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: ept-cache goplay packagesearch
 Installations reported by Popcon: 77218

   athcool (#278442), requested 3677 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 41

   awstats (#755797), requested 120 days ago
 Description: powerful and featureful web server log analyzer
 Installations reported by Popcon: 4142

   balsa (#642906), requested 1152 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 734

   cardstories (#624100), requested 1305 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 11

   chromium-browser (#583826), requested 1635 days ago
 Description: Chromium browser
 Reverse Depends: chromedriver chr

Re: r-base-core upload to unstable does not respect freeze policy

[peter green]

Hmmm, this is what I missed. :-(  I guess the only chance is to upload
to t-p-u, right? 
  
Afaict you could do a "source amd64 arm64 armel armhf i386 mips mipsel 
powerpc ppc64el s390x" upload to unstable so that binaries for all 
release architectures were supplied by you rather than by buildds.


It would be a PITA to do (build all the binaries, bring them back to a 
single box and mergechanges them into a single upload) but i'm pretty 
sure it would work.



--
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/546e88c1.7020...@p10link.net

Re: policy regarding redistributable binary files in upstream tarballs

[Jonas Smedegaard]

Quoting Salvo Tomaselli (2014-11-20 23:40:18)
>> Could you include some information about the upstream you are talking 
>> about and the specific files you are concerned about?
>
> I am talking about this bug:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769830

That's a nice bugreport.  It points out what several of us have now 
repeated here in this thread.

Please in the future make sure to mention such references in initial 
posts, to avoid us wasting time repeating each other.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: policy regarding redistributable binary files in upstream tarballs

[Scott Kitterman]

On Thursday, November 20, 2014 11:40:18 PM Salvo Tomaselli wrote:
> > Could you include some information about the upstream you are talking
> > about and the specific files you are concerned about?
> 
> I am talking about this bug:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769830
> 
> The package has a lintian override that I suggested, on the grounds that the
> incriminated file doesn't go inside a .deb package.
> 
> I am neither upstream or Debian maintainer for the package, but I have sent
> some patches to both.
> 
> The minified javascript file mentioned in the bug is completely ignored in
> Debian. It is replaced with a soft link and a dependency.
> 
> I don't think upstream would remove these minified javascript files, because
> they would need a more complex build process and more dependencies. The
> files are just used to do an "HTML export", so they are just copied inside
> a directory when the HTML export is done, so I think that to convince them
> to build them, we would need very strong arguments. Consider that they
> support windows and mac as well, so they'd need their build process to work
> on these platforms.

Go read the FTP Team statement that was referenced up-thread.  Your premise 
for the override is incorrect from the point of view of the FTP Team.

Scott K


-- 
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/1814299.PxqWUR9ErG@kitterman-optiplex-9020m

Re: policy regarding redistributable binary files in upstream tarballs

[Salvo Tomaselli]

> Could you include some information about the upstream you are talking
> about and the specific files you are concerned about?

I am talking about this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769830

The package has a lintian override that I suggested, on the grounds that the 
incriminated file doesn't go inside a .deb package.

I am neither upstream or Debian maintainer for the package, but I have sent 
some patches to both.

The minified javascript file mentioned in the bug is completely ignored in 
Debian. It is replaced with a soft link and a dependency.

I don't think upstream would remove these minified javascript files, because 
they would need a more complex build process and more dependencies. The files 
are just used to do an "HTML export", so they are just copied inside a 
directory when the HTML export is done, so I think that to convince them to 
build them, we would need very strong arguments. Consider that they support 
windows and mac as well, so they'd need their build process to work on these 
platforms.


-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di 
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/


-- 
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/1506228.ngB3iYNcAe@hal9000

Re: init system policy

[Cameron Norman]

On Thu, Nov 20, 2014 at 8:28 AM, Russ Allbery  wrote:
> Jonas Smedegaard  writes:
>
>> Seems to me this is a similar limitation as for config.d structures - as
>> an example apache2 is now far more modular than in the past but I no
>> longer as sysadmin get notified what exactly has changed when I upgrade
>> a system with customizations, as I did in the past thanks to the
>> monolithic configfile being a conffile.
>
> There was some discussion about this a while back, and I vaguely remember
> that systemd comes with a tool that will tell you exactly what you're
> overriding.  I'm not sure if that work got all the way to producing a nice
> Debian-aware tool or not.
>
> Personally (and this is just a wishlist), I'd love to have functionality
> similar to apt-listchanges that would (optionally) show me a report of
> every change to any unit file that I've overridden on each upgrade.

But systemd is not the only package to provide a vendor config in /lib
(or /usr/share or /usr/lib) and allow it to be overridden by a file in
/etc. One example is mountall, which provides a base fstab in
/lib/init/ that is overridden by entries in /etc/fstab. networkd and
many other systemd components are similar in this as well. I think
debian conffiles need a generic mechanism that allows packages to
associate files in /etc with files in the vendor directories like /lib
so that the admin is notified when the vendor supplied configuration
is changed. Maybe it could look like this, in
`debian/package.conffiles` :

# traditional conffiles entries
/etc/package/main.conf
# new entries
# admin-supplied vendor-supplied
/etc/package/other.conf /usr/share/package/other.conf
/etc/systemd/system/package.service /lib/systemd/system/package.service
/etc/systemd/system/package.service.d/* /lib/systemd/system/package.service

Seeing as systemd upstream is pushing the "stateless systems" idea,
and there is definitely merit to it, I think this is the best way to
tackle the issue.

Best wishes,
--
Cameron Norman


-- 
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/calzwfr+iosvcpxucmttt_1ck7c1jxrupgss_qbnacfwuplc...@mail.gmail.com

Bug#769907: A small suggestion on constructive engagement [Was, Re: Bug#769907: general: non-sysvinit init systems are made of fail]

[Octavio Alvarez]

On 19/11/14 21:32, Steve Langasek wrote:
>> 1) the problem with new feature in systemd which considers all 
>> filesystems in fstab vital for system boot and stops boot if they
>> fail. It's been decided that although it is a change in behaviour
>> that might render some systems unbootable it's technically correct
>> implementation and only enforces that non-vital filesystems are
>> marked as such in fstab which should have been the case from the
>> start.
>> 
> As regards the two issues you've described: the first is not a bug.
> It's a necessary change in how we view the boot in a truly
> event-driven system. There is no sane default policy for how to
> interpret entries in /etc/fstab on upgrade except to regard them as
> all mandatory - *but* it's important that the admin be given the
> opportunity to intervene to override this policy.

Question: is it safe to say that systemd doesn't yet support the full
/etc/fstab specification from util-linux [1]?

[1] man 5 fstab

Thanks.


-- 
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/546e6113.2010...@alvarezp.ods.org

Bug#769907: A small suggestion on constructive engagement [Was, Re: Bug#769907: general: non-sysvinit init systems are made of fail]

[Steve Langasek]

On Thu, Nov 20, 2014 at 01:45:55PM -0800, Octavio Alvarez wrote:
> On 19/11/14 21:32, Steve Langasek wrote:
> >> 1) the problem with new feature in systemd which considers all 
> >> filesystems in fstab vital for system boot and stops boot if they
> >> fail. It's been decided that although it is a change in behaviour
> >> that might render some systems unbootable it's technically correct
> >> implementation and only enforces that non-vital filesystems are
> >> marked as such in fstab which should have been the case from the
> >> start.

> > As regards the two issues you've described: the first is not a bug.
> > It's a necessary change in how we view the boot in a truly
> > event-driven system. There is no sane default policy for how to
> > interpret entries in /etc/fstab on upgrade except to regard them as
> > all mandatory - *but* it's important that the admin be given the
> > opportunity to intervene to override this policy.

> Question: is it safe to say that systemd doesn't yet support the full
> /etc/fstab specification from util-linux [1]?

 No?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Help to review a patch in ELisp

[Josh Triplett]

Stéphane Aulery wrote:
> I am looking for a person who knows enough to verify a ELisp patch. The
> patch is supposed to fix a problem of space in file names [1], upstream
> unfortunately does not have the in-house expertise [2].
[...]
> diff -r -u cscope-15.7a/contrib/xcscope/cscope-indexer 
> change/cscope-15.7a/contrib/xcscope/cscope-indexer
> --- cscope-15.7a/contrib/xcscope/cscope-indexer 2001-06-28 12:39:48.0 
> +0800
> +++ change/cscope-15.7a/contrib/xcscope/cscope-indexer  2010-04-28 
> 17:46:02.0 +0800
> @@ -139,7 +139,8 @@
>  ) | \
>  egrep -i '\.([chly](xx|pp)*|cc|hh)$' | \
>  sed -e '/\/CVS\//d' -e '/\/RCS\//d' -e 's/^\.\///' | \
> -sort > $LIST_FILE
> +sort | \
> +   sed -e 's/.* .*/\"&\"/' > $LIST_FILE
>  
>  if [ "X$VERBOSE" != "X" ]
>  then

I can't speak for the rest of the patch without digging into quite a bit
of the context and assumptions in the elisp, but regarding this bit,
rather than checking for spaces and only quoting filenames then, just
*always* quote all filenames.  That also makes sure you test that path
thoroughly.

- 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/20141120214131.GA7273@jtriplet-mobl1

Bug#770387: ITP: ruby-beaneater -- simple beanstalkd client library for Ruby

[Apollon Oikonomopoulos]

Package: wnpp
Severity: wishlist
Owner: Apollon Oikonomopoulos 

* Package name: ruby-beaneater
  Version : 0.3.3
  Upstream Author : Nico Taing
* URL : https://github.com/beanstalkd/beaneater
* License : MIT
  Programming Lang: Ruby
  Description : simple beanstalkd client library for Ruby

Beaneater is a library to interact with beanstalkd from within Ruby.  
Beanstalkd is a simple, fast work queue. Its interface is generic, but 
was originally designed for reducing the latency of page views in 
high-volume web applications by running time-consuming tasks 
asynchronously.

I intend to maintain this package under the Ruby Extras team.


-- 
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/20141120212134.ga19...@marvin.ws.skroutz.gr

Re: init system policy

[Philip Hands]

Matthias Klumpp  writes:

> 2014-11-20 17:44 GMT+01:00 Jonas Smedegaard :
>> Quoting Matthias Klumpp (2014-11-20 17:15:50)
>>> 2014-11-20 16:12 GMT+01:00 Jonas Smedegaard :
>>> > Quoting Vincent Danjean (2014-11-20 14:25:59)
>>> >>   Hi,
>>> >>
>>> >> On 18/11/2014 18:36, Ansgar Burchardt wrote:
>>> >> > With systemd you can ship a default configuration in
>>> >> > /lib/systemd/system and administrators can override specific options,
>>> >> > for example:
>>> >> >
>>> >> > +---
>>> >> > | [Unit]
>>> >> > | Description=Some Helpful Description
>>> >> > | Documentation=man:minidlda(1)
>>> >> > |
>>> >> > | [Service]
>>> >> > | User=minidlda
>>> >> > | ExecStart=/usr/sbin/minidldad -S
>>> >> > +---[ /lib/systemd/system/minidlda.service ]
>>> >> >
>>> >> > Then an admin can override the entire file by writing his own
>>> >> > /etc/systemd/system/minidlda.service or only override specific 
>>> >> > settings:
>>> >> >
>>> >> > +---
>>> >> > | [Service]
>>> >> > | User=some-other-user
>>> >> > +---[ /etc/systemd/system/miniblda.service.d/user.conf ]
>>> >>
>>> >>   I did not know that. It is very interesting.
>>> >>
>>> >> But, is there a way to be notified at upgrade time that the system
>>> >> service file has been modified when there is local (partial or full)
>>> >> changes ?
>>> >
>>> > I was wondering the same.
>>> At least for the systemd-case, you can easily notice changes using the
>>> systemd-delta command:
>>>  $> systemd-delta --diff
>>> This will list all overrides and the differences in case something has
>>> changed.
>>
>> Thanks.  Sounds like only a diff between system-provided and
>> sysadmin-overrided config, however: That might help for the latter part
>> of the question - notify only when system service file is overridden
>> locally (by suppressing notification if systemd-deta is empty).
>>
>> How to do first part of the question - be notified with a diff between
>> old versus new _effective_ config when a package update changes a system
>> service file?
> I don't now of any tool which does that yet - but it shouldn't be hard
> to write one that does it (maybe we could even run that by default if
> a package touches a vendor-supplied configuration in /lib).
> It would just be comparing checksums before and after installation of
> a package, and then point the sysadmin at the changed file.

Would it perhaps make sense to have etckeeper additionally keep track of
files in /lib directories for packages that have this /etc overrides
/lib scheme?  Such packages could add their config-outside-etc
directories to a list somewhere, perhaps, which packages like etckeeper
could then pick up on.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


pgpgMkmtJ9CJy.pgp
Description: PGP signature

Re: Bug#769907: general: non-sysvinit init systems are made of fail

[Steve Langasek]

On Thu, Nov 20, 2014 at 06:53:27PM +0100, Marco d'Itri wrote:
> On Nov 20, Sam Hartman  wrote:

> > The first issue (fstab now fatally blocks boot) is something the systemd
> > maintainers have considered (as I understand it) and rejected.
> The behaviour of systemd will not be changed, but I have plans to add 
> a fstab sanity check to preinst.

This would be a useful improvement, but bear in mind that there might be a
device successfully mounted at package install time that subsequently fails
to mount at boot - either because it's removable media and it has been
removed, or because it's a filesystem that requires something extra beyond
what's currently integrated with systemd in order to mount.  (e.g. a network
filesystem which requires an additional client daemon for mounting, and the
client daemon only has an init script running in runlevel 2.)

So it's important to provide users with straightforward means of recovery
when their system gets into this state on boot.  Based on my experience with
upstart, I would say this is a hard thing to get right - but it's important
to consistently work towards this.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#770384: ITP: sjaakii -- computer player for Chess and variants, including Shogi and XiangQi

[Yann Dirson]

Package: wnpp
Severity: wishlist
Owner: Yann Dirson 

* Package name: sjaakii
  Version : beta2
  Upstream Author : Evert Glebbeek 
* URL : http://www.eglebbk.dds.nl/program/chess-index.html
* License : GPL
  Programming Lang: C++
  Description : Sjaak II - computer player for Chess and variants, 
including Shogi and XiangQi

This is a new XBoard-compatible engine, including variants for Chess
and Shogi that are not widely available elsewhere.


-- 
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/20141120210222.ga2...@home.lan

Re: systemd, fstab, noauto and nofail

[Simon McVittie]

On 20/11/14 19:06, Noel Torres wrote:
> On Thursday, 20 de November de 2014 17:53:27 Marco d'Itri escribió:
>> On Nov 20, Sam Hartman  wrote:
>>> The first issue (fstab now fatally blocks boot) is something the systemd
>>> maintainers have considered (as I understand it) and rejected.
>>
>> The behaviour of systemd will not be changed, but I have plans to add
>> a fstab sanity check to preinst.
> 
> Just for my sanity of mind. Is this referring to entries in fstab that have 
> the auto option (either directly or via defaults)?

Yes, I'm pretty sure this is referring to entries in fstab that do not
have the noauto and/or nofail options.

systemd tries to mount each filesystem listed in fstab that does not
have noauto. If one of them fails, it checks for the nofail option; if
given, it carries on regardless and hopes for the best. If nofail was
not given, it considers the failure-to-mount to be potentially serious
breakage, and drops into an emergency shell.

noauto is appropriate for detachable/removable media that are not
normally present. The other option for such media is to leave them out
of fstab altogether, and use something like udisks to mount them
on-demand: that's what you'd typically do in GNOME or KDE or whatever.

nofail is appropriate for media that are normally present, but not
important enough to make the boot fail entirely; if you mount
non-essential data directories via NFS then maybe that should be nofail?

S


-- 
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/546e52a1.2080...@debian.org

Re: init system policy

[Matthias Klumpp]

2014-11-20 17:44 GMT+01:00 Jonas Smedegaard :
> Quoting Matthias Klumpp (2014-11-20 17:15:50)
>> 2014-11-20 16:12 GMT+01:00 Jonas Smedegaard :
>> > Quoting Vincent Danjean (2014-11-20 14:25:59)
>> >>   Hi,
>> >>
>> >> On 18/11/2014 18:36, Ansgar Burchardt wrote:
>> >> > With systemd you can ship a default configuration in
>> >> > /lib/systemd/system and administrators can override specific options,
>> >> > for example:
>> >> >
>> >> > +---
>> >> > | [Unit]
>> >> > | Description=Some Helpful Description
>> >> > | Documentation=man:minidlda(1)
>> >> > |
>> >> > | [Service]
>> >> > | User=minidlda
>> >> > | ExecStart=/usr/sbin/minidldad -S
>> >> > +---[ /lib/systemd/system/minidlda.service ]
>> >> >
>> >> > Then an admin can override the entire file by writing his own
>> >> > /etc/systemd/system/minidlda.service or only override specific settings:
>> >> >
>> >> > +---
>> >> > | [Service]
>> >> > | User=some-other-user
>> >> > +---[ /etc/systemd/system/miniblda.service.d/user.conf ]
>> >>
>> >>   I did not know that. It is very interesting.
>> >>
>> >> But, is there a way to be notified at upgrade time that the system
>> >> service file has been modified when there is local (partial or full)
>> >> changes ?
>> >
>> > I was wondering the same.
>> At least for the systemd-case, you can easily notice changes using the
>> systemd-delta command:
>>  $> systemd-delta --diff
>> This will list all overrides and the differences in case something has
>> changed.
>
> Thanks.  Sounds like only a diff between system-provided and
> sysadmin-overrided config, however: That might help for the latter part
> of the question - notify only when system service file is overridden
> locally (by suppressing notification if systemd-deta is empty).
>
> How to do first part of the question - be notified with a diff between
> old versus new _effective_ config when a package update changes a system
> service file?
I don't now of any tool which does that yet - but it shouldn't be hard
to write one that does it (maybe we could even run that by default if
a package touches a vendor-supplied configuration in /lib).
It would just be comparing checksums before and after installation of
a package, and then point the sysadmin at the changed file.

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
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/caknhny_n20kjy4rmk3ekkjrr8nz2qnxekki3grfcldcotx9...@mail.gmail.com

Re: init system policy

[Jonas Smedegaard]

Quoting Russ Allbery (2014-11-20 17:28:28)
> Jonas Smedegaard  writes:
>
>> Seems to me this is a similar limitation as for config.d structures - as
>> an example apache2 is now far more modular than in the past but I no
>> longer as sysadmin get notified what exactly has changed when I upgrade
>> a system with customizations, as I did in the past thanks to the
>> monolithic configfile being a conffile.
>
> There was some discussion about this a while back, and I vaguely remember
> that systemd comes with a tool that will tell you exactly what you're
> overriding.  I'm not sure if that work got all the way to producing a nice
> Debian-aware tool or not.

Sounds interesting.  If anyone recall that discussion and can share a 
pointer, I would appreciate it.


> Personally (and this is just a wishlist), I'd love to have functionality
> similar to apt-listchanges that would (optionally) show me a report of
> every change to any unit file that I've overridden on each upgrade.

I have tinkered with some tools related to that.  Far from reliable yet, 
but knowing I am not alone with that wishlist might push me enough to 
polish those tools adequately...  So thank you for the encouragement :-)


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Help to review a patch in ELisp

[Stéphane Aulery]

Hello,

I am looking for a person who knows enough to verify a ELisp patch. The
patch is supposed to fix a problem of space in file names [1], upstream
unfortunately does not have the in-house expertise [2].

Volunteers?

Regards,

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579531
[2] https://sourceforge.net/p/cscope/bugs/282/#9a4f/f853

-- 
Stéphane Aulery


-- 
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/20141120195438.gc5...@free.fr

Help to review a patch in ELisp

[Stéphane Aulery]

Hello,

I am looking for a person who knows enough to verify a ELisp patch. The
patch is supposed to fix a problem of space in file names [1], upstream
unfortunately does not have the in-house expertise [2].

Volunteers?

Regards,

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579531
[2] https://sourceforge.net/p/cscope/bugs/282/#9a4f/f853

-- 
Stéphane Aulery
diff -r -u cscope-15.7a/contrib/xcscope/cscope-indexer change/cscope-15.7a/contrib/xcscope/cscope-indexer
--- cscope-15.7a/contrib/xcscope/cscope-indexer	2001-06-28 12:39:48.0 +0800
+++ change/cscope-15.7a/contrib/xcscope/cscope-indexer	2010-04-28 17:46:02.0 +0800
@@ -139,7 +139,8 @@
 ) | \
 egrep -i '\.([chly](xx|pp)*|cc|hh)$' | \
 sed -e '/\/CVS\//d' -e '/\/RCS\//d' -e 's/^\.\///' | \
-sort > $LIST_FILE
+sort | \
+	sed -e 's/.* .*/\"&\"/' > $LIST_FILE
 
 if [ "X$VERBOSE" != "X" ]
 then
diff -r -u cscope-15.7a/contrib/xcscope/xcscope.el change/cscope-15.7a/contrib/xcscope/xcscope.el
--- cscope-15.7a/contrib/xcscope/xcscope.el	2002-04-11 00:59:00.0 +0800
+++ change/cscope-15.7a/contrib/xcscope/xcscope.el	2010-04-28 17:47:45.0 +0800
@@ -1750,7 +1750,7 @@
 
 		;; This should always match.
 		(if (string-match
-		 "^\\([^ \t]+\\)[ \t]+\\([^ \t]+\\)[ \t]+\\([0-9]+\\)[ \t]+\\(.*\\)\n"
+		 "^\\([^\t]+\\)[ \t]+\\([^ \t]+\\)[ \t]+\\([0-9]+\\)[ \t]+\\(.*\\)\n"
 		 line)
 		(progn
 		  (let (str)
diff -r -u cscope-15.7a/src/command.c change/cscope-15.7a/src/command.c
--- cscope-15.7a/src/command.c	2009-04-10 21:40:36.0 +0800
+++ change/cscope-15.7a/src/command.c	2010-04-28 17:39:19.0 +0800
@@ -728,7 +728,7 @@
 *oldfile = '\0';
 seekline(1);
 for (i = 0; 
-	 fscanf(refsfound, "%" PATHLEN_STR "s%*s%" NUMLEN_STR "s%*[^\n]", newfile, linenum) == 2;
+	 fscanf(refsfound, "%" PATHLEN_STR "[^\t]\t%*s%" NUMLEN_STR "s%*[^\n]\n", newfile, linenum) == 2;
 	 ++i) {
 	/* see if the line is to be changed */
 	if (change[i] == YES) {
@@ -884,8 +884,9 @@
 filelen = 4;		/* strlen("File") */
 fcnlen = 8;		/* strlen("Function") */
 numlen = 0;
-while ((i = fscanf(refsfound, "%250s%250s%5s %5000[^\n]", file,
-		   function, linenum, tempstring)) != EOF) {
+
+while ((i = fscanf(refsfound, "%250[^\t]\t%250s %5s %5000[^\n]\n", file,
+	   function, linenum, tempstring)) != EOF) {
 	if (i != 4 ||
 	!isgraph((unsigned char) *file) ||
 	!isgraph((unsigned char) *function) ||
diff -r -u cscope-15.7a/src/display.c change/cscope-15.7a/src/display.c
--- cscope-15.7a/src/display.c	2009-04-10 21:40:36.0 +0800
+++ change/cscope-15.7a/src/display.c	2010-04-28 17:21:24.0 +0800
@@ -224,7 +224,7 @@
 	 disprefs < mdisprefs && screenline <= lastdispline;
 	 ++disprefs, ++screenline) {
 	/* read the reference line */
-	if (fscanf(refsfound, "%" PATHLEN_STR "s%" PATHLEN_STR "s%" NUMLEN_STR "s %" TEMPSTRING_LEN_STR "[^\n]", file, function, 
+	if (fscanf(refsfound, "%" PATHLEN_STR "[^\t]\t%" PATLEN_STR "s%" NUMLEN_STR "s %" TEMPSTRING_LEN_STR "[^\n]\n", file, function, 
 		   linenum, tempstring) < 4) {
 		break;
 	}
diff -r -u cscope-15.7a/src/edit.c change/cscope-15.7a/src/edit.c
--- cscope-15.7a/src/edit.c	2009-04-10 21:40:36.0 +0800
+++ change/cscope-15.7a/src/edit.c	2010-04-28 14:49:06.0 +0800
@@ -60,7 +60,7 @@
 	seekline(i + topline);
 	
 	/* get the file name and line number */
-	if (fscanf(refsfound, "%" PATHLEN_STR "s%*s%" NUMLEN_STR "s", file, linenum) == 2) {
+	if (fscanf(refsfound, "%" PATHLEN_STR "[^\t]\t%*s%" NUMLEN_STR "s", file, linenum) == 2) {
 		edit(file, linenum);	/* edit it */
 	}
 	seekline(topline);	/* restore the line pointer */
@@ -83,7 +83,7 @@
 	seekline(1);
 	
 	/* get each file name and line number */
-	while (fscanf(refsfound, "%" PATHLEN_STR "s%*s%" NUMLEN_STR "s%*[^\n]", file, linenum) == 2) {
+	while (fscanf(refsfound, "%" PATHLEN_STR "[^\t]\t%*s%" NUMLEN_STR "s%*[^\n]\n", file, linenum) == 2) {
 		edit(file, linenum);	/* edit it */
 		if (editallprompt == YES) {
 			addstr("Type ^D to stop editing all lines, or any other character to continue: ");
diff -r -u cscope-15.7a/src/find.c change/cscope-15.7a/src/find.c
--- cscope-15.7a/src/find.c	2009-04-10 21:40:36.0 +0800
+++ change/cscope-15.7a/src/find.c	2010-04-28 17:18:06.0 +0800
@@ -506,7 +506,7 @@
 	char *file = filepath(srcfiles[i]);
 
 	progress("Search", searchcount, nsrcfiles);
-	if (egrep(file, refsfound, "%s  %ld ") < 0) {
+	if (egrep(file, refsfound, "%s\t %ld ") < 0) {
 		posterr ("Cannot open file %s", file);
 	}
 	}
@@ -532,7 +532,7 @@
 	s = srcfiles[i];
 	}
 	if (regexec (®exp, s, (size_t)0, NULL, 0) == 0) {
-	(void) fprintf(refsfound, "%s  1 \n", 
+	(void) fprintf(refsfound, "%s\t 1 \n", 
 			   srcfiles[i]);
 	}
 }
@@ -765,7 +765,7 @@
 	else {
 		output = nonglobalrefs;
 	}
-	(void) fprintf(output, "%s %s ", file, func);
+	(void) fprintf(output, "%s\t%s ", fi

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Bernhard R. Link]

* Ron  [141119 07:21]:
> I believe Bernhard explained earlier that git-dpm allows the replacement
> character to be configurable (but also offers just a single character
> for all replacements).

git-dpm doesn't have a replacement-character configurable, but different
control sequences for the variable parts of tags supporting different
version schemata, so one can configure "debian%e-%v" for the old style
1:2:3~4 generating tag name "debian1-2_3_4". And "debian/%E%V" would
give "debian/1.2.3.4" and "foobar-%e%v" would give "doobar-1.2_3_4".
The current sid version has some combinations (for the different parts
of the version needed for the different older schemata there are currently
%v %u %e %f %V %U %E) but yet none which replaces anything in versions
with "%", which will make it interesting to create code for it.

Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC


-- 
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/20141120193737.ga1...@client.brlink.eu

Re: Bug#769907: general: non-sysvinit init systems are made of fail

[Noel Torres]

On Thursday, 20 de November de 2014 17:53:27 Marco d'Itri escribió:
> On Nov 20, Sam Hartman  wrote:
> > The first issue (fstab now fatally blocks boot) is something the systemd
> > maintainers have considered (as I understand it) and rejected.
> 
> The behaviour of systemd will not be changed, but I have plans to add
> a fstab sanity check to preinst.

Just for my sanity of mind. Is this referring to entries in fstab that have 
the auto option (either directly or via defaults)?

Thanks

er Envite


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

Re: Bug#769907: general: non-sysvinit init systems are made of fail

[Marco d'Itri]

On Nov 20, Sam Hartman  wrote:

> The first issue (fstab now fatally blocks boot) is something the systemd
> maintainers have considered (as I understand it) and rejected.
The behaviour of systemd will not be changed, but I have plans to add 
a fstab sanity check to preinst.

-- 
ciao,
Marco


pgpZXi01wLyka.pgp
Description: PGP signature

Re: Bug#769907: general: non-sysvinit init systems are made of fail

[Russ Allbery]

Sam Hartman  writes:

> In that spirit.
> The first issue (fstab now fatally blocks boot) is something the systemd
> maintainers have considered (as I understand it) and rejected.
> I don't know that filing a bug that will be immediately wontfixed will
> be helpful.
> I don't think sending that issue to the TC is advised.

The suggestion that I made (I think in one of the OpenSSH bugs about this)
was that, during a transition from sysvinit to systemd, we could check for
any file systems listed in /etc/fstab but not currently mounted on the
system, and warn the administrator that mount points that are defined but
always fail will be handled differently under systemd.

-- 
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/87egsxepd5@hope.eyrie.org

Bug#769907: general: non-sysvinit init systems are made of fail

[Sam Hartman]

> "Didier" == Didier 'OdyX' Raboud  writes:

Didier> Steve's suggestions stands though: separated and actionable
Didier> bugs for these two issues filed on the corresponding
Didier> packages are way more helpful than a general "non-sysvinit
Didier> init systems are made of fail".

sure.
My assumption of what it means when someone files a general bug is that
they're hoping for help from all of us figuring out where the bug
belongs.

In that spirit.
The first issue (fstab now fatally blocks boot) is something the systemd
maintainers have considered (as I understand it) and rejected.
I don't know that filing a bug that will be immediately wontfixed will
be helpful.
I don't think sending that issue to the TC is advised.

The second issue seems more actionable.
I wonder if we can get a bit more detail so we can retitle and reassign.

In my case, I've found that with systemd I tend to get a lot less output
in some cases than I do with sysvinit, but I haven't figured out what is
going on well enough to produce something actionable so I didn't bother
trying.
If others are seeing that it's perhaps worth exploring.

--Sam


-- 
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/tslegsxzstn@mit.edu

Bug#769907: general: non-sysvinit init systems are made of fail

[Didier 'OdyX' Raboud]

Le jeudi, 20 novembre 2014, 12.06:45 Sam Hartman a écrit :
> > "Didier" == Didier 'OdyX' Raboud  writes:
> Didier> Systems cross-craded from Ubuntu to Debian are absolutely
> Didier> not supported, and I wouldn't be surprised if some of the
> Didier> issues you're seeing are in some way related to this.
> 
> I've seen both these issues on pure Debian systems.
> 
> And I do consider both of them likely to be significant problems on
> upgrades from wheezy.
> I've been burned by both of the identified issues on multiple systems.

Fair enough, and thanks for pointing this out. I also apologize to 
Michal for having jumped too rapidly to conclusions.

Steve's suggestions stands though: separated and actionable bugs for 
these two issues filed on the corresponding packages are way more 
helpful than a general "non-sysvinit init systems are made of fail".

Cheers,
OdyX


--
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/3920626.IYNqfL8Hhi@gyllingar

Bug#769907: general: non-sysvinit init systems are made of fail

[Sam Hartman]

> "Didier" == Didier 'OdyX' Raboud  writes:

Didier> Systems cross-craded from Ubuntu to Debian are absolutely
Didier> not supported, and I wouldn't be surprised if some of the
Didier> issues you're seeing are in some way related to this.

I've seen both these issues on pure Debian systems.

And I do consider both of them likely to be significant problems on
upgrades from wheezy.
I've been burned by both of the identified issues on multiple systems.


-- 
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/tslmw7lztqy@mit.edu

Re: Pre-Depends: init-system-helpers

[Tollef Fog Heen]

]] Bob Proulx 

> Russ Allbery wrote:
> > Bob Proulx writes:
> > > Maybe I am missing a better alternative?
> > 
> > update-rc.d  disable
> 
> No.  That is too late.  By the time you are disabling something it has
> already been installed and started in postinst scripts.  Using
> policy-rc.d is the only way to prevent unknown anythings from being
> enabled before installing.  That installation may be due to a
> dependency.  Think dnsmasq.  Also update-rc.d only configures the boot
> time configuration.  It doesn't affect things until you reboot.  It
> doesn't affect postinst scripts.  Using update-rc.d is not a solution.

Have your policy-rc.d call update-rc.d  disable too.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87wq6pbylt@xoog.err.no

Re: init system policy

[Jonas Smedegaard]

Quoting Matthias Klumpp (2014-11-20 17:15:50)
> 2014-11-20 16:12 GMT+01:00 Jonas Smedegaard :
> > Quoting Vincent Danjean (2014-11-20 14:25:59)
> >>   Hi,
> >>
> >> On 18/11/2014 18:36, Ansgar Burchardt wrote:
> >> > With systemd you can ship a default configuration in
> >> > /lib/systemd/system and administrators can override specific options,
> >> > for example:
> >> >
> >> > +---
> >> > | [Unit]
> >> > | Description=Some Helpful Description
> >> > | Documentation=man:minidlda(1)
> >> > |
> >> > | [Service]
> >> > | User=minidlda
> >> > | ExecStart=/usr/sbin/minidldad -S
> >> > +---[ /lib/systemd/system/minidlda.service ]
> >> >
> >> > Then an admin can override the entire file by writing his own
> >> > /etc/systemd/system/minidlda.service or only override specific settings:
> >> >
> >> > +---
> >> > | [Service]
> >> > | User=some-other-user
> >> > +---[ /etc/systemd/system/miniblda.service.d/user.conf ]
> >>
> >>   I did not know that. It is very interesting.
> >>
> >> But, is there a way to be notified at upgrade time that the system
> >> service file has been modified when there is local (partial or full)
> >> changes ?
> >
> > I was wondering the same.
> At least for the systemd-case, you can easily notice changes using the
> systemd-delta command:
>  $> systemd-delta --diff
> This will list all overrides and the differences in case something has 
> changed.

Thanks.  Sounds like only a diff between system-provided and 
sysadmin-overrided config, however: That might help for the latter part 
of the question - notify only when system service file is overridden 
locally (by suppressing notification if systemd-deta is empty).

How to do first part of the question - be notified with a diff between 
old versus new _effective_ config when a package update changes a system 
service file?

With conffiles, sysadmin can be notified on changes by simply changing 
whitespace to the conffile (as that invalidates md5sum).


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: init system policy

[Russ Allbery]

Jonas Smedegaard  writes:

> Seems to me this is a similar limitation as for config.d structures - as
> an example apache2 is now far more modular than in the past but I no
> longer as sysadmin get notified what exactly has changed when I upgrade
> a system with customizations, as I did in the past thanks to the
> monolithic configfile being a conffile.

There was some discussion about this a while back, and I vaguely remember
that systemd comes with a tool that will tell you exactly what you're
overriding.  I'm not sure if that work got all the way to producing a nice
Debian-aware tool or not.

Personally (and this is just a wishlist), I'd love to have functionality
similar to apt-listchanges that would (optionally) show me a report of
every change to any unit file that I've overridden on each upgrade.

-- 
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/87tx1tet03@hope.eyrie.org

Re: Pre-Depends: init-system-helpers

[Russ Allbery]

Bastien ROUCARIES  writes:
> Le 19 nov. 2014 21:33, "Russ Allbery"  a écrit :

>> Yes, absolutely.  Likewise for cron jobs, etc.  That's something that I
>> don't think we're doing a great job of right now, and really should
>> improve.

> Could lintian help here ?

Yes, although it's tricky.

If a package has only an init script, and that init script has a custom
action to do the right thing for log rotation, then running that with
service or /etc/init.d is actually okay.  But those are the patterns that
we should otherwise be wary of.

-- 
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/87y4r5et3p@hope.eyrie.org

Re: init system policy

[Matthias Klumpp]

2014-11-20 16:12 GMT+01:00 Jonas Smedegaard :
> Quoting Vincent Danjean (2014-11-20 14:25:59)
>>   Hi,
>>
>> On 18/11/2014 18:36, Ansgar Burchardt wrote:
>> > With systemd you can ship a default configuration in
>> > /lib/systemd/system and administrators can override specific options,
>> > for example:
>> >
>> > +---
>> > | [Unit]
>> > | Description=Some Helpful Description
>> > | Documentation=man:minidlda(1)
>> > |
>> > | [Service]
>> > | User=minidlda
>> > | ExecStart=/usr/sbin/minidldad -S
>> > +---[ /lib/systemd/system/minidlda.service ]
>> >
>> > Then an admin can override the entire file by writing his own
>> > /etc/systemd/system/minidlda.service or only override specific settings:
>> >
>> > +---
>> > | [Service]
>> > | User=some-other-user
>> > +---[ /etc/systemd/system/miniblda.service.d/user.conf ]
>>
>>   I did not know that. It is very interesting.
>>
>> But, is there a way to be notified at upgrade time that the system
>> service file has been modified when there is local (partial or full)
>> changes ?
>
> I was wondering the same.
At least for the systemd-case, you can easily notice changes using the
systemd-delta command:
 $> systemd-delta --diff
This will list all overrides and the differences in case something has changed.
Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
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/CAKNHny_YoFgcKTOY1d0BqobqoG8cG0XXw9nBj-B56efwCDR=a...@mail.gmail.com

Re: Cloudstack for Debian

[Thomas Goirand]

On 11/19/2014 11:40 PM, Martin Zobel-Helas wrote:
> Hi, 
> 
> On Wed Nov 19, 2014 at 14:55:51 +0100, Michael Meskes wrote:
>> Hi,
>>
>> Wido and I have been talking about bringing Cloudstack into Debian.
>> There is quite a bit of work involved because several dependencies are
>> not yet packaged.
>>
>> This obviously brings up the question if anyone else on either of the
>> developer lists is interested in working on it? Please raise your hands.
>>
>> Also, as a bonus question to the Debian folks, should we try
>> establishing a cloudstack packaging group or do we push the effort into
>> the java packaging group?
> 
> Or do we use debian-cloud@lists.d.o for that?

Please don't. This list is for general cloud stuff, like cloud-init,
which are of interest for everyone. I don't want to receive bug reports
for cloud-stack in my mail, for example.

Cheers,

Thomas


-- 
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/546e12f9.2070...@debian.org

Re: init system policy

[Jonas Smedegaard]

Quoting Vincent Danjean (2014-11-20 14:25:59)
>   Hi,
> 
> On 18/11/2014 18:36, Ansgar Burchardt wrote:
> > With systemd you can ship a default configuration in
> > /lib/systemd/system and administrators can override specific options,
> > for example:
> > 
> > +---
> > | [Unit]
> > | Description=Some Helpful Description
> > | Documentation=man:minidlda(1)
> > |
> > | [Service]
> > | User=minidlda
> > | ExecStart=/usr/sbin/minidldad -S
> > +---[ /lib/systemd/system/minidlda.service ]
> > 
> > Then an admin can override the entire file by writing his own
> > /etc/systemd/system/minidlda.service or only override specific settings:
> > 
> > +---
> > | [Service]
> > | User=some-other-user
> > +---[ /etc/systemd/system/miniblda.service.d/user.conf ]
> 
>   I did not know that. It is very interesting.
> 
> But, is there a way to be notified at upgrade time that the system 
> service file has been modified when there is local (partial or full) 
> changes ?

I was wondering the same.

Seems to me this is a similar limitation as for config.d structures - as 
an example apache2 is now far more modular than in the past but I no 
longer as sysadmin get notified what exactly has changed when I upgrade 
a system with customizations, as I did in the past thanks to the 
monolithic configfile being a conffile.


>   As a small workaround, I think I will put symlinks such as
> /lib/systemd/[perhaps sub-directory, to check] -> /etc/systemd/lib/[...]
>   This way, systemd config files and their changes will be, at least,
> recorded by etckeeper.

If you mean a symlink, then I suspect etckeeper will only track it as 
such - i.e. only really track the existence, not its content.

If you mean a hardlink, then I suspect it won't be preserved as such on 
package updates.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#770337: ITP: s-el -- The long lost Emacs string manipulation library

[Hajime MIZUNO]

Package: wnpp
Severity: wishlist
Owner: Hajime Mizuno 
X-Debbugs-CC: debian-devel@lists.debian.org, debian-emac...@lists.debian.org

* Package name: s-el
  Version : 1.9.0
  Upstream Author : Magnar Sveen 
* URL : https://github.com/magnars/s.el
* License : GPL-3+
  Programming Lang: elisp
  Description : The long lost Emacs string manipulation library

s.el is API library of manipulate character string for Emacs Lisp.
For example, you can easily perform truncate, padding, concatenate,
remove prefix/suffix, tweak whitespace, and more functions.


-- 
Regards,

Hajime MIZUNO 
Key fingerprint = 9B07 B934 B70C 8482 8892  E276 502E 0713 4EEF 9E8D


-- 
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/cahkmweorujhsejbx63hu0e8cmznkvldk2x6eup+twzqkmew...@mail.gmail.com

Re: Re: init system policy

[David Weinehall]

On Wed, Nov 19, 2014 at 02:51:57PM +, Ian Jackson wrote:
> Laurent Bigonville writes ("Re: Re: init system policy"):
> > Matthias Urlichs wrote:
> > > See "man 5 sudoers" for details.
> > 
> > You probably want to use "runuser" that has been introduced recently in
> > utils-linux
> 
> Or `really' from chiark-really (from chiark-utils).

Considering that util-linux is Priority: required while
chiark-really is Priority: extra I'd suggest that runuser would be
a more sensible recommendation.  Still, I love the package description
for really :)


Kind regards, David
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
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/20141120142109.gh8...@hirohito.acc.umu.se

Re: Re: init system policy

[Eric Valette]

>   I did not know that. It is very interesting.
>
> But, is there a way to be notified at upgrade time that the
> system service file has been modified when there is local
> (partial or full) changes ?
>   As a small workaround, I think I will put symlinks such as
> /lib/systemd/[perhaps sub-directory, to check] -> /etc/systemd/lib/[...]
>   This way, systemd config files and their changes will be, at least,
> recorded by etckeeper.

Non sure you want to automate that. For minidlna, there are several conf
files that can be edited.

more minidlna.conffiles
/etc/minidlna.conf
/etc/init.d/minidlna
/etc/default/minidlna


Some are mostly relevant to the init system itself (default one), some
to minidlna daemon itself. When you start modifying the daemon config
you may modify all the files and some have a syntax that cannot be
changed. If your restart the daemon after modifying the unit config file
and later modify its own managed config file, unless the daemon monitors
the config file chnages itself, you wil have to restart.

-- eric



-- 
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/546df440.9010...@free.fr

Re: Cloudstack for Debian

[Wido den Hollander]

On 11/19/2014 05:00 PM, Emmanuel Bourg wrote:
> Le 19/11/2014 14:55, Michael Meskes a écrit :
> 
>> Also, as a bonus question to the Debian folks, should we try
>> establishing a cloudstack packaging group or do we push the effort into
>> the java packaging group?
> 
> Cloudstack is more than welcome under the pkg-java umbrella if that
> helps you getting started quickly. We'll be happy to help you with the
> Java packaging tools.
> 

Great! I'm not an expert at packaging for Debian. I created the
packaging because we needed it, but it's not perfect.

The main problem now is that we include all kinds of JAR files in our
packages which isn't ideal.

Wido

> Emmanuel Bourg
> 
> 


-- 
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/546de76d.4020...@widodh.nl

Re: init system policy

[Vincent Danjean]

  Hi,

On 18/11/2014 18:36, Ansgar Burchardt wrote:
> With systemd you can ship a default configuration in
> /lib/systemd/system and administrators can override specific options,
> for example:
> 
> +---
> | [Unit]
> | Description=Some Helpful Description
> | Documentation=man:minidlda(1)
> |
> | [Service]
> | User=minidlda
> | ExecStart=/usr/sbin/minidldad -S
> +---[ /lib/systemd/system/minidlda.service ]
> 
> Then an admin can override the entire file by writing his own
> /etc/systemd/system/minidlda.service or only override specific settings:
> 
> +---
> | [Service]
> | User=some-other-user
> +---[ /etc/systemd/system/miniblda.service.d/user.conf ]

  I did not know that. It is very interesting.

But, is there a way to be notified at upgrade time that the
system service file has been modified when there is local
(partial or full) changes ?
  As a small workaround, I think I will put symlinks such as
/lib/systemd/[perhaps sub-directory, to check] -> /etc/systemd/lib/[...]
  This way, systemd config files and their changes will be, at least,
recorded by etckeeper.

  Regards,
Vincent

> Ansgar
> 
> 


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
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/546debe7.7060...@free.fr

Re: policy regarding redistributable binary files in upstream tarballs

[Jonas Smedegaard]

Quoting Ben Finney (2014-11-20 06:14:55)
> Paul Wise  writes:
>
>> Upstreams that want to cater to end-users can distribute prebuilt 
>> binary packages separately, in separate branches, zip/tarballs, 
>> binary packages or "app" installers.
>
> You'll get no disagreement from me on that.
>
> But a growing number of upstreams disagree, so those upstreams are 
> likely to be actively opposed to your recommendation to patches which 
> remove non-source files from the VCS repository.

Thanks for your (esp. earlier in the thread) excellent explanation of 
the situation.  I agree with that!


> How to resolve that? I don't know. But it will entail a change of 
> workflow, not merely patches submitted.

What I have done recently is suggest upstream to at least use a separate 
branch in the VCS for developer-facing and user-facing parts.

I imagine that helps my message being conceived more as a "here's how to 
improve your current practice" than a "stop doing what is working for 
you now."

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#770288: ITP: python-tasklib -- Task Warrior database interaction

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-tasklib
  Version : 0.5.0
  Upstream Author : Rob Golding 
* URL : https://github.com/robgolding63/tasklib
* License : BSD-3-clause
  Programming Lang: Python
  Description : Task Warrior database interaction

 Tasklib is a Python library for interacting with a taskwarrior databases,
 using a queryset API similar to that of Django's ORM. Supports taskwarrior
 2.1.x and above. Older versions of taskwarrior are untested and may not work.

This is a dependency for OpenStack Fuel.


-- 
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/20141120085043.14827.16654.report...@buzig.gplhost.com

Re: Pre-Depends: init-system-helpers

[Bastien ROUCARIES]

Le 19 nov. 2014 21:33, "Russ Allbery"  a écrit :
>
> Jonas Smedegaard  writes:
>
> > Which implies, I believe, that any other way of starting daemons should
> > also respect policy-rc.d if it can lead to automated triggering.
>
> > Example: if a logrotate snippet uses "update-rc.d force-restart ..."
> > then suppressing that deamon with policy-rc.d will be circumvented when
> > cron triggers log rotation.
>
> Yes, absolutely.  Likewise for cron jobs, etc.  That's something that I
> don't think we're doing a great job of right now, and really should
> improve.

Could lintian help here ?
> --
> 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/87bno3hqwm@hope.eyrie.org
>