Bug#983068: RM: xscorch -- RoQA; dead upstream; unmaintained; depeds on removed readline-gplv2 and others
Hi all, I am both the Debian maintainer and part of "upstream" ... I have discussed this with the co-author of the xscorch project and we do not have any time or intent to do another GTK upgrade right now. The GTK2 update was effectively a large part of what killed the project in the first place. It's a lot more fun to work on features than on a complete graphics rewrite just because programmers can never let well enough alone. That said, I am not certain why there is a rush to remove the package prior to the GTK2 removal. While it's true I have not updated the package for some time, the Debian community has provided NMUs for all of the issues that have come up. This seems more punitive than necessary ... until GTK2 is removed. I do need to orphan this package, and several others (or remove myself from maintainership lists) as I am no longer interested in maintaining (most) packages for Debian (aside from mussh which is easy enough to maintain and I still use regularly). I'll try and get that done at some point when I somehow find the time. Thanks, -Jacob
Bug#854551: 400 errors caused by 7.0.28-4+deb7u10
Hello all, Is there an ETA for old-sec? The latest version for wheezy is still 7.0.28-4+deb7u10 which is impacted by the regression (status 400). Thanks, -Jacob
Bug#796609: fcoe-utils: Has init script in runlevel S but no matching service file
Hi Felipe, On Wed, Jan 25, 2017 at 03:00:29PM -0300, Felipe Sateler wrote: > > It is plenty usable, just not if you are using systemd. Yes, I am aware > > policy at this point requires systemd support. > > OK, sorry. The impression I had from your earlier message is that it > didn't work[1]. Ahh, I see. No, the package provides the utilities necessary to mount FCoE volumes, it just does not work when you try to mount them automatically at boot time. I would be curious how systemd accomplishes the necessary ordering if that is working with the systemd units. If so, when I have some time I will have to try and understand what systemd is doing. As far as I can tell this problem is not well solved, at least in sysvinit. NFS has a special arrangement. FCoE and iSCSI can't work as far as I can tell because the network must come up in order to discover volumes, but aside from NFS, volumes are mounted before the network is brought up. If Debian has a provision to mark f.e. an ext4 volume as a network volume in /etc/fstab, I do not know about it. Additionally, in sysvinit the network is stopped before unmounting volumes, so when the system attempts to unmount the FCoE volumes, the network is already down and the system waits forever for the volumes to unmount. Both of these problems can be worked around with kludgy init hacks that are not really a high enough quality to ship in Debian. Resolving these problems the right way is what I was referring to when I said the init scripts need work. > 0030-fcoe.service-Add-foreground-to-prevent-fcoemon-to-be.patch > > => Seems to me it is better to change the unit to Type=forking > instead? This way, systemd would know when the monitor is ready. Given the description of Type=forking that does sound sensible. > debian/rules: > > => it seems weird to me that the socket is not started by default. Maybe something to do with the hack-y version of dealing with forking? Thanks, -Jacob
Bug#796609: fcoe-utils: Has init script in runlevel S but no matching service file
Hi Felipe, On Wed, Jan 25, 2017 at 11:50:33AM -0300, Felipe Sateler wrote: > Apparently, fcow-utils as currently packaged is not usable in > debian. It is plenty usable, just not if you are using systemd. Yes, I am aware policy at this point requires systemd support. > Jacob Luna Lundberg, Liang Guo, could you please review and upload > this patch? I can't review the systemd components. I do not use systemd and I am unfamiliar with its configuration. Also, I am not a DD, so although I could upload the patch to the repository, I can't upload a package. There are (as mentioned) a few bugs in the current package, so if there has been an upstream release, we should really incorporate that as well. Some of the patches merged into this jumbo patch also sound like a good idea for inclusion into Debian. I can (will) look into all of the non-systemd parts in a month or so when my schedule settles a bit. I would be inclined to just accept the systemd parts as submitted given they seem to have seen some testing already. Thanks, -Jacob
Bug#668001: debootstrap: cant install systemd instead of sysvinit
Hello,
I think this bug has a lot of dev and ops misunderstanding. It's not
surprising dev folks think the postinstall hack is good enough, but from
an ops perspective it very much is not. Rather than trying to argue
that point, let's just move ahead with solving the core problem
(debootstrap not honoring excludes).
I can confirm from moderately extensive testing the patch provided in
this bug resolves the problem of excludes not working and I have not
seen any undesired behavior resulting from this. Could we get this
uploaded at least to experimental, if not to unstable now that the
jessie release has been cut? Are the developers merely too busy and
would they welcome an NMU for this?
Also, for the other ops folks out there, I have seen quite a bit of
back-and-forth discussion about what you can and can't do without
patching debootstrap. Here's a quick run-down of the current status
(i.e. what we're stuck with for jessie):
* You cannot avoid systemd getting installed when using the debootstrap
shipped with jessie. Full stop. This impacts both the bare metal
installer and debootstrap used for things like LXC containers. You can
use debootstrap to install a package which conflicts with systemd in the
second phase, but this will merely remove systemd, not purge it. It
also will not uninstall systemd's dependencies.
* You can provide your own patched version of debootstrap for LXC
container hosts but unless you are willing to maintain your own version
of the installer images as well, you cannot do anything about the bare
metal installs. (Remember, the installer gets rebuilt from time to time
to accommodate kernel upgrades and you may be forced to do the same to
keep your preseeds working...)
* If you are using patched debootstrap, installing sysvinit instead of
systemd looks like this:
* bare metal:
Preseed with something like the following:
# Individual base packages to exclude
d-i base-installer/excludes string systemd systemd-sysv
# Additional base packages to include
d-i base-installer/includes string sysvinit-core
* LXC container:
Adjust the container template so it looks something like this:
PACKAGES_EXCLUDE="systemd,systemd-sysv"
PACKAGES_INCLUDE="...,sysvinit-core"
echo "Downloading debian minimal ..."
debootstrap --verbose --variant=minbase --arch="${ARCH}" \
--exclude "${PACKAGES_EXCLUDE}" --include "${PACKAGES_INCLUDE}" \
${RELEASE} "${CACHE}/partial-${RELEASE}-${ARCH}"
"http://${BITBUCKET}/debian";
(Ours is pretty heavily customized; sorry the variable names are all
different than they are in the script provided by Debian...)
* If you aren't using patched debootstrap, you probably want something
like the following in your post-install (f.e. in a script executed as an
installer late command in-target):
# We are running non-interactive
export DEBIAN_FRONTEND=noninteractive
export DEBIAN_PRIORITY=critical
# Clean up if the installer used a defective debootstrap which installed systemd
dpkg -l | egrep -q '^.[^n]. (systemd|systemd-sysv) ' && {
echo -e "Defective installer debootstrap; systemd was installed at some
point...\n"
# In the worst case, systemd may be the only thing installed
apt-get -mqy install sysvinit-core
# The installer may have left config files around
dpkg -P systemd systemd-sysv
# Remove non-Important systemd dependencies unless depended by another
package
for PKG in acl dbus libcap2-bin libcryptsetup4 libpam-systemd lvm2
systemd-shim systemd-ui; do
dpkg -P ${PKG} || true
done
# Remove files which systemd messily leaves around the filesystem
rm -vrf /etc/dbus-1 /etc/pam.d/systemd-user /etc/systemd/*.conf
echo
}
(Of course, one of the reasons ops folks don't like having to do this is
Debian might change the systemd deps and then we have to go change the
post-install script to accommodate...)
Thanks,
-Jacob
--
An original IBM 4.77MHz PC reports 0.7 bogomips running Linux 8086, but
can still run a webserver!
-Alan Cox, lkml post, 21 Mar 2003
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#753516: xscorch: fails to parse its data file
On Wed, Jul 02, 2014 at 07:29:33PM +0200, Yann Dirson wrote: > Not sure since when it started to fail, but it does not start up at all today: Since the +b1; I assume there must have been API changes. Thank you for taking the time to report this. I am going to try and get it taken care of before we freeze testing, but my time is in short supply right now. -Jacob -- "Dude! Your hair! It looks... different." 'Budget increase.' "HOLY SHIT!! We actually have a budget?!?" - Alex LaCroix and Siobhan Armittage, Ghost 2138 (the web comic) signature.asc Description: Digital signature
Bug#708123: grub2 (2.00-14) fails to install on v0.90 RAID1 arrays
I rebuilt my root array with a modern superblock and now grub handles it just fine. This problem is most likely specific to the old v0.90 layout. So it's still a bug in grub but I can't help test any fixes anymore. However, this does provide a (painful) way forward for people hitting the bug -- rebuild your root array with a v1.x format... Thanks, -Jacob -- No. That's where you're wrong. This is reality. It is a self- sustaining ecosociosystem powered by inter-universe warp generators. - Fred Fine, "The Big U" by Neal Stephenson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708123: grub2 (2.00-14) fails to install on RAID1 arrays
I can confirm this bug report. I also have root RAID 1 (and it's an old RAID volume created August 12th, 2005 so probably on an etch system). Upgrading to grub-pc 2.00-14 rendered my system unbootable (in the grub recovery console, my disks showed up but all their partitions were missing). Downgrading back to 1.99-27+deb7u1 allowed me to boot once more. If there is any further information I can provide to help, just let me know. Thanks, -Jacob -- Reechani, Sentrosi, Vasi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628804: resolved for me with the patch in comment 42
Hi all, I am seeing the same problem in wheezy with e-mail from a CRON task I wrote. I get e-mail every five minutes like clockwork! :) The patch in comment 42 completely resolved the issue for me. Thanks, -Jacob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#618470: Wrong group permission of task file
Version: 0.37.1-1
I can confirm this bug.
cgconfig.conf:
mount {
cpu = /sys/fs/cgroup;
cpuacct = /sys/fs/cgroup/cpuacct;
devices = /sys/fs/cgroup/devices;
memory = /sys/fs/cgroup/memory;
}
group firefox {
perm {
task {
uid = root;
gid = users;
}
admin {
uid = root;
gid = root;
}
}
memory {
memory.limit_in_bytes = 750M;
}
}
Resuling cgroup:
zorba:~# ls -la /sys/fs/cgroup/memory/firefox/
total 0
drwxr-xr-x 2 root root 0 Apr 8 13:47 .
drwxr-xr-x 4 root root 0 Apr 8 13:47 ..
-rw-r--r-- 1 root root 0 Apr 8 13:47 cgroup.clone_children
--w--w--w- 1 root root 0 Apr 8 13:47 cgroup.event_control
-rw-r--r-- 1 root root 0 Apr 8 13:47 cgroup.procs
-rw-r--r-- 1 root root 0 Apr 8 13:47 memory.failcnt
--w--- 1 root root 0 Apr 8 13:47 memory.force_empty
-rw-r--r-- 1 root root 0 Apr 8 13:47 memory.limit_in_bytes
-rw-r--r-- 1 root root 0 Apr 8 13:47 memory.max_usage_in_bytes
-rw-r--r-- 1 root root 0 Apr 8 13:47 memory.move_charge_at_immigrate
-r--r--r-- 1 root root 0 Apr 8 13:47 memory.numa_stat
-rw-r--r-- 1 root root 0 Apr 8 13:47 memory.oom_control
-rw-r--r-- 1 root root 0 Apr 8 13:47 memory.soft_limit_in_bytes
-r--r--r-- 1 root root 0 Apr 8 13:47 memory.stat
-rw-r--r-- 1 root root 0 Apr 8 13:47 memory.swappiness
-r--r--r-- 1 root root 0 Apr 8 13:47 memory.usage_in_bytes
-rw-r--r-- 1 root root 0 Apr 8 13:47 memory.use_hierarchy
-rw-r--r-- 1 root root 0 Apr 8 13:47 notify_on_release
-rw-r--r-- 1 root users 0 Apr 8 13:47 tasks
Seems to me that last line should be:
-rw-rw-r-- 1 root users 0 Apr 8 13:47 tasks
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#636188: xscorch: Please transition to use libreadline6-dev
Hi, On Tue, Aug 02, 2011 at 01:31:46AM +0800, Aron Xu wrote: > As you have written "libreadline5-dev | libreadline6-dev", then I assume > you have the sense that there is probably license issue with > libreadline6-dev, so you choose libreadline5-dev over it by default, and > you keep the latter one because it might be useful for those who want to > compile binary packages themselves. Actually, I was unaware of the license issue and don't really care what version of readline is used. XScorch works fine with both. I looked for libreadline-dev which would have been most convenient and when I didn't find it, I wrote a dep on both so I could still compile the package on older systems. The issue with the buildds using only the first dep is new to me and I really appreciate the information. I will start writing deps newest-to-oldest in my control files. > OK, then you need to check whether your build is correct, by running > lintian *and* checking the build log at least. You have tested it with > lintian already, then you forgot to check your log. I checked the log. It built fine. I didn't see any output I considered significant. However, I wasn't aware of the GPL issue. My omniscience level has been a bit low lately. Thanks, -Jacob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#636188: xscorch: Please transition to use libreadline6-dev
Hi, On Mon, Aug 01, 2011 at 09:07:37PM +0800, Aron Xu wrote: > retitle 636188 Please use libreadline-gplv2-dev instead of libreadline5-dev > thanks I will prepare a new version using libreadline-gplv2-dev. Thank you for pointing out the license issue. > Again, please check your package is buildable with pbuilder/cowbuilder > or even in a plain sid chroot. As the package's maintainer, it's your > responsibility to make sure all of the problems do not exist before > you ask for sponsorship. I don't appreciate this comment. The package built on my sid desktop and using pbuilder on sid both i386 and amd64 yesterday. I still have the logs and here's what it said about that dep: pbuilder-satisfydepends-dummy depends on libreadline5-dev | libreadline6-dev; however: Package libreadline5-dev is not installed. Package libreadline6-dev is not installed. [...] Get: 95 http://http.us.debian.org/debian/ sid/main libreadline6-dev i386 6.2-2 [247 kB] [...] Selecting previously deselected package libreadline6-dev. Unpacking libreadline6-dev (from .../libreadline6-dev_6.2-2_amd64.deb) ... [...] dpkg-buildpackage: full upload (original source is included) You seem to have some mistaken information about pbuilder, or at least specific to your own installation of it. BTW I also ran it through lintian. Thanks, -Jacob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#622023: xscorch: FTBFS: sdisplay.c:34:4: error: lvalue required as left operand of assignment
Ahh, the joys of GDK/GTK and their ever-changing APIs. If only somebody would give me a nickel for every time the deprecate an interface... I have a new package built so once I get someone to upload it for me, this will be fixed, until a month from now when they break some other interface instead. Thanks, -Jacob -- Hail Ilpallazzo! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#615975: xserver-xorg: Xorg server segfaults after starting
Probably it means this bug: https://bugs.freedesktop.org/show_bug.cgi?id=31675 I just hit the same thing in squeeze myself. -Jacob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#615975: xserver-xorg: Xorg server segfaults after starting
On Sun, Mar 06, 2011 at 10:06:00AM -0800, Jacob Luna Lundberg wrote: > I just hit the same thing in squeeze myself. Argh, I meant sid. -Jacob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#439763: debconf: hangs on puppet installs on preseed install
This is still happening with squeeze. It's something in the environment left over from the installer. This bit of bash is working for me in my post-install script: # Environment unset -v $(set | sed -e 's/=.*//g' | egrep -v '^(BASH*|HO*|IFS|PATH*|PWD|SHELL*|TERM*)') . /etc/profile export LANG=en_US.UTF-8 Before that, the shell variables are: - BASH=/bin/bash BASHOPTS=cmdhist:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath BASH_ALIASES=() BASH_ARGC=() BASH_ARGV=() BASH_CMDS=() BASH_LINENO=() BASH_SOURCE=() BASH_VERSINFO=([0]="4" [1]="1" [2]="5" [3]="1" [4]="release" [5]="i486-pc-linux-gnu") BASH_VERSION='4.1.5(1)-release' BOOT_IMAGE=debian6.0/i386/linux DEBCONF_OLD_FD_BASE=4 DEBCONF_REDIR=1 DEBIAN_FRONTEND=newt DEBIAN_HAS_FRONTEND=1 DIRSTACK=() EUID=0 GROUPS=() HOME=/ HOSTNAME=swiss HOSTTYPE=i486 IFS=$' \t\n' LANG=C.UTF-8 MACHTYPE=i486-pc-linux-gnu MENU=/usr/bin/main-menu OPTERR=1 OPTIND=1 OSTYPE=linux-gnu PATH=/sbin:/usr/sbin:/bin:/usr/bin PIPESTATUS=([0]="0") PPID=6436 PS4='+ ' PWD=/ SHELL=/bin/sh SHELLOPTS=braceexpand:hashall:interactive-comments SHLVL=1 TERM=bterm TERM_FRAMEBUFFER=yes TERM_TYPE=virtual UDPKG_QUIET=y UID=0 USER=root And after it, they are: --- BASH=/bin/bash BASHOPTS=cmdhist:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath BASH_ALIASES=() BASH_ARGC=() BASH_ARGV=() BASH_CMDS=() BASH_LINENO=() BASH_SOURCE=() BASH_VERSINFO=([0]="4" [1]="1" [2]="5" [3]="1" [4]="release" [5]="i486-pc-linux-gnu") BASH_VERSION='4.1.5(1)-release' EUID=0 HOME=/ HOSTNAME=swiss HOSTTYPE=i486 IFS=$' \t\n' LANG=en_US.UTF-8 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin PIPESTATUS=([0]="0") PPID=6436 PWD=/ SHELL=/bin/sh SHELLOPTS=braceexpand:hashall:interactive-comments TERM=bterm TERM_FRAMEBUFFER=yes TERM_TYPE=virtual UID=0 -Jacob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#591274: RM: ifpgui [kfreebsd-i386 kfreebsd-amd64] -- ANAIS; requires libusb-1.0-0-dev (not libusb2-dev); missing in kfreebsd
Package: ftp.debian.org Severity: normal The new version (1.0) of ifpgui explicitly uses libusb-1.0 in the source. According to a thread in debian-bsd [1], there is no plan to provide libusb-1.0-0-dev in the kfreebsd arches. Also, the package has never built for herd (because there is no libusb 0 or 1). I do not have time to port the package to use libusb2-dev and reliably debug incompatibilities before the release of Squeeze, and I would like to see ifpgui 1.0 in the release, because it contains several bug fixes and interface improvements. Therefore I have updated the package to specify linux-any and am requesting the kfreebsd packages be removed. Thanks! [1] http://osdir.com/ml/debian-bsd/2009-12/msg2.html -- System Information: Debian Release: 5.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: sparc (sparc64) Kernel: Linux 2.6.26-2-sparc64 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#590527: ITP: mussh -- MUltihost SSH Wrapper
Hi, On Wed, Jul 28, 2010 at 03:26:50PM +0200, J??r??my Lal wrote: > On 28/07/2010 15:14, Pierre Habouzit wrote: > > On Tue, Jul 27, 2010 at 12:46:16AM -0400, Holger Levsen wrote: > >> how is that different to dsh, already present in Debian? > > Or clusterssh ? > Or mssh ? As I alluded to in the expanded description, earlier in this thread, there is a large difference between what dsh / mussh do and what mssh / clusterssh do. The latter are primarily for concurrent access, whereas the former simply run pre-decided commands or strings against a set of hosts. If you want to fiddle around with the same thing on a few hosts by hand, you might try to do it with mssh, but if you have a predefined set of utility scripts and you want to execute one of them against all 256 of your data center hosts, mussh is the tool for the job. My current employer uses mussh with a library of scripts for things like updating the same package on any host where it is pending, removing root keys of a retiring sysadmin from every host, quickly grabbing host information such as OS release or installed packages from sets of hosts, etc. We check out our host lists and utility scripts from subversion and then execute a command somewhat like this: ssh-add mussh -l root -H svn/linux.hosts -C svn/frob.script -m10 -b That's the extent of it, and whatever well-known thing frob.script does gets done as root on every server in linux.hosts 10 at a time with output returned grouped by host. Thanks, -Jacob signature.asc Description: Digital signature
Bug#590527: ITP: mussh -- MUltihost SSH Wrapper
Hi Holger, On Tue, Jul 27, 2010 at 12:46:16AM -0400, Holger Levsen wrote: > how is that different to dsh, already present in Debian? They are similar. They have even both been around for a fair while now without recent changes. I find mussh a little more convenient to use. Also, mussh is just one file written in bash, which is considerably simpler (and thus easier for people to modify to suit their needs). I don't know that either one is Amazingly Better than the other, but I do know a number of large organizations who are using mussh (it is packaged for Fedora) and I think having it in Debian would be to our benefit. :) By the way, here's the current description I'm using now: " Description: MUltihost SSH Wrapper Mussh is a shell script that allows you to execute a command or script over ssh on multiple hosts with one command. When possible mussh will use ssh-agent and RSA/DSA keys to minimize the need to enter your password more than once. . Unlike clusterssh or mssh, mussh is just a shell script wrapper for ssh with concurrency support. It is intended to make running identical commands or scripts on almost any number of hosts possible with minimal overhead. There is no GUI and the only language used is bash. " Thanks, -Jacob signature.asc Description: Digital signature
Bug#590527: ITP: mussh -- MUltihost SSH Wrapper
Package: wnpp Severity: wishlist Owner: Jacob Luna Lundberg * Package name: mussh Version : 0.7 Upstream Author : dough...@doughnut.net * URL : http://sourceforge.net/projects/mussh/ * License : GPL Programming Lang: bash Description : MUltihost SSH Wrapper Mussh is a shell script that allows you to execute a command or script over ssh on multiple hosts with one command. When possible mussh will use ssh-agent and RSA/DSA keys to minimize the need to enter your password more than once. -- System Information: Debian Release: 5.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: sparc (sparc64) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561851: bug 561851: confirm
Hi, I can confirm this bug. My eth0 is an RTL8169sc/8110sc. I was just trying to figure out why it was in half duplex mode. Good to know it isn't really. kyo:~# mii-tool -v eth0 eth0: negotiated 1000baseT-HD flow-control, link ok product info: vendor 00:07:32, model 17 rev 2 basic mode: autonegotiation enabled basic status: autonegotiation complete, link ok capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control kyo:~# ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Link partner advertised pause frame use: No Link partner advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: g Current message level: 0x0033 (51) Link detected: yes Thanks, -Jacob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#372591: bug 372591 seems to have been ported to debian/stable
I updated BIND9 on my stable hosts today and now they exhibit the same behavior. I agree with Martin -- please use the filesystem permissions. -Jacob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365951: ITP: ifpgui -- QT based iRiver iFP media player manager
Package: wnpp Severity: wishlist Owner: Jacob Luna Lundberg <[EMAIL PROTECTED]> * Package name: ifpgui Version : 0.10.7 Upstream Author : Jim Campbell <[EMAIL PROTECTED]> * URL : http://ifpgui.sourceforge.net/ * License : GPL, BSD Programming Lang: C++ Description : QT based iRiver iFP media player manager This project is an open-source graphical user interface (GUI) for iRiver's iFP flash player. It uses libifp to access the player using the management interface. You can only use this software if your player has the "Management" version of iRiver's firmware installed. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.3 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348944: patch for this security vulnerability
If for some reason anyone wants the specific patch which addresses this vulnerability (as opposed to the larger diff in 0.2.0-4), it can be downloaded from the xscorch website at the following location: http://www.xscorch.org/releases/xscorch-0.2.0-stack-smash.patch.gz -Jacob -- Hail Ilpallazzo! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346856: security bug needs upload along with xlibs-dev transition Re: Bug#346856: intent to upload sponsored NMU to fix xlibs-dev bug
On Tue, Jan 17, 2006 at 10:45:05AM -0800, Jacob Luna Lundberg wrote: > On Tue, Jan 17, 2006 at 02:37:52AM -0800, Steve Langasek wrote: > > Well, I can't confirm this. Jacob, please consider the attached > > patch, which fixes some quoting issues in configure.ac and > > re-autoconfs the source. Confirmed to work in pbuilder here. If you > > would care to prepare a -4 that includes these fixes, I'd be happy to > > sponsor for you (as, I imagine, would Thomas). > > Funky, I thought we were using libxpm directly for a few things. I'll > try to verify and get the -4 updated later today. Ok, I guess we tossed out the direct xpm bits a while ago. I've applied your patch and also updated the debhelper compatibility. Sorry this took longer than "later today"... If you or Thomas can do the upload for me, that would be great. The updated version can be downloaded from: http://www.gnifty.net/code/xscorch/ Thanks again everybody, -Jacob -- Hail Ilpallazzo! signature.asc Description: Digital signature
Bug#346856: security bug needs upload along with xlibs-dev transition Re: Bug#346856: intent to upload sponsored NMU to fix xlibs-dev bug
On Tue, Jan 17, 2006 at 02:37:52AM -0800, Steve Langasek wrote: > Is it confirmed that this stack smash bug is a security vulnerability? > Not all are... I am not aware of any security issues with this stack smash. You can overwrite up to 10 chars of stack but I certainly don't know how I would use it in a security attack. You would need to overwrite the scorings file, which is installed as root, or to edit the user's ~/.xscorch/config file and point them at a custom scorings file. I don't know enough about the stack layout in that function to say for sure whether it could be used to execute custom code or not, though. > Well, I can't confirm this. Jacob, please consider the attached > patch, which fixes some quoting issues in configure.ac and > re-autoconfs the source. Confirmed to work in pbuilder here. If you > would care to prepare a -4 that includes these fixes, I'd be happy to > sponsor for you (as, I imagine, would Thomas). Funky, I thought we were using libxpm directly for a few things. I'll try to verify and get the -4 updated later today. Thanks, -Jacob -- Hail Ilpallazzo! signature.asc Description: Digital signature
Bug#346856: intent to upload sponsored NMU to fix xlibs-dev bug
On Mon, Jan 16, 2006 at 05:45:44PM -0500, Justin Pryzby wrote: > I intend to NMU a fix for this bug sponsored by some member of the QA > group; patch attached. My pbuild result of this patch was clean, and > produced a binary package with expected debdiff output from the most > recent version in sid. A build log is attached. Please consider using my package version 0.2.0-4 available here: http://www.gnifty.net/code/xscorch/ I requested that my usual sponsor do the upload a week ago but he hasn't had time yet. Thanks, -Jacob -- Hail Ilpallazzo! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
