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
❦ 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
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
❦ 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 c
> 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
❦ 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
❦ 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 ea
> 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
> componen
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 b
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
> 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 s
> 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!) discu
> 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 function
> 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
* 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
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-softw
-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 hand
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
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 ma
❦ 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 Javas
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 a
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 Devel
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
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.
> >
> > Th
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
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
P
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 si
* 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
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].
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:
>
> - M
-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
* 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 me
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
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, inste
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
-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 se
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 int
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://zya
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
❦ 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 dei
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 front
❦ 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 deinsta
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/
> >>>
> >>
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
conflict
❦ 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
>>> a
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
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
> shu
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
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.
* 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 t
[ 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
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 wil
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
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 dg
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 k
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 f
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 d
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 downloa
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 int
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.
a
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 v
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].
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 ht
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
64 matches
Mail list logo
