Hi Dirk,
> | > … Simon McVittie has actually patched our testing framework to vary
> | > this and this is now live.
> | >
> | > https://bugs.debian.org/901473#33
[…]
> Are we sure this is fixed?
It might have taken a while for various build chroots to update so
I would be wary of inferring too
On Mon, 19 Nov 2018 23:40:44 +0100, Bernhard Schmidt
wrote:
>1.) Drop src:asterisk and src:pjproject from Buster.
Worst option, cutting our users of from Asterisk totally.
>2.) Keep the current pjproject and Asterisk version and don't follow the
>upgrade. This will probably be harder as it sound
On Tue, 20 Nov 2018 09:33:18 +0800, Paul Wise wrote:
>On Tue, Nov 20, 2018 at 6:46 AM Bernhard Schmidt wrote:
>
>> 1.) Drop src:asterisk and src:pjproject from Buster.
>
>IMO this seems like the most appropriate option until both projects
>are high enough quality.
That would, IMO, be another step
On 19 November 2018 at 17:32, Sean Whitton wrote:
| Hello,
|
| On Mon 19 Nov 2018 at 01:15PM -0500, Chris Lamb wrote:
|
| > Hi Dimitri,
| >
| >> […] e.g. using reproducible builds infra to do "build in
| >> --no-merged-usr, rebuild in --merged-usr, result should be the same"
| >> either as a on
On Tue, Nov 20, 2018 at 6:46 AM Bernhard Schmidt wrote:
> 1.) Drop src:asterisk and src:pjproject from Buster.
IMO this seems like the most appropriate option until both projects
are high enough quality.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Hello,
On Mon 19 Nov 2018 at 01:15PM -0500, Chris Lamb wrote:
> Hi Dimitri,
>
>> […] e.g. using reproducible builds infra to do "build in
>> --no-merged-usr, rebuild in --merged-usr, result should be the same"
>> either as a one-off, or on the ongoing basis.
>
> So, as mentioned on:
>
> https:/
On 2018-11-19 23:40, Bernhard Schmidt wrote:
> Asterisk maintainers have first offerered, then recommended working
> around this issue by shipping a private copy
I suggest to go that way. I really do not like embedded code
copies, but this situation is a perfect excuse for allowing one.
Debian fro
Hello everyone,
I'm seeking packaging guidance for a package (combination) I co-maintain
since shortly before the Stretch release. I'm not quite sure how to deal
with this situation in a way best for everyone involved (especially
release managers and security team).
Asterisk is probably known to
tags 914135 + moreinfo
thanks
Hi Rebecca,
> > libnfs (2.0.0-1~exp1) experimental; urgency=medium
[..]
> > Is this something that may be notified by lintian?>
> In theory,
> https://lintian.debian.org/tags/distribution-and-changes-mismatch.html ,
> but since it didn't trigger on libnfs, it woul
Package: lintian
Version: 2.5.112
Patrice Duroux wrote:
I was surprise to discover such case of the following package:
https://tracker.debian.org/pkg/libnfs
for which the unstable and testing versions have the ~exp1 suffix and
the head of the corresponding changelog.Debian.gz is:
libnfs (2.0.
Enrico Weigelt, metux IT consult wrote:
> I'm often seeing packagers directly putting dfsg'ed trees into their git
> repos, w/o any indication how the tree was actually created from the
> original releases.
[...]
> My preferred way (except for rare cases where upstream history is
> extremely huge
On Mon, 19 Nov 2018 17:29:37 +0100, Enrico Weigelt, metux IT consult wrote:
(OT, but since I noticed it too:)
> Anyways, Skype doesn't work since 8.30 as it crashes directly on
> startup.
Apparently it needs (e)logind since that version.
Cheers,
gregor
--
.''`. https://info.comodo.priv.at
Dear Debian dev,
I am sorry to address you the following case to the devel mailing list if
is not the right place
but I think that it may concern different components in the Debian
infrastructure.
I was surprise to discover such case of the following package:
https://tracker.debian.org/pkg/libnf
Hi Dimitri,
> […] e.g. using reproducible builds infra to do "build in
> --no-merged-usr, rebuild in --merged-usr, result should be the same"
> either as a one-off, or on the ongoing basis.
So, as mentioned on:
https://reproducible-builds.org/blog/posts/185/
… Simon McVittie has actually patc
Ian Jackson wrote:
> Daniel Pimentel writes ("Iptables on Sid"):
>
> > I'd like to report a posible bug:
[..]
> Please see this page about how to report a bug:
Actually, I believe this to be already filed as:
https://bugs.debian.org/914074
Regards,
--
,''`.
: :' : Chris Lam
Michael Biebl writes:
>
> Most packages which are affected by this issue I've seen so far search
> for the binaries in $PATH and encode the full path of the first find.
> Since PATH is typically set to something like
>
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
On 19.11.18 17:36, Ian Jackson wrote:
Hi,
> I am saying that for packages whose Debian maintainer follow those>
> recommendations, much of what you want would be straightforward - or,>
anyway a lot easier. So I was plugging my recommendations.
Unfortunately, those packages I'm coping w/ don't r
Am 19.11.18 um 15:55 schrieb Dirk Eddelbuettel:
>
>
> tl;dr: We may be messing up /bin and /usr/bin on some platforms
>
>
> Sorry for the alarming headline but #913982 was filed, indepedently
> corrobated and simultaneously discovered by upstream.
>
> GNU R has long been relying on sed, tar,
Done,
thanks Ian,
att,
---
MSc. Daniel
d4n1.org
On 2018-11-19 14:12, Ian Jackson wrote:
> Daniel Pimentel writes ("Iptables on Sid"):
>
>> I'd like to report a posible bug:
>>
>> the symbolic link /sbin/iptables not exist when I did upgrade.
>> So I did: sudo ln -sf /usr/sbin/ipt
Ian Jackson writes:
> Russ Allbery writes ("Re: Our build system may be broken: /bin vs /usr/bin"):
>> Marco d'Itri writes:
>>> Actually this is the root problem: policy says that packages should
>>> use the $PATH to search for commands, but your package (like many
>>> others) hardcodes their fu
Daniel Pimentel writes ("Iptables on Sid"):
> I'd like to report a posible bug:
>
> the symbolic link /sbin/iptables not exist when I did upgrade.
> So I did: sudo ln -sf /usr/sbin/iptables-legacy /sbin/iptables to fix it in
> this momment.
>
> the iptables package broken in some package like d
Russ Allbery writes ("Re: Our build system may be broken: /bin vs /usr/bin"):
> Marco d'Itri writes:
> > Actually this is the root problem: policy says that packages should use
> > the $PATH to search for commands, but your package (like many others)
> > hardcodes their full path.
>
> Policy on
Matthias Klumpp writes ("Re: Our build system may be broken: /bin vs /usr/bin"):
> Ideally the build system would correctly detect an usr-merged system
> and set paths accordingly.
I don't know how that would be possible. If it's determined to
hardcode a path, the correct path to hardcode depends
Marco d'Itri writes:
> On Nov 19, Dirk Eddelbuettel wrote:
>> GNU R has long been relying on sed, tar, bzip2, ... and many more base
>> tools. No issues there. Generally looked for in /bin and found there.
> Actually this is the root problem: policy says that packages should use
> the $PATH to
Enrico Weigelt, metux IT consult writes ("Re: git vs dfsg tarballs"):
> On 19.11.18 13:52, Ian Jackson wrote:
> > I think that most of the workflows recommended in these manpages
> >
> >
> > https://manpages.debian.org/stretch-backports/dgit/dgit-maint-gbp.7.en.html
> >
> > https://manpages.
Hi,
I'd like to report a posible bug:
the symbolic link /sbin/iptables not exist when I did upgrade.
So I did: sudo ln -sf /usr/sbin/iptables-legacy /sbin/iptables to fix it
in this momment.
the iptables package broken in some package like docker and etc.
--
MSc. Daniel
d4n1.org
❦ 19 novembre 2018 09:51 -0600, Dirk Eddelbuettel :
> | Dirk Eddelbuettel writes ("Our build system may be broken: /bin vs
> /usr/bin"):
> | > tl;dr: We may be messing up /bin and /usr/bin on some platforms
> |
> | This is the result of the change of the buildds to have `usrmerge', ie
> | merg
On 07.10.18 21:20, Adrian Bunk wrote:
> For leaf software like Skype or Chrome, approaches like flatpak where>
> software can be installed by non-root users and then runs confined>
have a more realistic chance of being able to becoming a good solution.
I'd rather put those non-trustworthy code th
On 19.11.18 13:52, Ian Jackson wrote:
> Clearly the transformation on the *tree* can't be reversible because
> in the usual case it is deleting things. So you'll need the history.
It certain can be, if you know the exact orig commit.
Maybe I wasn't really clear here: I wanna do a fully automatic
On 19 November 2018 at 16:59, Matthias Klumpp wrote:
| Am Mo., 19. Nov. 2018 um 16:52 Uhr schrieb Dirk Eddelbuettel
:
| >
| >
| > Hi Ian,
| >
| > Thanks for the follow-up.
| >
| > On 19 November 2018 at 15:45, Ian Jackson wrote:
| > | Dirk Eddelbuettel writes ("Our build system may be broken: /b
On Nov 19, Matthias Klumpp wrote:
> I wonder how this was handled on other distributions when they made
> the change - even if the change was applied on all systems, there must
> have been at least one release where both modes were supported.
No, Fedora and RHEL just switched overnight.
On Nov 1
On Mon, 19 Nov 2018 at 15:02, Dirk Eddelbuettel wrote:
>
>
>
> tl;dr: We may be messing up /bin and /usr/bin on some platforms
>
>
> Sorry for the alarming headline but #913982 was filed, indepedently
> corrobated and simultaneously discovered by upstream.
>
> GNU R has long been relying on sed,
On Nov 19, Dirk Eddelbuettel wrote:
> GNU R has long been relying on sed, tar, bzip2, ... and many more base
> tools. No issues there. Generally looked for in /bin and found there.
Actually this is the root problem: policy says that packages should use
the $PATH to search for commands, but your
Dirk Eddelbuettel writes ("Re: Our build system may be broken: /bin vs
/usr/bin"):
> That was very much my gut feel but I am a little removed from the more core
> moving and shaking and I didn't know what changed recently.
This usrmerge change has been discussed here on -devel recently and
IIRC h
Am Mo., 19. Nov. 2018 um 16:52 Uhr schrieb Dirk Eddelbuettel :
>
>
> Hi Ian,
>
> Thanks for the follow-up.
>
> On 19 November 2018 at 15:45, Ian Jackson wrote:
> | Dirk Eddelbuettel writes ("Our build system may be broken: /bin vs
> /usr/bin"):
> | > tl;dr: We may be messing up /bin and /usr/bin
Hi Ian,
Thanks for the follow-up.
On 19 November 2018 at 15:45, Ian Jackson wrote:
| Dirk Eddelbuettel writes ("Our build system may be broken: /bin vs /usr/bin"):
| > tl;dr: We may be messing up /bin and /usr/bin on some platforms
|
| This is the result of the change of the buildds to have `
Dirk Eddelbuettel writes ("Our build system may be broken: /bin vs /usr/bin"):
> tl;dr: We may be messing up /bin and /usr/bin on some platforms
This is the result of the change of the buildds to have `usrmerge', ie
merged /bin and /usr/bin. I think this shows that this change is
generating RC b
Package: wnpp
Severity: wishlist
Owner: Andreas Henriksson
* Package name: mender-client
Version : 1.6.0b1+git20181015.3032b74-1
Upstream Author : Mender
* URL : https://github.com/mendersoftware/mender
* License : Apache 2.0
Programming Lang: Go
Descriptio
Package: wnpp
Severity: wishlist
Owner: Andreas Henriksson
* Package name: golang-github-mendersoftware-scopestack
Version : 0.0~git20180403.c2f5599-1
Upstream Author : Mender
* URL : https://github.com/mendersoftware/scopestack
* License : Apache 2.0
Program
Package: wnpp
Severity: wishlist
Owner: Andreas Henriksson
* Package name: golang-github-mendersoftware-mender-artifact
Version : 2.3.0b1+git20181022.1bedfca-1
Upstream Author : Mender
* URL : https://github.com/mendersoftware/mender-artifact
* License : Apache
Package: wnpp
Severity: wishlist
Owner: Andreas Henriksson
* Package name: golang-github-mendersoftware-mendertesting
Version : 0.0~git20180410.9e728b5-1
Upstream Author : Mender
* URL : https://github.com/mendersoftware/mendertesting
* License : Apache 2.0
P
Package: wnpp
Severity: wishlist
Owner: Andreas Henriksson
* Package name: golang-github-mendersoftware-log
Version : 0.0~git20180403.f608c95-1
Upstream Author : Mender
* URL : https://github.com/mendersoftware/log
* License : Apache 2.0
Programming Lang: Go
Package: wnpp
Severity: wishlist
Owner: Andreas Henriksson
* Package name: golang-github-ungerik-go-sysfs
Version : 0.0~git20170424.9c991ee-1
Upstream Author : Erik Unger
* URL : https://github.com/ungerik/go-sysfs
* License : MIT
Programming Lang: Go
Descr
Package: wnpp
Severity: wishlist
Owner: Andreas Henriksson
* Package name: golang-github-bmatsuo-lmdb-go
Version : 1.8.0+git20170215.a14b5a3-1
Upstream Author : Bryan Matsuo
* URL : https://github.com/bmatsuo/lmdb-go
* License : BSD-3-clause
Programming Lang:
tl;dr: We may be messing up /bin and /usr/bin on some platforms
Sorry for the alarming headline but #913982 was filed, indepedently
corrobated and simultaneously discovered by upstream.
GNU R has long been relying on sed, tar, bzip2, ... and many more base
tools. No issues there. Generally l
Enrico Weigelt, metux IT consult writes ("git vs dfsg tarballs"):
> Can we agree on some auomatically reproducable (and inversable)
> transformation process from orig to dfsg tree
Clearly the transformation on the *tree* can't be reversible because
in the usual case it is deleting things. So you'
Guido Günther writes ("Re: salsa.debian.org: merge requests and such"):
> On Fri, Nov 09, 2018 at 07:42:13PM +, Holger Levsen wrote:
> > - git wise, I think, I reverted these commits, pushed my changes and
> > merged the reverted commits again. No big deal, except a bit of messy
> > history
Dzień dobry,reprezentuję nowoczesnej Agencję Interaktywną.Zajmujemy się budową
nowoczesnych oraz profesjonalnych Stron i Sklepów internetowych. Jeżeli mogę
przedstawić Państwu nieodpłatnie naszą aktualną propozycję dla Państwa firmy to
bardzo proszę o odpowiedź o treści "tak" na ten adres e-m
Hi folks,
I'm often seeing packagers directly putting dfsg'ed trees into their git
repos, w/o any indication how the tree was actually created from the
original releases.
As I'm doing all patching exclusively via git (no text-based patches
anymore - adding my changes ontop the upstream release t
On 06.07.18 22:00, Colin Watson wrote:
> If the libraries in question are DFSG-free themselves, there's no DFSG
> issue and you don't need to remove them from the tarball (and we'd
> generally encourage not modifying the upstream tarball unnecessarily for
> upload to Debian). The policy about bun
On 17.10.18 08:55, free...@tango.lu wrote:
> Dropping sysvinit would also put an enormous amount of work on the
> Devuan project (the only future for Debian) by making them fork more
> packages.
Well, in that case we can also completely drop other Lennartware
dependencies in the affected packages
51 matches
Mail list logo
