Re: Switching to sysvinit-core fails miserably in buster/sid
On Wed, 2017-10-25 at 18:03 +, Felipe Sateler wrote: > Mea Culpa. This was a bug in the "defaults-disabled" implementation. I > have just uploaded a fixed version. Hi, when trying to follow which patches are applied to sysvinit, the git link given in the package page, https://packages.qa.debian.org/s/sysvinit.html is not up to date: https://anonscm.debian.org/cgit/collab-maint/sysvinit.git Latest entry there is from February 2017. Where is the recent git repo? Thanks!
Re: Switching to sysvinit-core fails miserably in buster/sid
On Thu, 26 Oct 2017 at 09:29:18 +0200, Svante Signell wrote: > Hi, when trying to follow which patches are applied to sysvinit, the git link > given in the package page, https://packages.qa.debian.org/s/sysvinit.html is > not > up to date: https://anonscm.debian.org/cgit/collab-maint/sysvinit.git > Latest entry there is from February 2017. Where is the recent git repo? update-rc.d is now built from init-system-helpers, not sysvinit (because the same script is used for multiple init systems). This bug was found and fixed there, not in sysvinit. sysvinit itself had its most recent maintainer upload in 2015, so it isn't surprising if nothing has changed in git recently. Patches corresponding to each subsequent NMU should be available in the BTS. smcv
Bug#879812: ITP: sasview -- Small Angle Scattering Analysis
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
* Package name: sasview
Version : 4.1.2
Upstream Author : Mathieu Doucet et al
* URL : http://www.sasview.org/
* License : BSD
Programming Lang: Python2
Description : Small Angle Scattering Analysis
SasView is a Small Angle Scattering Analysis Software Package,
originally developed as part of the NSF DANSE project under the name
SansView, now managed by an international collaboration of facilities.
.
SasView is software for the analysis of Small-Angle Scattering (SAS)
data.
.
It fits analytic functions describing different types of material
microstructure to experimental data in order to determine the shape,
size and degree of ordering.
.
SasView also includes tools for calculating scattering length
densities, slit sizes, resolution, fringe thicknesses/d-spacings, the
(Porod) invariant ('total scattering'), and distance distribution
functions.
This software is routinely used in scientific institutions to model
and interpret small angle scattering data (SANS,SAXS). A key point of
value is the "marketplace" of SAS models at
http://marketplace.sasview.org/ contributed by the community.
Sasview has been developed as collaboration of international facilities,
including www.diamond.ac.uk, www.umd.edu, www.tnw.tudelft.nl,
www.ansto.gov.au, www.ill.eu, ess-scandinavia.eu, www.isis.stfc.ac.uk,
neutrons.ornl.gov, www.nist.gov and www.utk.edu.
It has python package prequisites:
pylint
unittest-xml-reporting==1.10.0
pyparsing==1.5.5
html5lib==0.95
reportlab==2.5
lxml==2.3
#PIL==1.1.7
periodictable==1.3.0
bumps==0.7.5.9
numpy>=1.7.1
scipy>=0.18.0
# wx==2.8.12.1
# matplotlib==1.1.0
xhtml2pdf==0.0.6
sphinx==1.2.1
h5py==2.5
pyopencl==2015.1
Some are not yet packaged, and should be considered part of this ITP.
Packaging will be maintained under the Debian Science team.
Re: Switching to sysvinit-core fails miserably in buster/sid
On 10/25/2017 08:03 PM, Felipe Sateler wrote: > Mea Culpa. This was a bug in the "defaults-disabled" implementation. I > have just uploaded a fixed version. > > Thanks for reporting. Don't sweat it, big thanks for your quick response from me, too. signature.asc Description: OpenPGP digital signature
Bug#879817: ITP: ayatana-indicator-printers -- Ayatana Indicator showing active print jobs
Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: ayatana-indicator-printers Version : 0.1.8 Upstream Author : Mike Gabriel Lars Uebernickel * URL : https://github.com/AyatanaIndicators/ayatana-indicator-printers * License : GPL-2 Programming Lang: C Description : Ayatana Indicator showing active print jobs This Ayatana Indicator is designed to let you view and control active print jobs. . Use an indicator plugin for your desktop environment or a desktop environment that natively supports indicators to provide this indicator to the user. . This package will be maintained under the umbrella of the pkg-ayatana team.
Bug#879824: ITP: kronosnet -- Multipoint-to-multipoint VPN implementation
Package: wnpp Severity: wishlist Owner: =?utf-8?q?Ferenc_W=C3=A1gner?= * Package name: kronosnet Version : 1.0 to be released this year Upstream Author : Fabio M. Di Nitto * URL : http://www.kronosnet.org * License : LGPL 2.1+ (applications GPL 2+) Programming Lang: C Description : Multipoint-to-multipoint VPN implementation VPN library using UDP/SCTP technology focusing on High-Availability. Detects connectivity issues via link heartbeat and performs fast failover. Provides plugin interfaces for encryption, compression and switching. Carries arbitraty data types, not just Ethernet. Can be used internally or exposed to the host via TAP interfaces. This is a dependency of the upcoming Corosync major version 3, thus I'm bringing it under the Debian HA Team umbrella.
Bug#879828: ITP: haskell-cryptonite-conduit -- Conduit bridge for cryptonite
Package: wnpp Severity: wishlist Owner: Ilias Tsitsimpis * Package name: haskell-cryptonite-conduit Version : 0.2.0 Upstream Author : Vincent Hanquez * URL : https://hackage.haskell.org/package/cryptonite-conduit * License : BSD-3-clause Programming Lang: Haskell Description : Conduit bridge for cryptonite This package provides a conduit version for hash and HMAC. In the feature, it could be extended to also provide cipher conduits. This package is required for latest upstream version of haskell-stack. This package will be maintained under the umbrella of the Debian Haskell Group.
Bug#879829: ITP: bumps -- data fitting and Bayesian uncertainty modeling for inverse problems
Package: wnpp Severity: wishlist Owner: Drew Parsons * Package name: bumps Version : 0.7.6 Upstream Author : Paul Kienzle * URL : https://github.com/bumps/bumps * License : BSD Programming Lang: Python Description : data fitting and Bayesian uncertainty modeling for inverse problems Bumps is a set of routines for curve fitting and uncertainty analysis from a Bayesian perspective. In addition to traditional optimizers which search for the best minimum they can find in the search space, bumps provides uncertainty analysis which explores all viable minima and finds confidence intervals on the parameters based on uncertainty in the measured values. Bumps has been used for systems of up to 100 parameters with tight constraints on the parameters. Full uncertainty analysis requires hundreds of thousands of function evaluations, which is only feasible for cheap functions, systems with many processors, or lots of patience. . Bumps includes several traditional local optimizers such as Nelder-Mead simplex, BFGS and differential evolution. Bumps uncertainty analysis uses Markov chain Monte Carlo to explore the parameter space. Although it was created for curve fitting problems, Bumps can explore any probability density function, such as those defined by PyMC. In particular, the bumps uncertainty analysis works well with correlated parameters. . Bumps can be used as a library within your own applications, or as a framework for fitting, complete with a graphical user interface to manage your models. bumps is a prerequisite for SasView, ITP#879812
Bug#879831: ITP: haskell-data-clist -- Simple functional ring type
Package: wnpp Severity: wishlist Owner: Ilias Tsitsimpis * Package name: haskell-data-clist Version : 0.1.2.0 Upstream Author : John Van Enk * URL : https://hackage.haskell.org/package/data-clist * License : BSD-3-clause Programming Lang: Haskell Description : Simple functional ring type Simple functional bidirectional ring type. . Given that the ring terminiology clashes with certain mathematical branches, we're using the term CList or CircularList instead. This package is required for latest upstream version of haskell-brick. This package will be maintained under the umbrella of the Debian Haskell Group.
Bug#879833: ITP: periodictable -- a periodic table of the elements
Package: wnpp Severity: wishlist Owner: Drew Parsons * Package name: periodictable Version : 1.5.0 Upstream Author : Paul Kienzle * URL : http://www.reflectometry.org/danse/elements.html * License : Public Domain Programming Lang: Python Description : a periodic table of the elements This package provides a periodic table of the elements with support for mass, density and xray/neutron scattering information. . Masses, densities and natural abundances come from the NIST Physics Laboratory, but do not represent a critical evaluation by NIST scientists. . Neutron scattering calculations use values collected by the Atomic Institute of the Austrian Universities. These values do corresponding to those from other packages, though there are some differences depending to the tables used. Bound coherent neutron scattering for gold in particular is significantly different from older value: 7.63(6) as measured in 1974 compared to 7.90(7) as measured in 1990. . X-ray scattering calculations use a combination of empirical and theoretical values from the LBL Center for X-ray Optics. These values differ from those given in other sources such as the International Tables for Crystallography, Volume C, and so may give different results from other packages. This python package is a prequisite for SasView (ITP#879812) It will be maintained under Debian Science.
Bug#879834: ITP: haskell-here -- Here documents and interpolated strings via quasiquotation
Package: wnpp Severity: wishlist Owner: Ilias Tsitsimpis * Package name: haskell-here Version : 1.2.11 Upstream Author : Taylor M. Hedberg * URL : https://hackage.haskell.org/package/here * License : BSD-3-clause Programming Lang: Haskell Description : Here documents and interpolated strings via quasiquotation This package is required for latest upstream version of haskell-hledger. This package will be maintained under the umbrella of the Debian Haskell Group.
Bug#879837: ITP: haskell-uri-bytestring-aeson -- Aeson instances for URI Bytestring
Package: wnpp Severity: wishlist Owner: Ilias Tsitsimpis * Package name: haskell-uri-bytestring-aeson Version : 0.1.0.2 Upstream Author : Simon Hafner * URL : https://hackage.haskell.org/package/uri-bytestring-aeson * License : BSD-3-clause Programming Lang: Haskell Description : Aeson instances for URI Bytestring This package is required for latest upstream version of haskell-hoauth2. This package will be maintained under the umbrella of the Debian Haskell Group.
Bug#879838: ITP: haskell-annotated-wl-pprint -- The Wadler/Leijen Pretty Printer, with annotation support
Package: wnpp Severity: wishlist Owner: Ilias Tsitsimpis * Package name: haskell-annotated-wl-pprint Version : 0.7.0 Upstream Author : Daan Leijen, David Raymond Christiansen * URL : https://hackage.haskell.org/package/annotated-wl-pprint * License : BSD-3-clause Programming Lang: Haskell Description : The Wadler/Leijen Pretty Printer, with annotation support This is a modified version of wl-pprint, which was based on Wadler's paper "A Prettier Printer". This version allows the library user to annotate the text with semantic information, which can later be rendered in a variety of ways. This package is required for latest upstream version of haskell-stack. This package will be maintained under the umbrella of the Debian Haskell Group.
Bug#879839: ITP: xhtml2pdf -- A library for converting HTML into PDFs using ReportLab
Package: wnpp Severity: wishlist Owner: Drew Parsons * Package name: xhtml2pdf Version : 0.2b1 Upstream Author : Dirk Holtwick * URL : https://github.com/xhtml2pdf/xhtml2pdf * License : Apache-2.0 Programming Lang: Python Description : A library for converting HTML into PDFs using ReportLab xhtml2pdf is a html2pdf converter using the ReportLab Toolkit, the HTML5lib and pyPdf. It supports HTML 5 and CSS 2.1 (and some of CSS 3). It is completely written in pure Python so it is platform independent. . The main benefit of this tool that a user with Web skills like HTML and CSS is able to generate PDF templates very quickly without learning new technologies. This package is a prerequisite for SasView (ITP#879812) It will be maintained under Debian Science.
Bug#879840: ITP: seqtools -- visualising sequence alignments
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: seqtools Version : 4.44.1 Upstream Author : Eric Sonnhammer, Richard Durbin, Jean Thierry-Mieg, Ed Griffiths, Roy Storey, Malcolm Hinsley, Gemma Barson * URL : http://www.sanger.ac.uk/science/tools/seqtools * License : GPL Programming Lang: C++ Description : visualising sequence alignments The SeqTools package contains three tools for visualising sequence alignments: Blixem, Dotter and Belvu. Remark: This package will be maintained by the Debian Med team at https://anonscm.debian.org/git/debian-med/seqtools.git It replaces the tools acedb-other-belvu and acedb-other-dotter and provides a new tool blixem.
Bug#879841: ITP: haskell-bitarray -- Mutable and immutable bit arrays
Package: wnpp Severity: wishlist Owner: Ilias Tsitsimpis * Package name: haskell-bitarray Version : 0.0.1.1 Upstream Author : Balazs Komuves * URL : https://hackage.haskell.org/package/bitarray * License : BSD-3-clause Programming Lang: Haskell Description : Mutable and immutable bit arrays This package provides mutable and immutable bit arrays implemented as packed arrays of 64 bit words. It provides a pure interface as well as monadic interfaces for the IO and ST monad. This package is required for latest upstream version of haskell-stack. This package will be maintained under the umbrella of the Debian Haskell Group.
Bug#879843: ITP: haskell-getopt-generics -- Create command line interfaces with ease
Package: wnpp Severity: wishlist Owner: Ilias Tsitsimpis * Package name: haskell-getopt-generics Version : 0.13.0.1 Upstream Author : Linh Nguyen, Sönke Hahn * URL : https://hackage.haskell.org/package/getopt-generics * License : BSD-3-clause Programming Lang: Haskell Description : Create command line interfaces with ease This package is required for latest upstream version of haskell-stack. This package will be maintained under the umbrella of the Debian Haskell Group.
Bug#879842: ITP: haskell-echo -- A cross-platform, cross-console way to handle echoing terminal input
Package: wnpp Severity: wishlist Owner: Ilias Tsitsimpis * Package name: haskell-echo Version : 0.1.3 Upstream Author : Ryan Scott * URL : https://hackage.haskell.org/package/echo * License : BSD-3-clause Programming Lang: Haskell Description : A cross-platform, cross-console way to handle echoing terminal input The base library exposes the hGetEcho and hSetEcho functions for querying and setting echo status, but unfortunately, neither function works with MinTTY consoles on Windows. This is a serious issue, since hGetEcho and hSetEcho are often used to disable input echoing when a program prompts for a password, so many programs will reveal your password as you type it on MinTTY! . This library provides an alternative interface which works with both MinTTY and other consoles. This package is required for latest upstream version of haskell-stack. This package will be maintained under the umbrella of the Debian Haskell Group.
Bug#879844: ITP: haskell-pid1 -- Signal handling and orphan reaping for Unix PID1 init processes
Package: wnpp Severity: wishlist Owner: Ilias Tsitsimpis * Package name: haskell-pid1 Version : 0.1.2.0 Upstream Author : Michael Snoyman * URL : https://hackage.haskell.org/package/pid1 * License : Expat Programming Lang: Haskell Description : Signal handling and orphan reaping for Unix PID1 init processes Do signal handling and orphan reaping for Unix PID1 init processes. . This provides a Haskell library, and an executable based on that library, for initializing signal handlers, spawning and child process, and reaping orphan processes. These are the responsibilities that must be fulfilled by the initial process in a Unix system, and in particular comes up when running Docker containers. . This library/executable will automatically detect if it is run as some process besides PID1 and, if so, use a straightforward exec system call instead. This package is required for latest upstream version of haskell-stack. This package will be maintained under the umbrella of the Debian Haskell Group.
Bug#879846: ITP: haskell-text-metrics -- Calculate various string metrics efficiently
Package: wnpp Severity: wishlist Owner: Ilias Tsitsimpis * Package name: haskell-text-metrics Version : 0.3.0 Upstream Author : Mark Karpov * URL : https://hackage.haskell.org/package/text-metrics * License : BSD-3-clause Programming Lang: Haskell Description : Calculate various string metrics efficiently The library provides efficient implementations of various strings metric algorithms. It works with strict Text values. . The current version of the package implements: . * Levenshtein distance * Normalized Levenshtein distance * Damerau-Levenshtein distance * Normalized Damerau-Levenshtein distance * Hamming distance * Jaro distance * Jaro-Winkler distance * Overlap coefficient * Jaccard similarity coefficient This package is required for latest upstream version of haskell-stack. This package will be maintained under the umbrella of the Debian Haskell Group.
Bug#879847: ITP: haskell-unicode-transforms -- Fast Unicode 9.0 normalization in Haskell
Package: wnpp Severity: wishlist Owner: Ilias Tsitsimpis * Package name: haskell-unicode-transforms Version : 0.3.3 Upstream Author : Harendra Kumar * URL : https://hackage.haskell.org/package/unicode-transforms * License : BSD-3-clause Programming Lang: Haskell Description : Fast Unicode 9.0 normalization in Haskell Unicode characters with adornments (e.g. Á) can be represented in two different forms, as a single composed character (U+00C1 = Á) or as multiple decomposed characters (U+0041(A) U+0301( ́ ) = Á). They are differently encoded byte sequences but for humans they have exactly the same visual appearance. . A regular byte comparison may tell that two strings are different even though they might be equivalent. We need to convert both the strings in a normalized form using the Unicode Character Database before we can compare them for equivalence . This library implements fast Unicode 9.0 normalization in Haskell (NFC, NFKC, NFD, NFKD). This package is required for latest upstream version of haskell-stack. This package will be maintained under the umbrella of the Debian Haskell Group.
Re: Bug#879839: ITP: xhtml2pdf -- A library for converting HTML into PDFs using ReportLab
Hi Drew, many thanks for your ITP! Note, that xhtml2pdf is known also as "pisa" - nobody so far could explain to me, why there is this upstream name confusion. And pisa is in Debian: https://tracker.debian.org/pkg/pisa Unfortunately, pisa is not in a good state. It is not in testing, and did neither made it to stretch nor jessie. Python 3 support is needed, too. Please feel free, to takeover the package or maintain it within the Python modules team. I'm also still interested in having the package in Debian, because of trac-wikiprint, but did not have the time nor energy to take care of the package. I set Hugo in Cc, because he was also interested in helping. Cheers
Re: Let's enable AppArmor by default (why not?)
Hi, intrigeri: > tl;dr: I hereby propose we enable AppArmor by default in testing/sid, > and decide one year later if we want to keep it this way in the > Buster release. Thanks a lot to everyone who participated on this thread, tried AppArmor and reported bugs, or expressed support/interest privately! Summary of the discussion: no strong objection was raised; quite a few potential issues were mentioned; the most serious ones were either resolved already, or in good way to be resolved in the next 2 weeks. So, my understanding is that we have a broad consensus and can start the proposed experiment. I need advice from you folks on one specific matter, see below. > 1. Enable AppArmor by default in testing/sid as soon as feasible in >the Buster cycle. >I can think of several possible ways to do it but for now I'd >rather focus on the "do we want to do it at all" conversation. It's now time to discuss the "how" aspect. Enabling AppArmor by default requires two changes: 1. enabling the LSM in Linux: problem solved, Ben Hutchings agreed we should do this in src:linux, at least for the time being; 2. installing the apparmor package by default: it ships the bits of code that load AppArmor policy during boot and some shared bits of policy that most other AppArmor profiles rely upon. This email is about (2). There are two aspects to it. For new installations, it seems that making the apparmor package "Priority: standard" is the way to go. I've asked debian-boot@'s opinion about it [priority:standard?] but the rest of our developers community is of course welcome to comment as well. For upgrades it seems much more complicated. Ideally I would like the apparmor package to be installed automatically: - on testing/sid upgrades, during the Buster dev cycle: this would greatly increase the value of the "enable AppArmor by default for a while" experiment as we would get lots more data to reason about when the time comes; - during Stretch to Buster upgrades: this seems necessary so every user gets the AppArmor benefits, regardless of when they installed their system initially. I also want to provide easy means for users to opt-out from the experiment. I've requested advice on this topic from a few fellow Debian people and the conclusion seems to be: - I was told essentially "we generally don't do that in Debian" by a few people who suggested me asking this mailing list. I don't understand the rationale though — during system upgrades we do change the distro behavior in many ways: we add new features, we enable new security measures, we switch init systems, we switch from MySQL to MariaDB and all sort of things — so it's not obvious to me why doing the same to enable a security system like AppArmor would be a Bad Thing™. Is the concern specifically about doing so by pulling a new package in? Or is it specifically about enabling a LSM that was previously disabled? (Any such big change brings a risk of introducing regressions, so the underlying questions seem to be "is the risk worth it? is the risk well managed?") - We have no better option to achieve that than having another package, that's already installed by default, add a "Recommends: apparmor". This feels artificial and rather ugly, but it might be the only option. I don't know which other package would be the most suitable to add this dependency. Any suggestion? Any other idea? I'd love to read your thoughts about this. Let's discuss it. [priority:standard?] https://bugs.debian.org/879590#25 Cheers, -- intrigeri
Re: Let's enable AppArmor by default (why not?)
Hi Neal & others, Neal Gompa: > I was recently pointed to the thread going on debian-devel about > enabling AppArmor LSM in Debian, and as I read through your proposal, > I felt it should be warranted to point out a few things in regards to > the SELinux comparison: Thanks a lot for your carefully worded and extremely well sourced email! I've already learned quite a few interesting things. > intrigeri wrote: >> Why AppArmor and not SELinux? >> - >> >> SELinux is another LSM that tackles similar problems. [...] >> * Enabled by default in RHEL so in theory a great number of sysadmins >> are at ease with it (see below why reality may not match this). > It's also important to note that it is also enabled by default in > Fedora, which is the upstream for RHEL. Sure. I didn't mention it because I don't see this as very relevant in the context of this discussion: it's a fact that many sysadmins active in Debian have to use RHEL/CentOS at work, but I doubt many Debian people are this much exposed to Fedora, so I don't think it's a good source of pre-existing SELinux expertise in Debian. > I do know of users of SELinux in Debian and Ubuntu, though they often > fork from refpolicy or fedora-selinux the bits they want to use and > install it on top of the current refpolicy offered in Debian. Interesting. It's good to know there are such options to use SELinux on Debian :) It also says something that I'm inclined to interpret as "the SELinux policy in Debian is not ready for prime-time". I'd be glad to be wrong though! >> * Writing, maintaining, auditing and debugging SELinux policy >> requires grasping a complex conceptual model; I am told this is not >> as easy as doing the same with AppArmor. > This is not really true. While it is true that the conceptual model is > more complex, the tooling for doing all the regular work with SELinux > is great. In many cases, the tools can analyze what's happened and > suggest a course of action about how to fix it. If it looks like a > bug, they suggest filing one with the vendor (in my case, when weird > things happen with the SELinux policy in Fedora, bugs get filed on > selinux-policy with the information from setroubleshoot so that things > can get fixed). This sounds great UX; it makes me wish to try it out and draw inspiration from it to improve AppArmor's UX too. Thanks for sharing. > As for the complexity of making policies and policy modules, I've > written a few policy modules, and they're not that bad. You can make > some pretty simple policies if you don't want to expose any > administrative tunables. That said, even with the tunables, it's not > that bad. > For example, the container-selinux policy module is pretty easy to > understand: https://github.com/projectatomic/container-selinux > The refpolicy documentation is pretty comprehensive too: > http://oss.tresys.com/docs/refpolicy/api/ I had a quick look and I agree: it's not that bad. Still feels much scarier than AppArmor policy to me, but I'm clearly not the right person to judge these days :) >> * As far as I could understand when chatting with sysadmins of Red >> Hat systems, this has resulted in a culture where many users got >> used to disable SELinux entirely on their systems, instead of >> trying to fix the buggy policy. > Back in the RHEL 5 days, this is definitely true. And if many of of > the Red Hat sysadmins you've talked to primarily maintain RHEL 5 > systems (which is not unlikely), then it makes sense. Back in the RHEL > 5 days (circa 2007), the tooling was very primitive, and for the most > part, the troubleshooting tools didn't exist. > Today in Fedora and RHEL 7, the tooling is very advanced, and in > almost every case where I've hit AVC denials in SELinux, > setroubleshoot has given me very useful information including > suggested course of actions to actually fix it locally. OK, this does explain things. It's sad that this culture has been created in the first place — changing users' habits is hard: the sysadmins I'm talking about kept "disable SELinux" in their post-installation checklist and have no clue that RHEL 7 solved all these problems. I suspect they'll need many more years to realize they could change their habits. I'll tell them about it! Now, my point is not very relevant in the context of the Debian discussion: hopefully not many Debian users are affected by this "always disable SELinux" culture. >> I've seen the opposite happen with >> AppArmor, which is good: for example, pretty often bug reporters to >> the Debian BTS document themselves how they could workaround the >> problem locally *without* turning AppArmor off. Looking at open >> bugs in the BTS against src:refpolicy, this seems to happen very >> rarely for SELinux, so I wonder if it would be realistic to ship >> Debian with SELinux enforced by default and have our community >> support it. I think this was not contested. >> * https://wiki.deb
Re: I'm not MIA
On Wed, 25 Oct 2017 08:40:44 +0200, Adam Borowski wrote: >Thus, I believe Norbert's pings all ended up silently shoved into "spam" >then deleted. I have had cases of Mails to Gmail accepted by Gmail and then totally silently dropped, not even delivered into the recipient's spam folder. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Bug#879877: ITP: olivetti-mode -- simple Emacs minor mode for a nice writing environment
Package: wnpp Severity: wishlist Owner: Nicholas D Steeves * Package name: olivetti-mode Version : 1.5.8 Upstream Author : Paul Rankin * URL : https://github.com/rnkn/olivetti * License : GPL-3+ Programming Lang: elisp Description : simple Emacs minor mode for a nice writing environment Like the famous typewriter, Olivetti mode let's you focus on writing rather than on the interface. . Features: * Set a desired text body width to automatically resize window margins to keep the text comfortably in the middle of the window. . * Text body width can be the number of characters (an integer) or a fraction of the window width (a float between 0.0 and 1.0). . * Interactively change body width with: olivetti-shrink C-c [ [ [ ... olivetti-expand C-c ] ] ] ... olivetti-set-width C-c \ . * If olivetti-body-width is an integer, the text body width will scale with use of text-scale-mode, whereas if a fraction (float) then the text body width will remain at that fraction. . * Optionally remember the state of visual-line-mode on entry and recall its state on exit. . * Optionally hide the mode-line for distraction-free writing. This package is useful for anyone who uses emacs fullscreen, to reduce distractions while keeping the blocks of text centered and the lines short; this increases reading speed, because the eye needs to saccade less. In comparison to writeroom-mode, which needs to be renamed upstream before it can be uploaded to the archive, olivetti is somewhat more difficult to configure; however, it has enhanced on-the-fly configuration. I plan to maintain it as part of the Emacs addons team, and I will need a sponsor. Regards, Nicholas
Re: Let's enable AppArmor by default (why not?)
On Thu, Oct 26, 2017 at 1:49 PM, intrigeri wrote: > Hi Neal & others, > > Neal Gompa: >> I was recently pointed to the thread going on debian-devel about >> enabling AppArmor LSM in Debian, and as I read through your proposal, >> I felt it should be warranted to point out a few things in regards to >> the SELinux comparison: > > Thanks a lot for your carefully worded and extremely well sourced > email! I've already learned quite a few interesting things. > >> intrigeri wrote: >>> Why AppArmor and not SELinux? >>> - >>> >>> SELinux is another LSM that tackles similar problems. > > [...] > >>> * Enabled by default in RHEL so in theory a great number of sysadmins >>> are at ease with it (see below why reality may not match this). > >> It's also important to note that it is also enabled by default in >> Fedora, which is the upstream for RHEL. > > Sure. I didn't mention it because I don't see this as very relevant in > the context of this discussion: it's a fact that many sysadmins active > in Debian have to use RHEL/CentOS at work, but I doubt many Debian > people are this much exposed to Fedora, so I don't think it's a good > source of pre-existing SELinux expertise in Debian. > >> I do know of users of SELinux in Debian and Ubuntu, though they often >> fork from refpolicy or fedora-selinux the bits they want to use and >> install it on top of the current refpolicy offered in Debian. > > Interesting. It's good to know there are such options to use SELinux > on Debian :) It also says something that I'm inclined to interpret as > "the SELinux policy in Debian is not ready for prime-time". I'd be > glad to be wrong though! > I'm not sure that's actually the case. I can't really speak for it, as I generally don't use Debian (I primarily use Fedora, openSUSE, Mageia, and CentOS). One thing I have observed is that there are no guidelines or policy documentation from Debian on how to install policy modules. That's a very annoying gap for anyone who wants to leverage the modular nature of SELinux policies. Many, many, many common services and applications ship SELinux policy modules, and they are not packaged in Debian because no one is sure how to do it. I've more or less fallen back to telling people to use the Makefile to build and install the module and hope that Debian does The Right Thing(TM). But of course, I don't know if this is true. >>> * Writing, maintaining, auditing and debugging SELinux policy >>> requires grasping a complex conceptual model; I am told this is not >>> as easy as doing the same with AppArmor. > >> This is not really true. While it is true that the conceptual model is >> more complex, the tooling for doing all the regular work with SELinux >> is great. In many cases, the tools can analyze what's happened and >> suggest a course of action about how to fix it. If it looks like a >> bug, they suggest filing one with the vendor (in my case, when weird >> things happen with the SELinux policy in Fedora, bugs get filed on >> selinux-policy with the information from setroubleshoot so that things >> can get fixed). > > This sounds great UX; it makes me wish to try it out and draw > inspiration from it to improve AppArmor's UX too. Thanks for sharing. > >> As for the complexity of making policies and policy modules, I've >> written a few policy modules, and they're not that bad. You can make >> some pretty simple policies if you don't want to expose any >> administrative tunables. That said, even with the tunables, it's not >> that bad. > >> For example, the container-selinux policy module is pretty easy to >> understand: https://github.com/projectatomic/container-selinux > >> The refpolicy documentation is pretty comprehensive too: >> http://oss.tresys.com/docs/refpolicy/api/ > > I had a quick look and I agree: it's not that bad. Still feels much > scarier than AppArmor policy to me, but I'm clearly not the right > person to judge these days :) > >>> * As far as I could understand when chatting with sysadmins of Red >>> Hat systems, this has resulted in a culture where many users got >>> used to disable SELinux entirely on their systems, instead of >>> trying to fix the buggy policy. > >> Back in the RHEL 5 days, this is definitely true. And if many of of >> the Red Hat sysadmins you've talked to primarily maintain RHEL 5 >> systems (which is not unlikely), then it makes sense. Back in the RHEL >> 5 days (circa 2007), the tooling was very primitive, and for the most >> part, the troubleshooting tools didn't exist. > >> Today in Fedora and RHEL 7, the tooling is very advanced, and in >> almost every case where I've hit AVC denials in SELinux, >> setroubleshoot has given me very useful information including >> suggested course of actions to actually fix it locally. > > OK, this does explain things. It's sad that this culture has been > created in the first place — changing users' habits is hard: the > sysadmins I'm talking about kept "disable SELinux" i
Bug#879894: ITP: snapd-glib -- GLib snapd library
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Owner: jbi...@debian.org Package Name: snapd-glib Version: 1.24 Upstream Authors : Canonical LTD License : LGPL-2 or LGPL-3 Programming Lang: C and C++ Description: GLib snapd library snapd-glib is a library to allow GLib based applications access to snapd, the daemon that controls Snaps. . Snaps are 'universal' packages that work across many different Linux systems, enabling secure distribution of the latest apps and utilities for cloud, servers, desktops and the internet of things. The package also contains a login service and libraries for Qt/QML apps. Other Info -- snapd-glib is required for the Snap plugin to be re-enabled in Debian's GNOME Software package. https://bugs.debian.org/877684 This package will be maintained under the umbrella of the pkg-ayatana team. Packaging is at https://anonscm.debian.org/git/pkg-ayatana/snapd-glib.git Thanks, Jeremy Bicha
Re: Switching to sysvinit-core fails miserably in buster/sid
On Thu, Oct 26, 2017 at 09:26:57AM +0100, Simon McVittie wrote:
> On Thu, 26 Oct 2017 at 09:29:18 +0200, Svante Signell wrote:
> > Hi, when trying to follow which patches are applied to sysvinit, the git
> > link
> > given in the package page, https://packages.qa.debian.org/s/sysvinit.html
> > is not
> > up to date: https://anonscm.debian.org/cgit/collab-maint/sysvinit.git
> > Latest entry there is from February 2017. Where is the recent git repo?
>
> update-rc.d is now built from init-system-helpers, not sysvinit (because
> the same script is used for multiple init systems). This bug was found
> and fixed there, not in sysvinit.
>
> sysvinit itself had its most recent maintainer upload in 2015, so it isn't
> surprising if nothing has changed in git recently. Patches corresponding
> to each subsequent NMU should be available in the BTS.
Actually, it has seen a maintainer upload recently, but by mistake it had a
version number that looked like a NMU. And that upload was committed to
git.
Indeed, sysvinit is somewhat undermaintained, but as a mature piece of
software it doesn't require much fixing. For example: if you lxc-create -t
debian -- -r sid, the container created (as of yesterday) doesn't even boot
unless you switch to sysvinit ("Can't mount API filesystems.").
On the other hand, both of openrc's remaining uploaders are lazy bums and
some work is badly overdue...
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U.
⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift
⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters
⠈⠳⣄ relevant to duties], shall be punished by death by shooting.
Re: Switching to sysvinit-core fails miserably in buster/sid
Hi,
On Fri, Oct 27, 2017 at 12:04:37AM +0200, Adam Borowski wrote:
> Indeed, sysvinit is somewhat undermaintained, but as a mature piece of
> software it doesn't require much fixing. For example: if you lxc-create -t
> debian -- -r sid, the container created (as of yesterday) doesn't even boot
> unless you switch to sysvinit ("Can't mount API filesystems.").
Can you clarify the environment where you are experiencing this? I
tested creating and booting a sid container a few minutes ago, and it
just worked.
signature.asc
Description: PGP signature
Work-needing packages report for Oct 27, 2017
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: 1151 (new: 21) Total number of packages offered up for adoption: 155 (new: 0) Total number of packages requested help for: 47 (new: 1) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: aspell-kk (#879869), orphaned today Description: Kazakh dictionary for GNU Aspell Installations reported by Popcon: 71 Bug Report URL: http://bugs.debian.org/879869 ccrypt (#879649), orphaned 3 days ago Description: secure encryption and decryption of files and streams Installations reported by Popcon: 1015 Bug Report URL: http://bugs.debian.org/879649 cd-discid (#879870), orphaned today Description: CDDB DiscID utility Reverse Depends: abcde Installations reported by Popcon: 2316 Bug Report URL: http://bugs.debian.org/879870 hunspell-kk (#879871), orphaned today Description: Kazakh dictionary for hunspell Reverse Depends: parl-desktop-world Installations reported by Popcon: 122 Bug Report URL: http://bugs.debian.org/879871 inadyn (#879872), orphaned today Description: Simple and small DynDNS client written in the C language Installations reported by Popcon: 324 Bug Report URL: http://bugs.debian.org/879872 libical (#879395), orphaned 5 days ago Description: iCalendar library implementation in C (development) Reverse Depends: agenda.app almanah asterisk-modules bijiben bluez-obexd cairo-dock-clock-plug-in citadel-server citadel-webcit claws-mail-vcalendar-plugin cyrus-caldav (43 more omitted) Installations reported by Popcon: 53113 Bug Report URL: http://bugs.debian.org/879395 libsoc (#879389), orphaned 5 days ago Description: C library to interface with common peripherals Reverse Depends: libsoc-dev python-libsoc Installations reported by Popcon: 1 Bug Report URL: http://bugs.debian.org/879389 libutempter (#879388), orphaned 5 days ago Description: privileged helper for utmp/wtmp updates (development) Reverse Depends: libkpty4 libutempter-dev mosh screen tmux xterm xwrited Installations reported by Popcon: 118076 Bug Report URL: http://bugs.debian.org/879388 libzip (#879387), orphaned 5 days ago Description: library for reading, creating, and modifying zip archives (development) Reverse Depends: cbmc comet-ms fuse-zip hhvm ideviceinstaller kchmviewer libconcord4 libepub0 libmgba libmstoolkit-dev (20 more omitted) Installations reported by Popcon: 31692 Bug Report URL: http://bugs.debian.org/879387 linaro-image-tools (#879386), orphaned 5 days ago Description: collection of tools to work with Linaro images Reverse Depends: linaro-image-tools Installations reported by Popcon: 79 Bug Report URL: http://bugs.debian.org/879386 log4c (#879405), orphaned 5 days ago Description: C library for flexible logging (development) Reverse Depends: liblog4c-dev Installations reported by Popcon: 52 Bug Report URL: http://bugs.debian.org/879405 log4cpp-doc (#879407), orphaned 5 days ago Description: C++ library for flexible logging (documentation) Installations reported by Popcon: 66 Bug Report URL: http://bugs.debian.org/879407 metapixel (#879648), orphaned 3 days ago Description: generator for photomosaics Installations reported by Popcon: 151 Bug Report URL: http://bugs.debian.org/879648 openshot (#879778), orphaned yesterday Description: Create and edit videos and movies Installations reported by Popcon: 5098 Bug Report URL: http://bugs.debian.org/879778 powerdebug (#879409), orphaned 5 days ago Description: tool to display regulator, sensor and clock information Installations reported by Popcon: 30 Bug Report URL: http://bugs.debian.org/879409 qwbfsmanager (#879448), orphaned 5 days ago Description: graphical file manager for the WBFS filesystem Installations reported by Popcon: 174 Bug Report URL: http://bugs.debian.org/879448 srecord (#879437), orphaned 5 days ago Description: collection of powerful tools for manipulating EPROM load files Reverse Depends: libsrecord-dev libsrecord0-dbg srecord Installations reported by Popcon: 228 Bug Report URL: http://bugs.debian.org/879437 sxid (#879873), orphaned today Description: suid, sgid file and directory checking Installations reported by Popcon: 32 Bug Report URL: http://bugs.debian.org/879873 universalindentgui (#879447), orphaned 5 days ago Description: GUI frontend for several code beautifiers Installations report
Re: Bug#879839: ITP: xhtml2pdf -- A library for converting HTML into PDFs using ReportLab
Thanks Martin. Looking at the history on https://github.com/xhtml2pdf/xtml2pdfh, it got renamed from pisa to xhtml2pdf in 2010. Anyway, we'll get it back into shape either way. Makes sense to keep it in python-modules rather than debian-science. Drew On Thu, 2017-10-26 at 16:37 +0200, W. Martin Borgert wrote: > Hi Drew, > > many thanks for your ITP! > > Note, that xhtml2pdf is known also as "pisa" - nobody so far could > explain to me, why there is this upstream name confusion. > > And pisa is in Debian: https://tracker.debian.org/pkg/pisa > Unfortunately, pisa is not in a good state. It is not in testing, > and did neither made it to stretch nor jessie. Python 3 support is > needed, too. > > Please feel free, to takeover the package or maintain it within the > Python modules team. I'm also still interested in having the package > in Debian, because of trac-wikiprint, but did not have the time nor > energy to take care of the package. > > I set Hugo in Cc, because he was also interested in helping. > > Cheers >
Re: Let's enable AppArmor by default (why not?)
I think the only two ways to get a new package installed upon stretch → buster are: 1. Suggest the admin do it in the release notes. (It should be documented in the release notes no matter which option we pick, of course.) 2. Suggest the admin do it in a NEWS.Debian entry (but it needs to be an upgraded package, not a new one, else it won't be displayed. So the linux-image-4.* packages won't work, but e.g., linux-image-amd64 would). 3. Have a Recommends or Depends on it from another package that is installed. (Presumably that'd be a Recommends from the linux-image-* packages, and would be dropped down to a Suggests for buster+1). 4. Suggest the admin do it in a debconf note. Highly discouraged nowadays. All of those except #1 also work for folks following testing or unstable. Personally, I don't have a preference between #1 and #3, as long as we find some reasonable way to opt-out if we go with #3 (and document it in the release notes). On 10/26/2017 11:02 AM, intrigeri wrote: Hi, intrigeri: tl;dr: I hereby propose we enable AppArmor by default in testing/sid, and decide one year later if we want to keep it this way in the Buster release. Thanks a lot to everyone who participated on this thread, tried AppArmor and reported bugs, or expressed support/interest privately! Summary of the discussion: no strong objection was raised; quite a few potential issues were mentioned; the most serious ones were either resolved already, or in good way to be resolved in the next 2 weeks. So, my understanding is that we have a broad consensus and can start the proposed experiment. I need advice from you folks on one specific matter, see below. 1. Enable AppArmor by default in testing/sid as soon as feasible in the Buster cycle. I can think of several possible ways to do it but for now I'd rather focus on the "do we want to do it at all" conversation. It's now time to discuss the "how" aspect. Enabling AppArmor by default requires two changes: 1. enabling the LSM in Linux: problem solved, Ben Hutchings agreed we should do this in src:linux, at least for the time being; 2. installing the apparmor package by default: it ships the bits of code that load AppArmor policy during boot and some shared bits of policy that most other AppArmor profiles rely upon. This email is about (2). There are two aspects to it. For new installations, it seems that making the apparmor package "Priority: standard" is the way to go. I've asked debian-boot@'s opinion about it [priority:standard?] but the rest of our developers community is of course welcome to comment as well. For upgrades it seems much more complicated. Ideally I would like the apparmor package to be installed automatically: - on testing/sid upgrades, during the Buster dev cycle: this would greatly increase the value of the "enable AppArmor by default for a while" experiment as we would get lots more data to reason about when the time comes; - during Stretch to Buster upgrades: this seems necessary so every user gets the AppArmor benefits, regardless of when they installed their system initially. I also want to provide easy means for users to opt-out from the experiment. I've requested advice on this topic from a few fellow Debian people and the conclusion seems to be: - I was told essentially "we generally don't do that in Debian" by a few people who suggested me asking this mailing list. I don't understand the rationale though — during system upgrades we do change the distro behavior in many ways: we add new features, we enable new security measures, we switch init systems, we switch from MySQL to MariaDB and all sort of things — so it's not obvious to me why doing the same to enable a security system like AppArmor would be a Bad Thing™. Is the concern specifically about doing so by pulling a new package in? Or is it specifically about enabling a LSM that was previously disabled? (Any such big change brings a risk of introducing regressions, so the underlying questions seem to be "is the risk worth it? is the risk well managed?") - We have no better option to achieve that than having another package, that's already installed by default, add a "Recommends: apparmor". This feels artificial and rather ugly, but it might be the only option. I don't know which other package would be the most suitable to add this dependency. Any suggestion? Any other idea? I'd love to read your thoughts about this. Let's discuss it. [priority:standard?] https://bugs.debian.org/879590#25 Cheers,
