Re: source.changes has wrong hash sum (Was: ftp master uploads disappearing?)
Hi, On Thu, Oct 05, 2017 at 09:26:04PM +0200, IOhannes m zmölnig (Debian/GNU) wrote: > On 10/05/2017 06:53 PM, Andreas Tille wrote: > > Bad checksums on loki_2.4.7.4-7_source.changes: Checksum mismatch for file > > loki_2.4.7.4-7.dsc: b4d2841416822842e6e6b85c44e3f4f3 != > > 7acc0c03ab3a269d117decd6dd692967 > > > > What to try next? > > following this conversation with interest, i also tried telling my gbp > builds to produce both source and binary packages. > i also get the "checksum mismatch" for the source.changes (not for the > amd64.changes). > my workaround for now is to just (re)run "debsign" on the source.changes. > maybe someone has a better alternative (though my workaround is good > enough to be able to test the binary packages and do a sources-only > upload with a single build). Doesn't happen here. The _source and _arch changes files only differ by the generate binaries: --- osinfo-db_0.20170811-1~deb9u1_source.changes2017-10-06 09:57:20.435021916 +0200 +++ osinfo-db_0.20170811-1~deb9u1_amd64.changes 2017-10-06 09:57:20.179042580 +0200 @@ -2,7 +2,7 @@ Date: Mon, 25 Sep 2017 12:21:16 +0200 Source: osinfo-db Binary: osinfo-db -Architecture: source +Architecture: source all Version: 0.20170811-1~deb9u1 Distribution: stretch Urgency: medium @@ -17,12 +17,15 @@ Checksums-Sha1: 136126c992e8a1f1d499adeb7f41660412cea6d9 1162 osinfo-db_0.20170811-1~deb9u1.dsc e436f9488ffb29fb6dc45c02e279a1d3f0b11fe2 16456 osinfo-db_0.20170811-1~deb9u1.debian.tar.xz + 6d764b255cf8281a6bae4ddc0ad322a31c3de452 71424 osinfo-db_0.20170811-1~deb9u1_all.deb 9e258d5c47faf61d3819f54b77fc4b9461b5494b 5663 osinfo-db_0.20170811-1~deb9u1_amd64.buildinfo Checksums-Sha256: e1f2b2c9ccbd2714c9605e38c42bc8447aa1c3a3bfba9c2a59c3b42aef7269c4 1162 osinfo-db_0.20170811-1~deb9u1.dsc e6a9ef156ec9d52357527d90837d14e7658b897b68050c5d2dbf6d7d157a2278 16456 osinfo-db_0.20170811-1~deb9u1.debian.tar.xz + c2512ddf9514b198f7c3cb47ad2a81c6bf0d129c01304c17f1ceb0a1acb47224 71424 osinfo-db_0.20170811-1~deb9u1_all.deb 9862c86fdda5e274ad7d245334cbcab486db2320d67e0804e8d912addca3c937 5663 osinfo-db_0.20170811-1~deb9u1_amd64.buildinfo Files: a7ab0746f1e2edf120b07d8ffc879b7a 1162 libs optional osinfo-db_0.20170811-1~deb9u1.dsc 9389321e2eab8f0187ef11b213b14b12 16456 libs optional osinfo-db_0.20170811-1~deb9u1.debian.tar.xz + 77d6fd933276a47cf4ef66a4377fbecd 71424 libs optional osinfo-db_0.20170811-1~deb9u1_all.deb ef79bf531a056126108b02488f7ef04b 5663 libs optional osinfo-db_0.20170811-1~deb9u1_amd64.buildinfo Cheers, -- Guido
Bug#877864: ITP: libtest-log-log4perl-perl -- module to test Log::Log4perl
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libtest-log-log4perl-perl Version : 0.32 Upstream Author : Chia-liang Kao * URL : https://metacpan.org/release/Test-Log-Log4perl * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to test Log::Log4perl Test::Log::Log4perl module can be used to test that you're logging the right thing with Log::Log4perl. It checks that your code logs what you expect and only that. This module is a fork and can be used instead of Test::Log4perl The package will be maintained under the umbrella of the Debian Perl Group. -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Bug#877878: ITP: mailman3-suite -- Django project integrating Mailman3 Postorius and HyperKitty
Package: wnpp Severity: wishlist Owner: Jonas Meurer * Package name: mailman3-suite Version : 0+20170523 Upstream Author : Free Software Foundation, Inc * URL : https://gitlab.com/mailman/mailman-suite * License : GPL-3 Programming Lang: Python Description : Django project integrating Mailman3 Postorius and HyperKitty This django web application provides the Mailman3 Postorius web interface and the HyperKitty mailinglist archiver integrated into one project and made available via uwsgi. This package will be maintained under the pkg-mailman umbrella. Cheers jonas
Re: Removal of upstart integration
]] Simon McVittie
> On Thu, 05 Oct 2017 at 21:43:20 +0200, Tollef Fog Heen wrote:
> > However, if you just do the IMO more common sudo $command, you get a lot
> > more:
> >
> > $ sudo env | wc -l
> > 87
>
> Is that under default configuration? My /etc/sudoers{,.d/*} don't mention
> env_reset, and "sudo env" clears most of the environment (including LESS,
> but notably not PATH).
Hmm, no, it seems like my standard setup has snuck in a !env_reset in
there somewhere. With that removed, the environment is indeed a lot
cleaner (~similar to what I got with sudo -i). It still leaks
XAUTHORITY, HOSTNAME, DISPLAY, TZ, LANG, which is annoying, but it's
less of a problem than what I claimed.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Re: Bug#877212: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing
On Thu, 05 Oct 2017 12:39:42 -0500, Gunnar Wolf wrote: > Ian Jackson dijo [Thu, Oct 05, 2017 at 01:29:16PM +0100]: > > I have also heard of packages which do "apt-get source" in their rules > > files. [..] > > Of course it would be better if we had a more declarative way of > > saying "this package needs foo.deb to build - and we mean the .deb, > > not for foo to be installed", and the corresponding "this package > > needs the source code for bar". But this is rather a niche, and it > > doesn't seem to cause trouble in practice. So AFAICT it's no-one > > priority. > > UGH. > > I am not convinced this use case should be supported - Even if the > software providers are ourselves, which we trust not to trojan our own > goodies, this still allows for a great deal of nondeterminism. If the > "apt-get source"d package is updated, the build might not work anymore > or might yield different results. True but this is the same as when a package in Build-Depends(-Indep) changes. In practice I've had the case where an unpacked .deb (instead of an installed one) would have been enough, and I also have a use case for a source package: libdatetime-timezone-perl could be binNMUd [0] against newer versions of the tzdata source package instead of someone manually doing the dance of downloading the tzdata upstream tarballing, turning it into .pm files and creating a huge quilt patch. Cheers, gregor [0] if we had binNMUs for arch:all packages -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Willi Resetarits + Stubnblues: de w signature.asc Description: Digital Signature
Re: Let's enable AppArmor by default (why not?)
Hello, I was recently pointed to the thread going on debian-devel about enabling AppArmor LSM in Debian, and as I read through your proposal, I felt it should be warranted to point out a few things in regards to the SELinux comparison: > Why AppArmor and not SELinux? > - > > SELinux is another LSM that tackles similar problems. > > Disclaimer: I've picked AppArmor years ago and didn't look much at > SELinux recently, so some of what follows may be totally wrong or > outdated. Sorry! Debian SELinux people, if you don't mind please help > me get the basic facts right :) > > Pros: > > * Allows mediating more kernel objects / interfaces than AppArmor, so > policy can be made stricter and safer given sufficient expertise > and available time for maintenance. > > * Enabled by default in RHEL so in theory a great number of sysadmins > are at ease with it (see below why reality may not match this). > It's also important to note that it is also enabled by default in Fedora, which is the upstream for RHEL. > * A quick look at popcon suggests that SELinux might be more popular > in Debian than AppArmor, but I'm not sure I am interpreting the > numbers right (and I suspect that just like AppArmor, the popcon > won't tell us if users who have installed the relevant support > packages actually run their system with the corresponding LSM > enabled & enforced). > I do know of users of SELinux in Debian and Ubuntu, though they often fork from refpolicy or fedora-selinux the bits they want to use and install it on top of the current refpolicy offered in Debian. > Cons: > > * Writing, maintaining, auditing and debugging SELinux policy > requires grasping a complex conceptual model; I am told this is not > as easy as doing the same with AppArmor. > This is not really true. While it is true that the conceptual model is more complex, the tooling for doing all the regular work with SELinux is great. In many cases, the tools can analyze what's happened and suggest a course of action about how to fix it. If it looks like a bug, they suggest filing one with the vendor (in my case, when weird things happen with the SELinux policy in Fedora, bugs get filed on selinux-policy with the information from setroubleshoot so that things can get fixed). As for the complexity of making policies and policy modules, I've written a few policy modules, and they're not that bad. You can make some pretty simple policies if you don't want to expose any administrative tunables. That said, even with the tunables, it's not that bad. For example, the container-selinux policy module is pretty easy to understand: https://github.com/projectatomic/container-selinux The refpolicy documentation is pretty comprehensive too: http://oss.tresys.com/docs/refpolicy/api/ One of the members of the Red Hat/Fedora SELinux team maintains a nice blog describing improvements as they come: https://lvrabec-selinux.rhcloud.com/ There's a few videos done by Red Hat folks on SELinux that are worth watching on YouTube: * Are you listening to what SELinux is telling you?: https://www.youtube.com/watch?v=Wv9kwlabdlo * Security-enhanced Linux for mere mortals - 2015 Red Hat Summit: https://www.youtube.com/watch?v=cNoVgDqqJmM * SELinux by Paul Moore: https://www.youtube.com/watch?v=j_do1yfPISw There's also a great video by Noah Chelliah about SELinux: * Security Enhanced Linux | Ask Noah 9: http://www.jupiterbroadcasting.com/115151/security-enhanced-linux-ask-noah-9/ > * As far as I could understand when chatting with sysadmins of Red > Hat systems, this has resulted in a culture where many users got > used to disable SELinux entirely on their systems, instead of > trying to fix the buggy policy. I've seen the opposite happen with > AppArmor, which is good: for example, pretty often bug reporters to > the Debian BTS document themselves how they could workaround the > problem locally *without* turning AppArmor off. Looking at open > bugs in the BTS against src:refpolicy, this seems to happen very > rarely for SELinux, so I wonder if it would be realistic to ship > Debian with SELinux enforced by default and have our community > support it. > Back in the RHEL 5 days, this is definitely true. And if many of of the Red Hat sysadmins you've talked to primarily maintain RHEL 5 systems (which is not unlikely), then it makes sense. Back in the RHEL 5 days (circa 2007), the tooling was very primitive, and for the most part, the troubleshooting tools didn't exist. Today in Fedora and RHEL 7, the tooling is very advanced, and in almost every case where I've hit AVC denials in SELinux, setroubleshoot has given me very useful information including suggested course of actions to actually fix it locally. It would probably not be all that difficult to also support the case of submitting bugreports to the BTS (it currently can for Bugzilla based systems, such as Red Hat Bugzilla and SUSE Bugzilla). Most of my fell
Bug#877900: general: en-us locale defaults to 24-hour "military" time on stock install
Package: general Severity: minor Dear Maintainer, When Debian 9 is installed with the en-us locale selected, the clock defaults to 24 hour time in the resulting install. This is odd because the normal means of representing the time in the area covered by en-us is to separate the day into two 12-hour segments. (localization issue) -- System Information: Debian Release: 9.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: source.changes has wrong hash sum (Was: ftp master uploads disappearing?)
On Fri, Oct 06, 2017 at 10:04:00AM +0200, Guido Günther wrote: > Hi, > On Thu, Oct 05, 2017 at 09:26:04PM +0200, IOhannes m zmölnig (Debian/GNU) > wrote: > > On 10/05/2017 06:53 PM, Andreas Tille wrote: > > > Bad checksums on loki_2.4.7.4-7_source.changes: Checksum mismatch for > > > file loki_2.4.7.4-7.dsc: b4d2841416822842e6e6b85c44e3f4f3 != > > > 7acc0c03ab3a269d117decd6dd692967 > > > > > > What to try next? > > > > following this conversation with interest, i also tried telling my gbp > > builds to produce both source and binary packages. > > i also get the "checksum mismatch" for the source.changes (not for the > > amd64.changes). > > my workaround for now is to just (re)run "debsign" on the source.changes. > > maybe someone has a better alternative (though my workaround is good > > enough to be able to test the binary packages and do a sources-only > > upload with a single build). > > Doesn't happen here. The _source and _arch changes files only differ by > the generate binaries: I assume this is because in Andreas's case, debsign is automatically run on one of the .changes files after the build, which will also sign the .dsc (and thus change its contents since it now has an inline signature around it), but the hash in the other .changes file is for the original unsigned .dsc. Really, you should only be signing the .changes you want to upload, and *after* you've already checked it for errors :) Regards, James
Bug#877908: ITP: libweasel-widgets-dojo-perl - Dojo Widgits for Weasel
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libweasel-widgets-dojo-perl Version : 0.02 Upstream Author : Erik Huelsmann * URL or Web page : https://metacpan.org/pod/Weasel::Widgets::Dojo * License : perl Description : Weasel::Widgets::Dojo - Dojo Widgits for Weasel The Weasel::Widgets::Dojo module is a Weasel extension set for testing Dojo-based web apps (tag matchers and widgets). -- Robert J. Clay rjc...@gmail.com
Bug#877900: general: en-us locale defaults to 24-hour "military" time on stock install
Control: reassign -1 locales
On Fri, Oct 06, 2017 at 05:29:20PM -0400, debianuser2017_ wrote:
> When Debian 9 is installed with the en-us locale selected, the clock defaults
> to 24 hour time in the resulting install. This is odd because the normal means
> of representing the time in the area covered by en-us is to separate the day
> into two 12-hour segments. (localization issue)
Actually, not two but four discontinuous segments:
12:00am..12:59am
01:00am..11:59am
12:00pm..12:59pm
01:00pm..11:59pm
-- ie, even inside an am/pm value, the order is bizarre.
Also, there's no way to unambigously refer to noon or midnight, or whether a
midnight belongs to the previous or next day, as even the same users often
keep shifting between two possible variants; you can read more about this
horror at:
https://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight
But, the above reasons apply mostly to humans. In a computing context, the
main reasons are:
* 12-hour times don't sort. Save for some GUIs where display is distinct
from the internal format, most cases would do it wrong. And sorting by
time is something with lots of use.
* en_US (.UTF-8) is used as the default English locale for all places that
don't have a specific variant (and often even then). Generally, technical
users use English as a system locale as translations of computing terms
tend to be a horror show: for example, in Polish even such a basic term
as "file" has two versions ("zbiór" — correct, and "plik" — Microsoftese)
that are not intelligible between some groups of people. Anything more
complex gets bad enough that no one bothers translating advanced technical
documentation or running servers (rather than user-facing systems) in
pl_PL locale. And as far as I know, same applies to most languages.
Obviously, this is an abuse, but that's the cost of being the default. If
we had C.UTF-8 as a first-class locale, this wouldn't be that much an
argument, but currently d-i falls back to en_US for English for most
countries.
The decision belongs to the maintainer (I'm reassigning), but per the above
reasoning, I expect wontfix.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased
⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts.
⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got
⠈⠳⣄ agriculture, towns then cities. -- whitroth on /.
Processed: Re: Bug#877900: general: en-us locale defaults to 24-hour "military" time on stock install
Processing control commands: > reassign -1 locales Bug #877900 [general] general: en-us locale defaults to 24-hour "military" time on stock install Bug reassigned from package 'general' to 'locales'. Ignoring request to alter found versions of bug #877900 to the same values previously set Ignoring request to alter fixed versions of bug #877900 to the same values previously set -- 877900: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877900 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
