Bug#808162: NetworkManager does not allow remote management
Package: network-manager Version: 1.0.8-2 Hi, the NetworkManager polkit policy in Debian does not allow changing or adding connections from a remote session, such as a ssh or Cockpit login. The default upstream policy explicitly allows this. See https://bugzilla.redhat.com/show_bug.cgi?id=1145646 for some discussion. In the bug report above, the action that needed adjustement was "org.freedesktop.NetworkManager.network-control". In Debian, "org.freedesktop.NetworkManager.settings.modify.system" would need to be allowed for "any".
Bug#807384: Realmd crashes when trying to join a FreeIPA domain
Package: realmd Version: 0.15.1-1+b2 Hi, realmd is misconfigured in such a way that it crashes when trying to join a FreeIPA domain. It produces messages like this: ** (realmd:4770): CRITICAL **: No section found in settings: ipa-packages and also segfaults. To fix the crash one can include a empty [ipa-packages] section in /usr/lib/realmd-default.conf but that of course doesn't make joining work since ipa-client-install is not yet available outside of unstable (I think). A correct configuration would have this in realmd-distro.conf, I think: [providers] sssd = no
Bug#807384: closed by Laurent Bigonville (Bug#807384: fixed in realmd 0.16.2-2)
Debian Bug Tracking System writes: > Distribution: unstable > * debian/patches/01_freeipa_section.patch: Fix a crash by adding an > empty [ipa-packages] section (Closes: #807384) I think freeipa-client is in unstable, and a better fix there would be to add something like [ipa-packages] freeipa-client = /usr/sbin/ipa-client-install to realmd-distro.conf. But please don't believe me, test instead. :)
Bug#842269: parted clobbers in-memory state of extended partitions
Package: parted Version: 3.2-16+b1 Please see https://bugzilla.redhat.com/show_bug.cgi?id=1135493 Additional information: This bug is probably masked most of the time because of the asynchronous BLKRRPART done by udev some time later. However, newer versions of Storaged disable this BLKRRPART. This has been fixed upstream, but has not been released. It is probably best to tickle a release out of upstream... To reproduce: # flock -s /dev/sda sleep infinity & # parted /dev/sda mktable msdos # parted /dev/sda mkpart extended 1MiB 40MiB # parted /dev/sda mkpart logical ext2 2MiB 40MiB # blkid -p /dev/sda1 error: /dev/sda1: No such device or address # kill %1 [1]+ Terminated flock -s /dev/sda sleep infinity # echo >/dev/sda # blkid -p /dev/sda1 /dev/sda1: PTTYPE="dos" PART_ENTRY_SCHEME="dos" PART_ENTRY_UUID="a05ee957-01" PART_ENTRY_TYPE="0xf" PART_ENTRY_NUMBER="1" PART_ENTRY_OFFSET="2048" PART_ENTRY_SIZE="79872" PART_ENTRY_DISK="8:0" The "flock" prevents udevd from issuing its usual BLKRRPART ioctl.
Bug#808162: [Pkg-utopia-maintainers] Bug#808162: NetworkManager does not allow remote management
(Sorry for the late reply) Michael Biebl writes: > Am 16.12.2015 um 18:18 schrieb Marius Vollmer: > >> the NetworkManager polkit policy in Debian does not allow changing or >> adding connections from a remote session, such as a ssh or Cockpit >> login. >> >> The default upstream policy explicitly allows this. See >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1145646 >> >> for some discussion. >> >> In the bug report above, the action that needed adjustement was >> "org.freedesktop.NetworkManager.network-control". In Debian, >> "org.freedesktop.NetworkManager.settings.modify.system" would need to be >> allowed for "any". > > I don't think we should allow > org.freedesktop.NetworkManager.settings.modify.system for everyone. > > Why is auth_admin(_keep) not sufficient here? If I can remember this right, the actual entry in the polkit file would be auth_admin The "any" in the original report referred to "allow_any" in contrast to allow_inactive and allow_active. I didn't mean "yes" instead of auth_admin. Sorry for being too terse in the original report.
Bug#504325: apt: arfile.cc uses strlen where it should use sizeof
Package: apt
Version: 0.7.16+b1
Severity: minor
Tags: patch
In apt-inst/contrib/arfile.cc:99, the available space in the buffer 'S' is
computed with "strlen(S)".
I think that shuld be "sizeof(S)", as the content of S is undefined at this
point.
This only matters for names longer than 16 characters, and luckily normal .deb
files don't have member names that
long, I think.
--- arfile.cc~ 2008-06-10 00:10:08.0 +0300
+++ arfile.cc 2008-11-02 22:42:36.0 +0200
@@ -96,7 +96,7 @@
char S[300];
unsigned long Len;
if (StrToNum(Head.Name+3,Len,sizeof(Head.Size)-3) == false ||
-Len >= strlen(S))
+Len >= sizeof(S))
{
delete Memb;
return _error->Error(_("Invalid archive member header"));
-- Package-specific info:
-- (no /etc/apt/preferences present) --
-- (/etc/apt/sources.list present, but not submitted) --
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.25-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages apt depends on:
ii debian-archive-keyring 2008.04.16+nmu1 GnuPG archive keys of the Debian a
ii libc62.7-15 GNU C Library: Shared libraries
ii libgcc1 1:4.3.2-1 GCC support library
ii libstdc++6 4.3.2-1 The GNU Standard C++ Library v3
apt recommends no packages.
Versions of packages apt suggests:
pn apt-doc(no description available)
ii aptitude 0.4.11.10-1lenny1.1+b1 terminal-based package manager
ii bzip2 1.0.5-1high-quality block-sorting file co
ii dpkg-dev 1.14.22Debian package development tools
ii lzma 4.43-14Compression method of 7z format in
ii synaptic 0.62.1 Graphical package manager
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#505207: update-alternatives could ignore errors in /usr/share/{doc,man,info}.
"ext Guillem Jover" writes: > Hmm, even if I agree with the sentiment, I don't really like the idea of > hardcoding those directories in u-a. dpkg is used outside Debian and > the policy or paths there might be different. Yes. > I think it would be better to add a new option --slave-optional (or a > similar and better name), and change the callers to use that. So the idea is that a package has a better idea of which alternatives are optional for it than policy? Yes, I agree. But if we require packages to be updated, wouldn't it be enough if they ignored errors reported by update-alternatives for optional alternatives? But even if it would be enough, making the situation more explicit with --slave-optional might be better. So, I agree with the option. I'll make a patch when I find the time. Thanks for the considerations! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#505207: update-alternatives could ignore errors in /usr/share/{doc,man,info}.
"ext Guillem Jover" writes: >> But if we require packages to be updated, wouldn't it be enough if they >> ignored errors reported by update-alternatives for optional >> alternatives? > > They can do that already if all the names to be set are optional (all > --install and all --slave). But not the case when --install is mandatory > but some --slave are not. Just for completeness of the discussion: you could call update-alternatives individually for each file, and check ignore errors (or not) individually, no? I don't know enough about update-alternatives, actually, so I'll shut up. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#505207: update-alternatives could ignore errors in /usr/share/{doc,man,info}.
Package: dpkg
Version: 1.14.22
Severity: wishlist
The update-alternatives program could be changed to explicitly ignore
errors that happen inside /usr/share/doc, and by extending the spirit of
Policy, it could also explicitly ignore errors in /usr/share/man and
/usr/share/info. Maybe also /usr/share/locale.
The idea is that files in the three directories are 'optional' and might
or might not be present. They could have been removed by the sysadmin
to save space, or might have even been filtered out automatically during
installation.
Every package that uses update-alternatives could be changed to ignore
errors for optional files, or update-alternatives could be changed
itself to ignore the errors.
The motivation comes from hacks like localepurge and docpurge (on
Maemo). And although these programs are hacks, the functionality they
try to provide is good. I expect dpkg to get support for filters
eventually.
Nobody probably makes alternatives inside /usr/share/locale, but at
least the openssh-client package maintains alternatives for man pages
and it's a real problem when docpurge removes /usr/share/man.
Sooo. I'll try the following patch in Maemo. It is probably quite
incomplete.
Index: scripts/update-alternatives.pl
===
--- scripts/update-alternatives.pl (revision 16457)
+++ scripts/update-alternatives.pl (working copy)
@@ -113,6 +113,21 @@ sub quit
exit(2);
}
+# Same as 'quit', but ignore errors related to documentation.
+#
+sub maybe_quit {
+my ($file, $msg) = @_;
+printf STDERR "%s: %s\n", $progname, $msg;
+if ($file =~ "^/usr/share/man/" ||
+ $file =~ "^/usr/share/info/" ||
+ $file =~ "^/usr/share/doc/")
+{
+ printf STDERR "%s: ignoring error.\n", $progname;
+} else {
+ exit (2);
+}
+}
+
sub badusage
{
printf STDERR "%s: %s\n\n", $progname, "@_";
@@ -705,12 +720,12 @@ sub rename_mv {
sub checked_symlink {
my ($filename, $linkname) = @_;
symlink($filename, $linkname) ||
- &quit(sprintf(_g("unable to make %s a symlink to %s: %s"), $linkname,
$filename, $!));
+ &maybe_quit($linkname, sprintf(_g("unable to make %s a symlink to %s:
%s"), $linkname, $filename, $!));
}
sub checked_mv {
my ($source, $dest) = @_;
rename_mv($source, $dest) ||
- &quit(sprintf(_g("unable to install %s as %s: %s"), $source, $dest,
$!));
+ &maybe_quit($source, sprintf(_g("unable to install %s as %s: %s"),
$source, $dest, $!));
}
sub config_all {
opendir ADMINDIR, $admindir or die sprintf(_g("Serious problem: %s"), $!);
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#374195: Can't do anything: "terminate called after throwing an instance of 'std::logic_error'"
I have seen this bug in version 0.6.42.3 and in my case the "terminate" output was due to a bug in DPkgPM::Go. That function fails to parse status outputs from dpkg that span more than one line. Specifically, this dpkg output causes DPkgPM::Go to crash (two lines): status: big : error : Package is in a very bad inconsistent state - you should reinstall it before attempting a removal. Note the second line that starts with a space. DPkgPM::Go can't deal with that; it doesn't expect continuation lines at all. Concretely, it is not checking that the call to TokSplitString actually has found the expected fields. (Bad boy! Go to bed without dinner!) Using dpkg --force-remove-reinstreq just gets rid of the problematic package and thus the bug is not triggered anymore. Fixing the crash by simply ignoring the second line is of course the easy and wrong solution. DPkgPM::Go should be able to deal with continuation lines like this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#374195: Can't do anything: "terminate called after throwing an instance of 'std::logic_error'"
"ext Michael Vogt" <[EMAIL PROTECTED]> writes: > I think dpkg should be patched to strip out the \n from the messages > that it sends over the status pipe. Yes, I agree. I originally thought that the format of the "status:" messages produced by dpkg specifically allows for multi-line output (by flagging additional lines with a starting space, like in the status file, etc). That was just a guess, tho. > I attached a patch for dpkg to strip out the \n when it sends errors > over the status pipe. Comments welcome. (I think it should be "stripped_emsg", not "striped_emsg", no?) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#518473: Support for netrc
+1 from me, too. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529040: magit: Missing dependency on emacsen packages
Adrian Glaubitz writes: > Since it is an dependency issue only, the bug should be fixable by > correcting the dependencies and rebuilding the package, shouldn't it? I'll have to make my mind up about this: some people use magit exclusively via tramp, and in that case git is only executed on the remote machine and not needed locally. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547788: apt: apt-get install gets confused with multiple available versions
doc (no description available)
ii aptitude 0.4.11.11-1+b2 terminal-based package manager
ii bzip2 1.0.5-3high-quality block-sorting file co
ii dpkg-dev 1.15.4 Debian package development tools
ii lzma 4.43-14Compression method of 7z format in
ii python-apt0.7.13.2 Python interface to libapt-pkg
ii synaptic 0.62.9 Graphical package manager
-- no debconf information
>From bde13f7a5099e1238b86e242bc8d59765366187a Mon Sep 17 00:00:00 2001
From: Marius Vollmer
Date: Tue, 22 Sep 2009 11:21:01 +0300
Subject: [PATCH] Be smarter when installing virtual packages.
* cmdline/apt-get.cc (TryToInstall): When selecting a real package
instead of a virtual one, ignore versions that are not candidates.
This allows us to survive repositories that contain more than one
version of a package.
---
cmdline/apt-get.cc | 45 -
1 files changed, 36 insertions(+), 9 deletions(-)
diff --git a/cmdline/apt-get.cc b/cmdline/apt-get.cc
index a7221d4..c1981c8 100644
--- a/cmdline/apt-get.cc
+++ b/cmdline/apt-get.cc
@@ -1045,15 +1045,42 @@ bool TryToInstall(pkgCache::PkgIterator Pkg,pkgDepCache &Cache,
unsigned int &ExpectedInst,bool AllowFail = true)
{
/* This is a pure virtual package and there is a single available
- provides */
- if (Cache[Pkg].CandidateVer == 0 && Pkg->ProvidesList != 0 &&
- Pkg.ProvidesList()->NextProvides == 0)
- {
- pkgCache::PkgIterator Tmp = Pkg.ProvidesList().OwnerPkg();
- ioprintf(c1out,_("Note, selecting %s instead of %s\n"),
- Tmp.Name(),Pkg.Name());
- Pkg = Tmp;
- }
+ candidate providing it. */
+ if (Cache[Pkg].CandidateVer == 0)
+{
+ pkgCache::PkgIterator Prov;
+ bool found_one = false, found_more_than_one = false;
+
+ for (pkgCache::PrvIterator P = Pkg.ProvidesList(); P; P++)
+{
+ pkgCache::VerIterator PVer = P.OwnerVer();
+ pkgCache::PkgIterator PPkg = PVer.ParentPkg();
+
+ if (Cache[PPkg].CandidateVer != PVer)
+{
+ /* Ignore versions that are not a candidate. */
+ continue;
+}
+
+ if (!found_one)
+{
+ Prov = PPkg;
+ found_one = true;
+}
+ else if (PPkg != Prov)
+{
+ found_more_than_one = true;
+ break;
+}
+}
+
+ if (found_one && !found_more_than_one)
+{
+ ioprintf(c1out,_("Note, selecting %s instead of %s\n"),
+ Prov.Name(),Pkg.Name());
+ Pkg = Prov;
+}
+}
// Handle the no-upgrade case
if (_config->FindB("APT::Get::upgrade",true) == false &&
--
1.6.3.3
Bug#547788: apt: apt-get install gets confused with multiple available versions
ext Goswin von Brederlow writes: > It even gets confused if multiple packages of the same version are > available. This can happen if proposed-updates and security have the > same version but different builds (and therefore checksums) of a > package. > > Have you considered what happens then? My patch ignores all package versions that are not a installation candidate. Since only one of the versions of a package can be the candidate, my patch should also handle your situation. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#430958: dpkg should call fsync() before rename()
I want to draw attention to this bug again.
We are now running into this problem on Maemo 5, which is using ubifs as
its root filesystem. Not syncing 'properly' on ubifs leads to
zero-length files, etc, very much like on ext4.
While the discussions rage about how fsync is not what applications want
(I agree, we just want a write barrier), and while filesystems are being
changed (hopefully in a way that doesn't need changes in almost all
applications anyway to make them robust again), we need to get back
robustness for dpkg.
Basically, I think we need to put a write barrier into the code so that
all filesystem operations done by dpkg are guaranteed to be committed
before the update to the status db is committed. This includes all file
writes done by maintainer scripts, so it will not be enough to just put
fsyncs into dpkg itself.
I propose to just put a big "sync" into modstatdb_note_core:
diff --git a/lib/dbmodify.c b/lib/dbmodify.c
index 87400f1..f4fc586 100644
--- a/lib/dbmodify.c
+++ b/lib/dbmodify.c
@@ -247,6 +247,8 @@ modstatdb_note_core(struct pkginfo *pkg)
{
assert(cstatus >= msdbrw_write);
+ sync();
+
varbufreset(&uvb);
varbufrecord(&uvb, pkg, &pkg->installed);
I hope this is enough and not much too much. We will apply this patch
for Maemo 5.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#348833: svn-buildpackage runs "debian/rules clean" before dpkg-checkbuilddeps
Package: svn-buildpackage Version: 0.6.7 When run without the --svn-dont-clean option, svn-buildpackage runs "debian/rules clean" without checking whether the build dependencies of the package are satisfied. If they are in fact not satisfied, running debian/rules might fail in strange ways. It would be better to run dpkg-checkbuilddeps first and abort when that fails. That gives a much clearer indication of what is wrong. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#611729: apt: apt-get does not always mark a package as manually installed
Package: apt
Version: 0.8.10
Severity: normal
Tags: patch
[ This bug has been found in Maemo's version of apt, absed on 0.7.25.3,
and has only confirmed to be present in Debian's version of apt by
reading the code. Thus, I don't include any information about my
Debian installation.
]
Apt-get does not always mark a package as manually installed when it
should. I only have a Gedanken Test Case for reproduction, sorry, but
it should be simple.
Consider this scenario:
Package: a
Depends: b
Package: b
Neither a nor b are installed. Then
$ apt-get install a b
will not mark b as manually installed.
The culprit is this code in cmd-line/apt-get.cc, function TryToInstall:
// see if we need to fix the auto-mark flag
// e.g. apt-get install foo
// where foo is marked automatic
if (State.Install() == false &&
(State.Flags & pkgCache::Flag::Auto) &&
_config->FindB("APT::Get::ReInstall",false) == false &&
_config->FindB("APT::Get::Only-Upgrade",false) == false &&
_config->FindB("APT::Get::Download-Only",false) == false)
{
ioprintf(c1out,_("%s set to manually installed.\n"),
Pkg.FullName(true).c_str());
Cache->GetDepCache()->MarkAuto(Pkg,false);
AutoMarkChanged++;
}
This code will not "fix the auto-mark flag" when State.Install() is
false. However, planning to install a will produce the state where
State.Install() is true for b, and State.Flags for b will include Auto.
The following variant of the code should make this work:
// see if we need to fix the auto-mark flag
// e.g. apt-get install foo
// where foo is marked automatic
if((State.Flags & pkgCache::Flag::Auto) &&
_config->FindB("APT::Get::ReInstall",false) == false &&
_config->FindB("APT::Get::Only-Upgrade",false) == false &&
_config->FindB("APT::Get::Download-Only",false) == false)
{
Cache->GetDepCache()->MarkAuto(Pkg,false);
AutoMarkChanged++;
// If we are not actually installing the package right
// now because it is already installed, at least
// mention that we are changing its auto flag.
if (State.Install() == false)
ioprintf(c1out,_("%s set to manually installed.\n"),
Pkg.FullName(true).c_str());
}
[ No patch since I didn't even compile this. ]
The logic behind this change is that it shouldn't matter whether or not
State.Install() is true when deciding whether to fix the auto-mark. All
we really want is to supress the message in the normal case where a
package is about to be installed.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#611729: apt: apt-get does not always mark a package as manually installed
ext Marius Vollmer writes: > This code will not "fix the auto-mark flag" when State.Install() is > false. Sorry, this should read: This code will not "fix the auto-mark flag" when State.Install() is TRUE. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#518818: ITP: magit -- A Emacs interface for Git
Package: wnpp Severity: wishlist Owner: Marius Vollmer * Package name: magit Version : 0.7 Upstream Author : Marius Vollmer * URL : http://zagadka.vm.bytemark.co.uk/magit/ * License : GPLv3, FDL Programming Lang: Elisp Description : A Emacs interface for Git With Magit, you can inspect and modify your Git repositories with Emacs. You can review and commit the changes you have made to the tracked files, for example, and you can browse the history of past changes. There is support for cherry picking, reverting, merging, rebasing, and other common Git operations. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593357: eperl assumes file descriptors 11,12,13 are unused
Package: eperl Version: 2.2.14-16 Severity: normal Eperl dups fd 1 to fd 11 when redirecting stdout (for example), and dups fd 11 back to fd 1 when undoing the redirection. This fails in interesting ways when fd 11 is used for something else. In my case, fd 11 was used for very file that stdout should be redirected to. I'll attach a patch. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages eperl depends on: ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libperl5.10 5.10.1-14 shared Perl library ii perl 5.10.1-14 Larry Wall's Practical Extraction ii perl-base [perlapi-5.10.1]5.10.1-14 minimal Perl system eperl recommends no packages. Versions of packages eperl suggests: pn libapache-mod-perl (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593358: eperl: eperl assumes file descriptors 11,12,13 are unused
Package: eperl
Version: 2.2.14-16
Severity: normal
Tags: patch
Eperl assumes that file descriptors 11, 12, and 13 are available for it
to save the old stdin, stdout, and stderr channels when redirecting IO.
This assumption is not always true.
Patch attached.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages eperl depends on:
ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib
ii libperl5.10 5.10.1-14 shared Perl library
ii perl 5.10.1-14 Larry Wall's Practical Extraction
ii perl-base [perlapi-5.10.1]5.10.1-14 minimal Perl system
eperl recommends no packages.
Versions of packages eperl suggests:
pn libapache-mod-perl (no description available)
-- no debconf information
Index: eperl/eperl_sys.c
===
--- eperl.orig/eperl_sys.c 2010-08-17 14:28:38.0 +0300
+++ eperl/eperl_sys.c 2010-08-17 14:28:49.0 +0300
@@ -100,21 +100,22 @@
#define HANDLE_STDIN 0
#define HANDLE_STDOUT 1
#define HANDLE_STDERR 2
-#define HANDLE_STORE_STDIN 10
-#define HANDLE_STORE_STDOUT 11
-#define HANDLE_STORE_STDERR 12
static int IO_redirected_stdin = FALSE;
static int IO_redirected_stdout = FALSE;
static int IO_redirected_stderr = FALSE;
+static int IO_handle_store_stdin;
+static int IO_handle_store_stdout;
+static int IO_handle_store_stderr;
+
void IO_redirect_stdin(FILE *fp)
{
if (IO_redirected_stdin)
IO_restore_stdin();
/* first copy the current stdin to the store handle */
-(void)dup2(HANDLE_STDIN, HANDLE_STORE_STDIN);
+IO_handle_store_stdin = dup(HANDLE_STDIN);
/* then copy the new handle to stdin */
(void)dup2(fileno(fp), HANDLE_STDIN);
@@ -129,7 +130,7 @@
IO_restore_stdout();
/* first copy the current stdout to the store handle */
-(void)dup2(HANDLE_STDOUT, HANDLE_STORE_STDOUT);
+IO_handle_store_stdout = dup(HANDLE_STDOUT);
/* then copy the new handle to stdout */
(void)dup2(fileno(fp), HANDLE_STDOUT);
@@ -144,7 +145,7 @@
IO_restore_stderr();
/* first copy the current stderr to the store handle */
-(void)dup2(HANDLE_STDERR, HANDLE_STORE_STDERR);
+IO_handle_store_stderr = dup(HANDLE_STDERR);
/* then copy the new handle to stderr */
(void)dup2(fileno(fp), HANDLE_STDERR);
@@ -171,7 +172,7 @@
void IO_restore_stdin(void)
{
if (IO_redirected_stdin) {
-dup2(HANDLE_STORE_STDIN, HANDLE_STDIN);
+dup2(IO_handle_store_stdin, HANDLE_STDIN);
IO_redirected_stdin = FALSE;
}
}
@@ -179,7 +180,7 @@
void IO_restore_stdout(void)
{
if (IO_redirected_stdout) {
-dup2(HANDLE_STORE_STDOUT, HANDLE_STDOUT);
+dup2(IO_handle_store_stdout, HANDLE_STDOUT);
IO_redirected_stdout = FALSE;
}
}
@@ -187,7 +188,7 @@
void IO_restore_stderr(void)
{
if (IO_redirected_stderr) {
-dup2(HANDLE_STORE_STDERR, HANDLE_STDERR);
+ dup2(IO_handle_store_stderr, HANDLE_STDERR);
IO_redirected_stderr = FALSE;
}
}
Bug#548858: apt fails to upgrade
Hi, Maemo here again!
We ran into a problem with the ordering algorithm as well. We bootstrap
all our istallations with just a long "apt-get install" invocation, and
any change to the handling of the base system affects us immediatly,
especially so since we do not really maintain the priorities of our
packages to any useful degree.
Anyway, after some analysis, I found these things:
- The ordering algorithm sometimes does not unpack a package that it
wants to to configure, and then fails.
Please review and possibly apply the attached patch.
- I don't think we need to propagate the Immediate flag at all. The
normal ordering algorithm should take care that all depends and
pre-depends of any package are correctly satisfied, including those
that are immediately configured.
Adding the immediate flag to more packages should not break anything,
and once the bug above is fixed, ordering does indeed succeed
regardless of whether the Immediate flag is propagated or not.
Progagating just isn't necessary and complicates matters. (Maybe it
was added as a workaround for the bug above?)
So, I think you should consider removing ImmediateAdd and all its
invokations.
- I made a small test where every package gets the immediate flag set
to see whether ordering still works in this stressy situation. (It
does.)
But configuring everything immediately is interesting in its own
right, I think. Packages are then left unconfigured for a shorter
time and thus chances are lower that they are left behind
unconfigured when the operation is interrupted. This might give more
robust interrupt/retry behavior since the system is in 'more
configured' state after the interruption.
Anyway, this is just food for thought.
Index: apt/apt-pkg/packagemanager.cc
===
--- apt.orig/apt-pkg/packagemanager.cc 2009-11-10 17:27:12.0 +0200
+++ apt/apt-pkg/packagemanager.cc 2009-11-10 17:27:55.0 +0200
@@ -299,6 +299,14 @@
if (OList.OrderConfigure() == false)
return false;
+ if (List->IsFlag(Pkg,pkgOrderList::Configured) == true)
+ {
+ // Pkg got configured during DepAdd. That happens when DepAdd
+ // causes SmartUnpack to be called for a package that has a
+ // pre-dependency on us.
+ return true;
+ }
+
// Perform the configuring
for (pkgOrderList::iterator I = OList.begin(); I != OList.end(); I++)
{
@@ -370,12 +378,21 @@
// Not the install version
if (Cache[Pkg].InstallVer != *I ||
(Cache[Pkg].Keep() == true && Pkg.State() == PkgIterator::NeedsNothing))
- continue;
-
- if (List->IsFlag(Pkg,pkgOrderList::UnPacked) == true)
- Bad = !DepAdd(OList,Pkg,Depth);
+ continue;
+
if (List->IsFlag(Pkg,pkgOrderList::Configured) == true)
- Bad = false;
+ {
+Bad = false;
+ }
+else if (List->IsFlag(Pkg,pkgOrderList::UnPacked) == true)
+ {
+Bad = !DepAdd(OList,Pkg,Depth);
+ }
+else
+ {
+// Not even unpacked
+Bad = !SmartUnPack (Pkg) || !DepAdd(OList,Pkg,Depth);
+ }
}
}
Bug#617643: apt: https method breaks with ignored range requests
Package: apt
Version: 0.8.10.3
Severity: normal
Tags: patch
The https method make a range request for files that are already
partially downloaded. However, it does not handle the case where the
server ignores the range request and replies with the complete file
anyway, which is legal (status code 200 OK and not status code 206
Partial Content).
The attached patch fixes this by simply not making any range requests.
That's not optimal, of course, but better than corrupting files.
I haven't really looked at libcurl to see what it would take to properly
support range requests. If just the status code needs to be checked,
then it should be fairly easy, but I am not totally sure about that.
-- Package-specific info:
-- (no /etc/apt/preferences present) --
-- (/etc/apt/sources.list present, but not submitted) --
-- System Information:
Debian Release: 6.0
APT prefers squeeze-updates
APT policy: (500, 'squeeze-updates'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686-bigmem (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages apt depends on:
ii debian-archive-keyring 2010.08.28 GnuPG archive keys of the Debian a
ii gnupg 1.4.10-4 GNU privacy guard - a free PGP rep
ii libc6 2.11.2-10Embedded GNU C Library: Shared lib
ii libgcc1 1:4.4.5-8GCC support library
ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3
ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime
apt recommends no packages.
Versions of packages apt suggests:
pn apt-doc(no description available)
ii aptitude0.6.3-3.2terminal-based package manager (te
ii bzip2 1.0.5-6 high-quality block-sorting file co
ii dpkg-dev1.15.8.10Debian package development tools
pn lzma (no description available)
ii python-apt 0.7.100.1Python interface to libapt-pkg
ii synaptic0.70~pre1+b1 Graphical package manager
-- no debconf information
Index: apt/methods/https.cc
===
--- apt.orig/methods/https.cc 2011-03-09 15:54:49.0 +0200
+++ apt/methods/https.cc 2011-03-09 15:56:51.0 +0200
@@ -99,7 +99,6 @@
bool HttpsMethod::Fetch(FetchItem *Itm)
{
stringstream ss;
- struct stat SBuf;
struct curl_slist *headers=NULL;
char curl_errorstr[CURL_ERROR_SIZE];
long curl_responsecode;
@@ -249,25 +248,20 @@
// error handling
curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, curl_errorstr);
- // if we have the file send an if-range query with a range header
- if (stat(Itm->DestFile.c_str(),&SBuf) >= 0 && SBuf.st_size > 0)
- {
- char Buf[1000];
- sprintf(Buf,"Range: bytes=%li-\r\nIf-Range: %s\r\n",
- (long)SBuf.st_size - 1,
- TimeRFC1123(SBuf.st_mtime).c_str());
- headers = curl_slist_append(headers, Buf);
- }
- else if(Itm->LastModified > 0)
+ if(Itm->LastModified > 0)
{
curl_easy_setopt(curl, CURLOPT_TIMECONDITION, CURL_TIMECOND_IFMODSINCE);
curl_easy_setopt(curl, CURLOPT_TIMEVALUE, Itm->LastModified);
}
- // go for it - if the file exists, append on it
+ // go for it
+
+ // XXX - If the file exists, we replace it completely. using a
+ // range request would be better, but then we need to handle
+ // all the possible responses to it, which doesn't seem to be
+ // entirely trivial.
+
File = new FileFd(Itm->DestFile, FileFd::WriteAny);
- if (File->Size() > 0)
- File->Seek(File->Size() - 1);
// keep apt updated
Res.Filename = Itm->DestFile;
Bug#982841: ifupdown scripts interfere with bond setup
Package: network-manager Version: 1.28.0-2+b1 NetworkManager runs the ifupdown scripts on certain events, but especially /etc/network/if-post-down.d/ifenslave interferes with bond setup somehow. See https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/660 for the investigation. NM upstream says: That's bad. The script shouldn't to that. Please report it to debian or ifenslave package. So here you go. :)
Bug#982841: [Pkg-utopia-maintainers] Bug#982841: ifupdown scripts interfere with bond setup
Michael Biebl writes: > Am 15.02.21 um 09:29 schrieb Marius Vollmer: >> Package: network-manager >> Version: 1.28.0-2+b1 >> >> NetworkManager runs the ifupdown scripts on certain events, but >> especially /etc/network/if-post-down.d/ifenslave interferes with bond >> setup somehow. > > Since /etc/network/if-post-down.d/ifenslave is shipped by the ifenslave > package, I wonder why you filed this against network-manager. Because /etc/NetworkManager/dispatcher.d/01-ifupdown is owned by the network-manager package. It didn't immediately make sense to me that NM calls the ifupdown scripts at all, since I thought that NM itself does all the work of setting up the interfaces. I saw a confusion of authority there, and it is created by the network-manager package, so that seemed like a reasonable place to start. > Are you suggesting that I remove > /etc/NetworkManager/dispatcher.d/01-ifupdown? I don't see another way > to address in network-manager besides not running ifupdown hook at all > anymore. I am afraid I can't suggest any kind of fix. I have CCed one of the upstream NetworkManager maintainer. Thanks!
Bug#886811: Can't do system-wide mounts/unmounts in a ssh sessions
Package: openssh-server Version: 1:7.6p1-2 Mounting or unmounting filesystems from within a ssh session used to affect all processes, but now it only affects ssh sessions (all of them, not just the one doing the mounts/unmounts). To reproduce: $ ssh root@debian-box # dd if=/dev/zero of=/disk.img bs=1M count=20 # dev=$(losetup --show --find /disk.img) # mkfs.ext4 $dev # mount $dev /mnt # grep /mnt /proc/self/mounts /dev/loop0 /mnt ext4 rw,relatime,data=ordered 0 0 # grep /mnt /proc/1/mounts It seems that sshd and all its sessions are now in a single dedicated "mnt" namespace: # lsns NS TYPE NPROCS PID USER COMMAND ... 4026532316 mnt 1 508 root /usr/sbin/sshd -D ...
Bug#1006440: Packagekit returns wrong package ids, fails to update packages
Package: packagekit Version: 1.2.4-1 This started happening after getting these updates: apt (2.3.15 -> 2.4.0) debianutils (4.11.2 -> 5.7-0.1) golang-github-containernetworking-plugins (0.9.1+ds1-1 -> 1.0.1+ds1-1) golang-github-containers-dnsname (1.3.1+ds1-1+b1 -> 1.3.1+ds1-2) nftables (1.0.1-1 -> 1.0.2-1) python3.9 (3.9.10-1 -> 3.9.10-2) Packagekit itself didn't change when this bug started happening, but we observe it with PackageKit so let's start here. Let there be two versions of a package, "vapor 1-1" and "vapor 1-2". "vapor 1-1" is installed and "vapor 1-2" is available as an update. Then we observe this: # pkcon get-updates Normal vapor-1-2.all (local) dummy vapor All good. # pkcon resolve vapor Installed vapor-1-1.all (manual:local) dummy vapor Available vapor-1-2.all (local) dummy vapor Still good although it used to say "installed:local" instead of "manual:local" for "vapor-1.1.all". # pkcon get-update-detail vapor Details about the update: Package: vapor-1-1.all Updates: vapor;1-1;all;manual:local Update text: Changes: Changelog for this version is not yet available Issued: Updated: # pkcon update vapor There are no updates available at this time. This is wrong. PK returns details about "vapor-1-1.all" instead of "vapor-1-2.all", and indeed doesn't recognize that 1-2 is available when actually asking it to do the update. This can also be observed in the D-Bus API: - GetUpdates returns "vapor;1-2;all;local" - GetUpdateDetails for "vapor;1-2;all;local" emits the UpdateDetails signal for "vapor;1-1;all;manual:local".
Bug#1006440: Packagekit returns wrong package ids, fails to update packages
Version: 1.2.5 > Packagekit itself didn't change when this bug started happening, but we > observe it with PackageKit so let's start here. Sorry, this is incorrect, I was confused when looking at our apdate logs. We did update packagekit, from 1.2.4 to 1.2.5. The updates to apt and debianutils are not needed to reproduce this bug. Sorry for the confusion.
