Bug#613091: python-alsaaudio: Unable to cotrol software mixer
This issue is fixed in pyalsaaudio 0.8 (released May 2015): https://github.com/larsimmisch/pyalsaaudio Any chance of getting the current 0.8.2 version packaged for Debian?
Bug#545766: wpasupplicant: wpa-roam doesnt work w/ physical logical interface map; wpa_action produced "already configured" error.
Tags: patch
A patch for this issue is attached. Basically, the existing `grep
^$WPA_IFACE=$WPA_IFACE" "$IFSTATE_FILE"` line is replaced with `/sbin/ifquery
"$WPA_IFACE" | grep -q '^wpa-roam: '`.
In addition to fixing the reported physical=logical interface issue above, this
patch also ensures that wpa-roam works with the recent ifstate file changes
made in ifupdown, and future-proofs the code against future changes to the
ifstate file behavior in ifupdown.
This patch was originally posted at
https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1545363 which is a duplicate
of this bug.
Index: debian/ifupdown/functions.sh
===
--- debian/ifupdown/functions.sh(revision 1965)
+++ debian/ifupdown/functions.sh(working copy)
@@ -890,7 +890,6 @@
#
ifup () {
local INTERFACES_FILE
- local IFSTATE_FILE
local IFUP_RETVAL
local WPA_LOGICAL_IFACE
@@ -901,16 +900,6 @@
return 1
fi
- if [ -e /etc/network/run/ifstate ]; then
- # debian's ifupdown
- IFSTATE_FILE="/etc/network/run/ifstate"
- elif [ -e /run/network/ifstate ]; then
- # ubuntu's
- IFSTATE_FILE="/run/network/ifstate"
- else
- unset IFSTATE_FILE
- fi
-
if [ -z "$IF_WPA_MAPPING_SCRIPT_PRIORITY" ] && [ -n "$WPA_ID_STR" ];
then
WPA_LOGICAL_IFACE="$WPA_ID_STR"
fi
@@ -953,7 +942,7 @@
ifupdown_lock
- if [ -n "$IFSTATE_FILE" ] && grep -q "^$WPA_IFACE=$WPA_IFACE"
"$IFSTATE_FILE"; then
+ if /sbin/ifquery "$WPA_IFACE" | grep -q '^wpa-roam: ' ; then
# Force settings over the unconfigured "master" IFACE
/sbin/ifup -v --force "$WPA_IFACE=$WPA_LOGICAL_IFACE"
else
Bug#519363: ifupdown: wpa-roam doesn't run (pre-|post-|)down scripts
Dmitry: Moving the script lines from the 'iface wlp3s0' section to the 'iface dynamic' section should make it behave the way you expect it to. The problem is simply that the 'iface wlp3s0' section is overridden and ignored after wpa_supplicant associates with an AP and the wpa-roam feature re-configures the interface using the 'iface dynamic' section.
Bug#690087: selinux-policy-default: sshd shell transitions are always denied
To work around this issue without patching and recompiling the policy:
cd /etc/selinux/ ; mkdir -p fixes ; cd fixes/
Create ssh_cat_fix.te
module ssh_cat_fix 1.0;
require {
type sshd_t;
}
typeattribute sshd_t mcssetcats;
checkmodule -m -M -o ssh_cat_fix.mod ssh_cat_fix.te
semodule_package -m ssh_cat_fix.mod -o ssh_cat_fix.pp
rm ssh_cat_fix.mod
semodule -i ssh_cat_fix.pp
On Tue, Oct 09, 2012 at 04:12:52PM -0400, Paul Donohue wrote:
> Package: selinux-policy-default
> Version: 2:2.20110726-3
> Severity: important
>
> When protecting sshd with this policy, the transition that occurs when running
> the user's shell is always denied, which prevents users from logging in:
> type=AVC msg=audit(1349808486.496:121): avc: denied { transition } for
> pid=3120 comm="sshd" path="/bin/bash" dev=dm-0 ino=554
> scontext=system_u:system_r:sshd_t:s0
> tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
>
> The reason is that the daemon has no MCS categories assigned to it, so the mcs
> policy constraints prevent the addition of categories.
>
> As best as I can tell, sshd is not supposed to have any categories, and the
> user
> is supposed to have categories, so this behavior should be allowed. (Did I
> miss
> something here?)
>
> Assuming this behavior should be allowed, editing
> policy/modules/system/authlogin.if and adding mcs_process_set_categories($1)
> in the auth_login_pgm_domain interface fixes this problem.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#690086: More info (selinux-policy-default: Upstart jobs do not transition properly)
I found and enabled the init_upstart boolean (it was disabled by default). Reading the policy, it looks like that should solve this problem, but it didn't actually seem to help... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#690087: selinux-policy-default: sshd shell transitions are always denied
Package: selinux-policy-default
Version: 2:2.20110726-3
Severity: important
When protecting sshd with this policy, the transition that occurs when running
the user's shell is always denied, which prevents users from logging in:
type=AVC msg=audit(1349808486.496:121): avc: denied { transition } for
pid=3120 comm="sshd" path="/bin/bash" dev=dm-0 ino=554
scontext=system_u:system_r:sshd_t:s0
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
The reason is that the daemon has no MCS categories assigned to it, so the mcs
policy constraints prevent the addition of categories.
As best as I can tell, sshd is not supposed to have any categories, and the user
is supposed to have categories, so this behavior should be allowed. (Did I miss
something here?)
Assuming this behavior should be allowed, editing
policy/modules/system/authlogin.if and adding mcs_process_set_categories($1)
in the auth_login_pgm_domain interface fixes this problem.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#690086: selinux-policy-default: Upstart jobs do not transition properly
Package: selinux-policy-default Version: 2:2.20110726-3 Severity: normal Upstart runs as init_t. When running SysV init scripts, Upstart transitions to initrc_t when the init script is run, then transitions again to an appropriate domain when the daemon executable is run. However, when managing jobs directly with Upstart (for example, sshd in Ubuntu), this doesn't work properly. Upstart does not transition to initrc_t before running the daemon executable, so the normal daemon transition does not occur. The simple fix is to edit the Upstart job and have it run the daemon using 'runcon'. However, this is not really a scalable solution. The best way I can think to fix this is to extend the policy to allow init_t to transition directly to daemon contexts. Basically, in policy/modules/system/init.if, domtrans_pattern(init_t, $2, $1) should be added next to any call to domtrans_pattern(initrc_t, $2, $1). I can submit a patch for this if it would help. Of course, I'm open to other fixes if someone knows of a better solution. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#468246: rrdtool from 1.2.27 package is actually version 1.2.19
Package: rrdtool Version: 1.2.27-1 Severity: important The rrdtool binary in the 1.2.27 package is actually version 1.2.19 The rrdupdate binary appears to be the correct version # rrdupdate RRDtool 1.2.27 Copyright by Tobi Oetiker, 1997-2008 [...] # rrdtool RRDtool 1.2.19 Copyright 1997-2007 by Tobias Oetiker <[EMAIL PROTECTED]> Compiled May 22 2007 13:51:13 Usage: rrdtool [options] command command_options [...] Could you please repackage it with a fresh rrdtool binary? Thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#416452: sun-java5-jre: Any updates on the timezone bug?
Package: sun-java5-jre Version: 1.5.0-14-3 Followup-For: Bug #416452 Any updates regarding this bug? The sun-java6 packages area also affected by this bug ... I wonder if this bug should be reassigned to sun-java6, or if the bug should be duplicated on that package? It appears that the bug has been fixed in IcedTea: http://icedtea.classpath.org/hg/icedtea/rev/cb78e0fccf14 I'm not sure if that fix was part of the changes imported with OpenJDK b21 into IcedTea or if it was fixed in IcedTea only... For reference, here are related bug reports on Ubuntu and SDN: https://bugs.launchpad.net/debian/+source/sun-java5/+bug/102937 https://bugs.launchpad.net/ubuntu/+source/sun-java6/+bug/49068 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6456628 Thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457110: aptitude: Add support for section hierarchies more than two levels deep
[SNIP] > So my thought was that it would be more workable for them if I did > some up-front work to create a .po file for section descriptions. [SNIP] > On the other hand, all that works only in the default configuration, > and we'd still need a way to translate sections when the default file > has been modified. So maybe I just need to support a directory of > section translations and let the translators deal with it. Probably > they can just copy the default file and edit it appropriately to create > a Aptitude::Sections::Descriptions:: configuration group. [SNIP] Lemme know if you want me to do anything. Should I split out the external description configuration from the top-level section configuration and multi-level section description code in this patch? Is there any translation-related coding you'd like me to attempt? Thanks! -Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457110: aptitude: Add support for section hierarchies more than two levels deep
Hmmm. I attempted to write the section descriptions to be compatible with unicode ... the idea being that translators could simply write their own copies of the default config file... I don't know how successful I was (I didn't actually test it with unicode), and I'm not sure how elegant of a solution this is (as it would require swapping config files rather than simply changing the locale at runtime). Perhaps Aptitude::Sections::Descriptions could be extended to allow specification of descriptions in multiple languages, where the appropriate description is selected at runtime based on locale? I'm not deeply familiar with gettext, but from some quick reading of the docs, it looks like xgettext just needs some sort of identifier for translatable strings ... perhaps the description strings could be modified in some way that is benign from the config parser's perspective but marks the strings from xgettext's perspective? I haven't fully thought this through ... just kinda thinking out loud here. -Paul On Wed, Jan 16, 2008 at 05:51:31PM -0800, Daniel Burrows wrote: > On Fri, Jan 04, 2008 at 11:11:43AM -0500, Paul Donohue <[EMAIL PROTECTED]> > was heard to say: > > One more update... patch.topdir attached now uses the first entry > > listed in Aptitude::Sections::Top-Sections as a default if the top-level > > section is not recognized ... the previous patch was still using a > > hard-coded 'main' by default when the top-level section was not > > recognized. > > I like the idea of not hardcoding the set of known top-level sections, > but as I was looking over this I realized there's an issue I didn't even > think about earlier (or if I did I've forgotten). How will translators > deal with this? Right now I just use gettext to translate section > descriptions, but that won't work if the descriptions are drawn from an > external configuration file. > > It should be sufficient to arrange for these strings to be marked up by > xgettext, and to run gettext over them at runtime. Unfortunately, > xgettext will only process program source code -- but if the > configuration file was generated at runtime from a template by a shell > program, xgettext could be run on the shell script. It's a little gross > but should work just fine. > > Christian, is there a better way of handling this situation? > > Daniel > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457110: aptitude: Add support for section hierarchies more than two levels deep
One more update... patch.topdir attached now uses the first entry
listed in Aptitude::Sections::Top-Sections as a default if the top-level
section is not recognized ... the previous patch was still using a
hard-coded 'main' by default when the top-level section was not
recognized.
diff -Naur aptitude.orig/aptitude-defaults aptitude.topdir/aptitude-defaults
--- aptitude.orig/aptitude-defaults 2008-01-04 10:52:49.0 -0500
+++ aptitude.topdir/aptitude-defaults 2008-01-04 11:00:19.0 -0500
@@ -141,3 +141,53 @@
};
};
+Aptitude::Sections
+{
+ Top-Sections "main,contrib,non-free,non-US";
+ Descriptions {
+Unknown"Packages with no declared section\n No section is given for
these packages. Perhaps there is an error in the Packages file?";
+Virtual"Virtual packages\n These packages do not exist; they are names
other packages use to require or provide some functionality.";
+Tasks "Packages which set up your computer to perform a particular
task\n Packages in the 'Tasks' section contain no files; they merely depend
upon other packages. These packages provide an easy way to select a predefined
set of packages for a specialized task.";
+
+admin "Administrative utilities (install software, manage users,
etc)\n Packages in the 'admin' section allow you to perform administrative
tasks such as installing software, managing users, configuring and monitoring
your system, examining network traffic, and so on.";
+alien "Packages converted from foreign formats (rpm, tgz, etc)\n
Packages in the 'alien' section were created by the 'alien' program from a
non-Debian package format such as RPM";
+base "The Debian base system\n Packages in the 'base' section are
part of the initial system installation.";
+comm "Programs for faxmodems and other communication devices\n
Packages in the 'comm' section are used to control modems and other hardware
communications devices. This includes software to control faxmodems (for
instance, PPP for dial-up internet connections and programs originally written
for that purpose, such as zmodem/kermit), as well as software to control
cellular phones, interface with FidoNet, and run a BBS.";
+devel "Utilities and programs for software development\n Packages in
the 'devel' section are used to write new software and work on existing
software. Non-programmers who do not compile their own software probably do not
need much software from this section.\n .\n It includes compilers, debugging
tools, programmer's editors, source processing tools, and other things related
to software development.";
+doc"Documentation and specialized programs for viewing
documentation\n Packages in the 'doc' section document parts of the Debian
system, or are viewers for documentation formats.";
+editors"Text editors and word processors\n Packages in the 'editors'
section allow you to edit plain ASCII text. These are not necessarily word
processors, although some word processors may be found in this section.";
+electronics"Programs for working with circuits and electronics\n
Packages in the 'electronics' section include circuit design tools, simulators
and assemblers for microcontrollers, and other related software.";
+embedded "Programs for embedded systems\n Packages in the 'embedded'
section are meant to run on embedded devices. Embedded devices are specialized
hardware devices with much less power than a typical desktop system: for
instance, a PDA, a cell phone, or a Tivo.";
+gnome "The GNOME Desktop System\n GNOME is a collection of software
which provides an easy-to-use desktop environment for Linux. Packages in the
'gnome' section are part of the GNOME environment or closely integrated into
it.";
+games "Games, toys, and fun programs\n Packages in the 'games'
section are meant primarily for entertainment.";
+graphics "Utilities to create, view, and edit graphics files\n Packages
in the 'graphics' section include viewers for image files, image processing and
manipulation software, software to interact with graphics hardware (such as
video cards, scanners, and digital cameras), and programming tools for handling
graphics.";
+hamradio "Software for ham radio operators\n Packages in the 'hamradio'
section are meant primarily for ham radio operators.";
+interpreters "Interpreters for interpreted languages\n Packages in the
'interpreters' section include interpreters for languages like Python, Perl,
and Ruby, and libraries for these same languages.";
+kde"The KDE Desktop System\n KDE is a collection of
software which provides an easy-to-use desktop environment for Linux. Packages
in the 'kde' section are part of the KDE environment or closely integrated into
it.";
+libdevel "Development files for libraries\n Packages in the 'libdevel'
section contain files required for building p
Bug#457110: aptitude: Add support for section hierarchies more than two levels deep
I've updated the remaining patches... New patches are attached.
patch.subdirs.default is the same as before, just updated with new line
numbers...
patch.topdir now accomplishes 3 things:
1) It still uses a list of "known" top-level sections to make the
'topdir' grouping policy work more intuitively when using 'subdirs',
however, it now allows external configuration of this list of top-level
sections using 'Aptitude::Sections::Top-Sections'.
2) It adds external configuration of the section descriptions using the
'Aptitude::Sections::Descriptions' group. I've therefore moved the
default section descriptions from pkg_grouppolicy.cc to
aptitude-defaults in the patch.
However, when testing testing this, aptitude doesn't seem to be reading
my new settings from aptitude-defaults. If I copy the aptitude-defaults
file to either ~/.aptitude/config or /etc/apt/apt.conf, it reads my
section descriptions fine, but if I just use
/usr/share/aptitude/aptitude-defaults or
/usr/local/share/aptitude/aptitude-defaults, it doesn't seem to read
them. I'm probably missing something obvious here...but you should
double-check it before committing it.
3) It slightly modifies the code in add_package to allow section
descriptions to be specified for a complete multi-level section rather
than only for the last component of each section.
For example, let's say I wanted to have a section devel/perl, and
another section web/perl. The previous code would display the same
description for both, since it only used the last part of the section
('perl') to determine the section description to display. The new code
can display different descriptions for each:
Aptitude::Sections
{
Descriptions {
devel "Utilities and programs for software development\n ...";
devel/perl "Utilities and programs for software development using Perl\n
...";
web "Web browsers, servers, proxies, and other tools\n ...";
web/perl"Web-related perl modules\n ...";
};
};
When using section(subdir), this will appear in aptitude as:
--\ Installed Packages
--\ devel/perl - Utilities and programs for software development using Perl
--\ web/perl - Web-related perl modules
When using section(subdirs), it will appear as:
--\ Installed Packages
--\ devel - Utilities and programs for software development
--\ perl - Utilities and programs for software development using Perl
--\ web - Web browsers, servers, proxies, and other tools
--\ perl - Web-related perl modules
Thanks!
-Paul
diff -Naur aptitude.orig/aptitude-defaults aptitude.topdir/aptitude-defaults
--- aptitude.orig/aptitude-defaults 2008-01-03 17:28:45.0 -0500
+++ aptitude.topdir/aptitude-defaults 2008-01-03 17:58:41.0 -0500
@@ -141,3 +141,53 @@
};
};
+Aptitude::Sections
+{
+ Top-Sections "main,contrib,non-free,non-US";
+ Descriptions {
+Unknown"Packages with no declared section\n No section is given for
these packages. Perhaps there is an error in the Packages file?";
+Virtual"Virtual packages\n These packages do not exist; they are names
other packages use to require or provide some functionality.";
+Tasks "Packages which set up your computer to perform a particular
task\n Packages in the 'Tasks' section contain no files; they merely depend
upon other packages. These packages provide an easy way to select a predefined
set of packages for a specialized task.";
+
+admin "Administrative utilities (install software, manage users,
etc)\n Packages in the 'admin' section allow you to perform administrative
tasks such as installing software, managing users, configuring and monitoring
your system, examining network traffic, and so on.";
+alien "Packages converted from foreign formats (rpm, tgz, etc)\n
Packages in the 'alien' section were created by the 'alien' program from a
non-Debian package format such as RPM";
+base "The Debian base system\n Packages in the 'base' section are
part of the initial system installation.";
+comm "Programs for faxmodems and other communication devices\n
Packages in the 'comm' section are used to control modems and other hardware
communications devices. This includes software to control faxmodems (for
instance, PPP for dial-up internet connections and programs originally written
for that purpose, such as zmodem/kermit), as well as software to control
cellular phones, interface with FidoNet, and run a BBS.";
+devel "Utilities and programs for software development\n Packages in
the 'devel' section are used to write new software and work on existing
software. Non-programmers who do not compile their own software probably do not
need much software from this section.\n .\n It includes compilers, debugging
tools, programmer's editors, source processing tools, and other things related
to software development.";
+doc"Documentation and specialized programs for viewing
documentation
Bug#140963: openssh-server: Forgotten Bug?
Package: openssh-server Version: 1:4.6p1-5 Followup-For: Bug #140963 This seems like a simple fix for such an ancient and annoying bug... Any chance it'll get applied any time soon? Thanks. -Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457110: aptitude: Add support for section hierarchies more than two levels deep
Awesome! Thanks so much! Let me know when you get a chance to look at the others. Happy New Year! -Paul On Sun, Dec 30, 2007 at 01:02:46PM -0800, Daniel Burrows wrote: > OK, I've worked through and applied the first (main) patch in this > collection. > > Daniel > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457110: updated patch
Just noticed I forgot to strip some of the references to 'max-levels' out of
the documentation updates in patch.subdirs
Here's an updated patch...
diff -Naur aptitude.orig/doc/en/aptitude.xml
aptitude.subdirs/doc/en/aptitude.xml
--- aptitude.orig/doc/en/aptitude.xml 2007-12-19 12:53:15.0 -0500
+++ aptitude.subdirs/doc/en/aptitude.xml2007-12-20 10:34:45.0
-0500
@@ -5357,7 +5357,8 @@
Group based on the whole Section field, so
categories like non-free/games will be
- created.
+ created. This is the default if no
+ mode is specified.
@@ -5367,10 +5368,11 @@
- Group based on the part of the Section field
- before the /; if
there is
- no /,
- main will be used instead.
+ Group based on the part of the Section field before the
+ first / character; if there is no
+ /,
+ main will be used
+ instead.
@@ -5380,10 +5382,23 @@
- Group based on the part of the Section field
- after the /; if there
is
- no /, the entire field will
- be used.
+ Group based on the part of the Section field after the
+ first / character; if there is no
+ /, the entire field will be used.
+
+
+
+
+
+ subdirs
+
+
+
+ Group based on the part of the Section field after the
+ first / character; if there is no
+ /, the entire field will be used; if
+ there are multiple / characters,
+ a hierarchy of groups will be formed.
diff -Naur aptitude.orig/src/load_grouppolicy.cc
aptitude.subdirs/src/load_grouppolicy.cc
--- aptitude.orig/src/load_grouppolicy.cc 2007-12-19 12:53:19.0
-0500
+++ aptitude.subdirs/src/load_grouppolicy.cc2007-12-20 10:33:31.0
-0500
@@ -364,8 +364,10 @@
split_mode=pkg_grouppolicy_section_factory::split_topdir;
else if(!strcasecmp(args[0].c_str(), "subdir"))
split_mode=pkg_grouppolicy_section_factory::split_subdir;
+ else if(!strcasecmp(args[0].c_str(), "subdirs"))
+ split_mode=pkg_grouppolicy_section_factory::split_subdirs;
else
- throw GroupParseException(_("Bad section name '%s' (use 'none',
'topdir', or 'subdir')"), args[0].c_str());
+ throw GroupParseException(_("Bad section name '%s' (use 'none',
'topdir', 'subdir', or 'subdirs')"), args[0].c_str());
}
if(args.size() >= 2)
diff -Naur aptitude.orig/src/pkg_grouppolicy.cc
aptitude.subdirs/src/pkg_grouppolicy.cc
--- aptitude.orig/src/pkg_grouppolicy.cc2007-12-19 12:53:19.0
-0500
+++ aptitude.subdirs/src/pkg_grouppolicy.cc 2007-12-20 10:33:31.0
-0500
@@ -213,81 +213,95 @@
void pkg_grouppolicy_section::add_package(const pkgCache::PkgIterator &pkg,
pkg_subtree *root)
{
- const char *section=pkg.VersionList().Section();
- const char *name=pkg.Name();
- bool maypassthrough=false; // FIXME: HACK!
-
- if(name[0] == 't' && name[1] == 'a' && name[2] == 's' && name[3] == 'k' &&
name[4] == '-')
+ // Determine Section
+ string section;
+ if(!strncmp(pkg.Name(), "task-", 5))
+section=_("Tasks");
+ else if(pkg.VersionList().end())
+section=_("virtual");
+ else if(!pkg.VersionList().Section())
+section=_("Unknown");
+ else
{
- maypassthrough=true;
-
section=split_mode!=pkg_grouppolicy_section_factory::split_none?_("Tasks/Tasks"):_("Tasks");
-}
+ section=pkg.VersionList().Section();
- if(!section)
-{
- maypassthrough=true;
-
section=split_mode!=pkg_grouppolicy_section_factory::split_none?_("Unknown/Unknown"):_("Unknown");
+ // Split Section based on split_mode
+ string::size_type first_split=section.find('/');
+ if(split_mode==pkg_grouppolicy_section_factory::split_topdir)
+
section=(first_split!=section.npos?section.substr(0,first_split):_("main"));
+ else if((split_mode==pkg_grouppolicy_section_factory::split_subdir ||
+ split_mode==pkg_grouppolicy_section_factory::split_subdirs) &&
+ first_split!=section.npos)
+ section=section.substr(first_split+1);
}
-
Bug#457110: Aptitude Grouping Patch
On Wed, Dec 19, 2007 at 09:24:47PM -0800, Daniel Burrows wrote:
> On Wed, Dec 19, 2007 at 04:41:58PM -0500, Paul Donohue was heard to say:
> > To make things clearer and more readable, I've broken the subdirs patch
> > out into several patches anyway.
> >
> > I've also removed all the code for the 'max-levels' parameter. (When I
> > originally coded the patch, I wasn't sure how robust aptitude was, so I
> > put that parameter in there incase I ran into problems with packages
> > with tons of nested sections, and needed to limit the nesting ... I
> > haven't actually run into any problems, and this parameter added a lot
> > of cruft to the patch, so I stripped it out ... if you want it back, let
> > me know ... I suppose there is still some value in it ... with
> > max-levels set to 1, subdirs is the same as subdir, so we could
> > eliminate subdir and use max-levels instead if you wanted).
>
> I think that's probably fine. I can easily add the feature back in
> if someone has a use-case for it. Regarding your other comment, I'm
> not really interested in eliminating options from the code: they might
> still be in use in the wild, and breaking people's configuration without
> a really good reason is un-neighborly.
>
> > patch.subdirs is the main patch ... I've stripped as much cruft out of
> > it as possible. The changes to add_package aren't particularly readable
> > in the diff file itself, but if you patch the file and compare the
> > original and patched copies, the new function is organized in much the
> > same way as the original, so the similarities and differences should be
> > reasonably clear.
>
> Ok, I'll take a look at this later. If you don't hear from me by next
> Monday, send me a ping email.
>
> > BTW ... is the 'task' package handling code in add_package still valid?
> > It kinda looks like this code was intended for an old task mechanism that
> > is no longer in use... I kept the old functionality just incase.
>
> Yes, I don't think we use those task packages any more ... but again,
> I don't know what odd configurations are out there in the wild. I'd
> like to avoid breaking it if possible.
>
> > patch.subdirs.topdir adds a hack for identifying top-level sections.
>
> If I can summarize to see if I understand what this is intended to do
> (I haven't even glanced at the code yet): it essentially codes the
> Debian archive division into the aptitude source, right? The main
> problem I see here is that it'll make work for the Ubuntu guys and other
> repackagers, who may not have the same archive division as Debian.
> OTOH, I suppose that I already do that anyway!
Yes, exactly.
Keeping the Ubuntu guys in mind, the hard-coded archive division is
implemented simply as a string defined in init_section_descriptions()
The Ubuntu guys are already patching this function to include
descriptions for their archive sections, so hopefully it won't be a
problem for them to also update my hard-coded string to define their
top-level sections.
...from
http://archive.ubuntu.com/ubuntu/pool/main/a/aptitude/aptitude_0.4.6.1-1ubuntu3.diff.gz:
- section_descriptions["contrib"]=transcode(_("Programs which depend on
software not in Debian\n Packages in the 'contrib' section are not part of
Debian.\n .\n These packages are Free Software, but they depend on software
which is not part of Debian. This may be because it is not Free Software, but
is packaged in the non-free section of the archive, because Debian cannot
distribute it at all, or (in rare cases) because no-one has packaged it yet.\n
.\n For more information about what Debian considers to be Free Software, see
http://www.debian.org/social_contract#guidelines";));
- section_descriptions["main"]=transcode(_("The main Debian archive\n The
Debian distribution consists of packages from the 'main' section. Every package
in 'main' is Free Software.\n .\n For more information about what Debian
considers to be Free Software, see
http://www.debian.org/social_contract#guidelines";));
- section_descriptions["non-US"]=transcode(_("Programs stored outside the US
due to export controls\n Packages in 'non-US' likely contain cryptography; a
few implement patented algorithms. Because of this, they cannot be exported
from the United States, and hence are stored on a server in the \"free
world\".\n .\n Note: the Debian Project is currently merging cryptographic
software into the US-based archives after consulting with legal experts about
recent changes in export policies. Most packages which were formerly
Bug#457110: aptitude: Add support for section hierarchies more than two levels deep
Package: aptitude
Version: 0.4.10
Severity: wishlist
Tags: patch
I run my own package repository, and I'd like to be able to organize
packages in a Section-based hierarchy that is more than two levels
deep.
For example (I'm stealing this example from Daniel Burrows...),
imagine a Packages file that says:
Package: foo++
Section: devel/c++/template-libraries
...
Package: hwidget
Section: devel/haskell
...
Package: excelsior
Section: devel/otherosfs/msoffice/excel/oh/god/the/nesting/horror
...
I'd like to see a hierarchy in aptitude that looks like:
--\ Not Installed Packages
--\ devel
--\ c++
--\ template-libraries
pp foo++
...
--\ haskell
pp hwidget
...
--\ otherosfs
--\ msoffice
--\ excel
... etc.
Attached are a few patches to accomplish this... They could probably
use some refinement, so feel free to provide feedback, and I'll do my
best to make them fit for public consumption.
Thanks!
-Paul
diff -Naur aptitude.orig/doc/en/aptitude.xml
aptitude.subdirs/doc/en/aptitude.xml
--- aptitude.orig/doc/en/aptitude.xml 2007-12-19 12:53:15.0 -0500
+++ aptitude.subdirs/doc/en/aptitude.xml2007-12-19 15:03:57.0
-0500
@@ -5357,7 +5357,8 @@
Group based on the whole Section field, so
categories like non-free/games will be
- created.
+ created. This is the default if no
+ mode is specified.
@@ -5367,10 +5368,11 @@
- Group based on the part of the Section field
- before the /; if
there is
- no /,
- main will be used instead.
+ Group based on the part of the Section field before the
+ first / character; if there is no
+ /,
+ main will be used
+ instead.
@@ -5380,10 +5382,27 @@
- Group based on the part of the Section field
- after the /; if there
is
- no /, the entire field will
- be used.
+ Group based on the part of the Section field after the
+ first / character; if there is no
+ /, the entire field will be used.
+
+
+
+
+
+ subdirs
+
+
+
+ Group based on the part of the Section field after the
+ first / character; if there is no
+ /, the entire field will be used; if
+ there are multiple / characters,
+ a hierarchy of groups will be formed, up to
+ max-levels deep. If
+ max-levels is set to
+ 1, this behaves like
+ subdir.
diff -Naur aptitude.orig/src/load_grouppolicy.cc
aptitude.subdirs/src/load_grouppolicy.cc
--- aptitude.orig/src/load_grouppolicy.cc 2007-12-19 12:53:19.0
-0500
+++ aptitude.subdirs/src/load_grouppolicy.cc2007-12-19 15:03:57.0
-0500
@@ -364,8 +364,10 @@
split_mode=pkg_grouppolicy_section_factory::split_topdir;
else if(!strcasecmp(args[0].c_str(), "subdir"))
split_mode=pkg_grouppolicy_section_factory::split_subdir;
+ else if(!strcasecmp(args[0].c_str(), "subdirs"))
+ split_mode=pkg_grouppolicy_section_factory::split_subdirs;
else
- throw GroupParseException(_("Bad section name '%s' (use 'none',
'topdir', or 'subdir')"), args[0].c_str());
+ throw GroupParseException(_("Bad section name '%s' (use 'none',
'topdir', 'subdir', or 'subdirs')"), args[0].c_str());
}
if(args.size() >= 2)
diff -Naur aptitude.orig/src/pkg_grouppolicy.cc
aptitude.subdirs/src/pkg_grouppolicy.cc
--- aptitude.orig/src/pkg_grouppolicy.cc2007-12-19 12:53:19.0
-0500
+++ aptitude.subdirs/src/pkg_grouppolicy.cc 2007-12-19 16:04:04.0
-0500
@@ -213,81 +213,95 @@
void pkg_grouppolicy_section::add_package(const pkgCache::PkgIterator &pkg,
pkg_subtree *root)
{
- const char *section=pkg.VersionList().Section();
- const char *name=pkg.Name();
- bool maypassthrough=false; // FIXME: HACK!
-
- if(name[0] == 't' && name[1] == 'a' && name[2] == 's' && name[3] == 'k' &&
name[4] == '-')
+ // Determine Section
+ string section;
+ if(!strncmp(pkg.Name(), "task-", 5))
+section=_("Tasks");
+ else
Bug#431060: rrdtool update?
It's been another month and 1.2.26 is out already... Any news? In addition to numerous bug fixes, 1.2.24 and later now use fadvise which should significantly improve performance. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#446782: libapache2-mod-proxy-html: New Upstream Available
Package: libapache2-mod-proxy-html
Version: 2.5.2-1.1
Severity: wishlist
http://apache.webthing.com/mod_proxy_html/
The current version is 3.0.0 (July 31st 2007).
The new version supports environment variable substitution, which is especially
useful for Virtual Hosts (${HTTP_HOST} can be substituted instead of a fixed
hostname).
Thanks!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435718: wpasupplicant: Documentation Typo
Package: wpasupplicant Version: 0.6.0-1 Severity: normal There is a typo on line 279 of /usr/share/doc/wpasupplicant/README.modes.gz It says "The fallback interface can be chosen via the 'wpa-default-iface' option." However, 'wpa-default-iface' does not work - the real option name is 'wpa-roam-default-iface' So, the documentation should say "The fallback interface can be chosen via the 'wpa-roam-default-iface' option." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345839: [radeon] 2nd head of dualhead setup got "messed up"
The problem is gone for me now. I'm currently using Xorg in Etch, and two heads works fine with the radeon driver. I honestly can't remember when the problem went away. I have two dual head cards (one ATI, one nVidia), and only 3 monitors, so I believe I used one output on the ATI and two outputs on the nVidia for a while when the driver was broken. At some point, after a major upgrade, I tried switching it back to using two outputs on the ATI card and one on the nVidia, and it worked and has been working fine with that configuration for some time now. But I can't seem to remember when exactly that happened. So, as far as I'm concerned, you can close the bug. Thanks! -Paul On Tue, Jun 19, 2007 at 09:28:12PM +0200, Brice Goglin wrote: > Hi, > > About a year ago, you reported a bug to the Debian BTS regarding the 2nd > head of a duakhead setup on ATI boards being "messed up". Did any of you > guys reproduce this problem recently? With Xorg/Etch? With latest > xserver-xorg-core and drivers? If not, I will close this bug in the next > weeks. > > Thanks, > Brice > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342578: checkinstall - chmod 700 cause
I forwarded this info upstream at the same time as I submitted the info above to this bug report. The upstream maintainer mentioned he would fix the problems, but it doesn't look like a new upstream version has been released yet. You're right that my proposed solution wouldn't work. I'm not sure why tar is used instead of cp - perhaps something to do with the handling of special files? It looks like tar is always used in the script when copying files, so I guess there is probably a reason for it. BTW - http://lists.debian.org/debian-mentors/2006/11/msg8.html I believe the reason those bugs aren't going away is because they are tagged as 'fixed in installwatch 0.7.0beta4-1', so the BTS assumes the bug still exists in any version of checkinstall that is installed on a system without installwatch > 0.7.0beta4-1 - and, since the installwatch package is now gone, all versions of checkinstall are now "installed on a system without installwatch > 0.7.0beta4-1". You would expect that the 'replaces: installwatch' tag would automatically take care of this, but I guess not. You probably need to re-tag those bugs as 'fixed in checkinstall 1.6.0'. Or maybe add a changelog entry to your next update to checkinstall which closes all those bugs again. Thanks! -Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392739: duplicate entry in /etc/services
/etc/services in debian says: # Updated from http://www.iana.org/assignments/port-numbers and other # sources like http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/services . nameserver 42/tcp name# IEN 116 domain 53/tcp nameserver # name-domain server domain 53/udp nameserver http://www.iana.org/assignments/port-numbers says: name 42/tcpHost Name Server name 42/udpHost Name Server nameserver 42/tcpHost Name Server nameserver 42/udpHost Name Server domain 53/tcpDomain Name Server domain 53/udpDomain Name Server http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/services says: nameserver 42/tcpname #Host Name Server nameserver 42/udpname #Host Name Server domain 53/tcp#Domain Name Server domain 53/udp#Domain Name Server So, it looks to me like the 'nameserver' aliases associated with the 'domain' entries in debian's /etc/services are probably wrong and should probably be removed. Is the 'nameserver' entry on port 42 also supposed to have a udp entry on port 42 too? I wonder if the whole list should be updated, as it looks like there have been many changes upstream that never made it into debian... Would it be helpful if I submitted a patch? Or does someone else want to do the dirty work? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#87240: xinetd should satisfy dependencies for netbase
For the benefit of anyone reading this who doesn't want to spend hours digging through the archives to figure out exactly what's going on: Marco's original plan from 2002: http://lists.debian.org/debian-devel/2002/09/msg01532.html Marco's recent revised plan: http://lists.debian.org/debian-devel/2006/09/msg00208.html AJ's description from 2002 of what needed to be done to update-inetd: http://lists.debian.org/debian-devel/2002/09/msg01582.html AJ's most recent attempt to finish rewriting update-inetd: http://lists.debian.org/debian-devel/2006/08/msg00533.html List of packages depending on netbase: http://lists.debian.org/debian-devel/2006/08/msg00561.html A description of available inetd packages: http://lists.debian.org/debian-devel/2006/08/msg00483.html And a basic summary: +all packages depending on netkit-inetd have been updated to depend on other packages instead +openbsd-inetd has been updated to provide inet-superserver and replace netkit-inetd +netbase has been updated to depend on openbsd-inetd|inet-superserver instead of netkit-inetd -other inetd packages now need to be updated to provide inet-superserver -other packages which require an inetd now need to be updated to depend on inet-superserver -post-etch, netbase will be updated to remove the openbsd-inetd|inet-superserver dependency -netkit-inetd can now be removed from debian as it is severely obsolete +openbsd-inetd has been updated to depend on tcpd +netbase has been updated to remove the dependency on tcpd -other inetd packages now need to be updated to depend on tcpd if necessary +the update-inetd script has been removed from netbase and put in it's own update-inetd package +openbsd-inetd has been updated to depend on update-inetd -other inetd packages now need to be updated to either depend on the update-inetd package or provide their own update-inetd script does a new common interface for the update-inetd script need to be defined? or has it already been defined by one of the partial re-writes of the script? or is the old update-inetd interface going to live on in whatever new scripts are written? +/etc/init.d/networking has been pretty much stripped down to 'ifup -a' and 'ifdown -a' -/etc/init.d/networking should probably now be moved to the ifupdown package Once all this is straightened out, what remains of netbase will be very minimal - (protocols, rpc, and services files in /etc/, and a dependency on ifupdown and ping). Since ifupdown and iputils-ping are both priority important, the dependency can probably be safely removed, although any package that actually depends on ifup/ifdown/ping should be updated to depend on those just incase a user decides to try to remove those packages. The 3 remaining files could probably be moved to another package (base-files is the most likely candidate), and netbase could probably be gone completely. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#87240: xinetd should satisfy dependencies for netbase
Now that update-inetd has been separated into another package, what is the status of this bug? Do packages that actually require update-inetd (and were depending on netbase to get that script) need to be updated to depend on inet-superserver or update-inetd before the inetd dependency can be removed? Is there other work that still needs to be done within (or related to) netbase to remove the inetd dependency? Is there any way myself or others can help with this work? Would it be possible to change the inetd dependency from "Depends" to "Recommends" so that an inetd is installed by default, but can be removed by those users who really don't want it and know that it won't break anything? Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#398622: doh!
Sorry, looks like the iso was corrupted when being copied to my USB key this time. The upstream iso looks fine. I should have done slightly more digging before filing my bug report. You can close this bug. Thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#398622: installation-report: Corrupted installer component in i386 businesscard iso
Package: installation-report Severity: important Boot method: USB Key using boot.img.gz from http://ftp.nl.debian.org/debian/dists/testing/main/installer-i386/rc1/images/hd-media/boot.img.gz Image version: http://cdimage.debian.org/cdimage/etch_di_rc1/i386/iso-cd/debian-testing-i386-businesscard.iso Date: Tue Nov 14 11:35:12 EST 2006 Machine: Toshiba Tecra M5 Processor: Intel Core Duo T2500 Memory: 2GB PC2-5300 Partitions: none Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[ ] Configure network: [ ] Detect CD: [O] Load installer modules: [E] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: While loading installer components from the ISO, it says: There was a problem reading data from the CD-ROM. Please make sure it is in the drive. If retrying does not work, you should check the integrity of your CD-ROM. Switch to a console: #cd /cdrom #md5sum -c md5sum.txt | grep -v OK ../install/gtk/initrd.gz: FAILED ../pool/main/p/partman-lvm/partman-lvm_47_all.udeb: FAILED md5sum: WARNING: 2 of 242 computed checksums did NOT match # This has been happening for atleast a week - see: http://lists.debian.org/debian-boot/2006/11/msg00284.html http://lists.debian.org/debian-boot/2006/11/msg00285.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#281823: checkinstall: duplicate of #342578?
Package: checkinstall Version: 1.5.3-3 Followup-For: Bug #281823 This is almost certainly a duplicate of bug 342578 It should probably be merged with that bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#284786: checkinstall: fixed upstream in 1.6.1
Package: checkinstall Version: 1.5.3-3 Followup-For: Bug #284786 This bug is fixed upstream in 1.6.1: nov/01/2006 * Provides/Requires bug fixed * Applied the patches from Felipe Sateler: - We now explicitly run bash (It has always benn a requiremente anyway) - In Debian we set the architecture with dpkg-architecture. - If we're creating a .dpkg then we eliminate uderscores and put dashes instead in the package name. - Tag all files in /etc inside the package as config files -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342578: checkinstall - chmod 700 cause
Package: checkinstall
Version: 1.5.3-3
Followup-For: Bug #342578
The problem is line 211 in the checkinstall script (version 1.5.3-3):
206 function restore_backup {
207 ls ${TMP_DIR}/backup/* &> /dev/null
208 if [ $? -eq 0 ]; then
209 echo -n "Restoring overwritten files from backup..."
210 cd ${TMP_DIR}/backup
211tar -cpf - . | tar -f - -xvpC / &> /dev/null
212 okfail
213 echo
214 fi
215 }
Backups are by default enabled in checkinstall 1.5.3.
The $TMP_DIR/backup directory is created chmod 700 (it looks like it's created
by installwatch):
ls -ld /var/tmp/GCZUQqPIlOGQmQcZCPbN/backup/
drwx-- 2 root root 48 2006-11-13 15:45 /var/tmp/GCZUQqPIlOGQmQcZCPbN/backup/
If ctrl-c is hit from inside checkinstall, the cleanup function is called.
The cleanup function then calls restore_backup.
If any files exist in $TMP_DIR/backup when restore_backup is called, it
restores those files using the tar commands on line 211.
Line 211 tars up any files in $TMP_DIR/backup (including $TMP_DIR/backup
itself), then restores those files and their permissions in /
Since $TMP_DIR/backup is chmod 700, after restoring the backup files, / will
also be chmod 700
Perhaps line 211 should be changed to this?
tar -cpf - * | tar -f - -xvpC / &> /dev/null
---
checkinstall 1.6.0 doesn't have this problem because translation is enabled by
default:
function restore_backup {
# If we have translation turned on then we didn't do a backup
if [ "${TRANSLATE}" = "1" ]; then return 0; fi
# Else, restore the backup if it exists
rm -rf ${TMP_DIR}/BACKUP/no-backup &> /dev/null
ls ${TMP_DIR}/BACKUP/* &> /dev/null
if [ $? -eq 0 ]; then
echogn "Restoring overwritten files from backup..."
cd ${TMP_DIR}/BACKUP
$TAR -cpf - . | $TAR -f - -xvpC / &> /dev/null
okfail
echo
fi
}
However, if translation were to be disabled, the problem would resurface.
---
Note that checkinstall 1.6.1 was recently released... (As far as this problem
is concerned, checkinstall 1.6.1 and 1.6.0 behave the same)
---
Two other unrelated bugs I came across while researching this one:
#1:
In checkinstall 1.6.0/1.6.1, due to the new translation feature, even if you
tell checkinstall NOT to exclude files installed into `pwd`, it will exclude
them.
The files in pwd need to be copied to the translation directory to be included
in the package, but they aren't copied.
If translation is enabled, the files should be copied over (immediately after
checking for files in pwd - around line 1525 in 1.6.0 - the user is given an
opportunity to edit the list of files, and if the user adds any new files,
those files are automatically copied if translation is enabled - but it doesn't
happen unless '--inspect' is passed on the command line).
#2:
$TMP_DIR should begin with a '/' :
! [ "$BASE_TMP_DIR" ] && BASE_TMP_DIR=/var/tmp
TMP_DIR=${BASE_TMP_DIR}/`awk 'BEGIN { srand(); for (i=1;i<21;i++) { a=95; while
(a > 90 && a < 97) { a=65+int(50*rand())}; printf("%c", a) } }'`
However, there are a number of places in the code where the variable is used as
'/$TMP_DIR', so you end up with '//var/tmp/...'
Of course, it works just fine this way, but it can be a tad confusing and it is
technically incorrect, so it is probably worth grepping the code for those
cases and fixing them...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#353023: linux-image-2.6-686: hostap module overrides network card driver
> please send the output of: > pccardctl ident $ pccardctl ident Socket 0: product info: "TOSHIBA", "Wireless LAN Card", "Version 01.01", "" manfid: 0x0156, 0x0002 function: 6 (network) Socket 1: no product info available Thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#353023: hostap module overrides network card driver
'blacklist hostap' alone didn't do it I added: blacklist hostap blacklist hostap_cs to /etc/modprobe.d/blacklist, and that seems to work. Thanks! -Paul On Sun, Feb 26, 2006 at 10:06:33PM -0800, Jurij Smakov wrote: > Hi, > > You can blacklist the hostap driver by creating a file containing a line > > blacklist hostap > > in /etc/modprobe.d/ directory. Please post a followup to the bug if that > does not take care of your problems. > > Best regards, > > Jurij Smakov[EMAIL PROTECTED] > Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#332548: Summary
> Older driver code should still work with the current server code. > http://cvs.freedesktop.org/xorg/driver/xf86-video-ati/ > Note that in order to build this, you'll need xserver-xorg-dev from > experimental or Ubuntu dapper, or to build xserver CVS yourself. I've been having a horrible time trying to get a copy from CVS to work. I'm using Debian Testing. I grabbed the 12/20/05 version of the driver from cvs (I think this should correspond to 6.9.0): 'cvs -d :pserver:[EMAIL PROTECTED]:/cvs/xorg co -D "2005-12-20" driver/xf86-video-ati' I installed the autoconf2.13 and libtool packages. I ran 'sh autogen.sh': ~/driver/xf86-video-ati$ sh autogen.sh autoreconf2.50: Entering directory `.' autoreconf2.50: configure.ac: not using Gettext autoreconf2.50: running: aclocal --output=aclocal.m4t autoreconf2.50: `aclocal.m4' is created autoreconf2.50: configure.ac: tracing autoreconf2.50: running: libtoolize --copy autoreconf2.50: `aclocal.m4' is unchanged autoreconf2.50: running: /usr/bin/autoconf autoreconf2.50: running: /usr/bin/autoheader autoreconf2.50: running: automake --add-missing --copy automake: configure.ac: installing `./install-sh' automake: configure.ac: installing `./mkinstalldirs' automake: configure.ac: installing `./missing' Makefile.am:24: BUILD_LINUXDOC does not appear in AM_CONDITIONAL configure.ac: 30: required file `./[config.h].in' not found src/Makefile.am:37: invalid unused variable name: `ATIMISC_CPIO_SOURCES' src/Makefile.am:41: invalid unused variable name: `ATIMISC_DGA_SOURCES' src/Makefile.am:36: invalid unused variable name: `ATI_CPIO_SOURCES' autoreconf2.50: automake failed with exit status: 1 ~/driver/xf86-video-ati$ I spent a lot of time trying to figure out how to fix automake, but I didn't really get anywhere, so I eventually gave up and just ran './configure': [...] ./configure: line 18921: syntax error near unexpected token `XINERAMA,' ./configure: line 18921: `XORG_DRIVER_CHECK_EXT(XINERAMA, xineramaproto)' ~/driver/xf86-video-ati$ I couldn't figure out what this was all about, so I commented out all the lines in configure containing XORG_DRIVER_CHECK_EXT or PKG_CHECK_MODULES and ran './configure' again: [...] checking whether to include TV Out support... yes ./configure: line 19353: XORG_MANPAGE_SECTIONS: command not found ./configure: line 19354: XORG_RELEASE_VERSION: command not found ./configure: line 19355: XORG_CHECK_LINUXDOC: command not found configure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating man/Makefile config.status: creating config.h config.status: executing default-1 commands ~/driver/xf86-video-ati$ Alright, atleast it created the Makefiles this time. 'cd src' 'make' ...make wasn't able to find the xorg header files... So, I checked in Debian Experimental, but didn't find an xserver-xorg-dev package. I went to ubuntu and manually downloaded and installed the xserver-xorg-dev package instead. I later found I needed a bunch of the x11proto--dev packages as well; I installed core, fonts, xext, xf86misc, video, xinerama, render, randr, xf86dri, and gl from http://packages.ubuntu.com/dapper/x11/ dpkg wasn't very happy about installing the X7.0 dev package on a system running X6.9, so I just used 'dpkg -i --force-depends .deb' I also installed the mesa-common-dev, libdrm-dev, and libdrm2 packages from Debian. Then I ran 'make' again ...and make still wasn't able to find the xorg header files... So, rather than mucking with the make file, I just copied all the xorg headers to the src directory: 'cp /usr/include/xorg/* .' 'cp -R /usr/X11R6/include/X11/ .' 'cp /usr/X11R6/include/X11/dri/* .' 'cp /usr/include/drm/* .' I also had to add this to the beginning of radeon_accel.c: #define errno xf86errno #define EBUSY xf86_EBUSY and this to the beginning of r128_accel.c: extern int xf86errno; #define errno xf86errno #define EBUSY 1022 #define EAGAIN 1002 I ran 'make' again, and FINALLY, everything compiled! *whew* 'su' 'make install' ...this installed the driver in /usr/local/lib/xorg/modules/drivers/radeon_drv.so 'cd /usr/X11R6/lib/modules/drivers' 'mv radeon_drv.so radeon_drv.so.orig' I wasn't sure if libtool did anything special to the driver when installing it, so I edited radeon_drv.la - libdir='/usr/X11R6/lib/modules/drivers' - then ran: 'libtool --mode=install install -c radeon_drv.la /usr/X11R6/lib/modules/drivers/radeon_drv.la' Now the driver should be in the right place. Restarted X ... and ... *drum roll* ... (II) LoadModule: "radeon" (II) Loading /usr/X11R6/lib/modules/drivers/radeon_drv.so dlopen: /usr/X11R6/lib/modules/drivers/radeon_drv.so: undefined symbol: gRADEONEntityIndex (EE) Failed to load /usr/X11R6/lib/modules/drivers/radeon_drv.so (II) UnloadModule: "radeon" (EE) Failed to load module "radeon" (loader failed, 7) The full Xorg log file is attached. By this point, I had already spent some hours banging my head on the desk trying to get e
Bug#332548: Summary
> > It sounds like switching to MergedFB mode or the fglrx drivers fixes > > the problem for everyone - > BTW, dual head is known not to work correctly with fglrx when direct > rendering is not enabled. That's not related to this bug. When direct rendering is not enabled? Hmmm... I was under the impression direct rendering couldn't be enabled when dual head is enabled... > > If I have time, I'll try some revisions in CVS between 6.8.2 and 6.9.0 > > to see if I can find when the problem appeared, but this could take a > > while. > I'm afraid there's no way around that... I'm not particularly experienced with X development... Will I need to build all of X using each CVS revision, or will it be possible to just build one or two copies of X, then build each copy of the driver from CVS and use it with the one copy of X? ...and...um...where is the CVS archive for the radeon driver? I'm not seeing it at http://cvs.freedesktop.org/xorg/driver/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#332548: Summary
Oops... Forgot the attachments... Section "Files" #FontPath "unix/:7100"# local font server FontPath"/usr/lib/X11/fonts/misc" FontPath"/usr/lib/X11/fonts/cyrillic" FontPath"/usr/lib/X11/fonts/100dpi/:unscaled" FontPath"/usr/lib/X11/fonts/75dpi/:unscaled" FontPath"/usr/lib/X11/fonts/Type1" FontPath"/usr/lib/X11/fonts/CID" #FontPath "/usr/lib/X11/fonts/Speedo" FontPath"/usr/lib/X11/fonts/100dpi" FontPath"/usr/lib/X11/fonts/75dpi" EndSection Section "Module" #Load "GLcore" Load"bitmap" Load"dbe" Load"ddc" Load"dri" Load"extmod" Load"freetype" Load"glx" Load"int10" Load"record" #Load "speedo" Load"type1" Load"vbe" EndSection Section "InputDevice" Identifier "Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbRules" "xfree86" Option "XkbModel" "pc104" Option "XkbLayout" "dvorak" EndSection Section "InputDevice" Identifier "Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/input/mice" Option "Protocol" "ImPS/2" Option "Buttons" "5" Option "ZAxisMapping" "4 5" EndSection Section "Device" Identifier "Video 0" #Driver "radeon" Driver "fglrx" BusID "PCI:1:0:0" Screen 0 # Dell recommends you run 1905FP's at 60Hz # And for some reason, a 1905FP will not display properly on the second output at 75Hz - 60Hz works fine # So, force both monitors to 60Hz using the VertRefresh line in the Monitor section Option "IgnoreEDID""on" EndSection Section "Device" Identifier "Video 1" #Driver "radeon" Driver "fglrx" BusID "PCI:1:0:0" Screen 1 EndSection Section "Device" Identifier "Video 2" Driver "nv" #Driver "nvidia" BusID "PCI:4:0:0" Screen 0 EndSection Section "Monitor" Identifier "1905FP" Option "DPMS" HorizSync 30-81 VertRefresh 56-65 DisplaySize 376 301 EndSection Section "Monitor" Identifier "P1110" Option "DPMS" DisplaySize 388 291 EndSection Section "Screen" Identifier "Screen 0" Device "Video 0" Monitor "1905FP" DefaultDepth24 SubSection "Display" Depth 24 Modes "1280x1024" EndSubSection EndSection Section "Screen" Identifier "Screen 1" Device "Video 1" Monitor "1905FP" DefaultDepth24 SubSection "Display" Depth 24 Modes "1280x1024" EndSubSection EndSection Section "Screen" Identifier "Screen 2" Device "Video 2" Monitor "P1110" DefaultDepth24 SubSection "Display" Depth 24 Modes "1280x1024" EndSubSection EndSection Section "ServerLayout" Identifier "Default Layout" Screen "Screen 0" Screen "Screen 1" LeftOf "Screen 0" #Screen "Screen 2" RightOf "Screen 0" Option "Xinerama" "on" InputDevice "Keyboard" InputDevice "Mouse" EndSection Section "DRI" Mode0666 EndSection X Window System Version 6.9.0 (Debian 6.9.0.dfsg.1-4 20060114230205 David Nusinow <[EMAIL PROTECTED]>) Release Date: 21 December 2005 X Protocol Version 11, Revision 0, Release 6.9 Build Operating System: Linux 2.6.15-1-686 i686 [ELF] Current Operating System: Linux psd 2.6.15-1-686-smp #2 SMP Thu Feb 2 18:39:24 UTC 2006 i686 Build Date: 14 January 2006 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present OS Kernel: Linux version 2.6.15-1-686-smp (Debian 2.6.15-4) ([EMAIL PROTECTED]) (gcc version 4.0.3 20060128 (prerelease) (Debian 4.0.2-8)) #2 SMP Thu Feb 2 18:39:24 UTC 2006 Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Wed Feb 15 14:17:51 2006 (==) Using c
Bug#332548: Summary
>It sounds like switching to MergedFB mode or the fglrx drivers fixes the >problem for everyone - the bug only surfaces when trying to use the two card >outputs independently (for example, by configuring two Device sections for the >two outputs of the card, then using Xinerama). Unfortunately, MergedFB mode >isn't a practical option for many people. Interestingly - I just tried the fglrx drivers myself, and ran into the same exact problem as with the radeon drivers. I had read somewhere that the fglrx drivers didn't exhibit the problem, hence why I mentioned that above. But, for me, it seems, the fglrx drivers do exhibit the problem. Attached files are using the fglrx setup... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#353023: linux-image-2.6-686: hostap module overrides network card driver
Package: linux-image-2.6-686 Version: 2.6.15-4 Severity: important Since my last kernel upgrade (from 2.6.15-1 to 2.6.15-4, I believe), the hostap kernel module seems to override the orinoco kernel module, so my wireless card always comes up in ap mode. Once the hostap modules are started, it does not seem possible to unload them to put the card back into a normal client mode (rmmod/modprobe -r says the driver is in use and cannot be removed). So, it seems I have to manually delete or rename the hostap module to prevent it from being loaded, then reboot if I want to use my card as a client. Is there a more elegant way to disable the hostap driver by default? If not, could you please remove the hostap driver from the stock kernel and go back to the "install the hostap-kernel-module package if you want hostap" way of doing things? Thanks! -Paul -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages linux-image-2.6-686 depends on: ii linux-image-2.6.15-1-686 2.6.15-4 Linux kernel 2.6.15 image on PPro/ linux-image-2.6-686 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#315120: apt-spy: still segfaulting...
Package: apt-spy Version: 3.1-14 Followup-For: Bug #315120 apt-spy still seems to be having problems: $ apt-spy -d testing -s US -o ./sources.list SERVER: ftp.us.debian.org Benchmarking FTP... Downloaded 30845091 bytes in 15.13 seconds Download speed: 1990.31 kB/sec Benchmarking HTTP... Downloaded 30845091 bytes in 14.66 seconds Download speed: 2054.19 kB/sec Segmentation fault $ running 'apt-spy update' first doesn't seem to help Reverting to 3.1-13 fixes the problem (assuming you don't run 'apt-spy update' again and trigger the segfault mentioned earlier). -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686-smp Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages apt-spy depends on: ii libc6 2.3.5-8GNU C Library: Shared libraries an ii libcurl3 7.15.1-1 Multi-protocol file transfer libra apt-spy recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#339051: snmpd: snmptrapd.conf doesn't parse booleans
Package: snmpd Version: 5.2.1.2-4 Severity: normal The man page for snmptrapd.conf claims that boolean configuration directives can be specified as '1|yes|true|0|no|false' However, only '1' is parsed correctly as true - 'yes', 'true', 'no', 'false', and '0' are all parsed as false. (snmptrapd.c does 'if (atoi(cptr) == 1)' to determine if each configuration directive string is true or false, and atoi() does not parse strings) Other programs in the snmpd package may do the same - I didn't check any besides snmptrapd. Thanks. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-686-smp-custom Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages snmpd depends on: ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libsensors3 1:2.9.2-5 library to read temperature/voltag ii libsnmp9 5.2.1.2-4 NET SNMP (Simple Network Managemen ii libwrap0 7.6.dbs-8 Wietse Venema's TCP wrappers libra snmpd recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#298465: RAID/LVM Partition Table Bug
Package: installation-reports Debian-installer-version: March 7, 2005 http://people.debian.org/~joeyh/d-i/images/daily/floppy/ uname -a: Linux temp 2.4.27-2-686 #1 Thu Jan 20 11:10:41 JST 2005 i686 GNU/Linux Date: March 7, 2005 11am Method: Net Install of Sarge using Floppies - http://http.us.debian.org/ Machine: Dell PowerEdge 2450 Processor: 2 x PIII 866 Memory: 2GB PC133 ECC Registered Root Device: SCSI /dev/sd0 Root Size/partition table: 2GB Output of lspci and lspci -n: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [O] Config network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [E] Create file systems:[O] Mount partitions: [O] Install base system:[O] Install boot loader:[O] Reboot: [O] Comments/Problems: Everything worked great. Minor problem during Partitioning: When manually editing the partition table, after setting up Software RAID or LVM, the RAID metadisks and LVM logical volumes show up in the list as devices with a single partition listed under each of them. If you only mess with the single partition listed under each device, everything works fine. However, if you select a RAID or LVM device itself, it asks you if you want to create a new partition table on that device. If you do, it allows you to further partition a RAID or LVM device. Of course, Software RAID and LVM don't support partitioning a metadisk or logical volume, so doing this would probably confuse the installer and make a mess. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
