Re: Next attempt to add Blends to Debian installer
Am 11. Januar 2022 09:24:28 MEZ schrieb Wouter Verhelst : >On Tue, Jan 11, 2022 at 12:51:45AM +, Seth Arnold wrote: >> On Mon, Jan 10, 2022 at 08:02:50PM +0100, Philip Hands wrote: >> > The only missing bit AFAIK is getting the step where tasksel gets >> > installed into the target system, and then run, to be able to grab the >> > version of tasksel to use from an alternative apt repository (which is >> > already being created as part of the salsa-CI pipeline I've got setup), >> >> Is installing tasksel actually necessary? apt understands tasks, eg: >> apt install lamp-server^ >> >> https://shantanugoel.com/2010/10/23/apt-get-caret/ >> https://askubuntu.com/questions/211912/ >> >> I believe this works even if tasksel isn't installed on the target system. > >Yes, but that doesn't give a user a friendly way to select a task. > >If you know the task then yes, that's plenty, but there's more at play here. > Well, entries like "Debian desktop environment" do not have a good explanation in tasksel either. Unless you look at the apt information or the debian wiki, there is not much for the user to find out about it. Gnome is the default of it but still listed separately, adding more confusion. That's at least my experience with it. There could be more guidance for the user in tasksel itself, avoiding the need for a different media to get better information. -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: The Spirit of Free Software, or The Reality
Am 4. Juli 2015 19:40:28 MESZ, schrieb Jan Gloser jan.renra.glo...@gmail.com: This is a very nice philosophy. It has a history though. It also has a name. Communism. And history has shown us that communism on a large scale does not work. I'm afraid you are terribly wrong with that comparison. You sound like an US citizen that, by historical means, brings everything that does not completely value capitalism close to communism. Really strange for the rest of the world. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/7ddd1f7e-dce5-4e48-a7e5-a95150f4f...@hendrik-sattler.de
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Am 18. Juni 2015 03:54:56 MESZ, schrieb Russ Allbery r...@debian.org: Vincent Lefevre vinc...@vinc17.net Shared library symbol versioning makes the problem go away. Package dependencies try to solve the problem at the wrong level. The problem is rather that the package dependency system doesn't look at specific package dependency trees to find conflict between liblow1 and liblow2. Instead it always does this globally. That problem is solvable. But you just but the burden on upstreams again. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/25719340-bf04-4aa0-a69f-38c4c19d5...@hendrik-sattler.de
Re: NDEBUG when building packages?
Mathieu Malaterre ma...@debian.org schrieb: On Sat, Feb 23, 2013 at 11:09 AM, Vincent Cheng vincentc1...@gmail.com wrote: On Sat, Feb 23, 2013 at 1:39 AM, Mathieu Malaterre ma...@debian.org wrote: On Fri, Feb 22, 2013 at 9:52 PM, Russ Allbery r...@debian.org wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: Mathieu Malaterre writes (Re: NDEBUG when building packages?): In that case, this should really be clarified. A lot of debian/cmake packages are actually doing: -DCMAKE_BUILD_TYPE:STRING=Release within there debian/rules files. This settings by default compiles with: `-O3 -DNDEBUG` OMG WTF BBQ Certainly -DNDEBUG should never be used unless upstream explicitly say that it's intended to be supported, and usually not even then. Also, -O3 is generally considered rather iffy. It's not very well-tested and in various versions of GCC it tended to make the code slower, not faster (usually because it unrolled loops too far and blew the CPU cache). It's also had various code generation bugs from time to time. I wouldn't use -O3 without benchmarking of that specific code to confirm that it really improves matters. Seems like everyone agreed. I'll report a bug to lintian package to have it check for this string in d/rules: http://codesearch.debian.net/search?q=DCMAKE_BUILD_TYPE:STRING%3DRelease We should also suggest that packages use -DCMAKE_BUILD_TYPE=RelWithDebInfo instead (-g -O2). In fact, I think that this would be a sensible default for packages using debhelper's cmake integration. Sounds like another wishlist bug for debhelper... cmake from sid makes it even harder. RelWithDebInfo now contains -DNDEBUG ... I have to source-upload all my packages :( $ grep NDEBUG ChangeLog.manual Add -DNDEBUG to RelWithDebInfo flags where where Release flags had it. The solution (backward compat) is now: Either do *not* define CMAKE_BUILD_TYPE, or define CMAKE_BUILD_TYPE to Debug (and hope -DNDEBUG does not creep in ever) 2cts Or just define CMAKE_C_FLAGS properly and don't rely on the default values. It's not that hard, actually. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4965467d-46cf-4b56-979c-480b84403...@email.android.com
Re: NDEBUG when building packages?
Am Samstag, 23. Februar 2013, 16:39:22 schrieb Lisandro Damián Nicanor Pérez Meyer: On Sat 23 Feb 2013 12:33:58 Lisandro Damián Nicanor Pérez Meyer escribió: On Sat 23 Feb 2013 12:18:30 Lisandro Damián Nicanor Pérez Meyer escribió: On Sat 23 Feb 2013 07:09:39 Vincent Cheng escribió: [snip] We should also suggest that packages use -DCMAKE_BUILD_TYPE=RelWithDebInfo instead (-g -O2). In fact, I think that this would be a sensible default for packages using debhelper's cmake integration. Sounds like another wishlist bug for debhelper... IIRC, the cmake integration already does that. Not checked though. It doesn't. Will ask Modestas to see if there is a reaosn for it. Pino pointed me out that RelWithDebInfo is CMake's default. So if CMakeLists.txt doesn't override it, it's there. That's news for everyone using CMake. A simple CMake test shows: [100%] Building C object CMakeFiles/test.dir/test.c.o /usr/bin/gcc-o CMakeFiles/test.dir/test.c.o -c /home/hendrik/tmp/cmake test/test.c So RelWithDebInfo is _NOT_ the default setting. The default setting on Linux is an empty CMAKE_BUILD_TYPE variable. However, combined with automatically evaluated CPPFLAGS/CFLAGS/CXXFLAGS/..., the result may be the same. Also testing in Lintian for the -DCMAKE_BUILD_TYPE=RELEASE is plain wrong, as it may be configured using other -D settings. Not using -DNDEBUG for CFLAGS is new to me, though. === DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) CFLAGS = ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) CFLAGS_RELEASE = -O0 -g -DNDEBUG $(CFLAGS) CFLAGS_DEBUG = -O0 -g $(CFLAGS) else CFLAGS_RELEASE = -O2 -g -DNDEBUG $(CFLAGS) CFLAGS_DEBUG = -O2 -g $(CFLAGS) endif BUILD_TYPE = Release ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS))) BUILD_TYPE = Debug endif BUILD_FLAGS = -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=$(BUILD_TYPE) \ -DCMAKE_C_FLAGS_RELEASE=$(CFLAGS_RELEASE) -DCMAKE_C_FLAGS_DEBUG=$(CFLAGS_DEBUG) \ -DCMAKE_SKIP_RPATH=ON ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) BUILD_FLAGS += -DCMAKE_SYSTEM_NAME=$(shell dpkg-architecture -qDEB_BUILD_ARCH_OS) \ -DCMAKE_SYSTEM_PROCESSOR=$(shell dpkg-architecture -qDEB_BUILD_ARCH_CPU) \ -DCMAKE_C_COMPILER=$(DEB_BUILD_GNU_TYPE)-gcc endif BUILD_FLAGS += -DCMAKE_INSTALL_LIBDIR=lib/$(DEB_HOST_MULTIARCH) === HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201302231741.50338.p...@hendrik-sattler.de
Re: Moving /tmp to tmpfs is fine
Am 2012-05-25 11:19, schrieb Salvo Tomaselli: It's beginning to sound like your particular machines need either more RAM or to use a different temporary location which is on a permanent location. Just add some rules to clean it all up at reboot. Perhaps there are a couple of thousand users with the same use case, I don't know if it is the case but should be investigated rather than discarded. That does NOT mean that Debian should change the default just to suit low memory devices. So let's put minimum requirements unnecessarily high so a few people with super expensive laptops can have a 0.3μs speedup? (And people with cheaper hardware might never find out why the hell linux freezes if they click on a large tar archive). Doing that on inferior hardware is just plain stupid. If you have plenty of disk space, just unpack the tar archive. No. The default is fine and sane but no default will ever satisfy every possible device. Low memory devices have many many more problems than just where /tmp is mounted. But with tmpfs on disk, more devices would work by default (the ones with a lot of memory and disk, and the ones without much memory but with disk space). And those with lots of RAM but not so much disk space (SD card or USB driver or even with no hard drive at all)? There's no solution that works for everyone in all situations. However, tmpfs at least works for many of them. If you KNOW that this default does not fit your use-case, why don't you simply change the configuration? HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/d77602e05a6b6ce8cd0072a717bf8...@mail.hendrik-sattler.de
Re: many packages fail to build twice in a row again
Am Freitag, 23. Dezember 2011, 20:17:13 schrieb Goswin von Brederlow: Lars Wirzenius l...@liw.fi writes: On Fri, Dec 23, 2011 at 10:41:07AM +, Roger Leigh wrote: The suggestion that git clean be a solution appears to have caused some level of outrage. However, at least for '3.0 (git)', all the sources are known to git, and 'git clean' is a reliable and simple solution to the problem. The alternative, manually reverting all the changes, is both complex and error-prone. I'm not sure I see the problem with what is an obvious improvement to the process. I'd favor a solution that avoids having to fix hundres, or thousands, of upstream packages. For example, instead of building directly in the working tree, we could export the sources to a temporary directory and build there. Voila: no build artifacts to clean up at all. That sucks nearly as much as packages that unpack a upstream.tar.gz for every build. It makes editing the source, running make till it works and then building a new package a problem. What can usualy be done quite easily is out-of-tree builds. Pretty much the same effect with less inconvenience. And just as much work, actually. With e.g. autotools, there is a surprising possibility to not be done right by upstream. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201112232303.17622.p...@hendrik-sattler.de
Re: Towards multi-arch: Multi-Arch: same file conflicts
Am Sonntag, 20. November 2011, 19:30:45 schrieb Peter Samuelson: [Goswin von Brederlow] Ugly, but if it works ... You only have those 2 choices for Multi-Arch: same: Split the package or make the files equal. Well, the third choice is to assume nobody _really_ cares about multiarch for JNI libraries, and just drop the Multi-Arch: header. Since you are building the jarfile somewhere in your source you could fix the place where it is created in the first place. But that probably means patching the upstream Makefile. The jar is created with the command 'jar cf $output -C $inputdir org' (where 'org' is the top level of the class name). The 'jar' from gcj-4.6, at least, packs the zip file in 'readdir' order. Using the -@ option with fastjar, you can specify a list of files in a specific order. Sadly, Sun Java jar does not know this option. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20202046.05867.p...@hendrik-sattler.de
Re: /tmp as tmpfs and consequence for imaging software
Am Sonntag, 13. November 2011, 10:02:24 schrieb Salvo Tomaselli: I agree with samuel here. Science software know how to use disk baked file. And are better than general software. I will open rcbug to use /var/tmp instead of /tmp in this case. But it is a pitty. /var/tmp has a little problem: is not cleared upon reboot. In fact one time i couldn't do a graphical login anymore because the kde-stuff in /var/tmp had taken the entire available space on the partitin. Also i was thinking that if we consider the amount of IO that kde does on the home of the user, and the amount that does on /var/tmp, and of course the many libraries that it needs to load, and so on... In the end the activity on /tmp compared to the activity in general is so small that i doubt keeping tmp on the ram is going to have any positive impact at all on performances. Why must it be cleared on boot? What happens with this assumption if the user does not reboot a very long time but only suspend/resume instead? Does your software fail then? Giving your program an option to specify the temp directory is the only real solution. Hardcoding such a thing is a very lazy approach at best. Additionally, add the feature to the program to clean stale files before the next run (or to ask the user if it shall do that). This makes your reboot assumption go away. Your assumptions are bugs the software, not in the system. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131009.24021.p...@hendrik-sattler.de
Re: Bug#645656: network-manager in Gnome
Am Samstag, 5. November 2011, 22:14:15 schrieb Tollef Fog Heen: ]] Hendrik Sattler | Am Freitag, 4. November 2011, 20:55:24 schrieb Tollef Fog Heen: | So since gnome-shell actually needs gnome-bluetooth, the dependency | should be demoted to a Recommends? | | Needs? Why should a desktop _need_ bluetooth? Maybe it uses the gnome-bluetooth DBus APIs unconditionally, for instance? Ever considered this to be a bug? | It's not even common to have bluetooth hardware. Basically all laptops have it, and quite a few desktops does too, so I'll disagree with the «not common» bit. Definitely not basically, no. Maybe looking beyond your own environment helps?: 1. In companies, almost _no_ desktop computer has any wireless technology built- in. May it only be for security reasons (and bluetooth _can_ be a attack vector). Laptops in companies often only have WLAN, sometimes not even that. I know that at least a leading bluez developer got a laptop from his company that has no built-in bluetooth! 2. Lots of non-technical, private computer users cannot make any sense in having bluetooth in their desktop computers as all mobile devices ship with USB cables to sync with (or WLAN directly). Until devices actually start to have bluetooth 3.0+, this USB connection is also much faster. 3. On many private computers that have built-in bluetooth, it is _never_ used and switched off by default in the BIOS. So bluez also does not see it until switched on, something that is never done. I would even guess that the number of computers that are targetted by Gnome and are equipped with switched-on bluetooth hardware is well less below 50% or even much less. And that makes a non-optional choice _very_ questionable. Don't get me wrong: I'm very interested in bluetooth technology, following on the bluez mailing list and being upstream openobex developer. But I also know that the main usage area is NOT the desktop. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20061254.31697.p...@hendrik-sattler.de
Re: Bug#645656: network-manager in Gnome
Am Freitag, 4. November 2011, 20:55:24 schrieb Tollef Fog Heen: So since gnome-shell actually needs gnome-bluetooth, the dependency should be demoted to a Recommends? Needs? Why should a desktop _need_ bluetooth? It's not even common to have bluetooth hardware. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20051705.13400.p...@hendrik-sattler.de
Re: RFC: usb-modeswitch 1.2.0 release embedding jimtcl
Am Dienstag, 18. Oktober 2011, 17:03:02 schrieb Ian Jackson: Timo Juhani Lindfors writes (Re: RFC: usb-modeswitch 1.2.0 release embedding jimtcl): Didier Raboud o...@debian.org writes: Let's also note as context that the goal of this trick (AFAIUI) is to avoid having a tcl interpreter pulled up to first CDs; The modemmanager package that people typically use with USB 3G modems is already in CD#5. Isn't that already a problem ? I mean, if you're using a USB 3G modem for your network connectivity you really want it to be early in the CD set. usb-modeswitch is also useful when using pppd. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201110182044.22264.p...@hendrik-sattler.de
Re: Bug#635661: ITP: libusb-java -- wrapper for C library libusb
Zitat von Steffen Moeller steffen_moel...@gmx.de: Package: wnpp Severity: wishlist Owner: Steffen Moeller steffen_moel...@gmx.de * Package name: libusb-java Version : 0.8ztex20090101 * URL : http://libusbjava.sf.net * License : LGPL Programming Lang: Java Description : wrapper for C library libusb Alioth project pkg-escience will soon host a version. While the original sf version seems to find difficulties with maintainership, this version was updated by the ztex company. Libusb-0.1 only? Do we want that? HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110728091800.11412ccyq8435...@mail.hendrik-sattler.de
Re: Multiarch in Debian unstable
Am Montag, 27. Juni 2011, 16:20:23 schrieb Steve Langasek: So this: So it should be a matter of changing that to print this instead on Debian multiarch: $ gcc -print-multi-os-directory x86_64-linux-gnu $ gcc -print-multi-os-directory -m32 i486-linux-gnu would definitely be wrong, because neither /usr/lib/x86_64-linux-gnu/x86_64-linux-gnu nor /usr/lib/x86_64-linux-gnu/i486-linux-gnu will exist. Correct would be '.' and '../i486-linux-gnu', but that's of little help if one doesn't know what it's relative to in the first place! Then make it ../x86_64-linux-gnu instead of . That will always work for all subdirectories of /usr/lib, no? One question, though: How are build tools like CMake converted to use Multiarch directories for the installation rule? HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201106280740.03845.p...@hendrik-sattler.de
Re: Multiarch in Debian unstable
Zitat von Steve Langasek vor...@debian.org: One question, though: How are build tools like CMake converted to use Multiarch directories for the installation rule? I don't have a generic recipe for converting cmake to install to the multiarch directory. If someone has one, please add it to http://wiki.debian.org/Multiarch/Implementation. Maybe a patch to http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/GNUInstallDirs.cmake can be provided? Then, projects that use CMake and include this module automatically get support for multiarch. Those that don't probably need Debian-specific patches(*) or the debian/rules script handles it somehow itself. HS (*) Question: are other distributions going to follow the Debian multiarch scheme? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110628124704.9692660f6iqgc...@mail.hendrik-sattler.de
Re: Bug#627038: ITP: libacsccid -- PC/SC driver for ACS USB CCID smart card readers
Hi, Zitat von Godfrey Chung godfrey.ch...@acs.com.hk: Yes, libccid works for a few models only while libacsccid works for all models of ACS CCID smart card readers. You can download the drivers from http://www.acs.com.hk/index.php?pid=drivers. For example, select ACR122U (http://www.acs.com.hk/index.php?pid=driversid=ACR122U) and you will find the driver (http://www.acs.com.hk/drivers/eng/ACR122U_driver_Lnx_Mac10.5_10.6_1.02_P.zip). The driver acsccid-1.0.2.tar.bz2 is in the zip file. I am a maintainer of the driver. acsccid-1.0.2 is based on ccid-1.3.11 and supports all models of ACS CCID smart card readers. The driver is tested by software and hardware engineers from ACS. I figured from your mail address that ACS is directly involved here. OTOH, why are those changes not pushed to libccid upstream? For generic protocols like CCID (where even Windows has a generic driver for it), there should not be a driver set for each vendor, it simply defeats the purpose of generic protocols like that. Your example of ACR122U is marked as should work at http://pcsclite.alioth.debian.org/ccid/iManufacturer.html#2 If the libccid upstream is not cooperative for including your changes (if it's done in a clean way), maybe you can work with the Debian libccid maintainer? HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110518094650.47921ux2i5xma...@v1539.ncsrv.de
Re: Bug#627038: ITP: libacsccid -- PC/SC driver for ACS USB CCID smart card readers
Zitat von Godfrey Chung godfrey.ch...@acs.com.hk: Before we started the driver project in 2009, we had requested to join as a developer for libccid in alioth.debian.org but the author rejected us with no reason. As the same time, our customer pushed us to release Linux driver. Therefore, we decided to release our Linux driver based on libccid and had a plan to release our driver to any Linux Distributions. But libccid evolves and forks of such projects do usually not follow. This leaves both in a rather sad situation. Did you track the changes of 1.3.12 and 1.3.13? Any intention to rebase the work on 1.4.x so libusb-1.0 gets used instead of libusb-0.1? For the Windows platform, we also release our own driver. It is because the generic driver does not work with multi-slot smart card readers and we can control our driver source code to fix bugs from the readers. The Windows driver is also not very standard-compliant and does nasty things. It took me 30min on XP and Vista to get a bluescreen from it :-/ Note that there is also libusb-win32, making it potentially possible to use the same source there (ignoring the Microsoft driver for it) once it is compatible with (or integrated into) libusb-1.0. Please note that libccid upstream author and Debian maintainer are same person. He may reject our changes. Let's CC him so that he can comment... HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110518104806.17831ti5w4pzq...@v1539.ncsrv.de
Re: Bug#627038: ITP: libacsccid -- PC/SC driver for ACS USB CCID smart card readers
Zitat von Godfrey Chung godfrey.ch...@acs.com.hk: Package: wnpp Severity: wishlist Owner: Godfrey Chung godfrey.ch...@acs.com.hk * Package name: libacsccid Version : 1.0.2 Upstream Author : Advanced Card Systems Ltd. i...@acs.com.hk * URL : http://www.acs.com.hk/ * License : LGPL-2.1 Programming Lang: C Description : PC/SC driver for ACS USB CCID smart card readers This library provides a PC/SC IFD handler implementation for the ACS USB smart card readers compliant to the CCID protocol. This package is needed to communicate with the ACS CCID smartcard readers through the PC/SC Lite resource manager (pcscd). Does libccid not work for your reader? If it doesn't, maybe reword the description about the differences to libccid (which should support CCID compliant devices). The URL above only links to the main page of the vendor. Can it be a bit more specific (the URL where you got the source from)? HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110517120941.20100vn51cac8...@v1539.ncsrv.de
Re: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy)
Zitat von Stanislav Maslovski stanislav.maslov...@gmail.com: On Wed, Apr 06, 2011 at 10:51:08PM +0200, Hendrik Sattler wrote: Am Mittwoch 06 April 2011, 19:05:11 schrieb Stanislav Maslovski: On Wed, Apr 06, 2011 at 07:29:05AM +0200, Josselin Mouette wrote: Then you can stack all soft of stuff on top of it, and get them to work manually for your specific setup, and since it’s not event-based you have to hard-code the way your network is set up. ^^ The underlined claims, btw, are also false. You made clear that you think of yourself as the ultimate master of ifupdown. So what? That tells us _nothing_ about the rest of the world... First of all, that is only your interpretation which is wrong. Second, there is no point in turning a discussion about ifupdown vs. NM into a discussion of my abilities/disabilities. I am also not totally happy about network-manager but I still use it as it gives me a working wireless network on my laptop without having to spend hours reading endless documentation and writing multiple configuration files (hey, just for the purpose of getting _one_ network device running at two different locations!). Been there, done that for quite some time, with wired and wireless networking, analog/2G/3G modem and ISDN dialup. It was always a pain to setup and working if not too much goes wrong. Still I was switching to network-manager once available as for me it's not painless but much less pain. I remember one difficult case: my university was using cisco equipment to do the VPN. So I used vpnc to connect. How do you tell ifupdown to only start vpnc once wpa_supplicant made the connection to a specific network? Additionally, they used a different SSID for each AP, so no roaming but manual selection. That was a nightmare to setup as you had to have one entry for each AP! Additionally, wpa_supplicant was only working when the interface was not down, I had to manually figure that out to add a proper pre-up entry line. Yummy. I currently use ifupdown only for a 3G connection but only because the integration of plasma-widget-networkmanagement with network-manager's use of modemmanager is not working (already solved upstream according to the developers blog but not in Debian). So I am using pon/poff for that. However, the example gprs chat script for PIN entry is not correct (not even according to the applicable standard and my modem happens to take that part very strictly). I am currently using another solution to correctly enter the PIN code (a program that I wrote years ago happens to do that). Believe it or not but modemmanager would have been my preferred solution. No, I didn't file a bug about that, not until I found a working solution for that chat script. The network-manager solution still suffers from lots of bugs e.g. the KDE applet not being able to reconnect to network-manager after an upgrade of the latter, or a capable CLI solution (cnetworkmanager cannot do everything, nothing useful is shipped with network-manager). I am with you that ifupdown should always be available as fallback but it's not _my_ preferred solution for a desktop. It's ok that some like to read hundreds of lines to setup something that should be a no-brainer, I don't. For a server, ifupdown is preferrable but there, even a simple shell script would always be sufficient! HS PS: You are missing one important thing from your wpa-roam snippets: you really should restrict each SSID entry to the MAC address of the AP. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110407125633.140870takqbbd...@v1539.ncsrv.de
Re: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy)
Am Mittwoch 06 April 2011, 19:05:11 schrieb Stanislav Maslovski: On Wed, Apr 06, 2011 at 07:29:05AM +0200, Josselin Mouette wrote: Then you can stack all soft of stuff on top of it, and get them to work manually for your specific setup, and since it’s not event-based you have to hard-code the way your network is set up. ^^ The underlined claims, btw, are also false. You made clear that you think of yourself as the ultimate master of ifupdown. So what? That tells us _nothing_ about the rest of the world... HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201104062251.08798.p...@hendrik-sattler.de
Re: MBF alert: packages with very long source / .deb filenames
Am Freitag 25 März 2011, 21:59:31 schrieb Rene Engelhard: Hi, On Fri, Mar 25, 2011 at 09:48:15PM +0100, Adam Borowski wrote: On Fri, Mar 25, 2011 at 05:09:54PM +0100, Rene Engelhard wrote: Hi, On Fri, Mar 25, 2011 at 03:27:57PM +, Steve McIntyre wrote: The longest is: libreoffice-presentation-minimizer_1.0.3+LibO3.3.1-1_kfreebsd-amd64.d eb at 71. Good, then any bug against openoffice.org is not needed, as that obviously will be + wontfix wheezy-ignore, because it simply can't be fixed as we need the transitional packages :) It still can have a version number much shorter than 1.0.3+LibO3.3.1-1. And there's no package out of openoffice.org which has that style of version. And no, it cannot have a shorter version in libreoffice (e.g. you simply can't remov the +LibO3.3.1-1 unless you get problems in versioning as the version before the + doesn't necessarily change between releases) At least the LibO can be dropped. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201103261453.10548.p...@hendrik-sattler.de
Re: maintainer ignores bug
Am Samstag 26 Februar 2011, 18:50:41 schrieb Osamu Aoki: It looks like its an issue with your choice of .gtkrc files. I really do not recommend the setting in KDE to influence the themes of GTK programs. For me, it makes iceweasel using 100% _after_ closing it. It drove me almost nuts on my laptop until I found the cause. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201102261950.09670.p...@hendrik-sattler.de
Re: The future of m-a and dkms
Zitat von Patrick Matthäi pmatth...@debian.org:
I know that right now, when backporting stuff at work, we have to drop
the DKMS stuff and write our own packaging since DKMS doesn't play
nicely with multiple kernel versions, embedding the kernel *and* package
version in the final module version, etc. Things might have changed
recently, but last time I looked DKMS was only good for desktops, and
not as a reliable package-building method.
Of course, I might have wrong information, so clarifications welcome.
I think the disadvantage of dkms is, that apt will fail, if the module
couldn't be built for one of the n installed kernel versions, because
the module is not compatible {anymore} with the kernel version.
This process could be enhanced, by dropping an notify to the user, that
module x failed to buit on kernel version y and you might found more
information at z. But you have got the same problems with m-a, just
you don't have to execute m-a by yourself.
Personally, this is the _main_ problem of DKMS. I am using e.g.
virtualbox-ose but not often. I actually rather use m-a -t a-i
virtualbox-ose than dkms because I do compile my own kernels that the
virtualbox-ose modules often fail to compile with. I really do not
want an aborted upgrade module or kernel upgrade because of that!
DKMS should be configurable upon installation when to enable automatic
compilation of modules, meaning making automatic compilation totally
optional (without having to manually remove most of the files from the
package). It could even ship a m-a wrapper, doesn't it? (maybe only
for the commonly used functionality).
Also, the idea of having files derived directly from distribution
packages in /lib/modules/foo not visible to any standard package
frontend seems strange and a bit like a step backwards. It's like
having to install a package with pear because horde upgrade scripts
once again requires a module that is not packaged in Debian (which was
the case for Lenny and is also the case for Squeeze :-( ). Can those
tools be integrated with e.g. aptitude?
HS
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110214082938.6380382k10tcm...@v1539.ncsrv.de
Re: Safe file update library ready (sort of)
Zitat von Goswin von Brederlow goswin-...@web.de:
Adam Borowski kilob...@angband.pl writes:
On Wed, Jan 26, 2011 at 12:03:52PM +0100, Goswin von Brederlow wrote:
Shachar Shemesh shac...@debian.org writes:
I've promised to get a library out there, and here it is. The base URL
is https://github.com/Shachar/safewrite, and the actual code is at
https://github.com/Shachar/safewrite/blob/master/safewrite.c
Some things I noticed:
That way one could use
[..]
typedef struct {
int fd;
char buffer[PATH_MAX];
} safe_t;
Except, you can't rely on PATH_MAX on any modern system. It's defined in
Linux headers to an arbitrary value to make old code compile, but for
example Hurd folks decided to not define it altogether to make buggy code
fail during compilation rather than on runtime.
Right, so
typedef struct {
int fd;
char buffer[0];
} safe_t;
and allocating the struct as big as needed.
Maybe don't recommend invalid C? Bad habits don't have to live on forever...
HS
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110126153957.18702pqz49ugq...@v1539.ncsrv.de
Re: Safe file update library ready (sort of)
Zitat von Goswin von Brederlow goswin-...@web.de:
Hendrik Sattler p...@hendrik-sattler.de writes:
Zitat von Goswin von Brederlow goswin-...@web.de:
Adam Borowski kilob...@angband.pl writes:
On Wed, Jan 26, 2011 at 12:03:52PM +0100, Goswin von Brederlow wrote:
Shachar Shemesh shac...@debian.org writes:
I've promised to get a library out there, and here it is. The base URL
is https://github.com/Shachar/safewrite, and the actual code is at
https://github.com/Shachar/safewrite/blob/master/safewrite.c
Some things I noticed:
That way one could use
[..]
typedef struct {
int fd;
char buffer[PATH_MAX];
} safe_t;
Except, you can't rely on PATH_MAX on any modern system. It's defined in
Linux headers to an arbitrary value to make old code compile, but for
example Hurd folks decided to not define it altogether to make buggy code
fail during compilation rather than on runtime.
Right, so
typedef struct {
int fd;
char buffer[0];
} safe_t;
and allocating the struct as big as needed.
Maybe don't recommend invalid C? Bad habits don't have to live on forever...
HS
Would you use
typedef struct {
int fd;
char buffer[];
} safe_t;
or what do you mean by invalid C?
char buffer[0]; is veeery gcc-specific as the storage size of buffer
is 0. According to the C99 standard:
6.7.5.2 Array declarators
Constraints
1 In addition to optional type qualifiers and the keyword static, the [ and
] may delimit an expression or *. If they delimit an expression (which
specifies the size of an array), the expression shall have an integer type.
If the expression is a constant expression, it shall have a value greater
than zero.
Either make this char buffer[1]; and live with the fact that e.g.
cppcheck will yell at you (better not), or use safe_t x= ...; char
*buffer = x + 1; with or without explicit reference in safe_t (if you
want to allocate in one block) or simply allocate it seperately.
BTW: KDE4 is a very good example for failure with modern filesystems.
I regularly loose configuration files when suspend-to-ram fails even
if the configuration of the running programs were not changed. Yay :-(
And this is with XFS, not Ext4! Filed a bug a looong time ago in
KDE BTS. Reaction: none!
HS
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110126173619.185277zxg7ixv...@v1539.ncsrv.de
Re: Safe file update library ready (sort of)
Zitat von Olaf van der Spek olafvds...@gmail.com: On Wed, Jan 26, 2011 at 5:36 PM, Hendrik Sattler p...@hendrik-sattler.de wrote: BTW: KDE4 is a very good example for failure with modern filesystems. I regularly loose configuration files when suspend-to-ram fails even if the configuration of the running programs were not changed. Yay :-( And this is with XFS, not Ext4! Filed a bug a looong time ago in KDE BTS. Reaction: none! Maybe complain to the Linux kernel people instead. suspend-to-ram fails is the same situation as a sudden power loss. In this case, it's not a kernel bug. I don't know how KDE4 handles its configuration files but something is wrong there when I loose config data without changing any settings in this scenario... HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110126192542.91195o63nouch...@v1539.ncsrv.de
Re: Trying to install Oracle9i R2 on
Zitat von Bob Proulx b...@proulx.com: Arturo Gutierrez wrote: /oracle/tmp/OraInstall2011-01-17_02-30-24PM/jre/bin/i386/native_threads/java: error while loading shared libraries: libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file or directory Fortunately this library is still available in the archive. http://archive.debian.net/en/woody/i386/libstdc++2.9-glibc2.1 He could also replace the shipped jre/ directory with a symlink to the system's JRE installation. Or does Oracle only work with the shipped java? (That would be even more sick.) That Oracle ships something that relies on an ancient compiler (and then not even ships all necessary parts) is beyond comparison :-( HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110118084834.16945pp5uu6ev...@v1539.ncsrv.de
Re: Forwarding bugs upstream
Zitat von Ansgar Burchardt ans...@debian.org: Sune Vuorela nos...@vuorela.dk writes: Currently, the debian Qt/KDE team has around 800 open, non-forwarded bugs reported against their packages. I would guess that maybe 20 of them is packaging issues. But we can't find them. The rest of the bugs (780 open-non forwarded (and 300 forwarded)) is pure upstream issues. Ubuntu has a team (Bug Squad[1]) that tries to triage incoming bug reports, including forwarding them upstream when applicable. I don't know how successful this is, but if it has success, then maybe we could try to recruit volunteers for a similar team in Debian as well? This should of course include mentoring them a bit as well. I've some bug reports for Ubuntu for my software that are _clearly_ not related to it. It just happens to match the key words in its name. So I don't think that I would call it successful :-/ HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110113153311.42747ifnb156j...@v1539.ncsrv.de
Re: Problem with gfortran and pkg-config
Am Donnerstag 29 Juli 2010, 19:23:40 schrieb Tollef Fog Heen: The reason for stripping -Iany standard include path is so you can have in-tree include files that get included correctly even if their names overlap the files in /usr/include. This is not the case with current gcc. From man gcc: Directories named by -I are searched before the standard system include directories. If the directory dir is a standard system include directory, the option is ignored to ensure that the default search order for system directories and the special treatment of system headers are not defeated. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007292151.08100.p...@hendrik-sattler.de
Re: UPG and the default umask
Am Dienstag 18 Mai 2010, 12:49:08 schrieb Christoph Anton Mitterer: If you are not allowed to use ACLs That's no reason for UPGs to exist, is it? All important filesystems support ACLs, right? All kernels in Debian and do so, right? So technically, no problem. So being not allowed probably means organisational issues, right? But then talk to your admins. What's done here is to abuse a system just to workaround something else (don't have/want to ACLs), right? Do e.g. backup system deal well with ACLs? The standard tar doesn't, except when you script around it... or if you use star. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201005181738.07833.p...@hendrik-sattler.de
Re: Confused by .la file removal vs static linking support
Zitat von Josselin Mouette j...@debian.org: Le mardi 04 mai 2010 à 10:31 +0200, Emilio Pozuelo Monfort a écrit : Sorry I don't know what you're talking about. If you can explain it I'll try to look at the problem. It’s not a problem, it’s a disagreement over a design choice. When you do that: #include gtk/gtk.h you’re able to use gtk_* functions, but also g_* and pango_* functions, because the headers are designed so. Therefore, when you link to GTK+, you need to link explicitly to Pango and GLib. This is why Pango and GLib are in the Requires field for gtk+-2.0.pc, and not in Requires.private. Only when you use symbols from Pango or Glib directly. Having prototypes through gtk/gtk.h is not relevant. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100505104724.ey9r4irge84oo...@v1539.ncsrv.de
Re: PDF is blocked for printing, etc. OK for acroread (it behaves as expected), but KPDF allows me to print it, even if it is protected! Why?
Zitat von Jay Berkenbilt q...@debian.org: Merciadri Luca luca.mercia...@student.ulg.ac.be wrote: Sjoerd Hardeman wrote: Pdf anti-features are fake security. Don't trust on them, never. And what do you suggest if one wants some real protection _and_ the benefits of a format like PDF? Thanks. The PDF specification itself recommends using external encryption in this case. From section 7.6.1 of the PDF specification: NOTE: Conforming writers have two choices if the encryption methods and syntax provided by PDF are not sufficient for their needs: they can provide an alternate security handler or they can encrypt whole PDF documents themselves, not making use of PDF security. It is very easy to defeat PDF security in any file that has a blank user password since it is just up to the application to enforce security. I've written a detailed explanation of this which I can dig up and send you if you're interested. How could encryption make it possible to view it but prevent printing it? HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100420073908.6mqfjhea88k80...@v1539.ncsrv.de
Re: Default value of net.ipv6.bindv6only should revert to 0
Zitat von Russ Allbery r...@debian.org: Hendrik Sattler p...@hendrik-sattler.de writes: It's a trade-off with a different goal in mind. So what. Both settings of bindv6only are if you cannot assume standard behaviour. Maybe we should patch this option _out_ of the linux kernel to get rid of the assumption that the default may be changed. It's not an assumption. It's reality that one has to write code against, because different platforms do different things. Even if you could remove the option from the Linux kernel (retroactively, changing time to remove all the systems that already exist), that doesn't change the fact that Solaris and BSD behave differently. But that was not the reason why the default was changed for _linux_ in Debian. Since when do we need to adapt non-standard Solaris and BSD behaviour? Read about IPV6_ADDRFORM in ipv6(7). Use it. Change back to the default and forget about this discussion how hard it is to convert addresses to AF_INET style, so ACLs do match. Enjoy life :) This doesn't have much to do anything to do with the conversation that we're having, though. Once you're modifying the application, there's a bunch of things that you can do to address this problem in different ways. The question that we're debating is what the default should be for applications that are not expressing an explicit preference. You forgot to cite yourself! This was an answer to your BTW question. It was proposed to fix programs that may not work with bindv6only=1. This is correct. But it was also noted that the change was done to have less problems with some other applications (ACLs, etc.). If you need AF_INET addresses to make e.g. your ACLs to work correctly, the above socket option _is_ a solution. An easy solution. You need to patch those programs then? So what! That's exactly what you request from others. What again was the list of reasons to change the default value of bindv6lonly from 0 to 1? I have not seen any good reasons so far. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100413090739.p0jr7lt2as40g...@v1539.ncsrv.de
Re: Default value of net.ipv6.bindv6only should revert to 0
Am Dienstag 13 April 2010 20:11:34 schrieb Russ Allbery: Or are you saying that inetd implementations use IPV6_ADDRFORM before running the underlying program? (All of the ones in Debian?) If so, there's some missing connecting of the dots in your reply. I guess not all of them. OTOH, not all of them might use AF_INET6 sockets for IPv4 connections (the two-sockets approach is always possible when using IPV6_V6ONLY socket option). At least xinetd uses IPV6_ADDRFORM although that socket option is already deprecated again but still useful for such cases. openbsd-inetd explicitely doesn't support IPv4-mapped addresses, configuration needs seperate IPv4 and IPv6 setup. I didn't look at the other two. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004140714.37690.p...@hendrik-sattler.de
Re: Default value of net.ipv6.bindv6only should revert to 0
Am Montag 12 April 2010 18:19:08 schrieb Marco d'Itri: On Apr 12, Salvo Tomaselli tipos...@tiscali.it wrote: If a kernel without IPv6 support is used then e.g. an ACL will contain plain IPv4 addresses as expected, but when a kernel with IPv6 support is installed in your scenario then that ACL will not work anymore (without special code) because now the IPv4 addresses would need to be converted to v6-mapped addresses. 1 - In a kernel without IPv6 support, trying to accept IPv6 connections will simply fail, so for the server program to work without it, it is safe to You keep missing the point. Let me try with shorter sentences, if you still do not get it maybe I can try a puppets show. Root configures daemon on IPv4-only system. Daemon can only bind to 0.0.0.0. So it opens an AF_INET socket because using an AF_INET6 would fail. Configuration works. IPv6 is enabled. Daemon now can bind to ::. No, AF_INET socket cannot bind to ::, only AF_INET6 sockets can. So you assume a program to try AF_INET6 first, then additionally AF_INET. Daemon accepts IPv4 connection on the IPv6 socket. Configuration broken. So you try to fix some broken programs but asking other programs that assume the documented default to be fixed, instead? That really makes sense :-/ A socket option must be used for those programs that may fail with the default of bindv6only=1 because they use both AF_INET6 and AF_INET for the same port. However, your example above then just fails for the opposite case of bindv6only=0 and can by using the socket option correctly. Why exactly makes that bindv6only=1 a good choice? HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004121951.08997.p...@hendrik-sattler.de
Re: Default value of net.ipv6.bindv6only should revert to 0
Am Montag 12 April 2010 23:25:16 schrieb Russ Allbery: Adam Borowski kilob...@angband.pl writes: Instead of listening on a single socket, you need to change every single daemon to include a select() loop. That's explicitely allowed by all relevant RFCs and by POSIX, so breaking that is quite a regression. Yeah, I understand why POSIX made the choice that they did. I just think it's a bad tradeoff. It's a trade-off with a different goal in mind. So what. Both settings of bindv6only are if you cannot assume standard behaviour. Maybe we should patch this option _out_ of the linux kernel to get rid of the assumption that the default may be changed. BTW, I've not tried this myself: does someone know what happens if a daemon called from an inetd equivalent calls getpeername() on a socket bound by an IPv6-aware inetd using mapped addresses? For IPv4 connections, does it get back an IPv4 address or an IPv6 mapped address? Do the inetd implementations currently in Debian separately bind IPv4 and IPv6 sockets, or do they use mapped addresses? Read about IPV6_ADDRFORM in ipv6(7). Use it. Change back to the default and forget about this discussion how hard it is to convert addresses to AF_INET style, so ACLs do match. Enjoy life :) HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004130724.18975.p...@hendrik-sattler.de
Re: Default value of net.ipv6.bindv6only should revert to 0
Am Freitag 09 April 2010 18:29:40 schrieb Marco d'Itri: They will have an opportunity to develop more portable software. Actually not. They'll just assume that binding the port first for IPv4, then for IPv6 will work. Eventually, they'll be surprised that it fails elsewhere (notably those that stick to the _documented_ default value). As already noted, there are already systems with another default but with a specific reason for such a choice. I don't see such a reason for Debian (a bug in kfreebsd isn't one). HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004092004.02096.p...@hendrik-sattler.de
Re: Default value of net.ipv6.bindv6only should revert to 0
Zitat von Salvo Tomaselli tipos...@tiscali.it: On Thursday 08 April 2010 11:05:30 Stephane Bortzmeyer wrote: On Wed, Apr 07, 2010 at 08:20:37AM +0200, Vincent Danjean vdanjean...@free.fr wrote a message of 63 lines which said: I've no strong opinion about the default value for net.ipv6.bindv6only. However, I think that any application that breaks if the default value is 0 or 1 is broken and a bug must be filled.. You mean that applications should use the option IPV6_V6ONLY of RFC 3493, section 5.3, therefore not depending on the system-wide value? Could be hard to convince the developers to do so, and in my opinion distribution-specific patches should be used only when necessary, not as a normal way to proceed. Unfortunately i don't have access to the POSIX specification, but the opengroup says that by default bindv6only is 0. http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_10_20_02 So basically the developers will assume this value and will probably reject bugreports claiming that the assumption is wrong. OTOH, it defaults to 1 in Windows Vista/7, probably as compatibility to XP which didn't have a dual-IP stack. The text from the opengroup is directly derived from the RFC which had a transition for IPv4 applications in mind (you don't need to work with two sockets, then). I also don't really see the issues with bindv6only=0. If you listen on all interfaces, it makes is easier. If you only listen on specific interfaces, it's not in the way. Just let any application which cannot cope with it install another file in /etc that sets it back to 0. Let's have a configuration file war :-( HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100408120926.jmdmfqpthc0w8...@v1539.ncsrv.de
Re: Default value of net.ipv6.bindv6only should revert to 0
Zitat von Salvo Tomaselli tipos...@tiscali.it: OTOH, it defaults to 1 in Windows Vista/7, probably as compatibility to XP which didn't have a dual-IP stack. I don't think we should care about what windows does, there can't be compatibility anyway. I also don't really see the issues with bindv6only=0. If you listen on all interfaces, it makes is easier. If you only listen on specific interfaces, it's not in the way. The problem is that freebsd has bindv6only=1 by default, but i personally think it is a bug in the kernel. We are discussing this for linux, not freebsd, don't we? Just let any application which cannot cope with it install another file in /etc that sets it back to 0. Let's have a configuration file war :-( Apparently rewriting configuration of other packages is against the policy. You can use another file that is parsed after the problematic setting. How can this be a policy issue? If one package maintainer can decide to set this to 1 by default, another one can decide to set it back to 0. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100408123836.l321vo6v44gok...@v1539.ncsrv.de
Re: German Debian (was: Processed: ipv6 release goal)
Zitat von Marc Haber mh+debian-de...@zugschlus.de: On Wed, 24 Mar 2010 20:23:31 +0800, Paul Wise p...@debian.org wrote: On Wed, Mar 24, 2010 at 8:06 PM, Marc Haber mh+debian-de...@zugschlus.de wrote: Most web pages are much better translated to German than Debian's are. Unfortunately, Debian is broken beyond repair in regard to German language support. All of Debian or just the website? Unfortunately, all of Debian. Translating technical texts from English to German is controversial at its best, and the Debian translators have taken my least favorite approach of eliminating all English, leading to barbarities like SMTP-Sendezentrale or Sicherheitsgutachten. Debian's German translations feel to me (a native speaker of German) as babelfished from English. I used to take a look at Debian's translations of my own package's Debconf templates, but nowadays I just treat them as just another language that I don't speak. This approach saves me a lot of grief. Greetings Marc, who has preferred language DE as well and cringes whenever a Debian page comes up and would really love to see those in English Sounds like Debian has QA issues wrt the website translations. I assume that you reported that to the German website l10n folks, debian-i18n and debian-www? They are resistant to advice and think their way is the correct way. They work with a word list, so it must be correct. Directly from www.debian.org (english, then German, then translated back): it comes with over 25000 packages, precompiled software bundled up in a nice format for easy installation on your machine. - Es enthält mehr als 25000 Softwarepakete, vorkompilierte Software in einfach zu installierenden Paketen. - It contains more than 25000 software packages, precompiled software in easily installable packages. From a good translation, I'd expect that the reverse is the original text in some form. Additionally, the translations often sound too formal to a native speaker: Debian ist ein freies Betriebssystem (OS) für Ihren Rechner. Although Ihren is the formal translation of your (which has a formal and a non-formal translation in German), capitalizing that word is very formal (e.g. used in directly addressed letters). To avoid that, it is way more common to not address the reader directly. That may be totally different in english. Sometimes, they don't translate some words, e.g. in Das neueste stabile Release von Debian ist 5.0. with a different wording under the link in the same paragraph (Release - Veröffentlichung). And that wasn't even the half of the front page! I usually don't care enough (nobody can translate stuff in a way that all agree). The reason for asking for the language of the web page was my preference to stay with a language: a reference to an english page on an english mailing list. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100324163849.s0urlqu5i8c0g...@v1539.ncsrv.de
Re: German Debian (was: Processed: ipv6 release goal)
Am Mittwoch 24 März 2010 19:58:41 schrieb Thomas Weber: On Wed, Mar 24, 2010 at 04:38:49PM +0100, Hendrik Sattler wrote: Zitat von Marc Haber mh+debian-de...@zugschlus.de: Directly from www.debian.org (english, then German, then translated back): it comes with over 25000 packages, precompiled software bundled up in a nice format for easy installation on your machine. - Es enthält mehr als 25000 Softwarepakete, vorkompilierte Software in einfach zu installierenden Paketen. - It contains more than 25000 software packages, precompiled software in easily installable packages. From a good translation, I'd expect that the reverse is the original text in some form. That is an unfounded expectation. It's a well known effect that translations tend to be more explicit than the original text. _in_some_form_ - roughly means the same which is not the case here. The example above simply is not a good translation. Im selben Satz Pakete und Software zu wiederholen, klingt auch nicht sonderlich gut. Additionally, the translations often sound too formal to a native speaker: Debian ist ein freies Betriebssystem (OS) für Ihren Rechner. Although Ihren is the formal translation of your (which has a formal and a non-formal translation in German), capitalizing that word is very formal (e.g. used in directly addressed letters). To avoid that, it is way more common to not address the reader directly. $ lynx --dump http://www.duden.de/firmenloesungen/index.php?nid=15 | grep Ihren That page adresses companies in a formal matter. The debian front page doesn't do that or not in any obvious way. For non-german readers: the 'Duden' is usually considered to be *the* reference for spelling in Germany. A reference for spelling, not more. But ignoring that, how do you avoid addressing the reader when translating the snippet for your computer and at the same time keep your expectation above that the reverse translation should come really close to the original text? I don't know the english translation for klingt irgendwie steif. If you don't address the reader in the translation, there's no way to get the 'addressing' back in the reverse translation, is there? And these are exactly the kind of problems translators have. I know those problems, although not for Debian. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003242129.47834.p...@hendrik-sattler.de
Re: Processed: ipv6 release goal
Zitat von Ben Hutchings b...@decadent.org.uk: ipv6 This bug affects support for Internet Protocol version 6. This is *not* the same as the release goal, which is about fixing networking programs that don't support IPv6 at all. Many of these bugs should not be release-critical. Context? Can you make your post a bit less brief? Where does the citation comes from? HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100323093559.6gqgmi314wscc...@v1539.ncsrv.de
Re: Processed: ipv6 release goal
Zitat von Felipe Augusto van de Wiel (faw) f...@funlabs.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23-03-2010 05:35, Hendrik Sattler wrote: Zitat von Ben Hutchings b...@decadent.org.uk: ipv6 This bug affects support for Internet Protocol version 6. This is *not* the same as the release goal, which is about fixing networking programs that don't support IPv6 at all. Many of these bugs should not be release-critical. Context? As pointed by Colin: | Ben is replying to a BTS notification that many of these bugs were | upgraded to severity 'serious' by Clint Adams. Thanks. Can you make your post a bit less brief? Where does the citation comes from? http://www.debian.org/Bugs/Developer#tags BTW: How can I force that page to _not_ use the preferred language of the browser? Having to change that in the firefox/iceweasel settings every time is a bit... weird. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100323133351.ldsshmdvs404g...@v1539.ncsrv.de
Re: Processed: ipv6 release goal
Zitat von Hendrik Sattler p...@hendrik-sattler.de: http://www.debian.org/Bugs/Developer#tags BTW: How can I force that page to _not_ use the preferred language of the browser? Having to change that in the firefox/iceweasel settings every time is a bit... weird. Ups. Should have scrolled all the way down :-/ HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100323135635.5ac1y3iigwkgo...@v1539.ncsrv.de
Re: Processed: ipv6 release goal
Zitat von Paul Wise p...@debian.org: On Tue, Mar 23, 2010 at 8:33 PM, Hendrik Sattler p...@hendrik-sattler.de wrote: BTW: How can I force that page to _not_ use the preferred language of the browser? Having to change that in the firefox/iceweasel settings every time is a bit... weird. That is a feature, not a bug. Why is your preferred language set incorrectly in the first place? Unfortunately respecting the Accept-Language HTTP header is less and less common for web applications these days, mapping IP addresses to languages through GeoIP is more common and extremely annoying. Actually, it is (set to German). However, I do not always want to see a translated page. Nothing that any solution can get right (as for a computer, the choice is rather random), be it content negotiation or geoip. Already found it anyway :) HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100323151457.2l7dztujy8scs...@v1539.ncsrv.de
Re: Relying on glib to publish gettext linker flags
Zitat von Daniel Macks dma...@netspace.org:
Coming here for wider input from gnome bugzilla Bug #606977 (and now
I'm rethinking the much older Bug #500137), which seems to center on
the line in glib-2.0.pc.in:
Libs: -L${libdir} -lglib-2.0 @INTLLIBS@
[...]
This is a real issue for me on OS X, since gettext is not in my system
lib itself nor is the external lib supplied by my os vendor. So I have
several third-party-supplied versions and copies of it and also my
user-land for testing. It's also not sufficient to have glib link
against libintl and then other packages just link against glib.
Darwin's linker does not allow indirect symbol references. I really
need clean control over how/when/where gettext gets linked.
How about putting it into Libs.private?
This should solve your MacOS X problem and also works for static linking.
HS
PS: when referencing bugs from other BTS, please use a link, not just
a bug number.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: multiarch and pkg-config
Am Freitag 05 Februar 2010 09:04:45 schrieb Tollef Fog Heen: | #get the location of the .pc file | PC_NONOPTS=`echo $@ | sed -e 's/\(--[^ ]* \)*//g'` | PC_FILEDIR=`pkg-config --variable=pcfiledir $PC_NONOPTS` | PC_RESULT=$? | test $PC_FILEDIR || exit $PC_RESULT This one is not, it won't work at all. It does, at least for my use-case of pkg-config. Though I agree that this is not needed for you (only for relocation of libraries). But still, one simple wrapper is enough to support multiarch library dirs. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: multiarch and pkg-config
Am Dienstag 02 Februar 2010 21:43:21 schrieb Tollef Fog Heen: ]] Hendrik Sattler | Am Dienstag 02 Februar 2010 16:14:27 schrieb Simon McVittie: | However, this would also require that pkg-config itself was multiarch | or otherwise supported cross-compilation | (/usr/bin/i486-linux-gnu-pkg-config, like AC_CHECK_TOOL would use? | pkg-config --arch=i486-linux-gnu? etc.); until then, it's not useful | for pkg-config-using libraries to be multiarch (if I have i386 and | amd64 versions of libdbus-1-dev, but only the one whose architecture | matches my version of pkg-config actually works, then I might as well | uninstall the other version of libdbus-1-dev). | | pkg-config actually does support relocation of the libraries but for a | strange reason only on Windows. That means that for cross-compiling, | you have to fixup all paths it returns. The patch would be trivial. Uhm, no. You make sure the generated .pc files are correct and it will Just Work. The keyword here is _relocatable_ With a hard-coded 'prefix', there is no correct. | The undocumented pcfiledir variable can be used to hack around it, | probably better to convinve upstream to make pkg-config more | cross-compile-friendly. Thus, it may be possible to a generic shell | script as cross-pkg-config wrapper that does what you want (with many | symlinks to make autotools happy). Feel free to try to convince me. #!/bin/sh #find the GNU prefix GNU_PREFIX=`basename $0 | sed -e 's/\(.*\)-pkg-config/\\1/'` #set the new search path for pkg-config PKG_CONFIG_LIBDIR=/usr/lib/$GNU_PREFIX/pkgconfig:$PKG_CONFIG_LIBDIR export PKG_CONFIG_LIBDIR #get the location of the .pc file PC_NONOPTS=`echo $@ | sed -e 's/\(--[^ ]* \)*//g'` PC_FILEDIR=`pkg-config --variable=pcfiledir $PC_NONOPTS` PC_RESULT=$? test $PC_FILEDIR || exit $PC_RESULT #we assume that the wanted prefix is the parent directory #of the directory where the .pc file was found PC_PREFIX=`dirname $PC_FILEDIR` exec pkg-config --define-variable=prefix=$PC_PREFIX $@ May that work as a preplacement for xxx-yyy-zzz-pkg-config? HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: multiarch and pkg-config
Am Dienstag 02 Februar 2010 16:14:27 schrieb Simon McVittie: However, this would also require that pkg-config itself was multiarch or otherwise supported cross-compilation (/usr/bin/i486-linux-gnu-pkg-config, like AC_CHECK_TOOL would use? pkg-config --arch=i486-linux-gnu? etc.); until then, it's not useful for pkg-config-using libraries to be multiarch (if I have i386 and amd64 versions of libdbus-1-dev, but only the one whose architecture matches my version of pkg-config actually works, then I might as well uninstall the other version of libdbus-1-dev). pkg-config actually does support relocation of the libraries but for a strange reason only on Windows. That means that for cross-compiling, you have to fixup all paths it returns. The patch would be trivial. The undocumented pcfiledir variable can be used to hack around it, probably better to convinve upstream to make pkg-config more cross-compile-friendly. Thus, it may be possible to a generic shell script as cross-pkg-config wrapper that does what you want (with many symlinks to make autotools happy). HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: defaulting to net.ipv6.bindv6only=1 for squeeze
Am Samstag 26 Dezember 2009 03:43:08 schrieb Kurt Roeckx:
On Wed, Dec 23, 2009 at 12:47:45PM +0100, Hendrik Sattler wrote:
I have failures now with a client that cannot connect() to the IPv4
address but get an ENETUNREACH instead.
The application DOES set this socket option:
socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 3
setsockopt(3, SOL_IPV6, IPV6_V6ONLY, [0], 4) = 0
bind(3, {sa_family=AF_INET6,) = 0
listen(3, ) = 0
Does that mean your application only works if the kernel supports
IPv6?
Why would you want to disable basic IPv6 support?
In that case I think your application is broken.
No. Every software has requirements on the system. And this one requires basic
IPv6 support because it's programmed that way. I don't see any problem with
that. But you are free to have your own opinion.
HS
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: defaulting to net.ipv6.bindv6only=1 for squeeze
Am Mittwoch 23 Dezember 2009 14:07:54 schrieb Jarek Kamiński:
Na grupie linux.debian.devel napisałe(a)ś:
I have failures now with a client that cannot connect() to the IPv4
address but get an ENETUNREACH instead.
The application DOES set this socket option:
socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 3
^-- You meant IPPROTO_TCP?
setsockopt(3, SOL_IPV6, IPV6_V6ONLY, [0], 4) = 0
bind(3, {sa_family=AF_INET6,) = 0
listen(3, ) = 0
Did you ever test that setting this option back to 0 by a program before
bind() and listen() actually works?
Yes. Following code actually works (runs with bindv6only enabled,
listens on [::]:1234 and accepts connection made to localhost:1234):
#v+
#include sys/socket.h
#include netinet/in.h
int main ()
{
int no = 0;
int listenfd = socket (AF_INET6, SOCK_STREAM, IPPROTO_TCP);
int clientfd;
char buf[1024];
ssize_t rv;
struct sockaddr_in6 addr = { AF_INET6, htons(1234), 0, IN6ADDR_ANY_INIT
};
setsockopt (listenfd, SOL_IPV6, IPV6_V6ONLY, no, sizeof(no));
bind (listenfd, (void*)addr, sizeof(addr));
listen (listenfd, 1);
clientfd = accept (listenfd, 0, 0);
while ((rv = read (clientfd, buf, sizeof(buf))) 0)
write (1, buf, rv);
return 0;
}
I do:
int v6only = 0;
int fd = socket(AF_INET6, SOCK_STREAM, 0);
setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, (void*)v6only, sizeof(v6only));
bind(fd, (struct sockaddr *) my_sock, sizeof(struct sockaddr_in6));
listen(fd, 2);
...
And the client cannot connect! The value of IPPROTO_IPV6 and SOL_IPV6 are both
41, thus this cannot be the cause.
Maybe the difference is the 0 vs. IPPROTO_TCP? 0 is supposed to work,
though.
Additionally: what happens when I want to open an :::127.0.0.1 as an IPv6
socket?
But even when using IN6ADDR_ANY, the client cannot connect to 127.0.0.1.
Thanks
HS
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: defaulting to net.ipv6.bindv6only=1 for squeeze
Am Mittwoch 23 Dezember 2009 13:41:57 schrieb Marco d'Itri: On Dec 23, Hendrik Sattler p...@hendrik-sattler.de wrote: 1. It obviously doesn't do this only on new installation but also on upgrades. This is correct. 2. You cite RFC3493 but your request (and action) obviously violates it: RFC3493 is informational. Did you ever test that setting this option back to 0 by a program before bind() and listen() actually works? Yes. Nevermind, it's the client not calling the socket option. I still don't agree... HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: defaulting to net.ipv6.bindv6only=1 for squeeze
Am Samstag 24 Oktober 2009 20:24:31 schrieb Marco d'Itri:
I propose that netbase will create on new installations a file in
/etc/sysctl.d/ containing net.ipv6.bindv6only=1.
[...]
[2] http://tools.ietf.org/html/rfc3493#section-5.3
1. It obviously doesn't do this only on new installation but also on upgrades.
2. You cite RFC3493 but your request (and action) obviously violates it:
By default this option is turned off.
Hint: off means 0, not 1.
Why does Debian violate the RFC on purpose? Why does it break installed
systems?
I have failures now with a client that cannot connect() to the IPv4 address
but get an ENETUNREACH instead.
The application DOES set this socket option:
socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 3
setsockopt(3, SOL_IPV6, IPV6_V6ONLY, [0], 4) = 0
bind(3, {sa_family=AF_INET6,) = 0
listen(3, ) = 0
Did you ever test that setting this option back to 0 by a program before
bind() and listen() actually works?
Reverting your change fixes this. I am using Debian testing up-to-date with
linux-2.6.32 (self-compiled).
HS
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Minimal kernel version raised to 2.6.27
Zitat von Julien Cristau jcris...@debian.org: On Wed, Nov 11, 2009 at 02:14:00 -0600, Adam Majer wrote: On Wed, Nov 11, 2009 at 07:56:16AM +0100, Bastian Blank wrote: On Tue, Nov 10, 2009 at 06:08:08PM +0100, Marco d'Itri wrote: Due to changes in udev 147, squeeze will not support kernels earlier than 2.6.27. What are these changes? http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=26347a4c5538008318188118872490128f43fcd3 But still using pipe() instead of pipe2()? Was that commit incomplete? HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted obexftp 0.23-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 03 Oct 2009 10:37:15 +0200 Source: obexftp Binary: obexftp libbfb0 libbfb0-dev libmulticobex1 libmulticobex1-dev libobexftp0 libobexftp0-dev python-obexftp libobexftp-ruby libobexftp-perl Architecture: source amd64 Version: 0.23-1 Distribution: unstable Urgency: low Maintainer: Hendrik Sattler deb...@hendrik-sattler.de Changed-By: Hendrik Sattler deb...@hendrik-sattler.de Description: libbfb0- bfb protocol library libbfb0-dev - bfb protocol library - development files libmulticobex1 - multi-protocol cable OBEX library libmulticobex1-dev - multi-protocol cable OBEX library - development files libobexftp-perl - perl binding to the object exchange file transfer library libobexftp-ruby - ruby binding to the object exchange file transfer library libobexftp0 - object exchange file transfer library libobexftp0-dev - object exchange file transfer library - development files obexftp- file transfer utility for devices that use the OBEX protocol python-obexftp - Python binding to the object exchange file transfer library Closes: 522169 522302 Changes: obexftp (0.23-1) unstable; urgency=low . * New upstream release * Remove all patches, all were applied equally upstream * Rework the descriptions of all packages (closes: #522169) * Fix manpage links from obex(rm|ls|get|put) to obexftp (closes: #522302) * Put libobexftp-ruby into the right section * Fix the way of giving build (and if cross-building host) types to configure * Bump standards version to 3.8.3.0: no changes needed * Add ruby to Build-Depends Checksums-Sha1: da95ae656c7ac51ba2a6f5814e443d155d682bce 1926 obexftp_0.23-1.dsc a9e192f69d66d882a8a815d648a6383ce703b848 557251 obexftp_0.23.orig.tar.gz 1933a21c05a9855af11875d623e13b0fd8587078 7946 obexftp_0.23-1.diff.gz 3eacccec0862b410ca56c12d14803a773e6614db 30550 obexftp_0.23-1_amd64.deb 0769ced6bbd495d5a8330422e18d1f667639bb42 17360 libbfb0_0.23-1_amd64.deb 4ee33d5f4e4315a3fa5f0795d8050266d61f8b06 17896 libbfb0-dev_0.23-1_amd64.deb 7efb717168fc5849b910da6a3a7d541d3dba2415 13876 libmulticobex1_0.23-1_amd64.deb 19aa0779727a7853336fac877de5136eb784ad72 13180 libmulticobex1-dev_0.23-1_amd64.deb 0c2f44cdf71444c0611ffe96267a0f8d16612025 25642 libobexftp0_0.23-1_amd64.deb 991dc599ae0cb1f99e70697384f17fd34f5e41b1 87730 libobexftp0-dev_0.23-1_amd64.deb 90cb2c39dd9625c65084b55980216a282e7430a8 28146 python-obexftp_0.23-1_amd64.deb bb9e58d45154d9ded63c7f3dc94681bdc3acf8e8 21624 libobexftp-ruby_0.23-1_amd64.deb 0ef10e7e610dbb8516a37ab82ce750a01fb02fea 28024 libobexftp-perl_0.23-1_amd64.deb Checksums-Sha256: 1ff61dcb542bf87149b6725f1cf72c3cbcd4870a9cc591a92a3fbb4c24f08f0c 1926 obexftp_0.23-1.dsc c91d3a4ee6b2194765e70cdaf303747ef6bfb9ef932d1cb0815a615b8ea146bf 557251 obexftp_0.23.orig.tar.gz cdac622d17dd3dc0259f170f27b243569628ea6b4a09ba8b2d0fb2c13f04ba83 7946 obexftp_0.23-1.diff.gz 30749b147fa53687084a485bc8db1690b1193025e83bb642ee4620f6b4d5eb77 30550 obexftp_0.23-1_amd64.deb 448ff8f95c4452a3cc6bbc2303d04c25c298eed5385f53e5902cb468e4340419 17360 libbfb0_0.23-1_amd64.deb 300f6a4a33762b8f14a095b1fc601384f5d711201657d63e25597e203dfe0869 17896 libbfb0-dev_0.23-1_amd64.deb e66443ed0c4c0ee411f376d7839f6d7dca6cb2bd0893cf9e78c597bf3f7192e2 13876 libmulticobex1_0.23-1_amd64.deb a60f345e73610085586a6e77095e40486c7c386e4ec83250c7b939603f650b3d 13180 libmulticobex1-dev_0.23-1_amd64.deb f40bc05146a0308145de2b1a09f9dd6e602b089641ecec84a541232f7f965c3a 25642 libobexftp0_0.23-1_amd64.deb 5bcad46349414a6567d2101deae1a23381f261051a3222c6fcf6737bdc8ee68c 87730 libobexftp0-dev_0.23-1_amd64.deb 5088000a587852b641cea66ceea49b2441a28ed65e4ef696f7774389e9b6e889 28146 python-obexftp_0.23-1_amd64.deb 2b92254d41725708ff2669ca2a4ffe51ee8ac8dcc7939e936e911bddf9796620 21624 libobexftp-ruby_0.23-1_amd64.deb 2956038b5fb9de2a6e3b78c18031a54f2c77d326110d9c21041c322a5c4ebde6 28024 libobexftp-perl_0.23-1_amd64.deb Files: c1bd1b8d1db8f195606d391bae734843 1926 comm optional obexftp_0.23-1.dsc f7048562620d6b341f6abd4aa4f0e10d 557251 comm optional obexftp_0.23.orig.tar.gz b70647dacd3d150b5b2d2e786a1c40ee 7946 comm optional obexftp_0.23-1.diff.gz 77d62b4e6ae21ff17a0d50e5c4c82fe4 30550 comm optional obexftp_0.23-1_amd64.deb 9d7391ede567c10a6be0af837f134d6d 17360 libs optional libbfb0_0.23-1_amd64.deb 2d1efdd2b1ead433fc4430cbbc061621 17896 libdevel optional libbfb0-dev_0.23-1_amd64.deb 85f27bdeef6e2d37ba58900e5cac7850 13876 libs optional libmulticobex1_0.23-1_amd64.deb 0f73ad52506d4856e0f4983215705e7f 13180 libdevel optional libmulticobex1-dev_0.23-1_amd64.deb 215a39d79f1f2dd0e10cfc439584099e 25642 libs optional libobexftp0_0.23-1_amd64.deb 58afed553eb9d50fcab67571d96b27eb 87730 libdevel optional libobexftp0-dev_0.23-1_amd64.deb 6c0ae6c8e011cedd7272c9afaaf77760 28146 python optional python-obexftp_0.23-1_amd64.deb ab38daad0d8701f6943801e353797e04 21624 ruby optional libobexftp-ruby_0.23
Re: GObject introspection mini-policy, take 2
Am Sonntag 27 September 2009 04:59:38 schrieb Paul Wise: 2009/9/26 Josselin Mouette j...@debian.org: 1. Directory layout GObject-introspection data is generally provided in two formats: * XML format in /usr/share/gir-1.0/Foo-X.Y.gir * binary format in /usr/lib/girepository-1.0/Foo-X.Y.typelib ... 6. Example Suppose that libfoo-2.0 is an API built on libbar-3.0. The libfoo-2.0 source generates the following files, put in the following packages: libfoo-2.0-3 /usr/lib/libfoo-2.0.so.3* libfoo-2.0-dev /usr/lib/libfoo-2.0.so (and other usual stuff) libfoo-2.0-dev /usr/share/gir-1.0/Foo-2.0.gir gir1.0-foo-2.0 /usr/lib/girepository-1.0/Foo-2.0.typelib Would this proposal need to be adjusted for multiarch support? If so, perhaps just insert an arch triple? /usr/lib/arch/girepository-1.0/Foo-2.0.typelib Isn't the lib directory for each arch already different? I just question the need for a seperate package for _one_ typelib file. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Zitat von Josselin Mouette j...@debian.org: Le vendredi 04 septembre 2009 à 19:32 +0200, Hendrik Sattler a écrit : It rather needs to raise the question why simple low-level tools use something like libglib? I’d rather raise the question why each of our simple low-level tools implement its data structures and basic routines in its own fashion, leading to bugs and security issues sometimes, instead of re-using the ones from Glib. You mean useless functions like those only wrap standard functions and add no value except a (build-)dependency to libglib? Very exciting. There may be lots of useful stuff in libglib but some may only be useful as portability wrapper (but some not even for that). Get rid of all of those and I may agree. I fully disagree for using libglib as wrapper around libc. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Zitat von Josselin Mouette j...@debian.org: Le lundi 07 septembre 2009 à 15:51 +0200, Bjørn Mork a écrit : I'm suggesting that the utility uses lots of g_ prefixed functions while it's obvious that the author never ever evaluated the need for these. I assume that's because the author is used to them always being available. Well, in the context of udev helpers, they are not. Starting from the next glib2.0 upload, they will be. End of problem. So no trying to convince glib upstream to reduce wrapper bloat? *sigh* HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Am Samstag 05 September 2009 23:29:39 schrieb Steve Langasek: The rationale for this /using glib/ is that devicekit-disks is not an integral part of udev, it's an add-on component that will be installed only on desktop systems. So the size impact to /lib for servers for this component would be negligible; the total size impact of pulling in libglib on the desktop is zero; and the size impact to /lib for desktops is almost certainly also negligible. And what about embedded systems? They start to use those libraries for even the simplest utilities that are also usuable on very small systems. And that's what worries me. If libglib is accepted are core utility in /lib, there will be no end to this :-( (I'll do you one better, though -- system-config-printer upstream wants to install /lib/udev/udev-configure-printer, which pulls in the entire libcups stack. Sigh...) *sigh* I agree. Has the world gone mad? HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Am Samstag 05 September 2009 08:18:13 schrieb Steve Langasek: On Fri, Sep 04, 2009 at 09:09:40PM +0200, Bjørn Mork wrote: And it is also very unclear to me why this has to be in /lib/udev at all. Because it provides a single point where the desktop hooks into the kernel hotplug event system, instead of having hal redo all the work already done by udev. /That/ much has a sound rationale, even if reading text databases in does not. It's still no rationale at all to use libglib. Even d-bus is not a reason, it is possible to use it without using gobject. If it isn't, fix libdbus first or don't use it. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Am Samstag 05 September 2009 11:20:06 schrieb Michael Biebl:
Hendrik Sattler wrote:
Am Samstag 05 September 2009 08:18:13 schrieb Steve Langasek:
On Fri, Sep 04, 2009 at 09:09:40PM +0200, Bjørn Mork wrote:
And it is also very unclear to me why this has to be in /lib/udev at
all.
Because it provides a single point where the desktop hooks into the
kernel hotplug event system, instead of having hal redo all the work
already done by udev. /That/ much has a sound rationale, even if
reading text databases in does not.
It's still no rationale at all to use libglib. Even d-bus is not a
reason, it is possible to use it without using gobject. If it isn't, fix
libdbus first or don't use it.
I'm not sure why you bring up libdbus/dbus, but a quick look at dbus'
dependencies will show you that it doesn't require libglib.
This refers to the previously mentioned URL
http://article.gmane.org/gmane.linux.gentoo.devel/62973:
These extras are:
[...]
* gudev: glib/gobject support for libudev
Additionally, further down the thread:
This is the interface almost everything is going to turn to with GNOME
2.28 (via DeviceKit-power and DeviceKit-disks in most cases). By the
time GNOME 2.30 and 3.0 are released, (theoretically) nothing will use
HAL.
and
all current DeviceKit-{power,disks} versions *need* gudev.
And that is usually about the usage of dbus.
HS
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Am Freitag 04 September 2009 16:36:52 schrieb Michael Biebl: devkit-disks-part-id and devkit-disks-probe-ata-smart both link against libraries which are (currently) in /usr/lib, i.e. devkit-disks-part-id links against libglib-2.0 (784K) devkit-disks-probe-ata-smart links against (48K) This will mean, that we will need to install those two libs in /lib. It rather needs to raise the question why simple low-level tools use something like libglib? What does it use from libglib that it couldn't do without? HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Where should DLL files go?
Am Mittwoch 26 August 2009 19:06:22 schrieb Steve Langasek:
On Tue, Aug 25, 2009 at 09:48:56PM +0100, Sam Morris wrote:
Although on Debian, the same shared library files (libfoo.so) are used
by both compilers to link against, and ld-linux (what is that thing
called? The loader? The linker?) to satisfy runtime dependencies,
Mm, not exactly. At build time you use libfoo.so; at runtime you use
libfoo.so.VER. It just happens that the ELF version of stubs is trivial
(a symlink).
SONAME or, if no SONAME, libfoo.so. The SONAME may be something totally
different than libfoo.so.VER
But you know that ;)
From a multiarch point of view, perhaps the DLL could go
in /usr/lib/i586-mingw32msvc?
Cf. bug #542865 - in the future we might actually have a mingw32
mini-architecture, at which point these files would cause a package
conflict. Maybe use /usr/i586-mingw32msvc/lib for now (the cross-build
directory)?
Actually, the .lib files go to ${PREFIX}/lib and the .dll files go to
${PREFIX}/bin (together with binaries that need them). Having PREFIX as
/usr/i586-mingw32msvc is probably fine, though the 'msvc' is misplaced: gcc is
used not the MicroSoft Visual Compiler (usually abbreviated with msvc).
HS
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What to do with (packages like) Blender?
Zitat von Christian Perrier bubu...@debian.org: Quoting Cyril Brulebois (k...@debian.org): 4) http://article.gmane.org/gmane.comp.video.blender.devel/19895 Patch to add support for system-wide FTGL. I kind of get flamed for thinking about using something else than what blender provides. And who cares about shared libraries anyway, they are dangerous. If you want to have a good idea of what blender folks think about being distributed, you want to read that thread. That one shows the problem clearly enough. Blender folks are not interested in using system-wide libs *at all*. They apparently prefer using their own private (and buggySam made the point very clear) version of a library, on the vague assumption that, as libraries change their API without warning, they're bad. I'm anything but a specialist in this area, but my understanding is that this is what sonames are about..:-). Anyway, in 2009, such reasoning isawfully flawed. Just drop that blender thing and announce this loudly enough, preferrably by coordinating with other distro maintainers. That will eventually trigger a fork from people who have a more collaborative way of thinking. After all, to my understanding, this blender stuff is kinda widely used in 3D modelling, right? I read that discussion in a different tone as it mostly refers to the FTGL thing. They made changes to the library that are needed and blender would not work correctly without those. The patch doesn't ensure that the system version of that library includes those changes, it doesn't even check for known good versions. This was the main complaint especially since there is no release of FTGL with those changes, yet! So they cannot expect for everyone (and there are other distributions, too) to use _unreleased_ versions of a library (release candidates are not a release). Together, these are valid points for linking a private copy that was tested against. They didn't say anything against having to update that copy. Additionally, not all upstream library developers are aware of how SONAMEs are to be handled (and maybe they got burned by this before). Maybe because libtool's description of SONAMEs is way to complicated (what insane person wrote this?) and limited, and because other popular systems don't support this. After all, users only see bugs in the frontend, not in the libraries behind it. And there are lots of other projects, too, that include private copies of libraries (e.g. mplayer). This was even the proposed way for some GNU stuff some time ago! HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Re: Introduction to multiarch: What maintainers must do
Zitat von sthiba...@debian.org:
My first thought was Err. Won't moving all the shared libs into a
different location kinda screw things up? And then I looked, and found
| == /etc/ld.so.conf.d/x86_64-linux-gnu.conf ==
Yes, but however pkg-config won't yet find things in
/usr/lib/x86_64-linux-gnu/pkgconfig, so take care of putting .pc files
in /usr/lib/pkgconfig.
Please don't as those files can be different on different
architectures. Change PKG_CONFIG_PATH or PKG_CONFIG_LIBDIR instead.
pkg-config has a win32-only feature to derive the prefix variable from
the location of the .pc file. Removing the ifdef would also enable
this on Linux and make pkg-config multiarch-usable.
Alternative: install pkg-config as ${DEB_HOST_GNU_TYPE}-pkg-config for
each arch (each with the correct default search path) and link the
default arch pkg-config to it. Autotools will automatically handle it,
cmake currently won't.
HS
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#537588: RFP: gtk-kde4 -- theme engine using Qt 4 for GTK+2.x
Am Sonntag 19 Juli 2009 17:59:55 schrieb Resul Cetin: Package name: gtk-kde4 Version: 0.9b Upstream Author: Yulian Konchunas mu...@gala.net URL: http://www.kde-apps.org/content/show.php/gtk-kde4?content=74689 License: GPL2+ Description: theme engine using Qt 4 for GTK+2.x The GTK-Qt Theme Engine (also known as gtk-qt-engine) is a GTK+ 2 theme engine that calls Qt 4 to do the actual drawing. This makes your GTK+ 2 applications look almost like real Qt 4 applications and gives you a more unified desktop experience. . Please note that this package is targeted at KDE 4 users and therefore provides a way to configure it from within Systemsettings You can close this again as it is already available as gtk-qt-engine-kde4. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching the default /bin/sh to dash
Am Donnerstag 25 Juni 2009 05:21:45 schrieb Raphael Geissert: I just noticed I forgot to say something: What won't change: * Bash will still be used as the default interactive shells for users * the sh symlink won't be modified on existing installations So that it will be even more strange that a script with bashisms works on some Debian Squeeze systems but not on others? Yeah, great idea. And so that all users that upgrade do not benefit from the goal of this change? Even better. I usually don't like those not-on-upgrade exceptions. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted libopenobex 1.5-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 21 Jun 2009 17:29:41 +0200 Source: libopenobex Binary: libopenobex1-dev libopenobex1 openobex-apps Architecture: source amd64 Version: 1.5-2 Distribution: unstable Urgency: low Maintainer: Hendrik Sattler deb...@hendrik-sattler.de Changed-By: Hendrik Sattler deb...@hendrik-sattler.de Description: libopenobex1 - OBEX protocol library libopenobex1-dev - OBEX protocol library - development files openobex-apps - Applications for OpenOBEX Closes: 525493 Changes: libopenobex (1.5-2) unstable; urgency=low . * Fix Docbook-XML build dependencies to build the application manual pages * Replace dh_clean -k with dh_prep call * Fix cmake version dependency (closes: #525493) * Bump standard revision to 3.8.2.0: no changes required. Checksums-Sha1: 3016a5963b03b46bd6c2adc3a975bfe281db80e8 1204 libopenobex_1.5-2.dsc 2c33805e11e8a0841f5574c11289bbd8bab2ab7d 9333 libopenobex_1.5-2.diff.gz 3689584ded6b57eeebd2e956aca0a58ae631a7a1 100016 libopenobex1-dev_1.5-2_amd64.deb 008aa6916e8cb8a9dc7a88f5de33a50b08424b61 24166 libopenobex1_1.5-2_amd64.deb 15e51f8b9690e3dbfc85a166e46beed185b4bd2f 38168 openobex-apps_1.5-2_amd64.deb Checksums-Sha256: efd4be81aecada534af051f788019de941eba7ae31b14248730afb955de382df 1204 libopenobex_1.5-2.dsc 91776e2a300b0c9ffd15c9dc10341bdaebf68b0fb27d9a49bc11294f5bbf5aa3 9333 libopenobex_1.5-2.diff.gz 597a1b9aebda6abae98bc19a1b5368b3cbfea457c7a2c7e032061e8e821c21fb 100016 libopenobex1-dev_1.5-2_amd64.deb c970eecdcba898858c6852bedadb215e83f833686f9e80612e83607b1860448b 24166 libopenobex1_1.5-2_amd64.deb df1c69c54d02682163517f99bde431a00aaa641e7d90dd998c6949c93793f124 38168 openobex-apps_1.5-2_amd64.deb Files: 92e040319cc0dd765e32ad9f0a793e82 1204 comm optional libopenobex_1.5-2.dsc 65705528863aa0e78f043f94280ce008 9333 comm optional libopenobex_1.5-2.diff.gz c10b662b8a50f9672c054501aa9526c9 100016 libdevel optional libopenobex1-dev_1.5-2_amd64.deb e8f90403cf861f1223a775db0813b406 24166 libs optional libopenobex1_1.5-2_amd64.deb c619b01d01f8be46716af29836ad9473 38168 comm optional openobex-apps_1.5-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKPzXTVkEm8inxm9ERAoT9AJ9kI6DpByU9zWMMnwW5SnFOhxpa2gCdGacL VCweVVsfZBN10LW4ZD8D4TM= =trW/ -END PGP SIGNATURE- Accepted: libopenobex1-dev_1.5-2_amd64.deb to pool/main/libo/libopenobex/libopenobex1-dev_1.5-2_amd64.deb libopenobex1_1.5-2_amd64.deb to pool/main/libo/libopenobex/libopenobex1_1.5-2_amd64.deb libopenobex_1.5-2.diff.gz to pool/main/libo/libopenobex/libopenobex_1.5-2.diff.gz libopenobex_1.5-2.dsc to pool/main/libo/libopenobex/libopenobex_1.5-2.dsc openobex-apps_1.5-2_amd64.deb to pool/main/libo/libopenobex/openobex-apps_1.5-2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#533872: ITP: sdop -- Simple DocBook Processor
Am Sonntag 21 Juni 2009 10:05:34 schrieb Andreas Metzler: Package: wnpp Severity: wishlist * Package name: sdop Version : 0.52 Upstream Author : Philip Hazel * License : GPLv2+ Programming Lang: C Description : Simple DocBook Processor SDoP (Simple DocBook Processor) reads a DocBook XML file, processes it into typeset pages, and outputs the result as PostScript (which can easily be converted to a PDF). It is simple because it supports only a subset of DocBook, and also because it does not make use of a DTD or stylesheets or any other heavyweight apparatus. It is a single rogram. SDoP is used to format the Exim reference manual. Which DocBook version? Is the subset standardized somwehere? Has the program a webpage? HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#533872: ITP: sdop -- Simple DocBook Processor
Am Sonntag 21 Juni 2009 20:32:07 schrieb Andreas Metzler: On 2009-06-21 Hendrik Sattler p...@hendrik-sattler.de wrote: Am Sonntag 21 Juni 2009 10:05:34 schrieb Andreas Metzler: * Package name: sdop Version : 0.52 Upstream Author : Philip Hazel * License : GPLv2+ Programming Lang: C Description : Simple DocBook Processor SDoP (Simple DocBook Processor) reads a DocBook XML file, processes it into typeset pages, and outputs the result as PostScript (which can easily be converted to a PDF). It is simple because it supports only a subset of DocBook, and also because it does not make use of a DTD or stylesheets or any other heavyweight apparatus. It is a single rogram. SDoP is used to format the Exim reference manual. Which DocBook version? Is the subset standardized somwehere? According to the documentation: Support for almost all the elements that are part of Simplified DocBook, as defined in the following URL: http://docs.linux.cz/programming/markup/www.docbook.org/tdg/simple/en/html/ sdocbook.html The main omissions are support for bibliographies, multiple authors, subtables within tables, and some element attributes. Chapter 7 below contains a complete list of what SDoP does support. That looks like http://www.docbook.org/schemas/sdocbook/ should fit the document. So maybe you want to mention the exact name Simplified Docbook, maybe even the supported Version of that standard. That would make it possible to use it as alternative to xsltproc/saxon/xalan and fop for such cases. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted ussp-push 0.11-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 20 Jun 2009 16:54:54 +0200 Source: ussp-push Binary: ussp-push Architecture: source amd64 Version: 0.11-1 Distribution: unstable Urgency: low Maintainer: Hendrik Sattler deb...@hendrik-sattler.de Changed-By: Hendrik Sattler deb...@hendrik-sattler.de Description: ussp-push - Client for OBEX PUSH Closes: 391045 530359 Changes: ussp-push (0.11-1) unstable; urgency=low . * New upstream release * Rewrite debian/rules to use the new autotools build system * Remove all old patches: not needed anymore due to new build system * Change depends from libbluetooth2-dev to libbluetooth-dev (closes: #530359) * Add new patch hci_api_change.patch: change from hci_remote_name() to hci_read_remote_name() * Bump standards version to 3.8.1.0: no changes needed * Change to debhelper compat level 7 * Do not install the contents of doc/ subdir anymore, everything is already in the manpage * Fix typo in description (closes: #391045) * Use dh_prep instead of dh_clean -k Checksums-Sha1: 4768593855a9a5f1d69bd4ee02313d06159e2aa6 1109 ussp-push_0.11-1.dsc 0ebdee12c42a6f39adbde027f3e5eed3f64b839d 339071 ussp-push_0.11.orig.tar.gz ee1ddf67b2511540f4bb63803e985f78b10fa6f4 4007 ussp-push_0.11-1.diff.gz e854a2fb8774071453e9ea2b68f5ec42159dbe29 15716 ussp-push_0.11-1_amd64.deb Checksums-Sha256: a1b3b72c06659528181779843fbca471fbad8293158cae3854df1225ff5f4126 1109 ussp-push_0.11-1.dsc ee941e7064307d75193f51853c5f4b0de62cc6029a3dd5244a077946f729b4d8 339071 ussp-push_0.11.orig.tar.gz 67d32570f4e3be0acc141ed00c57da038f993a9e302932316b7cf4b8bdd62f1c 4007 ussp-push_0.11-1.diff.gz e9d46e49b2b10004498b2d78fd8d28341d090d6a3f55f28a59e4bea0fdf4fd60 15716 ussp-push_0.11-1_amd64.deb Files: 47eb9877953edd5c1cadd7681469c334 1109 comm optional ussp-push_0.11-1.dsc 8a4bbc482f8250f0ce60560a2c778836 339071 comm optional ussp-push_0.11.orig.tar.gz d09c3d12ed9dd393d6a8bcf26bfc4063 4007 comm optional ussp-push_0.11-1.diff.gz 724af99524fb8bc1881403914e0d3061 15716 comm optional ussp-push_0.11-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAko8/oYACgkQABzeamt51AEgPwCgtL5qcXhCu7liDafiqZAERtHj 2rgAoMRLBdfOfkHZW8NjPfe4HQG0C0k9 =69jY -END PGP SIGNATURE- Accepted: ussp-push_0.11-1.diff.gz to pool/main/u/ussp-push/ussp-push_0.11-1.diff.gz ussp-push_0.11-1.dsc to pool/main/u/ussp-push/ussp-push_0.11-1.dsc ussp-push_0.11-1_amd64.deb to pool/main/u/ussp-push/ussp-push_0.11-1_amd64.deb ussp-push_0.11.orig.tar.gz to pool/main/u/ussp-push/ussp-push_0.11.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted obexfs 0.11-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 16 Jun 2009 19:00:02 +0200 Source: obexfs Binary: obexfs Architecture: source amd64 Version: 0.11-1 Distribution: unstable Urgency: low Maintainer: Hendrik Sattler deb...@hendrik-sattler.de Changed-By: Hendrik Sattler deb...@hendrik-sattler.de Description: obexfs - mount filesystem of ObexFTP capable devices Closes: 492260 526456 Changes: obexfs (0.11-1) unstable; urgency=low . * New upstream release * Bump debhelper compat level to 7 * Update to standards version 3.8.1.0: no changes required * debian/control: require obexftp = 0.22 * debian/conrol: fix obexftp dependency (closes: #526456) * Update README.debian: obexfs now also handles USB devices * debian/manpages/obexautofs.sgml: correct option descriptions (closes: #492260) * Save and restore original config.sub and config.guess correctly * Use dh_prep instead of dh_clean -k Checksums-Sha1: 43d1bed21983f811d9c10519e1408500fed75af7 1041 obexfs_0.11-1.dsc ab12400dfbe9a9b118a0f3a57c742d5ea9ed4cb3 86933 obexfs_0.11.orig.tar.gz 504dae8d60360728d0cbe35c5ec2498b0ef6e92c 4912 obexfs_0.11-1.diff.gz 132beee9e2e5d45695d1c913890e8ffc04b0a7ee 17270 obexfs_0.11-1_amd64.deb Checksums-Sha256: 6912b91e39d8d64e8b34d7a4e6fdf2a037cded6a096992215d7f9ef524a0e517 1041 obexfs_0.11-1.dsc 4ff113dfa4f677e047fce0ee4da7c619adfe6087181376facbb605a38a347243 86933 obexfs_0.11.orig.tar.gz 26e783fc517738eedc597481715e9e0e978f925ca0329564898cd7e35f2dd2a8 4912 obexfs_0.11-1.diff.gz fb31903e6815ea770bc988827a870547ba8a50ccc13c6b25c018514074c6bc4d 17270 obexfs_0.11-1_amd64.deb Files: 85fda2a6578bfc094b1ce6256ce2e37d 1041 comm optional obexfs_0.11-1.dsc 0980ad75b27e15347c7621ca525ba36b 86933 comm optional obexfs_0.11.orig.tar.gz f6657649166504f559f859aba00ba0b0 4912 comm optional obexfs_0.11-1.diff.gz a3db5cf8d780afc437d0e047274c5250 17270 comm optional obexfs_0.11-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAko7QqgACgkQABzeamt51AF/NACfb7arYCiUFdjOaHq5ajp7I3Kd JGsAoIeXdZa8xLC5/xGGNTMBs2rustGS =O08Y -END PGP SIGNATURE- Accepted: obexfs_0.11-1.diff.gz to pool/main/o/obexfs/obexfs_0.11-1.diff.gz obexfs_0.11-1.dsc to pool/main/o/obexfs/obexfs_0.11-1.dsc obexfs_0.11-1_amd64.deb to pool/main/o/obexfs/obexfs_0.11-1_amd64.deb obexfs_0.11.orig.tar.gz to pool/main/o/obexfs/obexfs_0.11.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#528061: ITP: obexd -- OBEX client and server
Zitat von Filippo Giunchedi fili...@debian.org: On Sun, May 10, 2009 at 09:15:19PM +0200, Hendrik Sattler wrote: The obexd is an attempt to unify all current OBEX based servers for No, it isn't. It's another implementation. Implementation of OBEX client and server as a D-Bus service providing high-level functionality. sounds better? Yes. :) Linux and create a small, but powerful daemon. [taken from upstream http://www.bluez.org/obexd-01/] I'll package this under pkg-bluetooth http://svn.debian.org/wsvn/pkg-bluetooth/packages/obexd/ What is the difference to obex-data-server? e.g. ods changed API between 0.3 and 0.4, bluez-gnome 1.8 supports ods 0.3 and obexd AFAICT. And upcoming kdebluetooth4 uses solid which require bluez 4.x and (latest) obex-data-server (that's what I read about it). Bluez-gnome 1.8 is crippled when not used with bluez 4.x. I doubt obexd runs with anything but bluez 4.x. And bluez 4.x is not in unstable, yet. Hmm. Also the two use different dbus org.openobex APIs which I'm currently not sure what is the recommended one, see http://www.mail-archive.com/openobex-us...@lists.sourceforge.net/msg01284.html That one gives no answers. I'm lazy comparing both APIs but they use the same dbus namespace and thus cannot run in parallel. Both upstream, from obexd and from obex-data-server, should be contacted to clarify that. The decision should not be forwarded to the users and they simply won't know. And having kdebluetooth4 using ods while bluez-gnome uses obexd only makes it worse. If they use the same dbus API, they should share the same virtual package and the decriptions for both should state the OBEX profiles that they support (for obexd this is OPP and FBS). Both are in active development. Please also take into account that bluetooth is not only used with bluetooth transport but also with IrDA, USB, TCP and possibly serial cables. Obexd only supports bluetooth, AFAIK. obex-data-server also supports USB, AFAIK. I would like to avoid the same mess as we had with bluez 2.x - 3.x transition where there were no usuable frontends until much later. So the whole thing should be polished including packaging of kdebluetooth4. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#528061: ITP: obexd -- OBEX client and server
Am Sonntag 10 Mai 2009 17:36:25 schrieb Filippo Giunchedi: Package: wnpp Severity: wishlist Owner: Filippo Giunchedi fili...@debian.org * Package name: obexd Version : 1.5 Upstream Author : Marcel Holtmann mar...@holtmann.org * URL : http://www.bluez.org/ * License : GPL, LGPL Programming Lang: C, Python Description : OBEX client and server The obexd is an attempt to unify all current OBEX based servers for No, it isn't. It's another implementation. Linux and create a small, but powerful daemon. [taken from upstream http://www.bluez.org/obexd-01/] I'll package this under pkg-bluetooth http://svn.debian.org/wsvn/pkg-bluetooth/packages/obexd/ What is the difference to obex-data-server? HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Possible mass bug filing: non-doc packages recommending doc packages
Zitat von Neil Williams codeh...@debian.org: I rarely write TeX but I write a lot of docbook and expect to be able to convert that to PDF when necessary - without needing to care about how that happens or how to write TeX myself. Well, you might as well use the FO output and use fop to convert to PDF. This implies that you use docbook XML. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#524896: general: Home directory pollution
Am Mittwoch 22 April 2009 18:21:01 schrieb Roger Leigh: On Mon, Apr 20, 2009 at 05:59:24PM -0500, Manoj Srivastava wrote: On Mon, Apr 20 2009, Roger Leigh wrote: I was horrified to discover in the last few weeks that Emacs now also defaults to ~/Documents when you start it up, making you delete the useless Documents before you can actually type in something useful. Is this part of some desktop conspiracy to force us to use these Capitalised folder names?! Umm, what? I use Emacs from Git, and I have never seen that directory. Indeed, grepping through the source. the only place that appears is in rmail-mime-attachment-dirs-alist -- have I found the only other person in the world apart from RMS who uses rmail? I too have looked through the emacs sources, the installed files under /usr/share/emacs*, my .emacs and /etc/emacs* and I can see no trace of this, but when I hit C-x C-f on startup, it defaults to ~/Documents. I still can't find where this is set. Ah, I now think I have it. KDE4 must default to its CWD being ~/Documents (yuck, I really don't want that directory!), and by default emacs will use the CWD as the default path. I am running KDE4 but only the -nox version of emacs. I don't have ~/Documents in my $HOME and emacs doesn't default to it, just the current dir as you already realized. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted obexftp 0.22-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 25 Oct 2008 16:28:12 +0200 Source: obexftp Binary: obexftp libbfb0 libbfb0-dev libmulticobex1 libmulticobex1-dev libobexftp0 libobexftp0-dev python-obexftp libobexftp-ruby libobexftp-perl Architecture: source i386 Version: 0.22-1 Distribution: unstable Urgency: low Maintainer: Hendrik Sattler deb...@hendrik-sattler.de Changed-By: Hendrik Sattler deb...@hendrik-sattler.de Description: libbfb0- bfb protocol library libbfb0-dev - bfb protocol library - development files libmulticobex1 - multi-protocol cable OBEX library libmulticobex1-dev - multi-protocol cable OBEX library - development files libobexftp-perl - perl binding to the object exchange file transfer library libobexftp-ruby - ruby binding to the object exchange file transfer library libobexftp0 - object exchange file transfer library libobexftp0-dev - object exchange file transfer library - development files obexftp- file transfer utility for devices that use the OBEX protocol python-obexftp - Python binding to the object exchange file transfer library Closes: 394339 398068 493723 Changes: obexftp (0.22-1) unstable; urgency=low . * New upstream release (closes: #394339, #398068) * Remove all old patches, all were applied equally upstream * Bump debhelper compatibility to 7 * Add Homepage source package control field * Compile all libs as shared objects and split them into separate packages libobexftp0, libmulticobex1 and libbfb0 * Add python-obexftp package for the Python binding: - Change from dh_pysupport to dh_pycentral - Remove debian/pycompat, only needed for dh_python * Add libobexftp-ruby package for the ruby binding * Add libobexftp-perl package for the perl binding - Call dh_perl in debian/rules * Use dh_installexamples to install the programming examples * Bump standards version to 3.8.0 and apply the necessary changes: - added debian/README.source to describe how to apply the patches, - added Homepage field * Add obexls, obexget, obexput and obexrm as symlinks to obexftp binary * Add patch sizeof_fixes_SVN217 from upstream that fixes a bug related to usage of sizeof() * Remove sablotron from build-depends (closes: #493723) * Add doxygen to build-depends, needed to build the new API documentation * Add swig to build-depends and force rebuilding the pre-built swig files Checksums-Sha1: 72ade4dda868c451a85166466c3b467493d5e879 1316 obexftp_0.22-1.dsc f8fa04694baf3e0b2fa206607dc8d8ccf48fd91e 555168 obexftp_0.22.orig.tar.gz b7d47cf8dd4be90e57243eaa160da33786d208eb 8117 obexftp_0.22-1.diff.gz b55f38deebe9174954f4de35a5c7adffec039715 31996 obexftp_0.22-1_i386.deb 8d581c261910301875355496bc54f2d9e20ef841 16388 libbfb0_0.22-1_i386.deb c3290df172090b956b3e5e757ad6934c8658a133 16734 libbfb0-dev_0.22-1_i386.deb 9089e9a2ddc44badd01b4a6d7d6a1375e4f7e13f 13244 libmulticobex1_0.22-1_i386.deb c963a1e4bac12f7efc6775b23eaad63ce8203e41 12552 libmulticobex1-dev_0.22-1_i386.deb 818824076099fc6848d45070d14022c423c34fee 23606 libobexftp0_0.22-1_i386.deb 7e8baaa79edbe99e7046216606a6a1a7cc142f57 75976 libobexftp0-dev_0.22-1_i386.deb df26189570d6bafc2e76bacfed1b5a9da62faa9b 26302 python-obexftp_0.22-1_i386.deb 3a75c4b0ce20d154e9b908f40a94c6f59b88256c 19816 libobexftp-ruby_0.22-1_i386.deb e33562abef85af4f862226a3b3ba2d5a9a64b5c6 26626 libobexftp-perl_0.22-1_i386.deb Checksums-Sha256: 635cb9e8ed6db6782318f9dcc3bdfc28fe0bb767b984dfd6fde2f08688d268fa 1316 obexftp_0.22-1.dsc 954a176de97cbc1b8f54ad3897b33721d82077926a1980d1a8a651a490ec283c 555168 obexftp_0.22.orig.tar.gz 05ab81fcd09f43625bc538834f0ec815aabd10055d4445b3708beb85a73944d7 8117 obexftp_0.22-1.diff.gz 70144884f20d1228cda412e4a40f315c35f63d750b7330fb79101beefd480c0c 31996 obexftp_0.22-1_i386.deb ec20109f678d8544dd68db26e142193f07aa95864258378fe8df0243de5ce0ad 16388 libbfb0_0.22-1_i386.deb 289fc05ae6f5c5820cc6f1bb804a78db1cd99ffc699340e97d92f4d8ce1f799b 16734 libbfb0-dev_0.22-1_i386.deb fddf2a21e204cde542b751ae78843788abab66a45ff5f97b1ce60ed79239c1b7 13244 libmulticobex1_0.22-1_i386.deb 4c3dfae51789ee42973cc7627117650bc3a3c1a3ff0465f529c1c56e9a5fc877 12552 libmulticobex1-dev_0.22-1_i386.deb d7377c3098f4c36b766787c28dfa46503b898fdfb9b3591b63e115b7694debdb 23606 libobexftp0_0.22-1_i386.deb ec57083eba225a78f83b96114961be12d99a148e817656f467b82c129b004b9a 75976 libobexftp0-dev_0.22-1_i386.deb 122605e9a8230e82cae907bff821f4f44d4a26b5a759b2e4d5e871cce9ca4d85 26302 python-obexftp_0.22-1_i386.deb 71b68ee94c7d743f4b654f0145d5c47dbc5a7a0f14fe229b38fcb364fc6e0211 19816 libobexftp-ruby_0.22-1_i386.deb 0f2b3cd1b47dbc463f10985589aa7cf9434d216125a337cf092029de35b61fc6 26626 libobexftp-perl_0.22-1_i386.deb Files: 5ccd42cdcac494aa3309397383525024 1316 comm optional obexftp_0.22-1.dsc c578b0db85875658ec46733ab4957681 555168 comm optional obexftp_0.22.orig.tar.gz 184f88597f1d7cadfa81bba6a47e 8117 comm
Re: xcdroast does no longer work with wodim: Who to blame?
Joerg Schilling schrieb: As a hint: the work mkisofs is the plain files that can be found in the sub-directory mkisofs in the cdrtools source tree. Other sub-directories in this source tree colletion contain _other_ independent works. option type=personal So you like to enhance a program with a GPL license by implementing the extra stuff in a non-GPL library and using that library in the program. Nice GPL work-around :-( If that works and is legal, the whole GPL is non-sense. BTW: just making something compile separately is not independent work. /opinion It's personal optinion as I am no lawyer but it's my understanding of the GPL. And no, I will not discuss that opinion. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#516415: ITP: skysentials -- extra functionalities for Skype Linux client
Am Samstag 21 Februar 2009 11:29:19 schrieb Rafael Laboissiere: Package: wnpp Severity: wishlist Owner: Rafael Laboissiere raf...@debian.org * Package name: skysentials Version : 1.0.1 Upstream Author : Philipp Kolmann phil...@kolmann.at * URL : http://www.kolmann.at/philipp/linux/skysentials/ * License : BSD Programming Lang: Python Description : Extra functionalities for Skype Linux client [...] Architecture: amd64 (x86_64) That is strange: you depend on a package that is neither in Debian nor available for amd64 (skype.com only offer i386). HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted libopenobex 1.5-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 14 Feb 2009 11:08:49 +0100 Source: libopenobex Binary: libopenobex1-dev libopenobex1 openobex-apps Architecture: source amd64 Version: 1.5-1 Distribution: unstable Urgency: low Maintainer: Hendrik Sattler deb...@hendrik-sattler.de Changed-By: Hendrik Sattler deb...@hendrik-sattler.de Description: libopenobex1 - OBEX protocol library libopenobex1-dev - OBEX protocol library - development files openobex-apps - Applications for OpenOBEX Closes: 514577 Changes: libopenobex (1.5-1) unstable; urgency=low . * New upstream release (closes: #514577) * Removed patch files define.patch, compat_defines.path, ircp.path: included upstream * Rewrote debian/rules to compile using CMake * Added CMake = 2.6 to build-depends * Added parallel build option support in debian/rules * Bump standard revision to 3.8.0.0: Copied README.source from quilt package * Removed debian/manpages/*: included upstream as DocBook XML * Add patch: fix version information in toplevel CMakeLists.txt * Add patch: Add missing doc/openobex-apps.xml (from upstream git repository) * Add patch: fix bluetooth detection in CMakeModules/FindBluetooth.cmake * Add patch: fix undefined use of sprintf Checksums-Sha1: b9dbd69c6a55ef9d0a0a07485be143ace8c0145f 1190 libopenobex_1.5-1.dsc ff5fc07287d67fa73ec55998f76ed73787a2ddb1 400876 libopenobex_1.5.orig.tar.gz a86f4cb0292a14e8b29355469a29aedd0754577c 9234 libopenobex_1.5-1.diff.gz 749ad8f73d756c348b33f4a9758ef468b87e2318 99530 libopenobex1-dev_1.5-1_amd64.deb 5c34ae93e1b09a64a06ddec8680ae184215de406 24160 libopenobex1_1.5-1_amd64.deb ba09ad695fbb23bc0c82673341b78654309b9bad 35418 openobex-apps_1.5-1_amd64.deb Checksums-Sha256: 75377eda750880223cad59d476ce3c42c63604e2ee78ee7617281bc72550639e 1190 libopenobex_1.5-1.dsc e602047570799a47ecb028420bda8f2cef41310e5a99d084de10aa9422935e65 400876 libopenobex_1.5.orig.tar.gz 681402ef082a9aadb0ef6561b933e08c0f7cc729c4a321893f0c91f7f5d1dd2a 9234 libopenobex_1.5-1.diff.gz e9e20e47461e97a9f8b3c8ccbccec382ebc927fc5c2005e9af48debc4ec826b2 99530 libopenobex1-dev_1.5-1_amd64.deb 123216490e3de4ad9fc71bc82118d0837f6fe404163a9792056b2f9730c73211 24160 libopenobex1_1.5-1_amd64.deb 42e303f65459405b00d1711d409f760d7a8953661e821be3c018b0cb0b24 35418 openobex-apps_1.5-1_amd64.deb Files: a5d0f9596eff0c55b80b4d2dd24a15bb 1190 comm optional libopenobex_1.5-1.dsc 0d83dc86445a46a1b9750107ba7ab65c 400876 comm optional libopenobex_1.5.orig.tar.gz 37f684d85343c683b301f531cd0dc7c9 9234 comm optional libopenobex_1.5-1.diff.gz f946ce4d68dfc3ba69572f37d018c201 99530 libdevel extra libopenobex1-dev_1.5-1_amd64.deb 593d312f4ea6f4f8a2dc4dc99c4388be 24160 libs optional libopenobex1_1.5-1_amd64.deb 92c3f22847a6470705e75d04808c2e7c 35418 comm optional openobex-apps_1.5-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJmUaLVkEm8inxm9ERAhmYAJ9cya9TvqpiuzWc4+8cvYNKdkHGCACfa4Y/ wJNcNPzWmftJUNpwINM9x/w= =u0AD -END PGP SIGNATURE- Accepted: libopenobex1-dev_1.5-1_amd64.deb to pool/main/libo/libopenobex/libopenobex1-dev_1.5-1_amd64.deb libopenobex1_1.5-1_amd64.deb to pool/main/libo/libopenobex/libopenobex1_1.5-1_amd64.deb libopenobex_1.5-1.diff.gz to pool/main/libo/libopenobex/libopenobex_1.5-1.diff.gz libopenobex_1.5-1.dsc to pool/main/libo/libopenobex/libopenobex_1.5-1.dsc libopenobex_1.5.orig.tar.gz to pool/main/libo/libopenobex/libopenobex_1.5.orig.tar.gz openobex-apps_1.5-1_amd64.deb to pool/main/libo/libopenobex/openobex-apps_1.5-1_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#497304: general: packages cannot be partially installed
Am Tuesday 02 September 2008 16:01:17 schrieb Michelle Konzack: Am 2008-08-31 19:08:49, schrieb Mark Hobley: eg: coreutils depends on coreutils-fileutils and coreutils-fileutils depends on coreutils-fileutils-head, coreutils-fileutils-split This would leed into over 200.000 Binary packages... It is policy that internationalized (non-english) components are packaged separately to the core package. For example, a package foobar, would have its french documentation in a separate foobar-fr package. Packages should not install cruft on the system. This means that a package should not install a foreign language file, unless the system has been explicitly configured to support that foreign language. Hmmm, how many languages do we have? If each package is only translated into 10 languages, your wish will lead into over 15.000 additional packages. That's not what he said. If installation of language files (they can still be in the program package) could be only done for the language(s) that the user wants (many systems only will ever use one specific translation), you could reduce the installed files by many thousands. Actually nobody needs all of them but only a subset. Disc space of cheap most of the time, though. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch-Lenny upgrade mutes some/many old laptops.
Am Mittwoch, 27. August 2008 21:06:20 schrieb Sam Morris: At some time in the future it will hopefully be possible for udev(?) to get the 'missing firmware' event from the kernel; Since the firmware helper is part of udev, it already knows that the firmware is missing. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch-Lenny upgrade mutes some/many old laptops.
Am Dienstag, 26. August 2008 13:23:35 schrieb Joona Kiiski: I decided to give lenny a try and upgraded my old laptop. Everything went fine, except for some strange reason, sound didn't work. After about three hours of trial and error plus some googling, I found bug #464191 which is caused by removal of some binary-only driver from kernel. Not the driver, just the firmware. Using Google with the error message from the kernel log (escape the -2), the second entry would point you to the above bug report. Did the proposed solution from there work? While in principle I agree with the idea of avoiding all binary-only stuff, this change is going to cause much trouble for hundreds (thousands?) of upgraders and give debian some more hard to use and not beginner friendly reputation. But if you devs are so fanatic that you really can't live with some ten years old binary-only drivers in kernel (I doubt anyone is interested in writing open source replacement!), the least you can do is document this well in release notes and package those drivers in non-free/unofficial. It should be documented: yes. But what's your problem? It is the same situation as for so much other hardware like WLAN, etc. And the sound card is not even essential for booting or downloading additional software. And no need to write a driver: it is still there. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#493697: ITP: mobile-manager -- mobile manager GPRS/3G daemon
Am Freitag, 8. August 2008 19:09:14 schrieb Michelle Konzack: Am 2008-08-04 17:53:05, schrieb Hendrik Sattler: Am Montag, 4. August 2008 13:49:09 schrieb Guus Sliepen: What is missing here is whether or not mobile-manager comes with a GUI component to interact with the daemon. ...and how it can maybe interact with network-manager. There is not so much special about a GPRS/whatever device apart from the few AT chatting that handles PIN/PUK and the dial commands. The world was using pppd for that. I vote for all three working together... Does network-manager and mobile-manager allow SMS or Voice-Connect? It seems, in the next time there will be a third tool. These are kind of mutually exclusive. Some mobile GSM phones can do GSM multiplex (so SMS and data connections can work at the same time) but I don't know about a good working implementation. Voice-connection via bluetooth can be done using alsa, AFAIK, depends on the phone if this can be done in parallel. Anyway, in the best case (means capable hardware), there is no need to do this in one software. BTW: SMS functionality is better integrated in PIM software. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#493697: ITP: mobile-manager -- mobile manager GPRS/3G daemon
Am Montag, 4. August 2008 13:49:09 schrieb Guus Sliepen: What is missing here is whether or not mobile-manager comes with a GUI component to interact with the daemon. ...and how it can maybe interact with network-manager. There is not so much special about a GPRS/whatever device apart from the few AT chatting that handles PIN/PUK and the dial commands. The world was using pppd for that. I vote for all three working together... HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Include on first iso: m-a, build essential, kernel headers
Zitat von brian m. carlson [EMAIL PROTECTED]: On Wed, Jul 16, 2008 at 09:53:24PM +0200, richs wrote: I think that including headers, m-a and build essential would be a good move for the developers. Other distros have out-of-the-box non-free and proprietary apps/drivers/codecs, I would just like to see Debian offer a complete base on that first iso. At least offering the means to completely setup Debian form the get-go. Non-free (and contrib) packages are not part of Debian and are therefore not shipped on Debian CDs or DVDs. I understand your frustration with not being able to use your wireless card out of the box; I have the same problem, since my card (iwl3945) requires non-free firmware. However, the Social Contract states very clearly that only Free Software can be part of Debian. Even if the packages you request were available on the first CD, you still don't have the drivers that you would need to compile, since those are in non-free or contrib and thus aren't on the CDs. Please read the _whole_ mail! He does not request inclusion of non-free software, just the ability to compile them with packages from the first CD. The non-free data/sources come from his own media, e.g. by USB stick. A valid request, I'd say... HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please focus on one generic spell checker in Debian (Was: Bug#487732: O: ispell -- International Ispell (an interactive spelling corrector))
Am Mittwoch, 25. Juni 2008 21:53:24 schrieb Agustin Martin: Each spellchecker has currently some special features. Fortunately, the only thing where ispell is stronger than the other spellcheckers (support for pseudocharsets like 'a, a, \'a, ... ) is already included in aspell development version, so at that time we can drop ispell without any loss of features. Not sure about hunspell here. What tools are using such pseudo characters, probably because they do not support 8bit character sets? Can't they be fixed to do so? AFAIK, even latex knows the existence of the 8th bit, nowadays. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485516: ITP: o2scr -- PC/SC support for the O2Micro PCMCIA smartcard reader
Package: wnpp Severity: wishlist Owner: Hendrik Sattler [EMAIL PROTECTED] * Package name: o2scr Version : 1.0.2 Upstream Author : O2Micro Inc., Eric Piel, Jan Kiszka * URL : https://gna.org/project/o2scr * License : GPL Programming Lang: C Description : PC/SC support for the O2Micro PCMCIA smartcard reader Th o2scr source package will be split into o2scr-modules-source and libozscr. The o2scr-modules-source provides a Linux kernel driver and libozscr provides a user space library for the O2Micro PCMCIA Smartcard reader. The library implements both the CT-API and PCSC IFD handlers for use with PCSC-Lite. Initially, o2scr is based on an updated OZSCR legacy driver. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (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/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages in section python/perl simply because implemented in python/perl
Tshepang Lekhonkhobe schrieb: On Sat, May 24, 2008 at 11:22 AM, Sami Liedes [EMAIL PROTECTED] wrote: (NOTE: Am I the only one who thinks descriptions, especially short descriptions as in phenny, usually shouldn't tell what language was used to implement the program? It's just not relevant to the user.) Me agrees. Looks more of irresponsible advertising to me. Depends, I'd say. In the case of phenny, it might be relevant because extensible seems to be a core feature (probably means here: you can easily plug additional python code into it). Still the wrong section. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Should -dev packages providing .pc files depend on pkg-config?
Am Samstag 05 April 2008 schrieb Tollef Fog Heen: Whoever develops software based on libbar will have to have a call to pkg-config somewhere in their build process so they should depend on pkg-config. _If_ they do. Please consider the possibility that an application developer links to libbar without using pkg-config. pkg-config is _not_ part of an API, it is only a tool that _can_ be used, not must. Putting pkg-config on Recommends of Suggests of every -dev packages that has a .pc file, you could as well put it into built-essential dependency. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A suggestion
Am Mittwoch 02 April 2008 schrieb Chris Bannister: On Tue, Apr 01, 2008 at 03:16:48PM +0200, Andrea Bolognani wrote: On Tue, 1 Apr 2008 00:38:36 -0300 Joel Franco [EMAIL PROTECTED] wrote: I think that the testing or above releases may be suitable for the desktop of a EXPERT linux user. I need a stable release because my desktop must simply to work; it is not a so critical system like a server but this is critical to my business go on. From my experience, testing is perfectly suitable for a desktop/development system. I have used it exclusively on both my desktop and my laptop for a couple of years now, and I have experienced only a couple of minor issues so far. The main difference between a desktop and a server is that usually on a server you can't afford any downtime, while on a desktop system you can screw up and reinstall every once in a while if needed... Unfortunately, many people new to Debian/Linux get the impression that testing is perfectly suitable for a desktop system. It really depends on the person(s) using that desktop. But your wording is black or white anyway (see: perfectly). HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adding lzma to dpkg's Pre-Depends
Am Mittwoch 02 April 2008 schrieb Mike Bird: On Wed April 2 2008 01:52:39 Steve Langasek wrote: On Wed, Apr 02, 2008 at 10:24:43AM +0200, Lucas Nussbaum wrote: The results are a bit misleading, because they compare the absolute gain. It's the absolute size savings that counts - that's what's going to have the biggest impact on mirror size, mirroring time, CD set size, and download times for users. Lucas made a good point. Better to save 20% on ten 10MB packages than saving 10% on one 100MB package. Although we can probably have both, modulo decompression RAM issues. Well, oo.org probably needs the same amount of RAM to actually run, so it's not an issue, there. That not the case for the libgl1-mesa-dri but probably for programs that use OpenGL . So the consideration should always include what effect this actually has for the users of that package. No question that for Oo.org this is pure gain. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libopenobex 1.3+cvs20070425-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 14 Mar 2008 20:55:35 +0100 Source: libopenobex Binary: libopenobex1-dev libopenobex1 openobex-apps Architecture: source i386 Version: 1.3+cvs20070425-2 Distribution: unstable Urgency: low Maintainer: Hendrik Sattler [EMAIL PROTECTED] Changed-By: Hendrik Sattler [EMAIL PROTECTED] Description: libopenobex1 - OBEX protocol library libopenobex1-dev - OBEX protocol library - development files openobex-apps - Applications for OpenOBEX Closes: 470441 470444 Changes: libopenobex (1.3+cvs20070425-2) unstable; urgency=low . * patches/compat_defines.patch: reintroduce defines OBEX_CLIENT and OBEX_SERVER (closes: #470441, #470444) Files: 8613a2bc67ee4c608b692976e4e6e352 833 comm optional libopenobex_1.3+cvs20070425-2.dsc 62224107813bd4ed3201d72158c49418 27902 comm optional libopenobex_1.3+cvs20070425-2.diff.gz d09217bd715f670279f71df25feb9762 57416 libdevel extra libopenobex1-dev_1.3+cvs20070425-2_i386.deb ca5e064b93ec40c2d25ce4c6fae24cac 21678 libs optional libopenobex1_1.3+cvs20070425-2_i386.deb 1db895aadf75249ea0b338ab0474f53d 33362 comm optional openobex-apps_1.3+cvs20070425-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH25sEVkEm8inxm9ERAhZ3AJ4wK6VzGtCJlzUvu3qTdjV7BdA8WQCfVyg9 TBWEFO52U5kFl1MzXdqjDXU= =9HPK -END PGP SIGNATURE- Accepted: libopenobex1-dev_1.3+cvs20070425-2_i386.deb to pool/main/libo/libopenobex/libopenobex1-dev_1.3+cvs20070425-2_i386.deb libopenobex1_1.3+cvs20070425-2_i386.deb to pool/main/libo/libopenobex/libopenobex1_1.3+cvs20070425-2_i386.deb libopenobex_1.3+cvs20070425-2.diff.gz to pool/main/libo/libopenobex/libopenobex_1.3+cvs20070425-2.diff.gz libopenobex_1.3+cvs20070425-2.dsc to pool/main/libo/libopenobex/libopenobex_1.3+cvs20070425-2.dsc openobex-apps_1.3+cvs20070425-2_i386.deb to pool/main/libo/libopenobex/openobex-apps_1.3+cvs20070425-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Notice spam
Am Montag 10 März 2008 schrieb Adam Borowski: Please, if a package you maintain emits spam like this is free or such when not asked, consider fixing this annoyance. And consider that most of the software also runs on other systems, even Windows. HS
Accepted libopenobex 1.3+cvs20070425-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 06 Mar 2008 00:28:42 +0100 Source: libopenobex Binary: libopenobex1-dev libopenobex1 openobex-apps Architecture: source i386 Version: 1.3+cvs20070425-1 Distribution: unstable Urgency: low Maintainer: Hendrik Sattler [EMAIL PROTECTED] Changed-By: Hendrik Sattler [EMAIL PROTECTED] Description: libopenobex1 - OBEX protocol library libopenobex1-dev - OBEX protocol library - development files openobex-apps - Applications for OpenOBEX Closes: 416259 465262 Changes: libopenobex (1.3+cvs20070425-1) unstable; urgency=low . * Updated to current CVS (since CVS did not change in 9 months): - Adds new TcpOBEX (IPv6 support) * Remove patches: - docbuild2.patch: not needed anymore - pkgconfig.patch: not needed anymore * debian/control: - use libbluetooth-dev instead of libbluetooth2-dev - do not require libbluetooth-dev on kfreebsd-* (closes: #416259) * debian/rules: fix cross-build support (closes: #465262) * debian/copyright: add proper copyright information * debian/openobex-apps.copyright: removed Files: 26ee090f25314e5f2657a9c2cc50482c 833 comm optional libopenobex_1.3+cvs20070425-1.dsc 67c4dac9534343aeffc6522bbc66336d 367697 comm optional libopenobex_1.3+cvs20070425.orig.tar.gz b7107d12c552061413b6be19108790e0 27625 comm optional libopenobex_1.3+cvs20070425-1.diff.gz 48c28432c86d95d039a6907b3c49e00f 57344 libdevel extra libopenobex1-dev_1.3+cvs20070425-1_i386.deb b0104c7c72016ba861af9e8ec717b9e2 21590 libs optional libopenobex1_1.3+cvs20070425-1_i386.deb 846a4864b333a4626f91f9903cf4aade 33270 comm optional openobex-apps_1.3+cvs20070425-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH0+U9VkEm8inxm9ERAp5SAJ9e4qG+BtepDBLZx3mctz7EY+lmhACfXRvy gYTq7EjFk8L6fx86AiR0/G4= =O5Bp -END PGP SIGNATURE- Accepted: libopenobex1-dev_1.3+cvs20070425-1_i386.deb to pool/main/libo/libopenobex/libopenobex1-dev_1.3+cvs20070425-1_i386.deb libopenobex1_1.3+cvs20070425-1_i386.deb to pool/main/libo/libopenobex/libopenobex1_1.3+cvs20070425-1_i386.deb libopenobex_1.3+cvs20070425-1.diff.gz to pool/main/libo/libopenobex/libopenobex_1.3+cvs20070425-1.diff.gz libopenobex_1.3+cvs20070425-1.dsc to pool/main/libo/libopenobex/libopenobex_1.3+cvs20070425-1.dsc libopenobex_1.3+cvs20070425.orig.tar.gz to pool/main/libo/libopenobex/libopenobex_1.3+cvs20070425.orig.tar.gz openobex-apps_1.3+cvs20070425-1_i386.deb to pool/main/libo/libopenobex/openobex-apps_1.3+cvs20070425-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#466939: ITP: hex2bin -- Converts Motorola and Intel Hex files to binary
Am Freitag 22 Februar 2008 schrieb Uwe Hermann: On Fri, Feb 22, 2008 at 02:11:44PM +1100, Hamish Moffatt wrote: On Fri, Feb 22, 2008 at 12:04:19AM +0100, Uwe Hermann wrote: Package: wnpp Severity: wishlist Owner: Uwe Hermann [EMAIL PROTECTED] * Package name: hex2bin Version : 1.0.6 Upstream Author : Jacques Pelletier [EMAIL PROTECTED] * URL : http://sourceforge.net/projects/hex2bin/ * License : GPL Programming Lang: C Description : Converts Motorola and Intel Hex files to binary Converts Motorola and Intel Hex (*.hex or *.ihx) files to binary. FWIW, you can do this with the srecord package. Despite the name, it reads and writes a bunch of hex formats and binary, and can convert between them and apply various other transformations (address shift, byte swapping) etc. Note that I'm not objecting to your ITP, only proposing an existing solution. hex2bin might be simpler to use, although it could probably be implemented as a simple wrapper script on-top of srecord, and packaged with it. You can do a hex to binary conversion with: srec_cat infile -Intel -output outfile -Binary Yep, I'm aware of srecord, but bin2hex is indeed a bit more simple. One of the reasons why I want to package it is that many (AVR) Makefiles out there use it to convert *.hex files to *.bin and thus break on Debian as we don't yet have bin2hex. Sure, they can be fixed to use srecord, but having hex2bin in the archive (and not having to modify external scripts/Makefiles) is still worthwhile, IMO. Did you read the part with the wrapper script? The binary names are way to generic, too (just as the package name). HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for comment: a new software to manage linux networking features
Am Sonntag 17 Februar 2008 schrieb namnd: In this case, the configuration is as easy as: interface name=fpt1 type=ppp ppp type=pppoe options= depend_on=tap1 username=*** password=***/ network id=11 name=FPT1 auto=1/ /interface The ppp stanza should not contain authentication information. Especially since username/password only covers the most simple authentication method. And other parts could use a auth tag, too (ethernet, wlan, etc.). Additionally, the options attribute sounds like a work-around. HS
Re: List of packages shipping shell scripts with bashisms + MBF proposal
Am Sonntag 10 Februar 2008 schrieb Ralf Wildenhues: BTW, no matter what POSIX says, named signals are not portable to pre-POSIX shells, which is why Autoconf and Libtool do not use them. POSIX may not apply to pre-POSIX shells. So what? Creating a standard is not always a method to documenting the current way of doing things. Thus, implementations before the standard can differ from it. At one point you have to go on and ignore ancient systems. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: ITP: latencytop -- A tool for developers to visualize system latencies
Quoting Fathi BOUDRA [EMAIL PROTECTED]: * Package name: latencytop Version : 0.3 Upstream Author : Arjan van de Ven [EMAIL PROTECTED] * URL : http://www.latencytop.org/ * License : GPL-2 Description : A tool for developers to visualize system latencies LatencyTOP is a Linux tool for software developers (both kernel and userspace), aimed at identifying where system latency occurs, and what kind of operation/action is causing the latency to happen. By identifying this, developers can then change the code to avoid the worst latency hiccups. short description: tool for developers to visualize system latencies Or just visualize system latencies. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Qt/KDE team
Am Freitag 11 Januar 2008 schrieb RalfGesellensetter: Hi all happy new [EMAIL PROTECTED] Am Donnerstag 10 Januar 2008 schrieb Armin Berres: The plan is to use ~/.kde for KDE 3 and for KDE 4. We patched KDE 4 right now **Objection** Using KDE (now 3.5.7) within a larger rollout (educational environment), we already had problems with the current versions of KDE 3.5.x when switching between workstations with different subversions: For instance, quite often kicker disappeared (at least the window bar). Please take note, that there is some hundred thousands of pupils using KDE at school, whereas their home directory is centrally stored. I'd plea to follow the policy of openoffice.org by tagging conf folders with versions: ~/.kde3-57 ~/.kde3-58 ~/.kde4-00 Whenever a program fails to find conf files for its very version, it needs to fall back to the latest available version and import settings at its best. This keeps older versions to be used from worksstations that had not been updated yet. This ain't no good: changes in an older KDE will not show up in a newer KDE. Fact is that there should be an absolutely strict policy about changes that affect older versions: - ignore unknown options - ignore unknown option values (use default instead but do not change the value in the config file) - never change meaning of options If it is totally incompatible then another filename should be used. A global versioning is insufficient. OTOH: using a mixed setup in a network _always_ gets you into trouble one way or the other. HS signature.asc Description: This is a digitally signed message part.
