Bug#1035782: nuitka: Nuitka should hard-depend on an earlier python version and thus be uninstallable
Hello Stuart, Nuitka supports 3.12 for a while now, and will support 3.13 at release time. We will be able to keep it this way. I think I messed up with my sponsor such that currently the stable package didn't make it through my automatic checks, but I think it should be good to go I will check this weekend what the status is and get back to you, mostly likely with an upload to at least mentors. Yours, Kay Am Mi., 31. Juli 2024 um 14:07 Uhr schrieb Stuart Prescott < stu...@debian.org>: > Hi Kay > > I see that an updated nuitka has still not made it to Debian and so > nuitka has not been available in testing (or working in unstable) for > over 15 months. > > Do you have a firm plan for a nuitka upload? > > Would it make sense for nuitka to be team maintained so that others can > work on the package in your absence? > > nuitka is a test-dependency of pyside6 and it would be better to have > those tests run in the packaging than carry around lots of (fragile) > patches to disable or xfail them. > > In one of messages to this bug you had asked for advice on how to update > the dependencies for nuitka. I'm not sure of the nuances of your > question, but it seems that since nuitka is very tightly linked to > individual interpreter versions, it would be reasonable to not have > "Depends: python3" and instead have "Depends: python3.12" (for whatever > version of python it was built for). For the purposes of making > generalisable packaging, a using `py3versions -d` in debian/rules and in > a substvar for the Depends might be a reasonable approach. The main aim > is to have it appear in the transition tracker rather than the failure > appear in a later rebuild. Focusing the Debian packaging on Debian > (rather than supporting the matrix of derivatives and versions) would > also simplify the packaging substantially which might make it simpler to > work with. > > > regards > Stuart > > > -- > Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net > Debian Developer http://www.debian.org/ stu...@debian.org > GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 >
Bug#1043549: linux-image-6.4.0-1-amd64: btusb driver missing support for device "ID 05ac:821d Apple, Inc. Bluetooth USB Host Controller"
Package: src:linux
Version: 6.4.4-2
Severity: normal
X-Debbugs-Cc: debian@fungoiddreams.org
Dear Maintainer,
* What led up to the situation?
After upgrading from "bookworm" to "trixie", Bluetooth stopped working on my
MacBookPro9,1 (2012). No controller at all was found by rfkill, bluetoothctl
and GNOME Settings.
/usr/sbin/usb-devices showed that the device was not claimed by any driver:
T: Bus=02 Lev=04 Prnt=04 Port=02 Cnt=01 Dev#= 9 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=05ac ProdID=821d Rev=01.56
S: Manufacturer=Apple Inc.
S: Product=Bluetooth USB Host Controller
C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms
E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
* What exactly did you do (or not do) that was effective (or
ineffective)?
I created an udev rule to add the Vendor/ProdID back to the driver:
$ cat /etc/udev/rules.d/98-applebluetooth.rules
ACTION=="add", ATTRS{idVendor}=="05ac", ATTRS{idProduct}=="821d",
RUN+="/sbin/modprobe btusb" RUN+="/bin/sh -c 'echo 05ac 821d >
/sys/bus/usb/drivers/btusb/new_id'"
Afterwards, the system was rebooted.
* What was the outcome of this action?
With the udev rule, Bluetooth now works as expected. /usr/sbin/usb-devices now
shows the device claimed by the btusb driver:
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=05ac ProdID=821d Rev=01.56
S: Manufacturer=Apple Inc.
S: Product=Bluetooth USB Host Controller
C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms
E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
If I disable the udev rule and reboot the system, Bluetooth stops working
again.
Since Bluetooth did work without issues on bookworm with linux-
image-6.1.0-11-amd64, I suspect a regression either in the Debian kernel, or
upstream.
-- Package-specific info:
** Version:
Linux version 6.4.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-13 (Debian
13.1.0-9) 13.1.0, GNU ld (GNU Binutils for Debian) 2.40.90.20230720) #1 SMP
PREEMPT_DYNAMIC Debian 6.4.4-2 (2023-07-30)
** Command line:
BOOT_IMAGE=/vmlinuz-6.4.0-1-amd64 root=/dev/mapper/vg--hastur-root--hastur ro
mitigations=off video=LVDS-2:d nouveau.runpm=0 quiet splash loglevel=2
** Tainted: POE (12289)
* proprietary module was loaded
* externally-built ("out-of-tree") module was loaded
* unsigned module was loaded
** Kernel log:
[ 17.157097] RAPL PMU: hw unit of domain pp0-core 2^-16 Joules
[ 17.157098] RAPL PMU: hw unit of domain package 2^-16 Joules
[ 17.157100] RAPL PMU: hw unit of domain pp1-gpu 2^-16 Joules
[ 17.157263] iTCO_vendor_support: vendor-support=0
[ 17.157339] Loaded X.509 cert 'b...@debian.org:
577e021cb980e0e820821ba7b54b4961b8b4fadf'
[ 17.157473] input: applesmc as /devices/platform/applesmc.768/input/input12
[ 17.157660] at24 18-0050: 256 byte spd EEPROM, read-only
[ 17.158497] Loaded X.509 cert 'romain.per...@gmail.com:
3abbc6ec146e09d1b6016ab9d6cf71dd233f0328'
[ 17.158729] Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 17.167610] sr 1:0:0:0: Attached scsi CD-ROM sr0
[ 17.167878] platform regulatory.0: firmware: direct-loading firmware
regulatory.db
[ 17.168228] platform regulatory.0: firmware: direct-loading firmware
regulatory.db.p7s
[ 17.168526] sdhci-pci :02:00.1: SDHCI controller found [14e4:16bc] (rev
10)
[ 17.169815] mmc0: SDHCI controller on PCI [:02:00.1] using ADMA 64-bit
[ 17.175823] applesmc applesmc.768: hwmon_device_register() is deprecated.
Please convert the driver to use hwmon_device_register_with_info().
[ 17.192919] iTCO_wdt iTCO_wdt.1.auto: unable to reset NO_REBOOT flag, device
disabled by hardware/BIOS
[ 17.217573] usb 1-1.1: Found UVC 1.00 device FaceTime HD Camera (Built-in)
(05ac:8509)
[ 17.230295] tg3 :02:00.0 enp2s0f0: renamed from eth0
[ 17.285936] ACPI: Smart Battery System [SBS0]: Battery Slot [BAT0] (battery
present)
[ 17.288256] snd_hda_intel :00:1b.0: e
Bug#1035925: krita: unable to use G'MIC filter
Package: krita Version: 1:5.1.5+dfsg-2 Severity: normal X-Debbugs-Cc: debian@fungoiddreams.org Dear Maintainer, * What led up to the situation? I installed the packages krita, krita-gmic and gmic on Debian Bookworm * What exactly did you do (or not do) that was effective (or ineffective)? In Krita, I created a document with some text, flattened it and went to "Filter" -> "Start G'MIC-Qt" * What was the outcome of this action? I got the error message: "The GMic Plugin is not installed or could not be loaded". * What outcome did you expect instead? successful start of the G'MIC plugin According to this post: https://invent.kde.org/graphics/krita/-/blob/master/README.packagers.md , the way Krita and G'MIC interact has changed with Krita 5.x, and it now uses a forked version of G'MIC. This also makes the current krita-gmic package obsolete. We will probably need a new plugin package made from the forked G'MIC version. Kind regards, Kay -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-8-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages krita depends on: ii krita-data1:5.1.5+dfsg-2 ii libc6 2.36-9 ii libexiv2-27 0.27.6-1 ii libfftw3-double3 3.3.10-1 ii libgcc-s1 12.2.0-14 ii libgif7 5.2.1-2.5 ii libgsl27 2.7.1+dfsg-3+b1 ii libheif1 1.15.1-1 ii libimath-3-1-29 3.1.6-1 ii libjpeg62-turbo 1:2.1.5-2 ii libjxl0.7 0.7.0-10 ii libkf5completion5 5.103.0-1 ii libkf5configcore5 5.103.0-1 ii libkf5configgui5 5.103.0-1 ii libkf5coreaddons5 5.103.0-1 ii libkf5crash5 5.103.0-1 ii libkf5guiaddons5 5.103.0-1 ii libkf5i18n5 5.103.0-1 ii libkf5itemviews5 5.103.0-1 ii libkf5widgetsaddons5 5.103.0-1 ii libkf5windowsystem5 5.103.0-1 ii libkseexpr4 4.0.4.0-4 ii libkseexprui4 4.0.4.0-4 ii liblcms2-22.14-2 ii libmypaint-1.5-1 1.6.0-2 ii libopencolorio2.1 2.1.2+dfsg1-4+b3 ii libopenexr-3-1-30 3.1.5-5 ii libopenjp2-7 2.5.0-1+b1 ii libpng16-16 1.6.39-2 ii libpoppler-qt5-1 22.12.0-2+b1 ii libpython3.11 3.11.2-6 ii libqt5core5a 5.15.8+dfsg-7 ii libqt5dbus5 5.15.8+dfsg-7 ii libqt5gui55.15.8+dfsg-7 ii libqt5multimedia5 5.15.8-2 ii libqt5network55.15.8+dfsg-7 ii libqt5printsupport5 5.15.8+dfsg-7 ii libqt5qml55.15.8+dfsg-3 ii libqt5quick5 5.15.8+dfsg-3 ii libqt5quickwidgets5 5.15.8+dfsg-3 ii libqt5sql55.15.8+dfsg-7 ii libqt5sql5-sqlite 5.15.8+dfsg-7 ii libqt5svg55.15.8-2 ii libqt5widgets55.15.8+dfsg-7 ii libqt5x11extras5 5.15.8-2 ii libqt5xml55.15.8+dfsg-7 ii libquazip5-1 0.9.1-3 ii libraw20 0.20.2-2+b1 ii libstdc++612.2.0-14 ii libtiff6 4.5.0-5 ii libturbojpeg0 1:2.1.5-2 ii libwebp7 1.2.4-0.1 ii libx11-6 2:1.8.4-2 ii zlib1g1:1.2.13.dfsg-1 Versions of packages krita recommends: ii krita-gmic 2.9.4-4+b4 ii python3-pyqt55.15.9+dfsg-1 ii python3-sip 4.19.25+dfsg-5+b1 ii qml-module-qtmultimedia 5.15.8-2 Versions of packages krita suggests: ii colord 1.4.6-2.2 ii ffmpeg 7:5.1.2-3 pn krita-l10n -- no debconf information
Bug#1035782: nuitka: Nuitka should hard-depend on an earlier python version and thus be uninstallable
The later versions of Nuitka with less problems didn't make it to unstable yet, they would only give an error. However, I expect to make an upload in the next 2 weeks that will then close this bug. Yours, Kay
Bug#1022400: nuitka: FTBFS: make[1]: python2: No such file or directory
Hello Lucas, I have seen this on my side as well, but it was inconsequential, probably because I still have Python2 installed, but of course, that is bad. The relevant code should be this: BUILD_ONLY_PYTHON3 := $(shell [ `lsb_release -r -s | sed -e s/unstable/11/ -e s/testing/11/ -e s/buildd-// -e 's/\..*//'` -ge 11 ] && echo true) This is handling "unstable" only, and I am assuming Debian Sid changed to provide a "n/a" value there instead now. I will produce an upload later this coming week to address it. Yours, Kay
Bug#1021829: synaptic: APT::Default-Release still confusing with synaptic
Package: synaptic Version: 0.84.6 Severity: important Dear Maintainer, i always use stable and often Synaptic as Packetmanager. And on this actual machine i installed and upgraded Debian but at some point synaptic won't start anymore. It said APT::Default-Release "Stable-Updates" is invalid. But what it DID NOT say is from where this setting is coming. I tried to find it in /etc/apt but nothing found. And just after some web searching i found only ONE Post that explained a synaptic.conf in root's directory. This is weird because i have to key in my user password if i start synaptic as user (sudoed) and expected such a file in my home or in /etc/apt - but not in root's own dir. So, from a user's perspective Synaptic shut's down after the error message window and is no longer usable. For nothing. Making it an important bug i guess. I deleted the /root/.synaptic Folder and Synaptic is working again. I don't know how or from what this "stable-updates" entry is coming. I believe i did not set it but it must be done by anything. I only have the Trouble to make this work again. Because synaptic did not tell me in which file it founds a problematic entry. This is my suggestion that synaptic should tell the path and filename of the error. BTW. I tried to set a correct value in a new /etc/apt/apt.conf but then synaptic tells my bogus content at the end of file and... the filename. Why not everytime? -- System Information: Debian Release: 10.13 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-22-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages synaptic depends on: ii hicolor-icon-theme 0.17-2 ii libapt-inst2.0 1.8.2.3 ii libapt-pkg5.01.8.2.3 ii libatk1.0-0 2.30.0-2 ii libc62.28-10+deb10u1 ii libcairo-gobject21.16.0-4+deb10u1 ii libcairo21.16.0-4+deb10u1 ii libept1.5.0 1.1+nmu3+b1 ii libgcc1 1:8.3.0-6 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2+deb10u4 ii libgnutls30 3.6.7-4+deb10u9 ii libgtk-3-0 3.24.5-1 ii libpango-1.0-0 1.42.4-8~deb10u1 ii libpangocairo-1.0-0 1.42.4-8~deb10u1 ii libpcre2-8-0 10.32-5 ii libstdc++6 8.3.0-6 ii libvte-2.91-00.54.2-2 ii libx11-6 2:1.6.7-1+deb10u2 ii libxapian30 1.4.11-1 ii policykit-1 0.105-25+deb10u1 ii zenity 3.30.0-2 ii zlib1g 1:1.2.11.dfsg-1+deb10u2 Versions of packages synaptic recommends: ii libgtk2-perl 2:1.24992-1+b2 ii xdg-utils 1.1.3-1+deb10u1 Versions of packages synaptic suggests: pn apt-xapian-index pn deborphan pn dwww pn menu pn software-properties-gtk ii tasksel 3.53 -- no debconf information
Bug#1006754: theli tries to use swarp from suckless-tools instead of SWarp from swarp
Hi Yann, Thank you for reporting the the issue and a temporary solution. I will change the dependency to SWarp asap. Regards, Kay > On 4. Mar 2022, at 12:09, Yann Vernier wrote: > > Package: theli > Version: 3.1.3-1 > Severity: important > > Dear Maintainer, > > I tried installing theli on Debian unstable. Upon running the program, > it immediately reports swarp is the wrong version. Checking the swarp > package, Debian has renamed that program from swarp to SWarp, to avoid > collision with the suckless-tools program named swarp. > > I reckon the appropriate thing to do in the Debian package, particularly > as swarp is a dependency, is to make the similar change to call the > correct program in theli as well. > > As a workaround, it is possible to make a directory with a lower case > symlink and add it to PATH to run theli, e.g.: > > $ mkdir ~/theli-bin > $ ln -s /usr/bin/SWarp ~/theli-bin/swarp > $ PATH=~/theli-bin:$PATH theli & > > It is also possible that the program would look for SWarp if swarp were > not present, in which case this is a conflict with suckless-tools. > > -- System Information: > Debian Release: bookworm/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'oldstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.16.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) > Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8), > LANGUAGE=en_GB:sv > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages theli depends on: > ii libc62.33-7 > ii libcfitsio9 4.0.0-1 > ii libgcc-s112-20220302-1 > ii libgomp1 12-20220302-1 > ii libgsl27 2.7.1+dfsg-3 > ii libqt5core5a 5.15.2+dfsg-15 > ii libqt5gui5 5.15.2+dfsg-15 > ii libqt5printsupport5 5.15.2+dfsg-15 > ii libqt5widgets5 5.15.2+dfsg-15 > ii libraw20 0.20.2-2 > ii libstdc++6 12-20220302-1 > ii libtiff5 4.3.0-4+b1 > ii libwcs7 7.7+ds-1 > > Versions of packages theli recommends: > ii astrometry.net 0.89+dfsg-1 > ii plplot-driver-cairo 5.15.0+dfsg-24+b1 > ii python3-astropy 5.0.1-1 > ii python3-requests2.25.1+dfsg-2 > ii scamp 2.10.0-2 > ii source-extractor2.25.0+ds-3 > ii suckless-tools [swarp] 46-1 > ii swarp 2.41.5-1 > > theli suggests no packages. > > -- no debconf information >
Bug#937166: Bug#961896: nuitka: diff for NMU version 0.6.11.3+ds-1.1
Hello Adrian, thanks for your effort. As you probably know, my interest is to provide Debian packages for old distributions too. However, I think I will follow this, and remove the burden from Debian folk, and work in the future with an approach, where I will generate the control file based on the target version, where I continue to build for even oldest OSes myself, and provide to NeuroDebian and Debian a cleaner version. Please allow for a bit of time before I manage, I am aiming at my next major upstream release to be clear of this. I believe it might be a week away. I am OK with the NMU, but I am not Yaroslav, so I don't know for certain. Yours, Kay
Bug#959899: ITP: theli -- A pipeline for astronomical image data reduction
Package: wnpp Owner: Kay Thriemer Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org * Package name : theli Version : 3.0.0 Upstream Author : Mischa Schirmer * URL : https://github.com/schirmermischa/THELI * License : GNU GPL Programming Lang: C++ / Qt5 Description : A pipeline for astronomical image data reduction THELI is a data processing pipeline for optical, near-infrared and mid-infrared astronomical images. Version 3 is a complete rewrite in C++ / Qt5 (compared to version 2 in Qt3), eliminating a large number of dependencies and overcoming installation issues. Using a hybrid memory/drive data model and full parallelization, v3 offers a vast gain in processing speed. Depending on the hardware and data set, processing speed may increase by factors 2 to 20. THELI v3 also fully scales with the amount of available RAM and CPUs on your machine, and there is still potential for further improvement. It will maintained within the Debian Astronomy Working Group. A git repository will be created on salsa: https://salsa.debian.org/debian-astro-team/theli.git Best regards Kay
Bug#937166: Python2 is not really depended on
Hello, I am readying said release right now. Future releases will be faster though, promised. I got blocked as an upstream by a push to make Nuitka do real optimization, but will release more often again. Sorry for the delays. But in my defence, Nuitka uploads were blocked for months due to broken dependencies. Moritz Mühlenhoff : > If you want to use this kind of approach, put base-files first for the > python > > ones that aren't needed for the archive. > > I don't think it's even needed? The package dependencies are fulfilled by > the Python 3 packages even of old distributions like jessie, so Py2 doesn't > seem needed in any suite. > That is true. The package will build, but it will not be usable with Python2 then. It also would mean that it could not be used to compile Python2 programs of users that are otherwise executable on their system. Yours, Kay
Bug#937166: Python2 is not really depended on
Hello,
this is not explained in the FAQ, but the way I have done it is like this
(in build-depends, removed irrelevant parts):
python (>= 2.6.6-2) | base-files (>= 11),
python-all-dbg (>= 2.6.6-2) | base-files (>= 11),
python-all-dev (>= 2.6.6-2) | base-files (>= 11),
python-setuptools | base.files (>= 11),
scons,
python3-all-dev (>= 3.3),
python3-all-dbg (>= 3.3),
python3-setuptools,
python-appdirs | base-files (>= 11),
python3-appdirs | base-files (<< 7.2),
python-pil | python-imaging | base-files (>= 11),
python3-pil | base-files (<< 11),
The reason being, that Nuitka is built for older Debian and Ubuntu
distributions in Neurodebian as well. This is not pretty, but has been a
strategy used for a long time now, although more reduced, see the Python3
appdirs dependency.
In dependencies there is then this:
python3-appdirs | base-files (<< 7.2),
python-dev (>= 2.6.6-2) | base-files (>= 11),
python3-dev,
${misc:Depends},
${python:Depends},
${python3:Depends}
That should not cause an issue. I have a bullseye based builder, where my
package doesn't build, but the next one will (some rules check to discover
Debian 11 fails on "testing", but not for "unstable"), and I had to make
actual fixes with e.g. the tests not using "#!/usr/bin/env python" as that
won't work anymore, so I am convinced it pulls in no python2 package.
Are you saying, that portable control files like these are disallowed? Or
is simply the case, that I should put it in a different order, e.g.
"base-files (>= 11) | ..." and your checker tools (which I assume found
this) will be happier? As I said, in the past, I have used this approach to
disallow tools that were not usable.
Recommending python-xml will be replaced with python3-xml or simply
removed, but lxml will later become a dependency, where similar problems
will appear.
Please advise.
Yours,
Kay
Bug#947573: Nuitka and scons
Hello, Nuitka is very much ported to Python3 for a long time. I have done the changes to the packaging, which remove Python2 dependencies for Bullseye and Sid, but I wanted to keep the packaging working for Wheezy and higher, so this took more time. Nuitka has been not building due to rst2pdf failures for 4 months prior to this, only very recently this build dependency was fixed. Scons was never blocking, since Nuitka doesn't care about it. My debian Sid builds of Nuitka still seem to pull in scons and python2 with it, but I trust that nothing of scons really matters to me there. Note that Nuitka is used with Python3 scons a lot for years now. Question fro me: I am also upstream of the package. Do we need a pre-release of Nuitka right now? Or would be be OK if I continue upstream work for 1-2 weeks more, and make this a more complete release, where I also cover a few more open points of Python 3.8 compatibility? Otherwise I could also (ask my sponsor to) upload in 2-3 days. Best regards, Kay
Bug#653738: Configuration routine not run if a package specified on first run
Package: reportbug
Followup-For: Bug #653738
This seems fixed to me - there is a warning printed when the configuration
is skipped. The user can elect to ^C and re-run reportbug at this time.
--
if utils.first_run():
if not self.args and not self.options.searchfor:
offer_configuration(self.options)
main()
sys.exit(0)
else:
ewrite('Warning: no reportbug configuration found. Proceeding in
%s mode.\n' % self.options.mode)
--
-- Package-specific info:
** Environment settings:
INTERFACE="text"
** /home/user/j/jade/.reportbugrc:
reportbug_version "7.5.1"
mode standard
ui text
realname "Kay McCormick"
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default
Versions of packages reportbug depends on:
ii apt1.8.0~alpha2
ii python33.6.7-1
ii python3-reportbug 7.5.1
ii sensible-utils 0.0.12
reportbug recommends no packages.
Versions of packages reportbug suggests:
pn claws-mail
pn debconf-utils
pn debsums
ii dlocate1.07+nmu1
pn emacs24-bin-common | emacs25-bin-common
ii exim4-daemon-light [mail-transport-agent] 4.91-8+b1
ii file 1:5.34-2
ii gnupg 2.2.11-1
ii python3-urwid 2.0.1-2+b1
pn reportbug-gtk
ii xdg-utils 1.1.3-1
Versions of packages python3-reportbug depends on:
ii apt1.8.0~alpha2
ii file 1:5.34-2
ii python33.6.7-1
ii python3-apt1.7.0
ii python3-debian 0.1.33
ii python3-debianbts 2.7.2
ii python3-requests 2.20.0-2
python3-reportbug suggests no packages.
-- no debconf information
Bug#717563:
I managed to fix this (at least for the get_bugs case) but it required
changes
to python-debianbts package.
I have included two patches for feedback. There are some caveats:
* Other method calls need to be patched in reportbug/debbugs.py.
* pysimplesoap will use alternatve http transport libraries if httplib2 is
unavailable, and proxy support is unavailable for some of the other
transports such as urllib2.
* reportbug uses urllib2 over httplib2, and pysimplesoap uses httplib2 over
urllib2, but i don't think httplib2 is a dependency of reportbug -
therefore, that must changed also or pysimplesoap wont pick it up.
diff --git a/reportbug/checkversions.py b/reportbug/checkversions.py
index d94bf76..c37399d 100644
--- a/reportbug/checkversions.py
+++ b/reportbug/checkversions.py
@@ -84,7 +84,7 @@ def get_versions_available(package, timeout, dists=None,
http_proxy=None, arch='
# or to binary packages available on the current arch
url += '&a=source,all,' + arch
try:
-page = open_url(url)
+page = open_url(url, http_proxy, timeout)
except NoNetwork:
return {}
except urllib.error.HTTPError as x:
diff --git a/reportbug/debbugs.py b/reportbug/debbugs.py
index 92db224..c6bd6d0 100644
--- a/reportbug/debbugs.py
+++ b/reportbug/debbugs.py
@@ -1069,6 +1069,13 @@ def get_reports(package, timeout, system='debian',
mirrors=None, version=None,
pkg_filter = 'src'
else:
pkg_filter = 'package'
+if http_proxy:
+from urllib.parse import urlparse
+parsed_url = urlparse(http_proxy)
+# Probably ought to use more info for the proxy, if applicable.
+debianbts.set_soap_proxy(dict(proxy_host=parsed_url.hostname,
+ proxy_port=parsed_url.port))
+
bugs = debianbts.get_bugs(pkg_filter, package)
else:
bugs = list(map(int, package))
diff --git a/reportbug/urlutils.py b/reportbug/urlutils.py
index c16e48c..a3f2e20 100644
--- a/reportbug/urlutils.py
+++ b/reportbug/urlutils.py
@@ -146,6 +146,7 @@ def open_url(url, http_proxy=None, timeout=60):
proxies = urllib.request.getproxies()
if http_proxy:
proxies['http'] = http_proxy
+proxies['https'] = http_proxy
try:
page = urlopen(url, proxies, timeout)
debian-bts.patch
Description: Binary data
Bug#717563:
debianbts.get_bugs does not support passing of proxy into SoapClient. I would try to fix this but I am not sure right now of the correct approach. pysimplesoap uses httplib2 if it is available and if a specific transport library is not specified in the call to get_http_wrapper, which it is not in this application. See patch above for other changes to reportbug to support proxy handling. Take note that the patch sets the proxy for 'https' to the proxy specified for 'http'. Reportbug itself only allows to specify a single proxy for http, so this was required to support proxying for https. Probably another argument should be added to reportbug for https proxy configuration, in order to prevent simply using the http proxy, which may not be correct. On the other hand, I believe the environment configuration could be changed (i.e. stuff the proxy information into os.environ for the duration of the reportbug session). This would reduce in fewer code changes, which can be considered a good thing. I dont know what approach people wish to take, but part of this is a defect in debianbts which is another package.
Bug#912116: nuitka FTBFS: test failures
Hello Adrian, > +simpleFunction21: FAILED 125836 125872 leaked 36 The reference counting in 3.7.0 was broken, as reported in https://bugs.python.org/issue34042 which is reported fixed. For current releases, I have had disabled it for 3.7.0 therefore, and couldn't see what 3.7.1 will be. These now might be actual bugs become visible only with 3.7.1, which I need to look at, and fix it. Yours, Kay
Bug#868353: samba-libs dependencies broken in jessie debian-security repo
I have the problem after apt-get upgrade samba is removed and reinstall is not possible! sources.list deb http://security.debian.org/debian-security jessie/updates main contrib non-free deb-src http://security.debian.org/debian-security jessie/updates main contrib non-free deb http://ftp.debian.org/debian/ jessie main contrib non-free deb-src http://ftp.debian.org/debian/ jessie main contrib non-free cat debian_version 8.8 apt-get install samba Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut. Statusinformationen werden eingelesen Fertig Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass Sie eine unmögliche Situation angefordert haben oder, wenn Sie die Unstable-Distribution verwenden, dass einige erforderliche Pakete noch nicht erstellt wurden oder Incoming noch nicht verlassen haben. Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen: Die folgenden Pakete haben unerfüllte Abhängigkeiten: samba : Hängt ab von: python-samba soll aber nicht installiert werden Hängt ab von: samba-common-bin (= 2:4.2.14+dfsg-0+deb8u7) soll aber nicht installiert werden Hängt ab von: samba-dsdb-modules soll aber nicht installiert werden Hängt ab von: samba-libs (= 2:4.2.14+dfsg-0+deb8u7) soll aber nicht installiert werden Empfiehlt: samba-vfs-modules soll aber nicht installiert werden E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete. apt-cache policy samba samba: Installiert: (keine) Installationskandidat: 2:4.2.14+dfsg-0+deb8u7 Versionstabelle: 2:4.2.14+dfsg-0+deb8u7 0 500 http://security.debian.org/debian-security/ jessie/updates/main amd64 Packages 2:4.2.14+dfsg-0+deb8u6 0 100 /var/lib/dpkg/status 2:4.2.14+dfsg-0+deb8u5 0 500 http://ftp.debian.org/debian/ jessie/main amd64 Packages
Bug#867382: ITP: vspline -- generic C++ code for uniform b-splines, remap functions
Package: wnpp
Severity: wishlist
Owner: "Kay F. Jahnke"
User: debian-scie...@lists.debian.org
Usertags: field..mathematics
* Package name: vspline
Version : 0.1.1
Upstream Author : Kay F. Jahnke
* URL : https://bitbucket.org/kfj/vspline
* License : EXPAT
Programming Lang: C++11
Description : generic C++ code for uniform b-splines, remap functions
vspline is a header-only generic C++ library trying to address all
aspects of uniform b-splines. This includes b-spline prefiltering
(conversion of the source data into b-spline coefficients), evaluation
of the spline, and mass evaluation of data with remap-like functions.
I am the developer of this software, and members of the debian science
team have suggested I should get involved with packaging. The code is
now ready to be packaged, there is a repository at alioth already with
packaging information:
https://anonscm.debian.org/cgit/debian-science/packages/vspline.git
I intend to do the packaging.
I do seek for a mentor/sponsor.
Here's my writeup about vspline:
vspline can create uniform b-splines of
- real data types and their aggregates [*]
- coming in strided memory
- with a reasonable selection of boundary conditions
- used in either an implicit or an explicit scheme of extrapolation
- arbitrary spline order (up to 24)
- arbitrary dimensions of the spline
- with multithreaded code
- optionally using the CPU's vector units
on the evaluation side it provides
- evaluation of the spline at point locations in the defined range
- evaluation of the spline's derivatives
- mapping of arbitrary coordinates into the defined range
- evaluation of nD arrays of coordinates ('remap' function)
- target coordinate-fed remap function ('index_remap')
- functor-based remap, aka 'transform' function
- functor-based 'apply' function
[*] I use 'aggregate' here in the sense of 'several of the same type',
rather than 'several of any type'
while there is no lack of freely available b-spline code, vspline's aim
is to provide very fast prefiltering and evaluation by exploiting
multithreading and (optionally) the CPU's vector units. multithreading
is done with a tailor-made multithreading implementation using a thread
pool, while vectorization is done generically by using Vc. vspline's
remap routines bring these multithreading and vectorization capabilities
to bear when processing/generating mass data. The remapping routines can
produce interpolated values for nD arrays of coordinates or, more
generally, operate with functors which allow for the processing of
arbitrary value-generating pipelines. vspline's current main focus is on
image processing, but since the code is dimension-agnostic, it can
handle volume data as well, and there are specializations for 1D data, too.
vspline relies on vigra for data handling; vigra offers a convenient
zero-overhead nD array 'view' type, which can easily adopt regular nD
data by passing their shape and strides. It also offers efficient
handling of small aggregates of uniform type (like pixels) which vspline
also relies on.
I use the code in vspline in it's companion project pv, which is a
panoramic image viewer, available from
https://bitbucket.org/kfj/pv
vspline is probably beta stage, but due to the steady use in pv it is
well-tuned especially for image processing. The code has stabilized
nicely, so I think that presenting it to debian is appropriate. The very
low version number is due to the recent adoption of a debian-friendly
tagging scheme. Nevertheless I'd say that vspline is still experimental
- I only have access to a limited set of systems to experiment with, and
there are quite a few heuristics in the code which are probably
suboptimal on some targets. I'd welcome others to experiment with the
code and share their results to improve vspline.
When I started working on b-splines a few years ago, I worked a lot with
libeinspline, which is also available as a debian package, but is coded
in C and only offers cubic b-splines in up to three dimensions. I wanted
a wider scope and a modern code base in C++, and I wanted to use the
signal processing approach to b-splines rather than the linear algebra
approach used in libeinspline, so I set out on vspline. vigra, which I
use for data handling, also offers b-spline code, but I felt more
comfortable implementing the maths myself to fine-tune weight
generation, multithreading and vectorization, and also to make the
spline degree a run-time parameter rather than a template parameter.
Another source for b-spline code is opencv, which also offers a
remap function using b-spline interpolation, as does scipy. I made an
attempt to extend the concept of remapping. The classical remap function
takes an array of coordinates and produces an equally-shaped array of
interp
Bug#837701: apper: Same Letter Problem here with fresh install, seen with updates of perlmagick and imagemagick.
Package: apper Version: 0.9.1-2 Followup-For: Bug #837701 Dear Maintainer, I got the same problem (like 2 other bugreports) with german umlauts shown as ? here when running apper as it updates perlmagick, imagemagick and some libs for it. The ? was seen only on the noted program description line in apper but too when downloading AND updating them. It may be cosmetic but i do not know if there is another problem leading to this. The download and update seemed to work out successfully. No errors seen. -- System Information: Debian Release: 8.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apper depends on: ii apper-data 0.9.1-2 ii kde-runtime 4:4.14.2-2 ii libappstream10.7.3-1 ii libc62.19-18+deb8u9 ii libdebconf-kde0 0.3-1 ii libgcc1 1:4.9.2-10 ii libgee-0.8-2 0.16.1-1+deb8u1 ii libglib2.0-0 2.42.1-1+b1 ii libkcmutils4 4:4.14.2-5+deb8u2 ii libkdecore5 4:4.14.2-5+deb8u2 ii libkdeui54:4.14.2-5+deb8u2 ii libkemoticons4 4:4.14.2-5+deb8u2 ii libkidletime44:4.14.2-5+deb8u2 ii libkio5 4:4.14.2-5+deb8u2 ii libkprintutils4 4:4.14.2-5+deb8u2 ii libkutils4 4:4.14.2-5+deb8u2 ii libkworkspace4abi2 4:4.11.13-2 ii liblistaller-glib0 0.5.9-4 ii libpackagekitqt4-0 0.9.5-1 ii libqt4-dbus 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 ii libqt4-declarative 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 ii libqt4-network 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 ii libqt4-sql 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 ii libqt4-svg 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 ii libqt4-xml 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 ii libqt4-xmlpatterns 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 ii libqtcore4 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 ii libqtgui44:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 ii libsolid44:4.14.2-5+deb8u2 ii libstdc++6 4.9.2-10 ii packagekit 1.0.1-2 ii policykit-1-gnome0.105-2 ii polkit-kde-1 0.99.1-1 ii software-properties-kde 0.92.25debian1 Versions of packages apper recommends: ii appstream-index 0.7.3-1 Versions of packages apper suggests: pn debconf-kde-helper ii listaller 0.5.9-4 -- no debconf information
Bug#847154: Affects also debootstrap
Hello there, I noticed that this also affected my pbuilder instances. Assuming a file system corruption when the existing image started to fail with "segfault in method http", I then discovered that debootstrap of wheezy won't work, and crash in mysterious ways. The vsyscall=emulate kernel parameter works and allows debootstrap to work. So it's not just LXC, mere chroot is a problem too. Maybe list all these things in the news item and release notes. Yours, Kay
Bug#757861: I can reproduce this issue
Hi, i can reproduce this issue with the latest Jessie release. Wifi hardware is an ipw2200 in this case. During installation I can not connect to a WPA secured network. I just get into an endless loop asking for the SSID and key. A connection to an open network works well. In the installer log i can see the following entries which might be interesting for this issue: netcfg: INFO: Network chosen: FOO. Proceeding to connect. apt-install: Queueing package wpasupplicant for later installation netcfg: INFO: Couldn't connect to wpasupplicant dnesg says that the firmware ipw2200-bss.fw has been loaded. Will there be an update to the installer for Jessie? Kind regards Kay
Bug#827502: hunspell integration Consts obsolete?
Hi. I’m a core contributor to OmegaT. The entire package is years out of date. Those constants haven’t existed since 2011 as best I can tell. If this package isn’t going to be updated, I would suggest removing it entirely. -Aaron On Fri, 17 Jun 2016 09:36:30 +0200 Rene Engelhard wrote: > Package: omegat > Version: 2.3.0.1+dfsg-3 > Severity: important > > Hi, > > On Thu, Jun 16, 2016 at 10:40:46PM -0400, Jeremy Bicha wrote: > > Package:omegat > > Version: 2.3.0.1+dfsg-4 > > Severity: serious > > > > libhunspell-1.3-0 has been replaced by libhunspell-1.4-0 in Debian > > unstable and testing. > > > > I took a guess at the bug severity. I believe it's a RC issue because > > upgraders who have libhunspell-1.3-0 installed will not receive any > > bugfixes or security updates for that version of the library. > > Even worse; are you sure this hunspell integration is even working? I see > (both in stable and testing/unstable) only > > --- a/src/org/omegat/util/OConsts.java > +++ b/src/org/omegat/util/OConsts.java > @@ -100,7 +100,11 @@ > public static final String LEARNED_WORD_LIST_FILE_NAME = > "learned_words.txt";^M > ^M > /** The name of the spell checking library */^M > -public static final String SPELLCHECKER_LIBRARY_NAME = "hunspell";^M > +public static final String SPELLCHECKER_LIBRARY_NAME = "hunspell-1.2";^M > +^M > +/** directory of system dictionaries */^M > +public static final String SPELLCHECKER_SYSTEM_DICTIONARY_DIRECTORY =^M > +"/usr/share/myspell/dicts";^M > ^M > /** the native library directory */^M > public static final String NATIVE_LIBRARY_DIR = "native";^M > > patched in. > > SPELLCHECKER_LIBRARY_NAME coul dhave stayed hunspell to be compatible, > hunspell-1.2 is long gone (even wheezy has 1.3) and /usr/share/myspell/dicts > is compat stuff and maybe should be changed to /usr/share/hunspell/dicts? > > (And yeah, I missed this package in the transition because it wasn't > a Depends:) > > Regards, > > Rene > >
Bug#823602: hplip: Need to re-run hp-setup frequently
Package: hplip Version: 3.16.3+repack0-1 Severity: important Dear Maintainer, at some point in the past, my printer stopped working entirely. Previously already, likely because of upgrades, or so I assumed, the existing printer would no longer print, a new one added with a re-run of hp-setup, would. However, some time ago, that didn't work, and I gave up. After a fresh install, of the whole system (stretch) things work again, except that now the problem is that practically after every boot, every power cycle, the printer needs to be configured with hp-setup, or else it won't work. I got to assume that the firmware of the printer is not present anymore, and therefore this happens: I got this from systemctl -u cups.service: Mai 05 13:47:34 anna hp[7046]: io/hpmud/musb.c 153: unable get_string_descriptor -7: Resource temporarily unavailable Mai 05 13:47:34 anna hp[7046]: io/hpmud/musb.c 605: invalid product id string ret=-7 This is what happens during hp-setup -i: Mai 05 16:08:52 anna hp[10833]: io/hpmud/musb.c 427: Found interface conf=0, iface=0, altset=1, index=1 Mai 05 16:08:52 anna hp[10833]: io/hpmud/musb.c 389: Active kernel driver on interface=0 ret=0 Mai 05 16:08:52 anna hp[10833]: io/hpmud/musb.c 535: claimed 7/1/2 interface Mai 05 16:08:52 anna hp[10833]: io/hpmud/musb.c 780: read actual device_id successfully fd=1 len=128 Mai 05 16:08:52 anna hp[10833]: io/hpmud/musb.c 561: released 7/1/2 interface Mai 05 16:08:52 anna hp[10833]: io/hpmud/musb.c 960: new PRINT channel=2 clientCnt=1 channelCnt=1 Mai 05 16:08:52 anna hp[10833]: io/hpmud/musb.c 427: Found interface conf=0, iface=0, altset=1, index=1 Mai 05 16:08:52 anna hp[10833]: io/hpmud/musb.c 389: Active kernel driver on interface=0 ret=0 Mai 05 16:08:52 anna hp[10833]: io/hpmud/musb.c 535: claimed 7/1/2 interface Mai 05 16:09:02 anna hp[10833]: io/hpmud/musb.c 561: released 7/1/2 interface Mai 05 16:11:12 anna hp[10982]: io/hpmud/musb.c 427: Found interface conf=0, iface=0, altset=1, index=1 Mai 05 16:11:12 anna hp[10982]: io/hpmud/musb.c 389: Active kernel driver on interface=0 ret=0 Mai 05 16:11:12 anna hp[10982]: io/hpmud/musb.c 535: claimed 7/1/2 interface Mai 05 16:11:12 anna hp[10982]: io/hpmud/musb.c 780: read actual device_id successfully fd=1 len=128 Mai 05 16:11:12 anna hp[10982]: io/hpmud/musb.c 561: released 7/1/2 interface Mai 05 16:11:12 anna hp[10982]: io/hpmud/musb.c 960: new PRINT channel=2 clientCnt=1 channelCnt=1 Mai 05 16:11:12 anna hp[10982]: io/hpmud/musb.c 427: Found interface conf=0, iface=0, altset=1, index=1 Mai 05 16:11:12 anna hp[10982]: io/hpmud/musb.c 389: Active kernel driver on interface=0 ret=0 Mai 05 16:11:12 anna hp[10982]: io/hpmud/musb.c 535: claimed 7/1/2 interface Mai 05 16:13:22 anna hp[11166]: io/hpmud/musb.c 427: Found interface conf=0, iface=0, altset=1, index=1 Mai 05 16:13:22 anna hp[11166]: io/hpmud/musb.c 389: Active kernel driver on interface=0 ret=0 Mai 05 16:13:27 anna hp[11166]: io/hpmud/musb.c 526: invalid set_altinterface 7/1/2 altset=1: Connection timed out Mai 05 16:13:27 anna hp[11166]: io/hpmud/musb.c 427: Found interface conf=0, iface=0, altset=0, index=2 Mai 05 16:13:27 anna hp[11166]: io/hpmud/musb.c 389: Active kernel driver on interface=0 ret=0 Mai 05 16:13:27 anna hp[11166]: io/hpmud/musb.c 535: claimed 7/1/3 interface And these happen a lot too: Mai 06 08:28:39 anna hpcups[16319]: common/utils.c 220: Invalid Library hanlder pLibHandler = NULL. Not sure if it is related to failed print jobs. Yours, Kay -- Package-specific info: Saving output in log file: /data/home/hayen/hp-check.log HP Linux Imaging and Printing System (ver. 3.16.3) Dependency/Version Check Utility ver. 15.1 Copyright (c) 2001-15 HP Development Company, LP This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to distribute it under certain conditions. See COPYING file for more details. Note: hp-check can be run in three modes: 1. Compile-time check mode (-c or --compile): Use this mode before compiling the HPLIP supplied tarball (.tar.gz or .run) to determine if the proper dependencies are installed to successfully compile HPLIP. 2. Run-time check mode (-r or --run): Use this mode to determine if a distro supplied package (.deb, .rpm, etc) or an already built HPLIP supplied tarball has the proper dependencies installed to successfully run. 3. Both compile- and run-time check mode (-b or --both) (Default): This mode will check both of the above cases (both compile- and run-time dependencies). Check types: a. EXTERNALDEP - External Dependencies b. GENERALDEP - General Dependencies (required both at compile and run time) c. COMPILEDEP - Compile time Dependencies d. [All are run-time checks] PYEXT SCANCONF QUEUES PERMISSION Status Types: OK MISSING - Missing Dependency or Permission or Plug-in INCOMPAT - Incompatible dependency-version or Plugin-version warning: debian-stretch/sid version is not supported. Using debian-8.
Bug#823201: snmpd: Configuration errors on a fresh install
Package: snmpd Version: 5.7.3+dfsg-1.3 Severity: normal Dear Maintainer, I just installed "snmpd" from testing, and did systemctl status snmpd.service which gives lines like this: /etc/snmp/snmpd.conf: line 145: Warning: Unknown token: defaultMonitors. /etc/snmp/snmpd.conf: line 147: Warning: Unknown token: linkUpDownNotifications. The daemon appears to be running just fine, but I assume there must be some migration issues, probably these settings have been removed/renamed upstream. Of course, the default configuration should not have such errors. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages snmpd depends on: ii adduser3.114 ii debconf [debconf-2.0] 1.5.59 ii libc6 2.22-7 ii libsnmp-base 5.7.3+dfsg-1.3 ii libsnmp30 5.7.3+dfsg-1.3 ii lsb-base 9.20160110 snmpd recommends no packages. Versions of packages snmpd suggests: pn snmptrapd -- Configuration Files: /etc/snmp/snmpd.conf [Errno 13] Keine Berechtigung: u'/etc/snmp/snmpd.conf' -- debconf information: snmpd/upgradefrom521:
Bug#817023: os-prober doesn't detect EFI partition on MBR
Package: os-prober Version: 1.71 Also reproducible in os-prober 1.65 https://anonscm.debian.org/cgit/d-i/os-prober.git/tree/os-probes/mounted/x86/05efi#n42..n45 Disk has regular MBR table. It has Windows 7 and Ubuntu installed on different partitions. Os-prober doesn't detect EFI partition on MBR table because "udevadm info" returns "dos" partition scheme instead of expected "msdos". $ udevadm info /dev/sda1 | grep dos E: ID_PART_ENTRY_SCHEME=dos E: ID_PART_TABLE_TYPE=dos $ fdisk -lu /dev/sda | grep -B1 -A1 ef Device Boot Start End Blocks Id System /dev/sda1 * 2048 616447 307200 ef EFI (FAT-12/16/32) /dev/sda2 616448 128134439 63758996 7 HPFS/NTFS/exFAT Fixing conditions below resolves the issue: - \( "$ID_PART_ENTRY_SCHEME" != gpt -a "$ID_PART_ENTRY_SCHEME" != msdos \) -o \ + \( "$ID_PART_ENTRY_SCHEME" != gpt -a "$ID_PART_ENTRY_SCHEME" != dos \) -o \ \( "$ID_PART_ENTRY_SCHEME" = gpt -a "$ID_PART_ENTRY_TYPE" != c12a7328-f81f-11d2-ba4b-00a0c93ec93b \) -o \ - \( "$ID_PART_ENTRY_SCHEME" = msdos -a "$ID_PART_ENTRY_TYPE" != 0xef \) ]; then + \( "$ID_PART_ENTRY_SCHEME" = dos -a "$ID_PART_ENTRY_TYPE" != 0xef \) ]; then Probably this bug relates to udevinfo replacement (https://lists.debian.org/debian-user/2010/07/msg01134.html). P.S. Cross-posting report in ubuntu launchpad https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/1553678
Bug#806595: Workaround
Have faced same issue. Here is my workaround.
--- /usr/sbin/update-pepperflashplugin-nonfree.orig 2015-12-17
17:22:00.184075270 +0100
+++ /usr/sbin/update-pepperflashplugin-nonfree 2015-12-17
17:21:40.280204140 +0100
@@ -17,6 +17,8 @@
set -e
+SUDO="sudo -u _apt"
+
return_0() {
return 0
}
@@ -112,7 +114,7 @@
latestfile=latest-$variant-verified.txt
[ "$verified" != "no" ] || latestfile=latest-$variant.txt
-UNPACKDIR=`mktemp -d /tmp/pepperflashplugin-nonfree.XX` ||
die_hard "mktemp failed"
+UNPACKDIR=`$SUDO mktemp -d /tmp/pepperflashplugin-nonfree.XX`
|| die_hard "mktemp failed"
echo "$UNPACKDIR" | grep -q "^/tmp/pepperflashplugin-nonfree\." ||
die_hard "paranoia"
cd "$UNPACKDIR" || die_hard "cd failed"
@@ -169,7 +171,7 @@
deb [arch=$arch] http://dl.google.com/linux/chrome/deb/ stable main
EOF
- gpg --quiet --no-permission-warning --homedir "etc/apt"
--import /usr/lib/pepperflashplugin-nonfree/pubkey-google.txt
+ $SUDO gpg --quiet --no-permission-warning --homedir "etc/apt"
--import /usr/lib/pepperflashplugin-nonfree/pubkey-google.txt
[ "$verbose" != "yes" ] || echo "doing apt-get update on google
repository"
stdouterr=`APT_CONFIG=apt.conf apt-get --quiet --quiet update 2>&1`
Bug#678813: libreoffice-writer: multi-column label forms not laid out properly
I don't think I have trouble with this anymore. On 11/01/2015 08:08 PM, Ben Finney wrote: Control: package -1 libreoffice-writer Control: found -1 libreoffice-writer/1:3.5.4-4 Control: tags -1 unreproducible moreinfo On 24-Jun-2012, Gary Dale wrote: I selected an avery address label (30 labels per page in 3 columns of 10 labels) I think you're referring to LibreOffice Writer specifically; I've set the Package field accordingly. To attempt to reproduce this behaviour in libreoffice-writer version “1:5.0.3~rc1-2”, I used: * File → New → Labels * Labels → Brand → Avery Letter Size * Labels → Type → 5160 Address * New Document A new blank document appears with the selected layout. * Enter text on each label across the top row. * File → Print Preview The document print preview has text that appears spaced correctly across the page. * Close Preview * File → Export as PDF * Export * Select a filename, then Save The Writer document, and the resulting PDF, are attached to this message. but they didn't print properly. The printing shifted left on each subsequent column of labels. The label form was defined properly. I verified this by measuring the actual labels on the form. On 23-Dec-2012, James L. Kay, D.O., FAAP wrote: I can confirm this bug with Avery Letter Size 5160, LibreOffice Writer 3.5.4.2. I thought the settings for Avery 5160 must be incorrect, so I adjusted them for 2 hours without being able to get the 3rd column to print far enough to the right to be fully on the label. Thank you both for reporting this behaviour. Can you verify this with a LibreOffice version in currently-supported Debian? Please follow up to this bug report with the appropriate “found” or “fixed” field value for the versions you tried.
Bug#759277: gummiboot: function pointer typedefs using KnR-style(?) parameter declarations
On Tue, May 12, 2015 at 2:01 PM, Julian Andres Klode wrote: > Control: forwarded -1 k...@vrfy.org > > (Adding Kay Sievers & Harald Hoyer from upstream) > > On Mon, Aug 25, 2014 at 09:10:48PM +0200, Michael Tautschnig wrote: >> Package: gummiboot >> Version: 45-2 >> Usertags: goto-cc >> Severity: wishlist >> Tags: upstream >> >> While trying to build gummiboot using our research compiler infrastructure >> the >> build stumbled upon the following declaration in src/efi/console.c (from >> line 29 >> onwards): >> >> typedef EFI_STATUS (EFIAPI *EFI_INPUT_RESET_EX)( >> struct _EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL *This; >> BOOLEAN ExtendedVerification; >> ); >> >> While even gcc -Wall -pedantic will emit warnings, clang entirely rejects >> this. >> To address this, the semicolons after the function parameters should be >> replaced >> by commas, and the last one should be omitted, like this: >> >> typedef EFI_STATUS (EFIAPI *EFI_INPUT_RESET_EX)( >> struct _EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL *This, >> BOOLEAN ExtendedVerification >> ); >> >> The same problem appears multiple times in that file. >> >> I'm not sure about the rationale for the chosen syntax and surely this is an >> upstream problem, but I couldn't figure out what their bugtracker was. > > I'm not sure either, I added the upstream authors to the list > of recipients. Just a bug. Surprised that gcc even accepts that. Send a patch if you like it in the gummiboot repo, I'll fix the version in the systemd repo. Thanks, Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#782070: [live-config] preseed file for installation is not copied in binary/install
Am 07.04.2015 um 13:13 schrieb Louis-Maurice De Sousa: > ... > Even if I put a file preseed.cfg in each of these directories, the > file is not copied in binary/install where the debian installer > searchs it when booting with the live key. I had the same issue when I did migrate from Wheezy to Jessie. I figured out that the preseed.cfg file is now put to the root folder of the installer image. I have my own isolinux configuration file where I had to change the installer boot parameter for the preseed file to file=/preseed.cfg. I don't know what the default isolinux configuration looks like in Jessie, but with this setting it works for me. Kind regards Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777500: RFS: birdie/1.1-1 [ITP]
Hello,
regarding my question number 9: I've found the answer myself and put the
man page file in a directory debian/manpages and created a file
debian/birdie.manpages.
But I've two additional questions, which refer to you intial comments.
10. the patch should have a proper dep3-style header
What do you mean by that? Is there a way to check the formatting of
patch files?
11. why is this patch needed? why are you creating the file in the name
of the upstream authors?
Not doing this results in the following error during package build:
kay@notepad:~/Debian/birdie/birdie-1.1-2/birdie-1.1$ debuild -us -uc
dpkg-buildpackage -rfakeroot -D -us -uc
dpkg-buildpackage: source package birdie
dpkg-buildpackage: source version 1.1-2
dpkg-buildpackage: source distribution UNRELEASED
dpkg-buildpackage: source changed by Kay Abendroth
dpkg-source --before-build birdie-1.1
dpkg-buildpackage: host architecture amd64
fakeroot debian/rules clean
dh clean
dh_testdir
dh_auto_clean
dh_clean
dpkg-source -b birdie-1.1
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building birdie using existing ./birdie_1.1.orig.tar.gz
dpkg-source: info: local changes detected, the modified files are:
birdie-1.1/src/config.vala
dpkg-source: error: aborting due to unexpected upstream changes, see
/tmp/birdie_1.1-2.diff.ko8TCH
dpkg-source: info: you can integrate the local changes with dpkg-source
--commit
dpkg-buildpackage: error: dpkg-source -b birdie-1.1 gave error exit status 2
debuild: fatal error at line 1376:
dpkg-buildpackage -rfakeroot -D -us -uc failed
See also the attached file birdie_1.1-2.diff.ko8TCH
Regards,
Kay
Description:
TODO: Put a short summary on the line above and replace this paragraph
with a longer explanation of this change. Complete the meta-information
with other relevant fields (see below for details). To make it easier, the
information below has been extracted from the changelog. Adjust it or drop
it.
.
birdie (1.1-2) UNRELEASED; urgency=low
.
* Initial release. (Closes: #772739)
* XXX
* XXX
* XXX
* XXX
Author: Kay Abendroth
Bug-Debian: https://bugs.debian.org/772739
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: ,
Bug:
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded:
Reviewed-By:
Last-Update:
--- /dev/null
+++ birdie-1.1/src/config.vala
@@ -0,0 +1,26 @@
+// -*- Mode: vala; indent-tabs-mode: nil; tab-width: 4 -*-
+/*-
+ * Copyright (c) 2013-2014 Birdie Developers (http://birdieapp.github.io)
+ *
+ * This software is licensed under the GNU General Public License
+ * (version 3 or later). See the COPYING file in this distribution.
+ *
+ * You should have received a copy of the GNU Library General Public
+ * License along with this software; if not, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 02111-1307, USA.
+ *
+ * Authored by: Ivo Nunes
+ * Vasco Nunes
+ */
+
+namespace Constants {
+public const string DATADIR = "/usr/share";
+public const string PKGDATADIR = "/usr/share/birdie";
+public const string VERSION = "1.1";
+public const string GETTEXT_PACKAGE = "birdie";
+
+// translatable strings for the .desktop file
+private const string GENERIC_NAME = _("Twitter Client");
+private const string COMMENT = _("Twitter client for Linux");
+}
Bug#777500: RFS: birdie/1.1-1 [ITP]
Hello, I've one more question. 9. binary-without-manpage usr/bin/birdie I've written a man page, but I don't know where to put in the Debian package. Regards, Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777500: RFS: birdie/1.1-1 [ITP]
Hello, these are my questions regarding your feedback. Question 1 to 4 refer to http://mentors.debian.net/package/birdie. 1. Warning "Package uploaded for the unreleased distribution": How do I fix that? Right now I'm using Jessie on my laptop already. Can I tell the build tool to build it for Wheezy? 2. Lintian warning "no-upstream-changelog": Upstream version 1.1 doesn't provide a Changelog. Can I overwrite this warning? 3. Warning ""Maintainer" email is the same as the uploader": Why is this a warning? How do I fix it? 4. Warning "Package is not native": What does that mean and how do I fix it? 5. Your comment "the files in the dir cmake are not documented": I guess you mean the files from upstream. There is no more documentation provided by upstream. I use the package "as is." 6. Your comment "did not try: are the icons regnerated at build time? There is also an oddity: icons/128x128/apps has the svg in it, also other dirs have the svg": I didn't understand what you mean. How do I check the "regeneration"? What do you mean with the icon-oddity? 7. Regarding the VCS-field: I'd gladly maintain the package via Git for example. Is there a naming convention for the repository I can follow? I could imagine naming it 'debian-package-birdie'. Regards, Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777500: RFS: birdie/1.1-1 [ITP]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "birdie" Package name: birdie Version : 1.1-1 Upstream Author : Ivo Nunes , Vasco Nunes URL : http://www.birdieapp.eu/ License : GPL-3+ Section : web It builds those binary packages: birdie - Native Twitter client build for speed and ease of use. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/birdie Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/b/birdie/birdie_1.1-1.dsc Changes since the last upload: * Initial release. (Closes: #772739) Regards, Kay Abendroth -- OpenPGP Key ID: 0xBA7439A3A259BA8C Key fingerprint: 6BAC FF2D C7B5 8FEF 7ED2 0A40 BA74 39A3 A259 BA8C URL to public part of Key: http://ha.pool.sks-keyservers.net/pks/lookup?op=get&search=0xBA7439A3A259BA8C -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767323: LTO not working: File format not recognized
TL;DR The problem appears to be related to binutils and not clang.
I am having the same problem as the submitter with Clang 3.5.0-9. Compiling
the following simple hello world program:
#include
int main()
{
std::cout << "Hello World\n";
return 0;
}
$ clang++ -flto -c hello.cpp
$ clang++ -v -flto hello.o -o hello
Debian clang version 3.5.0-9 (tags/RELEASE_350/final) (based on LLVM 3.5.0)
Target: x86_64-pc-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/bin/../lib/gcc/i586-linux-gnu/4.8
Found candidate GCC installation: /usr/bin/../lib/gcc/i586-linux-gnu/4.8.4
Found candidate GCC installation: /usr/bin/../lib/gcc/i586-linux-gnu/4.9
Found candidate GCC installation: /usr/bin/../lib/gcc/i586-linux-gnu/4.9.2
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.7.4
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.4
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9.2
Found candidate GCC installation: /usr/lib/gcc/i586-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/i586-linux-gnu/4.8.4
Found candidate GCC installation: /usr/lib/gcc/i586-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/i586-linux-gnu/4.9.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.2
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Selected multilib: .;@m64
"/usr/bin/ld" --hash-style=both --build-id --eh-frame-hdr -m elf_x86_64
-dynamic-linker /lib64/ld-linux-x86-64.so.2 -o hello
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/crtbegin.o
-L/usr/bin/../lib/gcc/x86_64-linux-gnu/4.9
-L/usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu
-L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
-L/usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../..
-L/usr/lib/llvm-3.5/bin/../lib -L/lib -L/usr/lib -plugin
/usr/lib/llvm-3.5/bin/../lib/LLVMgold.so -plugin-opt=mcpu=x86-64 hello.o
-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/crtend.o
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o
hello.o: file not recognized: File format not recognized
clang: error: linker command failed with exit code 1 (use -v to see invocation)
It appears that the default linker is not the gold linker.
$ ls -l /usr/bin/ld*
lrwxrwxrwx 1 root root 6 Dec 25 16:33 /usr/bin/ld -> ld.bfd
-rwxr-xr-x 1 root root 1076192 Dec 19 13:30 /usr/bin/ld.bfd
-rwxr-xr-x 1 root root5388 Nov 6 15:12 /usr/bin/ldd
-rwxr-xr-x 1 root root 2642264 Dec 19 13:30 /usr/bin/ld.gold
The following workaround fixed the problem for me.
$ sudo rm /usr/bin/ld
$ sudo ln -s ld.gold /usr/bin/ld
$ clang++ -flto hello.o -o hello
$ ./hello
Hello World
Perhaps this bug should be reassigned to binutils.
$ dpkg -S /usr/bin/ld
binutils: /usr/bin/ld
$ dpkg -S /usr/bin/ld.gold
binutils: /usr/bin/ld.gold
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761530: Confirmation
Hello, I tried 2.7.8 and it does not happen, and I tried hg branch 2.7 and it does, obviously that is an issue of Nuitka, that Nuitka will face more widespread, once 2.7.9 gets released. However, check out this: [> /opt/python27_hg/bin/python Python 2.7.8+ (2.7:e6c7a5a94a1d, Sep 16 2014, 08:49:10) [GCC 4.9.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> > python Python 2.7.8 (default, Sep 9 2014, 22:08:43) [GCC 4.9.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. Can we get the "+" in the Debian version too. In the past, there were similar backports of bug fixes, where Nuitka with its goal of bug compatibility had checked against the "+" sign to tell that it's a Debian version of Python with extra fixes included. This was really helpful to tell that it's not a baseline version. In the concrete case, I can make a run time check to see if the new behaviour is needed or not. But that is not generally the case. In terms of solution, I am not so sure yet, how f2 and f3 can be made to differ, it is going to need a new upstream release. I hope to find a solution during the week though. Yours, Kay
Bug#761530: nuitka: FTBFS: Tests failures
Hello,
this is about a behaviour change of Python:
> -Exec with None as tuple args did update locals: 1
> > +Exec with None as tuple args did update locals: 0
>
Normally, "exec" only used to copy back to locals, if it was given no
argument, and using "locals()" in a read only fashion, when it's given as
"None".
In my attempt to fix it, I discovered that "None" now does the copy back,
while given "locals()" explicitly, does not, although "locals()" does not.
So:
def f1():
f = 1
exec("f=2")
# f now 2
def f2():
f = 1
exec("f=2", None, None) # None, None defaults to globals, locals()
# f now 2, but used to be 1
def f3():
f = 1
exec("f=2", globals(), locals())
# f now 1
There is something called a "unqualified exec". And it appears that bit is
no longer used to determine if locals is a dictionary, and therefore
writable, or not. Apparently in f3 it is not, and in f2 it is.
I wonder, if this is really an upstream change, or maybe a Debian specific
change. Unfortunately, this will need more investigation and has no obvious
fix. I am going to check against baseline 2.7.8 now and report on that.
Yours,
Kay
Bug#758050: [systemd-devel] Bug#758050: udev: ID_VENDOR_FROM_DATABASE, ID_MODEL_FROM_DATABASE for unrecognised USB device are taken from USB hub
On Thu, Aug 14, 2014 at 9:01 PM, Kay Sievers wrote: > On Thu, Aug 14, 2014 at 3:07 PM, Simon McVittie > wrote: >> I recently opened this Debian bug, for which I attach a >> patch that seems to work. Bug report quoted in full below. >> >> I would appreciate udev maintainers' opinions on whether this is >> likely to break non-USB devices, or whether there is a better way >> to do it. > > Maybe replace streq(dsubsys, "usb") with a specific match on " devtype > == usb_device" (sysfs hierarchy is usb_interface -> usb_device) and if > we hit that, we make sure we stop looking at any of the parents? Pushed a fix, similar to your patch, with the above explicit check for "usb_device". Thanks, Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#758050: [systemd-devel] Bug#758050: udev: ID_VENDOR_FROM_DATABASE, ID_MODEL_FROM_DATABASE for unrecognised USB device are taken from USB hub
On Thu, Aug 14, 2014 at 3:07 PM, Simon McVittie wrote: > I recently opened this Debian bug, for which I attach a > patch that seems to work. Bug report quoted in full below. > > I would appreciate udev maintainers' opinions on whether this is > likely to break non-USB devices, or whether there is a better way > to do it. Maybe replace streq(dsubsys, "usb") with a specific match on " devtype == usb_device" (sysfs hierarchy is usb_interface -> usb_device) and if we hit that, we make sure we stop looking at any of the parents? Thanks, Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748967: Strange wording
The man page reads like this: USENETWORK=no Specify yes when you do not want to disable network access during build. There appears to be some inverted logic going on. Can you clarify, if "yes" is the right value to disable network, or if a "NO" is missing in the name. Best regards, Kay Hayen
Bug#754411: udev: loop mounts fail after 204-14 update
On Fri, Jul 11, 2014 at 1:35 PM, Michael Biebl wrote: > Am 11.07.2014 05:01, schrieb Kay Sievers: >> The logic in util-linux, libmount, losetup, ... tries to access >> /dev/loop-control which will block and trigger a kernel-side module >> auto-load. >> >> All that is needed is that tmpfiles have created the "dead" device >> node to access from userspace, and the major/minor of that node will >> resolve to the kernel module providing the requested device. > > This seems to be setup correctly afaics: > > # modinfo loop > filename: /lib/modules/3.14-1-amd64/kernel/drivers/block/loop.ko > alias: devname:loop-control > alias: char-major-10-237 > alias: block-major-7-* > license:GPL > depends: > intree: Y > vermagic: 3.14-1-amd64 SMP mod_unload modversions > parm: max_loop:Maximum number of loop devices (int) > parm: max_part:Maximum number of partitions per loop device (int) > > # ls -la /dev/loop* > crw--- 1 root root 10, 237 Jul 11 06:02 /dev/loop-control > > > Yet, mount still fails > # mount -oloop /tmp/ISO/boot.iso /mnt/loop/ > mount: Could not find any loop device. Maybe this kernel does not know >about the loop device? (If so, recompile or `modprobe loop'.) > > Is our mount version too old or should it work irregardless of the mount > version? > > # mount --version > mount from util-linux 2.20.1 (with libblkid and selinux support) # lsmod | grep loop # mount -o loop nothing /mnt mount: nothing: failed to setup loop device: No such file or directory # lsmod | grep loop loop 28197 0 # mount --version mount from util-linux 2.25-rc2 (libmount 2.25.0: selinux, assert, debug) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754411: udev: loop mounts fail after 204-14 update
On Thu, Jul 10, 2014 at 10:55 PM, Michael Biebl wrote: > Am 10.07.2014 22:02, schrieb Peter Poeschl: >> Package: udev >> Version: 204-14 >> Severity: important >> >> Dear Maintainer, >> >>* What led up to the situation? >> udev upgrade from 204-8 to 204-14 removed the file /etc/udev/links.conf. >> >>* What exactly did you do (or not do) that was effective (or >> ineffective)? >> Try to loop-mount a file via an existing /etc/fstab entry >> >>* What was the outcome of this action? >> mount failed with >>mount: Could not find any loop device. Maybe this kernel does not know >> about the loop device? (If so, recompile or `modprobe loop'.) >> >>* What outcome did you expect instead? >> mount succeeds >> >> >> Workaround: >>1) running >> # modprobe loop >> temporarily solves the problem. >> >>2) # echo 'loop' > /etc/modules-load.d/loop.conf >> persistently solves the problem, but I don't know if this is the proper >> solution. >> > > Kay, is the loop modules supposed to be auto-loaded these days or does > it require and explicit modprobe? The logic in util-linux, libmount, losetup, ... tries to access /dev/loop-control which will block and trigger a kernel-side module auto-load. All that is needed is that tmpfiles have created the "dead" device node to access from userspace, and the major/minor of that node will resolve to the kernel module providing the requested device. Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751516: nuitka: Build-dep on python3-all-dev should be changed to python3-all
Hello, I think if you change python3-all-dev to python3-all you'll still be able to run your tests, won't you? That won't provide "Python.h", will it? It is only in the python*-dev packages AFAIK. Nuitka generates C++ code that depends on that include file. Yours, Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751516: nuitka: Build-dep on python3-all-dev should be changed to python3-all
Hello Scott, Am 13.06.2014 17:00, schrieb Scott Kitterman: Package: nuitka Version: 0.5.1+ds-1 Severity: normal As far as I can tell, nuitka doesn't compile any python3 code, so the build-dep on python3-all-dev is unneeded. python3-all is sufficient. We use build-deps on the python -dev packages to track what needs rebuilding/ updating for a python transition and so nuitka ends up on the list. Please consider this change for your next upload. Nuitka depends on this, because it runs the tests, which include using python3. Nuitka is affected by an updated "python3", as e.g. it needs to be changed to support Python 3.4, so that is true. I don't know of any way to not build depend on run time dependencies, when I mean to run the tests during builds. It's OK for you to ignore this though. Currently Debian has overtaken me in 3.4 as default supported, where Nuitka will only get there in the coming month. Yours, Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748872: installation-reports
Package: installation-reports Boot method: DVD Image version: debian-testing-amd64-DVD-1.iso (jessie) Date: 21.05.2014 Machine: amd64 Processor: intel Memory:4 GB Partitions: single + swap Output of lspci -knn (or lspci -nn): --- Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [?] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[E] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [ ] Install boot loader:[ ] Overall install:[E] Comments/Problems: I have to install behind a proxy but there is no way to enter the proxy information. I would like to enter something like "10.98.1.199:8080" . The installation of the base systems failes in advance stating that some files (mandb and alike) can't be downloaded (which is no surprise). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745280: [gummiboot] Re: Bug#745280: fails to cope properly with an existing boot loader
On Fri, Apr 25, 2014 at 8:25 PM, Julian Andres Klode wrote: > The Debian kernels are configured > CONFIG_FAT_DEFAULT_IOCHARSET="utf8" > which causes iocharset=utf8 to be the default here, rather than > iocharset=ascii. I can now > either work around that in the gummiboot package by one of > > (1) unlink() and then rename() > (2) do a stupid glob() [Bb][Oo][Tt][Xx]64.[Ee][Ff][Ii] (and the same for the > rest of the path) > > I don't think you'd like either of those upstream, so you might want to change > the generator to pass iocharset=ascii. We do not (apart from me) use that > generator, though, so it won't help Debian -- we generate a fstab entry during > system installation instead. Are we sure that this is the expected kernel behaviour? Seems pretty odd to be caused by the charset option: With ascii all is fine: # mount /dev/sda1 /boot -o iocharset=ascii # touch /boot/EFI/A # rm /boot/EFI/a rm: remove regular empty file ‘/boot/EFI/a’? y With UTF8 it breaks: # mount /dev/sda1 /boot -o iocharset=utf8 # touch /boot/EFI/A # rm /boot/EFI/a rm: cannot remove ‘/boot/EFI/a’: No such file or directory And it gets even more weird here: All is fine: [root@lon /]# touch /boot/EFI/a [root@lon /]# touch /boot/EFI/A This fails: [root@lon /]# touch /boot/EFI/A [root@lon /]# touch /boot/EFI/a touch: cannot touch ‘/boot/EFI/a’: File exists -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745280: [gummiboot] Re: Bug#745280: fails to cope properly with an existing boot loader
On Fri, Apr 25, 2014 at 7:10 PM, Julian Andres Klode wrote:
> On Fri, Apr 25, 2014 at 06:43:07PM +0200, Kay Sievers wrote:
>> On Fri, Apr 25, 2014 at 3:51 PM, Julian Andres Klode wrote:
>> > I received the following bug report in Debian about
>> > gummiboot.
>> >
>> > On Sun, Apr 20, 2014 at 10:04:23AM +0200, Philipp Kern wrote:
>> >> Package: gummiboot
>> >> Version: 44-1
>> >> Severity: important
>> >>
>> >> gummiboot fails to install if there is a preexisting EFI boot loader in
>> >> the fallback location (e.g. after a successful installation of Windows):
>> >>
>> >> pkern@simplex ~ % sudo gummiboot install --path=/boot/efi
>> >> Created /boot/efi/EFI/gummiboot.
>> >> Copied /usr/lib/gummiboot/gummibootx64.efi to
>> >> /boot/efi/EFI/gummiboot/gummibootx64.efi.
>> >> Failed to rename /boot/efi/EFI/Boot/BOOTX64.EFI~ to
>> >> /boot/efi/EFI/Boot/BOOTX64.EFI: File exists
>> >
>> > As we can see here, it tries to do an atomic replace of the boot loader,
>> > but this fails because /boot/efi (we need to use /boot/efi in Debian
>> > instead
>> > of /boot, because our kernel images are installed in /boot) is FAT32 and
>> > that does not seem to allow replacements.
>>
>> It works just fine here on a FAT partition. I have no idea why it
>> would go wrong.
>
> It seems to be a matter of lower vs. uppercase, for example:
>
> $ ls -l EFI/Boot/
> -rwxr-xr-x 1 root root 78107 Apr 11 00:25 bootx64.efi
> # mv y EFI/Boot/BOOTX64.efi
> mv: cannot move 'y' to 'EFI/Boot/BOOTX64.efi': File exists
>
> But:
> # mv y EFI/Boot/bootx64.efi
>
> works as intended. Strace shows the difference:
>
> rename("y", "EFI/Boot/BOOTX64.efi") = -1 EEXIST (File exists)
> rename("y", "EFI/Boot/bootx64.efi") = 0
>
> It does work in some cases though. I'm not entirely sure what is
> broken here.
>
> The file system is mounted in utf8 which produces the warning
> [2.998918] FAT-fs (sdb1): utf8 is not a recommended IO charset for FAT
> filesystems, filesystem will be case sensitive!
> which probably causes this. I'm not sure why it is mounted with
> utf-8, though.
I have it mounted without any specific options:
http://cgit.freedesktop.org/systemd/systemd/tree/src/efi-boot-generator/efi-boot-generator.c#n108
which results in:
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro
Kay
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745280: [gummiboot] Re: Bug#745280: fails to cope properly with an existing boot loader
On Fri, Apr 25, 2014 at 3:51 PM, Julian Andres Klode wrote:
> I received the following bug report in Debian about
> gummiboot.
>
> On Sun, Apr 20, 2014 at 10:04:23AM +0200, Philipp Kern wrote:
>> Package: gummiboot
>> Version: 44-1
>> Severity: important
>>
>> gummiboot fails to install if there is a preexisting EFI boot loader in
>> the fallback location (e.g. after a successful installation of Windows):
>>
>> pkern@simplex ~ % sudo gummiboot install --path=/boot/efi
>> Created /boot/efi/EFI/gummiboot.
>> Copied /usr/lib/gummiboot/gummibootx64.efi to
>> /boot/efi/EFI/gummiboot/gummibootx64.efi.
>> Failed to rename /boot/efi/EFI/Boot/BOOTX64.EFI~ to
>> /boot/efi/EFI/Boot/BOOTX64.EFI: File exists
>
> As we can see here, it tries to do an atomic replace of the boot loader,
> but this fails because /boot/efi (we need to use /boot/efi in Debian instead
> of /boot, because our kernel images are installed in /boot) is FAT32 and
> that does not seem to allow replacements.
It works just fine here on a FAT partition. I have no idea why it
would go wrong.
# blkid /dev/sda1
/dev/sda1: LABEL="EFI" UUID="9B5C-C8BD" TYPE="vfat" PARTLABEL="ESP"
PARTUUID="06a08fe0-82e8-4171-b00e-5afc13668ab4"
# strace -e rename gummiboot install --path=/boot
rename("/boot/EFI/gummiboot/gummibootx64.efi~",
"/boot/EFI/gummiboot/gummibootx64.efi") = 0
Copied /usr/lib/gummiboot/gummibootx64.efi to
/boot/EFI/gummiboot/gummibootx64.efi.
rename("/boot/EFI/Boot/BOOTX64.EFI~", "/boot/EFI/Boot/BOOTX64.EFI") = 0
Copied /usr/lib/gummiboot/gummibootx64.efi to /boot/EFI/Boot/BOOTX64.EFI.
Created EFI boot entry "Linux Boot Manager".
Kay
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738586: python-reportlab: rst2pdf fails to render document with package version 3.0~a1-1, works fine with 2.7-1, crashes in reportlab
Package: python-reportlab
Version: 3.0~a1-1
Severity: normal
Dear Maintainer,
* What led up to the situation?
I was building my package "nuitka", and update, which works fine in
my testing environment, but fails in chroot with unstable.
* What exactly did you do (or not do) that was effective (or
ineffective)?
I am using rst2pdf to render Developer_Manual.rst as found at
http://nuitka.net/gitweb/?p=Nuitka.git;a=blob_plain;f=README.txt;h=4c62d6a22ecad65e8bcc9d6850a52ad5b7
d57f24;hb=refs/heads/develop
as part of the package build, stack trace below.
* What was the outcome of this action?
The following Python exception was raised:
rst2pdf README.txt
Traceback (most recent call last):
File "/usr/bin/rst2pdf", line 9, in
load_entry_point('rst2pdf==0.93.dev', 'console_scripts', 'rst2pdf')()
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 353, in
load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2302, in
load_entry_point
return ep.load()
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2029, in
load
entry = __import__(self.module_name, globals(),globals(), ['__name__'])
File "/usr/lib/pymodules/python2.7/rst2pdf/createpdf.py", line 45, in
from opt_imports import psyco
File "/usr/lib/pymodules/python2.7/rst2pdf/opt_imports.py", line 49, in
from reportlab.lib.styles import getSampleStyleSheet, ParagraphStyle
File "/usr/lib/python2.7/dist-packages/reportlab/lib/styles.py", line 25,
in
from reportlab.lib.colors import white, black
File "/usr/lib/python2.7/dist-packages/reportlab/lib/colors.py", line 44,
in
from reportlab.lib.rl_accel import fp_str
File "/usr/lib/python2.7/dist-packages/reportlab/lib/rl_accel.py", line
330, in
f = _c_funcs[fn] or _py_funcs[fn]
KeyError: 'fp_str'
* What outcome did you expect instead?
The document should render as PDF.
On my Debian testing machine, the document renders just fine.
Yours,
Kay
Bug#567210: doc-available always returns false without network
> Warning: SXXP0005: The source document is in namespace > http://www.w3.org/2005/Atom, but none of the > template rules match elements in this namespace You can ignore that warning for present purposes. > [...] > Saxon does not have a local copy of PUBLIC -//W3C//DTD XHTML+RDFa > 1.0//EN SYSTEM http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd Unfortunately there is no complete list of DTDs on the W3C site that might potentially needed, and even if there were, I probably wouldn't want to ship them all with Saxon. So you might have to go back to using catalogs. On the other hand, if you can identify where this was referenced from, I can take a look and see if it ought to be included. It looks as if it comes from one of the XHTML variants, but there seem to be many of these in use. Michael Kay Saxonica -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#567210: doc-available always returns false without network
OK, so the problem seems to be here: Cannot read xhtml11/xhtml-inlpres-1.mod file and the reason would appear to be the absence of the w3c/ prefix on the file name. This takes us to here: https://saxonica.plan.io/boards/3/topics/5625 and that in turn leads me to https://saxonica.plan.io/issues/1813 which I think is fixed in the 9.5 branch but not in 9.4. The underlying cause is inconsistent use of system IDs and public IDs in the W3C-published DTDs. Michael Kay Saxonica On 29 Jan 2014, at 12:41, Eugene Zhukov wrote: > On Wed, Jan 29, 2014 at 11:00 AM, Michael Kay wrote: >> If you use the -t option on the command line, then attempts to use local >> copies of W3C DTDs will be traced on System.err. Hopefully this will shed >> more light on why the mechanism isn't working for you. >> >> The EntityResolver that Saxon uses in 9.4 can be found here: >> >> https://dev.saxonica.com/repos/archive/opensource/tags/9.4.0.7/hej/net/sf/saxon/lib/StandardEntityResolver.java >> >> I'm not sure why the data files aren't included under the 9.4.0.7 Subversion >> tag, but the files are here: >> >> https://dev.saxonica.com/repos/archive/opensource/latest9.4/data/w3c/ >> >> I note that your JAR file has been renamed, so it's possible it has also >> been rebuilt. Look inside it with a ZIP utility and check for the directory >> named "w3c". >> >> A list of the W3C documents bundled with Saxon for 9.5 can also be found >> here: >> >> http://www.saxonica.com/documentation/index.html#!sourcedocs/w3c-dtds >> >> and the corresponding list for 9.4 is at: >> >> http://www.saxonica.com/documentation9.4-demo/index.html#!sourcedocs/w3c-dtds >> > Thanks for the links! > I downloaded the official release from [0] and tried the test with it. > Here is the result with network: http://paste.debian.net/78983/ > And here is the result without network: http://paste.debian.net/78984/ > As you can see the test without network still fails. With this -t > option, when the test succeeds, you can see Saxon fetching a local > copy, but that doesn't seem to be the case without network. > > [0] > http://sourceforge.net/projects/saxon/files/Saxon-HE/9.4/SaxonHE9-4-0-7J.zip/download > > Eugene -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#567210: doc-available always returns false without network
If you use the -t option on the command line, then attempts to use local copies of W3C DTDs will be traced on System.err. Hopefully this will shed more light on why the mechanism isn't working for you. The EntityResolver that Saxon uses in 9.4 can be found here: https://dev.saxonica.com/repos/archive/opensource/tags/9.4.0.7/hej/net/sf/saxon/lib/StandardEntityResolver.java I'm not sure why the data files aren't included under the 9.4.0.7 Subversion tag, but the files are here: https://dev.saxonica.com/repos/archive/opensource/latest9.4/data/w3c/ I note that your JAR file has been renamed, so it's possible it has also been rebuilt. Look inside it with a ZIP utility and check for the directory named "w3c". A list of the W3C documents bundled with Saxon for 9.5 can also be found here: http://www.saxonica.com/documentation/index.html#!sourcedocs/w3c-dtds and the corresponding list for 9.4 is at: http://www.saxonica.com/documentation9.4-demo/index.html#!sourcedocs/w3c-dtds Michael Kay Saxonica On 29 Jan 2014, at 08:28, Eugene Zhukov wrote: > On Tue, Jan 28, 2014 at 4:25 PM, Michael Kay wrote: >> Saxon-B 9.1 does not include copies of these resources. >> >> You can always write a URIResolver and direct the request to copies held at >> application level, but it can't be done "behind the scenes". >> >> My recommendation would be to move forward to a later Saxon release that >> fixes the problem. The current release is 9.5. We have no plans to issue >> further maintenance releases for 9.1, although we do appreciate that some >> users have been sticking with that release because of the discontinuities >> introduced between 9.1 and 9.2. >> > > We have Saxon-HE 9.4.0.7 in Debian archive. So I tried the above > test-case with it: > $ java -cp > /etc/xml/resolver:/usr/share/java/xml-resolver.jar:/usr/share/java/Saxon-HE.jar > -Dxml.catalog.files=/etc/xml/catalog -Dxml.catalog.verbosity=1 > net.sf.saxon.Transform -s:foo.xml -xsl:foo.xsl > > The result is it still fails without network. With network it works. > Also, when I look into the source code of Saxon-HE 9.4.0.7 at [0], I > cannot find the local copies of those resources. So I don't understand > how it would work without the network. What did I miss? > > [0] https://dev.saxonica.com/repos/archive/opensource/tags/9.4.0.7/ > > Eugene -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735072: pylint: man page out of date for --msg-format and --include-ids
Package: pylint Version: 1.1.0-1 Severity: normal Dear Maintainer, upgrading to PyLint, and using a script to check my files, this was using --include-ids for enhanced parsing, which now fails according to changes described in changelog.gz, but when I looked at the man page, it still describes --include-ids and not the new parameter --msg-format The man page needs to be updated and document the new options and remove no more existent options. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pylint depends on: ii python 2.7.5-5 ii python-astroid 1.0.1-1 ii python-logilab-common 0.60.1-1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#726368: (no subject)
Could you please post the contents of ~/.xsession-errors? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732157: [systemd-devel] Fwd: [Pkg-systemd-maintainers] Bug#732157: Want SIGSTOP-style daemon/service readiness notification
On Sat, Dec 14, 2013 at 11:19 PM, Shawn Landden wrote: > It would be nice if systemd could implement the service supervisor > side of the service readiness protocol that upstart calls "expect > stop": > > The service doesn't fork, and when considers itself ready it raises > SIGSTOP. The supervisor can observe this via the usual mechanisms, > being the service's parent, and when it occurs it sends the service > CONT and starts whatever was waiting for readiness. > > The sd_notify(3) protocol is just about tolerable, and it is good that > it's documented, but it is quite unattractive for a daemon author: > Either they have to add a build- and runtime- dependency on a > systemd-specific library, or they have to reimplement a fairly tedious > piece of socket code. > > For a daemon author, raise(SIGSTOP) is lovely and simple. > > I guess this would be a new "Type" (but I'm still halfway through the > docs so no expert). No, it's not lovely, it's a very cheap and very bad hack. These signals are for admins and not for system management tools; just the same way ptrace is the very wrong tool to track startup behavior of services. It is just so wrong to things like that, and systemd should not do that. Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725714: udev firmware loading does not work in the Debian installer
On Fri, Dec 13, 2013 at 4:29 AM, Ben Hutchings wrote: > On Fri, 2013-12-13 at 00:28 +0100, Kay Sievers wrote: > [...] >> >> Such an explicit message would probably use printk_emit() and pass >> >> structured data with the filename and the ides from the kernel to >> >> userspace, and on systemd systems the journal would pick up the >> >> MESSAGE_ID and do something with it, or provide the data to other >> >> consumers. >> >> > The better approach would have been to write a replacement *before* >> > dropping >> > the udev missing-firmware handling. >> >> There have been many technical reasons to let the kernel do the job, >> and that is how it works today, and it works well and reliably. > [...] > > For the record, 3.12 still has: > > config FW_LOADER_USER_HELPER > bool "Fallback user-helper invocation for firmware loading" > depends on FW_LOADER > default y > > But at this point I suppose there is no point leaving it enabled. Yeah, not sure, if it could be removed. Fedora has that option disabled since a while. Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725714: udev firmware loading does not work in the Debian installer
On Fri, Dec 13, 2013 at 12:42 AM, Michael Biebl wrote: > Am 13.12.2013 00:34, schrieb Michael Biebl: > See also > http://lists.freedesktop.org/archives/systemd-devel/2013-November/014771.html > > But that thread just echoes what Kay already said, that user-space > firmware loading is deprecated and on it's way out. Right, it's gone, and upstream does not support it any more because it is technically the wrong solution and in-kernel loading the only supported option. It can all pretty trivially be made to run in userspsce like it did (unreliably in some cases) in the past, but the kernel and udev will need to be patched to do that. Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725714: udev firmware loading does not work in the Debian installer
On Fri, Dec 13, 2013 at 12:34 AM, Michael Biebl wrote: > Am 13.12.2013 00:26, schrieb Michael Biebl: >> Am 13.12.2013 00:12, schrieb Andreas Cadhalpun: >>> The Debian installer needs a way to load the firmware during >>> installation, otherwise the netinst.iso is pretty useless for WLAN >>> devices with non-free firmware. >>> Since a majority of the WLAN devices need non-free firmware, just >>> dropping this functionality without replacement is a serious regression. >>> Therefore I ask you to re-enable it until a replacement is written. >> >> Could something like isenkram [1] be integrated into d-i and install >> necessary (firmware) packages based on the modalias information? >> >> Especially [2] looks like it could be a replacement. >> That said, isenkram-autoinstall-firmware doesn't seem to use the >> modalias info and instead greps through the modinfo output which looks >> like a rather hackish approach on a cursory glance. > > According to codesearch.d.n, hw-detect is the only tool using > /run/udev/firmware-missing. I'm inclined to re-assign this bug to > hw-detect and let the hw-detect maintainers decided how to handle this. > If something like the isenkram approach would be suitable for them PackageKit used it too. General note: the entire idea of blindly recording firmware requests is flawed. It makes not much sense to make assumptions about drivers and that the files they ask for are *missing*, they are not in many cases. Many drivers just request things to check for updates which in many cases never exist. Or they request multiple files in a row, to fall back to older versions they find. The only sensible way to produce information about *missing* firmware would be to add explicit messages to the kernel when things are really *missing*. Blindly tracing firmware requests and guessing around never really made sense. Also: That all this is gone now is a side-effect of moving firmware loading into the kernel where it belongs. There is nothing userspace can do about, the information is just no longer available to userspace. Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725714: udev firmware loading does not work in the Debian installer
On Fri, Dec 13, 2013 at 12:26 AM, Michael Biebl wrote: > Am 13.12.2013 00:12, schrieb Andreas Cadhalpun: >> The Debian installer needs a way to load the firmware during >> installation, otherwise the netinst.iso is pretty useless for WLAN >> devices with non-free firmware. >> Since a majority of the WLAN devices need non-free firmware, just >> dropping this functionality without replacement is a serious regression. >> Therefore I ask you to re-enable it until a replacement is written. > > Could something like isenkram [1] be integrated into d-i and install > necessary (firmware) packages based on the modalias information? > > Especially [2] looks like it could be a replacement. > That said, isenkram-autoinstall-firmware doesn't seem to use the > modalias info and instead greps through the modinfo output which looks > like a rather hackish approach on a cursory glance. > > Kay, what's you opinion on something like this? It could work. The device modaliases of the running machine can produce the list of modules that will be loaded on a machine. The modules themselves carry the file names of the firmware files in the module's metadata. Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725714: udev firmware loading does not work in the Debian installer
On Fri, Dec 13, 2013 at 12:12 AM, Andreas Cadhalpun wrote: > On 12.12.2013 23:19, Kay Sievers wrote: >> On Thu, Dec 12, 2013 at 10:58 PM, Michael Biebl >> wrote: >>> This was removed upstream [1] and is highly unlikely to be added back. >>> Especially considering that the user space firmware loader is scheduled >>> to be removed sooner rather then later. >>> >>> This most likely means d-i needs to be updated to use some kind of >>> different mechanism to detect missing firmware. >>> >>> Kay, what is the recommended approach nowadays to detect such missing >>> firmware? >> >> There is no replacement for that. Userspace is no longer in the loop >> any more regarding firmware loading, it's all the kernel's job only. >> Hence, there will be no facility in udev for handling firmware, or >> getting notified about that. > According to Ben Hutchings the kernel still thinks udev is responsible for > handling missing firmware. Recent udev does not even have the code to handle firmware enabled. It's gone since a while already. >> The only possible solution would be to add explicit messages to the >> kernel drivers in case a firmware is really *missing* and the device >> does not just probe for stuff until it finds something. >> >> There are quite a lot devices which just look for *updates* and do not >> need anything to function. > In this case the WLAN devices really need the firmware to work, but since > the firmware is non-free, it is not included in the Debian installer. Which is not a technical problem, udev can or should try to solve. >> Such an explicit message would probably use printk_emit() and pass >> structured data with the filename and the ides from the kernel to >> userspace, and on systemd systems the journal would pick up the >> MESSAGE_ID and do something with it, or provide the data to other >> consumers. > The better approach would have been to write a replacement *before* dropping > the udev missing-firmware handling. There have been many technical reasons to let the kernel do the job, and that is how it works today, and it works well and reliably. > The Debian installer needs a way to load the firmware during installation, > otherwise the netinst.iso is pretty useless for WLAN devices with non-free > firmware. > Since a majority of the WLAN devices need non-free firmware, just dropping > this functionality without replacement is a serious regression. It is not, only if firmware is not installed, which seem to be a Debian-only problem but not a general one. Hence Debian needs to adopt/patch the software to do what it needs, and should not ask upstream to work around issues which seem to be a Debian-only problem. The in-kernel firmware loader solved years old serious problems, and it was worth to do it, and there is no reason to put back that fragile hack, just to solve a non-technical problem. > Therefore I ask you to re-enable it until a replacement is written. Udev will never load firmware again, the entire idea to use the driver core to create fake devices in userspace and let the kernel wait to them to be handled, was wrong at so many aspects, it will not come back from upstream udev. Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#730956: nuitka: FTBFS: Tests failed
Hello, > During a rebuild of all packages in sid, your package failed to build on amd64. Thanks for report. I also noticed this short time ago. CPython upstream has now included a patch that changes outputs, but the check tailored to Debian Python version no longer catches it. The new version of Nuitka to be released soon will address the issue by treating ">=2.7.6" the same as "2.7.5+". Best regards, Kay Hayen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711459: nuitka: can't import Python 3.2 modules: ImportError: dynamic module does not define init function
Hello, turns out, that CPython3 defines the module init function PyMODINIT_FUNC as follows: extern "C" PyObject * on the other hand, visibility attributes are supposed to be defined before the actual type, but since it's a define, one can't really get in between. I would content, that CPython should in fact, provide a visibility definition here. Otherwise, every module runs into it. Do you agree, I reckon having seen your name in other place, that you might know, Jakub. When it's not a type, as with CPython2: extern "C" void then it's acceptable, to define attributes afterwards. So Nuitka, using -fvisibility=hidden runs into trouble here. There is actually a bug report for gcc (the number I forgot), that complained about it, but that is how it should be, for pointers as return types, it won't work to define attributes after it. The solution is to test for __GNUC__ and to make its own declaration, not using PyMODINIT_FUNC. I am going to make a new release of Nuitka. The test didn't notice, because although it compiled all modules of Nuitka into single modules (that is the test, can be done more efficient), it was not copying the "nuitka" binary, and therefore it was location the "nuitka" package relative to that original place, not using them at all. So that had been broken for a while. It also found other (minor) issues, of why modules didn't work at all for Python3, and when they did, not correctly. Fixed them too. Will be fixed in 0.4.4 release. (If you or anybody need/want it sooner, checkout "factory" branch of official Nuitka repository. It's where I prepare releases, but reserve the right rebase often as I improve things.) Yours, Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711459: nuitka: can't import Python 3.2 modules: ImportError: dynamic module does not define init function
Hello Jakub, thank you for the report. I confirmed the bug indeed. Python is right here: nm Mini.so | grep PyInit b5b0 t PyInit_Mini The "t" in lower case means it's a local text symbol, i.e. it is not exported. Using CCFLAGS="-save-temps", I check the produced C++ code behind the preprocessor: grep PyInit module.Mini.ii extern "C" PyObject* PyInit_Mini( void ); extern "C" PyObject* PyInit_Mini( void ) It seems related to -fvisibility=hidden, the problem goes away which I remove that (from SingleExe.scons), one probably can override it from CCFLAGS too. Trying to get it what is used with Python2: extern "C" PyObject* __attribute__(( visibility( "default" ))) PyInit_Mini( void ); extern "C" PyObject* __attribute__(( visibility( "default" ))) PyInit_Mini( void ) gives this: Mini.build/module.Mini.hpp:7:82: warning: ‘visibility’ attribute ignored on non-class types [-Wattributes] Mini.build/module.Mini.cpp:225:82: warning: ‘visibility’ attribute ignored on non-class types [-Wattributes] And of course, still won't work. Unfortunately, the test, which is run at build time, to ensure that compiling modules works properly (and seems to compile them), is still working, i.e. there is also an error in tests/reflected/compile_itself.py that prevented me from detecting it. I will analyse this some more, and try to come up with a fix. However, using "nuitka --execute", it's also supposed to give you a warning, as it's a trap, but only if it sees you use "__main__". It's very likely though, that a user wants "nuitka --exe --execute" or rather "nuitka-python" instead. But this only as a side issue, in case your minimal test case, is not the reduction of a actual use. Thanks again for the report. I do have some hope, that the placement of the attribute is at fault, because with Python2, this gives "T": extern "C" void __attribute__(( visibility( "default" ))) initMini( void ); extern "C" void __attribute__(( visibility( "default" ))) initMini( void ) But that needs further research (over the weekend). Will keep you updated. Thanks, Kay Hayen Am 07.06.2013 02:10, schrieb Jakub Wilk: Package: nuitka Version: 0.4.3+ds-1 I cannot import modules that were compiled for Python 3.2: $ echo 'print(42)' > testcase.py $ nuitka --python-version=3.2 --execute testcase.py Traceback (most recent call last): File "", line 1, in ImportError: dynamic module does not define init function (PyInit_testcase) -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.9-1-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages nuitka depends on: ii g++-4.6 4.6.4-2 ii python 2.7.3-5 ii python-dev 2.7.3-5 ii scons 2.3.0-2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#678813: Bug confirmation
I can confirm this bug with Avery Letter Size 5160, LibreOffice Writer 3.5.4.2. I thought the settings for Avery 5160 must be incorrect, so I adjusted them for 2 hours without being able to get the 3rd column to print far enough to the right to be fully on the label. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683090: nuitka: does not honour DEB_BUILD_OPTIONS=nocheck
Hello Jakub, In fact there is "NUITKA_SKIP_TESTS=1" that I have been using, and I am going to support the Debian standard instead. I have just added support for it and it will be in the next release. In the mean time, you can use the old way if you wish to. Yours, Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#667706: openssl 1.0.1 breaks wpa_supplicant
No luck on the openssl front, but a patch to wpa_supplicant that disables TLS session tickets does the trick for me. See http://w1.fi/bugz/show_bug.cgi?id=447 I've attached a debdiff against wpa. diff -Nru wpa-1.0/debian/changelog wpa-1.0/debian/changelog --- wpa-1.0/debian/changelog 2012-05-13 16:39:47.0 -0400 +++ wpa-1.0/debian/changelog 2012-07-23 13:34:13.0 -0400 @@ -1,3 +1,12 @@ +wpa (1.0-2.1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Disable TLS session tickets. Ever since the release of openssl-1.0.1, +session tickets have (apparently) prevented WPA2 enterprise authentication +against some (probably broken) access points. (Bug #667706) + + -- Benjamin Kay Mon, 23 Jul 2012 13:33:49 -0400 + wpa (1.0-2) unstable; urgency=low * Really enable hardened build flags, thanks Simon Ruderich diff -Nru wpa-1.0/debian/patches/disable_session_tickets.patch wpa-1.0/debian/patches/disable_session_tickets.patch --- wpa-1.0/debian/patches/disable_session_tickets.patch 1969-12-31 19:00:00.0 -0500 +++ wpa-1.0/debian/patches/disable_session_tickets.patch 2012-07-23 13:33:32.0 -0400 @@ -0,0 +1,14 @@ +Disables TLS session tickets, thereby avoiding enterprise authentication +failures against some (probably broken) access points that had arisen since +the release of openssl-1.0.1. +See http://w1.fi/bugz/attachment.cgi?id=235&action=diff +--- a/src/crypto/tls_openssl.c b/src/crypto/tls_openssl.c +@@ -926,6 +926,7 @@ + #ifdef SSL_OP_NO_COMPRESSION + options |= SSL_OP_NO_COMPRESSION; + #endif /* SSL_OP_NO_COMPRESSION */ ++ options |= SSL_OP_NO_TICKET; + SSL_set_options(conn->ssl, options); + + conn->ssl_in = BIO_new(BIO_s_mem()); diff -Nru wpa-1.0/debian/patches/series wpa-1.0/debian/patches/series --- wpa-1.0/debian/patches/series 2012-04-17 07:03:56.0 -0400 +++ wpa-1.0/debian/patches/series 2012-07-23 13:33:32.0 -0400 @@ -6,3 +6,4 @@ 12_wpa_gui_knotify_support.patch 13_human_readable_signal.patch libnl3-includes.patch +disable_session_tickets.patch
Bug#682145: nuitka: insecure use of temporary files
Hello Jakub, nuitka creates temporary files insecurely in a few places: * misc/make-dependency-graph.sh: This is not part of the binary package, it's part of the upstream tarball and purely a developer tool. ( sfood nuitka | egrep -v "'(sys|signal|math|os.py|re.py|nuitka/(oset|odict).py)'" | sfood-graph | dot -Tps >/tmp/out.ps ) && evince /tmp/out.ps * nuitka/codegen/CppRawStrings.py: source_file = open( "/tmp/raw_test.cpp", "w" ) It's also executing the compiled source put there, but only if "_paranoid_debug" which is constant "False" in the source code. The installed binary package cannot run this code, can it? Do I need to take action here? I probably should remove it from the source in a patch for Debian, or make it more secure. * bin/benchmark.sh: $NUITKA_BINARY --exe --output-dir=/tmp/ --unstriped $NUITKA_EXTRA_OPTIONS $1 Same as the first entry, this is not part of the binary package, it's part of the upstream tarball and purely for developer purposes. I have to admit, that I have little clues, on how to create temporary directory names, or also how to do that in "/var/tmp" in any portable way in shell script. I will probably port the two scripts to Python and use the tempfile module, which allows me to be better at it. So, this bug will be addressed in the upcoming upstream release too. Best regards, Kay Hayen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682146: nuitka: broken if g++ is not installed: TypeError: argument of type 'NoneType' is not iterable
Hello Jakub, what I didn't know is that only the "g++" package provides the "g++" binary, and that the "g++-4.6" doesn't. I wonder why my minimal Debian chroot used for building has it. What I noticed is this "apt-get remove g++" wants to remove "build-essential" package. So a adding dependency on that is probably in order and solves the problem. Setting the CXX environment variable doesn't help much: $ CXX=g++-4.6 nuitka test.py KeyError: 'CXXVERSION': File "/usr/share/nuitka/nuitka/build/SingleExe.scons", line 216: gpp_version = int( env[ "CXXVERSION" ].replace( ".", "" ) ) File "/usr/lib/scons/SCons/Environment.py", line 409: return self._dict[key] This is a problem by itself that I will fix too with an upstream update soon. There is code to update "CXXVERSION" if Nuitka is asked to cross compile to Windows, and if "CXX" is fed from environment variable, the Scons won't uddate "CXXVERSION", so we have to do it outselves. Sorry about that. Installing g++ does fix the problem, but this package is neither depended on nor recommended by nuitka. Truly so. Thanks for your report. I will prepare an upload in the next days that will address the "g++" bug, and also the "CXX" environment bug. I think I have only tested "CXX" for setting to "clang", which has no check on "CXXVERSION" currently. Yours, Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675205: openssh-client: openssh 1:6.0 should depend on libssl1.0.0 >= 1.0.1
Package: openssh-client Version: 1:6.0p1-1 Severity: normal Dear Maintainer, openssh-client depends on libssl1.0.0 >= 1.0.0, but is should depend on libssl1.0.0 >= 1.0.1. With libssl1.0.0_1.0.0h-1 installed, attempts to login to a remote server using public key authentication produce the following error: OpenSSL version mismatch. Built against 1000103f, you have 108f Downgrading to openssh-client_5.9p1-5 serves as a workaround. I'm assuming that upgrading libssl1.0.0 (which I can't do due to an unrelated bug in that package) would also make the error go away. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openssh-client depends on: ii adduser3.113+nmu2 ii debconf [debconf-2.0] 1.5.43 ii dpkg 1.16.3 ii libc6 2.13-32 ii libedit2 2.11-20080614-3 ii libgssapi-krb5-2 1.10.1+dfsg-1 ii libselinux12.1.9-4 ii libssl1.0.0 ii passwd 1:4.1.5.1-1 ii zlib1g 1:1.2.7.dfsg-11 Versions of packages openssh-client recommends: ii openssh-blacklist0.4.1 ii openssh-blacklist-extra 0.4.1 ii xauth1:1.0.7-1 Versions of packages openssh-client suggests: pn keychain pn libpam-ssh pn monkeysphere pn ssh-askpass -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#667706: openssl 1.0.1 breaks wpa_supplicant
On Monday, April 30, 2012 20:15:26 Raghav Krishnapriyan wrote: > On Sun, Apr 29, 2012, at 07:26:11 pm +0200, Kurt Roeckx wrote: > >Can you please try with the 1.0.1b version? > > 1.0.1b still results in the same problem, unfortunately. > FYI, 1.0.1c (the most current version at the time of this writing) also still results in the same problem. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#665021: nuitka: FTBFS: unsatisfiable build-dependencies: base-files (< 6.0) but 6.7 is to be installed
Hello Lucas, Am 23.03.2012 10:27, schrieb Lucas Nussbaum: So it's much easier to fix that problem in your package, for example by build-depending on B | A. I totally agree and prepare an upload with this for my sponsor Yaroslav Halchenko at the next opportunity. Yours, Kay Hayen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#665021: nuitka: FTBFS: unsatisfiable build-dependencies: base-files (< 6.0) but 6.7 is to be installed
Hello Lucas, As to deterministic, are you implying that the choice is not made in a deterministic way? It probably is just that somebody or something hates it when not all choices are valid. If you use alternative build-deps, two builds of the same package at the same time might produce different binary packages (and it could happen that the i386 and amd64 packages are built against different dependencies, for example). That is not something desirable. As you can imagine, I would prefer to use optional build-deps and use the alternative one only as a stop-gap. The selected version of base-files is carefully selected to achieve the desired effect, i.e. no Debian this package builds on has both, so there cannot be indeterminism at all. Yet, I would also like to understand (feel free to ignore my desire to learn, and notice how it cannot apply to the Nuitka package as state above): Why (in a chroot, mind you) if both alternatives are available, a random one would be picked. Is there really a "random()" call in dpkg. Or was this just a general statement relating to non-chroot builds, where it clearly will be true that if the second one is already installed, it will change the result. Yours, Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#665021: nuitka: FTBFS: unsatisfiable build-dependencies: base-files (< 6.0) but 6.7 is to be installed
Hello Lucas, I am assuming a bug in an underlying package and ask to reassign this bug. Indeed, sbuild tends to drop alternative build-depends in order to enforce deterministic builds. I'm not sure if there's a bug in sbuild there, but given that squeeze and later have base-files>= 6.0, I'd recommend just dropping the alternative build-dep. The source package as is builds for older versions of Debian too. The idea of this dependency is to make an optional build dependency. I didn't find any other means to achieve it. So on Squeeze it is supposed to use "python3-all-dev" and on earlier version, it should accept that it is missing. If "sbuild" prefers the first choice (kind of makes sense now that I write this sentence), I should probably just reorder in the next upload, and that would fix the bug. As to deterministic, are you implying that the choice is not made in a deterministic way? It probably is just that somebody or something hates it when not all choices are valid. Best regards, Kay Hayen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#665021: nuitka: FTBFS: unsatisfiable build-dependencies: base-files (< 6.0) but 6.7 is to be installed
Hello Lucas, The following packages have unmet dependencies: sbuild-build-depends-nuitka-dummy : Depends: base-files (< 6.0) but 6.7 is to be installed Depends: base-files (< 6.0) but 6.7 is to be installed E: Broken packages The full build log is available from: http://people.debian.org/~lucas/logs/2012/03/21/nuitka_0.3.20.1+ds-1.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on about 50 AMD64 nodes of the Grid'5000 platform, using a clean chroot. Internet was not accessible from the build systems. The relevant part of the control file is this: Build-Depends: debhelper (>= 7.4.3), g++-4.6 (>= 4.6.1) | g++-4.5, python (>= 2.6.6-2), python-all-dbg (>= 2.6.6-2), python-all-dev (>= 2.6.6-2), rst2pdf (>= 0.14-2), scons (>=2.0.0), base-files (<<6.0) | python3-all-dev (>= 3.2), base-files (<<6.0) | python3-all-dbg (>= 3.2) Consider the last two lines. The versioned dependency on base-files can be fulfilled by having python3-all-dev and python3-all-dbg available for install. Checking the archive, these appear to be still available: apt-show-versions -a python3-all-dbg python3-all-dbg 3.2.2-1 install ok installed python3-all-dbg 3.2.2-1 testing ftp.debian.org python3-all-dbg 3.2.3~rc1-2 unstable ftp.debian.org python3-all-dbg/testing uptodate 3.2.2-1 apt-show-versions -a python3-all-dev python3-all-dev 3.2.2-1 install ok installed python3-all-dev 3.2.2-1 testing ftp.debian.org python3-all-dev 3.2.3~rc1-2 unstable ftp.debian.org python3-all-dev/testing uptodate 3.2.2-1 For some reason, the log of yours says: Merged Build-Depends: base-files, base-passwd, bash, coreutils, dash, debianutils, diffutils, dpkg, e2fsprogs, findutils, grep, gzip, hostname, ncurses-base, ncurses-bin, perl-base, sed, login, sysvinit-utils, sysvinit, tar, bsdutils, mount, util-linux, libc6-dev | libc-dev, gcc (>= 4:4.4.3), g++ (>= 4:4.4.3), make, dpkg-dev (>= 1.13.5), debhelper (>= 7.4.3), g++-4.6 (>= 4.6.1) | g++-4.5, python (>= 2.6.6-2), python-all-dbg (>= 2.6.6-2), python-all-dev (>= 2.6.6-2), rst2pdf (>= 0.14-2), scons (>= 2.0.0), base-files (<< 6.0) | python3-all-dev (>= 3.2), base-files (<< 6.0) | python3-all-dbg (>= 3.2) Filtered Build-Depends: base-files, base-passwd, bash, coreutils, dash, debianutils, diffutils, dpkg, e2fsprogs, findutils, grep, gzip, hostname, ncurses-base, ncurses-bin, perl-base, sed, login, sysvinit-utils, sysvinit, tar, bsdutils, mount, util-linux, libc6-dev, gcc (>= 4:4.4.3), g++ (>= 4:4.4.3), make, dpkg-dev (>= 1.13.5), debhelper (>= 7.4.3), g++-4.6 (>= 4.6.1), python (>= 2.6.6-2), python-all-dbg (>= 2.6.6-2), python-all-dev (>= 2.6.6-2), rst2pdf (>= 0.14-2), scons (>= 2.0.0), base-files (<< 6.0), base-files (<< 6.0) Witness how that filtering removed the "|" conditions in both cases and then insisted on "base-files << 6.0". It appears that my pbuilder, in sid doesn't at all do this merging and filtering of build dependencies, and therefore doesn't exhibit this problem, here it says: Depends: debhelper (>= 7.4.3), g++-4.6 (>= 4.6.1) | g++-4.5, python (>= 2.6.6-2), python-all-dbg (>= 2.6.6-2), python-all-dev (>= 2.6.6-2), rst2pdf (>= 0.14-2), scons (>= 2.0.0), base-files (<< 6.0) | python3-all-dev (>= 3.2), base-files (<< 6.0) | python3-all-dbg (>= 3.2) I am assuming a bug in an underlying package and ask to reassign this bug. Yours, Kay Hayen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#648629: segfault in libgnome-shell.so at startup
Hello, this bug report can be closed. I had a hard disk crash and did a clean installation. Now gnome-shell works very well. And sorry for the garbage at the beginning of my bug report. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#655910: Hotfix release done
Hello, this is to let you know that I just an uploaded an improved package to mentors.debian.net that addresses this bug: http://mentors.debian.net/debian/pool/main/n/nuitka/nuitka_0.3.18.1+ds-1.dsc Note that I changed the upstream version numbering for hotfixes, what normally was a "0.3.18a" is now a "0.3.18.1" instead. Yours, Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#655910: oddities in the manpage
Hello Yaroslav, thanks for reporting the bug. manpage has odd formatting in --recurse-to=MODULE/PACKAGE Recurse to that module, or if a package, to the whole package. Can be given multiple times.Default empty. Thanks corrected. This was coming from the optparse declaration of the option, and as such was also present in "--help". also you might like to group options into few sections instead of invisible embeddings like Dump options for internal tree: help2man you have used has an option for embedding arbitrary *roff given pattern to match: Blocks of verbatim *roff text are inserted into the output either at the start of the given [section] (case insensitive), or after a paragraph matching /pattern/. The output of "--help" is good in this respect. I believe it's an issue of "help2man", but I couldn't find anybody who needs or uses it, so we are on our own here. I am using this "help2man" option already to attach the examples section. I do not believe that adding after a match is good enough for this. So what I do now is to make changes to the nroff file after it was created. I am searching the control sections (first line in a ."IP" block) and replace it with ".SS" to add the subsection text with a forced newline as well. And while at it, I am fixing the problem with "--g++-only" up as well, where the bold text stops too early. I am now preparing an "0.3.18a" release that contains these fixes. Yours, Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#648489: Package available on mentors.debian.net
The package, meanwhile 0.3.17pre2 is available as a package from here: http://mentors.debian.net/package/nuitka Regards, Kay Hayen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#648629: segfault in libgnome-shell.so at startup
Package: gnome-shell Version: 3.0.2-5 Severity: important Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** I start gnome 3 via gdm3. The gnome-shell crashes a few seconds after login. Same with a new user, so it is not related to old gnome settings. Here is what is written in syslog: kernel: [ 3698.793547] gnome-shell[12429]: segfault at 4 ip b76a9c2f sp bfb51360 error 4 in libgnome-shell.so[b7673000+a5000] This is the output of lspci: 00:00.0 Host bridge: Intel Corporation Mobile 945GME Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) 00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02) 00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 02) 00:1d.0 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02) 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02) 00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02) 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02) It is an Intel Atom N270 based netbook. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.0.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.7.5-3 ii gconf2 2.32.4-1 ii gir1.2-atk-1.0 2.2.0-2 ii gir1.2-clutter-1.0 1.8.2-1 ii gir1.2-cogl-1.0 1.8.2-1 ii gir1.2-coglpango-1.0 1.8.2-1 ii gir1.2-freedesktop 0.10.8-2+b1 ii gir1.2-gconf-2.0 2.32.4-1 ii gir1.2-gdkpixbuf-2.0 2.24.0-1 ii gir1.2-gkbd-3.0 3.2.0-1 ii gir1.2-glib-2.0 0.10.8-2+b1 ii gir1.2-gnomebluetooth-1.03.2.1-1 ii gir1.2-gtk-3.0 3.0.12-2 ii gir1.2-json-1.0 0.14.0-1 ii gir1.2-mutter-3.03.0.2.1-4 ii gir1.2-networkmanager-1.00.9.0-2 ii gir1.2-pango-1.0 1.29.4-2 ii gir1.2-polkit-1.00.102-1 ii gir1.2-telepathyglib-0.120.16.0-1 ii gir1.2-telepathylogger-0.2 0.2.10-2 ii gir1.2-upowerglib-1.00.9.14-1 ii gjs 1.29.0-2+b1 ii gnome-bluetooth 3.2.1-1 ii gnome-icon-theme-symbolic3.2.1-1 ii gnome-settings-daemon3.0.3-3 ii gsettings-desktop-schemas3.0.1-1 ii libatk1.0-0 2.2.0-2 ii libc62.13-21 ii libcairo-gobject21.10.2-6.1 ii libcairo21.10.2-6.1 ii libcamel-1.2-23 3.0.3-1 ii libcanberra0 0.28-3 ii libclutter-1.0-0 1.8.2-1 ii libcogl-pango0 1.8.2-1 ii libcogl5 1.8.2-1 ii libcroco30.6.2-2 ii libdbus-1-3 1.4.16-1 ii libdbu
Bug#648489: ITP: nuitka -- Nuitka is a fully compatible Python compiler, capable of accelerating the execution.
Package: wnpp Severity: wishlist Owner: Kay Hayen * Package name: nuitka Version : 0.3.15 Upstream Author : Name * URL : http://nuitka.net/ * License : GPLv3, uses BSD parts. Programming Lang: Python, C++, Assembler Description : Nuitka is a fully compatible Python compiler, capable of accelerating the execution.# Nuitka is a good replacement for the Python interpreter and compiles every construct that CPython 2.6 and 2.7 offer. It translates the Python into a C++ program that then uses “libpython” to execute in the same way as CPython does, in a very compatible way. The speed improvement is currently not very high, but the plan is to become very compatible first, and then to optimize for speed through compile time type inference. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#557103: upgraded uw-imapd to dovecot
I should have reported this in May when I did the Lenny-> Squeeze upgrade. I couldn't get Uw-imapd working at all after the dist-upgrade, despite it having worked relatively trouble-free for many years through a few Debian releases. As I was fighting other fires at the time following the dist-upgrade of a complex email setup, I replaced the functionality using Dovecot . In my view unless maintained upstream and within Debian, uw-imapd should be removed from Debian as obsolete. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#579357: Aw: Bug#579357: AW: Bug#579357: AW: [Pkg-samba-maint] Bug#579357: AW: Bug#579357: winbind: passwd/smbpasswd causes segmentation fault on Debian Lenny x64 (Samba Winbind and Windows Active
Hello, I am running into the same problem here. Is there a solution for anybody? Regards, Kay Am Mittwoch, 16. Juni 2010 15:20:01 UTC+2 schrieb Phillip Drescher: > Hello, > > are there any new information / developments regarding that problem? Is > there any hope? ;) > > Regards, Phillip > > > -Ursprüngliche Nachricht- > > Von: Phillip Drescher [mailto:p...@slums.de] > > Gesendet: Freitag, 7. Mai 2010 16:48 > > An: 'Steve Langasek'; '579...@bugs.debian.org' > > Betreff: AW: Bug#579357: AW: [Pkg-samba-maint] Bug#579357: AW: > > Bug#579357: winbind: passwd/smbpasswd causes segmentation fault on > > Debian Lenny x64 (Samba Winbind and Windows Active Directory) > > > > Quoting Steve Langasek [mailto:vor...@debian.org] > > > > > Please run 'gdb passwd' and enter the commands 'run ' followed > > by > > > 'bt full' when it crashes. This will give us a full backtrace, > > rather > > > than just the segfault location in the log file. > > > > Debian:~# gdb passwd > > GNU gdb 6.8-debian > > (...) > > This GDB was configured as "x86_64-linux-gnu"... > > (no debugging symbols found) > > (gdb) run > > Starting program: /usr/bin/passwd > > (no debugging symbols found) > > (no debugging symbols found) > > (no debugging symbols found) > > (no debugging symbols found) > > (no debugging symbols found) > > (no debugging symbols found) > > (no debugging symbols found) > > (no debugging symbols found) > > (no debugging symbols found) > > (no debugging symbols found) > > (no debugging symbols found) > > (no debugging symbols found) > > (no debugging symbols found) > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x7ffce38ab49e in pam_sm_chauthtok (pamh=0x60d740, > > flags=, argc=, > > argv=) at ../nsswitch/pam_winbind.c:3187 > > 3187../nsswitch/pam_winbind.c: No such file or directory. > > in ../nsswitch/pam_winbind.c > > (gdb) bt full > > #0 0x7ffce38ab49e in pam_sm_chauthtok (pamh=0x60d740, > > flags=, argc=, > > argv=) at ../nsswitch/pam_winbind.c:3187 > > lctrl = > > ret = 4 > > user = 0x4e4c8f9e0 > > pass_old = 0x60b560 "" > > pass_new = 0x0 > > Announce = > > username_ret = 0x0 > > error = (struct wbcAuthErrorInfo *) 0x0 > > ctx = (struct pwb_context *) 0x0 > > #1 0x7ffce50b5c42 in ?? () from /lib/libpam.so.0 > > No symbol table info available. > > #2 0x7ffce50b973d in pam_chauthtok () from /lib/libpam.so.0 > > No symbol table info available. > > #3 0x0040403f in ?? () > > No symbol table info available. > > #4 0x00403711 in ?? () > > No symbol table info available. > > #5 0x7ffce495f1a6 in __libc_start_main () from /lib/libc.so.6 > > No symbol table info available. > > #6 0x004025e9 in ?? () > > ---Type to continue, or q to quit--- > > No symbol table info available. > > #7 0x7fffe798 in ?? () > > No symbol table info available. > > #8 0x001c in ?? () > > No symbol table info available. > > #9 0x0002 in ?? () > > No symbol table info available. > > #10 0x7fffeaae in ?? () > > No symbol table info available. > > #11 0x7fffeabe in ?? () > > No symbol table info available. > > #12 0x in ?? () > > No symbol table info available. > > > > > -- > To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628822: gtk-redshift should depend on python-gtk2 but doesn't
Package: gtk-redshift Version: 1.6-1 Severity: important gtk-redshift does not start on my system. Running gtk-redshift from the commandline produces the following output: Traceback (most recent call last): File "/usr/bin/gtk-redshift", line 22, in from gtk_redshift.statusicon import run File "/usr/lib/pymodules/python2.6/gtk_redshift/statusicon.py", line 33, in import gtk, glib ImportError: No module named gtk Installing the package python-gtk 2.24.0-2 resolves this problem and allows gtk-redshift to start and function normally. (Earlier versions of python-gtk2 would probably work equally well.) Since python-gtk2 is necessary for gtk-redshift to work, gtk-redshift should probably depend on the python-gtk2 package. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gtk-redshift depends on: ii python2.6.6-14 interactive high-level object- orie ii python-support1.0.13 automated rebuilding support for P ii python-xdg0.19-3 Python library to access freedeskt ii redshift 1.6-1 Adjusts the color temperature of y gtk-redshift recommends no packages. gtk-redshift suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#618417: python-twisted-words: Jabber ports do not work any more
Package: python-twisted-words Version: 10.2.0-1 Severity: important Hi. My PyICQt stopped working recently. I found out that jstrports.py depends on the _parse method from strports.py (python-twisted-core) which was removed in 10.2.0. This renders PyICQt completely unsusable. I added part of the PyICQt logfile below with the call stack of the error. Regards Kay Zumbusch -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages python-twisted-words depends on: ii python 2.6.6-3+squeeze5 interactive high-level object-orie ii python-openssl 0.10-1 Python wrapper around the OpenSSL ii python-twisted-core 10.2.0-1 Event-based framework for internet ii python2.6 2.6.6-8+b1 An interactive high-level object-o python-twisted-words recommends no packages. python-twisted-words suggests no packages. -- Logfile of PyICQt [2011-03-14 22:16:13] Removing stale pidfile /var/run/pyicqt/pyicqt.pid [2011-03-14 22:16:13] Traceback (most recent call last): [2011-03-14 22:16:13] File "/usr/share/pyicqt/PyICQt.py", line 14, in [2011-03-14 22:16:13] main.main() [2011-03-14 22:16:13] File "/usr/share/pyicqt/src/main.py", line 465, in main [2011-03-14 22:16:13] app = App() [2011-03-14 22:16:13] File "/usr/share/pyicqt/src/main.py", line 434, in __init__ [2011-03-14 22:16:13] self.c = component.buildServiceManager(jid, config.secret, "tcp:%s:%s" % (config.mainServer, config.port)) [2011-03-14 22:16:13] File "/usr/lib/python2.6/dist-packages/twisted/words/protocols/jabber/component.py", line 323, in buildServiceManager [2011-03-14 22:16:13] client_svc = jstrports.client(strport, svc.getFactory()) [2011-03-14 22:16:13] File "/usr/lib/python2.6/dist-packages/twisted/words/protocols/jabber/jstrports.py", line 30, in client [2011-03-14 22:16:13] name, args, kw = parse(description, factory) [2011-03-14 22:16:13] File "/usr/lib/python2.6/dist-packages/twisted/words/protocols/jabber/jstrports.py", line 25, in parse [2011-03-14 22:16:13] args, kw = strports._parse(description) [2011-03-14 22:16:13] File "/usr/lib/python2.6/dist-packages/twisted/python/deprecate.py", line 281, in __getattribute__ [2011-03-14 22:16:13] value = getattr(_module, name) [2011-03-14 22:16:13] AttributeError: 'module' object has no attribute '_parse' -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568347: Should use upper case for encoding names
Just to double check here; I see the project page has both a saxon6, Saxon-B and a Saxon-HE and we currently only ship a saxon (6.5.5) and a saxonb (which I assume are saxon6 and Saxon-B respectively). Is Saxon-HE the latest stable release? If we confine ourselves to open-source versions of the product: Saxon 6.5.5 was the end of the line for the XSLT 1.0 processor. It was produced as a maintenance release in 2005, but there had been no development other than bug-fixing since late 2001. There are still a significant number of users, but generally I recommend people to move to Saxon 9.x even if they are sticking with XSLT 1.0. It's not a trivial move for everyone, of course, because over that number of years the number of small changes accumulates to become quite a conversion minefield. Around 2002 development of Saxon as an XSLT 2.0 processor began; this continued through the 7.x releases; reaching 8.0 in 2004. At that stage I formed Saxonica to develop the product, and split it into the open source Saxon-B and the commercial Saxon-SA products. That continued through a sequence of 8.x releases up to and including the 9.1 release in 2008. In mid 2009, with the 9.2 release, I introduced another repackaging, this time into three variants (HE, PE, EE - for home, professional, and enterprise). The aim here (and it was successful) was unashamedly to get more of the serious commercial users of the product to pay something towards its development, and this was achieved by discontinuing some of the more advanced features of Saxon-B from the HE product. So Saxon-HE 9.2 is actually a subset of Saxon-B 9.1. (That upset a few people, of course, but for me open source has always been a route to market, not a philosophy of life). Saxon 9.3 was introduced a couple of months ago, again in (HE, PE, EE) variants: it's proving quite reliable, but the latest maintenance release of 9.2 can probably claim to be the most stable version today. So for the open source community, the choice is really between Saxon-B 9.1 which has more functionality but is a dead end, and Saxon-HE 9.2/9.3 which is being actively maintained and developed. Regards, Michael Kay Saxonica -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568347: Should use upper case for encoding names
The observation is quite correct. However, Saxon 6.5.5 is a mature release (the last Saxon release on the XSLT 1.0 branch) and there are no plans to issue any further maintenance releases on this branch unless critical problems are found. This problem is not considered critical. Michael Kay Saxonica -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#507716: Email Quota Alert
From: Campbell, Kay Sent: Monday, August 09, 2010 4:35 AM To: Campbell, Kay Subject: Email Quota Alert You have reached the limit of your mailbox by your web mail service, and you will not be able to send and receive emails. To prevent this, click on the link below to reset your account. http://www.webmail-emailupgradeplus.us.tt<http://www.webmail-emailupgradeplus.us.tt/> Failure to do so will result in a limited access to your mailbox. Warning! Reverence. Web service NOTICE: The information contained in this e-mail may be confidential and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained herein by any other person is not authorized. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator
Bug#591290: Buffer I/O error on device sr0, logical block 0
On Mon, Aug 9, 2010 at 08:02, Stanislav Maslovski wrote: > On Tue, Aug 03, 2010 at 08:20:03AM +0200, Kay Sievers wrote: > Thanks for your input. I did what you suggested; the log from runnig > 'udevadm test /class/block/sr0' is attached to this e-mail. I see lots > of the same errors in dmesg when I run this test (see below). I can do > further tests if you tell me which calls I should run manually. It's a Debian bug. With upstream udev rules from 'make install', blkid runs only for data disks. Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#591290: Buffer I/O error on device sr0, logical block 0
> When booting with an audio CD in the drive, at the stage of udev > populating /dev/ I see these errors on the screen and also in the > dmesg output: > . > [ 11.216120] sr 3:0:0:0: [sr0] Result: hostbyte=DID_OK > driverbyte=DRIVER_SENSE > [ 11.216127] sr 3:0:0:0: [sr0] Sense Key : Illegal Request [current] > [ 11.216135] sr 3:0:0:0: [sr0] Add. Sense: Illegal mode for this track > [ 11.216144] sr 3:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 00 00 00 > 00 02 00 Maybe a not fixed udisks, called from udev rules: http://cgit.freedesktop.org/udisks/commit/?id=c2464f7bf215cd17962e917b974c573378d4e58b Udev should not cause this anymore. Doing udevadm test /class/block/sr0 should show what's actually called, and repeating the listed calls manually, should show in the log what's causing the messages. Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#583283: udev - Weird behaviour with device names including a slash
I take that back, tested it, devtmpfs works fine with the '!' magic. The driver core translates the stuff already. Looks like a different issue then. If you kill udevd, unload the module, delete the possible remaining node, then load the module again, what has devtmpfs created? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#583283: udev - Weird behaviour with device names including a slash
Yeah, devtmpfs misses the magic '!' -> '/' support. I'll go and fix this.
If you don't want to change the device name, you can fill-in the name
in the miscdevice structure, like:
static struct miscdevice tun_miscdev = {
.minor = TUN_MINOR,
.name = "tun",
.nodename = "net/tun",
.fops = &tun_fops,
};
Kay
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550152: udev - Remove symlinks
Udev should no longer delete the link it has created: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=6252f9e732c827defdac38e2eccab0657492d9c9 Still, replacing the default kernel-named nodes with links with the same name can result in unexpected behavior and is not supported. It does not matter if devtmpfs is used or not, today the kernel defines the device nodes names, and udev manages only additional symlinks and the node's permissions. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550152: udev - Remove symlinks
On Mon, Apr 19, 2010 at 13:28, Mario 'BitKoenig' Holbe
wrote:
> On Mon, Apr 19, 2010 at 11:39:28AM +0200, Kay Sievers wrote:
>> On Sun, Apr 18, 2010 at 23:08, Marco d'Itri wrote:
>> >> On Apr 18, Mario 'BitKoenig' Holbe wrote:
>> >> > KERNEL=="audio", NAME="%k0", SYMLINK+="%k"
>> > /etc/udev/rules.d/00-local.rules
>>
>> If this specifies a name different than the kernel device name, it is
>> something that should be fixed.
>
> These are my own local rules and yes, these rules specify lots of
> rename-rules like the one above.
>
> Call it obsessive (well, this is what I'm calling it sometimes :)) or
> whatever you like. I personally don't like the kernel's style to threat
> 0-devices naming different than subsequent ones and prefer the other way
> around. I was free to do this all the time from the beginning of ages
> (i.e. static, fs-based /dev) up to udev 141. I always did this at my own
> risk and it was never a problem. I don't want to push my opinion about
> this to others, and I'm sure there are others with exactly the opposite
> opinion. I'd just like to be free again :)
Yeah, I'll check the current behavior, and if this is easy to fix.
It's weird to delete a link we just created in the same moment
ourselves. :)
But it might still cause problems now or in the future to replace the
defined kernel name with a symlink with the same name. Multiple
devices can claim the same name and the actual link that is created
get managed by a priority value. When a device goes away, the link
with the next highest priority is re-created. This all will fail in
interesting ways if links and node names are mixed. So the supported
solution is not to touch the kernel names and let udev manage only
symlinks to the standard kernel-provided name.
> I don't know what you exactly consider "different"... just a few
> examples for you to explain which of those you consider "good" and which
> "bad":
>
> SUBSYSTEM=="bsg", NAME="bsg/%k"
> SUBSYSTEMS=="usb", KERNEL=="hiddev[0-9]*", NAME="usb/%k"
> SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
> NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}"
> KERNEL=="capi", NAME="capi20",
> KERNEL=="capi[0-9]*", NAME="capi/%n"
> KERNEL=="card[0-9]*", NAME="dri/%k"
> KERNEL=="hw_random", NAME="hwrng"
> KERNEL=="cdemu[0-9]*", NAME="cdemu/%n"
> KERNEL=="pktcdvd[0-9]*", NAME="pktcdvd/%n"
> KERNEL=="cpu[0-9]*", NAME="cpu/%n/cpuid"
They are all gone from the upstream rules, and provided by the kernel
itself. And are only needed for older kernels. There is a
"compat.rules" file in the udev tree which has collected all these
rules, in case old kernels should run with a new udev:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=rules/gentoo/30-kernel-compat.rules;hb=HEAD
>> > Apart from my own rules this seems to be quite a common behaviour.
>> Swapping plain kernel-defined names with symlinks is not supported. It
>> may work, but the behavior is undefined.
>
> Well, this is basically the reason why in my own local rules I generally
> provide symlinks from the kernel-defined names to the ones I prefer
> (which triggers the bug we were talking about here :)).
>
>> > Well, I think moving device nodes forth and back in the /dev tree is
>> > quite common behavior
>> Upstream udev does not really support this. Kernel device names are
>> defined (and optionally created and deleted) by the kernel these days.
>
> All right, devfs-style so to say.
It is a real devfs. With devtmpfs the model for udev has changed a
bit. We passed control over the device nodes, and the names to the
kernel, and udev it is expected to manage only permissions and
additional symlinks now.
Kay
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550152: udev - Remove symlinks
On Mon, Apr 19, 2010 at 12:13, Bastian Blank wrote: > On Mon, Apr 19, 2010 at 11:56:37AM +0200, Kay Sievers wrote: >> This is not supported and must be fixed. Udev does not support >> swapping primary device names around, and devtmpfs will always create >> the device node with the kernel name anyway. > > The documentation does not stat this constraint. It's a recent change in behavior. Please add this, if you think it should be mentioned. > And udev is not devtmpfs. I guess, I know a bit about both. :) And devtmpfs, which is mandatory by most major distros now, changed a bit of udev's logic. Udev is still expected to work without devtmpfs, but devtmpfs still defines the supported udev features, and some future version of udev may even require devtmpfs. Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550152: udev - Remove symlinks
On Mon, Apr 19, 2010 at 11:46, Marco d'Itri wrote:
> On Apr 19, Kay Sievers wrote:
>
>> > /lib/udev/rules.d/55-dm.rules
>> Device-mapper is work-in-progress, and probably just uses NAME=""
>> which is ok.
> There is this rule, which is what the original poster was complaining
> about:
>
> ENV{DM_NAME}=="?*", NAME="mapper/$env{DM_NAME}", SYMLINK+="$kernel"
This is not supported and must be fixed. Udev does not support
swapping primary device names around, and devtmpfs will always create
the device node with the kernel name anyway.
If this is the intended behavior, the dm driver in the kernel needs to
provide this name (the kernel would need to properly be able to handle
block device renames though, which it can't. So is it not expected to
be the case anytime soon).
Kay
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550152: udev - Remove symlinks
On Sun, Apr 18, 2010 at 23:08, Marco d'Itri wrote: >> On Apr 18, Mario 'BitKoenig' Holbe wrote: >> > KERNEL=="audio", NAME="%k0", SYMLINK+="%k" >> Nowadays this is considered bad, accordingly to the upstream maintainer >> you should not change the kernel name of a device. > > $ grep -rl 'NAME=[^=]' /etc/udev/rules.d /lib/udev/rules.d > /etc/udev/rules.d/70-persistent-net.rules NAME for network devices is fine. They also rename the kernel device. > /etc/udev/rules.d/00-local.rules If this specifies a name different than the kernel device name, it is something that should be fixed. > /lib/udev/rules.d/75-persistent-net-generator.rules NAME for network devices is fine, as mentioned. > /lib/udev/rules.d/55-dm.rules Device-mapper is work-in-progress, and probably just uses NAME="" which is ok. (should still not be done that way, but it does not matter here). > /lib/udev/rules.d/50-udev-default.rules It's probably just for support of older kernels, or for deprecated subsystems drivers like "ieee1394", which need to be replaced by "firewire". There should be no rule that specifies a name that is different from the kernel device name. > Apart from my own rules this seems to be quite a common behaviour. Swapping plain kernel-defined names with symlinks is not supported. It may work, but the behavior is undefined. Recent kernels provide *all* device node names, and with devtmpfs they also manage their creation and deletion. On recent systems, udev is only expected to manage additional symlinks and the permissions of the kernel-created device node. > Well, I think moving device nodes forth and back in the /dev tree is > quite common behavior Upstream udev does not really support this. Kernel device names are defined (and optionally created and deleted) by the kernel these days. Thanks, Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#574270: Functionality overlap between udev's modem-modeswitch and usb-modeswitch about 19d2:2000
On Thu, Mar 18, 2010 at 17:48, Didier 'OdyX' Raboud wrote:
> Hi udev upstreams !
>
> (please keep me and the Debian bug CC'ed).
>
> I am the Debian maintainer for usb-modeswitch and I got a user reporting that
> his 3G dongle was not "switched" anymore [0]. After some investigation, I
> strongly suspect that udev's modem-modeswitch and usb-modeswitch have a
> conflicting functionality overlap.
>
> From /lib/udev/rules.d/61-mobile-action.rules :
>
>> # modem-modeswitch does not work with these devices, the fake CD-ROM needs to
> be ejected
>>
>> # ZTE MF6xx
>> ACTION=="add", ENV{ID_CDROM}=="1", ENV{ID_VENDOR_ID}=="19d2",
> ENV{ID_MODEL_ID}=="2000", RUN+="/usr/bin/eject %k"
>
> From /lib/udev/rules.d/40-usb_modeswitch.rules :
>
>> # ZTE devices
>> ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="2000", RUN+="usb_modeswitch
> '%b/%k'"
>
> It seems (to me) that those lines should be removed from udev (as
> usb-modeswitch
> provides a generic switching facility for more than "just" 19d2:2000.
>
> What is your opinion thereabout ?
If Dan has no objections, we are ready to delete modem-modeswitch from
the udev tree.
Kay
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561279: udev: Crash location and first-level cause
> srv:~# udevadm info > custom logging function 0x160e010 registered > selinux=0 > calling: info > Segmentation fault This was likely caused by using a va_list twice. This is expected to fix it: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=d5a01cb8b31bd0791d1617c56d4c669a02018bd7 Thanks, Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561686: corrections to bugreport on bacula-doc
Im Sorry, i made a mistake. The existing Directory named Techlogs - not Technotes. The rest is correct. Greetings Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561686: bacula-doc: document-subdirs as noted in README did not exist, only Technotes-dir is found.
Package: bacula-doc Version: 1.38.11.1-3 Severity: important after installing the package there is only one subdir named technotes with some content. But the more interesting document-subdirs noted in README are not found. -- System Information: Debian Release: 4.0 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-686 Locale: lang=de...@euro, lc_ctype=de...@euro (charmap=ISO-8859-15) Versions of packages bacula-doc depends on: ii bacula-common 1.38.11-8 Network backup, recovery and verif bacula-doc recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#516374: Info received (Bug#516374: Info received (Bug#516374: Have the same bugs in Debian Lenny with OpenVZ))
Could you please inform about the bug status? Do you need more logs? The bug is very annoying, as it is the backup server with squid and internet doesn't work when system is "in stuck". System stucks approximately 5 times in hour. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
