Re: Minutes from the "32bit architectures in Debian"-bof

[Marco d'Itri]

On Aug 25, Russ Allbery  wrote:

> > - for i386, there is still sold new hardware with 32bit-only. Are
> >   there open issues for i386 (apart from the 32bit-generic ones)?
> >   Discussion that we need to get rid of it one day should be started.
> Can we fully support cross-grading to amd64 before we do that?  My
> remaining i386 systems, and I'm sure I'm not the only one, are systems
> that I've been continuously dist-upgrading for some time precisely because
> I don't want to rebuild a system from scratch.
+1

Probably not much work is needed, I remember cross-grading from armel to 
armhf more than one year ago with some manual hacking but no major 
troubles.

-- 
ciao,
Marco


pgpkUmFEyWVyj.pgp
Description: PGP signature

Re: libstdc++ follow-up transitions

[Simon McVittie]

On 17/08/15 11:07, Matthias Klose wrote:
> There is now another test rebuild [2] done
> with an augmented dh_makeshlibs printing cxx11 symbols in libraries [3].  No 
> new
> bug reports were filed yet.
...
> [2]
https://people.debian.org/~doko/logs/gcc5-20150813/archive-gcc-08-13-2015/
> [3] deb https://people.debian.org/~doko/tmp/gcc-5 ./

I have gone through the ~500 logs that mention CXX11 and added them to
. I have not done mass-bug-filing or
checked how many rdeps there were. I am not an expert on the finer
points of C++ ABIs, so my attempts to partition the list into "exports
C++11" and "uses C++11" might not be entirely accurate, but it's a
start; if nothing else, it's useful to be able to search the titanpad
for a package name to see whether another package's build-dependencies
could potentially need a transition.

Please leave a note on the titanpad to "claim" a block of package names
before doing any mass-bug-filing, to avoid duplication. The "uses C++11"
set might still need a mass-bug-filing asking their maintainers to
check, but I think they're lower priority than the "exports C++11" set.

If it wasn't such an intrusive upstream change, I'd say we need a
release goal "C++ libraries use -fvisibility=hidden to hide all non-ABI
symbols" before next time this happens, so that the non-ABI symbols just
don't show up...

Release team, here are some suggestions for binNMUs and other
wanna-build interactions:

Fixes for some earlier failures, and version skews caused by
maintainer-built binaries not being discarded:

# retry failed build with binNMU'd imagemagick
gb pfstools_1.8.5-2.1 . amd64
# for opencv transition; maintainer upload had the old opencv
nmu ffmpeg_7:2.7.2-2 . amd64 . -m "rebuild with libopencv-core2.4v5"

Looking at the build-dependencies of the "bad" packages, the following
transitions (mostly small ones) don't appear to be entangled with
anything that hasn't already started or involve rebuilding any libraries
that are thought to need transitions, so they might be a good way to
reduce the problem space and make it easier to reason about larger
transitions:

* https://release.debian.org/transitions/html/auto-adplug.html
* https://release.debian.org/transitions/html/auto-assimp.html
* https://release.debian.org/transitions/html/auto-gflags.html
* https://release.debian.org/transitions/html/auto-givaro.html
* https://release.debian.org/transitions/html/auto-gstreamermm-1.0.html
* https://release.debian.org/transitions/html/auto-libassa.html
* https://release.debian.org/transitions/html/auto-libccrtp.html
* https://release.debian.org/transitions/html/auto-libclaw.html
* https://release.debian.org/transitions/html/auto-libhmsbeagle.html
* https://release.debian.org/transitions/html/auto-libmusicbrainz3.html
* https://release.debian.org/transitions/html/auto-libopkele.html
* https://release.debian.org/transitions/html/auto-log4cplus.html
* https://release.debian.org/transitions/html/auto-mimetic.html
* https://release.debian.org/transitions/html/auto-modglue.html

Fixing protobuf on mips/mipsel () would
unblock a number of transitions, and the affected packages can be queued
up behind a dep-wait already if I understand the process correctly:

dw mixxx_1.11.0~dfsg-5 . mips mipsel . -m libprotobuf9v5
dw clementine_1.2.3+dfsg-4 . mips mipsel . -m libprotobuf9v5
dw cubemap_1.2.0-2 . mips mipsel . -m libprotobuf9v5
dw libphonenumber_6.3~svn698-4 . mips mipsel . -m libprotobuf9v5
dw osmpbf_1.3.3-5 . mips mipsel . -m libprotobuf9v5
dw pink-pony_1.4.1-1 . mips mipsel . -m libprotobuf9v5

Regards,
S

Automated download/update of data files

[Ole Streicher]

Hi all,

for astronomy (and probably for other parts of science) we need to
access data files that are updated from time to time. An example is the
difference between UTC and earth rotation. This data is updated every
week and is needed to precisely calculate the positions of stars on the
sky [1].

What is the best way to keep these data up to date in Debian? An
automated process as written in the pull request [1] is probably not the
right way, since it is a potential privacy violation. One could let the
user manually start the download. However, then he has to keep track of
all these little updates himself (or be educated enough to write
cronjobs, or re-enable the automatic download, which is more that one
could expect from an average scientist). Should one use debconf to ask
the user if he wants automatic updates here?

Best regards

Ole

[1] https://github.com/astroplanners/astroplan/pull/67

Re: Automated download/update of data files

[Marco d'Itri]

On Aug 25, Ole Streicher  wrote:

> What is the best way to keep these data up to date in Debian? An
> automated process as written in the pull request [1] is probably not the
> right way, since it is a potential privacy violation. One could let the
I am frankly tired of people screaming "privacy violation" at every 
automated process which interacts with the rest of the world.

-- 
ciao,
Marco


pgpkLEJesvsIi.pgp
Description: PGP signature

Re: [DDEB] Status on automatic debug packages (2015-08-24)

[Matthias Klose]

On 08/24/2015 11:12 PM, Niels Thykier wrote:
>  * debhelper will be including debug-ids in the control file to make it
>easier to find the necessary debug symbols for a given file.
>- Thanks to paultag for this idea.
>- This is merged into git and will be included in the next upload.

are these debug-ids the same as the build-id emitted by GCC? If yes, please
could you consider enabling these build-id's independent of the debhelper compat
level? I see no reason why these should be only enabled by compat 9.

Matthias

Re: [DDEB] Status on automatic debug packages (2015-08-24)

[Niels Thykier]

On 2015-08-25 11:29, Matthias Klose wrote:
> On 08/24/2015 11:12 PM, Niels Thykier wrote:
>>  * debhelper will be including debug-ids in the control file to make it
>>easier to find the necessary debug symbols for a given file.
>>- Thanks to paultag for this idea.
>>- This is merged into git and will be included in the next upload.
> 
> are these debug-ids the same as the build-id emitted by GCC? If yes, please
> could you consider enabling these build-id's independent of the debhelper 
> compat
> level? I see no reason why these should be only enabled by compat 9.
> 
> Matthias
> 

Hi,

Indeed, they are the same as emitted by GCC and they will be added
regardless of compat level (like ddebs itself).

~Niels





signature.asc
Description: OpenPGP digital signature

Re: Automated download/update of data files

[Danny Edel]

On 25/08/15 09:44, Ole Streicher wrote:
> What is the best way to keep these data up to date in Debian? An
> automated process as written in the pull request [1] is probably not the
> right way, since it is a potential privacy violation.

Hi Ole,

I wouldnt say that it' automatically bad to download current data on a
regular basis, as long as the system administrator *agreed* to do
automated downloads / have the computer talk to the outside world.

>From a system administrator's point of view, the following would be all
right to me:

* When you install the package, debconf asks if you want the automated
upgrades, preferably telling me how often its going to download them and
information about the source. (And I know I can always change my mind
later with dpkg --reconfigure packagename, although this could be
explicitly stated in the dialog).

Take a look at "dpkg-reconfigure popularity-contest" for an example.

* The choice is stored in /etc/packagename.conf or similar. A comment
informing that "dpkg-reconfigure packagename" is the easy way to edit
the file might be nice.

* The package installs a cronjob that does loads the configuration file,
and depening on whether auto-downloads are allowed, does the actual
downloading/verification/installing of the files or simply does nothing.


Since this rests on the system administrator being informed about what
the system will do, and giving an explicit OK, I would not consider it a
privacy violation.


I don't know how complicated this is to implement, but do you think it
could be a good design rationale?

- Danny

Re: Automated download/update of data files

[Alastair McKinstry]

On 25/08/2015 08:44, Ole Streicher wrote:
> Hi all,
>
> What is the best way to keep these data up to date in Debian? An
> automated process as written in the pull request [1] is probably not the
> right way, since it is a potential privacy violation. One could let the
> user manually start the download. However, then he has to keep track of
> all these little updates himself (or be educated enough to write
> cronjobs, or re-enable the automatic download, which is more that one
> could expect from an average scientist). Should one use debconf to ask
> the user if he wants automatic updates here?
Hi Ole,

On the privacy front, I think we probably need to come up with a
mechanism with Debian for recording / signaling these issues to the
user, so a user can make a decision. As a project, we can look at what
we do for users privacy.

One principle to follow on cases like this is "keep requests local".
Rather than have it broadcast over the whole of the 'net (and any
monitored traffic points), request data from as local as possible and
make it cachable.
If the data comes via a local squid cache, etc. or local CDN then the
visibility is much reduced.

best regards
Alastair


> Best regards
>
> Ole
>
> [1] https://github.com/astroplanners/astroplan/pull/67
>

-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered. 

Re: Automated download/update of data files

[Ole Streicher]

m...@linux.it (Marco d'Itri) writes:
> On Aug 25, Ole Streicher  wrote:
>> What is the best way to keep these data up to date in Debian? An
>> automated process as written in the pull request [1] is probably not the
>> right way, since it is a potential privacy violation. One could let the
> I am frankly tired of people screaming "privacy violation" at every 
> automated process which interacts with the rest of the world.

I accept their concerns, even if I don't think that the download of the
UTC deviation could cause any privacy concern.

There are people who want to have full control how their systems
communicate, and they have a valid reason for that.  And Debian Policy
is to take them serious. So I will.

I just seek for a good way to make these people happy and have a good
user experience as well.

Being tired is not the way to go; solving issues is it. Being
constructive on your side would help much.

Best regards

Ole

Re: Automated download/update of data files

[Ole Streicher]

Danny Edel  writes:
> From a system administrator's point of view, the following would be all
> right to me:
>
> * When you install the package, debconf asks if you want the automated
> upgrades, preferably telling me how often its going to download them and
> information about the source. (And I know I can always change my mind
> later with dpkg --reconfigure packagename, although this could be
> explicitly stated in the dialog).

This is probably the way to go. However, the original package does not
update the data on a regular base. It checks whether the data are
current when they are accessed and downloads a new version if the local
version is too old.

Best regards

Ole

Re: git interface to snapshot.debian.org

[Ian Jackson]

Joachim Breitner writes ("git interface to snapshot.debian.org"):
> this is a follow-up to my question after the dgit talk today: It would
> be great to have a git view of the a package’s history in Debian. There
> is some possible overlap with dgit in the sense that if everyone had
> been using dgit from the start, then we would have that, but dgit’s
> objectives are slightly different, so maybe my question could be posed
> and answered separately.

Hi.  I'm sorry that we didn't manage to talk about this idea of yours
properly at DC.  I think it is a good idea.

> If the answer is „Nothing is stopping, just that someone has to do it“,
> then I’m volunteering, as long as I can do most of it during DebConf.

There are two problems that are stopping us doing this right away:

  - Maybe the amount of data is too big to suddenly dump in the dgit
git server (we should talk to DSA)

  - There is nothing which currently automatically updates the
server-side dgit history when non-dgit uploads are made.  Such a
thing could be produced, but I think it is essential to have it
before we embark on a historical import.

There are some things that you would need my help (as admin of
dgit.d.o) with:

  - your histories would have to be stitched into the dgit git history
for packages with existing dgit history

  - your ref updates can't be done by DDs in general, because the dgit
git server only accepts updates made with dgit push.  So you would
need me with my admin hat on to do the updates.


Your details seem largely sound:

>  * Every source package from snapshots.d.o becomes, extracted with 
>dpkg-source -x as usual, produces a git tree object.
>I’d probably simply ignore empty directories.

Right.

>- Parents: This is the interesting bit
>  The set of parents should be the commits corresponding to any 
>  version mentioned in debian/changelog, pruned by those that
>  are transitively reachable.

Nice idea.

>  * Every suite (unstable, jessie...) becomes a branch, pointing to the
>corresponding commit

s/unstable/sid/, but yes.

>  * Optionally: One tag per version pointing to the corresponding
>commit, for each version. Although maybe that would produce too
>many tags...

We definitely want this.  The tag should be in DEP-14 format, which
makes it identical to existing dgit git tags.

Thanks,
Ian.

Re: Replacing ldconfig maintscripts with declarative methods

[Ian Jackson]

Niels Thykier writes ("Replacing ldconfig maintscripts with declarative 
methods"):
> A possible solution is to replace these scripts with an
> "activate-no-await" trigger (again, no-await to avoid trigger cycles).
> I would need libc-bin to promote its trigger to part of its API for this
> to work.

I think this is a good idea.

>  * The major concern I have, is that "activate"-triggers are done for
>- unpack (is this ok?)

It had better be !  (Ie I think it is OK.)


>  * Performance-wise we would see up to 5 calls to ldconfig instead of
>1-2 per "dpkg run" (that processes triggers).

OTOH the reduced number of maintscript invocations might well outweigh
that.

Thanks,
Ian.

Re: [DDEB] Status on automatic debug packages (2015-08-24)

[Jean-Michel Vourgère]

Hi

Nikolaus Rath wrote:
> On Aug 24 2015, Sebastian Ramacher  wrote:
>> What's the plan for python(3)-*-dbg packages that include both Python 
>> extensions
>> built for the python-dbg interpreter and debug symbols? Should they also 
>> change
>> their Section to something else?
> 
> 
> .. and will they also be build automatically? Or rather, when relying on
> the automatic building, will they include the extension for the debug
> interpreter or just the debugging symbols for all extensions (built for
> debugging and regular interpreter)?

The question is also valid for python2:

When using dh --with python2 *and* build-depending on python-all-dbg,
I'm getting [1]:
* Some files like /usr/lib/debug/.build-id/*.debug
* Some files like
/usr/lib/python2.7/dist-packages/rrdtool.x86_64-linux-gnu_d.so

Am I correct in assuming that this need to be split?
* Each arch:any binary package will get its own -dbgsym package, like
python-rrdtool-dbgsym_1.5.4-6_amd64.deb,
lua-rrd-dbgsym_1.5.4-6_amd64.deb, ...
* The python debug $(arch)_d.so generated by dh_auto_build will need its
own package. (See questions of Nikolaus and Sebastian).

The main question is whether or not these -dbgsym package is only of
debug symbols.


Assuming this is split, should one make a recommends: towards these
non-main packages?


Finally, if the current -dbg packages are moved out of main, either the
buildd's will need to have them in their source list, or the section of
the python tools to generate the debug _d.so thingies need to be changed.

[1] https://packages.debian.org/sid/amd64/rrdtool-dbg/filelist
-- 
Nirgal

Re: git interface to snapshot.debian.org

[Peter Palfrader]

[ Added d-a@ldo for the dsa parts. ]

On Tue, 25 Aug 2015, Ian Jackson wrote:

> > If the answer is „Nothing is stopping, just that someone has to do it“,
> > then I’m volunteering, as long as I can do most of it during DebConf.
> 
> There are two problems that are stopping us doing this right away:
> 
>   - Maybe the amount of data is too big to suddenly dump in the dgit
> git server (we should talk to DSA)

Do you have an estimate on the resources required?  I'm sure we can
figure something out.

Cheers,
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Re: Security concerns with minified javascript code

[Jakub Wilk]

* Thomas Goirand , 2015-08-24, 16:08:
I believe the blog post below has relevance to Debian's stance on 
including minified JavaScript in packages:


https://zyan.scripts.mit.edu/blog/backdooring-js/

To me the problem suggests that it is important from a security and 
accountability perspective to 1) include the human-readable source 
code of JavaScript in Debian packages, and 2) to compile the 
human-readable source code into a minified code (if required) during 
package builds, using a JS-minifier that is included in Debian.

Thoughts?


This is anyway mandatory in Debian,


Do we actually require re-minifying JS code at build time?

--
Jakub Wilk

Re: Security concerns with minified javascript code

[Henrique de Moraes Holschuh]

On Tue, Aug 25, 2015, at 11:04, Jakub Wilk wrote:
> Do we actually require re-minifying JS code at build time?

You can either ship the unminifyied JS, or minify it at build time.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh 

Re: Security concerns with minified javascript code

[Jonas Smedegaard]

Quoting Jakub Wilk (2015-08-25 16:04:52)
> * Thomas Goirand , 2015-08-24, 16:08:
>>>I believe the blog post below has relevance to Debian's stance on 
>>>including minified JavaScript in packages:
>>>
>>>https://zyan.scripts.mit.edu/blog/backdooring-js/
>>>
>>>To me the problem suggests that it is important from a security and 
>>>accountability perspective to 1) include the human-readable source 
>>>code of JavaScript in Debian packages, and 2) to compile the 
>>>human-readable source code into a minified code (if required) during 
>>>package builds, using a JS-minifier that is included in Debian.
>>>Thoughts?
>>
>>This is anyway mandatory in Debian,
>
> Do we actually require re-minifying JS code at build time?

I believe we require proof of redistributed code being same as source.

Other than minifying during build, I can only imagine proving by a) 
checksum matching known-good source or b) checksum of throw-away 
normalization (e.g. minification).

I am unaware of any package doing any of a) or b) - but I would not be 
surprised if some maintainers conciously judge the javascript dance as 
silly and don't check at all.

Thanks, Simon, for pointing to a concrete example of why this isn't 
silly¹.


 - Jonas

¹ One can still argue that javascript is silly in general, but then 
don't redistribute at all!

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

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


signature.asc
Description: signature

Re: [DDEB] Status on automatic debug packages (2015-08-24)

[Paul Tagliamonte]

On Mon, Aug 24, 2015 at 02:28:05PM -0700, Steve Langasek wrote:
> I wonder how this list was arrived at.  Offhand, I see the libc6-dbg and
> python3.5-dbg packages are both in section 'debug', both of which are part
> of the build-dependency closure of main; I'm pretty sure we don't want them
> shunted to a separate archive.

Really good point; no one thought of this while we were sprinting on it.
Right, so, two things are now in.

nthykier has checked in a changeset to add a binary control header to
signal it's an autocreated debug package, and dak now uses that to check
to see if it should be diverted.

This means we *wont* see a great pickup in space by moving those super
ultra huge debs (like webkit's debug package) into the other mirror, but
I'm sure we can work something out with the maintainers.

Anyway, thanks for that. Patches made against dak and just getting some
testing locally now.

   Paul

-- 
 .''`.   Paul Tagliamonte |   Proud Debian Developer
: :'  :  https://people.debian.org/~paultag   |   https://pault.ag/
`. `'`   Debian - the Universal Operating System
 `-4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87


signature.asc
Description: Digital signature

Re: Automated download/update of data files

[Daniele Tricoli]

On Tuesday 25 August 2015 13:08:12 Ole Streicher wrote:
> This is probably the way to go. However, the original package does not
> update the data on a regular base. It checks whether the data are
> current when they are accessed and downloads a new version if the local
> version is too old.

What about using the same approach of upstream in the cronjob? If observations 
are <7 days old do nothing otherwise update.

Cheers,

-- 
 Daniele Tricoli 'eriol'
 https://mornie.org

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

Re: Security concerns with minified javascript code

[Vincent Bernat]

 ❦ 25 août 2015 16:04 +0200, Jakub Wilk  :

>>> I believe the blog post below has relevance to Debian's stance on
>>> including minified JavaScript in packages:
>>>
>>>https://zyan.scripts.mit.edu/blog/backdooring-js/
>>>
>>> To me the problem suggests that it is important from a security and
>>> accountability perspective to 1) include the human-readable source
>>> code of JavaScript in Debian packages, and 2) to compile the
>>> human-readable source code into a minified code (if required)
>>> during package builds, using a JS-minifier that is included in
>>> Debian.
>>>Thoughts?
>>
>>This is anyway mandatory in Debian,
>
> Do we actually require re-minifying JS code at build time?

No, we don't require to rebuild everything from source. It should just
be possible to do it with what is in main. The last occurrence that I
can find of this discussion is here:
 https://lists.debian.org/debian-devel/2014/11/msg00929.html
-- 
Test input for validity and plausibility.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

system upgrade by systemd

[Michael Meskes]

Can anyone tell me which package/configuration is reponsible for systemd
running a package upgrade during bootup? I certainly never willingly
configured this feature, but still have it. And for the second time it
destroyed my system by deinstalling a lot of packages, instead of putting the
conflicting packages on hold. 

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: Security concerns with minified javascript code

[Scott Kitterman]

On Tuesday, August 25, 2015 05:12:56 PM Vincent Bernat wrote:
>  ❦ 25 août 2015 16:04 +0200, Jakub Wilk  :
> >>> I believe the blog post below has relevance to Debian's stance on
> >>>
> >>> including minified JavaScript in packages:
> >>>https://zyan.scripts.mit.edu/blog/backdooring-js/
> >>>
> >>> To me the problem suggests that it is important from a security and
> >>> accountability perspective to 1) include the human-readable source
> >>> code of JavaScript in Debian packages, and 2) to compile the
> >>> human-readable source code into a minified code (if required)
> >>> during package builds, using a JS-minifier that is included in
> >>> Debian.
> >>>
> >>>Thoughts?
> >>
> >>This is anyway mandatory in Debian,
> >>
> > Do we actually require re-minifying JS code at build time?
> 
> No, we don't require to rebuild everything from source. It should just
> be possible to do it with what is in main. The last occurrence that I
> can find of this discussion is here:
>  https://lists.debian.org/debian-devel/2014/11/msg00929.html

The question posed there was, I think, already pretty clearly answered:

https://lists.debian.org/debian-devel-announce/2014/04/msg00014.html

AFAIK we've only ever discussed the need to provide source.  I don't know why 
there would be a requirement to reminify.

Scott K

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

Re: system upgrade by systemd

[Vincent Bernat]

 ❦ 25 août 2015 17:18 +0200, Michael Meskes  :

> Can anyone tell me which package/configuration is reponsible for systemd
> running a package upgrade during bootup? I certainly never willingly
> configured this feature, but still have it. And for the second time it
> destroyed my system by deinstalling a lot of packages, instead of putting the
> conflicting packages on hold. 

This is systemd-system-update-generator which adds a symlink to enable
the system-update target as a default target. Have a look at
systemd.generator(8) to know how to disable it (symlink to /dev/null in
/etc/systemd/system-generators/systemd-system-update-generator if I
understand correctly).
-- 
This was the most unkindest cut of all.
-- William Shakespeare, "Julius Caesar"


signature.asc
Description: PGP signature

Re: system upgrade by systemd

[Simon McVittie]

On 25/08/15 16:18, Michael Meskes wrote:
> Can anyone tell me which package/configuration is reponsible for systemd
> running a package upgrade during bootup?

I think packagekit does the actual upgrade during boot, if one has been
staged by some other component. gnome-software is the only PK frontend I
know about that stages upgrades in this way, but there might be others
that do the same (e.g. something in KDE).

S

Re: system upgrade by systemd

[Vincent Bernat]

 ❦ 25 août 2015 18:03 +0200, Vincent Bernat  :

>> Can anyone tell me which package/configuration is reponsible for systemd
>> running a package upgrade during bootup? I certainly never willingly
>> configured this feature, but still have it. And for the second time it
>> destroyed my system by deinstalling a lot of packages, instead of putting the
>> conflicting packages on hold. 
>
> This is systemd-system-update-generator which adds a symlink to enable
> the system-update target as a default target. Have a look at
> systemd.generator(8) to know how to disable it (symlink to /dev/null in
> /etc/systemd/system-generators/systemd-system-update-generator if I
> understand correctly).

Also, the actual update is not done by systemd. I believe that you need
to have packagekit installed (and I suppose that the /system-update file
needed to trigger the whole thing is also set by packagekit). Check with:
 systemctl list-dependencies system-update.target

On my machine, I don't have anything other than sysinit.target.
-- 
Man is the only animal that blushes -- or needs to.
-- Mark Twain


signature.asc
Description: PGP signature

Re: system upgrade by systemd

[Russ Allbery]

Michael Meskes  writes:

> Can anyone tell me which package/configuration is reponsible for systemd
> running a package upgrade during bootup? I certainly never willingly
> configured this feature, but still have it. And for the second time it
> destroyed my system by deinstalling a lot of packages, instead of
> putting the conflicting packages on hold.

unattended-upgrades would be my guess.  It's the only package in Debian
that I know of that does things like that.  (It's independent of init
systems; it would do the same if you were running upstart or sysvinit.)

-- 
Russ Allbery (r...@debian.org)   

Re: Security concerns with minified javascript code

[Jonas Smedegaard]

Quoting Scott Kitterman (2015-08-25 17:57:11)
> On Tuesday, August 25, 2015 05:12:56 PM Vincent Bernat wrote:
>> ❦ 25 août 2015 16:04 +0200, Jakub Wilk  :
> I believe the blog post below has relevance to Debian's stance on
>
> including minified JavaScript in packages: 
>https://zyan.scripts.mit.edu/blog/backdooring-js/
>
> To me the problem suggests that it is important from a security 
> and accountability perspective to 1) include the human-readable 
> source code of JavaScript in Debian packages, and 2) to compile 
> the human-readable source code into a minified code (if required) 
> during package builds, using a JS-minifier that is included in 
> Debian.
>
>Thoughts?

This is anyway mandatory in Debian,

>>> Do we actually require re-minifying JS code at build time?
>>
>> No, we don't require to rebuild everything from source. It should 
>> just be possible to do it with what is in main. The last occurrence 
>> that I can find of this discussion is here:
>>  https://lists.debian.org/debian-devel/2014/11/msg00929.html
>
> The question posed there was, I think, already pretty clearly 
> answered:
>
> https://lists.debian.org/debian-devel-announce/2014/04/msg00014.html
>
> AFAIK we've only ever discussed the need to provide source.  I don't 
> know why there would be a requirement to reminify.

I agree the question of shipping minified code in _source_ packages is 
discussed and permitted when its source is included as well.

I see no reason to require javascript code shipped in binary packages to 
be minified.

I do see a reason to require that *if* such code is minified then the 
minification must be done during build, not upstream.

...just to make sure we are discussing same thing here.


 - Jonas

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

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


signature.asc
Description: signature

Re: Security concerns with minified javascript code

[Gunnar Wolf]

Jakub Wilk dijo [Tue, Aug 25, 2015 at 04:04:52PM +0200]:
> >>To me the problem suggests that it is important from a security and
> >>accountability perspective to 1) include the human-readable source code
> >>of JavaScript in Debian packages, and 2) to compile the human-readable
> >>source code into a minified code (if required) during package builds,
> >>using a JS-minifier that is included in Debian.
> >>Thoughts?
> >
> >This is anyway mandatory in Debian,
> 
> Do we actually require re-minifying JS code at build time?

If your upstream does not ship the pre-minified JS code, you must
include it in the packaging (i.e. via debian/missing-sources/ )

You can choose whether to re-minify or not; I do re-minify for the
same reason upstream does (usually, reduced bandwidth or a lower
amount of requests due to combining several source files
together). You should only ship upstream's non-minified code if you
can reliably produce identical code to it.

Re: Security concerns with minified javascript code

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Aug 25, 2015 at 07:17:12PM +0200, Jonas Smedegaard wrote:
> Quoting Scott Kitterman (2015-08-25 17:57:11)
> > AFAIK we've only ever discussed the need to provide source.  I don't 
> > know why there would be a requirement to reminify.
> 
> I see no reason to require javascript code shipped in binary packages to 
> be minified.

My guess would be for performance.  I don't know how much it actually does
(it'll be mostly bandwidth, I suppose).

> I do see a reason to require that *if* such code is minified then the 
> minification must be done during build, not upstream.

AFAIK Debian doesn't *require* generated files to be rebuilt.  For example, it
used to be common practice for a long time to copy config.{guess,sub} from
autotools-dev instead of regenerating them with autoreconf (I think there is
consensus now that regenerating is better, but it still isn't a policy
requirement).

I think everyone agrees that binaries should be compiled during package build.
Just shipping a precompiled binary and its source is not how things should be
done.

I don't see why javascript minification would be different from C compilation
in a way that would lead to a different way of handling it.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJV3Ky6AAoJEJzRfVgHwHE6xdAQAIZUkdzmmIr8u2ug5jjqYD96
OO2vDku0uAt6chvH/qu/eh7w+b4Udy0/d3MOE6vWEo95ThJLQefVnxrMU1u1fUah
2CYoDZerixODAb9MgKSwzSlQ0dOG9H8iELTnbOlyfVYD4gpW204BSN0sFrQkuKTp
2sOX/3kR2QVMHM/Ywsrzd54qrhSSovC9vbVlbFJ5XOK7d0DoepE7vhZMdbmLjq2D
fezKm6caAUwi+bjiyYRFvP7eQKvrVygckVy8LY7AT0Vr1OwmKsiynYBGh39GzozS
A1Pb9TH/3szsNYITF36tCmJF9A6npjHApF/ysePBsgMxESXzGAfG9SrRLUzT+9tO
AXfSa76KWQpvEGAz1jWkuB11cevrSyH3gA4tpJ1aOKngFniV3trGeETN8ZH/y7KL
CMceSZMzFPYSXsR5rrONXasIhj7qB87yHKim1AGsHXBzbf/oA/sdePze3BB2nT2F
4QV8GetTslvHsIT6pTuJsfg8wpDp8pvopeSJrm90cb4KN+odmxoQgUjXpbhGHvCx
BPu2xKv5y8k8OonObvxQM/9IUlHLpdYWPJIGEnetxyBpwAm0KnO5yPLkA56neqeo
pOndBqDysQCwPshh6RtmgvkWUKmd4KdcdK3kkvCvxlj+p3D6vXAmaplnRRr6dzag
iF/wxplyM+n+chCTCZzY
=qMBg
-END PGP SIGNATURE-

Re: Security concerns with minified javascript code

[Gunnar Wolf]

Scott Kitterman dijo [Tue, Aug 25, 2015 at 11:57:11AM -0400]:
> > No, we don't require to rebuild everything from source. It should just
> > be possible to do it with what is in main. The last occurrence that I
> > can find of this discussion is here:
> >  https://lists.debian.org/debian-devel/2014/11/msg00929.html
> 
> The question posed there was, I think, already pretty clearly answered:
> 
> https://lists.debian.org/debian-devel-announce/2014/04/msg00014.html
> 
> AFAIK we've only ever discussed the need to provide source.  I don't know why 
> there would be a requirement to reminify.

The main reason IMO is that, unless we can ensure the minified code is
identical to what we are able to produce, we cannot be sure of its
contents. If upstream changes the version of the JS
library-to-be-minified then our provided source will no longer
match. Even worse, if upstream (or an attacker to upstream) were to
modify specific bits of the minified thingy (quite probably, the
pre-minified thingy they'd minify and ship), they will put our users
in compromised situations.

So, we can ensure a bit-identical minification (that is, checking the
hash for each minified JS or whatever other language we ship), or just
minify from a known-good source and distribute our results.

Minification is a very fast process IMO, so I don't see why not to do
it.

Re: system upgrade by systemd

[Steve McIntyre]

Michael Meskes wrote:
>Can anyone tell me which package/configuration is reponsible for systemd
>running a package upgrade during bootup? I certainly never willingly
>configured this feature, but still have it. And for the second time it
>destroyed my system by deinstalling a lot of packages, instead of putting the
>conflicting packages on hold. 

Looks like it's probably worth uninstalling all of the packagekit
stuff if you don't want this horrendous anti-feature.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html

Re: Security concerns with minified javascript code

[Ian Jackson]

Bas Wijnen writes ("Re: Security concerns with minified javascript code"):
> AFAIK Debian doesn't *require* generated files to be rebuilt.  For
> example, it used to be common practice for a long time to copy
> config.{guess,sub} from autotools-dev instead of regenerating them
> with autoreconf (I think there is consensus now that regenerating is
> better, but it still isn't a policy requirement).

config.{guess,sub} aren't modified by autotools, are they ?  Just
copied.  I think you probably want to be thinking about configure.

Not regenerating configure doesn't pose any significant risk that
we're shipping a configure script that we can't regenerate (or, at
least, regenerate an equivalent or better one).  I've not heard of
people (for example) using private autoconf macros not included in
their build tree.

So I think that while you are right in the general case that
we should regenerate everything from source, I think that autotools
output might reasonably get an exception.  There might be other
possible exceptions.

The key point is that we want to be confident that we can modify what
are supposedly the input files, regenerate the output files, and get a
working package.

> I don't see why javascript minification would be different from C
> compilation in a way that would lead to a different way of handling
> it.

In practice, given the widely adopted poor practice surrounding
webapps in general and minified javascript in particular, I think that
the only way we can be confident enough that we have useable source
code is to actually use what we think is the source code.

Ian.

Re: Bug#796529: ITP: local-apt-repository -- Ready to use local apt repository

[Marvin Renich]

* Joachim Breitner  [150823 07:24]:
> With pow-priority, you mean one that does not get shown by default? But
> is that much better than allowing the interested admin to change the
> configuration afterwards?

Actually, I was thinking it should be similar to postfix, which looks
like it is using medium priority for most questions (sorry, that was my
mistake).

> Note that my package does _not_ touch or put files in /srv. It merely
> uses files that are put in a certain directory that, that the admin has
> to create first. Does that mitigate your concerns?

Somewhat.  Still, it mandates that a specific directory in /srv be used.

Current practice in Debian, based on a very small sample, is to use a
subdirectory of /var, such as /var/www or /var/lib/pkgname.  You would
certainly be following precedent if you did something like this.

However, after reading bug #775318 (CC'ed, as the rest of this message
pertains to this specific package as well as the debian-policy bug), I
am forming some new opinions.

First, it now appears to me that the FHS authors:

1.  intended for /srv to be used for things like this.

2.  intended for the structure of /srv to be primarily under control of
the local admin.

3.  recognized that this directory was relatively new and best practices
had not been established.  They intentionally left the details
unspecified to allow distributions to arrive at a consensus.

In order for both distributions and local admins to safely share /srv,
there must be some rules about how the namespace is divided.  For /usr
and /var, distributions were alloted all except one subdirectory of
each:  /usr/local and /var/local.  This gives distributions primary
control over these two top-level directories.

To give local admins primary control of /srv, we should do the converse,
and reserve one top-level subdirectory for distributions (perhaps
/srv/pkg; other suggestions welcome), and leave the remainder of the
/srv namespace available for the local admin.  So you might use
/srv/pkg/local-apt-repository.

There currently does not appear to be any precedent in Debian for a
package to use /srv as a default, so it would be nice for the first
package to do so to "get it right".  Once packages start usurping
top-level subdirectories of /srv, it will be difficult to ebb the tide.

I do think that for packages where it makes sense to use a subdirectory
of /srv, it also makes sense to ask the admin what directory to use,
giving a sensible suggestion as a default.

...Marvin

Re: Security concerns with minified javascript code

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Aug 25, 2015 at 07:08:06PM +0100, Ian Jackson wrote:
> Bas Wijnen writes ("Re: Security concerns with minified javascript code"):
> > AFAIK Debian doesn't *require* generated files to be rebuilt.  For
> > example, it used to be common practice for a long time to copy
> > config.{guess,sub} from autotools-dev instead of regenerating them
> > with autoreconf (I think there is consensus now that regenerating is
> > better, but it still isn't a policy requirement).
> 
> config.{guess,sub} aren't modified by autotools, are they ?  Just
> copied.  I think you probably want to be thinking about configure.

They are just copied, but there are some more things happening when running
autoreconf (or running auto* manually) and IME autoreconf may not always work.
If it doesn't, the user cannot modify Makefile.am and have those changes work
their way into the compiled program.

(What it really means is that while Makefile.am is the source for Makefile, the
compilation process to turn one into the other is sometimes nontrivial; running
autoreconf during package build documents that process in debian/rules, or else
the package build will fail.)

> So I think that while you are right in the general case that
> we should regenerate everything from source, I think that autotools
> output might reasonably get an exception.  There might be other
> possible exceptions.

Yes, I agree that there are exceptions.  My point is not that it is a hard rule
(it isn't, and I think that is a good thing).  It may be broken, but you need a
reason.  I see no reason to break it for javascript code.

> The key point is that we want to be confident that we can modify what
> are supposedly the input files, regenerate the output files, and get a
> working package.

Exactly.  And the easiest way to be confident about it is to rebuild things, so
that is what you do unless you have a reason not to.

> In practice, given the widely adopted poor practice surrounding
> webapps in general and minified javascript in particular, I think that
> the only way we can be confident enough that we have useable source
> code is to actually use what we think is the source code.

Agreed.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJV3LNXAAoJEJzRfVgHwHE6FhoP/A0FckLDm+1NwhNhN/0AMypa
OKATAwHEqND5BLyvAAI5Kqi3qJ5c1GrLbNUD5/Ccsd40yMdOtAOLbpwur7MeGvzh
JoHGBXm0Q6Q0jHm5c67YySlS5/Gp4P58GUqLt8DF2NN1olx0AMWtZUzP052/Tn2i
9JVMhhZTgPproA0EhjawsqGsVHvleqNw4xNzh/fCfTbUKnT5Zt52DsabDJjEEvFK
bTNGOPd6Qd3PAf1yhvb17vqGeWMNpZP8opOxv89eUuQiCi1LfHciSV5fyFBXD/XG
VavTyjzXInMi/CuhamFDdrxLeyIW1qfqJCgt4G43uc+Dm8t8ICTkvdZTuekbjf96
hNYcZ6jaZ59GkQJI26p61Ffe6MCsnw5C9lOSUbXLEule6zeuRJazVKvjRocZWJtm
quRiXdI+DwHKsLSebjqGffmAWVaIrugubPNDBFvR8T9vXyL4WhsDsMm0gyz1iQ03
UE8nKfzOwFTmCM2OCY/kQXoGiIcd3jLUPuJQE3zO8h3YgKgLWdXuqJDxGsrDiOFR
idB561jLPpN0VBsUdVQaLmT5mj89AZPCedZQTgIQiELlxOMA/WnfYAs/5HeZ9Tap
IQ3JKnn0ZVys0WX9PZ/kHrU+aC4/mLyknFE9nBr7XnvOD/nYiQsvTMYG2CP69upt
LCQhv2chCCrU8yb5FVLp
=m7m8
-END PGP SIGNATURE-

Re: git interface to snapshot.debian.org

[Joachim Breitner]

Hi,

Am Dienstag, den 25.08.2015, 13:59 +0100 schrieb Ian Jackson:
> > If the answer is „Nothing is stopping, just that someone has to do it“,
> > then I’m volunteering, as long as I can do most of it during DebConf.
> 
> There are two problems that are stopping us doing this right away:
> 
>   - Maybe the amount of data is too big to suddenly dump in the dgit
> git server (we should talk to DSA)


as mentioned I created a proof-of-concept bash script, and for example
the (git gc’ed) repository of all history of ghc is 137MB. screen
-message, as an example for a small package, amounts to 572KB. Not sure
how to best extrapolate that, though.


> > >- Parents: This is the interesting bit
> > >  The set of parents should be the commits corresponding to any
> > >  version mentioned in debian/changelog, pruned by those that
> > >  are transitively reachable.
> > 
> > Nice idea.

At least for GHC, which had independently running branches in unstable
and experimental for a while, with occasional merges from unstable to
experimental, this worked fine.

I guess dgit by itself does not do anything like that, but rather
expects the right ancestry to come out of the „normal“ git use of the
maintianer.



Anyways, I postponed this project for now; too much other things going
on. I might get back to it in the future. In that case, I would
probably first try to get nice git repositories from all of
snapshot.d.o, independent of dgit. Once we have that, one can see if
and how that is best integrated with dgit.

(If you or someone else beats me to it: Even better :-))


Greetings,
Joachim


-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: system upgrade by systemd

[Matthias Klumpp]

This is a feature of systemd and PackageKit.
See http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/

The only thing which makes use of this feature is GNOME through
GNOME-Software, so if you don't want this, removing GNOME-Software will be
enough.
Nothing else in Debian uses this[1].

Cheers,
Matthias

P.S: A log file on why the update failed would be very helpful though,
because even if you don't use it, the functionality should be usable for
those who want to use it.


[1]: I know that thanks to codesearch

Re: Security concerns with minified javascript code

[Jakub Wilk]

* Ian Jackson , 2015-08-25, 19:08:
Not regenerating configure doesn't pose any significant risk that we're 
shipping a configure script that we can't regenerate (or, at least, 
regenerate an equivalent or better one).


Autotools stuff tends to bitrot, just like everything else. There's a 
reason we have 4(+1) versions of autoconf and two versions of automake 
in jessie.


I've not heard of people (for example) using private autoconf macros 
not included in their build tree.


#580190

--
Jakub Wilk

Bug#796916: ITP: osslsigncode -- Authenticode signing tool

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 

* Package name: osslsigncode
  Version : 1.7.1
  Upstream Author : Per Allansson 
* URL : https://sourceforge.net/projects/osslsigncode
* License : GPL-3+
  Programming Lang: C
  Description : Authenticode signing tool

 osslsigncode is an Authenticode signing tool for PE binaries
 (Windows executables, DLLs, drivers...), CAB archives and MSI
 installation packages. It also supports timestamping using
 Authenticode and RFC-3161.

Bug#796920: Subject: ITP: ripper -- scrape licenses out of files

[Fernando Ike]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Owner: Fernando Ike 

* Package name: ripper
  Version : 0.0~git20150415.0.bd1a682-1
  Upstream Author : Emmanuel Odeke 
* URL : https://github.com/odeke-em/ripper
* License : Apache-2.0
  Programming Lang: Go
  Description : scrape licenses out of files
 Ripper inspect source files and show the license if it found. It
 support directories, files or URI repositories as argument.
 .
 This package provides command-line to use alone or embbed in others
 programs.

-- 
Fernando Ike
http://www.fernandoike.com

Re: Security concerns with minified javascript code

[Ian Jackson]

Jakub Wilk writes ("Re: Security concerns with minified javascript code"):
> Ian Jackson , 2015-08-25, 19:08:
> >I've not heard of people (for example) using private autoconf macros 
> >not included in their build tree.
> 
> #580190

*reads* *blink*

Err, right.  I stand corrected.

(I'm not really convinced that the fix adopted there is adequate.  If
it were my package I would have lifted a copy of the macro into the
source package.)

Ian.

Re: git interface to snapshot.debian.org

[Ian Jackson]

Joachim Breitner writes ("Re: git interface to snapshot.debian.org"):
> Am Dienstag, den 25.08.2015, 13:59 +0100 schrieb Ian Jackson:
> > > If the answer is „Nothing is stopping, just that someone has to do it“,
> > > then I’m volunteering, as long as I can do most of it during DebConf.
> > 
> > There are two problems that are stopping us doing this right away:
> > 
> >   - Maybe the amount of data is too big to suddenly dump in the dgit
> > git server (we should talk to DSA)
> 
> as mentioned I created a proof-of-concept bash script, and for example
> the (git gc’ed) repository of all history of ghc is 137MB. screen
> -message, as an example for a small package, amounts to 572KB. Not sure
> how to best extrapolate that, though.

Right.  I can't see how to do it without actually trying it on the
whole archive.

I guess we could run a program that did this for each package, noted
the size, and then threw the resulting git branch away.  That would
use up some computer time and elapsed time but wouldn't require an
enormous scratch area.

> > > >- Parents: This is the interesting bit
> > > >  The set of parents should be the commits corresponding to any
> > > >  version mentioned in debian/changelog, pruned by those that
> > > >  are transitively reachable.
> > > 
> > > Nice idea.
> 
> At least for GHC, which had independently running branches in unstable
> and experimental for a while, with occasional merges from unstable to
> experimental, this worked fine.
> 
> I guess dgit by itself does not do anything like that, but rather
> expects the right ancestry to come out of the „normal“ git use of the
> maintianer.

Indeed.  (Although if a .dsc migrates between suites, the git history
is updated.)

> Anyways, I postponed this project for now; too much other things going
> on. I might get back to it in the future. In that case, I would
> probably first try to get nice git repositories from all of
> snapshot.d.o, independent of dgit. Once we have that, one can see if
> and how that is best integrated with dgit.

OK.

> (If you or someone else beats me to it: Even better :-))

Heh.

Thanks,
Ian.

Re: system upgrade by systemd

[Steve McIntyre]

On Tue, Aug 25, 2015 at 08:35:30PM +0200, Matthias Klumpp wrote:
>This is a feature of systemd and PackageKit.
>See http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/

I used the term "anti-feature" deliberately. I am well aware of what
the systemd devs are trying to achieve here, and I strongly believe
that it is a significant backwards step for Debian. We should not be
doing this and making things worse for our users without (at the very
least!) discussing it properly first.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"

Re: git interface to snapshot.debian.org

[Joachim Breitner]

Hi,

Am Dienstag, den 25.08.2015, 21:47 +0100 schrieb Ian Jackson:
> (Although if a .dsc migrates between suites, the git history
> is updated.)

I don’t understand that. Is there really git history changed? Or just
branches updated?



Greetings,
Joachim
-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Recommending packages not available in arch

[Debian/GNU]

hi all,

recently on IRC, i asked why "to exclude specific archs in
Recommends/Suggests?".

the use case is, that some package "foo" might not be available for a
specific arch (e.g. FTBFS on hurd-any), and package "bar" would still
like to recommend it (since "bar" is used together with "foo" 'in all
but unusual installations' - and hurd-any is considered an 'unusual'
though possible environment, 'unusual' mainly because "bar" is not
available, and also because it's hurd...).

my intuition tells me to use "Recommends: foo", and everyone can use
"bar" and will be happy (though the hurd-people less so, because they
don't get the extra features that 'foo' provides until somebody fixes
that FTBFS).



however, one of the first answers i got was: "recommending a
non-existent package is forbidden".

now §2.2.1 of our policy indeed says that 'packages in main must not
require or recommend a package outside of main for compilation or
execution (thus, the package must not declare a "Pre-Depends",
"Depends", "Recommends" [...] relationship on a non-main package)'.

my first reaction was that the intention of this paragraph is mainly to
keep the system uncontaminated from non-free and contrib, but while the
§2.2.1 refers a lot to DFSG, the quote above is explicitely "in
addition" to the DFSG, so it *might* apply.


so my question is:

Does §2.2.1 indeed apply to Recommends for packages that are in the main
archive but not available for a given architecture?

If so, what is the reasoning?

Also: does the "main archive" contain multiple architectures, or do we
have a main archive per architecture? (if the former, then i think that
§2.2.1 does not apply).


mgfsadr
IOhannes



signature.asc
Description: OpenPGP digital signature

Re: Security concerns with minified javascript code

[Vincent Bernat]

 ❦ 25 août 2015 17:58 GMT, Bas Wijnen  :

> I don't see why javascript minification would be different from C compilation
> in a way that would lead to a different way of handling it.

Playing a bit of devil's advocate here, but...

It has already been said numerous time in the past, for some Javascript
code, we don't really have the tools in Debian to easily go from the
source to the minified version. It's possible, but without the
appropriate tools, it's painful.

It's different from C compilation, because C is mature and Javascript is
still reinventing build tools pulling tons of dependencies to just do
the work of make and cat.

Notably, one of the tool is Grunt and its myriad of plugins. Even if
Grunt was in Debian, we would also need Gulp, then Broccoli, because in
Javascript, there is always someone thinking that it should be possible
to do better. We need to leave the Javascript ecosystem mature a bit
more but in the meantime, a bit of tolerance would be appreciated for
the some of us needing to package some javascript bits.

Of course, this is suboptimal and the attack using minifier bugs
illustrate why we need to be able to rebuild from the source.
-- 
Each module should do one thing well.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Security concerns with minified javascript code

[Steve McIntyre]

Vincent Bernat wrote:
>
>Notably, one of the tool is Grunt and its myriad of plugins. Even if
>Grunt was in Debian, we would also need Gulp, then Broccoli, because in
>Javascript, there is always someone thinking that it should be possible
>to do better. We need to leave the Javascript ecosystem mature a bit
>more but in the meantime, a bit of tolerance would be appreciated for
>the some of us needing to package some javascript bits.

Why should we be tolerating setups where it's not clear that we can
reproduce what's being shipped?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html

Re: system upgrade by systemd

[Simon McVittie]

On 25/08/15 16:18, Michael Meskes wrote:
> And for the second time it
> destroyed my system by deinstalling a lot of packages, instead of putting the
> conflicting packages on hold. 

That's the major issue here: packagekit and/or gnome-software (I'm not
sure which of them is the relevant part here, most likely PK) doesn't
understand apt holds, and the problem resolver that gets used is too
willing to remove packages. It would work fine for stable-updates, and
probably OK for testing most of the time, but unstable gets transient
uninstallability too often (particularly now!) for an approach that
simple to work.

S

Re: Security concerns with minified javascript code

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Aug 25, 2015 at 11:13:15PM +0200, Vincent Bernat wrote:
>  ❦ 25 août 2015 17:58 GMT, Bas Wijnen  :
> 
> > I don't see why javascript minification would be different from C 
> > compilation
> > in a way that would lead to a different way of handling it.
> 
> It has already been said numerous time in the past, for some Javascript
> code, we don't really have the tools in Debian to easily go from the
> source to the minified version. It's possible, but without the
> appropriate tools, it's painful.

In that case, it should be treated like any other thing for which the compiler
is not in Debian: either package the compiler, or put it in contrib.  But for
javascript that isn't even needed:

> We need to leave the Javascript ecosystem mature a bit more but in the
> meantime, a bit of tolerance would be appreciated

The minifier is a compiler.  If it's not in main, files that are compiled with
it cannot be in main.  For javascript, the easy solution is to not use the
compiler.  Non-minified code works fine.

If you really want minified code, then you need to go for the hard solution,
just like in any other language: package the compiler and run it during build.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJV3O40AAoJEJzRfVgHwHE6snwP/RjBujWfFHEVhf9JNCAO5vxP
XmQinXIJiZ8DS6i2zst5Pw+eL2Zj80Sa26+7b1mKshJm064H9cr5YxxeZFx389Hm
dPsds8CzFgsxY5H2rsfA0ipC+oUzYpCYnrQwzPjJoC0As14BWMpMfvbNbNHFEMjc
7gS1POcN6N/zSv9xVHVeJjuXyNTwi6CEjvcHr0cXaJ594iZHE85OEyjywnYF3MiM
Vbtl3GkeCyF9QLE6QTTjhytCqtpu7RzU91kr1F1zF9ZMbzCxz5/jto1hhNvuhbD5
U57mEJ/mxXvbFMSXNouWDHhr1TX2Y3CwUijBz4MNpb14+1uptJPWQ/8SEL2SZQKe
g3Of8P4Jq+L+vOlc8B9N8s9GTHvPY4haOmI8PB6VHp75e5RQtZ77TMFekYAsI+Ev
GQulvjT+0+cw/JbBkuQfRkaBuG8MCx76z8aFvAjQt3EeDeiH4c6QDBvSTLROBpZp
qbLEDz5+Ux01AjBoMj6NFzjwdli/+H9RfAvKtb3r081yEf6v4NzntPlzvU8PWW/b
0+FWDDwvKQw0InkKMLQ8QSeyBK7Xk5Rkp4rxaCtzwCKOyHU+sw4jg8lg0K8p0edu
uJ2OVm5Chpqo7mbkfikS/4e0dZh4AYuhwHYCefJ5ORKAQFNJaRE+00zODrYqW0Oe
oD2QZIGbekgWegNtfv5Y
=wczl
-END PGP SIGNATURE-

Re: system upgrade by systemd

[Matthias Klumpp]

2015-08-25 23:53 GMT+02:00 Simon McVittie :

> On 25/08/15 16:18, Michael Meskes wrote:
> > And for the second time it
> > destroyed my system by deinstalling a lot of packages, instead of
> putting the
> > conflicting packages on hold.
>
> That's the major issue here: packagekit and/or gnome-software (I'm not
> sure which of them is the relevant part here, most likely PK) doesn't
> understand apt holds,


PK does understand apt holds - only Aptitude doesn't set them correctly,
see bug #683099

and the problem resolver that gets used is too
> willing to remove packages. It would work fine for stable-updates, and
> probably OK for testing most of the time, but unstable gets transient
> uninstallability too often (particularly now!) for an approach that
> simple to work


PackageKit uses the very same resolver as apt itself does...
A log file of what actually happened would be very helpful here, to
determine the problem causing the package removal.

-- 
I welcome VSRE emails. See http://vsre.info/

Re: Raising the severity of reproducibility issues to "important"

[Jakub Wilk]

* Colin Tuckley , 2015-08-24, 21:12:
We are in the business of packaging upstream software for distribution. 
We should not make arbitrary changes to upstream software, such as 
changing the way a date is added to a man page, just to make the build 
reproducible.


If the manpage date was the date of last modification, as it should be, 
there wouldn't be anything to fix.


--
Jakub Wilk

Re: system upgrade by systemd

[Michael Meskes]

> Looks like it's probably worth uninstalling all of the packagekit
> stuff if you don't want this horrendous anti-feature.

Turns out I had only packagekit itself installed. Shouldn't its
description mention this "horrendous anti-feature"? I couldn't agree
more on the wording. Actually I consider this behavior a very grave bug.
Yes, I can see some reasons for this "feature" but certainly not for it
to be activated automatically and not exactly well documented.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: system upgrade by systemd

[Michael Meskes]

> The only thing which makes use of this feature is GNOME through
> GNOME-Software, so if you don't want this, removing GNOME-Software will
> be enough.

This is a joke, right?

> P.S: A log file on why the update failed would be very helpful though,
> because even if you don't use it, the functionality should be usable for
> those who want to use it.

Who said the update failed? I want to make the decision as to when and
how to update my system and I never want to see some stupid software
make a bad decisions in particular not while traveling and sitting
behind a line that doesn't give me enough bandwidth for a real update,
or even a small one for that matter.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: system upgrade by systemd

[Michael Meskes]

> I used the term "anti-feature" deliberately. I am well aware of what
> the systemd devs are trying to achieve here, and I strongly believe
> that it is a significant backwards step for Debian. We should not be
> doing this and making things worse for our users without (at the very
> least!) discussing it properly first.

And, may I add, tell the admin clearly and make it configurable.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: system upgrade by systemd

[Michael Meskes]

> PK does understand apt holds - only Aptitude doesn't set them correctly,
> see bug #683099

I wasn't talking about existing holds, but about an update strategy that
prioritized removing packages like gnome-control-center over putting
some other on hold automatically. I would expect an automatic system to
*always* take the path of least removals.

> PackageKit uses the very same resolver as apt itself does...
> A log file of what actually happened would be very helpful here, to
> determine the problem causing the package removal.

Just try an update on a recently updated (Sunday) sid system and you'll
see see the conflicts.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: system upgrade by systemd

[Russ Allbery]

Michael Meskes  writes:

>> PackageKit uses the very same resolver as apt itself does...  A log
>> file of what actually happened would be very helpful here, to determine
>> the problem causing the package removal.

> Just try an update on a recently updated (Sunday) sid system and you'll
> see see the conflicts.

I'm unclear as to what you have installed that triggers this, because I've
been using systemd and sid for eons and have never encountered this
behavior.  (That also makes me pretty sure, pace Steve, that this is not
something *systemd* as systemd is actually doing, but some other
component.)

Is it GNOME Software that you also have installed, per the other message
on this thread?

Looking at systemd-system-update-generator, it looks like this is a purely
optional feature that is only triggered if you use a system upgrade method
that uses the /var/lib/system-update staging area.  So I think blaming
this on systemd is a little odd.  I certainly agree that it's a rather
serious bug for this to suddenly start happening without your knowledge,
particularly when it makes some decidedly bad dist-upgrade choices, but I
think the fault here lies with whatever software staged this upgrade.  Not
with systemd for just doing what it was told by another package.

I like having the *choice* of being able to either use apt and upgrade
directly, or stage an upgrade and have it happen on reboot.  It seems like
systemd is providing that choice and supporting both options, which is
great.  The question, in my mind, is why you're getting surprised with
something using the method that you don't prefer.

-- 
Russ Allbery (r...@debian.org)   

Re: system upgrade by systemd

[Ramakrishnan Muthukrishnan]

On Tue, Aug 25, 2015, at 08:48 PM, Michael Meskes wrote:
> Can anyone tell me which package/configuration is reponsible for systemd
> running a package upgrade during bootup? I certainly never willingly
> configured this feature, but still have it. And for the second time it
> destroyed my system by deinstalling a lot of packages, instead of putting
> the
> conflicting packages on hold. 

It happened to me a couple of weeks ago too and I was left with a
totally unusable system. I lost two days of work during which I
reinstalled a minimal base system and made sure I don't install a trace
of GNOME and systemd anymore.

A kind soul has published what it takes to make a usable system without
all the anti-features of GNOME and other "user-friendly" desktop
systems.

 

Good luck!
-- 
  Ramakrishnan

Re: system upgrade by systemd

[Michael Meskes]

> I'm unclear as to what you have installed that triggers this, because I've
> been using systemd and sid for eons and have never encountered this
> behavior.  (That also makes me pretty sure, pace Steve, that this is not
> something *systemd* as systemd is actually doing, but some other
> component.)

Fair enough, I wasn't refering to systemd as the culprit, but to
whichever software caused this.

> Is it GNOME Software that you also have installed, per the other message
> on this thread?

Yes, sorry, I see your point. Also I have jessie security enabled in my
apt sources list, which may also make a difference.

> Looking at systemd-system-update-generator, it looks like this is a purely
> optional feature that is only triggered if you use a system upgrade method
> that uses the /var/lib/system-update staging area.  So I think blaming
> this on systemd is a little odd.  I certainly agree that it's a rather
> serious bug for this to suddenly start happening without your knowledge,
> particularly when it makes some decidedly bad dist-upgrade choices, but I
> think the fault here lies with whatever software staged this upgrade.  Not
> with systemd for just doing what it was told by another package.

Agreed, if that's the way to setup works, I'm completely with you.

> I like having the *choice* of being able to either use apt and upgrade
> directly, or stage an upgrade and have it happen on reboot.  It seems like
> systemd is providing that choice and supporting both options, which is
> great.  The question, in my mind, is why you're getting surprised with
> something using the method that you don't prefer.

Right, my point being this should never be the default.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: Security concerns with minified javascript code

[Vincent Bernat]

 ❦ 25 août 2015 22:37 GMT, Bas Wijnen  :

>> We need to leave the Javascript ecosystem mature a bit more but in the
>> meantime, a bit of tolerance would be appreciated
>
> The minifier is a compiler.  If it's not in main, files that are compiled with
> it cannot be in main.  For javascript, the easy solution is to not use the
> compiler.  Non-minified code works fine.

Non-minified code is decomposed in several dozen files. Using them is as
painful as trying to concat them and minifying them properly. There are
a lot of solutions. All of them will make the package a bit more buggy
than the previous ones. At the end, we will just get angry users and angry
upstream.

For years, we have been able to ship generated files without checking if
they can really be built from sources (for example, autoconf stuff). And
JS stuff should comply to stricter standards from day one? 

The main effect of this religious and overzealous application of our
guidelines is that people just stay away of JS stuff in Debian and
packaging any web-related app is becoming more complex as anyone needs
to deal with JS stuff in its own package.
-- 
Make sure your code "does nothing" gracefully.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Security concerns with minified javascript code

[Vincent Bernat]

 ❦ 25 août 2015 22:46 +0100, Steve McIntyre  :

>>Notably, one of the tool is Grunt and its myriad of plugins. Even if
>>Grunt was in Debian, we would also need Gulp, then Broccoli, because in
>>Javascript, there is always someone thinking that it should be possible
>>to do better. We need to leave the Javascript ecosystem mature a bit
>>more but in the meantime, a bit of tolerance would be appreciated for
>>the some of us needing to package some javascript bits.
>
> Why should we be tolerating setups where it's not clear that we can
> reproduce what's being shipped?

We have done that for years for autoconf stuff.
-- 
Use statement labels that mean something.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Security concerns with minified javascript code

[Riley Baird]

> For years, we have been able to ship generated files without checking if
> they can really be built from sources (for example, autoconf stuff). And
> JS stuff should comply to stricter standards from day one? 

JS stuff has been in Debian for a long time; it isn't fair to say that
this is day one. And autoconf isn't really a fair comparison, because
you can generally read the output files of autoconf, whereas minified
JS is just impossible.


pgpx8G0_fmk2j.pgp
Description: PGP signature

Re: system upgrade by systemd

[Vincent Bernat]

 ❦ 26 août 2015 05:23 +0200, Michael Meskes  :

>> Looks like it's probably worth uninstalling all of the packagekit
>> stuff if you don't want this horrendous anti-feature.
>
> Turns out I had only packagekit itself installed. Shouldn't its
> description mention this "horrendous anti-feature"? I couldn't agree
> more on the wording. Actually I consider this behavior a very grave bug.
> Yes, I can see some reasons for this "feature" but certainly not for it
> to be activated automatically and not exactly well documented.

There doesn't seem to have a bug report for this. This would be a better
place to discuss this issue.
-- 
He hath eaten me out of house and home.
-- William Shakespeare, "Henry IV"


signature.asc
Description: PGP signature

Re: system upgrade by systemd

[Marc Haber]

On Tue, 25 Aug 2015 20:35:30 +0200, Matthias Klumpp 
wrote:
>This is a feature of systemd and PackageKit.
>See http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/

Please disable this for Debian. Not tomorrow, do it today.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Security concerns with minified javascript code

[Vincent Bernat]

 ❦ 26 août 2015 15:44 +1000, Riley Baird 
 :

>> For years, we have been able to ship generated files without checking if
>> they can really be built from sources (for example, autoconf stuff). And
>> JS stuff should comply to stricter standards from day one? 
>
> JS stuff has been in Debian for a long time; it isn't fair to say that
> this is day one.

It's still young compared to autoconf stuff. And JS stuff is mostly
outdated in Debian due to the absence of the most common build
tool. Come on, we don't even have a modern jQuery. It's hard. Having
fellow developers nitpicking on stuff is not helping.

> And autoconf isn't really a fair comparison, because you can generally
> read the output files of autoconf, whereas minified JS is just
> impossible.

Sure, you can proofread a 30k-line configure script without a
problem. So, the condition is now "must be generated from source only if
the generated from is hard-but-not-impossible to read". Most people
(including me) just didn't want to deal with the bugs in those autoconf
scripts that may require specific versions of autoconf/automake and some
additional build dependencies. This is now mostly done but autoconf is
as old as Debian and the generalized use of dh-autoreconf is 2-year
old. Grunt is from 2012.
-- 
She is not refined.  She is not unrefined.  She keeps a parrot.
-- Mark Twain


signature.asc
Description: PGP signature

Re: Minutes from the "32bit architectures in Debian"-bof

[Paul Wise]

On Tue, Aug 25, 2015 at 3:08 AM, Russ Allbery wrote:

> Can we fully support cross-grading to amd64 before we do that?  My
> remaining i386 systems, and I'm sure I'm not the only one, are systems
> that I've been continuously dist-upgrading for some time precisely because
> I don't want to rebuild a system from scratch.
>
> If cross-grading were supported, I'd just do that and switch to amd64.

I guess folks interested in cross-grading should translate [1] into a
patch for [2], convince Holger to apply it and convert any errors into
bug reports.

1. https://wiki.debian.org/CrossGrading
2. http://jenkins.debian.net/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise