Re: Does anybody plan to keep using sbuild with Squeeze or older chroots?
Johannes Schauer writes ("Does anybody plan to keep using sbuild with Squeeze
or older chroots?"):
> does anybody plan to use sbuild in Stretch with Debian Squeeze or older
> chroots?
Yes.
> I would like to remove some code from sbuild which is only useful
> for chroots with very old apt inside (specifically apt without
> support for [trusted=yes] in the sources.list). Maintaining this
> piece of code takes lots of time and testing otherwise, which I
> would avoid if it doesn't have users anymore.
How annoying.
> If you still want to be able to use Squeeze chroots for some reason, please
> shout!
I want to be able to build backports to old installations.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Does anybody plan to keep using sbuild with Squeeze or older chroots?
Ian Jackson writes ("Re: Does anybody plan to keep using sbuild with Squeeze or
older chroots?"):
> Johannes Schauer writes ("Does anybody plan to keep using sbuild with Squeeze
> or older chroots?"):
> > does anybody plan to use sbuild in Stretch with Debian Squeeze or older
> > chroots?
>
> Yes.
...
> > If you still want to be able to use Squeeze chroots for some reason, please
> > shout!
I should say, thanks for asmking.
And to those others who replied, I would like to point out that
answers of the form "oh no surely they don't" to questions like
Johannes's can be harmful.
> I want to be able to build backports to old installations.
Is there some other way for me to be able to do this which doesn't
involve all that annoying work ?
What would happen if we took older sbuild and arranged for it to be
coinstallable with the new sbuild, so that one could use sbuild-old
for the old chroots ?
Or perhaps there are other ways of doing this. Sadly I don't think
running a jessie chroot containing a lenny chroot (or whatever) is a
good plan...
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Does anybody plan to keep using sbuild with Squeeze or older chroots?
On Fri, Aug 19, 2016 at 01:01:23PM +0100, Ian Jackson wrote: > > does anybody plan to use sbuild in Stretch with Debian Squeeze or older > > chroots? > > Yes. I'm actually not doing Debian packaging for it, but at work there still are embedded machines running Lenny, where upgrading is simply not possible without buying new hardware (not only a new motherboard and CPU, but also I/O cards and so on). > > I would like to remove some code from sbuild which is only useful > > for chroots with very old apt inside (specifically apt without > > support for [trusted=yes] in the sources.list). Maintaining this > > piece of code takes lots of time and testing otherwise, which I > > would avoid if it doesn't have users anymore. > > How annoying. It's always annoying when old functionality is removed when there are still users. I can understand that the sbuild maintainers don't want to spend lot of time on it when there are only a few users. Is it possible to keep the code in sbuild, but just declare it obsolete and untested? As long as it keeps working it will keep its users happy. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
How to distinguish .udeb files from regular .deb files?
Hello,
I accidentally called "dpkg-name" on some *.udeb files and they got
renamed to .deb.
Looking inside dpkg-name, it tries to evaluate "Package-Type" [1], but
that is not contained in the control file of the binary package, so
always evaluates to "deb":
> 123 my $type = $fields->{'Package-Type'} || 'deb';
>
Is there some other (preferred) way to identify .udeb packages?
1. "Section: debian-installer"?
2. Some pages use the suffix "-udeb" or "-di" in their package names.
3. If the control file contains a "isinstallable" script.
> dpkg -I 'potential.udeb' | grep -q isinstallable
4. If the control files has a "Installer-Menu-Item" field:
> grep -I 'potential.udeb' | grep -q Installer-Menu-Item
Other ideas?
Or is there a definitive answer hidden somewhere?
Thanks in advance.
Philipp
[1]
Re: Does anybody plan to keep using sbuild with Squeeze or older chroots?
Hi, Quoting Ian Jackson (2016-08-19 14:04:40) > And to those others who replied, I would like to point out that answers of > the form "oh no surely they don't" to questions like Johannes's can be > harmful. I read their answers as: "I don't think it is necessary for sbuild to support a distribution that is so old that it doesn't receive any official or unofficial support anymore". > > I want to be able to build backports to old installations. > > Is there some other way for me to be able to do this which doesn't > involve all that annoying work ? > > What would happen if we took older sbuild and arranged for it to be > coinstallable with the new sbuild, so that one could use sbuild-old > for the old chroots ? > > Or perhaps there are other ways of doing this. Sadly I don't think > running a jessie chroot containing a lenny chroot (or whatever) is a good > plan... Old sbuild will not help you. The problem is mainly, that older chroots contain an apt installation that has no support for the [trusted=yes] option in sources.list. This in turn means that it is required of subild to sign the internal dummy repository. This signing happens with a private/public key pair that is generated by the host running sbuild. The challenge is, to make it such that the keys generated by gnupg on the host can be consumed by older gnupg inside the chroot. I did lots of work in this direction already by for example changing the export format for the keys generated by $(sbuild-update --keygen) but apparently there are still bugs around as recently reported by weasel via IRC. Since I sank lots of time into this issue of cross-gpg-version-compatibility already I was wondering if it is worth to spend more time on it than I already have or whether I can just rip out the whole key generation and consumption part. It is not needed anymore for any Debian release after squeeze (thanks to newer apt). If there are still users who plan to build for squeeze on sbuild from stretch, help to keep compatibility for squeeze would be very much appreciated. Thank you! cheers, josch signature.asc Description: signature
Re: Does anybody plan to keep using sbuild with Squeeze or older chroots?
Johannes Schauer writes ("Re: Does anybody plan to keep using sbuild with
Squeeze or older chroots?"):
> Old sbuild will not help you. The problem is mainly, that older
> chroots contain an apt installation that has no support for the
> [trusted=yes] option in sources.list. This in turn means that it is
> required of subild to sign the internal dummy repository. This
> signing happens with a private/public key pair that is generated by
> the host running sbuild. The challenge is, to make it such that the
> keys generated by gnupg on the host can be consumed by older gnupg
> inside the chroot. I did lots of work in this direction already by
> for example changing the export format for the keys generated by
> $(sbuild-update --keygen) but apparently there are still bugs around
> as recently reported by weasel via IRC.
Urgh.
(Would it not be possible to generate the key inside the chroot? I
guess there are probably other problems with that.)
> Since I sank lots of time into this issue of
> cross-gpg-version-compatibility already I was wondering if it is
> worth to spend more time on it than I already have or whether I can
> just rip out the whole key generation and consumption part. It is
> not needed anymore for any Debian release after squeeze (thanks to
> newer apt).
Right.
> If there are still users who plan to build for squeeze on sbuild
> from stretch, help to keep compatibility for squeeze would be very
> much appreciated.
My use cases for this are not sufficiently essential to me for me to
want to wrestle (or for me to want you to wrestle) the problems you
describe above. But perhaps someone else will volunteer.
Anyway, thanks.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#834819: ITP: openvpn-systemd-resolved -- integrates OpenVPN with systemd-resolved
Package: wnpp Severity: wishlist Owner: Eugene Zhukov *Package Name: openvpn-systemd-resolved Version: 1.1.1 Upstream Author: Jonathan Wright *URL: https://github.com/jonathanio/update-systemd-resolved *License: GPL Description: integrates OpenVPN with systemd-resolved This is a helper script designed to integrate OpenVPN with the systemd-resolved service via DBus instead of trying to override /etc/resolv.conf, or manipulate systemd-networkd configuration files. Since systemd-229, the systemd-resolved service has an API available via DBus which allows directly setting the DNS configuration for a link. This script makes use of busctl from systemd to send DBus messages to systemd-resolved to update the DNS for the link created by OpenVPN.
Bug#834825: ITP: glbinding -- cross-platform C++ binding for OpenGL
Package: wnpp Severity: wishlist Owner: Ghislain Antony Vaillant * Package name: glbinding Version : 2.1.1 Upstream Author : CG Internals GmbH * URL : https://github.com/cginternals/glbinding * License : Expat Programming Lang: C++ Description : cross-platform C++ binding for OpenGL Long-Description: glbinding leverages modern C++11 features like enum classes, lambdas, and variadic templates, instead of relying on macros; all OpenGL symbols are real functions and variables. . It provides type-safe parameters, per feature API header, lazy function resolution, multi-context and multi-thread support, global and local function callbacks, meta information about the generated OpenGL binding and the OpenGL runtime, as well as tools and examples for quick-starting your projects. This package is a build dependency for forge. It will be maintained alongside forge under the Debian Science Team.
Re: Does anybody plan to keep using sbuild with Squeeze or older chroots?
Hi, Quoting Ian Jackson (2016-08-19 14:25:52) > (Would it not be possible to generate the key inside the chroot? I > guess there are probably other problems with that.) that would require lots of time and entropy - unless somebody knows how to trick gpg to generate a private/public key pair from a dummy entropy source. A better approach would probably be to copy everything that needs signing from the chroot to the host, do the signing there and then copy the signatures back into the chroot. But this still needs somebody to implement and test it... Thanks! cheers, josch signature.asc Description: signature
Re: Bug#834756: ITP: powershell -- scripting language interpreter built on .NET
On 18 August 2016 at 18:17, Marcin Kulisz wrote: > On 2016-08-18 16:27:23, Luke W Faraone wrote: >> Package: wnpp >> Severity: wishlist >> Owner: Luke W Faraone >> >> * Package name: powershell >> Version : 6.0.0~alpha9 >> Upstream Author : Microsoft >> * URL : https://github.com/PowerShell/PowerShell >> * License : Expat >> Programming Lang: C# >> Description : scripting language interpreter built on .NET >> >> Microsoft recently released PowerShell as free software, and this month >> announced support for Linux platforms. >> >> >From a parausal of the source code, it appears to be suitable for inclusion >> >in >> Debian. > > Most likely I'm missing something but what's the use case for Powershell on > Debian? On more practical note - there is a bunch of tooling and cmdtets to manage remote service from powershell. E.g. to manage ec2 / azure. As well as locally hosted services as far as I understand (e.g. connect to / manage via remote API Microsoft what-not servers). I'm guessing this will become more relevant as more of Microsoft software is opensourced and/or ported to Linux - eg. as the previously announced Microsoft SQL Server. Niche, but useful for the few. Kind of like R - I am not yet sold on it, and find it irrelevant, but there is a huge community of people using it. I'm more of a SageMath / numpy / scipy person. However, OMG RStudio with knitr is nice, I wish I could write lab reports in Markdown with R graphs like that back when I was in the university. On the similar note, there is a large community of people using powershell. -- Regards, Dimitri.
Re: Bug#834756: ITP: powershell -- scripting language interpreter built on .NET
On 2016-08-19 15:34:14, Dimitri John Ledkov wrote: > On 18 August 2016 at 18:17, Marcin Kulisz wrote: > > Most likely I'm missing something but what's the use case for Powershell on > > Debian? > > On more practical note - there is a bunch of tooling and cmdtets to > manage remote service from powershell. E.g. to manage ec2 / azure. As > well as locally hosted services as far as I understand (e.g. connect > to / manage via remote API Microsoft what-not servers). I'm guessing > this will become more relevant as more of Microsoft software is > opensourced and/or ported to Linux - eg. as the previously announced > Microsoft SQL Server. Ha, so we're trying lure Windows admins to Debian under the pretence of 'you can do the same from Debian' and then quietly make them drop proprietary platforms. Sounds like a good plan to me. Thx Dimitri :-) -- |_|0|_| | |_|_|0| "Panta rei" | |0|0|0| kuLa | gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3 3DF1 A4DF C732 4688 38BC F121 6869 30DD 58C3 38B3 signature.asc Description: PGP signature
Re: Bug#834756: ITP: powershell -- scripting language interpreter built on .NET
On August 19, 2016 10:44:44 AM EDT, Marcin Kulisz wrote: >Ha, so we're trying lure Windows admins to Debian under the pretence of >'you >can do the same from Debian' and then quietly make them drop >proprietary >platforms. Sounds like a good plan to me. Embrace, extend, extinguish? ;-) -- Harlan Lieberman-Berg ~hlieberman
Bug#834835: RFP: ShogiGUI -- GUI for japanese Chess (Shogi)
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: ShogiGUI Version: 0.0.6.1 Upstream Author: [shogix...@gmail.com] Can't figure out who the author is. URL: [http://shogigui.siganus.com/] License: [MIT/X,] Description: This is a GUI for Shogi, which is japanese Chess. The program is developed since 2015 and has a lot of features which are really up-to-date. I know that in debian there are some shogi-apps, but they are all quite aotdated. Hence it would be great if Shogi-GUI could be integrated. At the moment it is version 0.0.6.1 but very rapidly developed. Some Features: - supports english language (after you've figured out going to options, change it and restart the program) - supports USI-Engines - shows thinking - uses arrows on the board to show moves - also shows all book moves as arrows - supports branches - analyzes and considers modes - has a nice Notation-tree-window - supports user own images for piece, board, ... - supports a score graph - it even supports second (third, fourth, ...) best move!!! (Is GPSfish maybe finaly supporting the searchmoves-command. So the - winboard-protocol - version from HGM will no longer be the only one) Yours Andreas Hausmann
Re: Bug#834756: ITP: powershell -- scripting language interpreter built on .NET
Christoph Egger writes: > Marcin Kulisz writes: >> Most likely I'm missing something but what's the use case for Powershell on > > I don't know, what's the usecase for tcsh or lua? tcsh is to support legacy scripts, but, very good question: What *is* the use-case for Lua actually? :-) -- CYa, ⡍⠁⠗⠊⠕
Re: Bug#834756: ITP: powershell -- scripting language interpreter built on .NET
On 08/19/2016 08:15 PM, Mario Lang wrote: Christoph Egger writes: Marcin Kulisz writes: Most likely I'm missing something but what's the use case for Powershell on I don't know, what's the usecase for tcsh or lua? tcsh is to support legacy scripts, but, very good question: What *is* the use-case for Lua actually? :-) To rewrite PowerShell in it.
Bug#834865: ITP: libjs-jquery-selectize.js -- Extensible jQuery-based custom select UI control
Package: wnpp Severity: wishlist Owner: Sergio Durigan Junior * Package name: libjs-jquery-selectize.js Version : 0.12.2 Upstream Author : Brian Reavis * URL : https://github.com/selectize/selectize.js * License : Apache-2.0 and Expat Programming Lang: JavaScript Description: Extensible jQuery-based custom select UI control Selectize is an extensible jQuery-based custom select UI control. It's useful for tagging, contact lists, country selectors, and so on. The goal is to provide a solid & usable experience with a clean and powerful API. . Features . * Smart Option Searching / Ranking . Options are efficiently scored and sorted on-the-fly (using libjs-sifter.js). Want to search an item's title *and* description? No problem. . * Caret between items . Order matters sometimes. Use the left and right arrow keys to move between selected items. . * Select and delete multiple items at once . Hold down the CTRL key to select more than one item to delete. . * Díåcritîçs supported . Great for international environments. . * Item creation . Allow users to create items on the fly (async saving is supported; the control locks until the callback is fired). . * Remote data loading . For when you have thousands of options and want them provided by the server as the user types. . * Clean API and code . Interface with it and make modifications easily. . * Extensible . Plugin API for developing custom features (uses libjs-microplugin.js). . * Touch Support This package is a dependency necessary for pagure. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#834866: ITP: python-whitenoise -- static file serving for WSGI applications
Package: wnpp Severity: wishlist Owner: Antonio Terceiro * Package name: python-whitenoise Version : 3.2.1 Upstream Author : David Evans * URL : http://whitenoise.evans.io * License : MIT/Expat Programming Lang: Python Description : static file serving for WSGI applications With a couple of lines of config, WhiteNoise allows your web app to serve its own static files, making it a self-contained unit that can be deployed anywhere without relying on nginx, Amazon S3 or any other external service. This is specially useful if you want to deploy a WSGI application in an application container (e.g. docker). I plan to import this package into the Debian Python Modules Team repositories, even though I don't plan to get myself deeply involved with the team. I will subscribe to this specific package through the package tracker. signature.asc Description: PGP signature
Bug#834869: ITP: keysafe -- back up secret keys to cloud servers
Package: wnpp Severity: wishlist Owner: Sean Whitton * Package name: keysafe Version : 0.20160819 Upstream Author : Joey Hess * URL : https://joeyh.name/code/keysafe/ * License : AGPL-3 Programming Lang: Haskell Description : back up secret keys to cloud servers Upstream synopsis: > Keysafe backs up a secret key to several cloud servers, split up so > that no one server can access the whole secret by itself. > A password is used to encrypt the data, and it is made expensive to > decrypt, so password cracking is infeasibly expensive. LWN write-up: https://lwn.net/Articles/696765/ The intended audience of keysafe is those using secret keys to encrypt only their personal data, when storing it in the cloud. Such a user doesn't need to take the security precautions that a Debian Developer or Debian Maintainer must take to protect their secret key. However, they still don't want to lose it and thus invalidate their backups. Keybase is designed to make it easy to backup secret keys in the cloud for this kind of user. Although this software is experimental, it has the potential to enable a lot more Debian users to use public/private key cryptography to protect the data that they store in the cloud. I intend to package this and submit it for upload to experimental. I want to do this because I believe it will enable a lot more testing, and useful feedback submitted to Joey. In particular, it will enable feedback from those who know a lot about cryptography but not much about Haskell. Further, we will want it in unstable eventually, and getting the packaging in shape in advance makes that easy (Joey isn't the kind of upstream to abandon the software while it's still alpha). -- Sean Whitton signature.asc Description: PGP signature
Re: Bug#834756: ITP: powershell -- scripting language interpreter built on .NET
On Thu, Aug 18, 2016 at 12:17 PM, Marcin Kulisz wrote: > On 2016-08-18 16:27:23, Luke W Faraone wrote: >> Package: wnpp >> Severity: wishlist >> Owner: Luke W Faraone >> >> * Package name: powershell >> Version : 6.0.0~alpha9 >> Upstream Author : Microsoft >> * URL : https://github.com/PowerShell/PowerShell >> * License : Expat >> Programming Lang: C# >> Description : scripting language interpreter built on .NET Heh... ya' know what... I can recall a time when I had to scramble to figure out how to deploy a windows system in a particular environment so that I had Windows available so that I could load up a powershell script. In typical Windows fashion, the effort it took me to deal with the "enhanced security features" windows provides was quite frustrating, on top of having to find a way to run some queries to grant myself domain admin rights because 20,000 people were impacted and people didn't think it was a problem worth staying late for. Anyway, if I could have run "aptitude install powershell" and run the queries directly against our problem child from my debian workstation, well... that'd have been quite swell, pardon my language. As a Debian guy that gets cranky outside of *nix-land, I think powershell is a pile of garbage, but I've been in positions where having it in the repos would have been like a gift from god delivered on a silver/gold platter. Side note... I'm actually incredibly impressed that microsoft released powershell with such a free and open license. I don't get the impression this is actually the powershell-in-windows source. I get the impression it's just a portion, but... whatever. It also seems like it's sort of a trial to see if they want to continue open sourcing MS SQL (I don't think they did, yet...). I've cried a few times in meetings where they decide that's the DB of choice. Why? MariaDB is just so much nicer and easier and has support and dummy-proof docs... anyway, I would have been much less frustrated at the decision if aptitude install mssql-server were a thing. I can still deploy that with a config management system! :D
