Bug#813464: ITP: ciscocmd -- Expect script to send a set of commands to a set of Cisco devices

[Octavio Alvarez]

Package: wnpp
Severity: wishlist
Owner: Octavio Alvarez 

* Package name: ciscocmd
  Version : 1.11
  Upstream Author : Alain Degreffe 
* URL : http://cosi-nms.sourceforge.net/alpha-progs.html
* License : GPLv2
  Programming Lang: Expect/TCL
  Description : Expect script to send a set of commands to a set of
Cisco devices

 ciscocmd is a Tcl/Expect script. With this tool, you can send a set of
 command to a large number of ios target hosts and get a separated report
 for each node.

 I use this program on a day-to-day basis and I have contributed code
 to it.

 Because this program is a single-file Expect script, package maintenance
 should be simple. I plan to maintain it by myself.

 I will need a sponsor for this package, though.

Re: Debian Policy 3.9.7.0 released

[Daniel Reurich]

On 02/02/16 18:18, Jonas Smedegaard wrote:
> Quoting Daniel Reurich (2016-02-02 00:46:28)
>> On 02/02/16 12:36, Bill Allombert wrote:
>>> We have just released Debian Policy 3.9.7.0 to fix a FTBFS.
> 
> Thanks a lot for all the work on maintaining Debian Policy!
> 
> 
>>> 4.9 `debian/rules': required targets must not attempt network
>>> access.
>>> 
>> Doesn't this mean that debian-installer which requires network
>> access to build the image (may also be true of cdimage,
>> live-installer etc) fails on this policy??
> 
> Please do not hijack discussion on one topic (changes to Policy) with
>  another discussion (whether one specific package fits Policy).
> 
> Please instead follow up at bug#807312 (either consider file a new 
> bugreport based on the lack of responses there or help provide the 
> missing information requested there).
> 
Apologies,

It was the first I saw of the Policy changes and I thought this list was
the appropriate place to comment on the implications of said policy changes.


-- 
Daniel Reurich
Centurion Computer Technology (2005) Ltd.




signature.asc
Description: OpenPGP digital signature

Bug#813470: RFA: xenomai -- Real-time development framework for the Linux kernel

[stigge]

Package: wnpp
Severity: normal

I'm not actively using this package. Therefore, looking for a new maintainer.
The last upload was prepared by Leopold Palomo-Avellaneda .
Please coordinate with him.

Bug#813474: ITP: libhinawa -- I/O library for IEEE 1394 asynchronous transactions

[HAYASHI Kentaro]

Package: wnpp
Severity: wishlist
Owner: HAYASHI Kentaro 
X-Debbugs-CC: debian-devel@lists.debian.org, debian-de...@lists.debian.or.jp

   Package name: libhinawa
Version: 0.7.0
Upstream Author: Takashi Sakamoto 
   URL: https://github.com/takaswie/libhinawa
License: LGPL-2.1

Description: libhinawa is an I/O library for units on IEEE 1394 bus.
 This library supports any types of asynchronous transactions over IEEE 1394 
bus.
 Additionally, this library also supports some functionalities which
 ALSA firewire stack produces.

-- 
HAYASHI Kentaro 

Bug#813481: ITP: r-cran-markdown -- GNU R package providing R bindings to the Sundown Markdown rendering library

[Joost van Baal-Ilić]

Package: wnpp
Severity: wishlist

* Package name: r-cran-markdown
  Version : 0.7.7
  Upstream Author : Yihui Xie 
* URL : https://cran.r-project.org/web/packages/markdown/
* License : GPL e.a.
  Programming Lang: R, C
  Description : GNU R package providing R bindings to the Sundown Markdown 
rendering library

 Provides R bindings to the Sundown Markdown rendering library by Vicent Marti 
e.a.,
 based upon work by Natacha Porté.  Markdown is a plain-text formatting syntax 
that can
 be converted to XHTML or other formats.
 .
 The R function `markdownToHTML` renders a markdown file to HTML. Options
 controlling HTML output and supported markdown extensions can be optionally
 specified.
 .
 The package also exports the underlying Sundown C extension API which
 enables creating and calling custom renderers using the `renderMarkdown`
 function.


The R markdown package is a dependency for r-cran-knitr (ITP Bug#808155);
r-cran-knitr is needed for RStudio's Shiny Server.

I'll work on the packaging using debian-science's git at Alioth, at
http://anonscm.debian.org/gitweb/?p=debian-science/packages/r-cran-markdown.git 
.

See also https://lists.debian.org/<20151110083253.gb6...@dijkstra.uvt.nl>
"running RStudio's Shiny Server the Debian way".

Bye,

Joost



signature.asc
Description: Digital signature

Bug#813485: ITP: setop -- apply set operations like intersection to text inputs

[Frank Stähr]

Package: wnpp
Severity: wishlist
Owner: "Frank Stähr" 

* Package name: setop
  Version : 0.1
  Upstream Author : Frank Stähr 
* URL : http://github.com/phisigma/setop
* License : GPL-2+
  Programming Lang: C++
  Description : apply set operations like intersection to text inputs

setop is a simple console utility for handling multiple inputs from files or 
other streams as mathematical sets.
That is you can apply typical set operations like union, intersection, or set 
difference and print a resulting set (sorted and with unique string elements) 
to standard output or you can give answer to special queries like number of 
elements.

Up to now, there is no similar package in the repository. Programs like sort, 
uniq, comm, join, grep, awk, cat, combine, wc etc. can only inconveniently deal 
with some (in each case one or two) features of setop, but none of these is as 
universal, flexible, and easy to use as setop itself, including non-standalone 
utilities like script languages.

I already asked at  for the need of something 
like setop and got at least a slightly positive feedback, mixed with references 
to the above mentioned "workarounds", Python and LISP. See 
.

Further maintance (e. g. translations, new features and of course bug fixing) 
are planned, but at first I need a sponsor and am going to ask at 
debian-mentors.

Bug#813486: ITP: golang-github-flynn-go-shlex -- Fork of go-shlex from Google Code

[Zlatan Todoric]

Package: wnpp
Severity: wishlist
Owner: Zlatan Todoric 

* Package name: golang-github-flynn-archive-go-shlex
  Version : 0.0~git20150515.0.3f9db97-1
  Upstream Author : https://github.com/flynn-archive
* URL : https://github.com/flynn-archive/go-shlex
* License : Apache 2.0
  Programming Lang: Go
  Description : Fork of go-shlex from Google Code

 go-shlex is a simple lexer for go that supports shell-style quoting,
 commenting, and escaping.

This dependency is needed for caddy server.

Bug#813488: ITP: hfst-ospell -- Spell checker library and tool based on HFST

[Kartik Mistry]

Package: wnpp
Severity: wishlist
Owner: Kartik Mistry 

* Package name: hfst-ospell
  Version : 0.4.0~r4620
  Upstream Author : Department of Modern Languages, University of Helsinki
* URL : http://www.ling.helsinki.fi/kieliteknologia/tutkimus/hfst/
* License : Apache-2.0
  Programming Lang: C++
  Description : Spell checker library and tool based on HFST

 Minimal HFST optimized lookup format based spell checker library and
 a demonstrational implementation of command line based spell checker.

 This will be used for HFST spellchecker.

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com


signature.asc
Description: PGP signature

Bug#813504: ITP: erlang-luerl -- implementation of Lua in Erlang

[Philipp Huebner]

Package: wnpp
Severity: wishlist
Owner: Philipp Huebner 

* Package name: erlang-luerl
  Version : 0.2015.12.10
  Upstream Author : Robert Virding 
* URL : https://github.com/rvirding/luerl
* License : Apache-2.0
  Programming Lang: Erlang
  Description : implementation of Lua in Erlang

 An experimental implementation of Lua 5.2 written solely in pure Erlang
 .
 When to use Luerl:
 .
 Fast Language Switch: Luerl should allow you to switch between Erlang and Lua
 incredibly fast, introducing a way to use very small bits of logic programmed
 in Lua, inside an Erlang application, with good performance.
 .
 Multicore: Luerl provides a way to transparently utilize multicores. The
 underlying Erlang VM takes care of the distribution.
 .
 Microprocesses: It should give you a Lua environment that allows you to
 effortlessly run tens of thousands of Lua processes in parallel, leveraging
 the famed microprocesses implementation of the Erlang VM. The empty Luerl
 State footprint will be yet smaller than the C Lua State footprint.
 .
 Forking Up: Because of the immutable nature of the Luerl VM, it becomes a
 natural operation to use the same Lua State as a starting point for multiple
 parallel calculations.
 .
 However, Luerl will generally run slower than a reasonable native Lua
 implementation. This is mainly due the emulation of mutable data on top of an
 immutable world. There is really no way around this. An alternative would be
 to implement a special Lua memory outside of the normal Erlang, but this would
 defeat the purpose of Luerl. It would instead be then more logical to connect
 to a native Lua.
 .
 Some valid use cases for Luerl are:
  * Lua code will be run only occasionally and it wouldn't be worth managing
an extra language implementation in the application;
  * the Lua code chunks are small so the slower speed is weighed up by Luerl's
faster interface;
  * the Lua code calculates and reads variables more than changing them;
  * the same Lua State is repeatedly used to 'fork up' as a basis for
massively many parallel calculations, based on the same state;
  * it is easy to run multiple instances of Luerl which could better utilise
multicores.

This package is a dependency of the next ejabberd release.

Re: Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?

[Jonathan Dowland]

I must say that I do not like this proposal. The current situation does result
in under-maintained packages requiring churn, but that's true for many aspects
of them, not least their policy version. It's a good indicator of which
packages need some attention.

That's not what I dislike about the suggestion, though. I think it makes the
cognitive load of the control file larger. You have to know there are special
rules that exist for some URLs, but not all. It ties the function of the control
file closely to Debian, and if other control users like Ubuntu implement
something similar, there are even more special cases for a maintainer to have
to understand. A simple URL like we have now is quite self-describing, and if
you find a control file in the wild you don't need any additional expert
knowledge to use it.

If/as rules change over time you will have skew from control files and the 
current state of affairs, unless you try to version it and then we truly do
have something too overengineered IMHO.


-- 
Jonathan Dowland

Re: The state of cross building

[Theodore Ts'o]

On Sat, Jan 30, 2016 at 08:08:09PM +0100, Helmut Grohne wrote:
> 
> We have cross compilers and crossbuild-essential-* packages in unstable
> for quite a while now. (Thanks to Matthias Klose.)

I see these haven't entered testing because:

* 183 days old (needed 5 days)
* crossbuild-essential-arm64/amd64 unsatisfiable Depends: libc6-dev:arm64
* crossbuild-essential-armel/amd64 unsatisfiable Depends: libc6-dev:armel
* crossbuild-essential-armhf/amd64 unsatisfiable Depends: libc6-dev:armhf
   
* Invalidated by dependency
* Not considered
* Depends: build-essential dpkg-cross

Am I right in thinking this is because of how the testing scripts
work; is this something that is likely to be fixed in the future, or
is crossbuild-essential-* something that is only intended for unstable
and never for testing/stable?

Thanks,

- Ted

Re: The state of cross building

[Helmut Grohne]

On Tue, Feb 02, 2016 at 11:39:50AM -0500, Theodore Ts'o wrote:
> I see these haven't entered testing because:
> 
> * 183 days old (needed 5 days)
> * crossbuild-essential-arm64/amd64 unsatisfiable Depends: libc6-dev:arm64
> * crossbuild-essential-armel/amd64 unsatisfiable Depends: libc6-dev:armel
> * crossbuild-essential-armhf/amd64 unsatisfiable Depends: libc6-dev:armhf
>
> * Invalidated by dependency
> * Not considered
> * Depends: build-essential dpkg-cross
> 
> Am I right in thinking this is because of how the testing scripts
> work; is this something that is likely to be fixed in the future, or
> is crossbuild-essential-* something that is only intended for unstable
> and never for testing/stable?

As far as I can tell, there is nothing that would make these packages
unfit for release in principle. However, there currently are unsolved
problems that prevent them from transitioning to testing.

The crossbuild-essential-* packages use cross-architecture dependencies.
This is a rarely used feature and it is not currently supported by
britney. Thus these packages cannot transition before britney is
changed. I am not aware of anyone working on this problem. Adding this
feature to britney could also help with #807312.

The crossbuild-essential-* packages depend on dpkg-cross, which
currently is RC-buggy and not part of jessie or stretch and thus also
blocking the migration. The dpkg-cross tool is used to convert
architecture-dependent library packages into architecture-independent
packages for use in a pre-multiarch era. It happens to also contain
config.site files, that provide check results to autotool's configure.
The latter is the reason for this dependency.

It seems like these check results should find a new home, but it is not
clear that keeping them in a central place is a good long-term solution.
It also seems that every cross distribution has its own way of
maintaining these, which is sad. I have some ideas floating for
improving, but I put my work on hold to better understand the
requirements. In order to get a better understanding, I am maintaining
these check results on a per-package granularity for rebootstrap[1].

Personally, I am hoping for a future where packages that are being
checked ship these check results. For example, glibc contains malloc, so
libc6-dev could contain a file expressing
ac_cv_func_malloc_0_nonnull=yes. In a similar vein, acl contains
acl_get_file, so libacl1-dev could express
gl_cv_func_working_acl_get_file=yes. Unfortunately, some packages use
non-canonical names (e.g. xorg_cv_malloc0_returns_null), so the
envisioned future is non-trivial to implement.

You see that the whole cross building story is a huge task. Progress is
slow (but steady) and help is always welcome.

Helmut

[1] https://wiki.debian.org/HelmutGrohne/rebootstrap

Bug#813524: ITP: djangocms-admin-style -- CSS styles for the django CMS admin interface

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: djangocms-admin-style
  Version : 1.1.0
  Upstream Author : Ales Kocjancic 
* URL : https://github.com/divio/djangocms-admin-style
* License : BSD-3-clause
  Programming Lang: Python
  Description : CSS styles for the django CMS admin interface

 django CMS is a modern web publishing platform built with Django. It offers
 out-of-the-box support for the common features expected from a CMS, but can
 also be easily customised and extended by developers to create a site that is
 tailored to their precise needs.
 .
 django CMS is a well-tested CMS platform that powers sites both large and
 small. Here are a few of the key features:
  * robust internationalisation (i18n) support for creating multilingual sites
  * virtually unlimited undo history, allowing editors to revert to a previous
version
  * front-end editing, providing rapid access to the content management
interface
  * support for a variety of editors with advanced text editing features
  * a flexible plugins system that lets developers put powerful tools at the
fingertips of editors, without overwhelming them with a difficult interface
 .
 This package contains the common assets of the admin styles required by
 django CMS.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJWsOiNAAoJEGlMre9Rx7W2Cs0QAKn36DXm4NqpZAR9peQsfgsK
O0bnQIKedxKIwP3gEE54zDFIsN5ZsRrdDpwcoSqoxgjyPsEw26oC35k2uEZqZY01
CuGZdOeW1O7anjCgQrn+eBmc295/JMd7X27oRYJNXzjb2wOVVGA9H8ALM0eEc31p
uOpXM+VHBLCmtx1MW5cNl3Fe2jKefJSVFEKYO6fkCOyWra2noRW0MK2P/sQi6p95
96hZeFmMwpMX4UPqrPF8qApcIh+6kpB3z4uN5uTuE++R8Bz0Li3d3CGNGkF4KDW3
wzY6WSuo3NPB4gpgjXk/QV7pWP1BxorscJ/4SqUClLS3Y31q/130gJR8PhD9y9kG
340M6ggOv9eS6uqjJOm6FZkMcjS2pQafeKtWNYMOCQR+ZAXDQ8jJ8nJEir9rVPiL
pPqBLmmdWYU20aDRGcUBz7PAzsgum4bIA2AHOu/rDQ5havtCqoOZDJ+zzyyFFBar
QFIc5m2rs4v5jVJpAlrkPqG7bT9jFSpgcnO4bCqhHJs1AoPt1hsU7rHQ/fKrwKzn
kLnUGv3u7RWmmPRMVe1FpOxEmJWFw13I7tUn+PwJF4DWpCdug/I+IXzeNzlOozfA
hOXtgxHSZWQd5N0XgVKN0YPSpofvCDEuaUtUpnrTD3+UnLt3tXJ/ZtSM8J7+iaQw
GPseju16+5Uzhm/ExZ/Y
=PE5F
-END PGP SIGNATURE-

Re: Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?

[Simon McVittie]

On 02/02/16 17:38, Jonathan Dowland wrote:
> I must say that I do not like this proposal. The current situation does result
> in under-maintained packages requiring churn, but that's true for many aspects
> of them, not least their policy version. It's a good indicator of which
> packages need some attention.

At the moment, lintian needs changes anyway whenever best-practice
changes. Would it perhaps make sense to do the same transformations in
dak - perhaps data-driven, with some regexes supplied by the Alioth or
lintian maintainers - so that what is published in the Sources file for
consumers is always the currently-preferred form?

> I think it makes the
> cognitive load of the control file larger. You have to know there are special
> rules that exist for some URLs, but not all.

I think this can be mitigated by only doing this edit for complete URLs
that are valid-but-deprecated, with suitable redirections also in place
server-side.

S

Fixing dependency resolution of britney (was: Re: The state of cross building)

[Johannes Schauer]

Hi,

Quoting Helmut Grohne (2016-02-02 20:40:38)
> On Tue, Feb 02, 2016 at 11:39:50AM -0500, Theodore Ts'o wrote:
> > I see these haven't entered testing because:
> > 
> > * 183 days old (needed 5 days)
> > * crossbuild-essential-arm64/amd64 unsatisfiable Depends: libc6-dev:arm64
> > * crossbuild-essential-armel/amd64 unsatisfiable Depends: libc6-dev:armel
> > * crossbuild-essential-armhf/amd64 unsatisfiable Depends: libc6-dev:armhf
> >
> > * Invalidated by dependency
> > * Not considered
> > * Depends: build-essential dpkg-cross
> > 
> > Am I right in thinking this is because of how the testing scripts
> > work; is this something that is likely to be fixed in the future, or
> > is crossbuild-essential-* something that is only intended for unstable
> > and never for testing/stable?
> 
> As far as I can tell, there is nothing that would make these packages
> unfit for release in principle. However, there currently are unsolved
> problems that prevent them from transitioning to testing.
> 
> The crossbuild-essential-* packages use cross-architecture dependencies.
> This is a rarely used feature and it is not currently supported by
> britney. Thus these packages cannot transition before britney is
> changed. I am not aware of anyone working on this problem. Adding this
> feature to britney could also help with #807312.

in #807312 Ansgar helpfully pointed me to [1]. I have no clue at all about
britney but from my naive understanding I get that one of the things it does is
to check if a source package's build dependencies and its binary packages'
runtime dependencies are satisfied in testing.

My question is: why does it not just use dose3 just as the buildds are doing
it? You would then get multiarch support, build profile support, cross
architecture support, versioned provides support and so on for free.

I tried to find where the source code lives but I have a hard time finding it.
The page at [1] seems not to be generated by britney but by [2] which is
parsing what I understood is britney output at [3]. But neither [3] nor the
parent directory at [4] seem to point to the code generating [3]. I found [5]
but when I cloned that I couldn't find much code in it and its README was
talking about a code/b1 directory which I also cannot see while it lists "Some
HOWTO here." as a TODO item at the bottom...

So, in case I am not missing something really obvious here, could you make it
easier for users to find the code generating the pages they can find on
release.debian.org? I think it would be nice if all Debian web services had
such a link to the code that creates them at the bottom. This would show how
much we value to be open and would maybe even attract more contributors.

And it would be even better if there was some instructions of how to hack the
britney code (how to test changes etc). If that existed, I could see if I can
create a patch which adds dose3 support to britney.

Thanks!

cheers, josch

[1] https://release.debian.org/migration/testing.pl?package=cross-gcc-4.9-armhf
[2] https://release.debian.org/migration/testing.txt
[3] https://release.debian.org/britney/update_excuses.html
[4] https://release.debian.org/britney/
[5] https://release.debian.org/britney/code.git/


signature.asc
Description: signature

Re: Debtags consolidation

[Paul Wise]

I think removing anonymous debtags will eliminate casual debtagging
from non-technical users. If we can still allow anonymous submissions
after the SSO integration then I would be willing to moderate
anonymous submissions once a week as I do for screenshots. Perhaps the
site could allow any DD moderate any package and any DM to moderate
their packages?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise
http://bonedaddy.net/pabs3/

Re: Fixing dependency resolution of britney (was: Re: The state of cross building)

[Adam D. Barratt]

On Tue, 2016-02-02 at 23:07 +0100, Johannes Schauer wrote:
> My question is: why does it not just use dose3 just as the buildds
> are doing it? 

How old is the dose codebase? The changelog.gz in the current Debian
package only goes back to 2012, which is more than a decade after
britney was originally written.

> So, in case I am not missing something really obvious here, could you make it
> easier for users to find the code generating the pages they can find on
> release.debian.org? I think it would be nice if all Debian web services had
> such a link to the code that creates them at the bottom. This would show how
> much we value to be open and would maybe even attract more contributors.

If you want people to do something, it's generally better to ask them,
not assume that they happen to be reading debian-devel.

> I tried to find where the source code lives but I have a hard
> time finding it.

The front page of release.debian.org has an "our tools" link which leads
to https://release.debian.org/tools.html , which in turn has a link to
an alioth mirror of the britney1 and britney2 source repositories.
That's not _that_ undiscoverable, imho.

Regards,

Adam

Re: Fixing dependency resolution of britney

[Johannes Schauer]

Hi,

Quoting Niels Thykier (2016-02-02 23:27:21)
> Britney does *not* look at Build-Depends.  Only (Pre-)Depends.

okay, thanks for clarifying!

> So, Britney's dependency resolver ("InstallabilityTester") actually supports
> all of that.  What is lacking is support for passing the information to the
> resolver.
> 
> Note though that:
>  * Multi-arch - there are policy decisions involved.  Examples:
>- Q: When is it permitted to depend on packages on foreign
>  architectures?

this sounds like before britney can accept any patches above question has to be
answered and agreed upon by the release team.

Why would we want to not always permit binary packages to depend on packages of
foreign architectures if these architectures are also release architectures and
the binary packages are installable together with packages from the native
architecture?

> Code: https://anonscm.debian.org/git/mirror/britney2.git
> Test suite:
>  https://anonscm.debian.org/cgit/collab-maint/britney2-tests.git
> Docs: https://wiki.debian.org/CommittingBritneyChanges

Thanks for the links...

> Feel free to ask if you got any questions or suggestions for
> improvements.  I am happy to improve the documentation.

...and for the offer :)

cheers, josch


signature.asc
Description: signature

Progress on hardened1-linux-amd64 (was: Re: Proposing amd64-hardened architecture for Debian)

[Bálint Réczey]

Hi All,

2014-04-15 18:15 GMT+02:00 Thomas Goirand :
> On 04/15/2014 06:00 PM, Balint Reczey wrote:
>> Hi,
>>
...
>> My proposal for serving those security-focused users is introducing a
>> new architecture targeting amd64 hardware, but with more security
>> related C/C++ features turned on for every package (currently hardening
>> has to be enabled by the maintainers in some way) through compiler flags
>> as a start.
>>
>> Introducing the new architecture would also let package maintainers
>> enabling additional dependencies and build rules selectively for the new
>> architecture improving the security further. On the users' side the
>> advantage of having a separate security enhanced architecture instead of
>> a Debian derivative is the potential of installing a set of security
>> enhanced packages using multiarch [6]. You could have a fast amd64
>> installation as a base and run Apache or any other sensitive server from
>> the amd64-hardened packages!
>>
>> -
>>
>> What do you think? Would adding a new arch be feasible and a good solution?
>>
>> Cheers,
>> Balint
>
> My take on this: start it if you wish, and see how it takes you. If it
> is successful enough, it will go to http://www.debian-ports.org/. If it
> has even more success, then probably it will go through the standard
> repository and be official part of Debian. Whatever happens, it will be
> interesting to see what kind of performance hit you get, and what kind
> of security enhancement there is.
I made some progress on this wanna-be port in the last months [8]
starting from Helmut's and others' work on rebootsrap [9]. First, the
name is still not final, but has been changed to hardened1-linux-amd64
which fits current port naming better. There are ongoing discussions
regarding the name and I'm working on fulfilling all requirements for
new ports.

The port's objective changed slightly with targeting QA first since I
find too many bugs which prevent using the packages on a stable system
yet. :-)

Right now packages can only be cross-built, thus help on
cross-buildability of packages is highly appreciated especially for
the few missing ones needed for creating a pbuilder/sbuild chroot. You
can try plenty of build-essential packages following the post's [8]
instructions already.

I plan continuing work on this port as my time permits and if there is
significant interest from users. If you are interested and don't want
to share that in public feel free to drop me a mail.

Cheers,
Balint

[8] 
http://balintreczey.hu/blog/progress-report-on-hardened1-linux-amd64-a-potential-debian-port-with-pie-asan-ubsan-and-more/
[9] https://wiki.debian.org/HelmutGrohne/rebootstrap

Re: Fixing dependency resolution of britney

[Niels Thykier]

Johannes Schauer:
> Hi,
> 
> [...]
> 
> in #807312 Ansgar helpfully pointed me to [1]. I have no clue at all about
> britney but from my naive understanding I get that one of the things it does 
> is
> to check if a source package's build dependencies and its binary packages'
> runtime dependencies are satisfied in testing.
> 

Britney does *not* look at Build-Depends.  Only (Pre-)Depends.

> My question is: why does it not just use dose3 just as the buildds are doing
> it?

I presume Britney predates dose3 and evolved organically.  To be honest,
I doubt Britney has an architecture where blindly adding dose3
integration will be beneficial.

> You would then get multiarch support, build profile support, cross
> architecture support, versioned provides support and so on for free.
> 

So, Britney's dependency resolver ("InstallabilityTester") actually
supports all of that.  What is lacking is support for passing the
information to the resolver.

Note though that:
 * Multi-arch - there are policy decisions involved.  Examples:
   - Q: When is it permitted to depend on packages on foreign
 architectures?
 * Versioned Provides - parts of Britney have hardcoded assumptions on
   "Provides" *not* having "(= )" to the point where Britney
   computes the wrong result.

But once you "fix" that and map it correctly to the resolver, then it
will "just work(tm)".  Of course, I made it sound a bit easier than it is.

> I tried to find where the source code lives but I have a hard time finding it.
> [...]
> 

Code: https://anonscm.debian.org/git/mirror/britney2.git
Test suite:
 https://anonscm.debian.org/cgit/collab-maint/britney2-tests.git
Docs: https://wiki.debian.org/CommittingBritneyChanges


> So, in case I am not missing something really obvious here, could you make it
> easier for users to find the code generating the pages they can find on
> release.debian.org? I think it would be nice if all Debian web services had
> such a link to the code that creates them at the bottom. This would show how
> much we value to be open and would maybe even attract more contributors.
> 

Indeed, patches welcome to make it easier to find.

> And it would be even better if there was some instructions of how to hack the
> britney code (how to test changes etc). If that existed, I could see if I can
> create a patch which adds dose3 support to britney.
> 

The best I got is: https://wiki.debian.org/CommittingBritneyChanges

Feel free to ask if you got any questions or suggestions for
improvements.  I am happy to improve the documentation.

> Thanks!
> 
> cheers, josch
> 
> [1] 
> https://release.debian.org/migration/testing.pl?package=cross-gcc-4.9-armhf
> [2] https://release.debian.org/migration/testing.txt
> [3] https://release.debian.org/britney/update_excuses.html
> [4] https://release.debian.org/britney/
> [5] https://release.debian.org/britney/code.git/
> 

Thanks,
~Niels






signature.asc
Description: OpenPGP digital signature

Re: The state of cross building

[Wookey]

+++ Helmut Grohne [2016-02-02 20:40 +0100]:
> On Tue, Feb 02, 2016 at 11:39:50AM -0500, Theodore Ts'o wrote:
> > I see these haven't entered testing because:
> > 
> > * 183 days old (needed 5 days)
> > * crossbuild-essential-arm64/amd64 unsatisfiable Depends: libc6-dev:arm64
> > * crossbuild-essential-armel/amd64 unsatisfiable Depends: libc6-dev:armel
> > * crossbuild-essential-armhf/amd64 unsatisfiable Depends: libc6-dev:armhf
> >
> > * Invalidated by dependency
> > * Not considered
> > * Depends: build-essential dpkg-cross
> > 
> > Am I right in thinking this is because of how the testing scripts
> > work; is this something that is likely to be fixed in the future, or
> > is crossbuild-essential-* something that is only intended for unstable
> > and never for testing/stable?

We do want to get these into stretch so that stable has a working cross-build 
setup.
 
> As far as I can tell, there is nothing that would make these packages
> unfit for release in principle. However, there currently are unsolved
> problems that prevent them from transitioning to testing.
> 
> The crossbuild-essential-* packages use cross-architecture dependencies.
> This is a rarely used feature and it is not currently supported by
> britney. Thus these packages cannot transition before britney is
> changed. I am not aware of anyone working on this problem. Adding this
> feature to britney could also help with #807312.
> 
> The crossbuild-essential-* packages depend on dpkg-cross, which
> currently is RC-buggy and not part of jessie or stretch and thus also
> blocking the migration. The dpkg-cross tool is used to convert
> architecture-dependent library packages into architecture-independent
> packages for use in a pre-multiarch era. It happens to also contain
> config.site files, that provide check results to autotool's configure.
> The latter is the reason for this dependency.

I've just finished a project so plan to spend some time fixing stuff
like this which is blocking cross-building in stretch. I plan to
either fix dpkg-cross or (better), move the still-useful parts into a
'cross-support' package. Of course I'm happy if someone beats me to it
:-)

> It seems like these check results should find a new home, but it is not
> clear that keeping them in a central place is a good long-term solution.
> It also seems that every cross distribution has its own way of
> maintaining these, which is sad. I have some ideas floating for
> improving, but I put my work on hold to better understand the
> requirements. In order to get a better understanding, I am maintaining
> these check results on a per-package granularity for rebootstrap[1].
> 
> Personally, I am hoping for a future where packages that are being
> checked ship these check results. 

As you know I agree that this is probably better, but I still think
it's worth making what we currently have at least be shippable. 

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Re: bugs in bootstrap.debian.net (was: Re: The state of cross building)

[Wookey]

+++ Johannes Schauer [2016-01-31 15:27 +0100]:
> Quoting Stephen Kitt (2016-01-31 11:49:32)
> > For example, hhvm can't be cross-compiled because it
> > build-depends, directly and indirectly (via imagemagick), on 
> > libfreetype6-dev
> > (which contains /usr/bin/freetype-config and is therefore not multi-arch
> > co-installable).
> 
> Correct. Imagemagick's build dependency on libfreetype6-dev will draw in
> libfreetype6-dev:${hostarch} while libmagickcore-dev is multiarch:foreign and
> thus will be installed for the build architecture and thus in turn
> (transitively) depends on libfreetype6-dev:${buildarch}. But
> libfreetype6-dev:${hostarch} and libfreetype6-dev:${buildarch} are not
> coinstallable because they are not multiarch:same which practically is the 
> case
> because of /usr/bin/freetype-config as pointed out by Stephen. A fix could be
> to move /usr/bin/freetype-config to a separate binary package, make
> libfreetype6-dev multiarch:same (i didn't check if there are other problems
> with it) and make sure to fix all reverse dependencies which actually need
> /usr/bin/freetype-config. I don't know whether this would work or be 
> practical,
> I'm just using it here as an example to show how fixing these problems can be
> very difficult.

I think we need to bring this 'old-style foo-config' problem to the
fore and decide what we are going to do about it. Early on in multiarch
this issue was left on the 'worry about that later' pile because it
didb't prevent libraries being multiarched, only -dev packages. And
having -dev packages not being co-installable still allows quite a lot
of cross-building, so long as you only need the host arch _or_ the
build arch, not both at once. The further you get up the 'stack' the
more of a problem this becomes as dependency chans grow.

I see that there is now a lintian check for this issue whcih is great,
and gives us some idea of how big it is:
https://lintian.debian.org/tags/old-style-config-script-multiarch-path.html

So that lists 240 packages which are MA:same and also contain an
arch-specific foo-config script.

There are presumably several hundred more which contain a foo-config
script but are not listed as MA:same

So this is quite a big problem. 

The original multiarch discussions said 'just get everyone to use
pkg-config instead of internal foo-config', as then this issue doesn't
arise.

In many cases the pre-multiarch -config script was not
arch-dependent. It said '/usr/lib/foo'. It has _become_ arch dependent
because post-multiarch the lib is in '/usr/lib//foo.
Oh the irony.

A second part of this problem is that foo-config scrips sometimes do
more than pkg-config does. They are used to supply other information
about the build environment. I understand that xapian is an example of
this.

A bit of research to classify the scripts, how many packages (and
build-dependencies which use those scripts) are affected, what our
available solutions are and how many scripts are 'difficult', would be
good. I have a bit of time to apply to crossing so will try to get a
better understanding of the issue and put it on a wiki page.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Re: The state of cross building

[Wookey]

+++ Helmut Grohne [2016-01-31 20:13 +0100]:
> Hi Colin,
> 
> On Sun, Jan 31, 2016 at 04:51:26PM +, Colin Watson wrote:
> > Thanks for doing this.
> > 
> > How frequently will these be updated?  It would be nice for people to be
> > able to upload fixes and see the effects.
> 
> Thus far, these are one-shot rebuilds. It is the second attempt of mine.
> I crossed 1000 source packages last year and worked towards fixing
> tooling issues.
> 
> Doing them more frequently is something I would like to see in the
> future. We already expressed that vision at the bootstrap sprint in
> 2014. I guess that jenkins.d.n could afford a node doing cross builds,
> so the missing piece probably just is having someone write the code
> (https://anonscm.debian.org/git/qa/jenkins.debian.net.git). I can help,
> but not drive that.

We also expressed this desire at the debconf mini-sprint (which I
still haven't written-up - apologies for extreeme tardiness).

I have got as far as aquiring a box and installing debian on it. I
hope to set it up as a cross-buildd, and as Doko says, once we have
that set up, getting the cross-status into the PTS is the way to get
it generally actionned, although that also requires us to have
reasonably cogent advice for packagers on what they should/should-not
do. There is some here:
https://wiki.debian.org/CrossBuildPackagingGuidelines but as ever
there is a lot more that could be said and that page was last updated
in mid 2013. Quite a lot has changed since then.
 
Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Re: Fixing dependency resolution of britney

[Steve Langasek]

On Tue, Feb 02, 2016 at 11:55:19PM +0100, Johannes Schauer wrote:
> Quoting Niels Thykier (2016-02-02 23:27:21)
> > Britney does *not* look at Build-Depends.  Only (Pre-)Depends.

> okay, thanks for clarifying!

> > So, Britney's dependency resolver ("InstallabilityTester") actually supports
> > all of that.  What is lacking is support for passing the information to the
> > resolver.

> > Note though that:
> >  * Multi-arch - there are policy decisions involved.  Examples:
> >- Q: When is it permitted to depend on packages on foreign
> >  architectures?

> this sounds like before britney can accept any patches above question has to 
> be
> answered and agreed upon by the release team.

> Why would we want to not always permit binary packages to depend on
> packages of foreign architectures if these architectures are also release
> architectures and the binary packages are installable together with
> packages from the native architecture?

Because allowing arbitrary packages to have cross-dependencies has the
potential to negatively impact the installability of packages on a system
that has not been configured for multiarch.  We want to allow
cross-dependencies for certain use cases not well served by the current
infrastructure (e.g., cross-compilers).  We don't want packages to
inadvertently introduce cross-dependencies that break the
same-arch-bootstrappability of the archive, or that cause all our users to
have to download 2x as many Packages files to make full use of their
systems.

-- 
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: Fixing dependency resolution of britney

[Adam Borowski]

On Tue, Feb 02, 2016 at 06:46:52PM -0800, Steve Langasek wrote:
> On Tue, Feb 02, 2016 at 11:55:19PM +0100, Johannes Schauer wrote:
> > Why would we want to not always permit binary packages to depend on
> > packages of foreign architectures if these architectures are also release
> > architectures and the binary packages are installable together with
> > packages from the native architecture?
> 
> Because allowing arbitrary packages to have cross-dependencies has the
> potential to negatively impact the installability of packages on a system
> that has not been configured for multiarch.  We want to allow
> cross-dependencies for certain use cases not well served by the current
> infrastructure (e.g., cross-compilers).  We don't want packages to
> inadvertently introduce cross-dependencies that break the
> same-arch-bootstrappability of the archive, or that cause all our users to
> have to download 2x as many Packages files to make full use of their
> systems.

In that case, perhaps what you want is a hand-managed list of packages that
are allowed to have cross-arch dependencies.  If you also skip real checks,
this would be trivial to implement.

This way, britney's logic would remain purely single-arch.


-- 
A tit a day keeps the vet away.

Bug#813556: ITP: libprotocol-acme-perl -- Perl Interface to the Let's Encrypt ACME API

[Salvatore Bonaccorso]

Package: wnpp
Owner: Salvatore Bonaccorso 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libprotocol-acme-perl
  Version : 0.11
  Upstream Author : Stephen Ludin 
* URL : https://metacpan.org/release/Protocol-ACME
* License : Artistic-2.0
  Programming Lang: Perl
  Description : Perl Interface to the Let's Encrypt ACME API

The Protocol::ACME is a class implementing an interface for the Let's Encrypt
ACME API.

NOTE: This code at this point is functional but should be considered 'alpha'
quality.

The class handles the protocol details behind provisioning a Let's Encrypt
certificate.

The package will be maintained under the umbrella of the Debian Perl Group.

Bug#813562: ITP: ocrmypdf -- add an OCR text layer to PDF files

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: ocrmypdf
  Version : 3.1.1
  Upstream Author : James R. Barlow 
* URL : https://github.com/jbarlow83/OCRmyPDF
* License : MIT
  Programming Lang: Python
  Description : add an OCR text layer to PDF files

OCRmyPDF is a nice wrapper around the Tesseract OCR engine, and various
other tools to optimise the resulting PDF.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: bugs in bootstrap.debian.net

[Tollef Fog Heen]

]] Wookey 

> A second part of this problem is that foo-config scrips sometimes do
> more than pkg-config does. They are used to supply other information
> about the build environment. I understand that xapian is an example of
> this.

Those scripts can wrap pkg-config, and pkg-config already knows how to
provide user-defined variables, so this sounds like a problem that's
solveable.

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

Re: bugs in bootstrap.debian.net

[Helmut Grohne]

Hi Tollef,

On Wed, Feb 03, 2016 at 06:10:50AM +0100, Tollef Fog Heen wrote:
> Those scripts can wrap pkg-config, and pkg-config already knows how to
> provide user-defined variables, so this sounds like a problem that's
> solveable.

What sounds obvious isn't. The important bit here is which architecture
you are building for. pkg-config has an API for this: You invoke it as
$DEB_HOST_GNU_TYPE-pkg-config. Those foo-config scripts do not have this
API (with rare exceptions). Thus they do not know the host architecture
and have no way of correctly invoking pkg-config.

Yes, there were proposals checking $DEB_HOST_GNU_TYPE inside foo-config
scripts, but this will just break those scripts for those users that are
the reason for keeping them.

So this doesn't work, but I cannot tell you what works, sorry.

Helmut

Re: bugs in bootstrap.debian.net (was: Re: The state of cross building)

[Helmut Grohne]

Hi Wookey,

On Wed, Feb 03, 2016 at 02:49:07AM +, Wookey wrote:
> I see that there is now a lintian check for this issue whcih is great,
> and gives us some idea of how big it is:
> https://lintian.debian.org/tags/old-style-config-script-multiarch-path.html
> 
> So that lists 240 packages which are MA:same and also contain an
> arch-specific foo-config script.

The assumption that the tag would only hit MA:same packages is wrong. It
hits e.g. libgpg-error-dev, which is correctly not marked MA:same. In
defense, this tag is very young and correctly marked with with low
confidence.

> A second part of this problem is that foo-config scrips sometimes do
> more than pkg-config does. They are used to supply other information
> about the build environment. I understand that xapian is an example of
> this.

Another example for seeing pkg-config too limited is postgresql. #794103

> A bit of research to classify the scripts, how many packages (and
> build-dependencies which use those scripts) are affected, what our
> available solutions are and how many scripts are 'difficult', would be
> good. I have a bit of time to apply to crossing so will try to get a
> better understanding of the issue and put it on a wiki page.

Another problem is packages that ship both pkg-config files and
foo-config scripts. Those tend to be multiarch marked (hello icu
#776821), but still contain the foo-config. Thus reverse dependencies
can choose whether to use pkg-config or not and tend to get this wrong
(hello libxml2). These foo-config scripts are not going away, because
non-Debian users want them for backwards compatibility. What we really
need is a way to keep shipping them, that doesn't break our own tools.

I'm not sure that a future where we have lots of libfoo-legacy-dev
packages containing just foo-config is a bright one.

Helmut