Re: ISO download difficult

[Paul Wise]

On Wed, Dec 6, 2017 at 7:00 AM, Guus Sliepen wrote:

> In my eyes, that is just moving the choice to an earlier point in time
> when the user might not have enough information to make the decision,
> for example because of brand new hardware. But, having two installers
> side by side is a very good option, and then also have the non-free
> version prompt the user when it detects that non-free firmware is needed
> to get a fully operating system. Also, the purely free version could
> point to the non-free installer if non-free firmware is required.

I think install time is way too late to be doing prompting for
firmware because you can't download WiFi firmware over WiFi if you
don't have the WiFi firmware yet, possibly the same with some Ethernet
cards. That seems to be the biggest problem with non-free firmware
people are having. So, we need to move the non-free firmware or no
non-free firmware choice earlier in the process, to before the d-i ISO
has been downloaded. In addition, for a lot of users it is difficult
to impossible to determine which hardware they have, let alone if it
requires firmware or if that firmware is free, non-free but available
in Debian, non-free+redistributable but not in Debian or even
non-redistributable entirely. By enhancing win32-loader (and creating
similar tools for distros/Android/macOS) and promoting that as the
primary install mechanism for Debian, we can detect the firmware
requirements of the current system and educate the user about those,
including the downsides of that firmware being non-free or
non-redistributable. If we did this we could even drop the ISOs that
contain non-free firmware.

> I'd avoid emotional words entirely. Just say that non-free firmware is
> provided as-is and does not allow modifications to fix bugs or add
> functionality, in contrast with the vast majority of the software in
> Debian, which does guarantee those properties.

Seems reasonable, as long as we indicate which actors are responsible
for that situation, for example it should say " does not allow
modification ..." or "The company that built your device does not
allow modification..." etc. We don't want people to be blaming Debian
for the non-freeness on their systems.

> I have no illusions that a competitor to x86 will magically be more free.

RISC-V is definitely not going to be more free than x86 (except if you
are a CPU/SoC vendor), though there are some parts of that ecosystem
that definitely will be open down to the silicon designs sent to
Foundries.

> I would just keep it neutral and stick to facts.

It would probably be a good idea to link to the free/SC/DFSG pages on
the website in addition.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian Stretch new user report (vs Linux Mint)

[Paul Wise]

On Wed, Dec 6, 2017 at 1:46 AM, Didier 'OdyX' Raboud wrote:

> * splitting non-free in subsets;
> * adding a non-free-firmware area;

I think we don't want either of these, instead we should *add*
additional Packages files for each of the classes of non-free things
that people want to be able to isolate from the rest of non-free,
"firmware" being the first one and probably the only one.

After talking with the apt maintainers on IRC and some
experimentation, I think this is doable and it definitely does not
require the GR process.

The parts that need to be patched seem to be:

Each firmware package to use 3-part Section fields like
non-free/firmware/sound. Initially dak could override all of the
packages we want in that subcomponent.

dak for dealing with 3-part Section fields, adding the new
non-free/firmware component, generating the new Packages files and
adding them to Release files.

d-i for adding the non-free/firmware component instead of non-free.

Possibly aptitude/packages.d.o/lintian for dealing with 3-part Section fields.

Policy for describing 3-part Section fields and listing allowed ones.

Alternatively, we could end the conflation between the Section and
Components but that would require more changes.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian Stretch new user report (vs Linux Mint)

[Paul Wise]

On Tue, Dec 5, 2017 at 6:18 AM, Philipp Kern wrote:
> On 04.12.2017 19:03, Holger Levsen wrote:
>> yes, I also agree this would work and be better than the status-quo.
>> however I'm inclined to believe doing this and adding a fourth repo,
>> non-free-firmware (additionally to main, contrib and non-free) would
>> be even better and also not need a GR.

I agree that having subsets of non-free would be useful for folks who
don't need all of it, but they should be subset components like
non-free/firmware rather than top-level components like
non-free-firmware.

> I like that this *finally* gets some traction. I have floated a GR
> before but people seem to be reluctant to have yet another vote.

I don't think we need a GR to do sub-setting of archive components,
just dak coders.

> I guess the question from my side is if the list of archive components
> in §5 of the Social Contract is supposed to be exhaustive or not. I.e.
> if we need to change that or not. If we don't need to: yay. (Maybe
> because we editorially consider firmware not to be software or something.)

