Setting permissions on new users in postinst
See bug #1064349.
I think the problem (correct me if I am wrong!) is that the postinst -
debian/amavisd-new.postinst - does (simplified):
=== cut ===
#DEBHELPER#
case "$1" in
configure)
# configure file permissions to use new amavis user
...
esac
=== cut ===
This means that #DEBHELPER# expands to the code that creates the
users and starts the daemons.
=== cut ===
# Automatically added by dh_installsysusers/13.14.1
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
systemd-sysusers ${DPKG_ROOT:+--root="$DPKG_ROOT"} amavisd-new.conf
fi
# End automatically added section
# Automatically added by dh_installsystemd/13.14.1
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
# The following line should be removed in trixie or trixie+1
deb-systemd-helper unmask 'amavis.service' >/dev/null || true
# was-enabled defaults to true, so new installations run enable.
if deb-systemd-helper --quiet was-enabled 'amavis.service'; then
# Enables the unit on first installation, creates new
# symlinks on upgrades if the unit file has changed.
deb-systemd-helper enable 'amavis.service' >/dev/null || true
else
# Update the statefile to add new symlinks (if any), which need
to be
# cleaned up on purge. Also remove old symlinks.
deb-systemd-helper update-state 'amavis.service' >/dev/null ||
true
fi
fi
# End automatically added section
# Automatically added by dh_installsystemd/13.14.1
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
if [ -d /run/systemd/system ]; then
systemctl --system daemon-reload >/dev/null || true
if [ -n "$2" ]; then
_dh_action=restart
else
_dh_action=start
fi
deb-systemd-invoke $_dh_action 'amavis.service' >/dev/null ||
true
fi
fi
# End automatically added section
[ similar for other services that are disabled by default ]
=== cut ===
I think we have a race condition, the daemon tries to start before we
setup the file permissions correctly. Both on sysvinit and systemd, but
seems we can get away with this more with systemd. Probably because of
the extra checks in the initd script that systemd version doesn't have.
But I can't move the #DEBHELPER# to the bottom, because then the setting
the file permissions would fail because we haven't added the user yet.
How do I fix this?
(Please CC responses to me, thanks)
--
Brian May @ Linux Penguins
Re: Reducing allowed Vcs for packaging?
On Sun, 2023-02-26 at 14:24 +0100, Bastian Germann wrote:
> Hi!
>
> During the last weeks I had a look at the Vcs situation in Debian. Currently,
> there are eight possible systems allowed and one might specify several of them
> for
> one package. No package makes use of several Vcs references and frankly I do
> not
> see why this was supported in the first place.
>
> For the allowed systems the situation in unstable is the following:
> arch is used by 2 packages pointing to bad URLs: #1025510, 1025511.
> bzr is used by ~50 packages, half of which point to bad URLs.
> cvs is used by 3 packages, 2 of which point to bad URLs: #1031312, #1031313.
> svn is used by ~130 packages, many of which point to bad URLs.
> darcs, mtn, and hg are not used.
>
> We can see: The Vcs wars are over; with git there is a clear winner and in my
> opinion, we should remove the possibility to use most of them for package
> maintenance. It is one additional barrier to get into package maintenance and
> we should remove the barriers that are not necessary.
>
> I would like to suggest removing the possibility to specify several systems
> and
> removing all systems except bzr, svn, and git, while deprecating bzr and
> possibly svn.
> This means solving the four listed bugs and convincing the cvsd maintainer to
> switch or drop the Vcs-Cvs reference. Then, the Debian Developer's Reference
> should specify the changes in §6.2.5 and whatever parses Vcs-* in
> debian/control
> should be adapted to do the specified thing.
>
> Finally, we can drop the orphaned packages {cvs,mercurial}-buildpackage
> (see #1026433) and add deprecation notices in brz-debian and svn-buildpackage.
>
> Thanks for any comments,
> Bastian
>
It does seem like the VCS wars are over--for now. Who knows what type of
situation could force our hand to use a different VCS than Git? That future is
hard to imagine but is certainly a possibility. I think I'm understanding your
point that it would make the package maintainers lives' easier, and it does
sound like some of the packages using non-Git VCS are rotting, at least in that
regard. However, I would be hesitant to remove support for the other VCS
systems.
From my experience, whenever software engineers are actively limited for
seemingly no or little gain, they tend to turn their attention elsewhere. Also,
ripping out logic to support 7 other VCS systems stifles creativity and puts us
down a one-way street. Sure, you could argue that adding that logic back in
wouldn't be hard, but then why remove it in the first place? Wouldn't it be
more prudent just to update the non-Git packages to use Git? That's going to
have to be done anyway for a lot of them (or not).
My point is, the gain doesn't seem to be larger than the possible (and not that
probable in the near future) cost. Admittedly, it's difficult to gauge the
costs of these things.
--
Sincerely,
Brian T
publickey - brianrobt@pm.me - c8f2ec48.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
Re: Bug#1030780: Maintainers wanted for softether-vpn
On Wed, 2023-02-08 at 05:52 -0600, Brian Thompson wrote: > On Tue, 2023-02-07 at 14:23 +0100, Andrej Shadura wrote: > > Package: wnpp > > Severity: normal > > X-Debbugs-Cc: debian-devel@lists.debian.org > > > > Hi all, > > > > I packaged SoftEther VPN back in 2020 when people in Belarus protested > > against decades of > > dictatorship, and they needed a safe way to communicate with the outside > > world and with each > > other, circumventing the state censorship. > > > > Since then, due to a massive crackdown on protests and repressions against > > anyone remotely > > involved, most of my friends have moved abroad, and I, personally, don't > > know a single user of > > this VPN right now. Packaging is not hard, but not super trivial either, > > and requires some work to > > package subsequent releases. Not using this software myself, I'm really not > > in position to > > continue being the maintainer, and if nobody takes it over, I will have to > > orphan it eventually. > > > > Please let me know if you can help. > > > > -- > > Cheers, > > Andrej > > > > Hi Andrej. The package's history sounds really interesting. I would be > honored to continue > maintaining it. > Andrej, I have packaged the latest Stable version (https://github.com/SoftEtherVPN/SoftEtherVPN_Stable/releases?page=1) locally but have some questions for you. We can connect on IRC (or wherever) outside of the mailing list if you'd like. My IRC@OFTC is brianrobt. -- Sincerely, Brian GPG fingerprint: 60B2 99C0 F893 81E0 AA81 6205 6C9B 5E73 B3E1 2C3B signature.asc Description: This is a digitally signed message part publickey - brianrobt@proton.me - 688c834d.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Bug#1030780: Maintainers wanted for softether-vpn
On Tue, 2023-02-07 at 14:23 +0100, Andrej Shadura wrote: > Package: wnpp > Severity: normal > X-Debbugs-Cc: debian-devel@lists.debian.org > > Hi all, > > I packaged SoftEther VPN back in 2020 when people in Belarus protested > against decades of > dictatorship, and they needed a safe way to communicate with the outside > world and with each > other, circumventing the state censorship. > > Since then, due to a massive crackdown on protests and repressions against > anyone remotely > involved, most of my friends have moved abroad, and I, personally, don't know > a single user of > this VPN right now. Packaging is not hard, but not super trivial either, and > requires some work to > package subsequent releases. Not using this software myself, I'm really not > in position to > continue being the maintainer, and if nobody takes it over, I will have to > orphan it eventually. > > Please let me know if you can help. > > -- > Cheers, > Andrej > Hi Andrej. The package's history sounds really interesting. I would be honored to continue maintaining it. -- Sincerely, Brian signature.asc Description: This is a digitally signed message part publickey - brianrobt@proton.me - 688c834d.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Consensus on closing old bugs
On Mon, 2023-02-06 at 11:51 +0100, Santiago Vila wrote: > Let the maintainers handle their bugs. > Old bugs should not be closed just because they are "old". > > For example, I have an open bug which is 26 years old: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=5898 > > and I don't see any reason to close it. Fair enough. Thanks! signature.asc Description: This is a digitally signed message part publickey - brianrobt@proton.me - 688c834d.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Consensus on closing old bugs
I understand that the usual way to close out bug reports is having the original author do it themselves. What's the policy on closing bug reports that haven't had activity in over 6 months? Specifically I am talking about the following: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007922 Sincerely, Brian publickey - brianrobt@proton.me - 688c834d.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]
On 2022-11-10 at 16:37:53, Tollef Fog Heen wrote: > ]] Robie Basak > > > But are you in essence saying that libpam-tmpdir requires that *every > > maintainer script* that runs things as non-root, or starts processes > > that do that, unset TMPDIR first? > > I think it's more wide than that: If you change UID, you need to > sanitise the environment. Your HOME is likely to be wrong. PATH might > very well be pointing at directories which are not appropriate for the > user you're changing the UID to, etc. I believe this is the best practice. For example, sudo typically passes through only a handful of environment variables, such as TERM, to avoid things like insecure PATH entries. For example, if MySQL invoked a binary in PATH and I had a custom script named the same thing that had insecure behaviour when invoked as another user, that would be bad. OpenSSH also sanitizes the environment passed over the connection. Without getting into a debate about systemd, this is one the pieces of functionality it provides, since it runs binaries in a clean environment. You can probably get most of that in a sysvinit script by using `env -i` with a handful of environment variables specifically overridden if necessary. Then it would be very obvious what dependencies the binary had on the outside environment. > > I think the answer to this should probably be established by the > > libpam-tmpdir maintainer and documented first, for fear of someone else > > later coming along and saying that the maintainer script incorrectly > > ignores TMPDIR because we started ignoring it to resolve this bug. So I > > copied debian-devel@ for comment. > > I'm not sure this is libpam-tmpdir specific, but rather a bit more > general: what are the expectations that maintainer scripts can have > about the environment they're running in, and how do we make those > expectations hold? This should probably then be documented in policy. I agree documentation here is helpful. For reference, this was an invocation from `sudo aptitude` as part of a normal package upgrade, which I think is a relatively common situation to be in. Possibly also an initscript helper which enables developers to do the right thing automatically, or a flag to start-stop-daemon, or other tooling would be beneficial to help people easily solve this problem without thinking too much about it. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
membership revoked?
Hi, I don't see my name "Brian Smith" listed at https://nm.debian.org/members/. However, I do see my profile at https://nm.debian.org/person/bsmith/. Did I get kicked? -- Brian T. Smith System Fabric Works Senior Principal Engineer bsm...@systemfabricworks.com GPG Key: 0xB3C2C7B73BA3CD7F
Re: Debian choice of upstream tarballs for packaging
On 0825, Simon Richter wrote: >Hi, > >On 8/25/21 1:21 AM, Sean Whitton wrote: > >> From my point of view, signing git tags is no less well established a >>best practice than signing tarballs -- in fact, to me, it seems *more* >>well established. > >That is ecosystem dependent. > >FWIW, I'd love to see git bundles as a source archive format -- this would >allow shipping a (signed) tag, its commit, and the tree and blob objects for >that commit as a single file that can be built in a reproducible way and allows >changes on top to be easily tracked, including the branch point. > >In the absence of an "official" upstream release tarball, using this format >also makes it clear that this is a git snapshot, so no explanation is needed >how that archive was created. Ecosystem-dependent or not, I can see being able to verify who uploaded the Git tag (or anything for that matter) as being increasingly valuably in a world where there is a lot of uncaught or ignored plagiarism. Uploaders and creators should have integrity so that their users can rely on them and be confident to deliver quality work. -- Best regards, Brian T signature.asc Description: PGP signature
Re: Bits from the Release Team: say hello to our studious bookworm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 2021-08-15 at 00:02 +0100, Jonathan Wiltshire wrote: > Hi, > > On 14th August 2021 we released Debian 11 "bullseye". > > There are too many people who should be thanked for their work on > getting > us to this point to list them all individually, and we would be sure > to > miss some. Nevertheless, we would like to particularly thank the > installer > team, the buildd and ftp teams, the CD team, the publicity team, the > webmasters, the Release Notes editors, porters and all the bug > squashers, > NMUers, package maintainers and translators who have contributed to > making > bullseye a great release of which we should all be proud. > > First point release > === > > As on previous occasions, we anticipate that the first point release > for > bullseye will occur in approximately one month's time. > > Please co-ordinate fixes which you would like to see included in the > point > release with the Stable Release Managers (SRMs) via a "pu" bug against > the > release.debian.org pseudopackage, including a debdiff of the current > and > proposed source packages. Remember to use reportbug unless you enjoy > crafting the metadata by hand. > > Autopkgtests continue to be crucial to migration > > > Following the release of bullseye, we can confirm that autopkgtests > (when > provided) will continue to be considered across all architectures for > migration to bookworm. In other words, the tests need to succeed on > all > release architectures for your package to migrate. > > Start working on bookworm > = > > With the start of the bookworm release cycle, you can now upload to > unstable those changes you've been holding off during the freeze. > Please do > not rush to upload everything all at once, in order to manage load on > the > buildds etc. Automatic testing migration is not yet re-enabled, but > that > will happen during the next few days. > > As with bullseye, we would ask that you co-ordinate particularly large > transitions or changes; if your plans involve major toolchain changes > or > otherwise have the potential to cause problems in unstable for a long > time > (e.g. due to FTBFS issues), please talk to us. We know that there are > a > large number of changes which have been waiting for the release to > happen > and we're keen not to stand in the way of those but would also like to > avoid a number of larger transitions becoming entangled. > > That's it for now; it is time for the celebrations to begin, whether > at a > Release Party[1] or otherwise. :-) > > Thank you everyone for all your hard work! - -- Best regards, Brian T. -BEGIN PGP SIGNATURE- iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEYccETHGJyaWFuQGhh c2h2YXVsdC5pbwAKCRCDDY1y7c2GfacLD/9hOuSji6aJQprXk05lvJ+mKHhnhCV9 jX6eEN9exJ4v+gtbD62PYoegqUScVCMYR/B49Je4CKIqlh+9EmcjwnURSBtZPA3F dP0wgO2zU9j5P4wwCdLEtY5pKYD5Guxl4pqDEvasuoJqV+1RMtyiHC6X8DUeQgJS O1QtpYgukZEsCaAcQIXFPsI3x3wgMKjiT9WNYLvccknwkEqXikZnvA2T+Dpkijsx N4MidaOf0syVD1bh3X6uiB+r2WbLdT8j0zJ8Og5dqTWsT011PKnMCf4H8z6PIxwp RsMokIabZdn1ul99PTTILPMAMD2oV8E8XMzI49++00PH5bJ14xsHBnIbguaxuDa6 aeOyCNZoWn5gKknEsG0LOkAoagkzvaUUq+ZEBOEKeqbuQDPZU9aMMrlH4gsQVXfJ LEa2h7DNSkShK7NTFugYDaRmec4YFs8CkS7BhbhEvWXaZHMYOaWBcxpzoFaxrJiQ KQfrjxlE/ddI8JFy+KsAQdmM8jE40vNeFf6H/XXrY3Zj6s5rFG87wqaxGW+iVuV/ 1BqpLhXsn8mQN9W+FPHc9zTEco1vDo3fwvDatEWktkNJM/zk2TURG/VBATBd1N+z kansOpHtQ0grEDlhVcYhKBF8XnpmphGGKt4NGN+RE6MYsSa/tErt/bgD6HksVcVa o/HMNFHI8J+PJw== =fGSa -END PGP SIGNATURE-
Re: Debian package manager privilege escalation attack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2021-08-12 at 11:19 +0500, Andrey Rahmatullin wrote: > On Thu, Aug 12, 2021 at 01:12:37AM -0500, Brian Thompson wrote: > > Would you agree that there is an issue with sudo access that is > > enabled > > by default on most Debian and Debian-based distributions? The bug > > may > > not be in apt, but it definitely lives somewhere. > Do you think "sudo access" itself is a "privilege escalation attack"? I do not. I think that the possibility of dangerously configured sudo access is a vulnerability. -BEGIN PGP SIGNATURE- iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEUvsITHGJyaWFuQGhh c2h2YXVsdC5pbwAKCRCDDY1y7c2GffuzD/9+1W9z3AA/DFy5HgBgV5ntSiP6hhQ4 PdybHxQ1zP7A4uZHdGV4IqsfOKWkuhnzV/dA5Rpk7pvT1iWDQgkz7uEK5HXkQT4N QCg3MeBbqdDpqG5UakVnyu+qGJ26pRyQYmq54dZOUFmNJL8uF5BwnPg7d4NWikds 0e2QrYtyaFFVaInhDHE7uM+eYQtmWSP5yXYxGy9RLjUpLB1SPqAxeR4bZxeJ2yAz 873L1VpWOHbmxsRZj6NRH6dh2o87fqAq1BcnJZrLpbm38YKIE8PKtaNjKlhFLItt hwnGPJfobrxGG4gPgwJBB2S+FP+K6kWxSSA9y1lpAo+kLZlZFENWWxnGpgBIZ2+Q DZTFM6nPkwAvWLz1rpP5tf9Kqa7ABLyHnHdNqHAd44VtihCjwFkRtzPQgoysPGux nghHMpCmdYXuen6xaPaDSvR5emy6XVuuYvEBVjGMtR4VwJsYwgLOv1hbh+yN+fTx ItpwQjOXsD0PgGPs5BjF2G2aGHiVcHLuAZ6q0JbBo+QsCC5T3cDEJyPyuImRpNUX zQ9oyA8crGO5kq/7qz1I8/mMBrbaHKtgI9sCwwOwT56EUCvN2J0VcQGgrqQ0mVEB fJnCJFGlBrixpwbrMOik/P4QtibprVh070MgATb0QunTxyJLvnC3y/1XySkRCY8j eLvWe2IBKBalmw== =4yEj -END PGP SIGNATURE-
Re: Debian package manager privilege escalation attack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2021-08-12 at 10:44 +0500, Andrey Rahmatullin wrote: > On Wed, Aug 11, 2021 at 10:55:44PM -0500, Brian Thompson wrote: > > Thank you for bringing this to everyone's attention. This are very > > real > > vulnerabilities. > How are they vulnerabilities? > They are vulnerabilities because the user is susceptible to this kind of attack by default. I don't think a lot of users are security-conscious enough to prevent sudo access for commands like apt and snap. > > NPM has similar issues with stopping malicious packages from being > > published to the FTP server. > That's not what is the article about. Correct, but NPM served as an anecdote for a point I was trying to make. > Ah, so you haven't read the article. No, I read the article. - -- Best regards, Brian T. -BEGIN PGP SIGNATURE- iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEUvN8THGJyaWFuQGhh c2h2YXVsdC5pbwAKCRCDDY1y7c2GfZx5D/4i2kVC+zcYFXYad13SPPJjwIRI0pM3 PMKwdb4NIFG8eG3vurWbq/p7cUihXjahpq1xbTkifzfAnE22y9k7Sj85vDR5j2F/ Pfir09qymjLoOdmFCCRuRdraBe8bUuaWolHnHIVdT0Jif3KeRk/I6njn0ZKa0dI3 2yaA9owJPIxRUGki7OMFLwz5WdoTU4t77AHD3JiU9e1QExV/Z2AQi6twGAVqJVVY JtUan3P/NmWBsBjPxPg+zuAp3/YVPpHBS02mI3A+sHp2qzQDUQ3S9lpuEx/QuxN0 BhLynoqugG8ZQDJvymENFCvr2WYRz1/0heE/YouR9MCLpchdZidSzyTsgvj6BH9d WipAdocRzqgEWvL+vDbcnG8JKHhzGqpeny08fbMKbl/Nmm7cS781MdWtw7tmk0Nq Bs3yzneBihgi9duQrvlIncaroBv5FkoGCzNPvL8dKudA8dVLyPWG0rlPSrkRLSfs zYSVRL/D99G+f8YCz+HmPq1CYEKNxeATZI/l1qrUZq6K5yAlUWHlmEnylZILcUAm ZnAgIQnpTq/SrH8QLH/03qSZ/lqYi05Rn/Q0WOkv8g+t5I7mytvzKWu9qsZUopWg YFmVp/4+eyg1SjaCM5PCO6tv2D8AjK8UW0uzwTXT1LF+2DeM7sC8/hgIU49Ebv/T Q6ZdTfoS3cbL3g== =W0yz -END PGP SIGNATURE-
Re: Debian package manager privilege escalation attack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2021-08-12 at 07:38 +0200, Niels Thykier wrote: > Timothy M Butterworth: > > All, > > > > I just ran across this article > > https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I > > tested > > the attacks on Debian 11 and they work successfully giving me a root > > shell prompt. > > > > Tim > > > > Hi Tim, > > All of the attacks presented assumes that the local user has "sudo" > permissions to run apt and use that as the basis for escalating > privileges (not commenting on yum or snap). > > I think it is a good demonstration of how some sudo policies are too > lenient and can be exploited. Though I am not sure this is a bug in > apt, as I do not think apt ever promised to be "safe" to use from a > constrained sudo policy. > Would you agree that there is an issue with sudo access that is enabled by default on most Debian and Debian-based distributions? The bug may not be in apt, but it definitely lives somewhere. > Thanks, > ~Niels > -BEGIN PGP SIGNATURE- iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEUu9UTHGJyaWFuQGhh c2h2YXVsdC5pbwAKCRCDDY1y7c2Gfb8QD/sH4ko8qsI7Dxyf4t8oM7bRWnGeyYXG C+e/7kb8ePKXJcSIspbzlEHefsp/chqjWQnA8f3Kqjdn77eGVecxk5O7cyN0nJyC Ih3LyLvuU2CoeLsPw7+0g4Ta81sdNh22xl/M1V3Fkbg5E1AWL7dSLwuj7LzgH5Fo w/YudfGKiyZD7gtdgOP3rfae0rLsgxklUsZQOSEEHyYGuwWZRhwNimWnytKI9XC2 z4LrAxeW07e3GA/RjUWp86/+Lub7RchirCvkV2HpAFRY88mBQbHGLjskyRma3FQ4 rfkuGOQ8R34MHuth7HeSjzuKQhqQ7FRFbH5n0rPB1O20jnjbtO/0UuQ88Foha2Um +S//kLXXpPEo/52nBGnT9KmRTTaMAmqbZPTuE2F5T2hLtNBhgK8HPEcMpn7jW1vT EYYg3aoNvO6pFe0jL9gGomViS+JoCcFkXQI4xaPqkQchjOkTaQNym8alxDiZqwEk rKq8Fz3mTlMYQHpuTM9qNLPCkTWlMg+mFsEarZJcWtjrHiqIKFFPAH+G9SMqHRxD LUcU0iKcoZtBvtSnDnt8QFhwc9eWPFqitoPihliAkfORC7KMmMJ5QgEd0TN/5r6n LmyVo7n8zF2D1ZwUAty3WfWMpRgx8TC2keXsuLWyqW9EZO/PSQplO86tjzYDYWfg WgY5vDsL7eMzFg== =QmLv -END PGP SIGNATURE-
Re: Debian package manager privilege escalation attack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2021-08-11 at 23:30 -0400, Timothy M Butterworth wrote: > All, > > I just ran across this article > https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested > the attacks on Debian 11 and they work successfully giving me a root > shell prompt. > > Tim Thank you for bringing this to everyone's attention. This are very real vulnerabilities. NPM has similar issues with stopping malicious packages from being published to the FTP server. They have made some improvements after they were aware of the issue, but I haven't heard any new developments at NPM about how to stop malicious packages from making it to the server. Malicious packages can and do make it into the dependency sets of popular packages. This is a problem. I don't think that any amount of human effort and attention can prevent malicious packages from making it to the FTP server. I think that AI would be better-equipped to handle the critical checks necessary for FTP upload security to be top-of-the-line. The AI couldn't just be left unchecked, though, and humans are still needed to monitor, tweak, and make sure the AI is working and behaving in a responsible manner. As far as behaving responsibly is concerned, the main issue I foresee is having the AI flag false positives, and making sure the AI doesn't evolve into something insidious. I'm not sure if that last point can exist within limited AI, because I am not an AI expert. Perhaps a workaround for users right now would be to have a user with package management sudo access, and not much else. sudo access for package managers would have to be disallowed at the root and [other] user levels. I am not even sure that this would even work for all use cases, and having a manual ad-hoc hotfix is far from ideal. What does the Debian community think about this? Also, we should notify our upstream projects, and the Linux community as a whole, of these vulnerabilities. I believe that to be a moral obligation. - -- Best regards, Brian T. -BEGIN PGP SIGNATURE- iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEUm8ATHGJyaWFuQGhh c2h2YXVsdC5pbwAKCRCDDY1y7c2GfYQuD/47aYb4u7hIZ0n8yAdfzPVHVjvYrOzc Ke7sSSHktgtsBPxWulXjwggm4/XlYlk06TEmDycr60/Ql1ncPZkZ9L2WaKUWabiy fZ3wSaN7Sd8fCM2ls4GGr6m66UiqjIYzmlJJrn3WdVQxXvuMULWPyD2yGEYbLydu QQynSkB18OzTxNtwZYEBV7y7Qe69vZBFa0jfd4kH+zLk6lbmyHLFKn8smnFVQdby uaFGynpX5faYTeY7ccBUkeveBJMUJcomDlzJZ6XbsmSvaDgX1aPJNkkOzirr8L/5 ilSzydrtifmrvkBcvcesPwEwqHp9xMExYazM7Nz1iLhqafYZHMOiwFnQDF9Tn0cW mTIEzqz5Jbk9LoBxNMxfcPAd6XHGK/zntUbNhxDGNqgnYHjeWhIKWNj6qAP8yKPp 8W1loXMoKyHeE1A4d7ILJNYczYoGz5V2QlfXgHnWgwzrATDmqs6RHmhHM4BNKYTl AQAMili65MdULWwkKjtDHube8UVxLyKxkLgfRChSrXq8mkhSb9zRyqthv5z87G84 pKeiy92TXxkV/KZfWyMX8naYnnckcA9x4FS7tLZGqPN6fqRpUNW8XM3snaW99Jbk GqlCpE1XkQXDhdb3TPd8Uo3FQAVbgce9tmec99HGhWpBrMtay4N7p1xLUQG/mbNM uyrGcXtiLlGefQ== =iA8K -END PGP SIGNATURE-
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)
On Tue, 2021-07-20 at 21:13 -0400, Polyna-Maude Racicot-Summerside wrote: > Ended up with a 3 month useless discussion regarding if this would > give > a bad impression, that we need to use node for doing development. > Later on I was working on a plugin that treated huge amount of data. > So > I introduced Vue.JS, again a three month discussion with people > saying > it's a overhead, even after explaining that you can't always do > server > side processing and serve all the data at a time. Even if people > didn't > understand a word about the global concept and the system as a whole, > they halted the project. > So I just let go my participation. > Now 4 years later, they are integrating Vue.JS and Node doing code > validation while development. > > One of the main reason some people don't want to invest time in FOSS > project is exactly because of that type of toxic situation that make > everyone look like crazy nut head. I find it pretty crazy that you think FOSS is toxic, when in reality the only toxic thing about this situation was when you labeled a discussion as "useless". They didn't want to use your technology stack four years ago. Now they do. Throwing a temper tantrum when you don't get your way isn't doing anyone else any favors. P.S. You may be the biggest hippocrit in these mailing lists. -- BT signature.asc Description: This is a digitally signed message part
Re: Regarding the new "Debian User Repository"
On Mon, Jul 05, 2021 at 12:44:15AM -0500, Hunter Wittenborn wrote: >> By the way, how many users do you currently have? > >At the time of checking there's 46 registered users. > >There's also a counter on the DUR website (bottom-right corner) that displays >the amount of users. Thanks, I haven't viewed the site yet. :) Thanks for coming to the appropriate channel to discuss this and take care of the legal side of things. -- Best regards, Brian T B.S. Computer Science 2014 (Truman State University) Minor Stasitics Minor Chemistry Minor Mathematics signature.asc Description: PGP signature
H Fcc can
Hahn Hjhhjhj Hggghhcbc Gvv cvgggyvt Gydjsjsjsnsndnsjdjdjjdj Shdhdjsjjsjdjdjsjjjdj Hdjxjv Sent from my iPhone
RE: Debian Installer Bullseye RC 1 release
Looks to be fixed now. -Brian Best regards, Brian Thompson From: Andrew M.A. CaterSent: Friday, April 23, 2021 3:46 AMTo: debian-devel-annou...@lists.debian.orgCc: debian-b...@lists.debian.orgSubject: Re: Debian Installer Bullseye RC 1 release Unfortunately, the website links to media still only point to the Alpha-3 release :( All best, Andy C
RE: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)
> Is it really still an open question whether Debian is a political> project that has opinions on non-technical topics like the board of the> FSF or the legal status of Taiwan, Palestine and Kosovo, or whether> Debian is a technical project where people of diverse backgrounds and> political opinions can work together on making a good distribution? I'm very new to the project, but for those who were unaware of this discussion, it makes the project a lot less appealing to contribute to upon hearing about it. It doesn't make any sense for a "FOSS" project to have any weight whatsoever on political on goings. To put it bluntly, political opinion shouting is repulsive, and very disappointing at best. I can probably safely say that many people who are a part of this project already work for the elite IT companies who push their garbage political agendas all day, every day. The last thing people want to do is contribute to a project in their free time that does the same thing. -Brian Thompson Best regards, Brian Thompson From: Donald NorwoodSent: Sunday, April 18, 2021 5:54 PMTo: Adrian Bunk; debian-devel@lists.debian.orgSubject: Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result) On 4/18/21 9:56 AM, Adrian Bunk wrote: > Is it really still an open question whether Debian is a political> project that has opinions on non-technical topics like the board of the> FSF or the legal status of Taiwan, Palestine and Kosovo, or whether> Debian is a technical project where people of diverse backgrounds and> political opinions can work together on making a good distribution?Excellent question. From some online postings I have read and emails I have received on thetopic, there is a growing consensus that Debian on a whole is movingfrom a quality software development organization to yet another angrypolitical leveraging machine. So on this I would say perhaps that is a valid question to put forth andto seek dialog and answers on. People on the outside are confused on thematter, and I would put forth maybe a few on the inside as well. Be well, -Donald-- ---⢀⣴⠾⠻⢶⣦⠀⣾⠁⢠⠒⠀⣿⡁ Donald Norwood⢿⡄⠘⠷⠚⠋⠀ B7A1 5F45 5B28 7F38 4174⠈⠳⣄ D5E9 E5EC 4AC9 BD62 7B05
Re: Problems uploading libpsm2
Hi Adam, On Thu, Aug 6, 2020 at 4:00 PM Adam D. Barratt wrote: > > On Thu, 2020-08-06 at 15:48 -0500, Brian Smith wrote: > > The upload succeeds. I see the files sitting in > > ftp://ftp.upload.debian.org/pub/UploadQueue/. Eventually, I see the > > .changes file disappear and the remaining files are: > > > > libpsm2_11.2.185-1.debian.tar.xz > > libpsm2_11.2.185-1.dsc > > libpsm2_11.2.185-1_amd64.buildinfo > > libpsm2_11.2.185.orig.tar.gz > > > > These seem to hang around until something decides to delete them. > > The logs on the upload side say: > > Aug 5 23:57:30 processing /libpsm2_11.2.185-1_amd64.changes > Aug 5 23:57:30 GnuPG signature check failed on > libpsm2_11.2.185-1_amd64.changes > Aug 5 23:57:30 /libpsm2_11.2.185-1_amd64.changes has bad PGP/GnuPG signature! > Aug 5 23:57:30 Removing /libpsm2_11.2.185-1_amd64.changes, but keeping its > associated files for now. > Aug 6 19:07:13 processing /libpsm2_11.2.185-1_amd64.changes > Aug 6 19:07:13 GnuPG signature check failed on > libpsm2_11.2.185-1_amd64.changes > Aug 6 19:07:13 /libpsm2_11.2.185-1_amd64.changes has bad PGP/GnuPG signature! > Aug 6 19:07:13 Removing /libpsm2_11.2.185-1_amd64.changes, but keeping its > associated files for now. > Aug 6 20:02:18 processing /remove-libpsm2.commands > Aug 6 20:02:18 GnuPG signature check failed on remove-libpsm2.commands > Aug 6 20:02:18 /remove-libpsm2.commands has bad PGP/GnuPG signature! > Aug 6 20:02:18 Removing /remove-libpsm2.commands > > The .changes file has been removed, as per the logs, but the .dsc > appears to be signed by a key that is not the one you have in the DM > keyring. > > > I don't receive any email notifications from Debian FTP Masters, > > regarding the accept/reject of the source or any other > > acknowledgement. > > You won't receive notifications about signature verification failures, > because there's no way for the infrastructure to verify who should be > notified. > Thank you for the analysis. The signing key is new, as of yesterday, due to the expiration of my previous signing key. The new subkey 0x93FF37DA54760549 was pushed to keyring.debian.org, but I guess I will have to wait for the monthly update before I can upload. Thanks, again. > Regards, > > Adam > -- Brian T. Smith System Fabric Works Senior Principal Engineer bsm...@systemfabricworks.com GPG Key: 0xB3C2C7B73BA3CD7F
Problems uploading libpsm2
Greetings, I've been banging my head against the wall for the past two days trying to get libpsm2 uploaded to anonymous-ftp-master. Despite being a DM on this package for the past two years, I'm totally stumped. I used the following dupload command: dupload --to anonymous-ftp-master libpsm2_11.2.185-1_amd64.changes The upload succeeds. I see the files sitting in ftp://ftp.upload.debian.org/pub/UploadQueue/. Eventually, I see the .changes file disappear and the remaining files are: libpsm2_11.2.185-1.debian.tar.xz libpsm2_11.2.185-1.dsc libpsm2_11.2.185-1_amd64.buildinfo libpsm2_11.2.185.orig.tar.gz These seem to hang around until something decides to delete them. I don't receive any email notifications from Debian FTP Masters, regarding the accept/reject of the source or any other acknowledgement. 16 hours have passed since my first attempt. https://ftp-master.debian.org/dm.txt indicates that I have upload permission for libpsm2. Does anyone have an idea as to what is going on? Thanks. -- Brian T. Smith System Fabric Works Senior Principal Engineer bsm...@systemfabricworks.com GPG Key: 0xB3C2C7B73BA3CD7F
Re: Problems uploading libpsm2
Sorry, I fat-fingered a hot-key and the email went merrily on its way. To continue... I used the following dupload command: dupload --to anonymous-ftp-master libpsm2_11.2.185-1_amd64.changes The upload succeeds. I see the files sitting in ftp://ftp.upload.debian.org/pub/UploadQueue/. Eventually, I see the .changes file disappear and the remaining files are: libpsm2_11.2.185-1.debian.tar.xz libpsm2_11.2.185-1.dsc libpsm2_11.2.185-1_amd64.buildinfo libpsm2_11.2.185.orig.tar.gz These seem to hang around until something decides to delete them. I don't receive any email notifications from Debian FTP Masters, regarding the accept/reject of the source or any other acknowledgement. 16 hours have passed since my first attempt. https://ftp-master.debian.org/dm.txt indicates that I have upload permission for libpsm2. Does anyone have an idea as to what is going on? Thanks. On Thu, Aug 6, 2020 at 3:23 PM Brian Smith wrote: > > Greetings, > > I've been banging my head against the wall for the past two days > trying to get libpsm2 uploaded to anonymous-ftp-master. Despite having > been a DM on this package for the past two years, I'm totally stumped. > > First and foremost, I use dupload > > -- > Brian T. Smith > System Fabric Works > Senior Principal Engineer > bsm...@systemfabricworks.com > GPG Key: 0xB3C2C7B73BA3CD7F -- Brian T. Smith System Fabric Works Senior Principal Engineer bsm...@systemfabricworks.com GPG Key: 0xB3C2C7B73BA3CD7F
Problems uploading libpsm2
Greetings, I've been banging my head against the wall for the past two days trying to get libpsm2 uploaded to anonymous-ftp-master. Despite having been a DM on this package for the past two years, I'm totally stumped. First and foremost, I use dupload -- Brian T. Smith System Fabric Works Senior Principal Engineer bsm...@systemfabricworks.com GPG Key: 0xB3C2C7B73BA3CD7F
Remove
-- Best Regards, Brian Samson Please excuse any typos as this was sent from my mobile phone.
Re: Congratulations BRIAN , Your Roof is Covered. Thank You!4Yq7
By the way, What I have in mind of this case, is to make sure that as many people as can be warned of this attempt on the lives of our Americans, are warned of the nature of these peoples own religions deranged atmosphere that is created within the institutional environment. I mean, I have only a problem of a sleep apnea, and I believe even this problem has a lot to do with this case, gone without justice in our country. It has been a very, very serious development for me to handle when our own governing body runs derelict to the laws set aside for their own inclusion. This is an attempted murder by medical instrumentation, one of which I would had never thought could had been made available as a weapon against me. 1.4 million people have died at the rate of 40 to 50 thousand at a time yearly of this cancerous plague in America, and I believe with all my heart that bringing this history out will go above and beyond a normal citizens responsibility. But it is so important that I cant get my normal sleep patterns back in order, until this thing gets the reporting required of the harboring of these criminals that I am positive they know that is going on, by my own reporting anyway. Again, thanks for anything you can do to make this aware of our responsibilities to God and our country. Brian On Sun, Jul 21, 2019 at 3:47 PM Brian Bushart wrote: > Hi Debian; > Yes, I will be happy to take more of the content out for you to further > clear-up the vague (hidden) declusion by our governments effort to cover > this story up. Right now, I am in the middle of a move and it will be > difficult to get to until I am settled once again. I have to re-up the > internets entry at my new place, and have a lot to do to make it a home. > But during the evenings I should be available to get as much of the daily > journals inclusion that I have still been taking down, in order for > everyone to know of this kind of Jihadist development at our hospitals. > Last place any of us would expect of our own normalcy that something like > this could take place. If you can bear with me for a short time, I will > run more of the truthful history of what has occurred to you at this > address. Okay with you? Thanks for your concern,Brian > > On Mon, Feb 13, 2017 at 5:06 PM Brian Bushart > wrote: > >> Considering all that has gone on over thsere where you live, and where my >> own origins go back to; I was curious to know if you plan to assist with >> getting out the news which is vital to all of the worlds peoples of the >> horrific inclusion of genocidal medical inclusion in America. This, as a >> device for governments to cover-up there own criminal inclusion to the laws >> not just set aside for our own countries, but also the laws which even >> still are understood for the world, brought to us by the peaceful people in >> Geneva. Another of my own relatives inclusive variations of which I remain >> proud of. >> What exactly do you have in mind by sending me this email? Of which, of >> its meaning, is rather vague of its contents inclusion, Can you reach me >> again with more substance of your own content? >> >> Thanks >> Brian >> >> >> abb. sum. of life story >> <https://drive.google.com/file/d/0By2BwQ1HUY_1SjVfMXJZcEMtbDFfQWlON0g4S2lMRnhzZjkw/view?usp=drive_web> >> >> High crime criminal governing and allowance of ... >> <https://docs.google.com/document/d/1nHKcReCf4DhqL5S-zvZp4gW-X9N3tbR6CB5IX48I4Ck/edit?usp=drive_web> >> >> The Derelict Plagues >> <https://docs.google.com/document/d/1No_2UW4knSKV5if18J2uRonm6DXvuu9NqKSjrs5TehE/edit?usp=drive_web> >> >> >> On Sun, Feb 12, 2017 at 12:34 PM, Wookey wrote: >> >>> dfh C0ngratuIatl0n >>> >>> _The_Home_Warranty_Limited_time_event_ >>> >>> _Never_pay_for_covered_home_repairs_again!_ >>> >>> _Click_Here_ >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> <http://photonics.com/Clickthru.aspx?CT=CIEW&MemberID=0&IEID=2551&URL=http%3A%2F%2Fleakforum.ml/H59N12.psd>__If_You_Wish >>> _To_UnSubscribe_From_Future_Mailings_Please_Click_Here__ >>> >>> <http://photonics.com/Clickthru.aspx?CT=CIEW&MemberID=0&IEID=2551&URL=http%3A%2F%2Fleakforum.ml/N243TR.psd>0_p_t_0_u_T_ >>> >>> <http://photonics.com/Clickthru.aspx?CT=CIEW&MemberID=0&IEID=2551&URL=http%3A%2F%2Fleakforum.ml/2WGOJX.psd> >>> asdf >>> asdf >>> #^#$^^&(^&(^&(^&%^#$%#&%^&$%%@^&%^&$#%#%^&$%^$%& >>> >>> >>> asdf >>> asdf >>> #^#$^^&(^&(^&(^&%^#$%#&%^&$%%@^&%^&$#%#%^&$%^$%& >>> >>> >>
Re: Congratulations BRIAN , Your Roof is Covered. Thank You!4Yq7
Hi Debian; Yes, I will be happy to take more of the content out for you to further clear-up the vague (hidden) declusion by our governments effort to cover this story up. Right now, I am in the middle of a move and it will be difficult to get to until I am settled once again. I have to re-up the internets entry at my new place, and have a lot to do to make it a home. But during the evenings I should be available to get as much of the daily journals inclusion that I have still been taking down, in order for everyone to know of this kind of Jihadist development at our hospitals. Last place any of us would expect of our own normalcy that something like this could take place. If you can bear with me for a short time, I will run more of the truthful history of what has occurred to you at this address. Okay with you? Thanks for your concern,Brian On Mon, Feb 13, 2017 at 5:06 PM Brian Bushart wrote: > Considering all that has gone on over thsere where you live, and where my > own origins go back to; I was curious to know if you plan to assist with > getting out the news which is vital to all of the worlds peoples of the > horrific inclusion of genocidal medical inclusion in America. This, as a > device for governments to cover-up there own criminal inclusion to the laws > not just set aside for our own countries, but also the laws which even > still are understood for the world, brought to us by the peaceful people in > Geneva. Another of my own relatives inclusive variations of which I remain > proud of. > What exactly do you have in mind by sending me this email? Of which, of > its meaning, is rather vague of its contents inclusion, Can you reach me > again with more substance of your own content? > > Thanks > Brian > > > abb. sum. of life story > <https://drive.google.com/file/d/0By2BwQ1HUY_1SjVfMXJZcEMtbDFfQWlON0g4S2lMRnhzZjkw/view?usp=drive_web> > > High crime criminal governing and allowance of ... > <https://docs.google.com/document/d/1nHKcReCf4DhqL5S-zvZp4gW-X9N3tbR6CB5IX48I4Ck/edit?usp=drive_web> > > The Derelict Plagues > <https://docs.google.com/document/d/1No_2UW4knSKV5if18J2uRonm6DXvuu9NqKSjrs5TehE/edit?usp=drive_web> > > > On Sun, Feb 12, 2017 at 12:34 PM, Wookey wrote: > >> dfh C0ngratuIatl0n >> >> _The_Home_Warranty_Limited_time_event_ >> >> _Never_pay_for_covered_home_repairs_again!_ >> >> _Click_Here_ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> <http://photonics.com/Clickthru.aspx?CT=CIEW&MemberID=0&IEID=2551&URL=http%3A%2F%2Fleakforum.ml/H59N12.psd>__If_You_Wish >> _To_UnSubscribe_From_Future_Mailings_Please_Click_Here__ >> >> <http://photonics.com/Clickthru.aspx?CT=CIEW&MemberID=0&IEID=2551&URL=http%3A%2F%2Fleakforum.ml/N243TR.psd>0_p_t_0_u_T_ >> >> <http://photonics.com/Clickthru.aspx?CT=CIEW&MemberID=0&IEID=2551&URL=http%3A%2F%2Fleakforum.ml/2WGOJX.psd> >> asdf >> asdf >> #^#$^^&(^&(^&(^&%^#$%#&%^&$%%@^&%^&$#%#%^&$%^$%& >> >> >> asdf >> asdf >> #^#$^^&(^&(^&(^&%^#$%#&%^&$%%@^&%^&$#%#%^&$%^$%& >> >> >
re: ITP #919508 warewulf, naming
Greetings, I recently created BTS #91508 "ITP: warewulf -- systems management suite for Linux clusters" and have a question about package naming. Upstream uses the name "warewulf3" as its git repository name. However, the software uses warewulf in its paths, such as /var/lib/warewulf. It doesn't seem like this software is designed to coexist with a different version of itself (e.g. warewulf4). That could be changed, but would be more invasive than I would expect while packaging software for Debian. Thus, it seems to me that the source package name and binary package name prefix should be "warewulf", not "warefulf3". I appreciate any input on this topic. -- Brian T. Smith System Fabric Works Senior Technical Staff bsm...@systemfabricworks.com GPG Key: 0xB3C2C7B73BA3CD7F
Bug#919508: ITP: warewulf -- systems management suite for Linux clusters
Package: wnpp Severity: wishlist Owner: "Brian T. Smith" X-Debbugs-CC: debian-devel@lists.debian.org, debian-...@lists.debian.org * Package name: warewulf Version : 3.8.1 Upstream Author : Gregory M. Kurtzer * URL : https://warewulf.lbl.gov/ * License : BSD-3-Clause-like Programming Lang: Perl, Bourne, Bash Description : Systems management suite for Linux clusters Warewulf is an operating system management toolkit designed to facilitate large scale deployments of systems on physical, virtual and cloud-based infrastructures. It facilitates elastic and large deployments consisting of groups of homogenous systems. Compute nodes are managed via the warewulf suite that is installed to a head node. The head node executes services used to provision the operating system to compute nodes, which execute an iPXE agent. The essential services are tftpd, dhcpd, httpd and nfsd. Warewulf consists of a set of scripts which automate configuration of these services via a command-line interface. The upstream Warewulf source package includes embedded source tarballs for parted, ipxe, e2fsprogs, busybox, libarchive and unionfs. Thus, the upstream builds include binary code for these packages that are already available for Debian. A goal of this project is to remove these embedded packages from the build and ship packages that target the "all" architecture. Warewulf's upstream build also includes packaging of a compute node initrd image, created from the embedded packages. The Debian package will not include an initrd image. Rather, a script to create the initrd image via mkinitramfs and custom hooks will be used by the administrator to build the compute node initrd image after installing warewulf to the head node. This technique has the benefit of easing an administrator's task of updating the initrd image, when necessary. Warewulf is used by administrators who need to manage clusters of linux computers, and also by those who need to deploy operating system images over a LAN. I use it in my development environment for these purposes. I plan to maintain Warewulf within the debian-hpc team, of which I am a member. As my role is Debian Maintainer, the initial upload will require assistance from a sponsor.
opa-ff patch-queue
Greetings, I've been looking into updating opa-ff to the upstream 10.8.0.0.201 release and have some questions about the patch-queue process specified in d/README.source, which references DEP-14. The document states that the upstream tag should be merged to the patch-queue/debian/master branch. However, after doing that and executing gbp pq export, it generates a patch that upgrades the source to the latest version, since gbp-pq sees the merge commit. The process I've found that "works" is: 1) Merge the upstream tag to debian/master. 2) Refresh the existing patches and fix any conflicts. 3) Execute gbp pq switch. At this point, debian/master is merged to patch-queue/debian/master. patch-queue/debian/master now contains d/patches and each patch has to be applied and the changes committed to git. Also, it appears that the patch-queue/debian/master branch was dropped and recreated by the gbp-pq export command, as the previous commits to that branch are now removed. I stopped here, as this didn't really feel quite right. There doesn't appear to be a lot of supporting documentation for the gbp pq workflow. Can someone point me to a document or clarify how this process is supposed to work, regarding the rebase of the patch-queue branch to the latest release and exporting the updated patches? -- Brian T. Smith System Fabric Works Senior Technical Staff bsm...@systemfabricworks.com GPG Key: 0xB3C2C7B73BA3CD7F
Bug#898065: general: Since linux-headers-4.9.0-6-amd64:amd64, Intel HD 3000 gives lower resolution
Hi, Can you cancel this please? It might have been a once off, it got fixed with reinstalling grub. Sorry for wasting your time if it wasn't a bug. Thanks for all your work, Brian On 06/05/18 16:40, Brian wrote: > Package: general > Severity: normal > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? > Normal system update: > > user@debian:~$ less /var/log/apt/history.log > Start-Date: 2018-05-02 12:11:40 > Commandline: apt upgrade > Upgrade: linux-libc-dev:amd64 (4.9.82-1+deb9u3, 4.9.88-1), linux-libc-dev:i386 > (4.9.82-1+deb9u3, 4.9.88-1), linux-headers-4.9.0-6-amd64:amd64 > (4.9.82-1+deb9u3, 4.9.88-1), linux-compiler-gcc-6-x86:amd64 (4.9.82-1+deb9u3, > 4.9.88-1), linux-kbuild-4.9:amd64 (4.9.82-1+deb9u3, 4.9.88-1), linux- > image-4.9.0-6-amd64:amd64 (4.9.82-1+deb9u3, 4.9.88-1), linux- > headers-4.9.0-6-common:amd64 (4.9.82-1+deb9u3, 4.9.88-1) > End-Date: 2018-05-02 12:38:46 > >* What exactly did you do (or not do) that was effective (or > ineffective)? >* What was the outcome of this action? >* What outcome did you expect instead? > > *** End of the template - remove these template lines *** > > > > -- System Information: > Debian Release: 9.4 > APT prefers stable > APT policy: (1001, 'stable'), (500, 'stable-updates'), (500, 'stable-debug') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), > LANGUAGE=en_IE:en (charmap=UTF-8)
Planning the removal of c_rehash | mass bug filling
> Hi, > > the openssl package provides the c_rehash script which creates the links > from .Y to the actual certificate in /etc/ssl/certs/. During the > transition from 0.9.8 to 1.0.0 the hash (for the X part) changed from > md5 to sha1. Since that transition in Debian the c_rehash script > provides both symlinks: the old hash (md5) and the new (sha1) one. > > The c_rehash script is considered by upstream as a fallback script and > will disappear at some point. The recommended way is to use the "openssl > rehash" command instead which appeared in 1.1.0. This command creates > half that many symlinks (one per certificate instead of two) because it > uses only the sha1 hash. There is also the -compat option which creates > both symlinks (and behaves like c_rehash currently does) but as > explained above it should not be required to use it. I thought it was worth mentioning that the behavior of 'openssl rehash' when encountering a duplicate certificate was to return 1 while 'c_rehash' would return 0. I say was because I filed an upstream bug[1] about it which was resolved. This difference in behavior resulted in the following Debian and Ubuntu bug reports. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895473 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895482 https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1764848 We've gone ahead and patched openssl in Ubuntu for the 18.04 release but it would be good to get openssl updated in Debian. [1] https://github.com/openssl/openssl/issues/6083 Thanks! -- Brian Murray
Re: (solved) Re: wireless fail after stretch installation
At some point Jude DaShiell Cc'ed -devel. This accounts for some of the
traffic in this thread. I am also Cc'ing -devel. You didn't, but I am
not trimming any of your post; nor am I replying to every portion in
it.
On Sat 10 Mar 2018 at 09:53:58 -0600, David Wright wrote:
> On Wed 07 Mar 2018 at 13:25:16 (+), Ian Jackson wrote:
> > bw writes ("Re: (solved) Re: wireless fail after stretch installation"):
> > > On Tue, 6 Mar 2018, Brian wrote:
> > > > One user calls it a "sick joke". After five years and with no attempt
> > > > to rectify the situation, I'm beginning to have sympathy with that view.
> >
> > Debian, like all ordinary software, is full of bugs. Many bugs
> > languish unfixed for years. This is not malice, or a "sick joke".
> > It's just that there is too much to do and too few people to do it.
>
> I'm afraid I've been misquoted. The exchange was (my lines are marked ★):
>
> --✄
>
> > How connectivity is re-established on a machine with only a wireless
> > interface is left as an exercise for the user.
>
> This is some sort of sick joke. ★
>
> --✄
>
> https://lists.debian.org/debian-user/2018/02/msg00015.html
Many apologies for quoting out of context.
> > There are rare cases where horrible people deliberately sabotage
> > things. They are very high profile because they are so outrageous,
> > but they are not the norm. I see no evidence in relation to this bug
> > that anyone is sabotaging anything.
>
> I made no accusations of sabotage. Again:
>
> --✄
>
> > > > So this must be intentioal, wouldn't you say?
> > >
> > > No. ★
>
> […]
>
> > > > And this is also clearly intentional.
> > >
> > > Intended to do what? ★
> >
> > To leave the user without network connectivity after first boot? There
> > are at least three bug reports against netcfg on the matter. My
> > recollection is that no deeper intention is revealed there.
>
> […]
The word "deliberately" was picked up and labelled as giving the message
an unfortunate tone and then linked with "deliberately breaking stuff".
A deliberate action need not be done with malice and there was nothing
in what I said which put ill-intent forward as a reason.
> Yes, I don't think the intentions are deeper, but just that simple ★
> cases have been overlooked, and overlooked for several years. ★
>
> --✄
>
> The thing that seemed odd to me when I examined the log was that the
> installer removed the wireless configuration right at the last moment,
> with no method of circumventing it.
>
> On discovering the udeb package called netcfg and looking through its
> bugs, it seemed that the network connection was torn down (with good
> reason, to do with DHCP leases perhaps) but then the configuration
> itself was also torn down, and this was considered a good thing for
> reasons I couldn't fathom, and which seemed to forget the case of a
> wireless interface and its intended future use of ifupdown with /e/n/i
> after rebooting.
>
> > The correct approach to this bug is to figure out how to fix it, and
> > send a patch.
> >
> > > Brute forcing this thing with wifi to /e/n/i might not be the best
> > > approach? What about people who want a different config than the
> > > installer? What about people who don;t want to be UP (auto) on bootup?
> > > What about static configs? Wifi is by nature a mobile environment, what
> > > about security or several devices? Let's help the devs by hashing out
> > > the
> > > pros and cons and making a coherent proposal?
> >
> > We are considering the situation where the user has installed a
> > barebones system, with no GUI network management tools.
> >
> > Such a user will probably *expect* to edit a configuration file when
> > they want to change their network configuration, whether because their
> > needs change, or because their needs are different to those of the
> > majority of people.
> >
> > Consequently, there is no problem in principle with setting up /e/n/i
> > to have the wifi configuration from the install. That is what most
> > people who do this will want; and if it doesn't suit them, they can
> > change it. (It is easier to change it or delete it, than it is to set
> > it up from scratch.)
>
> Yes, that's just what I had originally expected, and would be great.
>
> > AFAICT from reading #694068, the reason d-i currently strips this
>
Re: (solved) Re: wireless fail after stretch installation
On Tue 06 Mar 2018 at 18:34:27 +, Ian Jackson wrote:
> bw writes ("Re: (solved) Re: wireless fail after stretch installation"):
> > I think the idea needs to be talked over a little better, because using
> > e/n/i for wireless by default after first boot has implications if the
> > user (who is clueless) later installs a desktop environment.
>
> If installing a desktop environment, after putting the wireless in
> /e/n/i, does not work, then that is a bug in the desktop environment,
> surely ?
Most probably. But desktop environments were not the subject of this
thread. (Sorry for trying to keep on-topic).
> In practice I would expect the config in /e/n/i to keep working
> because nowadays network-manager will ignore things in /e/n/i. The
> difficulty would only come if you
> - used the installer to install a bare system over wifi
That difficulty is exactly the subject of this thread. The rest of this
post is snipped because it side-steps addressing the issue. What is put
in /e/n/i ceases to work because it is obliterated by the installer for
reasons unknown.
One user calls it a "sick joke". After five years and with no attempt
to rectify the situation, I'm beginning to have sympathy with that view.
(Yes, I know we are all volunteers).
--
Brian.
> - later install network-manager or wicd
> - then expect the system to give you a gui prompt for new wifi
> networks, rather than expect to have to edit /e/n/i
>
> It would be possible for the n-m and wicd packages to spot when this
> is happening and offer to take over the interface. And I do think
> that in the absence of code to do that, it would be more important to
> make the barebones system work in the first place, than to improve the
> behaviour you later install n-m.
>
> (I'm not sure if what I say about wicd is right. I use n-m on
> machines I have where the user needs to switch between various network
> connections, wifi networks, etc.)
>
> > I'd hate to see the bug tracker turned into a discussion forum though.
>
> The bug tyracker is precisely the right place to discuss how to solve
> a particular bug. So I have CC'd it.
>
> Ian.
>
> --
> Ian JacksonThese opinions are my own.
>
> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
> a private address which bypasses my fierce spamfilter.
>
Re: (solved) Re: wireless fail after stretch installation
On Tue 06 Mar 2018 at 18:27:29 +, Ian Jackson wrote:
> Brian writes ("Re: (solved) Re: wireless fail after stretch installation"):
> > #694068, #696755, #727740 and #777439.
>
> Thanks.
>
> I have read the bug logs and Trent Buck's message here
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694068#47
> seems to suggest a way forward.
>
> Perhaps someone would care to write and test a patch to d-i's network
> configuration arrangements, to implement Trent's suggestion ? I think
> that the people who don't have network-manager would probably prefer
> this to use ifupdown, and making a whole new udeb will be work, so
> Trent's second suggestion seems sensible.
I would hazard a guess and say that 100% of users would expect to be
able to use the network they have set up during installation, afterwards.
Without an ethernet interface on the machine it becomes resorting to
setting it up again (5%), resorting to -user or the internet from
another machine (20%) or some head-scratching followed by walking away.
(The percentages are rough estimates).
> > > > The plain and simple fact is that a user who installs over a wireless
> > > > link and does not have network-manager does not have any connectivity
> > > > to the internet after first boot. Long Wind solved the issue by taking
> > > > the advice given and Charlie S used his initiative and knowledge to
> > > > devise an /e/n/i file which replaced the one the installer had wiped
> > > > out.
> > > >
> > > > This has been going on since Debian 7.0.0 and is not the first time the
> > > > issue has arisen here. Debian must be the only OS which deliberately
> > > > removes connectivity present during installation.
>
> I have to say that the tone of this message is rather unfortunate.
> You make it sound like someone is deliberately breaking stuff. That
> doesn't seem to be the case.
The message was written to -user. Besides having a really helpful bunch
of users, there can sometimes be a robustness and directness to the
exchanges. Don't let it put you off if you are used to a more gentile
environment.
I hadn't realised the breakage was accidental and unplanned. OTOH, I am
not in possession of the reasons behind it; apart from some conjecture,
they still remain unknown. As you will see from the bug record, even
Debian developers are mystified.
> Comparing to other distros can be very helpful but generalised
> statements that they don't have this bug is less useful than looking
> into how they solve the problem.
We don't know what the problem is.
--
Brian.
Re: (solved) Re: wireless fail after stretch installation
On Tue 06 Mar 2018 at 15:01:03 +, Ian Jackson wrote:
> Brian writes ("Re: (solved) Re: wireless fail after stretch installation"):
> > The plain and simple fact is that a user who installs over a wireless
> > link and does not have network-manager does not have any connectivity
> > to the internet after first boot. Long Wind solved the issue by taking
> > the advice given and Charlie S used his initiative and knowledge to
> > devise an /e/n/i file which replaced the one the installer had wiped
> > out.
> >
> > This has been going on since Debian 7.0.0 and is not the first time the
> > issue has arisen here. Debian must be the only OS which deliberately
> > removes connectivity present during installation.
>
> Can someone point me to the bug report about this ?
>
> Ian.
#694068, #696755, #727740 and #777439.
--
Brian.
Re: (solved) Re: wireless fail after stretch installation
On Sun 04 Mar 2018 at 19:10:02 +0100, Philip Hands wrote: > Jude DaShiell writes: > > > The least debian-boot membership could do would be to have a note come > > up for installers to execute a shell and do the file copy before > > rebooting once hard drive got mounted. This is a problem for wifi users > > with no impact for ethernet users. > > Your tone does not encourage a civil response, but you're going to get > one anyway I'm afraid. > > Since you didn't bother to say what you are complaining about in any > useful way, I thought I'd look at the first post in the first thread > referred to in the mail from Brian, which is about the fact that > desktop-configured wifi connections don't come up until someone logs in. You would have done better to have read further and, amongst other posts which are pertinent to what Long Wind and Charlie S wrote, you would have found this: https://lists.debian.org/debian-user/2018/02/msg00015.html The plain and simple fact is that a user who installs over a wireless link and does not have network-manager does not have any connectivity to the internet after first boot. Long Wind solved the issue by taking the advice given and Charlie S used his initiative and knowledge to devise an /e/n/i file which replaced the one the installer had wiped out. This has been going on since Debian 7.0.0 and is not the first time the issue has arisen here. Debian must be the only OS which deliberately removes connectivity present during installation. In the link above David Wright asks whether this is a "sick joke". If the reasons for inflicting this issue on users were explained in some detail, we could perhaps answer sensibly. [Snip. The issue in this thread has nothing to do with an installed network-manager.] -- Brian.
Bug#881220: ITP: qperf -- Measure socket and RDMA performance
Package: wnpp Severity: wishlist Owner: "Brian T. Smith" * Package name: qperf Version : 0.4.9 Upstream Author : Johann George * URL : http://www.openfabrics.org * License : GPL, BSD Programming Lang: C Description : Measure socket and RDMA performance qperf measures bandwidth and latency between two nodes. It can work over TCP/IP as well as the RDMA transports. - qperf is a widely-used tool for testing performance of RDMA stacks and fabrics. - While there is some overlap with iperf3 in the area of TCP performanced testing, iperf3 cannot directly test an RDMA trasport. qperf allows direct testing of UD and RC RDMA. - qperf will be maintained as part of my employer's ongoing project of supporting RDMA functionality on Debian. - I do not yet have Debian maintainer status, and will require a sponsor. - qperf will be included in the software packages maintained by pkg-ofed. - I use qperf on a regular basis to test functionality and performance of RDMA fabrics with the amd64 architecture.
Re: changes to upload queue for security archive
Brian May writes: > Michael Hudson-Doyle writes: > >> Sounds like MTU related fun perhaps? > > Hmmm I am doubtful, however I will conduct some more experiments > tomorrow to test this. Was all set to debug MTU issues today, but found that it is working without problem. Hope it stays this way :-) -- Brian May
Re: changes to upload queue for security archive
Michael Hudson-Doyle writes: > Sounds like MTU related fun perhaps? Hmmm I am doubtful, however I will conduct some more experiments tomorrow to test this. Thanks! -- Brian May
Re: changes to upload queue for security archive
Ansgar Burchardt writes: > the host for the security upload queue changed. The new location is > > ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue For some reason I can't upload to this host (or the old one) from my network without disabling IPv6 first (by overriding the IP address in /etc/hosts). Otherwise I get timeout errors from dput-ng. ping/traceroute works, both over IPv4 and IPv6. Manually connecting to the port seems to work fine too. Any ideas? -- Brian May
Re: Bug#868640: hdb_generate_key_set_password broke ABI
Hello Debian-Devel! I have this tricky situation. It appears in 2011, upstream made a change to Heimdal that broken the shared library ABI, and didn't change the SONAME. === cut === commit af011f57fc4ae6e865bab471c20aa9047e4e19d4 Author: Roland C. Dowdeswell Date: Mon Nov 28 15:18:52 2011 + Provide server side kadm5_chpass_principal_3() with ks_tuple implementation. We enable kadm5_chpass_principal_3() in the server side of the library. The client kadm5 library calls will still return the error KAMD5_KS_TUPLE_NO_SUPP. Signed-off-by: Nicolas Williams === cut === This change was undetected, and included in Debian in Wheezy, Jessie, Stretch. Now Upstream has realized their error. https://github.com/heimdal/heimdal/issues/246 There response was to restore the ABI to the previous state. This change is now in testing and unstable. What should I do? It appears patch the ABI back to the previous state, and break compatability with other distributions. Or I can keep it as it and break upgrades. Please read the bull details of 868640 for more information, and for details of similar situation that occured before the Stretch release. #848694 -- Brian May
Re: Re: Too many Recommends (in particular on mail-transport-agent)
On 2017-06-06 10:37, Jeremy Bicha wrote: > On Mon, Jun 5, 2017 at 8:02 PM, Terry McKenna > wrote: > >> This one may be at the extreme, but it is one I personally encountered. I >> was installing nmap on a system (no gui) and was a bit shocked. The problem >> is well articulated by one post (an my thanks to him for the work around). >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714320#17 > > That particular example appears to have been fixed years ago with > https://bugs.debian.org/682062 714320 [1] was opened in 2013, and people were complaining about 714320 [1] this year. 682062 [2] was opened and closed in 2012. Are people sure that 714320 [1] really is fixed? Also it appears 714320 [1] is marked "unreproducible" and is against the wrong package. If 714320 [1] has been fixed, it should be closed, not marked unreproducible. Links: -- [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714320#17 [2] https://bugs.debian.org/682062
Bug#862754: ITP: libhfi1 -- Userspace driver for Intel Omni-Path fabric interface
Package: wnpp Severity: wishlist Owner: "Brian T. Smith" * Package name: libhfi1 Version : 0.5-23 Upstream Author : Intel Corporation * URL : http://www.intel.com * License : GPL or BSD Programming Lang: C Description : Userspace driver for Intel Omni-Path fabric interface (HFI1). libhfi1 is a device-specific driver for Intel Omni-Path fabric interface hardware for the libibverbs library. This allows userspace processes to access the HFI1 hardware directly with low latency and low overhead. . This package contains the loadable plug-in. . I am an employee of System Fabric Works. SFE has the experience, hardware and resources to maintain and test this package.
Bug#862725: ITP: python-parse-type -- Extends the parse module
Package: wnpp Severity: wishlist Owner: Brian May * Package name: python-parse-type Version : 0.3.4 Upstream Author : Jens Engel * URL : https://github.com/jenisys/parse_type * License : BSD-3-clause Programming Lang: Python Description : Extends the parse module parse_type extends the parse module (opposite of string.format()) with the a number of additional features. This is required for packaging pytest-bdd. See #825071.
Bug#862313: ITP: libpsm2 -- PSM2 runtime, dev and compatibility libraries for Intel Omni-Path
Package: wnpp Severity: wishlist Owner: "Brian T. Smith" * Package name: libpsm2 Version : 4.0 Upstream Author : 01org * URL : https://github.com/01org * License : GPL, BSD Programming Lang: C Description : PSM2 runtime, dev and compatibility libraries for Intel Omni-Path libpsm2 provides the Performance Scaled Messaging API for user-space applications that wish to perform high-bandwidth, low-latency RDMA communications (e.g. openmpi, mvapich2). The predecessor of PSM2 is the PSM API provided by libpsm-infinipath1. Intel Omni-Path hardware and the supporting hfi1 kernel module require use of PSM2. libpsm2 will be able to coexist on a system that has libpsm-infinipath1 installed. It is not a replacement for libpsm-infinipath1. A host that has PSM and PSM2 capable hardware should be able to use either API, depending upon the fabric interface needed for communications. This proposal involves multiple packages: * libpsm2 - runtime libraries for PSM2 * libpsm2-dev - development headers and linker libraries for PSM2 * libpsm2-compat - compatibility library for PSM applications The purpose of libpsm2-compat is to allow a PSM application to use hardware that requires PSM2 (e.g. Intel Omni-Path). An example of such an application is openmpi 1.6.5. By prepending the compatibility library's installation directory to LD_LIBRARY_PATH, a PSM application is able to transparently use the PSM2 API without requiring a code port or recompilation. I have been maintaining the Intel Fabric Suite for Omni-Path on Debian for the past year as an employee of System Fabric Works (SFW). SFW has adequate hardware and resources to test and maintain this package.
Bug#862311: ITP: hfi1-firmware -- non-free firmware for Intel Omni-Path hfi1 fabric interface
Package: wnpp Severity: wishlist Owner: "Brian T. Smith" * Package name: hfi1-firmware Version : 0.9-46 Upstream Author : 01org * URL : https://github.com/01org/opa-firmware * License : Proprietary, non-free Programming Lang: none, binary Description : non-free firmware for Intel Omni-Path hfi1 fabric interface Debian stretch, kernel 4.9.0-2-amd64 includes the hfi1 module that provides kernel-space ibverbs access to Omni-Path hardware for network communications. However, the hfi1 module requires non-free firmware in order for the module to properly initialize. This package will provide the required firmware for hfi1 hardware. The upstream URL contains many firmware images. The only binaries that will be installed by this package are: * hfi1_dc8051.fw * hfi1_fabric.fw * hfi1_pcie.fw * hfi1_platform.dat * hfi1_sbus.fw I have been maintaining the Intel Fabric Suite for Omni-Path on Debian for the past year as an employee of System Fabric Works (SFW). SFW has adequate hardware and resources to test and maintain this package.
Re: policy for shipping sysctl.d snippets in packages?
On 2017-04-27 16:19, Andrey Rahmatullin wrote: It seems you've missed the point (which was about 4 years between RHEL releases). There was almost three years between Woody (July 19th 2002) and Sarge (June 6th 2005), yet we still allowed upgrades from Woody to Sarge. The time duration is irrelevant. It is the policy we have that we support and test upgrades that matters. It is much easier to ignore upgrades and recommend to reinstall from scratch, that means we don't need to test and debug why upgrades break under various corner cases. Not so good for our users however.
Re: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]
On 2017-04-13 10:13, Russ Allbery wrote: > It would be nice if people would stop doing the same thing over and over > again and expecting different results. Maybe this illustrates the core of the problem: https://xkcd.com/242/
Re: Fwd: can anyone review diaspora-installer?
On 2017-04-06 15:47, Pirate Praveen wrote: > Sharing with wider debian community, hoping to get some support. > > Current version in unstable does not have any RC bugs, but recent > changes in the package made release managers not happy with the quality > of the package and it was removed from testing. Now their justification > to not accept unblock request is lack of time to review it before > stretch release. postrm has: id -u diaspora && userdel -r diaspora Where -r == delete all files in the user's home directory. As per: https://sources.debian.net/src/diaspora-installer/0.6.3.0%2Bdebian4/debian/diaspora-common.postrm/ This makes me very very nervous. You have no control over what changes might happen to the home directory. It might not be the directory you expect it to be. Been there myself. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=190427 Far safer to delete the files you need deleted yourself, and remove the "-r" option.
Re: Fwd: can anyone review diaspora-installer?
On 2017-04-06 15:47, Pirate Praveen wrote: > Sharing with wider debian community, hoping to get some support. > > Current version in unstable does not have any RC bugs, but recent > changes in the package made release managers not happy with the quality > of the package and it was removed from testing. Now their justification > to not accept unblock request is lack of time to review it before > stretch release. >From last line of https://release.debian.org/stretch/freeze_policy.html: "After 5th January 2017, removed packages will NOT be permitted to re-enter testing." So you may be out of luck, sorry. One thing that puzzles me though is that the bug was opened at: "Thu, 23 Mar 2017 02:17:28 +0100" and the package was auto removed "Thu, 23 Mar 2017 16:39:09 +" https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858521 https://packages.qa.debian.org/d/diaspora-installer/news/20170323T163909Z.html I thought normally more time was allowed. Is this because the bug was critical? If so, are the times before autoremoval documented anywhere? I asked Google, but Google said "10 days" which may not be up-to-date information: https://lists.debian.org/debian-devel-announce/2013/09/msg6.html
Re: "Ask HN: What do you want to see in Ubuntu 17.10?"
On 2017-04-03 10:10, Russell Stuart wrote: > The first is better HDPI handling. This will require Wayland ... Did I miss something? I thought Ubuntu was doing their own thing and not using Wayland. https://wiki.ubuntu.com/Mir/Spec
Re: System libraries and the GPLv2
Carlos Alberto Lopez Perez writes: > But in the worst case, it will be compatible with GPLv2+ and GPLv3. I am not sure I see this as the worst case situation. Or maybe you meant to write "incompatable"? -- Brian May
Re: Bug#858229: ITP: passh -- passh: a pass fork - stores, retrieves, generates, and synchronizes passwords securely.
Christian Seiler writes: > Specifically take a look at this message from the author of the original > tool: > https://lists.zx2c4.com/pipermail/password-store/2017-February/002799.html > > The fork appears to have happened after that, but wasn't mentioned at > all on the upstream mailing list. "However, the basic ideas seem like good ones, and I'll look into adopting these with a less offensive implementation." Seems like the author liked the concepts behinds the patches, but felt that the patches needed more work. I think I would have started by trying to submit a smaller change (e.g. maybe the first patch in the series). I don't see any response to this email. Doesn't inspire confidence :-( -- Brian May
Bug#858073: apparent freeze when exiting text session on second vt while X is running on first vt
On Sat 18 Mar 2017 at 00:50:51 +0100, Daniel Haid wrote: > Package: general > Severity: important > > Dear Maintainer, > > I do not know under which package this bug should be filed or what additional > information is needed to help solve this. > > I am running Debian stretch and have configured it to give me text consoles on > boot. I have intel graphics and for Xorg I am using the modesetting driver > which has been the default for some time. > > The steps to reproduce the bug are as follows: > > 1) login on first vt. > 2) run "startx" on frist vt. > > X is now running normally. > > 3) Ctrl+Alt+F2 > 4) login on second vt. > > I can use the text console normally. I can also switch back and forth between > the first vt (with X) and the second vt (text console) without problems. > > 5) run "exit" on second vt. > > I now automaticaly see my X session on the first vt again. However, I can not > move the mouse and my keyboard is not working. The system seems to be frozen. > > 6) Alt+F1 > > After typing Alt+F1 in the frozen state, the X server dies and I get back > the text console. I can now start X again. > > Note: If I override the driver by putting Driver "intel" into xorg.conf, > I get the same behaviour except that after Step 6 my screen just turns > black completely. This is the same as #791342. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791342 Does changing if [ "$SHLVL" = 1 ] in ~/.bash_logout to if [ "$SHLVL" = 2 ] alter the behaviour? Cheers, Brian.
Re: Congratulations BRIAN , Your Roof is Covered. Thank You!4Yq7
Considering all that has gone on over thsere where you live, and where my own origins go back to; I was curious to know if you plan to assist with getting out the news which is vital to all of the worlds peoples of the horrific inclusion of genocidal medical inclusion in America. This, as a device for governments to cover-up there own criminal inclusion to the laws not just set aside for our own countries, but also the laws which even still are understood for the world, brought to us by the peaceful people in Geneva. Another of my own relatives inclusive variations of which I remain proud of. What exactly do you have in mind by sending me this email? Of which, of its meaning, is rather vague of its contents inclusion, Can you reach me again with more substance of your own content? Thanks Brian abb. sum. of life story <https://drive.google.com/file/d/0By2BwQ1HUY_1SjVfMXJZcEMtbDFfQWlON0g4S2lMRnhzZjkw/view?usp=drive_web> High crime criminal governing and allowance of ... <https://docs.google.com/document/d/1nHKcReCf4DhqL5S-zvZp4gW-X9N3tbR6CB5IX48I4Ck/edit?usp=drive_web> The Derelict Plagues <https://docs.google.com/document/d/1No_2UW4knSKV5if18J2uRonm6DXvuu9NqKSjrs5TehE/edit?usp=drive_web> On Sun, Feb 12, 2017 at 12:34 PM, Wookey wrote: > dfh C0ngratuIatl0n > > _The_Home_Warranty_Limited_time_event_ > > _Never_pay_for_covered_home_repairs_again!_ > > _Click_Here_ > > > > > > > > > > > > > > > > > > > > > > > > > > > <http://photonics.com/Clickthru.aspx?CT=CIEW&MemberID=0&IEID=2551&URL=http%3A%2F%2Fleakforum.ml/H59N12.psd>__If_You_Wish > _To_UnSubscribe_From_Future_Mailings_Please_Click_Here__ > > <http://photonics.com/Clickthru.aspx?CT=CIEW&MemberID=0&IEID=2551&URL=http%3A%2F%2Fleakforum.ml/N243TR.psd>0_p_t_0_u_T_ > > <http://photonics.com/Clickthru.aspx?CT=CIEW&MemberID=0&IEID=2551&URL=http%3A%2F%2Fleakforum.ml/2WGOJX.psd> > asdf > asdf > #^#$^^&(^&(^&(^&%^#$%#&%^&$%%@^&%^&$#%#%^&$%^$%& > > > asdf > asdf > #^#$^^&(^&(^&(^&%^#$%#&%^&$%%@^&%^&$#%#%^&$%^$%& > >
Re: Feedback on 3.0 source format problems
Nikolaus Rath writes: >> I have had to sort out the mess when the Debian package upload >> did not match my git tree because another maintainer didn't correctly >> merge in my changes. > > I don't understand... how does a Debian package upload affect any of the > work on your git-dpm tree? I can't remember the exact details now. However I suspect that some people get so frustrated with git dpm problems and end up using "git push -f" to fix them up. I think a maintainer may have missed the fact that I had made changes, and did a "git push -f" without noticing he was creating a new fork without my changes. Which caused no end of confusion - I can see my changes in my git tree, but they didn't appear in Debian upload. I think the problems git-dpm can create can result in bad habbits - with people rushing to fix problems without understanding what the underlying cause was, that can lead to this sort of thing. -- Brian May
Re: Feedback on 3.0 source format problems
Vincent Bernat writes: > There have been a lot of complaints about it. For me, it is a pain to > use. Its integration with gbp is poor, it produces a messy history when > you are working on your patches and I often run into problems with > .debian/.git-dpm file it maintains (import a new upstream, make some > changes, notice that somebody else also pushed a change, pull --rebase, > everything is broken). Since we started using it, we opened a lot of bug > reports and not a single one of them has been fixed. I think that nobody > wants to work on it because it is an extremely fragile tool and the > first one to try to fix it will inherit of all the problems to solve. It also has a number of bugs that are not getting fixed. Plus if conflicts occur because multiple people unexpectedly make changes at the same time it (i.e. you can't push because somebody else already pushed changes) can be a world of confusion trying to sort out the mess. I have had to sort out the mess when the Debian package upload did not match my git tree because another maintainer didn't correctly merge in my changes. I believe there is increasing feeling that DPMT should switch away from git dpm. I think at least one project has already done so. Just nobody has raised the issue on the mailing list, or come up with an proposal to change yet. > Isn't "gbp pq" a correct execution of the same principles? No, my understanding that is git pq is something quite different, and does not maintain the history of changes in git - except by commiting the debian/patches/* files. It is a while since I looked at this in depth however. "gbp pq" is probably way better then using quilt however. -- Brian May
Re: DEP 8: Gathering Django usage analytics
Lars Wirzenius writes: > If I understand this correctly, Django wants to gather usage > statistics from installed Django instances, in a way that they say > respects user privacy (though I failed to understand how, given a > quick read). They claim this information gathering is necessary for > them to sustainably get funding for Django development. ... there was a response to this email here: https://github.com/django/deps/pull/31#issuecomment-261181821 Probably better to followup on this pull request as opposed to here, where upstream will read it. -- Brian May
Re: More 5 november in the release schedule
Scott Kitterman writes: > I seem to get email when a package I maintain is marked for autoremoval > (regardless of whether it is an issue with my package or an rdepend). That > and it showing up on your DDPO Packages overview ought to be enough to be > forewarned, I would have thought. That will help in some cases, but not all cases. Can't remember what happened for my particular cases. I should look up the details and refresh my memory, but out of time now. One situation I can think of: If for example the package is not yet in testing, you will not get notified that it depends on a broken package and as such will not get into testing. So you can mistakenly think it is a simple package, it has no bugs, and not realize it isn't in testing. Another situation: You are not listed as the maintainer of the package you really care about, and the real maintainer ignores the autoremoval notifications. Other people looking at the package bug reports (there may be none) may not realize it is pending autoremoval. -- Brian May
Re: More 5 november in the release schedule
Christian Seiler writes: > Why? Any package currently in testing still has time to enter > (until roughly end of this year), so it's not like there is no > heads-up for people. And RC bugs don't lead to immediate > removal from testing, you still have quite a bit of time until > they actually cause removal of a package. The problem is if the maintainer is not responding to RC bug reports, and you don't realize a package you depend on has RC bugs. This happened several times to me during the last freeze. -- Brian May
Re: Request for feedback: systemd backport for jessie
On Tue 05 Jul 2016 at 20:46:07 +0200, Elimar Riesebieter wrote: > Hi Mika, > > * Michael Prokop [2016-07-05 17:34 +0200]: > > > Hi, > > > > here at DebConf I've been working on a backport of systemd for jessie. > > > > If you're interested in all the new features, bugfixes and changes > > that systemd received since its version 215-17+deb8u4 (the one > > available from jessie) you might wanna give it a try. > > > > The backport is based on what will be released as v230-6 for Debian > > unstable soonish. Once systemd v230-6 migrated to testing and if I > > receive enough feedback I'll upload systemd v230-6 officially > > towards jessie-backports then. > > Are you aware of the 'Thinking about a "jessie and a half" release' > thread at debian-devel [0]? > > [0] https://lists.debian.org/debian-devel/2016/07/msg00054.html I am aware of it. What bearing has it on working on providing a backport of systemd for jessie (which I would agree with)? Improving the systemd experience on Jessie can only be for the good of its users.
Re: schroot broken in testing?
Jakub Wilk writes: > #821442 Thanks. I was looking for bugs against schroot, never thought to look at bugs against linux :-( Downgraded my kernel for now, looks like this will get fixed when the latest kernel gets into testing. -- Brian May
Re: schroot broken in testing?
Something wrong maybe with how it is mounted? [brian:/] 1 % schroot --chroot jessie-amd64-sbuild --user=root -bash: /usr/bin/id: Operation not permitted -bash: [: : integer expression expected -bash: /usr/bin/mesg: Operation not permitted (jessie-amd64-sbuild)root@prune:/# [ -bash: [: missing `]' (jessie-amd64-sbuild)root@prune:/# /usr/bin/id -bash: /usr/bin/id: Operation not permitted (jessie-amd64-sbuild)root@prune:/# /usr/bin/id -bash: /usr/bin/id: Operation not permitted (jessie-amd64-sbuild)root@prune:/# ls -l /usr/bin/id -rwxr-xr-x 1 root root 39560 Mar 14 2015 /usr/bin/id (jessie-amd64-sbuild)root@prune:/# ls -l /usr/bin/mesg -rwxr-xr-x 1 root root 10336 Apr 6 2015 /usr/bin/mesg /dev/mapper/tomb.home.1462878396.loop2 on /media/home.tomb type ext4 (rw,nodev,noatime,data=ordered) /dev/sda8 on /var/lib/schroot/union/underlay/jessie-amd64-sbuild-340bd7cf-b493-4a9e-b70a-ed775aaef0b8 type ext4 (rw,relatime,errors=remount-ro,data=ordered) jessie-amd64-sbuild on /run/schroot/mount/jessie-amd64-sbuild-340bd7cf-b493-4a9e-b70a-ed775aaef0b8 type overlay (rw,relatime,lowerdir=/var/lib/schroot/union/underlay/jessie-amd64-sbuild-340bd7cf-b493-4a9e-b70a-ed775aaef0b8,upperdir=/var/lib/schroot/union/overlay/jessie-amd64-sbuild-340bd7cf-b493-4a9e-b70a-ed775aaef0b8/upper,workdir=/var/lib/schroot/union/overlay/jessie-amd64-sbuild-340bd7cf-b493-4a9e-b70a-ed775aaef0b8/work) proc on /run/schroot/mount/jessie-amd64-sbuild-340bd7cf-b493-4a9e-b70a-ed775aaef0b8/proc type proc (rw,nosuid,nodev,noexec,relatime) sysfs on /run/schroot/mount/jessie-amd64-sbuild-340bd7cf-b493-4a9e-b70a-ed775aaef0b8/sys type sysfs (rw,nosuid,nodev,noexec,relatime) devpts on /run/schroot/mount/jessie-amd64-sbuild-340bd7cf-b493-4a9e-b70a-ed775aaef0b8/dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run/schroot/mount/jessie-amd64-sbuild-340bd7cf-b493-4a9e-b70a-ed775aaef0b8/dev/shm type tmpfs (rw,relatime) /dev/sda8 on /run/schroot/mount/jessie-amd64-sbuild-340bd7cf-b493-4a9e-b70a-ed775aaef0b8/build type ext4 (rw,relatime,errors=remount-ro,data=ordered) Linux prune 4.5.0-1-amd64 #1 SMP Debian 4.5.1-1 (2016-04-14) x86_64 GNU/Linux Guess I should try an older kernel, see if that helps. -- Brian May
Re: schroot broken in testing?
Brian May writes: > schroot has suddenly decided to throw errors whenever I use it: > > prune# schroot --chroot jessie-amd64-sbuild --user=root > E: 20copyfiles: cp: cannot create regular file > '/var/run/schroot/mount/jessie-amd64-sbuild-569a4fef-b267-4e4b-bb6c-da14e167ddee/etc/resolv.conf': > Operation not permitted > E: jessie-amd64-sbuild-569a4fef-b267-4e4b-bb6c-da14e167ddee: Chroot setup > failed: stage=setup-start > > prune# schroot --chroot sid-amd64-sbuild --user=root > E: 20copyfiles: cp: cannot create regular file > '/var/run/schroot/mount/sid-amd64-sbuild-b87ff7e8-a09e-47ee-be8d-8a407056d84c/etc/resolv.conf': > Operation not permitted > E: sid-amd64-sbuild-b87ff7e8-a09e-47ee-be8d-8a407056d84c: Chroot setup > failed: stage=setup-start Also I the error message changes each time, sometimes I get the following instead: [brian:/] 1 % schroot --chroot jessie-amd64-sbuild --user=root E: Failed to execute “/bin/bash”: Operation not permitted -- Brian May
schroot broken in testing?
schroot has suddenly decided to throw errors whenever I use it: prune# schroot --chroot jessie-amd64-sbuild --user=root E: 20copyfiles: cp: cannot create regular file '/var/run/schroot/mount/jessie-amd64-sbuild-569a4fef-b267-4e4b-bb6c-da14e167ddee/etc/resolv.conf': Operation not permitted E: jessie-amd64-sbuild-569a4fef-b267-4e4b-bb6c-da14e167ddee: Chroot setup failed: stage=setup-start prune# schroot --chroot sid-amd64-sbuild --user=root E: 20copyfiles: cp: cannot create regular file '/var/run/schroot/mount/sid-amd64-sbuild-b87ff7e8-a09e-47ee-be8d-8a407056d84c/etc/resolv.conf': Operation not permitted E: sid-amd64-sbuild-b87ff7e8-a09e-47ee-be8d-8a407056d84c: Chroot setup failed: stage=setup-start Anybody else seen similar problems? The permissions on the files look fine to me. -- Brian May https://linuxpenguins.xyz/brian/
Re: Bug#823052: ITP: python-mkdocs-bootswatch -- Bootswatch themes for MkDocs
Would appreciate it if somebody could confirm that the license is BSD and if so what version of the BSD license this is. https://github.com/mkdocs/mkdocs-bootswatch/blob/master/LICENSE setup.py declares the license as BSD, however in my current sleep deprived state it looks different to the BSD licenses that I can see here: https://en.wikipedia.org/wiki/BSD_licenses -- Brian May
Bug#823052: ITP: python-mkdocs-bootswatch -- Bootswatch themes for MkDocs
Package: wnpp Severity: wishlist Owner: Brian May * Package name: python-mkdocs-bootswatch Version : 0.4.0 Upstream Author : Dougal Matthews * URL : https://pypi.python.org/pypi/mkdocs-bootswatch/ * License : BSD Programming Lang: HTML/CSS Description : Bootswatch themes for MkDocs No idea what to put here for long description. This is a requirement for python-mkdocs. Not sure if this prefix of python- is appropriate or not because this package doesn't contain any python, however it is part mkdocs, and the source of mkdocs which has been named python-mkdocs in Debian. I plan to maintain this as part of the DPMT - Debian Python Modules Team. Also see discussion on mailing list: https://lists.debian.org/debian-python/2016/04/msg00042.html
Bug#823053: ITP: python-mkdocs-bootstrap -- Bootstrap theme for MkDocs
Package: wnpp Severity: wishlist Owner: Brian May * Package name: python-mkdocs-bootstrap Version : 0.1.1 Upstream Author : Dougal Matthews * URL : https://pypi.python.org/pypi/mkdocs-bootstrap/ * License : BSD Programming Lang: HTML/CSS Description : Bootstrap theme for MkDocs No idea what to put here for long description. This is a requirement for python-mkdocs. Not sure if this prefix of python- is appropriate or not because this package doesn't contain any python, however it is part mkdocs, and the source of mkdocs which has been named python-mkdocs in Debian. I plan to maintain this as part of the DPMT - Debian Python Modules Team. Also see discussion on mailing list: https://lists.debian.org/debian-python/2016/04/msg00042.html
Re: Overall bitrot, package reviews and fast(er) unmaintained package removals
Felipe Sateler writes: >> - no upload in a long time > > s/upload/maintainer upload/ In the past I have maintained some important packages by doing regular NMUs when the maintainer is not responsive (including emails asking to take over the package). So just because the *maintainer* hasn't made an upload in a long time doesn't mean that nobody cares about the package. If there aren't RC bugs to be fixed and the package is up-to-date, an unresponsible maintainer still doesn't mean nobody cares about the package; however it could mean another maintainer (or team maintained) is desirable. -- Brian May
Bug#819853: ITP: pytest-runner -- Invoke py.test as distutils command with dependency resolution.
Package: wnpp
Severity: wishlist
Owner: Brian May
* Package name: pytest-runner
* Binary Package name : python{,3}-pytest-runner
Version : 2.7
Upstream Author : Jason R. Coombs
* URL : https://github.com/pytest-dev/pytest-runner
* License : Expat
Programming Lang: Python and Python3
Description : Invoke py.test as distutils command with dependency
resolution.
Setup scripts can use pytest-runner to add setup.py test support for pytest
runner.
Will package this as part of the Debian Python Modules Team. Is required
by Django Guardian.
For some reason thought this was already in Debian, however I can't find
it.
The only indication I can see that this is Expat/MIT licenses is:
https://github.com/pytest-dev/pytest-runner/blob/master/setup.py#L43
Which contains:
"License :: OSI Approved :: MIT License",
Not sure if this is adequate for Debian or not. If this is sufficient, I
have a working package that I can upload.
Have filled a bug report:
https://github.com/pytest-dev/pytest-runner/issues/16
Bug#819157: ITP: bitstruct -- Python bit pack/unpack package
Package: wnpp Severity: wishlist Owner: Brian May * Package name: bitstruct Binary packages : python-bitstruct and python3-bitstruct Version : 2.1.3 Upstream Author : Erik Moqvist * URL : https://github.com/eerimoq/bitstruct * License : Expat Programming Lang: Python2 and Python3 Description : Python bit pack/unpack package This module is intended to have a similar interface as the python struct module, but working on bits instead of primitive data types (char, int, ...). This package is required by another package I am interested in that I may or may not package in Debian at a later date (lifx-sdk project on pypi). Anybody interested in lifx-sdk please let me know. I intend to maintain it as part of the the Debian Python Modules Team.
Bug#819126: ITP: tzlocal -- tzinfo object for the local timezone
Package: wnpp Severity: wishlist Owner: Brian May * Package name: tzlocal Version : 2.1 Upstream Author : Lennart Regebro * URL : https://github.com/regebro/tzlocal * License : CC0 Programming Lang: Python2 and Python3 Description : tzinfo object for the local timezone This module attempts to fix a glaring hole in pytz, that there is no way to get the local timezone information, unless you know the zoneinfo name, and under several Linux distros that’s hard or impossible to figure out. . With tzlocal you only need to call get_localzone() and you will get a tzinfo object with the local time zone info. On some Unices you will still not get to know what the timezone name is, but you don’t need that when you have the tzinfo file. However, if the timezone name is readily available it will be used. . This package contains the Python 2 module. This is required for the latest version of apscheduler. I plan to maintain it as part of the Debian Python Modules Team.
Re: a poll for Dgit workflows
Barry Warsaw writes: > Even if I didn't like 3.0-quilt, I think it's clear that dgit has to work well > with such package formats as it will be a long time, if ever that a maintainer > won't have to walk up to a quiltified package to do some work on. I'm not > personally a fan of single-debian-patch. I think the single-debian-patch makes doing security updates a lot harder. Particularly if one distribution has been patched, and the patch needs to be ported to other distributions. Sure, you might be able to retrieve/store the individual patches from git, however we don't have any one standard for storing the patches in git. This means in order to do security updates, the first step would be to learn how this particular packages stores the patches in git. Unlike 3.0-quilt format which is a standard that most packages use (or some similar storing of patches in debian/patches at least). I haven't looked at dgit in sometime, so I can't recall how well it works - assuming it does work - with 3.0-quilt format. -- Brian May
Re: Bug#815675: ITP: ftpbackup -- Script to backups your data from a Debian system to a ftp space
Nikolaus Rath writes: > Alright. In your opinion, what should be the standard for getting > something packaged into Debian? Just because something does not get included in Debian, doesn't stop you from packaging it and distributing it outside Debian. In fact, in this case, it has certain advantages. You can release a new version whenever you want. You can require user's to have the latest version to get support. Debian is not stuck trying to support a legacy version in stable until LTS support ends. The security team is not stuck trying to patch security vulnerabilities in an obsolete version that the upstream maintainer lost interest in years ago. etc. I haven't seen the code myself, however one of the comments was: "just having whitespace in the destination directory will lead to a crash, set -e is not used, and errors are redirected to /dev/null" This sounds to me like a recipe for security problems. -- Brian May
Re: broken mount behaviour on jessie
Brian May writes: > I have a patched 1.6.10-2 for sid and jessie, amd64 and i386 at > https://linuxpenguins.xyz/debian/pool/main/s/schroot/ > > Haven't had a chance to test it extensively yet, but so far seems to > work. Still getting unexpected mount errors; don't have time to investigate right now. schroot.chroot.SchrootCommandError: u'E: 10mount: umount: /var/lib/schroot/mount/jessie-i386-02a65cf6-3770-44b6-a1b8-c2f38d0c090e/dev: target is busy\nE: 10mount: (In some cases useful info about processes that\nE: 10mount: use the device is found by lsof(8) or fuser(1).)\nE: jessie-i386-02a65cf6-3770-44b6-a1b8-c2f38d0c090e: Chroot setup failed: stage=setup-stop\n' -- Brian May
Re: broken mount behaviour on jessie
Raphael Hertzog writes: > Both patches are the same but for two different schroot branches (1.7.x is > in experimental, 1.6.x in unstable). I have a patched 1.6.10-2 for sid and jessie, amd64 and i386 at https://linuxpenguins.xyz/debian/pool/main/s/schroot/ Haven't had a chance to test it extensively yet, but so far seems to work. -- Brian May
Re: broken mount behaviour on jessie
Michael Biebl writes: > Have you tried the patch in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786566 I see two patches here - one patch applies easy enough to schroot - 1.6-schroot-mount-make-bind-mounts-private.patch I am not sure what the master-libexec-mount-make-bind-mounts-private.patch is for, it seems to patch files not in schroot but has references to schroot files. Do I need the 2nd patch or is the 1st one sufficient? -- Brian May
Re: broken mount behaviour on jessie
Peter Palfrader writes: > o) you cannot unmount the tmp0 tree while the tmp1 tree is busy: > > } root@valiant:/mnt# (cd tmp1/dev/pts ; sleep 10 &) > } root@valiant:/mnt# umount /mnt/tmp0/dev/pts > } umount: /mnt/tmp0/dev/pts: target is busy > } (In some cases useful info about processes that > } use the device is found by lsof(8) or fuser(1).) Sounds very much like the reason behind #794828, which has been a constant problem for me. Are there any workarounds for Jessie? -- Brian May
Re: mkdocs locale error building djangorestframework
Ben Hutchings writes: > Oh, well that's probably because you only set LANG and it's being > overridden by LC_ALL. Use a bigger hammer: set LC_ALL yourself. Yes, somebody mentioned this on the BTS also. I very much suspect this will be the solution. Thanks -- Brian May
Re: mkdocs locale error building djangorestframework
Ben Hutchings writes: > That's not the problem at all. Read the error message again. Read the > source line it points to. Now look at where rv comes from: Yes, that is how it would appear. However, all this code does is try to work out the appropriate fatal error message that should get displayed. i.e. we should never have executed this code in the first place. (I did file a bug on the python3 issue however) -- Brian May
Re: mkdocs locale error building djangorestframework
Adam Borowski writes: > My guess as to the cause of #812672 is that you have LC_CTYPE or LC_ALL set > to an ancient locale. These variables override LANG, the order is > LC_ALL>LC_CTYPE>LANG. Interesting thought. Unfortunately, I can't tell from the supplied build logs what these are set to. I probably should change the line from: LANG=C.UTF-8 mkdocs build && mv site docs.debian/html To something like: LANG=C.UTF-8 LC_CTYPE= LC_ALL= mkdocs build && mv site docs.debian/html Just in case. -- Brian May
Re: mkdocs locale error building djangorestframework
Ben Hutchings writes: > C.UTF-8 is built into glibc so I believe you can assume it's present in > all Debian installations (from wheezy onward). Ok, this is getting more and more complicated. The only reason I can see for the FTBFS in #812672 is because the C.UTF-8 locale doesn't exist. It shouldn't even be reaching that line of code otherwise. Maybe something to do with building with pbuilder as opposed to sbuild? -- Brian May
Re: support for merged /usr in Debian
Marc Haber writes: > Keep support for things that used to work for, say, at least three or > four stable releases, document that and commit to it. And, of course, > stick to it. So at approx 2 years per stable release, that would be around 6 to 8 years before we could get this optional change into Debian. Which in turn mean we are 6 to 8 years behind the other major Linux distributors. That would definitely put me off Debian. Or maybe you can see into the future, and can see a time when the new /usr will be mandatory for all users. Maybe this is your concern. You want a commitment for it to remain optional for at least 6 to 8 years. Do we want debian to be slow and conservative or fast and bleeding edge? I would find 6 to 8 years far too long myself, by the time we get changes in a stable release, it is likely they will already be obsolete and replaced by something better. It would probably result in Debian being forked by people who want to develop using the latest standards but unable to do so in Debian. Maybe what you are looking for is LTS support or extended LTS support on our releases? -- Brian May
Bug#810061: ITP: python-django-environ -- utilize 12factor inspired environment variables for Django
Package: wnpp Severity: wishlist Owner: Brian May * Package name: python-django-environ Version : 0.4 Upstream Author : joke2k * URL : https://github.com/joke2k/django-environ/ * License : MIT Programming Lang: Python2 and Python3 Description : Simplified environment variables for Django Simplifies configuring key aspects of Django Applications through environment variables. I am hopeless with descriptions, any improvements to the above description welcome. This will be maintained as part of DPMT, and will be required for the next release of django-guardian.
Bug#809705: general: let people use non-free software but opt-out of non-open software
Johannes Schauer writes: > I am talking about adding the metadata about which license code is released > under and/or which DFSG freedoms it violates as proposed by Stefano in a > machine readable way: either debtags or DEP-5 and make either or both of them > understood by apt pinning so that I can tell my system which software to allow > and which to not allow. It might be worth looking at what FDroid have done with there antifeatures metainformation: https://f-droid.org/manual/fdroid.html#AntiFeatures -- Brian May
Re: Bug#807019: tracking bin-num - broken unison due to binnmu upload
Alexander Wirt writes: >> This should be integrated in the backports.d.o repositories. > Backports is not for fixing bugs in stable. I think there is a misunderstanding here. This is not about fixing unison in stable. "unison" 2.40.102-2 in stable works fine. It is not broken. There is nothing to fix. It works fine when talking to other stable servers. The package called "unison2.40.102" version 2.40.102-3+b1 in testing and unstable is broken. This broken package is not in stable. If it can't get fixed, it probably should get removed. The most recent "unison" package, version 2.48.3-1 in testing and unstable is not broken. Unfortunately it is not compatable with the version in stable. This is about letting stable users use the latest bleeding each version so that they can have compatability with unison 2.48 in unstable which is not broken. Which I believe is inline with what backports is for. -- Brian May
Re: django-ajax-selects lintian errors/warnings
Neil Williams writes:
> Then the reference needs to be inserted by a templatetag which knows
> about the running configuration.
>
>> Also, bootstrap.js is also a static file, so we cannot use
>> {{ STATIC_URL }} here.
>
> If it's also a static file, that's exactly what {{ STATIC_URL }}
> provides. It's a static file owned by django-ajax-selects, so
> {{ STATIC_URL }} is correct within d-a-s and the file just gets replaced
> by a symlink to the min.js of the external package during install. The
> URL is the .min.js but the editable .js is provided in VCS.
errr.. It is static. Meaning it is served by Apache without any help
from Django. Meaning none of Django's template stuff will work inside
bootstrap.js, because Django's template stuff doesn't get
invoked. Meaning we cannot use {{ STATIC_URL }} in this file.
Referencing bootstrap.js is easy. However getting bootstrap.js to
reference a local copy of jquery.js isn't.
Possibly the confusion here is the name. This bootstrap.js has *nothing*
to do with a similar file from JQuery. It is a django-ajax-selects
file. I quoted the entire contents of it previously.
If we want this file to get served by Django its template system, we
would need to allocate some url to it within ajax_select/urls.py, and
move it to the Django template's directory. Not sure I could convince
upstream of the need for the extra complexity.
This is a file that needs to be loaded for every page, so there is the
extra load and roundtrip on the server to think about too, serving a
file through Django instead of serving a cachable file directly from
disk.
> Sounds like there needs to be some clarification here. What I'm
> expecting is something like this:
>
> 0: blah.js lives in the django-ajax-select VCS, upstream.
>
> 1: javascript.py is configured to convert that to a symlink to
> the .min.js from an external package or to uglify the VCS version into
> a .min.js and remove the .js from the django-ajax-select binary
> package. This happens at build time of django-ajax-select so that
> security fixes to blah.js can be applied as Debian patches to
> django-ajax-select with the assurance that changes to the .js do get
> carried into the .min.js that every dependency actually uses. If
> d-a-s does the uglify, then d-a-s is in sole control of where
> that .min.js can be found.
So if my understanding is correct, people who use the package directly
from PyPI will get blah.js, not the minified version?
> 2: Apps using django-ajax-select can call a templatetag (which lives
> in the d-a-s python code) to get the location of the .min.js installed
> by django-ajax-select (whether that's a symlink or not) or can be left
> to do their own setup of finding it. As a file installed by d-a-s, it's
> quite possible that apps which are packaged for Debian would simply put
> the installed location into their own configuration of javascript.py in
> their own source code. In that sense, d-a-s is no different to
> libjs-blah which puts a .min.js into /usr/share/ - apps can simply list
> that in their own configuration for javascript.py. If using a
> templatetag, the templatetag can be generic for the d-a-s location,
> independent of what {{ STATIC_URL }} says within the app using d-a-s.
> Any logic about whether to reference it or not either goes into the
> dependency app or the templatetag. Overall, it's simpler to just get
> dependencies to use their own javascript.py config.
Ok, so here is a fundemental difference in philosophy.
Upstream wants to have all of this included automagically without the
App having to do anything. This is done with the bootstrap.js file. The
bootstrap.js file is referenced by Django media objects from the
fields. This has the advantage that it will work with fields with the
Django admin interface without having to overload the admin/base.html
template file.
Maybe it would be better to require all Apps use a specified templatetag
at the top of their template files. That way we could completely delete
the bootstrap.js file.
I guess the key problem I see with this, from upstreams perspective, is
that this would require copying and overriding the
django/contrib/admin/templates/admin/base.html file to get this working
properly with Django admin.
Or another option would be to delete bootstrap.js and replace the media
object reference in fields.py with direct references to jquery.js
conditional on AJAX_SELECT_BOOTSTRAP being set to True - this would mean
the autodetection on jquery is gone however.
> setup.py isn't useful here - it barely knows how to do the install of
> the files in the first place, let alone actually implementing logic
> during the install.
setup.py is the only file executed however when non-Debian user's or
virtualenv user's install packages with pip install.
--
Brian May
Re: django-ajax-selects lintian errors/warnings
Neil Williams writes:
> So the reference to bootstrap.js needs to be patched out to refer to a
> static location which can be put in place using a Depends in
> debian/rules.
Still trying to work out how this could work. What path should I put in
bootstrap.js?
STATIC_URL is configured by the application that uses
django-ajax-selects. We have no idea what it might be set to. So we
cannot hardcode any path into bootstrap.js
Also, bootstrap.js is also a static file, so we cannot use
{{ STATIC_URL }} here.
> Isn't bootstrap.js doing that already? If bootstrap.js is part of
> upstream, using bootstrap.js brings in an external jquery.
bootstrap.js is a NOP if jquery and jquery-ui has already been loaded by
the application.
> I provided links for scripts which do exactly this last time, these:
>
> https://git.linaro.org/lava/lava-server.git/blob/HEAD:/share/javascript.py
> https://git.linaro.org/lava/lava-server.git/blob/HEAD:/share/javascript.yaml
What calls javascript.py? Is it somehow called by setup.py?
--
Brian May
Re: git, debian/ tags, dgit - namespace proposal [and 1 more messages]
Ian Jackson writes: > It has nothing to do with the source format. That's the opposite of > what this tag namespace is for. For a package and version this git > tag refers to the source code that you'd get out of `apt-get source' > or dpkg-source -x, _regardless_ of the source format. Maybe I am confused or missed something, however I thought that was exactly the point of the debian/ tag in DEP-14. In what way does your use differ from the debian/ tag in DEP-14? -- Brian May
Re: django-ajax-selects lintian errors/warnings
Neil Williams writes:
>> E: django-ajax-selects source: source-is-missing
>> ajax_select/static/ajax_select/js/bootstrap.js
>
> If this really is your own source code, a filename change would be one
> way to do it. In most cases, bootstrap is not written by this upstream
> but has been included into the upstream VCS from another location.
No, I have another package with bootstrap.js and lintian has no
problems. Suspect it might be due to line length. There are several bug
reports on this, the one I can find is:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802028
>> python3-ajax-select: image-file-in-usr-lib
>> usr/lib/python3/dist-packages/ajax_select/static/ajax_select/images/loading-indicator.gif
>
> This matters more when the package list from this source package
> contains Architecture: any instead of Architecture: all binaries, which
> is uncommon with django apps. With Arch: any, the files in /usr/lib/
> would be duplicated for each arch build which is a clear problem to be
> avoided.
This is Architecture: all, so sounds like not a problem here.
>> E: python3-ajax-select: privacy-breach-uses-embedded-file
>> usr/lib/python3/dist-packages/ajax_select/static/ajax_select/js/bootstrap.js
>> You may use libjs-jquery-ui package.
>
> You may indeed - replace the file with a symlink in debian/rules and
> add to Depends.
Replace what file with a symlink? bootstrap.js isn't the problem itself,
the problem is bootstrap.js referencing jquery.min.js from an external
source. The library itself doesn't currently come with a copy of jquery.
In this case the python*-ajax-select packages are not intended to be
used by users, rather they are libraries intended to be used by other
applications (Django apps) which are used by users. There simply isn't a
single standard way I know of providing and using one and only one
jquery in Django libraries. (no - Django Media objects don't help)
Maybe I should raise this issue with the Django developers? Even if I
did, came up with a proposal (I don't have one), and we agreed to a
solution, we still need a solution for now, with the current release of
Django.
If I tell upstream to include a copy of jquery.min.js and/or jquery.js
in the static directory (this is another issue[1]), it will get exported
in all Django apps that use this library, including those that don't
need or want it. Maybe this is considered a reasonable tradeoff - it is
unlikely to cause conflicts due to the directory name used, however I
come from the school of thought that you shouldn't be publishing files
unless there actually is a need to publish the files.
Apologies if I seem argumentative, however I really don't see a good
solution to this. The best decision really depends on the Django app
that uses this library, and upstream have tried to make it easier to get
started using the library in such a way it has minimal downsides for
Django apps that want to include their own version of jquery.
>> privacy-breach-uses-embedded-file - this is only correct if used by an
>> application that does not import jquery symbols itself. If the
>> application already has loaded jqueblry and jquery-ui from, say a
>> local source, I believe there is no privacy issue:
>>
>> // load jquery and jquery-ui if needed
>> // into window.jQuery
>> if (typeof window.jQuery === 'undefined') {
>> document.write('
django-ajax-selects lintian errors/warnings
Hello,
For django-ajax-selects in git[1] I am getting the following errors and
warnings:
E: django-ajax-selects source: source-is-missing
ajax_select/static/ajax_select/js/bootstrap.js
W: python3-ajax-select: extra-license-file
usr/lib/python3/dist-packages/ajax_select/LICENSE.txt
W: python3-ajax-select: image-file-in-usr-lib
usr/lib/python3/dist-packages/ajax_select/static/ajax_select/images/loading-indicator.gif
E: python3-ajax-select: privacy-breach-uses-embedded-file
usr/lib/python3/dist-packages/ajax_select/static/ajax_select/js/bootstrap.js
You may use libjs-jquery-ui package.
(//code.jquery.com/ui/1.10.3/themes/smoothness/jquery-ui.css)
E: python3-ajax-select: privacy-breach-uses-embedded-file
usr/lib/python3/dist-packages/ajax_select/static/ajax_select/js/bootstrap.js
You may use libjs-jquery package.
(//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js)
W: python-ajax-select: image-file-in-usr-lib
usr/lib/python2.7/dist-packages/ajax_select/static/ajax_select/images/loading-indicator.gif
E: python-ajax-select: privacy-breach-uses-embedded-file
usr/lib/python2.7/dist-packages/ajax_select/static/ajax_select/js/bootstrap.js
You may use libjs-jquery-ui package.
(//code.jquery.com/ui/1.10.3/themes/smoothness/jquery-ui.css)
E: python-ajax-select: privacy-breach-uses-embedded-file
usr/lib/python2.7/dist-packages/ajax_select/static/ajax_select/js/bootstrap.js
You may use libjs-jquery package.
(//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js)
To me it looks like I should override some of these.
source-is-missing - this is false, this is the source file, I believe it
was written by hand. It has some long lines. See below, I pasted it into
this message.
extra-license-file - at quick glace this warning is correct, and should
get fixed.
image-file-in-usr-lib - do we really care about this? For Django apps it
is common practise to put static files under the Python directory like
this. That means they go under /usr/lib. It is not really possible to
change this without a lot of extra complexity using a -common package
and symlinks. For one small file, not convinced it is worth it.
privacy-breach-uses-embedded-file - this is only correct if used by an
application that does not import jquery symbols itself. If the
application already has loaded jquery and jquery-ui from, say a local
source, I believe there is no privacy issue:
// load jquery and jquery-ui if needed
// into window.jQuery
if (typeof window.jQuery === 'undefined') {
document.write('
Re: An abrupt End to Debian Live
Colin Watson writes: > FWIW, while I helped the vmdebootstrap folks at the recent Cambridge > sprint with getting UEFI support in place, it was something of a > surprise to me to hear that their tool would be called "live-build-ng". > This seems pretty over the top to me and I was expecting it to be called > vmdebootstrap-live or something like that; at the very least, calling > something "-ng" seems like it sets pretty high expectations. I only briefly read the bug report: https://bugs.debian.org/804315 It sounds like an email on the lines of "this is what we are working on; this is what we intend to call it" might have been a good idea when they started. So it doesn't come as a complete surprise when it happens. Isn't that one of the reasons we have ITPs? Also I assume there is a good reason why they felt they had to start a new project as opposed to contributing changes to the existing project? Sure maybe a rewrite in Python was a good thing, I can't comment on this aspect. -- Brian May
Bug#802730: ITP: python-setuptools-scm -- Handles managing your python package versions in scm metadata.
Package: wnpp Severity: wishlist Owner: Brian May * Package name: python-setuptools-scm Version : 1.8.0 Upstream Author : Ronny Pfannschmidt * URL : https://github.com/pypa/setuptools_scm/ * License : MIT Programming Lang: Python 2 and Python 3 Description : Handles managing your python package versions in scm metadata. Handles managing your Python package versions in scm metadata instead of declaring them as the version argument or in a scm managed file. Required for pytest-django, which is required by djangorestframework. Will be packaged as part of the DPMT (Debian Python Modules Team).
Bug#802727: ITP: pytest-django -- Test Django project/applications with pytest.
Package: wnpp Severity: wishlist Owner: Brian May * Package name: pytest-django Version : 2.9.1 Upstream Author : Andreas Pelme * URL : https://github.com/pytest-dev/pytest-django * License : BSD Programming Lang: Python 2 and Python 3 Description : Test Django project/applications with pytest. Running your test suite with pytest-django allows you to access features of pytest that wouldn't normally be available with the Django’s manage.py test command. This seems to be required to get the djangorestframework tests working properly. I will package this as part of the DPMT (Debian Python Modules Team).
package description translation bugs
Hello, How should I deal with bug #786980? I don't believe using the Debian BTS will get through to the DDTP. I can't even find how to contact the DDTP. Regards
Re: init script, installed but not activated
On Thu, 8 Oct 2015 at 08:35 Nick Phillips wrote: > Personally, I'd prefer that packages get a default configuration and > services are never enabled on install. However, I get that some/many > people would prefer that debconf ask them enough questions to configure > a package and that the service be enabled by the end of the install. > For a (rare?) example I have had recently where I prefer services don't get configured or enabled on install, consider build-depends required for testing. I have a python library in Debian that build depends on slapd. https://packages.debian.org/sid/python-tldap It does this because it has tests that require slapd. The tests create a slapd database and run slapd on a non-standard port. Unfortunately, when slapd gets installed it automatically configures a database (completely redundant) and starts a slapd instance on the default ldap port. This means you can't build my package in a schroot instance on a host that is already running slapd on the port (e.g. another build instance), because it will fail to install slapd. It would be much better (for testing) if I could just install the slapd daemon without doing any of the automatic configuration. As another example with the same package, any automatic configuration makes it harder to write scripts to automatically create a Debian install instance with slapd running for testing. I was working on this in my previous job. A change in the default configuration from testing to unstable broke my LDIF configuration changes (due to change in database backend). I was almost considering making step delete existing configuration after installing OS packages, so it could start from a clean/known state[1]. After being made redundant from my previous job, I am no longer working on this particular project. Still need to consider if I want to continue maintaining python-tldap or not as a result. Notes: [1] For the record the rpm packages were a lot worse then the Debian packages because they make assumptions on the default configuration, such as default DN, with no easy/obvious way of changing them.
Re: Security concerns with minified javascript code
On Mon, 31 Aug 2015 at 16:50 Raphael Hertzog wrote: > In both cases, I worked around the problem by shipping the upstream > sources in debian/missing-sources/ but I did not support doing changes > there and did not rebuild the embedded libraries. > I haven't been paying lots of attention to this thread, however in the past that has been my strategy too. If I did the minimization myself in the Debian package, or used js from an existing Debian package, I would be seriously worried about introducing bugs. There are lots of potential issues here: * Different versions used. * Bugs in the minimization process. * Upstream may have made changes to js code before including it from third parties. Some of these packages, the js is only a small part of the full functionality. Or I just want to package it quickly because it is a required dependency of the package I really need. Typically these packages don't have any js testing either, so it is not always possible to know you broke some obscure feature that requires a specially crafted input file to enable. Maybe lack of testing is the real issue that needs to get resolved first? As an example, my own package - not yet in Debian - I was forced to modify moment-timezone-with-data.js as downloaded from upstream, because without this kludged modification, pipeline+slimit combined would completely break the js to the point that browsers wouldn't touch it. I reported this against django-pipeline in March, no responses yet. Actually I don't really understand where the bug is, most likely django-pipeline or slimit. https://github.com/cyberdelia/django-pipeline/issues/445 Having said this, yes, I understand the desire to build everything from source, and I believe this is a good goal.
Bug#794829: ITP: python-django-cors-headers -- Django app for handling the server headers required for Cross-Origin Resource Sharing (CORS)
Package: wnpp Severity: wishlist Owner: Brian May * Package name: python-django-cors-headers Version : 1.1.0 Upstream Author : Otto Yiu * URL : https://github.com/ottoyiu/django-cors-headers/ * License : MIT Programming Lang: Python2 and Python3 Description : Django app for handling the server headers required for Cross-Origin Resource Sharing (CORS) Pypi link: https://pypi.python.org/pypi/django-cors-headers Will be DPMT maintained. Required for another package I am creating. I think this is likely to be useful for other people besides myself. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150807011318.15108.81449.report...@prune.in.vpac.org
Re: GitHub “pull request” is proprietary, incompatible with Git ‘request-pull ’
On Sat, 11 Jul 2015 at 02:06 Dimitri John Ledkov < dimitri.led...@surgut.co.uk> wrote: > The problem with all of these they are still centralised. gerrit is > slightly better, as it stores all the review details as git notes, and > thus one can migrate them away without any loss of information. > Are you sure about this? Everything I have read seems to indicate review details / history gets stored in the database, and is a real pain to move onto another gerrit server. e.g.: http://stackoverflow.com/questions/26421537/how-do-i-merge-gerrit-instances-without-losing-history http://stackoverflow.com/questions/17850483/migrating-a-gerrit-project-into-a-different-instance-of-gerrit https://groups.google.com/forum/#!msg/repo-discuss/jbhIe4sIUZo/8g3J773avgQJ A distributed alternative for gerrit would be nice :-)
Re: RFC schema in package citadel
On Wed, 8 Jul 2015 at 20:50 Michael Meskes wrote: > citadel always came with an LDAP schema file under openldap/rfc2739.schema > that says: > openldap comes with schemas that have similar licenses. If it is OK for openldap, I think it should be fine here too.