If we go with the subset approach I suggest the firmware packages
would still be in the non-free/contrib "areas" and still be in the
pool/non-free directory on our mirrors but would also be mentioned in
the non-free/firmware/*/Packages files, which would be the firmware
subset of the non-free component.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: ISO download difficult (was: Debian Stretch new user report (vs Linux Mint))

[Paul Wise]

On Tue, Dec 5, 2017 at 12:34 AM, Jonathan Dowland wrote:

> Yes, I've never managed to get d-i to find firmware I've put on a USB
> myself, and always resorted to this approach. I never got around to
> reading the source to figure out where it expects to look (nor to
> improve the docs etc.)

The docs say to dump firmware files or packages on a USB stick:

https://www.debian.org/releases/stable/amd64/ch06s04.html.en

To prepare a USB stick (or other medium like a hard drive partition,
or floppy disk), the firmware files or packages must be placed in
either the root directory or a directory named /firmware of the file
system on the medium. The recommended file system to use is FAT as
that is most certain to be supported during the early stages of the
installation.

The wiki documentation for this doesn't mention the root directory, so
perhaps this has been improved in recent releases:

https://wiki.debian.org/Firmware#Firmware_during_the_installation

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Should tasks be considered harmful?

[Paul Wise]

On Mon, Dec 4, 2017 at 9:18 PM, Bjørn Mork wrote:

> No, not really.  I want the installation to end up with a *more*
> predictable set of packages.  Attempting to do any sort of harware based
> package selection will result in less predictability.

Understood.

> Imagine a Debian user trying to assist another Debian user.  If
> you can't even establish a package set baseline, then where do you
> start?

There is already the possibility of different package sets, people can
install different desktops or even no desktop using d-i. They can also
add or remove packages after the installation is complete.

> No, I definitely don't want some magic guessing of what packages I need.
> I want the default install to include a large enough set of packages
> supporting as many use cases as reasonable.  If there are more than one
> alternative package providing a given service, then the default should
> be the one supporting most use cases.  At least if there is little or no
> doubt. Which I believe covers the wicd vs NM case.

That seems reasonable, I guess you should then file a bug against any
tasks that depend on wicd and ask them to switch to NM, but see Jonas'
response.

OTOH the number of use-cases supported by Debian is high.
Does everyone need to access NTFS/HFS+ filesystems?
Does everyone need to access iOS devices?
Does everyone need to interact with LEGO devices?
Does everyone need the app for firing foam missile launchers?

> Hardware detection during installation will also fail for common use
> cases like plugging in a USB modem after installation.  My example had a
> built-in modem, but it could just as well be an external one.

isenkram was primarily developed for the use-case of plugging in
devices and then getting the appropriate software installed and the
device working, my suggestion of adding isenkram to the installer was
primarily so that devices plugged in at install time will always work
on first boot. So isenkram could be both in the installer and in the
installed system.

> And even if this example was related to hardware enablement, that is
> only part of the problem.  Replacing any core system package with
> something other users won't consider "default" is going to cause
> confusion. I guess the definition of "core system package" is something
> which can be discussed.  But it is a fact that all the DEs come with
> their own set of system daemons, libraries and tools.  Take it to the
> extreme and you end up with the kernel being the only shared package
> between two different DE installations.

Debian hasn't yet defined any immutable "standard systems", it might
be interesting to do that and put them in ostree like Endless are
doing:

https://debconf17.debconf.org/talks/41/

That would require some repacking of "apps" .deb files into Flatpaks.

https://debconf17.debconf.org/talks/59/

It is definitely true that each desktop reinvents a lot of wheels, but
some things (like libsecret or gnome-shell or GTK+ or Qt) are shared
between some of them.

> I just realized that this might appear as if I am opposing choice.  That
> is not my intention.  What I am trying to say is that I found the
> results of the task selection confusing, because it wasn't clear to me
> that I was actually choosing a different Debian derivative by selecting
> one of the desktop tasks.  If you are going to continue to provide these
> variants, then it would have been better (for me at least) if every task
> was packaged as a separate installer image.

The Debian installer doesn't install any Debian derivatives (like
Ubuntu), it only installs subsets of the whole of Debian, but I assume
that "subset" is what you meant by "derivative".

To a small extent the different tasks are already packaged as
different installer images, there is an Xfce installer CD.

> This would also reduce the number of necessary questions during install.

This is probably a good thing for new users.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian Stretch new user report (vs Linux Mint)

[Paul Wise]

On Mon, Dec 4, 2017 at 7:39 PM, Jonathan Dowland wrote:

> Are we promoting hardware that *doesn't* require non-free firmware (not
> drivers, there is an important distinction) at the moment?

On our website, we don't promote hardware, just people/companies that
you can pay to install Debian for you:

https://www.debian.org/distrib/pre-installed

On our wiki, there are numerous install howto pages but we don't
separate those by non-free firmware requirement, just by vendor.

https://wiki.debian.org/InstallingDebianOn

> Where are we prominently explaining the problem?

In our install manual at least:

https://www.debian.org/releases/stable/amd64/ch02s02.html.en
https://www.debian.org/releases/stable/amd64/ch02s03.html.en

> Where are the links to the unencumbered hardware that
> people could/should be using instead?

We can definitely do better here, especially after promoting h-node in
a press release:

https://www.debian.org/News/2014/20140908

> Where are the Debian developers working on better supporting such
> hardware, where are the blog posts on Planet Debian about it, where are
> the unencumbered hardware platforms being distributed with Debian
> pre-installed?

mafm posted about his work on the RISC-V architecture port a while
ago, which has the potential to be

> Instead we prevent close to 100% of our new potential users from
> installing on their laptops due to the firmware issue. Those users are
> much more likely to go elsewhere than to be educated as to the merits of
> free software and unencumbered hardware.

We can definitely do better here and I think it is feasible to do
both, as mentioned in my other mail.

> Are *you* using non-free firmware?

Unfortunately yes, all of the devices I've acquired in recent history
have required firmware from Debian non-free and also had embedded
non-free firmware. Multiple devices even ran Linux and most of those
were GPL-violating, one even violated the BSD license for some of the
userland.

https://wiki.debian.org/PaulWise#contribnonfree

> I can understand the discomfort of grasping this nettle. But are you
> completely closed to the idea of revisiting our core value documents
> at all? The Social Contract and DFSG were written a long time ago.
> Should the project not be open to looking at what our collective values
> are today, or are we beholden to the terms layed down by braver people,
> all those years ago?

Personally, I think the values written down in the SC/DFSG are not
where we are going wrong, but our execution of them could use some
work.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian Stretch new user report (vs Linux Mint)

[Paul Wise]

On Mon, Dec 4, 2017 at 7:31 PM, Jonathan Dowland wrote:

> IMHO, we need to go (more) one way or the other. We either reaffirm that
> firmware is in-scope for our DFSG values and stop compromising it with
> the non-free install images, or we look to revise the DFSG in line with
> modern realities and can "promote" the status of the installer images
> with firmware. That seems much harder: there have been brave efforts
> to reform the DFSG before, not least by Ian; and they have not
> succeeded. However, I think the project is healthier in one way from
> those days, we've weathered some fierce debates and I think we've grown
> as a project in the way we communicate together to resolve problems.

I don't like this dichotomy and I think we can do better than choosing
one or the other. Instead, expose the reality of the situation to
users, state Debian's position on non-free firmware, state that the
practical downsides of using (or not) non-free firmware, mitigate them
using more imaginative solutions where possible, give users the choice
to use non-free firmware if they want to and also give them the choice
to use just the firmware part of non-free by having a
non-free/firmware subset.

For example, we could offer the Debian installer itself or
win32-loader style tools as apps on other operating systems, where
they can detect the hardware present but still access the network to
download firmware from Debian non-free or extract firmware from the
filesystem of the operating system it runs under. This approach is
practical for Windows (win32-loader or WSL), Linux/BSD distros
(perhaps via Flatpak) and possible for Android (several of apps exist
already, the android-sdk is being packaged) based devices right now,
for macOS devices it seems a bit more tricky, perhaps Python & Tk
would work as an installer bootstrap app. I guess Debian can give up
on iOS devices due to lockdown (though there is one person on
#debian-mobile who was working on trying to get Debian installed on an
iPhone) and consoles/TVs/IoT and other "appliance"-class devices due
to lockdown and/or GPL violations.

https://wiki.debian.org/ChrootOnAndroid
https://wiki.debian.org/AndroidTools
https://en.wikipedia.org/wiki/Usage_share_of_operating_systems

> I know I've needed non-free firmware on every single laptop I've ever
> used Debian with and I suspect that's true for nearly everyone.

That is the nature of the hardware industry these days, except perhaps
for some future corners of the RISC-V community and a few minor
exceptions like carl9170.fw or open-ath9k-htc-firmware. Even hardware
that allegedly "doesn't need non-free firmware" usually has it
embedded instead.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian Stretch new user report (vs Linux Mint)

[Paul Wise]

On Mon, Dec 4, 2017 at 5:22 AM, Marc Haber wrote:

> Debian is also about providing an Universal Operating System, and I
> have seen BIG installations of Debian on server farms moving to PragBF
> because the Broadcom network chips on those servers required people
> jumping through hoops while PragBF just works.

Could you link to PragBF? I can't find any mention of it on web search engines.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Should tasks be considered harmful?

[Paul Wise]

On Mon, Dec 4, 2017 at 6:43 AM, Bjørn Mork wrote:

> But how would a user without any previous knowledge of modemmanager or
> Linux networking be able to figure this out?

It sounds like you are looking for isenkram to be integrated into the
installer so that the knowledge of which package maps to which
hardware is available to the user when doing an install and for
modemmanager to declare which devices it supports via AppStream and
for installing modemmanager to pull in networkmanager and remove wicd:

https://tracker.debian.org/pkg/isenkram
http://people.skolelinux.org/pere/blog/tags/isenkram/
https://wiki.debian.org/AppStream/Guidelines#Announcing_supported_hardware

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian Stretch new user report (vs Linux Mint)

[Paul Wise]

On Fri, Dec 1, 2017 at 1:36 AM, Arturo Borrero Gonzalez wrote:

> * no support for the wifi interface of the dekstop machine (this was
> expected, fixed by installing non-free package by hand, since no
> network)

It would have been best for him to download the ISO with non-free
firmware embedded, do you know how he made the decision to download
the ISO without non-free firmware?

> * no support for RW on NTFS drives, only RO. This wasn't fixed even by
> installing ntfs-3g [0].
> I didn't have the time to investigate the NTFS issue myself, sorry :-(

Sounds like you need to get him to file a bug against ntfs-3g and
against whichever meta-package or other component should be installing
ntfs-3g. For the latter, perhaps gnome-software/PackageKit needs some
sort of filesystem detector that installs relevant packages. I was in
the same position recently with the Apple HFS+ filesystem.

> Both issues together were enough for my friend to directly move to
> Linux Mint in both machines, which is not fine

That is a shame, since Linux Mint isn't exactly known for its security
support. I'd strongly suggest he move to Debian with cinnamon and
other Linux Mint apps.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: please check links and text in Spanish.wml

[Paul Wise]

On Thu, Nov 30, 2017 at 3:19 AM, eamanu15 . wrote:

> I am new.. Where can I join to start contribute with commits? There is a
> team in alioth? I can commit directly to anonscm repo?

Please read the instructions for website contributors and website
translators and send any translation updates you have to the
translation co-ordinators. Other contributions should be sent as bugs
against the www.debian.org pseudo-package.

https://www.debian.org/devel/website/
https://www.debian.org/devel/website/translating
https://www.debian.org/devel/website/translation_coordinators
https://www.debian.org/international/Spanish
https://www.debian.org/international/spanish/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Accepted flasm 1.62-10 (source) into unstable

[Paul Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 23 Nov 2017 09:54:16 +0800
Source: flasm
Binary: flasm
Architecture: source
Version: 1.62-10
Distribution: unstable
Urgency: medium
Maintainer: Paul Wise <p...@debian.org>
Changed-By: Paul Wise <p...@debian.org>
Description:
 flasm  - assembler and disassembler for Flash (SWF) bytecode
Closes: 882408
Changes:
 flasm (1.62-10) unstable; urgency=medium
 .
   * Add patch by Adrian Bunk to prevent FTBFS with parallel builds (Closes: 
#882408)
Checksums-Sha1:
 0f497dd8f0fcc21400ac5c2704d931e1136dc46a 1843 flasm_1.62-10.dsc
 47cd2179d0be58e54727b69ffc579f530bf62d17 8308 flasm_1.62-10.debian.tar.xz
Checksums-Sha256:
 a093bc4610be47fa633e5084f477faa0216d871f1b9d36e7281008a654938052 1843 
flasm_1.62-10.dsc
 a2a63b8e0c3f341e21afd50aca5437522e58cff6e2f7169529d0a0b8498a 8308 
flasm_1.62-10.debian.tar.xz
Files:
 b13646d907ca27e3f1ba5a599ab8de9f 1843 utils optional flasm_1.62-10.dsc
 7dafd3ff13ef0922edba0b1e11c2a1a3 8308 utils optional 
flasm_1.62-10.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAloWLEQACgkQMRa6Xp/6
aaO5GRAAp5MHPX8NrkmD/4qBVa5IDIRZQW5ZJwfFVTMGZSkWlpnvIzqV5FoqBeHX
Joxo6aG3aWoqXv0/pKytBB1txuMiOupk1g0OW3ttCuJM3mO64gRAMTCyUEGf5RP5
yV26j2s4JKiBVEHC/7IqIqzOa5868uQDbrOkpw30AxrraDYe0qBL2ulEZb72LjsA
1ELcZByYpS4ZQYa9Bv1wAjqD5DWBzoy8ggrbpkO5Gq0Vi2Gp+I9r9BseqXKeL0tI
teHodKvfRX/8XyMektDqpaj0W85E/hSRC8KgTszmbVcIgRkr1wsFSTl3WufPvhF0
eunzJno+CliBHpVGd7AMBcq5gZ/Qdk3uqWoGLMvsHvlqpliDqLgVwMym6BSJfMWk
U1RLAs64hj8RXt9jIps9c7EpMsmTn/+pjL1BJaQH9HDH+8izacPDh3MYr++RwfPI
BlGtXCA6Hs2nN8DzPtRO6LT6586FS+Xhy+blas+W3wgypME3aiFVV8qrWdbw0vPO
2m/oTSf1FoeSKAtvm2bJA7U9QbqKAp21NQ7WEle+KMg4qajgchW1VjWdykevymFE
vAJhpfIcP0u0mSNU2hgN8o7Zt7LVxL7msFW31W/ZNPOfmmvm+weaNOvONVmrLJU9
Y4YOwO8OOHl3c4Ob3faB8GLsY2mJlQH0jIyK3q2DpLlD12yNw5Y=
=wRlR
-END PGP SIGNATURE-

Re: Proposed change of offensive packages to -offensive

[Paul Wise]

On Wed, Nov 22, 2017 at 8:42 PM, Phil Wyett wrote:

> In my honest opinion, rating certain content types within a package should be
> done along the lines of PEGI[1]. A self regulatory rating done as part of a
> social policy and administered by the particular packages maintainer. All
> subsequent questioning of rating would be done via bug reports against the
> particular package.

Some rating related resources are at:

https://wiki.debian.org/OpenRating

> * Rating set within debian folder - maybe rating file.

Personally I think a debtags/screenshots style service would be better here.

> * Seen on packages.d.o, PTS and query by apt etc. for package.
> * Should not be auto installed as a recommends etc.

Preferably configurable, perhaps by installing packages with standard names.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Accepted flasm 1.62-9 (source) into unstable

[Paul Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 22 Nov 2017 16:20:32 +0800
Source: flasm
Binary: flasm
Architecture: source
Version: 1.62-9
Distribution: unstable
Urgency: medium
Maintainer: Paul Wise <p...@debian.org>
Changed-By: Paul Wise <p...@debian.org>
Description:
 flasm  - assembler and disassembler for Flash (SWF) bytecode
Closes: 882364
Changes:
 flasm (1.62-9) unstable; urgency=medium
 .
   [ Helmut Grohne ]
   * Fix FTCBFS: Let dh_auto_build pass cross compilers to make. (Closes: 
#882364)
 .
   [ Paul Wise ]
   * Change priority from extra to optional
   * Move upstream meta-data file to the correct location
   * Switch to machine-readable copyright files
   * Update links from http to https where possible
   * Now complies with Debian Policy 4.1.1
   * Convert clean override to debian/clean file
   * Switch to debhelper compat version 10
Checksums-Sha1:
 d1428101a512da1b704b58e4a433f9727659d298 1839 flasm_1.62-9.dsc
 caa0c8b0caeaa2b0e1eca4edcd947140450b371c 8040 flasm_1.62-9.debian.tar.xz
Checksums-Sha256:
 11c11ca9043d2c839f872f1f9c8ad227c9c798ccaab92fe3f8145b0ca2112c3f 1839 
flasm_1.62-9.dsc
 a204ec1f8e3720dea2bfdbee129e2fef3847e88767628ca1e169538bbf2ef9d5 8040 
flasm_1.62-9.debian.tar.xz
Files:
 df8b14b70ba965b968830a37e834a65f 1839 utils optional flasm_1.62-9.dsc
 79d166f7d4ed93dbd7e2759b12a6df97 8040 utils optional flasm_1.62-9.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAloVNNUACgkQMRa6Xp/6
aaPzYg/+KgWforWrDGqdMepKPj5OL0XB36dSAUYp6zv12eiR/V8nFp2aMXCantxX
008itZ8mrx2rXAXYBEY/X49mL9TXtk195fx7KEX4RPw5kubMXhpxo5oWcHOiRnfx
QNDGp9Icf+I2V1uji0mE4TuN0nzF8MGgVxgA2l44/r5mR+kfcj2kBeHSAyfYE94H
nGMU0m+jfS4yqeHL0ilEuVGgpda1kPb98HZKUNLnBoIneGfF52uqrLQCM8plWAgK
wpI/ycKKxEhDH224P4BpeNfsfZXeQCi4I/ELDzw6ZgXL2Kw09x21X6B+9dERQkMi
u6PqDvRqf33Eqj09lmdePRn6lfASQ4yqdfkAH00ymMFmD5nyYhDIdswvaSAHF4Os
e2hBa8QynCBEKH76CJQCt26TlOayCN4YOZymNNpQSl1FECQG3EwbPF25V7Fib98A
SEFt+KI16YbhhO/88GoEU+uFKJ9plM339aXj2d3fNXKN3b75jItF2UCjyQaZvU35
Oi/so/ctS3yvB8lathKdN9LZuIfskICZoXZMFoeDSZaKjs37Yxuw6voj7xQDcpBl
Nzchti6YWPDZTCsAfAmdEOarY7aFZ74psfVS9YniYvtNMoDWfT3yhuKEM/+4bMh4
ifTuOxWcxnykFjS0W+Pv0gd8/kapD8QwgOG9T1OsNnQJA2tuvRA=
=M4MW
-END PGP SIGNATURE-

Re: Removing Qt4 in Buster

[Paul Wise]

On Fri, Oct 27, 2017 at 11:05 PM, Andrey Rahmatullin wrote:

> Just bundle the libs, as you would do on Windows, and you'll be fine (wrt
> Qt, not wrt libc, but that's a separate problem). After all, running
> software compiled on a different system was never fully supported even if
> the dependencies were available.

I have a machine mainly used to install Debian games. I had to stop
upgrading it because when games get removed due to obsolete libraries
getting removed and I keep those removed games/libraries installed, I
can't upgrade the rest of the system due to conflicts between the
removed packages and new packages. I've come to the conclusion that I
want to move all of the removed games into flatpaks/snaps
automatically generated from the snapshot.d.o archives. This is
probably the right sort of solution for all sorts of other
unmaintained software too, including stuff that is stuck on Qt4.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: I'm not MIA

[Paul Wise]

On Tue, Oct 24, 2017 at 5:22 PM, Jonathan Dowland wrote:

> However, I cannot find your mail to debian-private in *my* archives. I
> have not checked the official archives, perhaps there's a problem with
> my mail set up.

My archives do have the mail.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: allowed uses of non-baseline CPU extensions

[Paul Wise]

On Tue, Oct 24, 2017 at 4:25 AM, Philipp Kern wrote:

> I think that's a very important observation. I don't think you can
> necessarily conclude that the system where the package is initially
> installed is the system were the code is executed.

Indeed.

> You argued in #873733[1] that you'd rather see the package installation
> fail. I see the appeal of that, especially to alert the admin. But there
> needs to be some kind of switch to flip to ignore these. Right now it
> seems that switch is IGNORE_ISA in the environment. But given the
> attempts to get a cleaner environment for dpkg, I'm not sure that's the
> best file. I.e. it'd be better to also have a flag file.

The discussion on IRC between myself, apt folks and Adam was leaning
towards an apt config & cmdline option.

There was an interesting idea about pinning, but in the end it was
concluded that this wouldn't be workable because the pinning would
only be generated after apt had already started.

>From there the discussion moved towards integrating this into apt, but...

There is still the question of if we want to allow deviation from the
baseline at all and if we don't, who is going to do the work to
achieve the goal of falling back on baseline code at runtime for all
upstreams.

> As a side note I'm also amazed that there's literally a uuencoded blob
> in the preinst that contains binary code that is unpacked and executed,
> just like any malware would do. :)

It cannot use files from the package, since those are not available in preinst:

https://www.debian.org/doc/debian-policy/#maintainer-script-flowcharts

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: RFP: pgadmin4 -- Web administration tool for PostgreSQL

[Paul Wise]

On Sun, Oct 22, 2017 at 12:10 AM, Alexander Wirt wrote:

> My company (credativ) released Elephant Shed [1] on Friday which is an
> Opensource, Debian Based Postgressql Appliance. My colleague packaged
> pgadmin4 in that process and we will probably polish those packages in the
> next weeks to make them ready for debian.

Please note that there are already ITPs for these packages:

https://bugs.debian.org/834129
https://bugs.debian.org/856025
https://bugs.debian.org/879382

Personally, I hope someone will be packaging the Python Qt version for
desktop users.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: New package, name recycling

[Paul Wise]

On Fri, Oct 20, 2017 at 10:59 PM, W. Martin Borgert wrote:

> a package "dino" in Debian

This seems like a fairly generic name.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Concerns about infrastructure for Alioth replacement

[Paul Wise]

On Wed, Oct 18, 2017 at 2:13 PM, Alexander Wirt wrote:

> Please don't get me wrong, but even if gitlab packages are recent tomorrow 
> (which I
> don't think) we won't migrate. The work is done and we have all the things in
> place to maintain them. So please do me a favour and don't mention alioth as
> the reason.

I note that the Debian security team doesn't support libv8, nodejs and
the stack above it.

https://sources.debian.net/src/debian-security-support/2017.06.02/security-support-limited/#L14

In my experience the JavaScript team doesn't appear to be following
the nodesecurity.io security advisories.

https://nodesecurity.io/advisories

What is your plan for avoiding the security issues discovered in
libv8/nodejs and gitlab-related node modules?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Alioth: the future of mailing lists

[Paul Wise]

On Thu, 2017-10-12 at 12:04 +0200, Andreas Tille wrote:

> Could anybody provide VMs as a service to a group of DDs?

Several companies provide hosting for Debian services:

https://wiki.debian.org/ServicesHosting#Outside_the_Debian_infrastructure

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#877977: RFP: node-web-ext -- build, run, and test web extensions

[Paul Wise]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: pkg-mozext-maintain...@lists.alioth.debian.org, 
pkg-javascript-de...@lists.alioth.debian.org, debian-devel@lists.debian.org

* Package name: node-web-ext
  Version : 2.0.0
  Upstream Author : Mozilla
* URL : https://github.com/mozilla/web-ext
* License : MPL-2.0
  Programming Lang: JavaScript
  Description : build, run, and test web extensions

This is useful for people wanting to create WebExtensions, which
are becoming the only extension API for Firefox from version 57.
I would guess that some WebExtensions will require it for building.

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Getting_started_with_web-ext

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: Bug#877212: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing

[Paul Wise]

On Wed, Oct 4, 2017 at 9:17 PM, Pirate Praveen wrote:

> I regularly get FTBFS when tests that require network access fail on
> buildds. So I'm not sure what is the basis of your assertion.

Do you have an example build log illustrating this?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: allowed uses of non-baseline CPU extensions

[Paul Wise]

On Thu, Oct 5, 2017 at 9:52 AM, Adam Borowski wrote:

> Any thoughts?

A better place to put isa-support might be in an apt plugin that
detects packages being installed that declare for example CPU-Flags:
SSE4.1 and prevents installing them unless in a chroot (for d-i or
debootstraps) and has an option to disable that blockage. Zero idea if
apt has a hook that could be used for this.

Anything that generates different code depending on the instructions
supported by the build CPU is going to break reproducible builds. So
whatever mechanism is used, it needs to be deterministic. We need to
get a wide variety of CPUs doing reproducible builds verification to
detect failures in this area. I'd like to see CMAKE_SYSTEM_PROCESSOR
and similar be deprecated upstream because of that.

Obviously runtime choice of CPU instructions is best (and as Ben says
FMV is a good way to do that), but if upstream doesn't support that
and has some lofty CPU requirements, I don't think we can force
maintainers to spend time on migrating to runtime detection or other
solutions. Probably the policy should be that the package description
and other metadata (isa-support deps for eg) must document any CPU
requirements above the baseline.

Does anyone have thousands of ancient slow CPUs to reproduce all the
builds and run autopkgtests on? :)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: e2fsprogs as Essential: yes?

[Paul Wise]

On Mon, Oct 2, 2017 at 5:01 AM, Michael Stone wrote:

> If e2fsprogs goes non-essential I'd rather see a new package for the
> filesystem-indpendent parts than have random packages depending on
> "ext2/ext3/ext4 file system utilities" because they want chattr. (Side note:
> if the fs-independent programs aren't spun off to a new package, the
> description really should be updated to make it clear that there's stuff in
> there that isn't specific to ext2/3/4.)

I wonder why these tools weren't put into util-linux/etc in the first
place, perhaps they should move to a less filesystem-specific source
package too?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Accepted autorevision 1.21-1 (source) into unstable

[Paul Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 01 Oct 2017 13:54:10 +0800
Source: autorevision
Binary: autorevision
Architecture: source
Version: 1.21-1
Distribution: unstable
Urgency: medium
Maintainer: Paul Wise <p...@debian.org>
Changed-By: Paul Wise <p...@debian.org>
Description:
 autorevision - extracts revision metadata from your VCS repository
Changes:
 autorevision (1.21-1) unstable; urgency=medium
 .
   * New upstream release
   * Avoid installing texlive along with asciidoc
   * Bump Standards-Version, no changes needed
   * Bump debhelper compat, no changes detected
Checksums-Sha1:
 2c73e03582019435749950cf85deb5b980613c15 2078 autorevision_1.21-1.dsc
 0b677eb080dff14339dd6aafcb7fe61b0027af03 21149 autorevision_1.21.orig.tar.gz
 2eb3810271c8572c83b6d7606b89603dc1978a72 2191 autorevision_1.21.orig.tar.gz.asc
 7b92779d3b8636ab5159329bffddffbc5eeb4932 37600 
autorevision_1.21-1.debian.tar.xz
Checksums-Sha256:
 ef181f16399860248374dd937709d3c6e5d571358828c65580b1f584cde9f87a 2078 
autorevision_1.21-1.dsc
 08070f15939b3b9cc7695f3a0e2d3e15224014cec38a7472c7eb55e1658e5a1f 21149 
autorevision_1.21.orig.tar.gz
 17ce0712cb1b5219538b223529f38b6e83e14b6bd542a7ef82a3166e3abf67fc 2191 
autorevision_1.21.orig.tar.gz.asc
 b43c1e44cc3e6604431b4bfcd1e98d0811b7652bf13f76188effbe4a4e550f0a 37600 
autorevision_1.21-1.debian.tar.xz
Files:
 635f0dcbca8bf9fa8705330217c9f91c 2078 devel optional autorevision_1.21-1.dsc
 4906670221b1e502f07de03351377e87 21149 devel optional 
autorevision_1.21.orig.tar.gz
 52ad283dcec41b8e8d0ad0d086d0a7e2 2191 devel optional 
autorevision_1.21.orig.tar.gz.asc
 400685c7e27c4c11a9d9357d3ea41141 37600 devel optional 
autorevision_1.21-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAlnQg5kACgkQMRa6Xp/6
aaPojRAAvGAYS3swrMUkb2pRW6iI3EyFQS3MBrAaWdLSMdhzWav3kuKf7tjSfW1q
dk6qinFNnahQWec6nvKFmPPo/lUC/a36aJMh8XuQm5I86EBIQlaOo/UzNDaFEDr3
ZVBIP+/i8iocHYan9zpW5aU3UqeU9c1+Sazh/5oDsAQU41HdfJxUhdjnw8jh+/tL
rA5iNpTbUJcKe8rnqiNyAmBD4IjN7qyjM0Tsxmzfn2kaKmAAsaI7ZqchBtuHTnGI
Dy2GXsHqK39V45VP4wpBsXET9LIQqZT3r9B503BRR7Bu1FS5yPPHQ7zlR2RheEqh
z0ianAwN0SuNf/rizZkqGRXAapBc7mdpC8gDHpXUe+l2TyNix0rnNKxAG3Xb3cA+
fe4mZaH6IsBd5lTrhtUKFVpajmVSjXNm0MHk1XmlqEmp+Z3kL/rUz2GvJOc0IGnB
CKqSNGVisom3WPYtqx+evvb9KHPnibBPihoRWV/4W5dilD0iPl1FcKP0snJgjAiq
qPfA6q0iKtd/25FvwZ/MvUTTnAWXM/TNwbP1ICUZSrbC5KQp/gdJrr6+VS9p8cp0
my1P71+OzfqlqwpCQMMZCOIiuMtzUDfq8afL1qmEGwqYBTTTjNkk7QMbSrKxkv2L
jpaSOvMDOFqCU5QUv8q7f7tY30hzEU2+6pDJZh0WP8LA3hsEofM=
=xsAk
-END PGP SIGNATURE-

Re: debian/control file: how to selectively suppress recommends?

[Paul Wise]

On Wed, Sep 27, 2017 at 10:28 PM, Marcel Partap wrote:

> Any ideas how to block installation of only some packages' recommendations?

I assume that adding Breaks or Conflicts to your meta-packages for the
packages you do not like should do the trick. You can even go one step
further and add Provides for the cases where the packages you do not
like are Depended on by some package in Debian. For example some
desktops may Depend on CD/DVD related tools but your computer might
not have a CD/DVD drive. With versioned Provides now being supported
you can even prevent versioned Depends being installed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Requirements for simple ncurses/console applications for entering Debian?

[Paul Wise]

On Sun, Sep 24, 2017 at 11:47 PM, spartrekus spartrekus wrote:
>
> I would like to bring few of my applications, only reliable, stable,
> programmes to the world of Debian.
>
> Which requirement list should be carefully observed in order to enter the
> debian stage processing for new applications.

Since you are the upstream developer, please read our upstream guide:

https://wiki.debian.org/UpstreamGuide

As Simon mentioned, the Debian policy document applies to Debian packages:

https://www.debian.org/doc/debian-policy/

> Noteworthy, since I am author, I can package and maintain these apps.

In addition to what Simon wrote about this, please see this page:

https://mentors.debian.net/intro-maintainers

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: alioth down?

[Paul Wise]

On Wed, Sep 20, 2017 at 8:50 PM, Elimar Riesebieter wrote:

> what is the reason why alioth.debian.org can't be reached?

https://wiki.debian.org/TopicDebianDevel?action=diff=1931=1932

 * Alioth currently rebooting/fscking

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian distro build system

[Paul Wise]

On Wed, Sep 20, 2017 at 1:26 AM, Aaron Gray wrote:

> I am wanting to build a Debian rootfs and possibly whole distro for x86,
> amd64, and ARM HF and EL. Specifically with Debian Installer.

The standard way to create a Debian install is to download and boot
the Debian installer (d-i):

https://www.debian.org/distrib/netinst

There are a lot of other different ways to build a Debian rootfs or
related things if d-i does not suit your needs:

https://wiki.debian.org/SystemBuildTools

If you can give us some info on what you are actually trying to do
then we can give you a better answer.

http://xyproblem.info/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Alioth: the future of mailing lists

[Paul Wise]

On Mon, Sep 18, 2017 at 8:55 PM, Raphael Hertzog wrote:

> Instead we should use @packages.debian.org.

If the Maintainer field is going to be completely deterministic based
on the package name, we should probably just change dak/BTS/etc to
mail those addresses instead of making dak put those addresses in
Maintainer fields in Sources/Packages or updating almost every package
in the archive.

There are a number of non-Debian mailing lists in Maintainer fields
though, do we want to drop support for that?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: for the future of Debian Live

[Paul Wise]

On Sun, Sep 17, 2017 at 6:25 AM, Washington Feitosa wrote:

> please do not stop the production of Debian Live in the next distributions.

I would encourage you to get involved in the Debian Live testing and
development. Join the mailing list and IRC channel and introduce
yourself and state your willingness to help the project and what you
are able to do. There is some info about the team here:

https://wiki.debian.org/DebianLive

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: How to start a new packaging team now?

[Paul Wise]

On Sat, Sep 16, 2017 at 2:35 AM, PICCA Frederic-Emmanuel wrote:

> What is the status of this migration ? which solution was selected ?

It is still being worked on and no announcement has been made yet.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: SDL2 Libraries issue

[Paul Wise]

On Wed, Sep 13, 2017 at 3:36 AM, Aushana.Jr.1026 wrote:

> Please provide me with some assistance!

Please ask for help on the Ubuntu support channels:

https://www.ubuntu.com/support/community-support

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: distributing .buildinfo files (Re: Bad interaction between pbuilder/debhelper/dpkg-buildinfo/dpkg-genchanges and dak on security-master)

[Paul Wise]

On Sat, 2017-09-02 at 21:48 +, Holger Levsen wrote:

> > So I suppose we talk about 13 GB[1] of static content in about 1.7M
> > files. Is that something that could be distributed through
> > static.debian.org if there are concerns around inodes for the main
> > mirrors? Given that they would be accessed mostly rarely[2]?
> > 
> > [1] 7.7kB (75%ile as mentioned in the referenced bug) * 55000 binary
> > packages * 10 architectures * 3 versions - so quite conservatively

I had a quick look at the (currently) 4 systems behind static.d.o and
it looks like they can all take the extra space and inodes. senfter
only has 48GB space left but we can expand the storage there.
mirror-csail only has 64M inodes available, but should be fine.

One concern might be the rsync time for 1.7M inodes, I'm not sure if
our static setup does sites in parallel.

There might be other factors here that I'm not aware of, hopefully
other DSA folks can fill them in.

Are these files going to only be available for the versions of packages
that exist in the archive right now, or is it going to be a historical
archive of all Debian build information forever?
paralel
What kind of growth per year are we expecting?

> using static.debian.org seems to be a good idea to me, what would be needed 
> to make
> this happen?

Some patches to files in dsa-puppet to define the service:

modules/roles/manifests/static_mirror.pp
modules/roles/misc/static-components.yaml
modules/roles/templates/static-mirroring/vhost/static-vhosts-simple.erb
modules/sudo/files/sudoers

https://anonscm.debian.org/cgit/mirror/dsa-puppet.git/

> or, we could put them in a git repo instead, and use git.debian.org…

It strikes me as quite a lot of data for one git repo :)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: Whether remotely running software is considered "software" for Debian.

[Paul Wise]

On Mon, Aug 28, 2017 at 7:59 PM, Dr. Bas Wijnen wrote:
> On Mon, Aug 28, 2017 at 12:31:15PM +0200, Philipp Kern wrote:
>> I think the sanity check that fails today is a) free implementations of
>> the RAR algorithm exist so this is unnecessary
>
> I'm not familiar with the details, but I know some rar files cannot be
> extracted with unrar-free.  So I'm pretty sure unrar-nonfree contains things
> that are not free and are required for some features.

You might not be aware that there exists free code to convert newer
RAR archives to a directory tree. That code is within the upstream
software known as "The Unarchiver". The command-line version of this
is known as "unar" and is packaged in Debian main. AFAIK there is no
free tool to produce RARv3 archives from a directory tree though.

https://theunarchiver.com/command-line
https://packages.debian.org/search?keywords=unar
https://en.wikipedia.org/wiki/RAR_(file_format)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Mail templates

[Paul Wise]

On Wed, Aug 30, 2017 at 3:52 AM, Ana Guerrero Lopez wrote:
> On Tue, Aug 29, 2017 at 09:19:23PM +0200, Anon Andme wrote:
>> Please stop sending emails to this address. I did not subscribe to this
> I replied this email off-list.

It might be simpler to respond to unsubscribe requests by pasting the
email address into the relevant unsubscribe form on lists.debian.org.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Accepted glewmx 1.13.0-4 (source) into unstable

[Paul Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 28 Aug 2017 08:12:59 +0800
Source: glewmx
Binary: libglewmx1.13 libglewmx-dev
Architecture: source
Version: 1.13.0-4
Distribution: unstable
Urgency: medium
Maintainer: Paul Wise <p...@debian.org>
Changed-By: Paul Wise <p...@debian.org>
Description:
 libglewmx-dev - OpenGL Extension Wrangler MX - development environment
 libglewmx1.13 - OpenGL Extension Wrangler (Multiple Rendering Contexts)
Closes: 873144
Changes:
 glewmx (1.13.0-4) unstable; urgency=medium
 .
   [ Helmut Grohne ]
   * Fix FTCBFS: (Closes: #873144)
 + Drop binutils build dependency satisfied in wheezy.
 + Let dh_auto_build pass cross compilers to make.
 + Pass the correct LD and SYSTEM to make.
 .
   [ Paul Wise ]
   * Drop unused srcversion debian/rules variable
   * Switch to debhelper compat 10
   * Switch to dh debhelper sequencer
   * Pass build flags to upstream build system
   * Enable all hardening build flags
   * Drop unused manual page source
   * Bump Standards-Version, no changes needed
   * Switch URLs in debian/ to https where possible
   * Drop unused gbp/dpkg options
   * Convert debian/rules to UTF-8
Checksums-Sha1:
 7641cfaeed4962a8f149ef0d0738b3b1a2548365 1872 glewmx_1.13.0-4.dsc
 b4d5367db622d023989629b0e77c8c408067440c 18032 glewmx_1.13.0-4.debian.tar.xz
 321732703ce7eb22a30c94a64af30091835e8d06 8862 glewmx_1.13.0-4_amd64.buildinfo
Checksums-Sha256:
 5d87945213b39ffb9093137c3477d02c3406b63d04ff2a8ab7b5681a27e1bc33 1872 
glewmx_1.13.0-4.dsc
 3342a2ab1f91107ed276dc3adb8dfbb4b5b53faf7a3ab08fe5f77a98f815bbc9 18032 
glewmx_1.13.0-4.debian.tar.xz
 2d60ff154eaffa902814e85abedbffb6689b4e8ff140807e813b49ac7775bbfe 8862 
glewmx_1.13.0-4_amd64.buildinfo
Files:
 21636887b438656af80a58f33fbd3ac2 1872 libs optional glewmx_1.13.0-4.dsc
 de080b1f73eff3bdab0312f9fb497a5f 18032 libs optional 
glewmx_1.13.0-4.debian.tar.xz
 5fd7a3b6a015104a26e4e1ae364ad639 8862 libs optional 
glewmx_1.13.0-4_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAlmjcZYACgkQMRa6Xp/6
aaNEbRAAr6CkYqrKfpazqcb/WxwvbeYpcInhDw4beA7s0szo5B3dv9wLeFgvyous
D5CHIrPgN7Bcbis4/PXW2A38DtZ1Ro8MbJp863ekspr5y0rJAFDWlTamIM19VIds
Q5F9FtRIyzwlZopVxSvhU0E5NJGhWmpyJvGn1+KjXKbSIEbnqOWeGhMjb9C6xbhY
UwiRumBx1XGRVknENdtZ8aELbldJkIis9suTLm0vtxsdemdTyJxGO00/+cbKMSIv
zqYTr4+fErtpofJqfwlR85DnnvXRNL//u5UQN3/ubBbPX4JaNlBz5fUnvJaqqcLM
LiEEeYZYiHNuk1m3a27lhb8p977ZNF9s/Hx+NSS83IgeMYYR3r6sjMXrL4rzYfhl
nfoTzvcukrKuTvErwim8G/DZHPQnVFQpJVBZ6X1Pp1Ck3V505bu7s5twBERGombQ
ECP8mSDij0G0V7/4CUpRx8Yf845SWeQQMsJSQP16Z8BkxNTnQAy/H2GDjA45w/eC
4XuXSO8i7ABvXIPwffouFNgLiJVo3DNjcqQI4McKIUQBkKD0pJ4GC2u40Kc/FJ3j
h/Mq1fD5HOPnHPhZp0q9bv2fIV9rYlgM/i9lnaKkd7lO0T1AkrjQSyM/45bexPjF
/4Bnvs13Prf426EkaCm0N0EqGqCKV3+zLnr4ozxwKQaPOQbeP2E=
=+GSu
-END PGP SIGNATURE-

Re: OpenSSL disables TLS 1.0 and 1.1

[Paul Wise]

On Mon, Aug 7, 2017 at 9:42 AM, Kurt Roeckx wrote:

> This will likely break certain things that for whatever reason
> still don't support TLS 1.2. I strongly suggest that if it's not
> supported that you add support for it, or get the other side to
> add support for it.

This has broken the Python mechanize based script that I use to
connect to my ISP's web interface and extract information about how
much bandwidth quota I have used. I don't have any way to fix my ISP's
web servers.

Will we be disabling TLS 1.0/1.1 in web browsers and other TLS
implementations too?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: New archive key for wheezy generated

[Paul Wise]

2017-08-16 5:15 GMT-04:00 bogdan:

> My name is bogdan .i need help.

Please contact Debian user support for help:

https://www.debian.org/support

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Proposal: A new approach to differential debs

[Paul Wise]

On Sun, Aug 13, 2017 at 5:38 AM, Adrian Bunk wrote:

> It sounds like something that would have been a cool feature 20 years
> ago when I was downloading Debian updates over an analog modem.
>
> Today the required effort, infrastructure and added complexity would
> IMHO not be worth it for a potential few percent of bandwidth decrease.

Low-speed connections and low bandwidth quotas (especially on mobile)
are still common enough around the world that delta upgrades make a
difference right now, IIRC even Google uses them for Chrome.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Can Ubuntu font be added to a Debian repository?

[Paul Wise]

On Tue, Aug 8, 2017 at 9:40 AM, Garrett R. wrote:

> Is there a good reason why Ubuntu font is not found in Debian repositories?

Looks like it requires proprietary software to build the font from source:

https://bazaar.launchpad.net/~sladen/ubuntu-font-family/midstream/view/head:/midstream/SOURCES.txt

> Is there a formal way to request that it be added to a repository?

Not sure if you are subscribed, so I quote from Andrey Rahmatullin's reply:

> There is a formal way, and it was already done:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603157

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Embedded library copies - mergerfs

[Paul Wise]

On Mon, Aug 7, 2017 at 8:30 AM, Antonio SJ Musumeci wrote:

> My users span several generations of Debian (and other) Linux distributions.
> Early 2.9.X versions of libfuse had bugs which led to "random" crashes.
> These versions are still in wide use (I get 2.8.x users on occasion too).
> Over past couple years I've spent countless hours tracking down issues
> related to these buggy versions and helping (often inexperienced) users
> upgrade their systems. This is the core reason I decided to embed libfuse
> 2.9.7 into mergerfs.

If faced with this situation myself, personally I think I would have
marked those versions of libfuse as explicitly unsupported using both
build and run time checks. People building from source would then need
to backport libfuse before updating mergefs.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Automatic way to install dbgsym packages for a process?

[Paul Wise]

On Sun, Aug 6, 2017 at 12:14 PM, Stefan Fritsch wrote:

> Is there some tool that parses /proc/maps and the build-ids fields from
> the apt repository to determine which dbgsym packages to install?

Not AFAIK but I guess that Fedora probably has a script for this somewhere.

The service to map build-ids to snapshot.d.o packages is not fully
implemented yet either.

http://build-id.debian.net/ (code on lw08.d.o)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Windows viruses in Debian email packages [from Misc Developer News (#44)]

[Paul Wise]

On Sat, Aug 5, 2017 at 10:03 AM, Steve Robbins wrote:

> The news item doesn't specify what to do after scanning, but the referenced
> bug requests removal of the offending material.

Personally I would recommend removal, especially since most (but not
all) malware is not DFSG-free. If the malware is Free Software then I
would recommend building it from source. I would guess that the source
would not trigger these various malware scanners.

> The news bit refers to "test corpus", so removal would presumably not change
> the output.  But I have to wonder: are there not cases where the malware is
> present for *training* a detection system?  If so, I would imagine removal
> could reduce the effectiveness of training.  So what alternative exists for
> this case (if it indeed is a case we need to worry about)?

Can you think of any particular examples of the type of training you
are talking about?

Personally I tend to think that the training should be done on
real-world malware from the current time in history and any package of
such malware would quickly get out of date and also be non-DFSG-free.
So training some model on Debian buildd systems would be pretty
pointless and that should instead happen on external services. There
is already quite an industry around malware, it might be interesting
for the industry to become more open, transparent and accessible to
people without money but that should happen outside Debian.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Maintainer information in source packages (was: Re: Returning to the requirement that Uploaders: contain humans)

[Paul Wise]

On Fri, Aug 4, 2017 at 6:10 AM, Ansgar Burchardt wrote:

> So I have been wondering several times whether we should move the
> maintainer information elsewhere.  For example, tracker.d.o could be
> extended to record maintainer information.  It could also understand
> the concept of "teams" listing team members and whom to send mails
> about individual packages.

This has been planned by the distro-tracker folks for many years,
there is even a DEP about it:

http://dep.debian.net/deps/dep2/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Accepted gravitation 3+dfsg1-5 (source) into unstable

[Paul Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 01 Aug 2017 10:46:46 -0400
Source: gravitation
Binary: gravitation
Architecture: source
Version: 3+dfsg1-5
Distribution: unstable
Urgency: medium
Maintainer: Debian Games Team <pkg-games-de...@lists.alioth.debian.org>
Changed-By: Paul Wise <p...@debian.org>
Description:
 gravitation - game about mania, melancholia, and the creative process
Closes: 776872
Changes:
 gravitation (3+dfsg1-5) unstable; urgency=medium
 .
   * Fix build reproducibility issues due to use of imagemagick (Closes: 
#776872)
Checksums-Sha1:
 08fdd2d8f5b7750260541fe3d9854044a94d6c10 2007 gravitation_3+dfsg1-5.dsc
 b416eb603069dec7bc78d1e022d4bda5f8355892 5808 
gravitation_3+dfsg1-5.debian.tar.xz
Checksums-Sha256:
 6f75193aff12088e045d0c3522f9e4442842c478b9acbe707d1ace281fd91bc7 2007 
gravitation_3+dfsg1-5.dsc
 90339c0dda633f75c443b67fa8749de94b6ef5f0403a73f53acf6f92a7f6a1c7 5808 
gravitation_3+dfsg1-5.debian.tar.xz
Files:
 d849c9250ac23bf76b5b33fc5fe07763 2007 games extra gravitation_3+dfsg1-5.dsc
 b3bb0f0c2071b34f53d44e878b254059 5808 games extra 
gravitation_3+dfsg1-5.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAlmAlJ8ACgkQMRa6Xp/6
aaMmuA/6At4WbEHZZmOMa8JplrbeH63pq4i2ORjjevtS5sfqgtFGccPcfZeoNEBX
NmylodxyrH3A27oYRY7dfN+Iqu3b5sEaB5IWwYcfdcm/N+nwB4WttoLiPTZUqvHW
EF5jRsRwxWHjzl1ptyMs+ku4ErgzhG1S1vJN9WdbZtEP+588jQSuReHqGayukrC4
LHz1HpBJzWO37EPzWluoFr1kVsSPVsxAwH+xIoexOIE99t+Du0m0DOGIn1m1HM/t
f+ODCNv2goZtJvXiD7LzcWVc2loE47/rXqC6LRoFE1qHT+iugO2feotK8nHUjyKW
g32YBY3s2NKw/VzxD1E9f0PYrOJk+58pxdLS7menebeGjq1ZstfgIyGzeiHaPMzm
5vfAXOO1/Xv1YgEedEqqeNIVVHraaVQZ9Mcw3MXacjf4QwW4lcg8Y6riN7yWgqe5
aHbwXDiRXNUsLxLV206GYZQlmP5l5DAprkwtqKAddPr0t4pdKThHE+9F5CRFR2vE
Ua6HHypXhOKimGCf2XWaA9Wv1xViycRhVmyxeRUTEfpAHfsA9IGsKlFtLROsPfUa
QTtS4RkJfY6zOxfcKuHLnbqA59NTV77xgv9b/3bfySuPkZE3kSSlZo4+O7XDlFbs
WEJTirKIkZNNNQFhLcLWTnoWYraU/egbsgblGFzpPk1kGe/AhU4=
=cyiI
-END PGP SIGNATURE-

Accepted passage 4+dfsg1-3 (source) into unstable

[Paul Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 01 Aug 2017 10:43:37 -0400
Source: passage
Binary: passage
Architecture: source
Version: 4+dfsg1-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Games Team <pkg-games-de...@lists.alioth.debian.org>
Changed-By: Paul Wise <p...@debian.org>
Description:
 passage- game about the passage through life
Closes: 779136
Changes:
 passage (4+dfsg1-3) unstable; urgency=medium
 .
   * Fix build reproducibility issues due to use of imagemagick  (Closes: 
#779136)
Checksums-Sha1:
 fd8344943632ff50e38c72a5488df7b9992df960 1959 passage_4+dfsg1-3.dsc
 f36331a9d30ab67a63dde021a6ad2ba65059007f 5972 passage_4+dfsg1-3.debian.tar.xz
Checksums-Sha256:
 8ad2112a8abe9d674da1143364e8516f4cfcf4b631479b3051f3caee05298987 1959 
passage_4+dfsg1-3.dsc
 71a4a0de08bdbcb1dcf1a5968bb25402dc8a3a7e5fd6d2aa15e30382e35badc3 5972 
passage_4+dfsg1-3.debian.tar.xz
Files:
 f9177fe4a7bbab17848f27585b333215 1959 games extra passage_4+dfsg1-3.dsc
 122c6418d87f427479b1660d51915635 5972 games extra 
passage_4+dfsg1-3.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAlmAk+wACgkQMRa6Xp/6
aaNDHQ/+Pg97AnWJRL36JqyLIZT4GDGXwyGTwNVv8/6fqmM/3lD7UdnTgWprN5iI
ZlU3I2s2/lHfCrfXBPThR1lNTEkdtk2pjZe83CUDHuhNeS/KvrgTDiqI2514AA4m
9jWtwl+7rM9n/s3/nwRz1Tlriy6R/QABMrDWR7LZJiDI7q2DAjV4WuWR+uZxEryP
alB+4xE5Fm+rdYjUojoFJ//mtNZTe+BxEkfnJa5s/NVuyK+bqFdilY4E+XiVbDfR
HghGufpRX2QTp/ylN8W6p19X6wcXbgsQy55Rp2DFFP/s2B/vgo58gzXuK9ShhesJ
HgyimGISubuI7Cjk+kqzmFDWhzdjkVMRuWOYQrmZsmstwnkrPU4YUe15ZgNvkJ+p
IomCvCa2E2uCI1PhBkXwf0hyYwiZPUnu5I3JrTx/5RVhiGdszJCpqmDWKWbUwV23
OBjPZyTiU0EA55YhLvm67JAL5YMyOpluflLk+Y53QxZy7p3hYV6RdyqBTeFZESBd
jy4AtGpTvzJOnlh6ektzztgjq5BQREAsot14MU49bicN9d3jblHl0QaXbRweGsPk
ykgp5S9IQELVD3pT+G6YC6hXHl3SkTI3uGjRxFLHuAdYAEQZgWFGrWAP7ZX3Pooe
SGXoH4VrH9CX0/thx2j1iVyIBwAyR69RksYHpphbaPhsXKrRKqQ=
=5nBR
-END PGP SIGNATURE-

Accepted primrose 6+dfsg1-4 (source) into unstable

[Paul Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 01 Aug 2017 10:33:16 -0400
Source: primrose
Binary: primrose
Architecture: source
Version: 6+dfsg1-4
Distribution: unstable
Urgency: medium
Maintainer: Debian Games Team <pkg-games-de...@lists.alioth.debian.org>
Changed-By: Paul Wise <p...@debian.org>
Description:
 primrose   - compelling tile-placement puzzle game
Closes: 778481
Changes:
 primrose (6+dfsg1-4) unstable; urgency=medium
 .
   * Fix build reproducibility issues due to use of imagemagick (Closes: 
#778481)
Checksums-Sha1:
 e713b59b4c23ecc7992a4b80f59d3d4eee0a6336 2032 primrose_6+dfsg1-4.dsc
 c2a4cf0a84b0aee4d459c459bff8678e40af08d9 5936 primrose_6+dfsg1-4.debian.tar.xz
Checksums-Sha256:
 5b9c64ea269ab4a53cb21785c0667ba082840278a0c66dde1fb06e5cef1c44f8 2032 
primrose_6+dfsg1-4.dsc
 4b8b0129a1d8e81b91188c2c2c0ec8fb28867bcf79de407f655593eb373c5c19 5936 
primrose_6+dfsg1-4.debian.tar.xz
Files:
 c55f93a2f6a9eff7d582df636895d0ae 2032 games extra primrose_6+dfsg1-4.dsc
 f7f1fcb32e08640d4a04bd4151cdc51a 5936 games extra 
primrose_6+dfsg1-4.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAlmAkqoACgkQMRa6Xp/6
aaMw3BAAkIOneTMUuAha8KxSGWQS/1PyPrLqX2Fr923bLPJKdFsx7OBGOqumCLgw
BXzpWfwykJRSCIJm5io+g0XsP2y9YGMwmY8RUAJTNcQ0S5LbLiwIYb2M5rQJdb+T
Gh+Q3x7MPB7FWoiGIWbZ/Nb7ErYnsU7Ml/PYdsRoWTewT5PBeXylFvgf6nTBR5fZ
XBRwYP69bqv550AX2rslqX7Pvv5d8pn2AsqUs+GGxLYRKeiM9/k6mJCxeF2+AB2P
1F/soZOUhCZKKo9D6vjum60u0hGQz/rcy5L/viA2sOvPySVAD7+xPorqn5gXJd6R
/xLGx92GGBBscDuWNnqJox5Dt13k5RzbfpJiCyenoaJdvJcM011ci9vVlXXAMmyS
jAAuxO6eFOb5B7maU/nkDC1C3k44q3dgdZJ1n50LUcrJuCVrl4pJTMblBz1J7n0x
Kvv2TfuBBETYDk1lgSaxCkPNzbAFkziEf3yESuXYlOoemQ+wwYH4mxRbxWYjLBj+
L8Uw4/ehGm+szH6+QMC+G1077HomA47PBvdNBgg9XjbNOM6X9Vo07j0ONbTVMJ0e
VRiZmUcaBig2WsUgyQn22x5QNVOov+5aJp6VKo/JLieiqSozNHUpkia8h8B7d3Zg
wTE46k4ptsQYX7qnq2YYMgcmkgib24VHehi9eg/J4CbgCzE4ihE=
=hXbO
-END PGP SIGNATURE-

Accepted flasm 1.62-8 (source) into unstable

[Paul Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 29 Jul 2017 23:20:39 -0400
Source: flasm
Binary: flasm
Architecture: source
Version: 1.62-8
Distribution: unstable
Urgency: medium
Maintainer: Paul Wise <p...@debian.org>
Changed-By: Paul Wise <p...@debian.org>
Description:
 flasm  - assembler and disassembler for Flash (SWF) bytecode
Closes: 869595
Changes:
 flasm (1.62-8) unstable; urgency=medium
 .
   * Fix FTBFS with new gperf by updating copy of function prototype
 (Closes: #869595)
Checksums-Sha1:
 b3c129ad3ab75556182e09d9406dae1b0aad15f3 1834 flasm_1.62-8.dsc
 95adb912524a098e4a7744e96fec1c8ddfcfda3a 7800 flasm_1.62-8.debian.tar.xz
Checksums-Sha256:
 a3d3fab4c776156041350cd7aa35a67e58bf37cd71cb4dee04f891e91ba968e8 1834 
flasm_1.62-8.dsc
 a3432857f3acd56093265ce9b9918ac51114ca515441a845da7bd86720095343 7800 
flasm_1.62-8.debian.tar.xz
Files:
 a336953797e23ed07c784ce4a99ba34d 1834 utils extra flasm_1.62-8.dsc
 24229bf8d5b4981d36a790c77c17c049 7800 utils extra flasm_1.62-8.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAll9UuoACgkQMRa6Xp/6
aaOkIRAAssrqqCbstEqDPTHlzREqVM+XCtDg5SpsJ4nnQnOiJJFC2jtadOsK8TVL
DYMrf6SLlAkX+9uWQFWxtgzjRls3XHcXbZfLyoit5PP3YExgoj8JBepFp7jRwEOG
tMGS+CbSWmYjTNzuvyuxls+6DNwJgbL3/RIwoe0772JIDpC+Sypr9zG4usPdWtxC
Pv3WsVtb4A5jLz2aimN6iKA9VytCg5wD0AYu+xLKjmdi4wPfYHRQBUk/DGa/qM8P
EQkzBH4qdTglHK9+iu/OSrr9ZiUqtNQHdEKd+HlymgD4A2p8BkzmgCnyAsQbCSgU
0SCr5Nx/VRnzhGNqFnoMJUJYeqQWJRpTU3bmx5+XjS6DPNx4O/KTkHl/FeeAPMGW
K/p43DbtP6qiBTtyWS6siCDaoTYxtYg4IrdEhcJcvSQjY9lXvPlljMaBih9WtXsz
uzkgGqQ7hGOb7nSPkqOP/OcCdVzB8bhTJCf8Uq7PWInZuUP0gqEM4CFnkX/EqjhE
48GDMxDwlz8iwDWH/FqvTB1JZqrneRA5CAKKTfp13v5/L8Fq7BiN9T47QmJBOSYg
vOW4iOpDTiTH/9HIOEP/wv9SeQBWFjCQ1P8OdNotU8IJUqLjiDpyoAOEvfRsmXuZ
AN9T033ds0B8ll4jPfhQ7S2pWSvc0JcwVFomHD6nCE8xdn4BWJY=
=WiUm
-END PGP SIGNATURE-

Re: User-installable Debian packages?

[Paul Wise]

On Sat, Jul 29, 2017 at 11:26 AM, Steffen Möller wrote:

> If flatpak is an answer - great. But from what I get, there is no automated
> transformation from .deb to it, so we would need to decide for packaging
> in that different format instead of our regular effort.

We could probably leverage our existing efforts and add a layer on top
to get Flatpaks out of Debian binary packages. Simon mentioned on IRC
that he is working on a demo of a Flatpak app produced from the
corresponding Debian binary package, with a runtime built from Debian
binary packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Running tests with xvfb

[Paul Wise]

On Sat, Jul 29, 2017 at 5:45 AM, Jeff wrote:

> I did that six months ago:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857620

Looks like that received no responses, you might want to re-test with
the latest Xorg in sid/experimental and forward the results to nouveau
upstream.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Running tests with xvfb

[Paul Wise]

On Fri, Jul 28, 2017 at 4:46 PM, Jeff wrote:

> I have a package whose tests crash X on my machine, which uses nouveau.

This sounds like an Xorg/nouveau bug, please do report it:

http://x.debian.net/howto/report-bugs.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: User-installable Debian packages?

[Paul Wise]

On Sat, Jul 22, 2017 at 8:28 PM, Steffen Möller wrote:

> user-installable packages

That sounds like Flatpak/Snappy/etc.

I would wager most Debian packages are not bit-for-bit identical when
you vary the installation prefix (and Debian build tools don't support
doing that AFAICT), but you can almost fake user-installable packages
using existing binary packages using something like this (sorry about
the wrapping). If we were all using Hurd then a few extra overlay
mount points would be enough of course.

==> .bash.d/software <==
export PATH=$PATH:~/software/usr/bin:~/software/bin
export 
LD_LIBRARY_PATH=~/software/usr/lib:~/software/usr/lib/x86_64-linux-gnu:~/software/lib:~/software/lib/x86_64-linux-gnu
export PERL5LIB=~/software/usr/share/perl5
export PYTHONPATH=~/software/usr/lib/python2.7/dist-packages

==> software/update <==
#!/bin/sh
rm -rf usr apt/archives/*.deb
rsync --delete --archive --exclude archives /var/cache/apt/ apt/
rsync --delete --archive --exclude lock --exclude Lock /var/lib/dpkg/ dpkg/
apt-get -o 'Dir::Cache=/home/pabs/software/apt' -o
'Dir::State::status=/home/pabs/software/dpkg/status' --download-only
install foo
for f in apt/archives/*.deb ; do
dpkg -x $f .
done

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian built from non-Debian sources

[Paul Wise]

On Tue, Jul 18, 2017 at 9:09 AM, Steve McIntyre wrote:

> Making images often requires tweaks to the build script at/near
> release time. The archive continues to be a moving target until very
> close to that time. More than once we've fixed things or added
> workarounds in the image generation scripts *on release day*.

Does the freeze have an affect on this situation?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Crossgrading in stretch

[Paul Wise]

On Wed, Jul 12, 2017 at 2:36 AM, Jose M Calhariz wrote:

> Anyone have recently done a Crossgrading in stretch?

I have not, but I think it would be interesting to have automated
testing of individual packages via piuparts.d.o and various default
configurations via jenkins.d.n.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Declarative packaging (Was: Re: Intended MBF: maintainer scripts not using strict mode)

[Paul Wise]

On Thu, Jun 29, 2017 at 12:34 AM, Michael Biebl wrote:

> The common expectation in Debian is, that we expect packages to be
> "usable" after installation. Which means we often intermix installation
> with configuration, which is typically done via maintainer scripts.
>
> This makes it very hard to disentangle those steps.

We are re-implementing hacking around this entanglement in multiple
places (Debian Live, OpenStack images, cloud-init etc), but only for a
limited portion of the archive and only via manually munging the
filesystem after install.

This is also preventing us from having "OEM installs" where an
hardware vendor can create a generic disk image and each boot of that
image would run the necessary first-boot setup (like creating OpenSSH
keys or prompting to create users).

IIRC last time we discussed this, the recommendation was to set an
environment variable that maintainer scripts could check to determine
if they should do host-specific actions or just generic actions common
to all hosts. Personally I think that seems like a bit of a hack and
there needs to be a new state for packages to be in added to dpkg.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Subject: UMASK 002 or 022?

[Paul Wise]

On Thu, Jun 29, 2017 at 12:21 AM,  gwmfms6 wrote:

> Paul, you seemed to indicate that you were able to set a different "user
> default" umask in Stretch that's respected by gnome apps like gedit?

No, I didn't indicate that. See my other reply for clarification.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Subject: UMASK 002 or 022?

[Paul Wise]

On Wed, Jun 28, 2017 at 8:59 PM,  gwmfms6 wrote:

> You didn't notice because you run umask from your shell configuration?

I should clarify, I meant bash shell not gnome-shell.

>  In other words, you have a working umask in Stretch?

In my terminals yes, but not in apps launched from the GUI.

> Can you tell me how to "run `umask 027` from my shell configuration"?

I have the equivalent of this:

echo 'umask 027' >> ~/.bashrc

> Currently, I have not found a way to get gnome to respect umask setting in 
> Stretch.

No idea how to do that.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Subject: UMASK 002 or 022?

[Paul Wise]

On Wed, Jun 28, 2017 at 7:25 PM, Ian Jackson wrote:

> The appropriate default umask is 002 if the user's primary group is
> named after the user, or 022 otherwise.

AFAICT, neither of these achieve what the initiator of the thread
wants to achieve; no read access by other users to one's files on
multi-user systems by default.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Subject: UMASK 002 or 022?

[Paul Wise]

On Wed, Jun 28, 2017 at 1:11 AM,  gwmfms6 wrote:

> I'd like to know why giving the world (Other) read access is even under
> consideration. If user wants a file to have Other readability this should be
> on the user to set it, but it should not be the default.

I expect for most Debian deployments this isn't that relevant, since
most are either servers with no real users or single-user systems with
no guest account.

> What is the justification that every user be able to read everyone else's
> documents?

This decision was made in the mists of time and has never been questioned.

> This discussion should be on whether to set a default UMASK of 077 or 027.

I think the appropriate default umask is 077 due to the possibility of
some sites not naming the primary group of each user after the user.
That said, 027 would probably be a reasonable default too since most
sites do not do that.

> NOTE: this discussion is moot at the present time anyway because it is
> impossible to set a UMASK at all on Debian Stretch. None of the usual ways
> work within gnome on Debian Stretch. Can anyone comment on this fact?

I had "UMASK 027" in /etc/login.defs and I didn't notice that this no
longer works because I also run `umask 027` from my shell
configuration. If you can track down why this no longer works, please
file a bug about it and convince the maintainer to fix it in stretch.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Intended MBF: maintainer scripts not using strict mode

[Paul Wise]

On Tue, Jun 27, 2017 at 4:23 AM, Ralf Treinen wrote:

> we currently have in sid 84 maintainer scripts not using strict mode.
> That is, they neither start on "#!/bin/[ba]sh -e", nor do a "set -e".
> The list is attached. This list includes the 12 remaining scripts not
> starting on #! (bugs are already filed for these).

Looks like you were talking about these bugs:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=colis-shparser;users=trei...@debian.org

> What is your opinion? Policy says "should", not "must". If you agree
> with the MBF, what do you think would be the appropriate severity?

I note that naively adding "set -e" can make shell scripts more
brittle, especially when using diff or other commands that can return
failure in unforeseen circumstances. When doing the MBF, please remind
people to read their scripts, note the range of exit codes for each
command and add "|| true" for commands that return failure exit codes
that do not indicate failures or indicate conditions that should not
terminate the maintainer script.

PS: will you be packaging the software produced by the CoLiS project?
PPS: the lintshell link on the CoLiS website requires a login.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Intended MBF: maintainer scripts not using strict mode

[Paul Wise]

On Tue, Jun 27, 2017 at 6:37 AM, Christoph Biedl wrote:

> Let's be honest: Shell scripts, while easy to write, carry too many
> risks of unsafe programming. So while your proposed fixing is a step in
> the right direction, this is all just band-aid. We (as in Debian) should
> look forward and try to replace these maintainer scripts with something
> more error-prone. Niels has mentioned declarative approaches which seem
> like a good idea. No idea about the status, though, and I'm interested
> in details if there already are some.

I assume you meant *less* error-prone :)

For maintainer scripts that can't be converted to the declarative
approaches, I hope that folks are checking their scripts using the
various tools available to do that, especially shellcheck:

https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/tree/data/sh.ini

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Possible bug

[Paul Wise]

On Sun, Jun 25, 2017 at 6:06 PM, Alessio Abrugiati wrote:

> Hi, I found an error in installing a live 9.0.1 but only with qemu, with
> qemu not working the mirror part.

Please file an installation report using these instructions:

https://www.debian.org/releases/stable/amd64/apas04.html.en

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Help me

[Paul Wise]

On Sat, Jun 17, 2017 at 12:05 AM, МБУЗ ГКБ № 1 wrote:

> Hi no work in Debian 8.8
> No start firebird 2.5 classic and super error

Please contact our support channels for help diagnosing the error:

https://www.debian.org/support

Once you have diagnosed where the problem is, you can report a bug:

https://www.debian.org/Bugs/Reporting

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Please add lzip support in the repository

[Paul Wise]

On Thu, Jun 15, 2017 at 9:05 PM, Christoph Biedl wrote:

> I'm not keen on extending regular expressions like
>
> \.(gz|bz2|lzma|xz)$
>
> that I have in many places again and again.

That sort of hard-coding should stop, if you see it somewhere please
switch to using apt, either via the apt libraries or via apt-helper
cat-file.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Too many Recommends (in particular on mail-transport-agent)

[Paul Wise]

On Tue, Jun 6, 2017 at 9:55 PM, Adam Borowski wrote:

> bash-completion: bash dput-ng licensecheck
> * DEBATABLE: I like the Tab key to do something reasonable,
>   "bash-completion" means you never know what you'll get.

I definitely would not want to run a Debian system that didn't have
bash-completion installed. Being able to tab complete command-line
arguments and apt package names are two examples of invaluable
features this package provides.

> fonts-cantarell: fontforge-common
> * BAD: FontForge works perfectly without it

Cantarell is the default font in the UI, changing it would mean Debian
FontForge would look very different to FontForge on other distros.

https://codesearch.debian.net/search?q=Cantarell+package%3Afontforge

> freepats: libwildmidi-config timidity
> * BAD: freepats is too ugly to live: abysmal quality, lacks instruments for
>   pretty much any .mid file in the wild.  We do have a bunch of good
>   alternatives.  timgm6mb-soundfont for one is 5.6 times smaller yet is
>   complete.

We probably need a pair of virtual packages for this.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Switch default installation image link?

[Paul Wise]

On Tue, Jun 6, 2017 at 8:01 PM, Steve McIntyre wrote:

> For a number of years, we've been linking to the amd64/i386 netinst
> installer image from the front page.

Seems reasonable, perhaps with a small link for other options.

> I'm *also* tempted to switch from the netinst to the first DVD image
> instead - network connections have improved a lot.

I think that improvement has been mostly specific to Europe and maybe
also parts of Asia & North America. Most of Australia is going to be
stuck on ADSL for a long time to come and remembering back to Sicelo's
DebConf16 talk, Africa might too.

https://debconf16.debconf.org/talks/121/
https://en.wikipedia.org/wiki/List_of_countries_by_Internet_connection_speeds

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: /root directory

[Paul Wise]

On Mon, Jun 5, 2017 at 11:08 PM,  José Vieira wrote:

> In the Debian tutorials, somewhere in the Debian file system[1] page it 
> states:
> 1. https://www.debian-tutorials.com/debian-file-system

FYI, this page isn't maintained by Debian so we can't fix it. You
might want to leave a comment on the page.

> Would it be feasible to change the name of the /root directory to sort out
> the confusion? It could be renamed as /adm, for instance.

Anyone can do that on their own systems quite simply (manually update
/etc/passwd, rename the directory) but I expect that doing this by
default would break some folks automation and more folks expectations
about the default root user home directory.

> I’m not an IT educated person, so I recognize that I may be suggesting a
> nonsense. However, as a fairly recent user of a Debian based distro, I got
> quite confused and somehow frustrated for not properly understanding what
> the guidelines were telling me to do. Besides this “root” issue, there is
> also the indiscriminate use of /home and home, as well as the use of /home
> (ou just home) directory and /home partition. I’ve sorted it out now, but
> it’s very confusing for someone who newly arrives to linux (Debian, in the
> case).

If we called / the base directory and /root the root user home
directory, would that help? If you can find any Debian documentation
where this is discussed then we can clarify it, but the page you
linked to isn't maintained by Debian.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: What does "freeze" mean?

[Paul Wise]

On Mon, Jun 5, 2017 at 7:49 PM, Hans wrote:

> I know, debian is now on freeze. But what does this actually mean?

These links should help with getting an idea about that:

https://www.debian.org/doc/manuals/debian-faq/ch-ftparchives#s-testing
https://www.debian.org/releases/testing/
https://www.debian.org/devel/testing
https://www.debian.org/doc/manuals/developers-reference/pkgs#testing
https://release.debian.org/testing/freeze_policy.html
https://release.debian.org/

In practice it means that the release team decides what it means for
any one release. For Debian stretch the freeze progressed like this:

2016-11-05: freeze of all library/toolchain/etc transitions
2016-12-08: increased unstable -> testing migrations to 10 days for all packages
2017-01-07: stopped addition of new packages
2017-01-07: stopped addition of removed packages
2017-02-05: required approval for all changes

> Does this mean, only security fixes are implemented or does this also mean,
> packages, which are buggy are still be fixed.

Security, release-critical and other important bugs are fixed during the freeze.

> I am asking, because I filed a bugreport to "uswsusp" (running debian/testing
> i386 on an EEEPC) because resume does not work (hibernation=suspend-to-disk is
> ok, but when I want to resume, it reloads the image from swap, then full
> resets to BIOS again).

It would have been useful to have included the bug number (#862743)
here. The cause of the bug has not been diagnosed and no patch has
been written to fix it. Both of those have to happen before the bug
can be closed. It is generally better to ask for help on the Debian
user support channels about bugs that do not have a diagnosis yet and
only when the cause has been figured out, then file the bug report.

https://www.debian.org/support

Please note that the uswsusp shouldn't be needed any more as systemd
handles hibernation IIRC. It is possible that removing uswsusp will
fix the issue for you.

In addition, uswsusp doesn't look well maintained as it hasn't seen an
upload from the maintainers since 2014-11-01 and the primary
maintainer looks missing in action (MIA). Could you please report the
primary maintainer Rodolfo García Peñas (kix) to the MIA team?

https://www.debian.org/doc/manuals/developers-reference/ch07.en.html#mia-qa

> Back to my topic: Does freeze mean, such bugs are fixed after(!) the release 
> of
> next stable debian or does such a bug inhibit the upcoming release?

Bugs like the one you have reported probably qualify for fixing during
the freeze and also for fixing in a stretch point release after the
initial release happens, once the cause has been discovered and a fix
for the issue found.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Quantic

[Paul Wise]

On Sat, May 27, 2017 at 11:22 PM, Maxime Vitrac wrote:

> Is there a "quantic" group or something like that?

Could you explain what you mean by quantic?

If you are talking about mathematics, the Debian Science team might be
interesting to you.

https://www.debian.org/blends/
https://wiki.debian.org/DebianScience
https://blends.debian.org/science/tasks/mathematics

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Accepted check-all-the-things 2017.05.20 (source) into unstable

[Paul Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 20 May 2017 17:33:18 +0800
Source: check-all-the-things
Binary: check-all-the-things
Architecture: source
Version: 2017.05.20
Distribution: unstable
Urgency: medium
Maintainer: Paul Wise <p...@debian.org>
Changed-By: Paul Wise <p...@debian.org>
Description:
 check-all-the-things - check all of the things!
Changes:
 check-all-the-things (2017.05.20) unstable; urgency=medium
 .
   * New release.
 - The "Check Things Securely Yet Again" release
 - Support BSD versions of the find command
 - Support running in more types of terminals/places
 - Support running commands in other dirs for safety
 - Support properly disabling flags/checks
 - Disable remarks about already disabled checks
 - Update documentation, TODO items and URLs
 - Print remarks more nicely in certain situations
 - Print filenames and line numbers where possible
 - Flag checks:
   + dangerous - rpmlint ocaml-lintian
   + run-in-tmp-dir - luacheck puppet-lint epubcheck erl-tidy
   + fixme-silent - flawfinder gettext-lint-* luacheck hlint
   + network - cme-check-dpkg
   + manual - gettext-lint-spell
 - Fix complexity - prevent arbitrary code execution
 - Fix perlcritic - disable code execution, only run when perl present,
increase verbosity to be more useful
 - Fix clang-tidy regression from version 2016.06.29
 - Fix zzuf - incorrect path matches
 - Fix yamllint - incorrect find argument grouping
 - Fix ELF & Perl checks - add MIME types
 - Fix grep checks - use short options for portability
 - Fix xapian-check - crash due to use of format strings
 - Fix uudecode - include filenames in command-line
 - Fix insecure-recv-keys - typo in regex
 - Fix appstreamcli - unknown command-line option
 - Fix m64-m32 - reduce false positives
 - Fix gettext-lint-spell - add missing dependency, drop *.pot
 - Fix afl - check it is installed properly
 - Fix embed-dirs - add inc/ dirs for Perl packages
 - Add podchecker - check Perl POD documentation
 - Add pscan - check C printf format strings
 - Add leaktracer - check programs for memory leaks
 - Add tmperamental - check programs for tmpfile issues
 - Add govet - report suspicious Go source code
 - Add golint - report Go source code lint
 - Add goimports - check missing/unused Go import lines
 - Add rubocop - check Ruby code against Ruby Style Guide
 - Add roodi - check Ruby code for design issues
 - Add gendarme - check Mono/.NET ECMA CIL files
 - Add make-phony - find misspelled .PHONY targets
 - Add mypy - check Python static typing hints
 - Add pyroma - check Python packaging quality
 - Add bandit - check Python security quality
 - Add dodgy - check dodgy lines in Python code
 - Add vulture - check for dead Python code
 - Add pycodestyle - check Python code style
 - Add pydocstyle - check Python documentation style
 - Add proselint - check for English prose issues
 - Add chktex - check typographic errors in LaTeX docs
 - Add fitscheck/wcslint/volint - FITS/VOTable files
 - Add putty-private-key & openssh-private-key-rsa1
 - Remove ghc-mod - just a wrapper for hlint
 - TODO items for wtf flake8-plugins xpi-addons-linter
   go-fix libdetectcoll sha1collisiondetection giffix
   haxelint dockerlint dockerfile_lint dockerfile_checker
   truffleHog pyt chap Devel::Plumber
Checksums-Sha1:
 640893da1c098acf7d88fdd42881ab85c4f7a8c3 1709 
check-all-the-things_2017.05.20.dsc
 50ef77d47ad7e5fa623581e72473dd773831fdc5 33548 
check-all-the-things_2017.05.20.tar.xz
Checksums-Sha256:
 f8e5538036475bca3fc0665e16e952a451853f7c41ebad5f7b9385bbc62e8467 1709 
check-all-the-things_2017.05.20.dsc
 c099633c1daf96f57a29cef2f01aae44a23644d21b76bb3edbc0fbf1b8b8f5b5 33548 
check-all-the-things_2017.05.20.tar.xz
Files:
 4c7532b9ee9cca4040c31ab67c7843e2 1709 devel optional 
check-all-the-things_2017.05.20.dsc
 04c7e4c3bcb7a1481fa8493ed9fe2e20 33548 devel optional 
check-all-the-things_2017.05.20.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAlkgHRMACgkQMRa6Xp/6
aaPWRBAAgTa/ebYspLiAI8TXnXMySybaRNsWlHLZPFQ0UplqaNa0UrGvh5MLDQ1Z
/tYwtZG3H4uei8SRRPFXVWlTpq7/iboTkbyaXxVL6NBh9cuXjngnUtwF99PiKUl4
dqLIitUsYRhHioWXqNyGMB7/RHoD2x3j5MfjDPzt8wsYBJc81q0nrVvo1ds0hn7F
SfkqAEONtaGnKQMVwhzeQ1KRiHONg//BMju6C48xcg5Lc2AywD5AIMYTaZmTFKuK
XebjcpjZN9BiPlcJA7iV0PK1/CQACrR2yRl7V/wWVJ01SL7dbAXBFCw4n5ToDbLU
YvhaKBNtMeDm9qC9ziTN0cm9lIbjS/oUU7WmqN2sdHYsuLP4Vxv9KH+Ck6AWsggc
mDegxC0cHc26DBNeo7f3Khdud0EtrS/LoBYIhJYxJN5hjzdNW/auk5R2zbM6e///
JH+W4G+gVPkfIPupSAmu9ZFXSmmBkBqz2DMN3nyIF/Hh/WOq1ZNhHX3q4plAJz8q
541gAtpZUbC7noJrtiV9EysFQNPPGt83v6a6XO7ordRhY3byCuyocuPyKTdSD12w
D3H6NXO+axMIFqrIQzD1/2IRpymCTiOit5YkHY2KqJy7HmrCKRYOopvqLsZok+3L
WhM+F5x/IvMXjpSZLueBrDu+2cvP8W5nqo9e2qgRqGJ1NT0fF1A=
=I4f/
-END PGP SIGNATURE-

Re: Packaging of libraries with unstable ABI (D, Rust, Go, ...)

[Paul Wise]

On Thu, May 18, 2017 at 10:37 PM, Matthias Klumpp wrote:

> Unfortunately though, the D language ABI isn't stable, so any future
> compiler update might break the software in weird ways unless all D
> software is recompiled when a new compiler is released.
> To make things worse, D also has three different compilers (which
> share the same frontend), the GNU D Compiler (GDC), LLVM D Compiler
> (LDC) and the reference compiler Digital Mars D compiler (DMD).
> All compilers have different advantages, but they also have
> incompatible ABI, especially because each comes with a separate
> version of the D runtime and standard libraries.

Is there any chance of the D community creating a standard ABI that
will be stable and shared all of the compilers?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Bug#862775: ITP: visitors -- OCaml syntax extension for object-oriented visitors

[Paul Wise]

On Wed, May 17, 2017 at 3:51 AM, Ralf Treinen wrote:

> * Package name: visitors
>   Version : 20170404

FYI, there was already a visitors source package in Debian (RMed after
jessie) so I would suggest using a less generic source name, maybe
ocaml-visitors.

https://packages.qa.debian.org/v/visitors.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Paul Wise]

On Tue, May 16, 2017 at 12:39 AM, Antonio Terceiro wrote:

> Right. IIRC that was said to me at Debconf16 about Debian-specific
> services (such as ci.debian.net which was the context of my question).

Yeah, for codebases maintained by the service maintainer not having
packages seems reasonable (but not for dependencies of that codebase)
and that seems to be the current feeling within DSA.

Personally I'm leaning towards the feeling that all configuration,
code and dependencies for Debian services should be packaged and
subjected to the usual Debian QA activities but I acknowledge that the
current archive setup (testing migration plus backporting etc) doesn't
necessarily make this easy. The PPA/bikeshed mechanism might make it
more feasible if that happens.

> It makes sense to prefer packages for something that has a proper
> upstream that is not us, which is the case in this discussion.

Right.

> In any case, it would be super useful to have this explicitly documented
> at the DSA website.

AFAICT, DSA doesn't have any hard rules/policy written down, just
evaluation on a case-by-case basis.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Paul Wise]

On Mon, May 15, 2017 at 7:48 PM, Antonio Terceiro wrote:

> This is a common misconception. DSA does *not* require that the service
> is packaged. On the contrary, they say it's better if the service is
> *not* from a package because this way the service admin does not need to
> have root access on the machine where the service is hosted.

Uhhh, I think that misrepresents DSA's position. For most things that
might run on a future Alioth replacement, we would definitely want
them packaged properly.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Paul Wise]

On Mon, May 15, 2017 at 6:54 PM, Medical Wei wrote:

> I think we need to start having a catchphrase

Check:

$ curl -s https://www.debian.org/ | grep ''
  Debian -- The Universal Operating System 

> What I know is that we have revised our design but that is not attractive
> enough.

We revised our visual design, but our content remains the same.

> (I did lxde.org from old.lxde.org but I don't know if that seems
> "attractive".)

TBH if I was confronted with the new LXDE web design with CSS turned
on, I would probably just close the page. The old page is way more
informative and less heavy on the marketing.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Paul Wise]

On Mon, May 15, 2017 at 6:12 PM, lumin wrote:

> https://www.debian.org/
>
> We are the last major distro that move to systemd as the
> default init system. And now we are the last major distro
> that keeps an old design of homepage.

I'd like to point out that what you are seeing is the *new* design,
not the old design of the Debian website, which looked quite
different.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Accepted check-all-the-things 2017.01.15.1 (source) into unstable

[Paul Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 27 Apr 2017 20:34:00 +0800
Source: check-all-the-things
Binary: check-all-the-things
Architecture: source
Version: 2017.01.15.1
Distribution: unstable
Urgency: high
Maintainer: Paul Wise <p...@debian.org>
Changed-By: Paul Wise <p...@debian.org>
Description:
 check-all-the-things - check all of the things!
Changes:
 check-all-the-things (2017.01.15.1) unstable; urgency=high
 .
   * New release.
 - The "Check Shiny Things More Securely" release
 - Fix perlcritic to not execute code from the current dir
Checksums-Sha1:
 ea05f32135e956a9f98f0f6890b3d9b43190b0b8 1717 
check-all-the-things_2017.01.15.1.dsc
 703ec6c3f841d8f554d9eee5b5733e5404b56877 30756 
check-all-the-things_2017.01.15.1.tar.xz
 088dc0f9eb18e76ee49127ca0d205c106e97e9c1 7013 
check-all-the-things_2017.01.15.1_source.buildinfo
Checksums-Sha256:
 8617792062ba2d090928ad63d49f5dc0c77586aa1f472298e51bf96ff507a4ca 1717 
check-all-the-things_2017.01.15.1.dsc
 707e86d56980b52b92ffd75fb227e507cc6e5d7532912861fbf25e75b5860282 30756 
check-all-the-things_2017.01.15.1.tar.xz
 14f97ee1c5673e2f4f0f5e81428238c3d81b306cddf7059c5e9fbb6adda74cd8 7013 
check-all-the-things_2017.01.15.1_source.buildinfo
Files:
 a33aacc88e3c62d6b1a78bad986b3dd8 1717 devel optional 
check-all-the-things_2017.01.15.1.dsc
 d284ada5d98b3b69c657e2f71803d9cc 30756 devel optional 
check-all-the-things_2017.01.15.1.tar.xz
 3d204b16ddc4b25a40f3c3bc4fbf506c 7013 devel optional 
check-all-the-things_2017.01.15.1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAlkB57UACgkQMRa6Xp/6
aaPM1Q/9Fu9P0UN+1zPpzxXSwo0FdHO5X41u2+kYoylv7GF+6t2Q8WJUBpVZX8dE
Q7FjGHfRKTl3kW9psK+KU6I8B1zkfN+OeE5YpQWyb/fwMZ5Yw2Jh+omX0Wg7iRze
heJNxM1fgvlRcT44RA3t8Ry0eonqIlDxyqnNwGIxXGkK3hNkpX3dUZ7mQIa0gjrb
KzyzEHp8Hy0RoiThS4i1YEqD9Y9lekpM2u3p1sUAkHq/QJFYUplPxThJpwzAH81P
6aLE+eZ8AjyAqff+lMIk0QEuYPWYRaMCgwKFLsDWlgYgLWi0Ahc55ImYJ6YAiHrf
EgeB8NkIFi/2UzRoL4H7UO5ietPy76yyz663df9kbFPLAbIJM1V3fADagR93bCWG
9fLMMP+RN4XjD5U+gDr1j25vtXQwn/i54fYN9pylQ2IWM4X4GTo1AZ49DK3rjC/B
dJLWw1DDCm91BlZzTAu+F6YOpdhf7XOh90olxiH8mj73+pHn9wKfNgP9LFRxHQyd
qLX8HOBDMHGRgV2OiJvvI/2ZVlS4d0trYjpiR8M9QQLFpLeObsSsRpFfGC1UydRN
CMDsw2pLmWBoYFnKsFBjrc3phwU+FNnw424RmBxKJCelH/2ep/wxYNu88Q+/mXeR
F4MlSig4+tnmrcO0v0NYdUV+wmcmLDAjiOi4xxfl5kEQdVH33KI=
=C+XC
-END PGP SIGNATURE-

Re: I need your advice

[Paul Wise]

On Thu, Apr 27, 2017 at 12:27 PM, Pavlo Solntsev wrote:

> will not work so easily. I need to rebuild libgda and glib. It is
> doable but, as you understands, I would prefer leave this solution as
> my last chance.

Both of these are in Debian already, you might want to file bugs
asking to get the packages updated to the versions you need in
experimental (due to the stretch freeze). Bonus points if you join the
Debian GNOME team and help them with this task.

> I am not sure what is called "GNOME runtime".

Sorry, I meant the Flatpak GNOME runtime:

http://flatpak.org/runtimes.html

> I already done this. I just need to go through the standard process.

BTW, the standard procedure begins with letting others know your intent:

https://www.debian.org/devel/wnpp/

> It still doesn't solve problem with upstream development.

I'm not understanding what you mean here.

> I put all my packages here
> https://drive.google.com/open?id=0B8fjSLiFRX_PZWFnbUVfMTcxYTA

That isn't accessible to people without JavaScript.

> Definitely, all three suggestions serve different needs.
> Many thanks for your comments.

I hope they were helpful.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: I need your advice

[Paul Wise]

On Thu, Apr 27, 2017 at 11:25 AM, Pavlo Solntsev wrote:

> I need your advice about development under Debian. I use testing repo.
> My desktop environment is Gnome and I contribute to some Gnome's
> projects. For me the big challenge is to work with upstream libraries.
> Basically, questions lays in the plane how to maintain upstream library
> that I can use in my own project. For now, I can't build some libraries
> because of dependency that are not available in my debian repo. I know
> jhbuild can be used but some libraries, e.g. libgdamm are not available
> as modules. I checked Flatpak but can't figure out how to use my own
> library for development. I just wanted to ask for advice if someone can
> share an experience in this matter that would be very helpful.

Your options are:

Manually build libgdamm/etc and install them in ~/ or /opt or /usr/local

Talk to the jhbuild folks about getting libgdamm/etc into that.

Talk to the libgdamm/etc folks about adding it to the GNOME runtime.

Package libgdamm/etc in .deb form and get them into Debian experimental:

https://mentors.debian.net/intro-maintainers

Personally, I would choose just the last one or possibly all of the last three.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: policy for shipping sysctl.d snippets in packages?

[Paul Wise]

On Wed, Apr 26, 2017 at 2:52 AM, Christian Seiler wrote:

> But this is a much more general problem. A lot of software in Debian
> ships configuration files in /etc that look like this:
>
> #
> # Setting ABC
> #
> #ABC = 123

I always thought that Debian shipping what is essentially
documentation in /etc is weird. This stuff belongs in the manual pages
or other documentation.

> If in any of these cases the default in the code changes, the behavior
> of the software changes.

Indeed, most default configuration is in one of /usr/*bin /usr/lib
/usr/share and isn't in a form that can be version controlled or
compared between versions.

> In my experience, having to merge configuration files on updates
> has cost me a _lot_ of time.

Especially since most packages don't use ucf, which has 3-way merge.

> Personally, from a user point of view  I really like the "vendor
> defaults in /usr, user configuration in /etc" scheme.

Likewise.

> I consider dpkg's default behavior to be horrible (no copy
> of the original is saved anywhere, so no 3-way merge is
> possible [2]), I never completely grokked ucf as a user (I stumbled
> upon ucf prompts on updates of some packages that used it, and only
> once it actually did manage to do what I wanted automatically, the
> other times I found the way you could manually intervene in the
> merging process there to be highly unintuitive), and I gave up on
> trying to understand ucf from a package maintainer's perspective a
> long time ago.

I've always found ucf's 3-way merge to do exactly what I want.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Bug#761348: ftp.debian.org: need machine-readable metadata about suites & repositories

[Paul Wise]

On Fri, 2017-04-21 at 09:28 +0200, Michael Stapelberg wrote:

> pabs, what’s the current status on this?

Mostly at the 'collecting information' stage; about what hard-coding
exists and what requirements there might be etc.

> AFAICT, you mentioned you wanted to come up with a spec on the
> RepositoryFormat wiki page. I don’t see that on the RepositoryFormat
> wiki page yet.

I wrote a couple of sketches of possible ideas here:

https://wiki.debian.org/SuitesAndReposExtension#Possible_solutions

FYI the repository format page has moved here:

https://wiki.debian.org/DebianRepository/Format

> Is there any way to help?

Help on this is very much welcome as I don't have much time for it.
Go through as many Debian services as possible, look for hard-coding of
suites, codenames, architectures, compression formats etc and add it to
the SuitesAndReposExtension wiki page and send patches to reduce
hard-coding by getting architecture info from the archive or
suites information from the ftp-master API.

https://api.ftp-master.debian.org/list_paths

> I’m also interested in this issue due to hardcoding in manpages.d.o,
> which I’ve now described on
> https://wiki.debian.org/SuitesAndReposExtension#manpages.debian.org

Thanks for that.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: Bug#857508: ITP: gnome-games-app -- Game browser and launcher for GNOME

[Paul Wise]

On Sun, Apr 16, 2017 at 2:56 PM, Evgeni Golov wrote:

> Why not retire the gnome-games metapackage if it was only for upgrades?
> As far as I can see it, the real package is in wheezy, and since jessie
> we have the transitional one. Same will apply for stretch. And for buster
> you can safely drop it and re-introduce the real app under that name?

AFAICT, gnome-games is a meta-package not a transitional package.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: "Ask HN: What do you want to see in Ubuntu 17.10?"

[Paul Wise]

On Thu, Apr 6, 2017 at 7:22 AM, Russell Stuart wrote:

> Anyway, this discussion prompted me to get off my bum and look at why
> unattended-upgrades wasn't working.  Turns out the default install has
> "label=Debian-Security", and all these laptops are running testing.  I
> guess the assumption that people running testing have the wherewithal
> to configure their machines properly isn't unreasonable.

Theoretically security.d.o does support security upgrades for testing
but in practice those happen via unstable. To get security upgrades
from unstable and everything else from testing, I pin testing >
unstable and use a script to pin security upgrades based on the output
of debsecan.

The script is available in this mail:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725934#20

Needs this setup also:

ln -s /var/lib/debsecan/apt_preferences /etc/apt/preferences.d/debsecan

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Database of all (historic) package versions - dak?

[Paul Wise]

On Wed, Apr 12, 2017 at 9:09 PM, Philipp Hahn wrote:

> do we (or someone else) have a database of all (source-)packages and
> their versions ever released in a Debian suite?

snapshot.d.o is approximately that, but it doesn't have everything:

http://snapshot.debian.org/

You can interact with it via this API:

https://anonscm.debian.org/cgit/mirror/snapshot.debian.org.git/tree/API

> but I would like to know which exact version was is 7.0, 7.1, .., 7.7
> and 8.0, too.

Maybe look at the CD list files here:

http://cdimage.debian.org/cdimage/archive/8.4.0/amd64/list-cd/

> I guess  would work

I might be wrong but I don't think ProjectB includes what you want.

> I'm denied login permission on "mirror.ftp-master.debian.org".

Most debian.org machines require Debian membership to login.

BTW, could you state the reason you are looking for this database?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: "Ask HN: What do you want to see in Ubuntu 17.10?"

[Paul Wise]

On Sat, Apr 1, 2017 at 4:48 AM, Chris Lamb wrote:

> There's a very active conversation happening on Hacker News right
> now entitled «What do you want to see in Ubuntu 17.10?»:
>
>   https://news.ycombinator.com/item?id=14002821

There is a followup and some analysis of the thread here:

http://blog.dustinkirkland.com/2017/04/thank-you-note-to-hackernews.html

It is being discussed here:

https://news.ycombinator.com/item?id=14049868

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: "Ask HN: What do you want to see in Ubuntu 17.10?"

[Paul Wise]

On Wed, Apr 5, 2017 at 4:47 AM, Sean Whitton wrote:

> Do you know if anyone is working on including this in the default
> desktop install?  If it works well, it seems like an uncontroversial
> inclusion that does not depend on the debate over unattended-upgrades.
> I don't know which package would need to be changed, so I'm not sure
> where to look for an existing wishlist bug.

Not AFAIK. I would guess that needrestart would need to be promoted to
standard priority and needrestart-session would need to be added to
tasksel's task-desktop package, or to each of the task-*-desktop
packages; this adds wxWidgets to the default install though. The
latter would allow different desktops to add different
implementations, for example if someone wrote a GNOME Shell extension
to highlight windows of applications that need restarting.

One important downside of needrestart/needrestart-session/systemd is
that it can't automatically restart systemd user services and root
systemctl can't restart user services, even via su/sudo and
needrestart-session doesn't restart them AFAIK. I guess this should be
fixed by needrestart-session doing restarts (or stops for
RefuseManualStart=true) of user services when requested to start via
the dbus call, plus adding a restart/stop button for processes
corresponding to user services.

Another downside of needrestart is that a lot of stuff doesn't support
being restarted sanely, like dbus, display managers, networking stuff,
/etc/rc.local, etc. There is a blacklist for that but it doesn't yet
include rc.local (#852864):

https://sources.debian.net/src/needrestart/2.11-2/ex/needrestart.conf/#L79

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: "Ask HN: What do you want to see in Ubuntu 17.10?"

[Paul Wise]

On Tue, Apr 4, 2017 at 6:58 AM, Sean Whitton wrote:

> Fixing #744753 would ensure systems got the updates.
> The only issue then is restarting the applications.

needrestart and needrestart-session handles that. There are also many
other implementations but needrestart seems to be the most complete
solution right now.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Convenient access to Debian keyrings

[Paul Wise]

On Sun, Apr 2, 2017 at 7:06 AM, gregor herrmann wrote:

> % crontab -l | grep debian-keyring
> 30 17 * * * /usr/bin/rsync -rlptDq 
> "keyring.debian.org::keyrings/keyrings/*.gpg" 
> /home/gregoa/.gnupg/debian-keyring

The rsync protocol is unencrypted, I'd suggest switching this to SSH
(one colon instead of two). You could also use rsync over TLS on port
1873 (uses the same cert as via http). I couldn't easily work out how
to do it with stunnel but the following works with socat. I thought
there was also a way to verify the keyring when it was at rest but
can't find where I saw that.

rsync --rsh 'sh -c "socat OPENSSL:keyring.debian.org:1873 STDIO"'
keyring.debian.org::keyrings .

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: translator

[Paul Wise]

On Sun, Mar 26, 2017 at 12:39 PM, Gaga Tavxelidze wrote:

> Do you need Georgian-English translator?

The Debian Installer has some support for Georgian, if you would like
to volunteer your time to work on improving it, please see the links
on this wiki page:

https://wiki.debian.org/DebianInstaller#Internationalization_resources

We currently do not have a translation team for Georgian, if you would
like to volunteer your time to create a Georgian translation team,
please see the instructions further down on this page on the Debian
website:

https://www.debian.org/international/

If you need any guidance in creating a Georgian translation team,
please contact the debian-i18n mailing list:

https://lists.debian.org/debian-i18n/

If you are part of a local Debian user group in Georgia, you might
like to add information about that group to this wiki page:

https://wiki.debian.org/LocalGroups

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Rethinking dynamic linking a bit (was: Re: Depends/Recommends from libraries)

[Paul Wise]

On Wed, Mar 22, 2017 at 6:17 PM, Christian Seiler wrote:

> For $DAYJOB I had to work on Mac OS X a bit, and they have an interesting
> feature there: weakly binding to a shared library.

Apparently Solaris has support for optional shared libraries:

https://lists.debian.org/debian-devel/2015/02/msg00261.html
https://sourceware.org/ml/libc-help/2013-02/msg00017.html
http://comments.gmane.org/gmane.comp.handhelds.tizen.devel/4892

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Coorperation

[Paul Wise]

On Fri, Mar 17, 2017 at 10:21 AM, 李松林 wrote:

> I am a sales from Archermind Technology , we work together with Mstar ,
> and we want to debug Debian os ,

If you have a specific issue with Debian, please report a bug about it:

https://www.debian.org/Bugs/Reporting

If you are not sure which part of Debian to report the bug against,
please contact our support channels for help:

https://www.debian.org/support

> so can you give me a contact to for further cooperation .

Who are you interested in contacting and what kind of cooperation do
you have in mind?

There are many ways to help Debian, some of them are listed here:

https://www.debian.org/intro/help

Donations and sponsorship are appreciated:

https://www.debian.org/donations
https://debconf.org/sponsors/
https://www.debian.org/partners/

In 2018 the annual Debian conference will be held in Hsinchu, Taiwan.
It would be great if Archermind could help fund DebConf18 and
Archermind developers could attend DebConf18.

https://wiki.debconf.org/wiki/DebConf18

Sponsorship information for DebConf17 is listed here:

https://debconf17.debconf.org/sponsors/become-a-sponsor/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Accepted needrestart-session 0.3-4.1 (source) into unstable

[Paul Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 14 Mar 2017 15:37:11 +0800
Source: needrestart-session
Binary: needrestart-session
Architecture: source
Version: 0.3-4.1
Distribution: unstable
Urgency: medium
Maintainer: Patrick Matthäi <pmatth...@debian.org>
Changed-By: Paul Wise <p...@debian.org>
Description:
 needrestart-session - check for processes need to be restarted in user sessions
Closes: 787291 857703
Changes:
 needrestart-session (0.3-4.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Fix path to needrestart, now shows same results (Closes: #787291)
   * Don't fork before system(), fixes crash on double-click (Closes: #857703)
Checksums-Sha1:
 4c5eb1711d7cf56be15e25991d596970c6dbab92 1813 needrestart-session_0.3-4.1.dsc
 dbaa175c7e45e1ab1efe6cd3f96bf17bde9bb8e8 2728 
needrestart-session_0.3-4.1.debian.tar.xz
Checksums-Sha256:
 80b98452adc1f1b094a481861d93dd46681d2b79909e26d4a0105173a02eb394 1813 
needrestart-session_0.3-4.1.dsc
 de0734eff16cfe427fbe3c921d4fc0f572855c3637d8b186b3cf5af6a0e74622 2728 
needrestart-session_0.3-4.1.debian.tar.xz
Files:
 a238b03aa30a9f73b84f50fcd7414ce9 1813 admin optional 
needrestart-session_0.3-4.1.dsc
 426df8a188f3b0e124474b58eeb59c88 2728 admin optional 
needrestart-session_0.3-4.1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIyBAEBCAAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAljHni0ACgkQMRa6Xp/6
aaPTUA/3Wa+QAHBtsIvd0TDI26kpMISwxySVgChuFj32nI/RsGKVpZtbeDRXK2Tw
wcY1LbeZEeqScKsA14PDNMQeDYba5CmlR0ABiStoEcvOqcfnJLSygzd+7/GfFV7u
Q0tL3sZCxxhpcEZ8kvTpyadEiCRyVpZCHkKkr9aZOuN2nLB7isg1GfcK2XgXhXAZ
k6/AAqFKUBLmN6gPvfkvN1B7l/yJ5DAWObL5OvD4vRHf6J/AaB+7kWrHa91u+1/l
662QUbr1e1eT3brKWUhR4YBAX9DA9BS0JJJA7S0CMxGGAngsI8VvcZ9pbPpbaAkr
OKa16WYxyIHQGKYx7Oh9Nh5cbAELQpEJmYTPqoea1IOLotrVQM+ZQe2CWFusWLTI
SwLJ1/3XnT+/EgCINhC0vR5mrZgEFAI1Pa4PupWOU1+zuGfN6rnC4lOaPYIeY+5y
n8rhKayi84/HkYnWdTsLkKr/2W/gl92JZd1NIsdbn2nz9mEyVmGVJlBlDIM/4iQU
SXh0P1yIDvJLTHJ1VendI89yz1/OcDiEfXqAhvaIgK04QN9VI1X50U87GIkUwOx1
C4e7T8bJ08pA3Dula4yqyvx21/PsRx4cN9sCdnLs2XEx5Q0cYThjv5W20ojtSfaM
7E69j5w44p9WYsM5C7b4fM2c+HPIpy+5QNrznkT0jkvynhdDUA==
=wFVS
-END PGP SIGNATURE-

Re: Post-stretch mass bug filing: build-depending on automake1.11

[Paul Wise]

On Mon, Mar 13, 2017 at 1:36 AM, Simon McVittie wrote:

> Most of the packages that I've glanced at so far seem to have moved
> from an ancient version (often automake1.4 or automake1.9) to 1.11.
> In the past, Automake had a tendency to break compatibility
> between minor releases, making it desirable to lock the build system
> to the specific version that upstream used. However, recent versions
> have been queueing up incompatible changes for 2.0 instead (as
> described in the Automake 1.14 release notes,
> )
> so maybe many of these packages can track 1.x indefinitely?

Probably automake should have automake1 and automake2 binary packages
once they release 2.0?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Post-stretch mass bug filing: build-depending on automake1.11

[Paul Wise]

On Mon, Mar 13, 2017 at 1:36 AM, Simon McVittie wrote:

> Paul Wise <p...@debian.org>
>warzone2100 (U)

I've talked to folks on the upstream IRC channel and it appears to be
compatible with automake 1.14 so the latest version will probably
work.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Bits from the DPL -- January-February 2017

[Paul Wise]

On Mon, Mar 13, 2017 at 12:58 AM, jathan wrote:

> Hello. If I want to organize a Bug Squashing Party in my city, it could
> be in any month before July 2017? Thanks and regards.

You can organise a BSP at any time, but obviously before the release
is more helpful to the release :)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Release file for own backport repository?

[Paul Wise]

On Thu, Mar 9, 2017 at 7:36 PM, Joerg Desch wrote:

> After this, "apt-get update" prints the error (jessie expected but jessie-
> backports received):

Did you also update your sources.list?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Depends/Recommends from libraries

[Paul Wise]

On Thu, Mar 9, 2017 at 11:48 AM, Michael Biebl wrote:

> out of the box. Unfortunately we don't have a well supported mechanism
> which would install such hardware-enablement packages when the hardware
> is plugged in.

Is the AppStream hardware support stuff not well supported in the desktops?

https://wiki.debian.org/AppStream/Guidelines#Announcing_supported_hardware

We do have at least one tool in Debian supporting it:

http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Non-free RFCs in stretch

[Paul Wise]

On Wed, Mar 8, 2017 at 12:16 PM, Tollef Fog Heen wrote:

> A package can only be in a single section.

That wouldn't prevent adding subsetted Packages files:

deb http://ftp.debian.org/debian/ unstable main non-free/firmware non-free/docs

Types: deb
URIs: http://ftp.debian.org/debian/
Suites: unstable
Components: main non-free/firmware non-free/docs

-- 
bye,
pabs

https://wiki.debian.org/PaulWise