Bug#986830: ITP: sscg -- simple SSL certificate generator
Package: wnpp Severity: wishlist Owner: Martin Pitt * Package name: sscg Version : 2.6.2 Upstream Author : Stephen Gallagher * URL : https://github.com/sgallagher/sscg/ * License : GPL-3+ with OpenSSL exception Description : sscg is a utility to aid in the creation of more secure "self-signed" certificates. The certificates created by this tool are generated in a way so as to create a CA certificate that can be safely imported into a client machine to trust the service certificate without needing to set up a full PKI environment and without exposing the machine to a risk of false signatures from the service certificate. See this blog post for details: https://sgallagh.wordpress.com/2016/05/02/self-signed-ssltls-certificates-why-they-are-terrible-and-a-better-alternative/ Cockpit's web server makes use of sscg if it is available, as a slightly better alternative than direct self-signed certificates. CC'ing upstream author Stephen for questions about the functionality. I recently sent the Debian packaging to the upstream project, where it will run in CI for each PR: https://github.com/sgallagher/sscg/pull/22 Thanks, Martin signature.asc Description: PGP signature
Bug#985768: ITP: cockpit-machines -- Cockpit user interface for virtual machines (source splitout from cockpit)
Package: wnpp Severity: wishlist Owner: Martin Pitt * Package name: cockpit-machines Version : 241 Upstream Author : Cockpit development team * URL : https://github.com/cockpit-project/cockpit-machines/ * License : LGPL-2.1+ Description : The Cockpit Web Console enables users to administer GNU/Linux servers using a web browser. . This package adds an user interface for managing virtual machines. . If the "virtinst" package is installed, you can also create new virtual machines. This has existed as a binary package [1] built from the cockpit source [2] for quite some time already. For various reasons split out this component into a separate project [3], and will remove it from cockpit.git soon. This is similar to cockpit-podman [4]. The first upstream release 241 [5] is a clean code copy. This provides a clean upgrade path from the last official cockpit release 240 which still built -machines. As such I hope to get it into experimental relatively soon, so that uploading new cockpit releases don't get blocked for too long. Thanks, Martin [1] https://packages.debian.org/sid/cockpit-machines [2] https://tracker.debian.org/pkg/cockpit [3] https://github.com/cockpit-project/cockpit-machines/ [4] https://tracker.debian.org/pkg/cockpit-podman [5] https://github.com/cockpit-project/cockpit-machines/releases/tag/241 signature.asc Description: PGP signature
Bug#939054: O: editmoin -- edit MoinMoin wiki pages with your favourite editor
Package: wnpp I haven't used editmoin myself for many years, and the upstream project has been dead for even longer than that. I'm not even sure any more how well it works on recent moinmoin setups. The biggest issue right now is porting it to Python 3 (https://bugs.debian.org/936466). If nobody is interested in adopting this package, I suggest to just remove it from bullseye/sid. Packaging-wise, this is in a good shape. salsa git+gbp+dh, etc. Package: editmoin Version: 1.17-4 Installed-Size: 51 Maintainer: Martin Pitt Architecture: all Depends: python:any Recommends: sensible-utils Suggests: vim-addon-manager Description-en: edit MoinMoin wiki pages with your favourite editor editmoin allows you to edit pages in MoinMoin wikis with your preferred editor instead of the (usually quite limited) web browser text areas. . It also supports configuration files to define shortcuts for URLs that you edit often. . This package also includes a Vim syntax file. Install vim-addon-manager and use "vim-addons install editmoin" to activate. . However, you can use any other editor by setting the standard $EDITOR environment variable. Thanks, Martin signature.asc Description: PGP signature
Re: Debian Buster release to partially drop non-systemd support
Petter Reinholdtsen [2018-10-16 15:55 +0200]: > [Benda Xu] > > I was about to reply to this thread, but you have completely expressed > > what I want to say: > > > > 1. systemd-shim is not necessary, even for DEs (except GNOME3). > > 2. sysvinit-core is very stable and do not need new uploads. > > Thank you for expressing so well the cause of the fate for sysvinit in > Debian. It seem clear its proponents believe everything is OK and no > effort is needed to save sysvinit. If this continues, sysvinit in > Debian will continue to rot and end up being removed. > > I know from maintaining the sysvinit set of packages that it require > work to maintain them. There are hundreds of open bugs against the > sysvinit packages in Debian already. It's not only that. The sysvinit package *itself* doesn't actually do much really. That's not to downplay your past involvement there of course (e. g. developing insserv alone was a huge task), but the *real* maintenance is in all the packages that *ship* SysV init scripts. SysV init leaves all the really hard problems to these, as it cannot really do much by itself. That's a fact that people that keep yelling "but SysV init was so easy!" keep finessing.. So "how many RC bugs does sysvinit have" is a completely useless metric IMHO. Martin
Re: Announce: docker-buildpackage
Chow Loong Jin [2018-05-03 12:27 +0800]: > On Wed, May 02, 2018 at 11:23:56AM +0200, Thomas Goirand wrote: > > [...] > > Frankly, I don't see the point in writing this kind of software. Sbuild > > works super well with the overlay backend, and already has throw-able > > chroots in tmpfs. Adding docker into this doesn't add any new feature, > > and in some way, is less flexible than the already existing sbuild. > > Something that comes to mind is network isolation, which sbuild still > doesn't seem to have proper support[1] for: > > [1] > https://wiki.debian.org/sbuild#Disabling_network_access_for_dpkg-buildpackage Not just network, but also process isolation and reducing privileges. schroot would be way too "leaky" for a production CI system like ci.debian.net or autopkgtest.ubuntu.com. The existing backend that compare much better to that are -lxc and -lxd, and IMHO they are superior to docker. lxc and lxd are "full OS" containers while docker is optimized for application containers and thus needs some special treatment (like --privileged, which makes the whole thing rather unsafe and often causes crashes if you try to start udev in the docker container) to allow really booting a full OS. Usability wise, they are just as simple as docker too, as linuxcontainers.org has a lot of pre-built OS images for all kinds of OSes. So I agree that there is very little point about adding a docker backend other than "it's possible" (albeit inferior). As long as someone wants to maintain it, there is little harm in including it. Martin signature.asc Description: PGP signature
Re: Announce: docker-buildpackage
Hello Ian, all, Ian Jackson [2018-05-01 18:59 +0100]: > > https://salsa.debian.org/ci-team/autopkgtest/merge_requests/3 > > Oh, excellent. It looks like it's awaiting a re-review from Martin. Reviewed now. > Martin, will you get to this soon, or would you like me to look at it > and maybe merge it ? (You may need to give me some permission in > salsa for that...) Oh, does reviewing/commenting require that? Anyway, I was about to add you as a project member, but 18 hours ago someone already did that. Martin
Bug#864816: ITP: volume-key -- library and utility for manipulating storage encryption keys and passphrases
Package: wnpp Severity: wishlist Owner: Martin Pitt * Package name: volume-key Version : 0.3.9 Upstream Author : Miloslav Trmač https://releases.pagure.org/volume_key/ * License : GPL-2+ Programming Lang: C Description : Library/utility for manipulating storage encryption keys and passphrases This package provides libvolume_key, a library for manipulating storage volume encryption keys and storing them separately from volumes. The main goal of the software is to allow restoring access to an encrypted hard drive if the primary user forgets the passphrase. The encryption key back up can also be useful for extracting data after a hardware or software failure that corrupts the header of the encrypted volume, or to access the company data after an employee leaves abruptly. This is a build/binary dependency of the ITP'ed libblockdev [1] which in turn is a new dependency of upcoming udisks [2]. I know that the package names is less than ideal - one usually thinks about buttons to control the audio volume. If there's demand, I'm okay with changing the source package name to storage-volume-key, but the binary names need to (and should) match the upstream library/soname and thus can't be prefixed; so I don't think it's worth bothering. If anyone else is interested, co-maintenance is highly welcome and appreciated! Thanks, Martin [1] https://bugs.debian.org/862776 [2] https://github.com/storaged-project/udisks/pull/260 signature.asc Description: PGP signature
Bug#864815: ITP: libbytesize -- library for common operations with sizes in bytes
Package: wnpp Severity: wishlist Owner: Martin Pitt * Package name: libbytesize Version : 0.10 Upstream Author : Vratislav Podzimek URL : https://github.com/rhinstaller/libbytesize * License : LGPL-2.1+ Programming Lang: C Description : Library for common operations with sizes in bytes Many projects need to work with sizes in bytes (be it sizes of storage space, memory,...) and all of them need to deal with the same issues like: * How to get a human-readable string for the given size? * How to store the given size so that no significant information is lost? * If we store the size in bytes, what if the given size gets over the MAXUINT64 value? How to interpret sizes entered by users according to their locale and typing conventions? * How to deal with the decimal/binary units (MB vs. MiB) ambiguity? This library aims to be as much generally usable as possible, small, fast and be easily interfaced from other languages. This is a build/binary dependency of the ITP'ed libblockdev [1] which in turn is a new dependency of upcoming udisks [2]. If anyone else is interested, co-maintenance is highly welcome and appreciated! Thanks, Martin [1] https://bugs.debian.org/862776 [2] https://github.com/storaged-project/udisks/pull/260 signature.asc Description: PGP signature
Bug#862776: ITP: libblockdev -- library for manipulating block devices
Package: wnpp Severity: wishlist Owner: Martin Pitt * Package name: libblockdev Version : 2.6 Upstream Author : Vratislav Podzimek URL : https://github.com/rhinstaller/libblockdev * License : GPL-2+ Programming Lang: C Description : Library for manipulating block devices libblockdev is a C library supporting GObject introspection for manipulation of block devices. It has a plugin-based architecture where each technology (like LVM, Btrfs, MD RAID, Swap,...) is implemented in a separate plugin, possibly with multiple implementations (e.g. using LVM CLI or the new LVM DBus API). This will soon be used by udisks [1], see that PR for details of the rationale. In short, this will replace the coarse/brittle command line tool interfacing with a proper library which will also be used in different storage management related tools. Peter and Andreas did the brunt of the packaging at [2], I'll give it a review and some fine-tuning soon. This will be maintained under the Utopia umbrella, the project which already maintains udisks, upower, libatasmart, and other hardware related plumbing stack parts. If anyone else is interested, co-maintenance is highly welcome and appreciated! Thanks, Martin [1] https://github.com/storaged-project/udisks/pull/260 [2] https://github.com/rhinstaller/libblockdev
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
Hello all, Scott Kitterman [Fri, 13 Jan 2017 13:54:26 -0500] > Probably the simplest way to avoid problems with systems like this is to > remove any autopkg tests your packages are shipping. > > P.S. Perverse incentives FTW. No, that won't work at all. If you upload libfoo which regresses a reverse dependency bar and bar's tests now fail, then removing libfoo's autopkgtests won't help you *at all* in landing the new libfoo in testing. You'd need to convince bar's maintainer to change/drop the test. The carrot for adding tests is that the better they are, the harder you make it for *other people* (i. e. your dependencies) to break your software. The stick is that you then of course need to make/keep your own tests running so that you can upload new versions of libfoo yourself. So IMHO the incentives are quite right here. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
Hello all, (I'm not subscribed, thus hand-crafting In-Reply-To:; please keep CC'ing me on replies). Ole Streicher [Fri, 13 Jan 2017 15:57:09 +0100] > Will there be a way to override this for the maintainer? Otherwise I > would see the danger that a buggy reverse dependency CI test can prevent > an important update, for example if the reverse dependency uses a long > deprecated function that is now removed. If you upload a new version of a library that removes a symbol, then all reverse dependences must get fixed in or removed from testing anyway. In this scenario the new lib would already not propagate as the rdepends would FTBFS in the binNMU against the new library SONAME (assuming that you did bump it). OTOH, if you did not bump the SONAME, then this is an RC bug anyway which then gets caught by the test. For other scenarios which aren't already caught by britney's installability checks (change in behaviour which doesn't reflect in changed ABI) we actually do want the same: If we can catch a regression through a test, then it makes zero sense to automatically land that regression in testing anyway -- the whole point of this exercise is to allow us to land transitions with confidence and sort out transitions in unstable *before* landing regressions in testing. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Re: ifupdown2: debconf followup
On Mon, 1 Aug 2016 12:40:37 +0200, Adam Borowski wrote: > On Mon, Aug 01, 2016 at 12:31:14PM +0200, Marco d'Itri wrote: > > We should also think hard about switching to a new default since > > currently many other major distributions are moving to NetworkManager > > and/or systemd-networkd (which nowadays is usable, works well for > > simpler use cases and will be installed on every Debian system anyway). > > For the latter, "installable only with a certain init implementation, and > not portable to any kernel but Linux" doesn't say "every Debian system" to > me. For the record, networkd does *not* depend on systemd as pid 1, it happily works even in our initramfs without any (real) init. However, it *is* Linux specific as it uses/offers Linux specific network device types and uses Linux API like epoll(). Martin P.S. Sorry if I broke the thread, hand-crafted In-Reply-To:. Please CC: me, I'm not on the list. -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#832508: O: systemd-shim -- SysVinit shim for systemd
Package: wnpp Neither Steve nor I still have any interest in maintaining systemd-shim. Debian's default init system is systemd, Ubuntu supports nothing else any more (and does not even have systemd-shim any more), upstart is gone from both Debian and Ubuntu, so the only use case for it right now is running Debian with SysVinit (in particular, on non-Linux flavors). So this should be picked up by someone who is interested in keeping SysV init support for desktops (i. e. which need logind or timedatectl) alive in Debian. There are currently no release-critical bugs and the package is working reasonably well for main use cases, but there *are* a few bugs worth looking into. The upstream branch is currently at <https://github.com/desrt/systemd-shim/>. Allison isn't interested any more in this either, so I suggest that the upstream repo gets mothballed and systemd-shim just becomes a Debian-native package (I'm not aware of any other distro using it anyway). Note that systemd-shim currently uses cgmanager, which by itself is obsolete [1]. Package description: Description: shim for systemd This package emulates the systemd function that are required to run the systemd helpers without using the init service Martin [1] https://s3hh.wordpress.com/2016/06/18/whither-cgmanager/ -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: PGP signature
Re: Bug#827705: dependency loop between initscripts and sysvinit-utils causes dist-upgrade failure
Control: tag -1 pending Hello Michael, Michael Biebl [2016-06-20 0:59 +0200]: > The issue being that /lib/init/vars.sh has been moved from initscripts > to sysvinit-utils. > sysvinit-utils got a Breaks/Replaces: initscripts (<< 2.88dsf-59.5) for > that. > On the other hand, the initscripts has got a dependency on > sysvinit-utils (>= 2.88dsf-59.5) to ensure /lib/init/vars.sh is available. > > As mentioned, dropping the Breaks should break the loop. I can reproduce the upgrade failure in a schroot, this is indeed very similar to the util-linux vs. sysvinit upgrade problem that we had some weeks ago. Similar to what we did back then, I also see no other option than dropping the Breaks:. This will break carefully crafted downgrade scenarios, but if you do these you are already on your own anyway.. I verified that upgrading from jessie to unstable plus a local apt repo without the Breaks: works fine, so I committed this: http://anonscm.debian.org/cgit/collab-maint/sysvinit.git/commit/?id=f1acba82 I'll 0-day NMU this now, as it got introduced by my previous NMU and fixes an RC bug. Thanks and sorry for the trouble, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: PGP signature
Re: Proposal v2: enable stateless persistant network interface names
Hey Benjamin, Benjamin Drung [2015-06-25 12:44 +0200]: > How about adding a easy-to-type symlink for MAC named devices? Would > that work? Then users could refer to a device by the persistent MAC name > enx112233445566, but also could use a short name like eth2 (which might > not be persistent). > > It would be similar to hard drives. I used UUIDs in /etc/fstab, but > short names like /dev/sdb3 when calling mount on the command line. Unlike /dev nodes, network interfaces can't have aliases as far as I know. Am I missing anything? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: Proposal v2: enable stateless persistant network interface names
Vincent Danjean [2015-06-03 12:43 +0200]: > So, you can show a debconf note, try (or not) to migrate the file > automatically, remove (or comment-out) the 70-persistent-net.rules, > or ... but, please, do not write a preinst script that fails > because the admin did not update its config before upgrading. Fair enough. We can just point out that this is an unsupported configuration in stretch+2. There is no way we can reliably migrate the whole system. > One "good" solution would probably a new kind of scripts run > by dpkg and apt *prior to any other things* (for all involved > packages) to decide if the upgrade can run or not. But that > would involve lots of change in apt/dpkg and I'm sure I do not > oversee all the implications of such a proposal. Indeed, and this should probably also happen at a higher level (like Ubuntu's release-upgrader, which has extra pre/post hooks). Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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/20150604093701.gb3...@piware.de
Re: Proposal v2: enable stateless persistant network interface names
Martin Pitt [2015-06-03 12:01 +0200]: > | $ cat /lib/systemd/network/01-mac-for-usb.link > | [Match] > | Path=*-usb-* > | > | [Link] > | NamePolicy=kernel database mac onboard slot path > | MACAddressPolicy=persistent Sorry, that was an old version. We want this: NamePolicy=kernel database onboard mac I. e. prefer onboard names over mac, and never use slot/path based names for USB; the latter will hardly make a practical difference, but it's cleaner that way. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Proposal v2: enable stateless persistant network interface names
Hello all, some 4 weeks ago I sent a first proposal to change persistent network interface naming away from our current /lib/udev/rules.d/75-persistent-net-generator.rules (which is inherently racy and doesn't apply to all virtualized environments) to udev's "net.ifnames": https://lists.debian.org/debian-devel/2015/05/msg00170.html Thanks to the comments and followups! Based on that I updated the proposal. (Sorry for the delay..) Martin Pitt [2015-05-08 7:59 +0200]: > Details about [ifnames] > --- > This is a generic solution which extends the [biosdevname] idea and > thus applies to all practical cases and all architectures. It doesn't > need any persistant state (i. e. dynamic /etc/udev/rules.d/) and thus > applies nicely to snappy/touch, and also avoids the race condition. > > The main downside is that by nature the device names are not familiar > to current admins yet. For BIOS provided names you get e. g. ens0, for > PCI slot names enp1s1 (ethernet) or wlp3s0 (wlan). But that's a > necessary price to pay (biosdevname names look similar). The main objection in the discussion was that path based names aren't appropriate for USB based devices. I agree, so I change my proposal to use MAC based names for anything USB based. The names will look even worse as they include the MAC in hex (enx112233445566), but the two goals "use MAC for these devices", "don't maintain state files in /etc", and "avoid any collisions" don't leave room for much else. However, on a desktop you don't ever care about the device names, and higher-level firewall tools will also hide this. After all, we survived the step from /dev/sda1 to UUID=112233DEADBEEF... as well :-) > Proposal > > I propose to retire [mac], i. e. drop > /lib/udev/rules.d/75-persistent-net-generator.rules and enable > [ifnames] by default. Amendment: ... and ship a naming policy by default which uses MAC based names for USB. FYI, this will look like | $ cat /lib/systemd/network/01-mac-for-usb.link | [Match] | Path=*-usb-* | | [Link] | NamePolicy=kernel database mac onboard slot path | MACAddressPolicy=persistent It's easy enough to override/customize, see man systemd.link. (Despite the name, this is all udev; it doesn't depend on using systemd or networkd). This will of course also be included in the documentation. > For upgrades: As we don't know what refers to existing stable network > names, we can't ever safely remove a generated > /etc/udev/rules.d/70-persistent-net.rules. So when we do the above, > names on existing installations will *not* change (as > 70-persistent-net.rules trumps [ifnames]). > > So we can only let time and replacing/reinstalling machines take care > of this. Michael Biebl and I discussed that the other day. We plan to do that in steps: stretch: - Enable ifnames for new installations - Drop [mac] generator - Point out the transition/documentation in NEWS - Ship example rules to show how to use your own custom names stretch+1 (or maybe +2): - Check existance/non-emptiness of /etc/udev/rules.d/70-persistent-net.rules in udev.preinst, Show critical debconf note, and refuse to upgrade - Drop our hack to retry renames for a while (to mitigate the race) Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: Proposal: enable stateless persistant network interface names
Hello, Karsten Merker [2015-05-11 20:22 +0200]: > >From what Ben Hutchings has described in > <1431294933.2233.66.ca...@decadent.org.uk>, the race condition > could easily be avoided with the current codebase by simply not > using "eth" as the prefix, but e.g. "en". Right, that would solve one problem, but not the others. > Could you explain why the existing code does not provide stable > names in virtual machines? As long as the virtual ethernet > controller keeps the same MAC address over time (which I believe > to be the normal case), I see no reason why the existing codebase > should not provide stable names in a VM in the same way it does > on physical hardware. I'm afraid you have to ask folks more familiar with clouds about the "why", but it seems MAC addresses change all the time there as with every new instance or even boot you get a different virtual ethernet card assigned. See all the reports that we are getting about adding entries to the blacklist. > As "slot" has been shown to be not really stable for a number of > use cases (even for PCI, see above), I think that "mac" is the > only way that works for all cases. It clearly doesn't work for "all cases", like replacing network cards (in physical servers, but this is what by and large happens in clouds too), or where you have to rely on the location of cards instead of their MACs (like running the same config on a rack of servers, where what you see, wire, and configure are port locations). Anyway, I do see that we want to use MAC addresses by default for at least USB. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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/20150512041237.gb3...@piware.de
Re: Proposal: enable stateless persistant network interface names
Hey Marco, Marco d'Itri [2015-05-11 5:53 +0200]: > I am not sure that we really need to retire 75-persistent-net-generator > right now: the annoying part to maintain is the kernel patch which we > will need anyway for at least a couple of releases Which kernel patch? I think all of this ought to work on a vanilla kernel. > It is trivial to make it opt-in by setting something like > net.ifnames=0 (or even a different and specific value), and we can > revisit this decision when we will be closer to the release. Yes, that will be the case once we drop the Debian specific Make-net.ifnames-opt-in-instead-of-opt-out.patch . > Actually it requires us to keep maintaining the > Revert-udev-network-device-renaming patch as long as there will be > systems with a 70-persistent-net.rules file renaming eth* to eth*. Argh, that's true. I. e. another decade or so :/ > Maybe biosdevname would be nice to have, but: > [...] > So I do not think that we need to care about it. Full ack. ifnames does everything biosdevname does and is both more universal and also more flexible to configure, so there is absolutely zero reason to introduce biosdevname now. It's mostly a backwards compatibility problem for systems which already have it installed (i. e. not pure Debian). > An obvious downside is longer names for devices which do not provide > ID_NET_NAME_ONBOARD: e.g. the WiFi card in my Dell laptop does > not (wlp2s0), but the Ethernet port does (eno1). > It will be even worse when not even ID_NET_NAME_PATH is defined (e.g. on > my Allwinner-based ARM computer), which means that interfaces will get > a mac-based name like enx028909xx. Remember, MAC based names aren't used with the default policy, you have to opt-in. Although it might happen that we do configure this by default for USB devices in the Debian policy, see the other parts of the thread. Thanks! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: Proposal: enable stateless persistant network interface names
Hey Paul, Paul Wise [2015-05-09 16:15 +0800]: > Is there a tool to list interfaces based on their characteristics? > Right now at $work our initial setup code does glob eth* in > /sys/class/net in order to setup a bond interface using all NICs, so > network works no matter which NIC one plugs a cable into. It sounds > like this proposal would break that, so we would need a way to list > all Ethernet interfaces but not the bond interface and not any USB > network interfaces etc. en* should be the equivalent with ifnames (but not with biosdevname!). Wifis are called wl*, and virtual interfaces like vlans, bridges, bonds, etc. are assigned by the admin (or at least not by the kernel and udev) anyway. However, I don't know how USB ethernet interfaces look like (neither in the kernel driver nor with ifnames). Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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/20150509094446.gc3...@piware.de
Re: Proposal: enable stateless persistant network interface names
Bjørn Mork [2015-05-08 16:13 +0200]: > PCI buses can be and are hotplugged, similar to network devices. Yes, that's certainly a valid point. It's not unanimously clear how you define the "identity" of an interface, whether it's more like "by location" or "by MAC address". There are pros and cons for either POV. Karsten Merker [2015-05-08 18:31 +0200]: > while this probably works resonably well for (semi-)fixed devices > like onboard-NICs and PCI/PCIe cards, it results in a completely > unsuitable behaviour with pluggable devices such as USB network > adapters. TBH, hotpluggable USB network adapters which change all the time sound like a corner case in a server world where you have hand-written config files referring to interface names. They are of course common on the client side, but there stable interface names don't matter at all. But see below. peter green [2015-05-09 8:49 +0100]: > The "path based names" use the PCI bus number as their "root". PCI bus > numbers are dynamically allocated as the bios enumerates the busses. PCI bus and slot numbers are stable across reboots, unless of course you physically change the cards (what Bjørn raised above). So, there's obviously two schools of thoughts here. Some people think in terms of MAC addresses, which breaks if you replace a broken or outdated card with a new one. Some people think in terms of location, like "the left port goes to the internet, the right port to the intranet", and there is absolutely nothing wrong with that either; in that scenario you can replace a network card, but keep the cables etc, and everything will still work. I don't want to get down into philosophical questions whether rearranging the hardware in your server should or shouldn't be considered an identical configuration still, as that's just bikeshedding and we'll never find 100% consensus there. Neither MAC or location based stable names are flawless; the above show pitfalls of location based ones, the whole cloud story (or replacing faulty hardware) shows that MAC addresses are totally unsuitable in common situations. But what I do want to get rid of is the current 70-persistent-net-names.rules which have the inherent race condition and have no configurability at all; and it provides no stable interface names for any virtualized environment. With ifnames you can always choose your own policy (see man systemd.link), and e. g. say "NamePolicy=onboard mac" if you so prefer. We can even discuss preferring "mac" over "slot" by default (although I personally think that would be a worse default). One could even default to "mac" for USB based hardware and the default (kernel database onboard slot path) for others [1]. Martin [1] I don't have USB-ethernet devices myself; if you have one, please get in touch with me, I'd like to investigate how they look like in udev, and what "udevadm test /sys/class/net/ |grep NAME" says about these. -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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/20150509092614.gb3...@piware.de
Re: Proposal: enable stateless persistant network interface names
Hello Konstantin, Konstantin Khomoutov [2015-05-08 13:08 +0300]: > Is it possible to provide a tool (a shell script?) that would print out > the new would-be name of the interface provided by the user so that it > would be possible to migrate remote systems only accessible via SSH? The closest thing to that would be something like this: $ sudo udevadm test /sys/class/net/wlan0 |grep ID_NET_NAME_ ID_NET_NAME_MAC=wlxa44e31848d2c ID_NET_NAME_PATH=wlp3s0 As I wrote the _MAC name isn't used by default (this has to be enabled explicitly, and it's a bit unwieldy); the default policy is to use the first existing variable in ID_NET_NAME_ONBOARD, ID_NET_NAME_SLOT, or ID_NET_NAME_PATH. Indeed it sounds useful to put that into a little shell script in /usr/share/doc/udev/ or so which the admin can run if she wants to migrate to the new names. > I mean, a sysadmin would then be able to determine the new name of the > network interface, reflect this change in the firewall setup and other > relevant places, delete 70-persistent-net.rules and reboot the box > (or may be perform some more involved encantation with calling ifdown / > ip link name ... / ifup while in a screen/tmux session). It's not advisable to change network names at runtime. Well, you could stop all networking services and unload and reload the driver modules, but that sounds about as error prone as just rebooting :-) I don't know whether it's possible to change the name while the interface is up and in use. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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/20150508104039.gf12...@piware.de
Re: Proposal: enable stateless persistant network interface names
Martin Pitt [2015-05-08 7:59 +0200]: > Details about [mac] > --- > [...] > * It requires a writable /etc/udev/rules.d/ for persistantly storing > the assignment. We don't want/have that with system-image > (touch/snappy). Sorry, these are Ubuntu specific terms, forgot to edit. This meant to say: we don't have that with read-only or stateless root file systems, which become increasingly more popular. We do get bug reports in Debian as well about stuff that breaks r/o root; it's not much of an issue yet, so if you don't consider this a valid/sane use case just ignore this bit of the argument (the other reasons are still strong enough to change this anyway). Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Proposal: enable stateless persistant network interface names
ng stable network names, we can't ever safely remove a generated /etc/udev/rules.d/70-persistent-net.rules. So when we do the above, names on existing installations will *not* change (as 70-persistent-net.rules trumps [ifnames]). So we can only let time and replacing/reinstalling machines take care of this. /etc/udev/rules.d/70-persistent-net.rules requires zero maintenance from us (it's just like the admin had manually set their own rules). Opinions? FTR, I also posted a similar mail to https://lists.ubuntu.com/archives/ubuntu-devel/2015-May/038761.html If you see this via debian-devel@, please keep CC'ing pkg-systemd@, I'm not subscribed to d-devel@. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: dpkg packaging problems
Hello Enrico, Enrico Weigelt, metux IT consult [2015-01-02 16:52 +0100]: > Unfortunately, the .so's loose the +x flag in the package > (while usual 'make install' is okay) - it seems that some of the > dh stuff drops that flag :( Yes, man dh_fixperms. Shared libraries don't need to and should not be executable. If you have a corner case where that's desirable, use -X to exclude those from permission fixes. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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/20150102160840.gd3...@piware.de
Re: Bug#769747: Technical committee acting in gross violation of the Debian constitution
Hello all, Josselin Mouette [2014-11-17 19:38 +0100]: > This decision has been made in gross violation of constitution §6.3.6, > being summoned to override a maintainer’s choice while the solution was > still under discussion. > > I urge the systemd maintainers not to take it into account. TBH, I think this was blown way out of proportion. I already switched the dependencies around yesterday in git. It's a rather harmless change after all -- a no-op for any existing system, regardless of whether they have systemd-sysv or sysvinit installed. And on upgrades, libpam-systemd is *not* meant to be the package that decides which init system you end up with IMHO -- that should be the job of a meta-package like "init" or other means (and there's still a pending discussion whether and how to upgrade existing wheezy machines to systemd). If other systemd maintainers want to keep discussing this dependency issue, please do (but it seems we are just losing them in dangerous quantities!), but I see absolutely no point in this personally. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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/20141118052952.gb3...@piware.de
Re: TLP package vs. pm-utils
Hello, Thomas Koch [2014-10-09 20:18 +0200]: > Looking into the current pm-utils package in Debian testing i noticed > that it is kind of inert: nor is pm-powersave called by upowerd – > changed in upower 0.99.1-1 That is a good point. I didn't really notice yet as in Ubuntu we still have the older upower, but this indeed will degrade power usage :/ > see [3] –, neither is pm-suspend called by systemd's sleep.target. Not by systemd as pid 1, but if you run with upstart or sysvinit, systemd-shim will use pm-utils if it is installed, so that suspend quirks still work. IMHO it is a bit unfortunate that all the suspend quirks and power management scripts were so lightly discarded upstream. I do understand their perspective of "fix stuff in the kernel", but in a distribution we have a slightly different perspective (e. g. consider an admin of a stable release -- what will he realistically be able to do: add a documented quirk to a text file, or fix the nvidia graphics driver?) > My conclusion would be to add > > > conflicts: pm-utils > > to my package – associated with the additional advantage that there is > no need to mask pm-utils' power.d/hooks via postinst/postrm anymore [4]. That seems a bit harsh and unnecessary -- you said that pm-utils was inert, not breaking TLP or systemd in any way? As it's still useful on non-systemd systems, I don't see a technical reason for the conflict. One of these days in the future we should put a conflict to pm-utils to clean it up on upgrades when we are ready to not support old hardware any more that still needs quirks, and the kernel or another component does a good enough power management by itself. But from my POV that day hasn't come yet, I still run into laptops which need quirks. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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/20141010052317.gc3...@piware.de
Re: dpkg-source to automatically add a Testsuite field
Hey Guillem, Guillem Jover [2014-08-14 13:05 +0200]: > Good. :) At the end I went for warning and removing the autopkgtest > value if the file is missing, as that seemed to make more sense, but we > can certainly revisit that if there's advantages in keeping the value. Splendid! > It migth make sense to update the last section describing the field > in «doc/README.package-tests.rst», now that this is handled by > dpkg-source >= 1.17.11. Indeed, done in http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=859cf134 I also updated https://people.debian.org/~mpitt/autopkgtest/ Thanks! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: dpkg-source to automatically add a Testsuite field
Hey Guillem, Guillem Jover [2014-07-06 18:35 +0200]: > Given that dpkg-dev has recognized the Testsuite field for some time, > I don't really see a reason for dpkg-source not to automatically add > it to the generated .dsc with an “autopkgtest” value if there is a > debian/tests/control file around, instead of requiring maintainers > to remember to set it manually. Absolutely. In fact this was even discussed back then, that's why README.package-tests.rst says "Future versions of dpkg-source might add this automatically when a ``debian/tests/control`` file is present." I just forgot to file a dpkg wishlist bug for that. > Reading the spec [S], it seems to me that the file can be empty, as > it states “This is a file containing zero or more RFC822-style > stanzas”, so the code cannot do any sanity check, like checking if > the file contains one stanza with a Tests field. So it will only > check for the file presence. That seems fine. A file with zero will cause the result "SKIP no tests in this package", which should be as expected. > I've queued a patch doing exactly that for dpkg 1.17.11. If there's > any known reservations with that, please speak up. Yay, thanks! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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/20140706181100.gb3...@piware.de
Anyone using autopkgtest-xenlvm? Needs a maintainer or get dropped
Hello Debian developers, around 2006 Ian wrote the autopkgtest-xenlvm [1] testbed for autopkgtest, which contains some scripts to set up LVM and XEN to provide ephemeral test beds for autopkgtest. However, Ian stopped developing autopkgtest many years ago, and currently I'm the only maintainer. These days we have several much simpler alternatives to the rather complicated Xen/LVM setup, with schroots, LXC, and QEMU all providing ephemeral testbed overlays without much effort or requirements to the host system. I never used -xenlvm or have heard from anyone who does (except Ian of course), so I don't even know whether it's still working. If anyone is still using this, can you please get in contact with autopkgtest-de...@lists.alioth.debian.org and tell us the status of it? Would you like to continue maintaining/testing it? If nobody is interested in this any more, I'd like to drop the package. It's been a bit of a maintenance drag as it prevents us from doing changes to the testbed protocol (which really could do with some major simplifications and bug fixes). Thank you, Martin [1] https://packages.debian.org/sid/autopkgtest-xenlvm -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: autopkgtest + chroot howto ? - Was: Re: Is it possible to run autopkgtest without a virtual machine ?
Hey Olivier, Olivier Berger [2014-01-26 14:45 +0100]: > I haven't been able to find a comprehensive set of instructions on how > to get started with autopkgtest, and I imagined that chroot would be an > interesting option. TBH I never use it myself, it's largely obsolete. You shouldn't use it with a "plain" directory chroot, as it cannot properly clean up after itself. You can call it with a dchroot name, so that dchroot does the overlays/cleanup, but as dchroot has been superseded by schroot that's obsolete. I advise to use the schroot runner instead. schroots are easy to set up these days with mk-sbuild, and with some additional love (like installing and configuring apt-cacher-ng and symlinking /var/lib/schroot/union/overlay/ and /var/lib/schroot/unpack/ to /tmp/, and having /tmp on a tmpfs), set up, tear down, and package installation are extremely fast. Then running autopkgtests with them is a simple matter of e. g. adt-run --- adt-virt-schroot sid if "sid" is your desired schroot name. > I quite don't see the interest of the adt-virt-null, as I suppose that a > clean test bed is generally required when testing... :-/ It is mainly useful for two cases: * You already have all the test dependencies installed on your developer machine and just want to quickly run tests of your package. It doesn't suffice for verifying that your test depends are sufficient and your test actually works in a minimal/untainted environment, but if you just want to test a change, its the fastest thing you can get. * You use adt-virt-null within an already built test bed such as Qemu. (That's how Ubuntu currently runs its production autopkgtests, as there is no adt-virt-qemu yet [1]) FTR, adt-virt-lxc is also a very nice runner as it provides much better isolation than schroots; but currently it requires an image with cloud-init, and AFAIK there are no ready-made daily Debian cloud images at the moment. Improving lxc itself and/or adt-virt-lxc to work for arbitrary containers would be nice. Martin [1] http://bazaar.launchpad.net/~auto-package-testing-dev/auto-package-testing/trunk/ -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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/20140126170951.gd3...@piware.de
Bug#705193: ITP: fatrace -- report system wide file access events
Package: wnpp Severity: wishlist Owner: Martin Pitt * Package name: fatrace Version : 0.4 Upstream Author : Martin Pitt * URL : https://launchpad.net/fatrace * License : GPL 3+ Programming Lang: C Description : report system wide file access events fatrace (File Access Trace) reports file access events from all running processes. Its main purpose is to find processes which keep waking up the disk unnecessarily and thus prevent some power saving. Please see this blog post for the justification and how to use it: http://www.piware.de/2012/02/fatrace-report-system-wide-file-access-events/ It has been in Ubuntu for a while, but I got a request to put it into Debian as well. It's a tiny little tool which doesn't require much maintenance, it's by and large done for its main purpose. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Bug#692023: ITP: python-dbusmock -- Mock D-Bus objects for testsuites
Package: wnpp Severity: wishlist Owner: Martin Pitt * Package name: python-dbusmock Version : 0.1.2 Upstream Author : Martin Pitt * URL : https://launchpad.net/python-dbusmock * License : LGPL 3+ Programming Lang: Python 3 Description : Mock D-Bus objects for testsuites With this program/Python library you can easily create mock objects on D-Bus. This is useful for writing tests for software which talks to D-Bus services such as upower, systemd, ConsoleKit, gnome-session or others, and it is hard (or impossible without root privileges) to set the state of the real services to what you expect in your tests. When using a local system/session bus, you can do integration testing without needing root privileges or disturbing a running system. The Python API offers some convenience functions like "start_session_bus()" and "start_system_bus()" for this, in a DBusTestCase class (subclass of unittest.TestCase). You can use this with any programming language, as you can run the mocker as a normal program. The actual setup of the mock (adding objects, methods, properties, etc.) all happen via D-Bus methods on the org.freedesktop.DBus.Mock interface. You just don't have the convenience API that way. Have a look at the README for more information, examples, and pointers to documentation: http://bazaar.launchpad.net/~pitti/python-dbusmock/trunk/view/head:/README.rst PyPI page: http://pypi.python.org/pypi/python-dbusmock Ubuntu packages: https://code.launchpad.net/~pitti/+archive/daily-builds Is it ok to upload this with Maintainer: being the Python team, and me being the/an uploader? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: [Pkg-postgresql-public] postgresql-* package namespace (was: Re: Bug#683486: ITP: barman -- Backup and Recovery Manager for PostgreSQL)
Hello Ansgar, Christoph, Christoph Berg [2012-08-01 21:12 +0200]: > The various postgresql-* packages are mostly plugins (PL/something) Right, postgresql-X.Y-foo are server-side plugins which are specific to a major PostgreSQL server version. They need to be versioned just like PostgreSQL itself for upgrades, parallel installability, etc. > which follow the example of postgresql-plperl-x.y (built from PG > core). For real applications like barman, that's not really > necessary. Where "real applications" == client-side PostgreSQL users, i. e. which only use libpq, not build against postgresql-server-dev-X.Y. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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/20120801204318.gc2...@piware.de
Re: DEP-8 extension proposal: Add source package header
Hello Ian, Ian Jackson [2012-06-15 17:18 +0100]: > > I saw that coming: There would be little dispute about adding a > > header, but lots of difficulty to find a good name. :-) Perhaps we > > should think about an actual name for DEP-8 first (similar to what we > > had with DEP-5 -> "copyright 1.0 format"), and then use an > > abbreviation of that for the XS-Testsuite: value? > > Is there some reason why we can't use "autopkgtest" ? It's a pretty > boring name really and I don't mind it being reused for both spec and > implementation. That's a thing we do quite often anyway. Eg "dpkg" :-) FTR, I think "autopkgtest" as a spec name is just fine. It conveys what the standard is about rather well in a really short name. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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/20120619052042.gb3...@piware.de
Re: DEP-8 extension proposal: Add source package header
Martin Pitt [2012-06-14 14:48 +0200]: > Right, that would do as well. However, I don't see this on > > http://ftp.debian.org/debian/dists/unstable/ Nevermind, found it; it's by-component apparently. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: DEP-8 extension proposal: Add source package header
Hello Stefan, Stefano Zacchiroli [2012-06-13 23:42 +0200]: > [ Adding autopkgtest-devel to recipients, where I've also just bounced > your mail. If you're interested in this topic, please consider > subscribing to that, very low traffic, list. ] Subscribed. Thanks for bouncing it, as I cannot mail Ian directly (his MTA rejects my mail server). > Oh, that's nice, thanks! Is the test execution environment something > that can easily deployed elsewhere? Not directly yet, but we are planning to. From bottom up it's autopkgtest running in a VM with a daily development release install triggered by Jenkins jobs: https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/ I'm not sure whether the scripts to do the back and forth setup/reporting are in some public branch, Jean-Baptiste would know. Locally I test with something like sudo adt-run foo.dsc --- adt-virt-null which is essentially what these Jenkins jobs do as well. > I'm also curious about the implementation: do you actually use > autopkgtest as low level test runner for Jenkins integration or...? We do. We had to fix a number of bugs there, they just recently were uploaded to Debian as well (thanks Ian). > As a temporary alternative to a hardcoded list, Stuart's proposal to use > Contents-source.gz is clearly better. Right, that would do as well. However, I don't see this on http://ftp.debian.org/debian/dists/unstable/ ? We don't build a Contents-source.gz on Ubuntu either. > As long as it stays as a XS-* header (which, for the history, it's also > how Vcs-* fields came into existence), no tool change is needed. Not needed, but it would be nice if dpkg-source could just add it automatically, so that developers don't need to care about it. > We should just agree upon a name. But if we want to have hopes to > promote it to something more official, I think it should rather be > independent from autopkgtest. Fully agree. It should be specific to this standard (developed as DEP-8), which does not have a name yet apparently? > How about something like "XS-Testsuite: runtime", where the key is > actually a space separate list of values values. Right now only > "runtime" [1] makes sense, but others might appear in the future. Perhaps "system-integration" or "install"/"installed" (as opposed to "build" test which are run during package build from debian/rules) might be clearer? I saw that coming: There would be little dispute about adding a header, but lots of difficulty to find a good name. :-) Perhaps we should think about an actual name for DEP-8 first (similar to what we had with DEP-5 -> "copyright 1.0 format"), and then use an abbreviation of that for the XS-Testsuite: value? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
DEP-8 extension proposal: Add source package header
Hello all, in Ubuntu we have started adding some autopkgtests to packages, using the DEP-8 debian/tests/control standard [1]. We now also have a test execution environment [2] which automatically triggers autopkgtest runs for a package and all its reverse dependencies on each upload. So far this is rather experimental. The main problem that we are facing with this is that it is not easily discoverable which source packages actually ship tests. Right now this is a hardcoded list, which does not scale at all. Thus I would like to propose to add a source package header, so that test execution environments can find out packages with tests by merely scanning Sources.gz (or iterating over the package dict with python-apt and the like). What do you think about something like this? (Diff against [3]) --- dep8.mdwn.orig 2012-06-13 09:22:06.156404163 +0200 +++ dep8.mdwn 2012-06-13 09:36:34.564446191 +0200 @@ -30,6 +30,14 @@ currently implemented by the [autopkgtest](http://packages.debian.org/sid/autopkgtest) package. +# Source package header + +To allow test execution environments to discover packages which provide tests, +their source packages should have a "Has-Autotests: true" header. This can +be set manually in debian/control with adding "XS-Has-Autotests: true" in the +"Source:" paragraph. Future versions of dpkg-source might add this +automatically when a debian/tests/control file is present. + I don't particularly care about the name or value of the header, but it's important to agree on one so that we can avoid having to change lots of packages later on. Once this is in the standard and proven to work, I'm happy to send a patch against dpkg-source to add that header automatically. Thank you, Martin [1] http://dep.debian.net/deps/dep8/ [2] https://jenkins.qa.ubuntu.com/view/Precise/view/AutoPkg%20Test/ [3] http://anonscm.debian.org/viewvc/dep/web/deps/dep8.mdwn?view=markup -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: Accepted postgresql-9.0 9.0.0-1 (source all amd64)
Hello again, Bastian Blank [2010-09-20 19:10 +0200]: > A preliminary analysis shows that the addition of a symbols file should > be enough for the client library in libpq5. There are five new exported > functions and no tricky define stuff. Not sure about the other lib. OK, fixed and tested by checking psql's own dependencies (-client now depends on >= 9.0~, but -contrib only on >= 8.4~), and rebuilding an rdepends. Sorry again for the brainfart, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: Accepted postgresql-9.0 9.0.0-1 (source all amd64)
Hello Bastian, Bastian Blank [2010-09-20 19:10 +0200]: > On Mon, Sep 20, 2010 at 06:11:31PM +0200, Rene Engelhard wrote: > > $ cat /var/lib/dpkg/info/libpq5.shlibs > > libpq 5 libpq5 (>= 9.0~) > > And how are packages linking against libpq5 now aupposed to go into squeeze > > with fixes? > > A preliminary analysis shows that the addition of a symbols file should > be enough for the client library in libpq5. There are five new exported > functions and no tricky define stuff. Not sure about the other lib. I'm terribly sorry for the mess, should have thought about that before. I'm currently preparing another upload with a proper symbols file. I need to leave now for about 2.5 hours, but you'll definitively get a new and tested upload by midnight (CEST) today. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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/20100920173816.gl2...@piware.de
Re: JPEG 8 transition
Hello Bill, Bill Allombert [2010-02-14 10:18 +0100]: > The first step is to fix packages that Depend on 'libjpeg62-dev'. They should > Depend on 'libjpeg-dev' instead. Please do not make them Depend on > 'libjpeg8-dev', or 'libjpeg-dev|libjpeg62-dev' or 'libjpeg-dev|libjpeg8-dev' > or > other combinaisons since this is useless and can only cause problem is the > future. This sounds wrong, though. So far it has been good practice (and lintian complains about it, too) to specify a real dependency first, and only then a virtual alternative; and for libraries it seems like an abuse of virtual packages to me in the first place: * If these were, and are expected to, keep API backwards compatibility, the binary package should be called libjpeg-dev, without any virtual packages. Then a simple binNMU would be enough. * If/once they break API, they should get a name like libjpeg8-dev, but then of course a virtual libjpeg-dev would be wrong. Thanks, and have a nice weekend, Martin P.S. Please keep me in CC, I'm not subscribed. -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: esound [was: Re: Non-related 'Recommends' dependencies - bug or not?]
Klaus Ethgen [2008-06-17 14:06 +0100]: > > The alternative to esound is not really ALSA, but rather pulseaudio. > > Is pulsaudio supported by applications like wine for example? Do > pulsaudio work on top of OSS? pulseaudio provides an esound ABI compatibility layer, thus it's a drop-in replacement. It also provides OSS and ALSA emulation for legacy applications; of course there will still be problems left with those, it can never be 100% transparent (especially not for OSS, which does not have a library API, but is so close to the metal). > OSS: Works well. > OSS<-ESD: Works well too. Ubuntu got a lot of bug reports about random desktop crashes/deadlocks with esound, that's why I learned to hate it so much (apart from the totally ridiculous video A/V desync). > ALSA: The problems above. > ALSA<-ESD: I never really tested. Thanks for your insights! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: esound [was: Re: Non-related 'Recommends' dependencies - bug or not?]
Hi Klaus, Klaus Ethgen [2008-06-17 10:12 +0100]: > I cannot prove that. Its sound quality is much better than the one of > ALSA direct. (Well esd on top of OSS. It is not that good than with OSS > direct but it is ok.) Hm, that rather sounds like for your card the OSS driver is much better than the ALSA one. But OSS/ALSA both live below the application level (where esound/pulseaudio/arts reside). > > (huge A/V desync when playing videos, etc.), > > I just see that issues when using ALSA. So please drop ALSA and not ESD. On the vast majority of systems out there, esound plays through ALSA. The kernel only has very few OSS-only drivers left, and gradually shifts towards ALSA only. Since ALSA is the kernel ABI (of course it has userspace libraries, too), and esound is the user session daemon, it's not really an 'either or' here. The alternative to esound is not really ALSA, but rather pulseaudio. > > The only thing I know which really still needs the esound interface is > > libgnome, for the sound events. > > There are other needs. > - The sound hardware do only support one bitrate and you need something > between to scale the bitrate. > - You want to have sound mixing and do not want to use ARTS (Which is > mud). Then IMHO you should use Pulseaudio nowadays. However, gstreamer and other infrastructure never really made bitrate/frequency conversion an issue with direct ALSA output. YMMV. > > At least in my personal experience, using ALSA directly (which has had > > dmix enabled by default for years) gives much better results. > > My experience is complete opposite. ALSA is that kind of buggy. If you > move the mouse while using sound on ALSA you hear cracks and sound > disorders. Also they halfly translate the config files!!! And then I was > not able to use it long time as it makes my systems complete instable > and it ops all time. (Tested on kernel 2.4.*, 2.6.* and also with debian > kernels or vanilla. And on all distros, Stable, Unstable or testing.) That's interesting indeed! So you avoid that by using an OSS driver instead of the ALSA one? I can really not imagine how esound on top of a broken ALSA driver would sound better than just using the ALSA output directly? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: "cupsys" renamed to "cups", please adjust your (build-)depends
Hi Bernhard, Bernhard R. Link [2008-06-12 18:23 +0200]: > How about using this transition to move some binaries between package > boundaries? Especially having some programs with generic names in -client and > some in -bsd seem to be a problem for some users (like #405827). I do not agree to this bug report. CUPS upstream's native tools have sysv names, so they should be in cups-client, and not a package which says "please do not install me". With those you can access all the features of cups (especially with lpadmin and lpinfo). Also, it already renames the very generic 'enable' and 'disable' commands to 'cupsenable' and 'cupsdisable'. But we cannot really do that for all the other frontend programs (lp, etc.), since their names have a long history and are just expected to be named like this. Renaming them now would break a lot. You can install a cups server without the client programs, and thus only use IPP for printing (as done by GNOME/KDE/gtkprint, etc.). So isn't the real problem that lprng isn't split into a client and server side package? If it was, you could mix them by installing cups and lprng-client, or the other way around (no idea whether this actually makes sense and would work, and whether the wire protocols are compatible). > I do not think having lp and lpr in different packages can cause any > good (and the same for lprm and cancel and so on). The cups-bsd package should really stay split, too, IMHO. They are a compatibility layer, and you do not need to have them installed in order to use cups for printing on the client side. Also, from your POV, merging -bsd into -client would only aggravate the problem? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
esound [was: Re: Non-related 'Recommends' dependencies - bug or not?]
Frans Pop [2008-06-15 20:39 +0200]: > Also, the package has had uploads of new upstream versions to Ubuntu > without getting similar uploads in Debian, but even there not by its > Debian maintainer who AFAIK is an Canonical employee. esound should *so much* die completely. It has very poor sound quality (huge A/V desync when playing videos, etc.), very poor code quality (it causes complete desktop locks very often, due to not being thread safe), and is abandoned upstream. At least in Ubuntu nobody likes it, and nobody wants to touch it, and we have not installed it by default since 6.06 or even earlier. Apparently in Debian the amount of esound love from the DDs is very similar. :-) The only thing I know which really still needs the esound interface is libgnome, for the sound events. However, Pulseaudio has a compatibility layer which provides full esound emulation (pulseaudio-esound-compat), without all the shortcomings of esd. If you don't care about sound events, then IMHO you are much better off with not having any sound server at all. At least in my personal experience, using ALSA directly (which has had dmix enabled by default for years) gives much better results. For the record, Ryan Murray isn't a Canonical employee. Also, the last upstream update was done by a community member who screwed it up pretty severely (he dropped all the Debian and Ubuntu patches). However, since nobody cares, we never fixed that. So please don't use the Ubuntu package as a basis for a Debian upload. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
"cupsys" renamed to "cups", please adjust your (build-)depends
xfprint4 (U) Christian Perrier <[EMAIL PROTECTED]> samba (U) Mark Purcell <[EMAIL PROTECTED]> cupsddk (U) hplip (U) Martin-Éric Racine <[EMAIL PROTECTED]> cups-pdf (U) Thierry Randrianiriana <[EMAIL PROTECTED]> gimmie Sebastian Rittau <[EMAIL PROTECTED]> netatalk (U) Emanuele Rocca <[EMAIL PROTECTED]> xfprint4 (U) Matthew Rosewarne <[EMAIL PROTECTED]> kde4libs (U) Otavio Salvador <[EMAIL PROTECTED]> python-cups Gustavo Noronha Silva <[EMAIL PROTECTED]> gnome-cups-manager (U) Sjoerd Simons <[EMAIL PROTECTED]> gnome-cups-manager (U) Jonas Smedegaard <[EMAIL PROTECTED]> ghostscript (U) netatalk netatalk (U) Jose Carlos Garcia Sogo <[EMAIL PROTECTED]> gnome-cups-manager (U) Clément Stenac <[EMAIL PROTECTED]> gnome-cups-manager (U) Ondřej Surý <[EMAIL PROTECTED]> gnome-cups-manager (U) Rob Taylor <[EMAIL PROTECTED]> libgnomeprint BrDesktop Team <[EMAIL PROTECTED]> brdesktop-flavours Antonio Terceiro <[EMAIL PROTECTED]> brdesktop-flavours (U) Modestas Vainius <[EMAIL PROTECTED]> kdelibs (U) qt-x11-free (U) Tiago Bortoletto Vaz <[EMAIL PROTECTED]> brdesktop-flavours (U) Sune Vuorela <[EMAIL PROTECTED]> kde4libs (U) kdelibs (U) qt-x11-free (U) Torsten Werner <[EMAIL PROTECTED]> grace6 (U) Jeroen van Wolffelaar <[EMAIL PROTECTED]> splix -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: Using sgid binaries to defend against LD_PRELOAD/ptrace()
Josselin Mouette [2008-04-30 10:17 +0200]: > This looks indeed like a reasonable alternative if we don't get the > noptrace group ; it would be easy to patch gksu/gnome-keyring/... with > the same stuff. I agree, and give the other possible attack scenarios it doesn't make much sense to throw a lot of effort (with noptrace group, etc.) at it. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: Using sgid binaries to defend against LD_PRELOAD/ptrace()
Martin Pitt [2008-04-28 9:22 +0200]:
> That's what the current Ubuntu version of libpolkit does (patch
> attached FYI).
*cough*
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
# Description: Disable ptrace() and core dumping for programs using libpolkit
# Ubuntu: https://wiki.ubuntu.com/DesktopTeam/Specs/PolicyKitIntegration
# Upstream: https://bugs.freedesktop.org/show_bug.cgi?id=13742
--- policykit-0.7/src/polkit/polkit-policy-default.c 2007-11-28 22:22:52.0 +0100
+++ policykit-0.7.new/src/polkit/polkit-policy-default.c 2007-12-31 18:14:45.0 +0100
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include "polkit-debug.h"
#include "polkit-error.h"
@@ -570,3 +571,14 @@
};
#endif /* POLKIT_BUILD_TESTS */
+
+/**
+ * Library constructor: Disable ptrace() and core dumping for applications
+ * which use this library, so that local trojans cannot silently abuse PK
+ * privileges. (This is a just a bandaid, not a robust solution).
+ */
+__attribute__ ((constructor))
+void init()
+{
+prctl(PR_SET_DUMPABLE, 0);
+}
signature.asc
Description: Digital signature
Re: Using sgid binaries to defend against LD_PRELOAD/ptrace()
Colin Watson [2008-04-27 13:19 +0100]: > > Can't you do something against ptrace in the binary itself and only > > for critical sections? > > You can (use prctl() to disable PR_SET_DUMPABLE), but it's only checked > on ptrace_attach so that would be racy. That's what the current Ubuntu version of libpolkit does (patch attached FYI). So far my feeling is that this is good enough for PolicyKit and the applications that use it. It prevents passwords from accidentally leaking to core dumps and programs which randomly ptrace() other processes from silently abusing gained PK privileges. In the end I did not worry too much about the startup race condition. If there is already a Trojan in the user's session, it is trivial to circumvent PR_SET_DUMPABLE, of course (by running the target application through gdb right from the start). But it is easy to call the PK dialog (or gksu/kdesu) with some crafted application name/reason as well, i. e. do some social engineering/phishing. So, having a standard group which sensitive applications could sgid to would be handy and fix the race on startup, but I consider it low-priority as long as we still have the 'fake UI' problem. A truly good solution for this is the "press Ctrl+Alt+Del before entering your password" schema, but even Windows abandonded it again, for usability reasons I guess. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: [Pkg-cups-devel] cupsddk - stolen WNPP - policy violation
Hi Patrick, Patrick [2008-04-21 17:55 +0200]: > You have not _explicitely refused it - but you didnt add me either. Oh, that might have been the point of confusion. I am an administrator for the cupsys package alioth project, but you didn't state that you wanted to work on cupsys itself (and, besides, you should do some contributions before you get commit access). So far I assumed that there would be separate projects for separate sources? > And to be honest - or rathe rin fact it does NOT make any sense, since > the Ubuntupackage is more of a hack than a debian-like package That might very well be so, I haven't checked it at all. I just wanted to ensure that you are aware of it. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: [Pkg-cups-devel] cupsddk - stolen WNPP - policy violation
Hi Patrick, Patrick Ringl [2008-04-21 3:46 +0200]: > I am concerned about 'cupsddk' which recently passed NEW. On 25th of > march I contacted pkg-cups for joining the team and working on cupsddk > [1] since I am about to repackage 'splix' (a driver for samsung laser > printers). > Martin Pitt did not accept my request for NO reason and told me to work > together with the Ubuntumaintainer of the package. What? I was happy to see someone working on those in Debian and welcomed you to join [1][2]. That hasn't changed, and I did not refuse your request at all. I merely suggested that someone else already packaged those, and it would make sense to look at the existing package rather than doing everything from scratch again. Where did I write that I refused your request?? Martin, who is slightly confused and thinks that there is a big misunderstanding happening here [1] http://lists.alioth.debian.org/pipermail/pkg-cups-devel/2008-March/005104.html [2] http://lists.alioth.debian.org/pipermail/pkg-cups-devel/2008-March/005110.html -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: Using sgid binaries to defend against LD_PRELOAD/ptrace()
Hi, Aaron M. Ucko [2007-12-10 12:32 -0500]: > Martin Pitt <[EMAIL PROTECTED]> writes: > > > That would be ideal, of course. Does ELF support anything like that? > > AFAICT, it should be possible to use a custom .note.* or .gnu.* > section for such purposes. I'm not an ELF expert, though. I dropped the question to upstream: http://www.uwsg.indiana.edu/hypermail/linux/kernel/0712.1/2025.html Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using sgid binaries to defend against LD_PRELOAD/ptrace()
Hi, Aaron M. Ucko: > I would counter-propose introducing some sort of ELF tag that ld could > set and the kernel and ld.so could check; while this would be more > involved, it would be less hackish and would avoid introducing new > potential vulnerabilities. That would be ideal, of course. Does ELF support anything like that? Thanks, Martin P.S. Please honour m-f-t, thanks. -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Using sgid binaries to defend against LD_PRELOAD/ptrace()
Hi all, one thing that has bothered me for a long time already is the complete lack of a security boundary between processes of the same user. Things like LD_PRELOAD and ptrace() (IOW, gdb) are enabled by default for all users, and especially for developers this is a good thing. However, a lot of programs that we have deal with passwords and other secrets which deserve some protection, like passwords you type into ssh, screensavers, seahorse, etc. This problem has become more pressing with the advent of PolicyKit, where even fewer processes have the in-built privilege separation between root and users. Getting rid of a lot of instances of gksu/kdesu is great, of course. :) [1] This concerns a scenario where you might have a rogue trojan in your session (e. g. a malicious firefox plugin or an autostart shell script). Admittedly, if an attacker gets that far he has almost won the machine and can easily get more privileges with some social engineering and spoofing, but I feel it is worth the small effort to at least not allow reading passwords from other processes' memory without making any noise at all. One easy solution that comes to my mind is to install those affected programs setgid, and drop the additional group immediately after program start with setgid(getgid()). For this we should introduce a new static group into base-passwd, like "noptrace", to not abuse existing groups and not confuse auditing tools. Setgidness provides a robust way to disallow ptrace/LD_PRELOAD for the user's peer processes without disabling them in general. (Note that all attempts to disable ptrace() within the program itself, such as prctl(SET_DUMPABLE, 0) are subject to race conditions and won't help). Another option would be to introduce a sysctl for enabling ptrace for users and disable it by default, but that would just mean that every developer get immediately frustated about gdb not working and enable it again at instant, so that you don't end up with any protection at all. Providing the sysctl would be useful anyway for servers, but disabling it by default is a bad idea I think. So I am asking for the addition of a new static group with this purpose. Once we have that, we can convert specific packages to use that setgid trick. What do you think about this approach? I'm well aware that this alone won't rescue desktop security (getting there is looots of more work), but one has to start somewhere. Thanks in advance for any comments, Martin P.S. Please keep me in CC. [1] gksu's security properties are just *so* horrible... That program is a mess. (I haven't looked at kdesu, but I guess it's not much better) -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Bug#452946: ITP: editmoin -- edit MoinMoin wiki pages with your favourite editor
Package: wnpp Severity: wishlist Owner: Martin Pitt <[EMAIL PROTECTED]> * Package name: editmoin Version : 1.9.1 Upstream Author : Gustavo Niemeyer <[EMAIL PROTECTED]> * URL : http://labix.org/editmoin * License : GPL 2 or later Programming Lang: Python Description : edit MoinMoin wiki pages with your favourite editor editmoin allows you to edit pages in MoinMoin wikis with your preferred editor instead of the (usually quite limited) web browsers' text areas. . It also supports configuration files to define shortcuts for URLs that you edit often. . This package also includes a Vim syntax file. However, you can use any other editor by setting the standard $EDITOR environment variable. The package is already in Ubuntu [1] (packaged by me), but by popular request I'd like to introduce it into Debian, too. [1] http://packages.ubuntu.com/editmoin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
Hi Christian! Christian Perrier [2005-10-21 7:05 +0200]: > > At this point, most of the major packages that have to be > > modified to enable a bare SELinux Debian system are in place, with > > coreutils being the last holdout. > > > Myself and other shadow package maintainers were wondering whether we > have to compile shadow utilities (login, su, passwd...) with SELinux > support. > > One of my co-maintainers said me we shouldn't because libselinux1 is > not in the base system...which seems untrue..:-) (or I misunderstood > him which is also likely) Even if it wasn't - libraries are not promoted to base just because its cool to have them there, but because base programs (want to) use them. Having OOTB support for SELinux would really rock *dream*, and I guess there will be little to no opposition to this feature, since it would not be enabled by default. > So, I guess we could, indeed...anyway I bet you'll ask us to do so at > some moment, won't you? *asking* :-) Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org In a world without walls and fences, who needs Windows and Gates? signature.asc Description: Digital signature
Re: Using buildds only
Hi Michael! Michael Spang [2005-08-25 12:44 -0400]: > Wouldn't those bugs just be indicative of an improperly packaged app or > broken build system? I really don't see the point of using pbuilder to > inefficiently work around a fixable problem. Sure, these packages should be fixed. However, at the time the bug is detected, the chroot is already polluted and must be restored. > If they're not fixable (I don't see how this could be) perhaps we > need a Build-Conflicts field. Most probably not, since buildd chroots only install the required build-deps and build-essential, so there shouldn't actually be build conflicts. Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developerhttp://www.debian.org signature.asc Description: Digital signature
Re: Using buildds only
Hi! Goswin von Brederlow [2005-08-23 21:54 +0200]: > You have to keep the chroot up-to-date manualy anyway as sbuild does > not upgrade unless a Build-Depends requires a newer version > specificaly. That's not true for Ubuntu's buildds, they are upgraded daily. I guess with the amount of new compilers that were uploaded in the last weeks, there is no other choice anyway. I'm surprised how Debian can get away without doing that. So buildd admins need to manually watch for toolchain updates and install them? Thanks, Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: Using buildds only
Hi Tomas! Tomas Fasth [2005-08-23 9:31 +0200]: > >>So you suggest throwing buildd out of the window and switching to > >>pbuilder, then? > > > > > > Something like this is in fact considered. Probably Ubuntu won't use > > pbuilder itself since it is not the most efficient implementation > > around, but rebuilding the buildd chroots from scratch would help to > > eliminate many FTBFS bugs due to polluted chroots. > > I find your statement about pbuilder and efficiency interesting. > Would you care to explain what you mean? > > As a side note, I have myself thought about extending pbuilder using > unionfs and overlays to avoid the tarball extraction for each build. Indeed I referred to the overhead of tarball extraction and the like. unionfs is a great idea, do you plan to integrate this into the main pbuilder package? This would really rock. :) Thanks, Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: Using buildds only (was: Results of the meeting...)
Hi! Steve Langasek [2005-08-22 18:09 -0700]: > On Mon, Aug 22, 2005 at 03:34:16PM +0200, Martin Pitt wrote: > > > W. Borgert [2005-08-22 14:37 +0200]: > > > Quoting Matthew Palmer <[EMAIL PROTECTED]>: > > > > I used to think that too. I took a wander through queue/reject on > > > > merkel. > > > > I don't think that any more. I'm curious as to how Ubuntu is going to > > > > sustain source-only uploads, honestly. > > > > Mandatory, signed build and test logs? I've no idea... > > > Ubuntu does not do anything of that sort. If I merely fix a > > description or add a Recommends:, I don't need to bother with > > rebuilding the package locally, and if I fix something bigger, I need > > to build and test the package anyway. > > > The system of source uploads works well in Ubuntu, so please don't try > > to invent problems which don't matter in reality. > > So, hmm, what about the anecdotal evidence of some Ubuntu maintainers doing > 3-4 sequential uploads of a package before finally uploading a version that > is buildable from source *anywhere*? This will teach them to do a build before uploading. :-) In most cases, this is due to forgotten build depends, so this problem is quite orthogonal to source-only uploads. Such failures happen in Debian, too (however, not quite as often, since katie runs much more often in Ubuntu, so it's much more tempting to just throw it at a buildd and see what happens). It doesn't really hurt us right now, so we didn't start to force building packages in pbuilder. buildd time is cheap compared to developer time, so introducing mandatory pbuilding would slow down development quite drastically. Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: Using buildds only (was: Results of the meeting...)
Hi Wouter! Wouter Verhelst [2005-08-23 1:26 +0200]: > On Mon, Aug 22, 2005 at 04:08:37PM +0200, Martin Pitt wrote: > > Hamish Moffatt [2005-08-22 23:47 +1000]: > > > There is the possibility that developer builds get extra features > > > enabled due to other installed libraries etc. This could be checked for > > > by analysing the packages files for different architectures or similar. > > > > The clean way to ensure this is to build them in a clean-room > > environment in the first place. It would be an unnecessary effort to > > implement more sanity checking in katie, and it is computationally > > impossible to check for additional/missing features in libary code. > > So you suggest throwing buildd out of the window and switching to > pbuilder, then? Something like this is in fact considered. Probably Ubuntu won't use pbuilder itself since it is not the most efficient implementation around, but rebuilding the buildd chroots from scratch would help to eliminate many FTBFS bugs due to polluted chroots. > (in case you wonder, buildd (which Ubuntu also uses) does /not/ > guarantee either up-to-dateness or clean chroots) For the latter, see above. For the former, lagging behind by at most one day (as the buildds do) is certainly acceptable. OTOH, lagging behind for several weeks (which is not unreasonable for folks without a phat pipe) is certainly not, especially if you are in a period of massive transitions. Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developerhttp://www.debian.org signature.asc Description: Digital signature
Re: Using buildds only (was: Results of the meeting...)
Hi Olaf! Olaf van der Spek [2005-08-22 19:28 +0200]: > > If we're starting to worry about what kind of damage a DD can do to the > > world by providing some bogus uploads, let's just not. Any DD can cause > > code to be executed as root on a potentially very big number of machines > > world wide, source-only uploads or not, and there are many ways to > > obfuscate malicious code within a big, complex application. Full ack. > With a (far) better privilege system you could avoid running most if > not all code as root, but that's another topic. No, you can't. The naming (whether you call it root or whatever) is insignificant. You can't write down a set of rules that describe which actions are deemed "good" and "bad", and since packages do need fairly many privileges to install and change files in a system, and execute code (postinst, etc.), you can always screw up user's systems with a malicious package. That's why we mainly trust developers, not heuristics on the buildds. Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developerhttp://www.debian.org signature.asc Description: Digital signature
Re: Results of the meeting in Helsinki about the Vancouver proposal
Hi! Manoj Srivastava [2005-08-22 7:58 -0500]: > The end goal is not just to have packages built on the > buildd -- and important goal for Debian, certainly, but not the only > one we have. As promoters of free software, we also are committed to > have packages build for our users, in a "real" environment, not just > a sterile, controlled. artificial "debian specific test" > environment. But it is exactly the derivations from the canonical standard system on a buildd that has the potential to break stuff for users (wrong shlib dependencies, different toolchain, etc.). Why we deprive the majority (i386) of our users the privilege of getting known good packages? (Since the majority of DDs does binary uploads for i386 as well)? Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: Using buildds only (was: Results of the meeting...)
Hi! Hamish Moffatt [2005-08-22 23:47 +1000]: > On Mon, Aug 22, 2005 at 03:31:40PM +0200, Martin Pitt wrote: > > Please let's not try to solve the problem of sloppy maintainers with a > > (wrong) technical solution. If a maintainer doesn't care for his > > packages, he can screw up a binary upload as well (or even worse than) > > a source upload. If a DD uploads a broken package, he should be told > > so, and we should aim to help him do it better the next time (that's > > what we do in Ubuntu and it works very well). > > I think this same argument can be used in favour of binary uploads. > Trust the developer to keep their machine up to date and build working > packages, and tell them when they make a mistake. I did not say that source uploads would make a DD more or less conscious about their uploads (I don't think so). I just said that source uploads are more convenient for the DD, cleaner design-wise, and avoid dependency and build chain breakage. > I've always found my mistakes are caught by the other buildds. > I don't remember ever uploading a broken i386 deb and source that > produced working debs on other architectures. I totally agree. > There is the possibility that developer builds get extra features > enabled due to other installed libraries etc. This could be checked for > by analysing the packages files for different architectures or similar. The clean way to ensure this is to build them in a clean-room environment in the first place. It would be an unnecessary effort to implement more sanity checking in katie, and it is computationally impossible to check for additional/missing features in libary code. Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developerhttp://www.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using buildds only (was: Results of the meeting...)
Hi! W. Borgert [2005-08-22 14:37 +0200]: > Quoting Matthew Palmer <[EMAIL PROTECTED]>: > > I used to think that too. I took a wander through queue/reject on merkel. > > I don't think that any more. I'm curious as to how Ubuntu is going to > > sustain source-only uploads, honestly. > > Mandatory, signed build and test logs? I've no idea... Ubuntu does not do anything of that sort. If I merely fix a description or add a Recommends:, I don't need to bother with rebuilding the package locally, and if I fix something bigger, I need to build and test the package anyway. The system of source uploads works well in Ubuntu, so please don't try to invent problems which don't matter in reality. Have a nice day, Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: Using buildds only (was: Results of the meeting...)
Hi Matthew! Matthew Palmer [2005-08-22 22:22 +1000]: > On Mon, Aug 22, 2005 at 10:45:58AM +0200, W. Borgert wrote: > > Quoting Sven Luther <[EMAIL PROTECTED]>: > > > All packages should be built by official debian buildds anyway, not on > > > developper machines with random cruft and unsecure packages installed, or > > > even > > > possibly experimental or home-modified stuff. > > > > That would be very good, indeed. I am very much in favour of allowing > > only source-only uploads and having all binaries build by the buildds > > only. The argument against it is, that DDs wouldn't check, whether > > the package builds cleanly etc. I think, that this is a poor argument, > > but anyway. > > I used to think that too. I took a wander through queue/reject on merkel. > I don't think that any more. I'm curious as to how Ubuntu is going to > sustain source-only uploads, honestly. I still think that source-only uploads would be preferable to our current binary uploads. It saves upload bandwith and ensures that packages are built in a clean chroot with the correct toolchain and libraries, rather than on tweaked, outdated, and potentially broken developer machines. It would also ensure the buildability of Arch: all packages (something that is not done at all in Debian now). I really love the source only uploads in Ubuntu, and as far as I can see, we never had a particular problem with this which would have been solved by binary uploads. Please let's not try to solve the problem of sloppy maintainers with a (wrong) technical solution. If a maintainer doesn't care for his packages, he can screw up a binary upload as well (or even worse than) a source upload. If a DD uploads a broken package, he should be told so, and we should aim to help him do it better the next time (that's what we do in Ubuntu and it works very well). Thanks for considering, Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: RFC: allow new upstream into stable when it's the only way to fix security issues.
Hi! Nikita V. Youshchenko [2005-08-01 10:34 +0400]: > Since such cases should be very rare, they may be handled manually (so > infrastructure changes are not needed). For the same reason, I don't think > that stability risks are high. Agreed. The whole point of backporting patches is to minimize introduction of instability and regressions from new versions. But if backporting produces so many regressions that the package becomes unusable, then that stability argument isn't valid any more, and it should rather be attempted to create good packages with new upstream versions. We did that for the Mozilla products in Ubuntu (in fact we seem to be the only ones who actually tried to backport the 1.0.5 changes, all other distros just upgraded to 1.0.5 proper), and apart from some minor things (upgrade of the locale packages in our "Warty" release which shipped Firefox 0.9.3, and enigmail upgrade), the upgrade was pretty smooth and the users are happy again. Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developerhttp://www.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: allow new upstream into stable when it's the only way to fix security issues.
Hi! Nikita V. Youshchenko [2005-07-31 23:10 +0400]: > So options seem to be: > > (1) keep vulnerable packages in stable, > (2) remove affected packages from distribution, > (3) allow new upstream into stable. We recently had the same problem in Ubuntu. Adam Conrad and me both spend literally weeks with backporting and fixing patches, and in the end we came up with a semi-working Firefox which was pretty buggy and broke almost all extensions. So we just gave up and uploaded the new upstream versions into stable, which made relatively little trouble compared to the mess we created with backporting. It was not an easy decision since usually we follow the same strict "minimal patches" backporting policy, but we finally had to bow to reality; the Mozilla code is so ugly and intertwined that backporting patches is a battle you can't win without employing a couple of upstream developers (which just say "use the new upstream version, dude!"). I think in the end we have to do the same for Debian. Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developerhttp://www.debian.org signature.asc Description: Digital signature
Re: debian mentors & ubuntu
Hi Nico! Nico Golde [2005-07-19 13:09 +0200]: > Hello Martin, > > * Martin Pitt <[EMAIL PROTECTED]> [2005-07-19 12:37]: > > Nico Golde [2005-07-19 12:21 +0200]: > > > Heyho, > > > why is mentors.debian.net powered by Ubuntu? > > > > This gave me a good laugh, and it's certainly way better than "SuSE" > > or "Micro$$$ IIS" :-), but still a bit embarrasing... > > I don't undestand what has ubuntu to do with a site which is > mainly used by new debian maintainers and their packages? As I tried to make clear in my initial reply, I don't have the slightest clue. It's not any official part of the Ubuntu world domination plan. :-) Maybe the admins just found Ubuntu easier to install, although it should not really make a big difference on a server, compared to a Debian installation. Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian mentors & ubuntu
Hi! Nico Golde [2005-07-19 12:21 +0200]: > Heyho, > why is mentors.debian.net powered by Ubuntu? This gave me a good laugh, and it's certainly way better than "SuSE" or "Micro$$$ IIS" :-), but still a bit embarrasing... Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: configure a program -- debconf abuse?
Hi! Petter Reinholdtsen [2005-07-05 11:00 +0200]: > [Hamish Moffatt] > > I thought policy said something stronger than that, but I seem to be > > wrong. Best practice used to be to ask questions only when there was > > no sensible default whatsoever. Not to ask everything possible just > > because you can. > > Keeping the question priority at 'low' make sure most users will not > see the question, and that only reconfigure will present it. I hope > you are not setting the debconf priority limit to low. :) Indeed, but IMHO low questions are just a waste of packaging work and, moreover, waste the time of translators who do not see the priority from the templates. There is a reason that packages generally don't ask for user-related configurations (ever seen "vim: do you want to enable syntax highlightning by default?"). It does make sense on complicated server packages which should run out of the box, but changing the user interface of a graphical editor is neither complicated, nor is it necessary to make the package work. Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developerhttp://www.debian.org signature.asc Description: Digital signature
Re: configure a program -- debconf abuse?
Hi! Joerg Sommer [2005-07-04 13:33 +]: > can I use debconf to ask the admin what should be the default look and > feel for the editor jed? The developers-reference manual tells us to not > abuse debconf. Is this an abuse? > > Jed can have the look and feel like emacs or the KDE editor. Can I ask > the admin, what should be the default? Hmm, this sounds pretty inadequate for a debconf question, since the admin should not decide it globally; that rather sounds like an user-specific configuration. Given that emacs-using people much more likely know what they are doing than people using the standard KDE editor, defaulting to the latter without bothering the admin seems a good choice IMHO. Have a nice day, Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: links to logs in /etc? (/etc/postgresql/7.4/main/log)
Hi!
Wouter Verhelst [2005-06-15 1:29 +0200]:
> [EMAIL PROTECTED]:~$ ls -l /usr/bin/awk
> rwxr-xr-x 1 root root 21 2005-03-28 10:49 /usr/bin/awk ->
> /etc/alternatives/awk
> [EMAIL PROTECTED]:~$ ls -l /etc/alternatives/awk
> rwxr-xr-x 1 root root 13 2005-03-28 13:22 /etc/alternatives/awk ->
> /usr/bin/gawk
>
> In other words, alternatives are *never* directly read from
> /etc/alternatives; they are read from, e.g., /usr/bin/awk.
>
> If you have a symlink /var/log/app.log -> /etc/app/log, then you're
> fine. If your app is writing directly to /etc/app/log, you're not.
>
> Why? Because otherwise your application tries to open a file which it
> can lstat but not stat if whatever the symlink tries to write to is not
> available for some reason (e.g., the file system is b0rked or not
> mounted).
That doesn't happen, pg_ctlcluster supplies the real log file location
to the postmaster:
sub cluster_info {
my %result;
$result{'configdir'} = "$confroot/$_[0]/$_[1]";
[...]
$result{'logfile'} = readlink ($result{'configdir'} . "/log");
[...]
}
As I said, I only regard the symlink target as configuration value, I
don't actually pretend that the actual log file is in /etc.
Martin
--
Martin Pitthttp://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
signature.asc
Description: Digital signature
Re: links to logs in /etc? (/etc/postgresql/7.4/main/log)
Hi again, Martin Pitt [2005-06-14 23:53 +0200]: > The basic idea of the new cluster system was to have the complete > information about a cluster's files in > /etc/postgresql//. That includes the location of the > log files and the data directory, which are configured using these > symlinks to their actual position. > > This makes it possible to move around clusters, rename them, or even > have several postmasters log to the same file without assuming any > preferred log file name in the infrastructure. As a concrete example: When transitioning the Sarge PostgreSQL package to the new architecture, the cluster is originally at /var/lib/postgres/data. If that directory is on the same partition as /var/lib/postgresql/7.4/main (the new canonical location for the main cluster), it is moved there. However, some people actually mounted a separate database partition to /var/lib/postgres, or even configured their cluster to use a completely different data directory. The transition can't just copy the files to /var/lib/postgresql then since there might be far too little space and the admin specifically *wanted* to use a dedicated partition. Thus the configuration of the data directory, log files, etc. must be configurable somewhere. This can't happen in postgresql.conf, so either there is another configuration file for the paths, or the paths are configured using the symlinks. The latter method is much faster and also more elegant IMHO. Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: links to logs in /etc? (/etc/postgresql/7.4/main/log)
Hi! Erik Steffl [2005-06-12 16:25 -0700]: > why is there a link to logs in /etc? > > /etc/postgresql/7.4/main/log is a link to > /var/log/postgresql/postgresql-7.4-main.log The basic idea of the new cluster system was to have the complete information about a cluster's files in /etc/postgresql//. That includes the location of the log files and the data directory, which are configured using these symlinks to their actual position. This makes it possible to move around clusters, rename them, or even have several postmasters log to the same file without assuming any preferred log file name in the infrastructure. > /etc is supposed to be for configuration files that are static, the > link to log violates both (yes, it's only a link so it doesn't change > but points to a file that changes and is definetely not a configuration > file). As you just said yourself, the link itself does not change, so it _is_ a static file. Its target is meant to be a piece of configuration which is user-changeable. As other people pointed out, it is equivalent to a link in /etc/alternative or an option in a real configuration file, so I don't see any problem with violating the spirit and the letters of the Debian Policy. The DP does not say that log files may never be moved around. > is this a bug? Or is this somehow valid? It is not a bug in the sense of an unexpected behavior. pg_createcluster was specifically designed that way. > btw I am not sure which package is this part of, can't find it using > dpkg -S, not even when I dpkg -L all postgresql packages I have > installed (I guess it was created by postinst sript or something like that). It is not a conffile, none of the files below /etc/postgresql is. These files are created by pg_createcluster and are properly cleaned in the respective postrm scripts. I still think this architecture is a good idea. It is technically possible to do without the symlinks and hardcode log file paths into the wrapper scripts. But it would just drop some nice features without actually gaining anything. So if you want to have that changed, you really have to convince me that symlinks in /etc are evil and worse than a config file option. Thanks and have a nice day, Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: PostgreSQL transition ahead
Hi! Adeodato Simó [2005-06-08 2:36 +0200]: > Do you plan on filing bugs to prevent loosing track of the remaining > uploads? Yes, that's what I'm going to do. > - file bugs against remaining packages after e.g. 2 or 4 weeks. A > bit more of effort, won't create a flood of RC bugs (hopefully). This seems saner. I don't think it is necessary to flood the BTS if many people fix their package anyway, so I'll just wait some weeks. Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: PostgreSQL transition ahead
Hi! Andreas Metzler [2005-06-07 20:03 +0200]: > Martin Pitt <[EMAIL PROTECTED]> wrote: > [...] > > I will upload the new packages to unstable very soon. This has a > > reasonably big impact to all packages that depend/build-depend on > > PostgreSQL since the package structure changed a bit: > > > (1) postgresql-dev was split into libpq-dev (for client apps like > >postfix or pygresql) and postgresql-server-dev- for server > >extensions (like postgresql-plruby and postgresql-ocaml). > [...] > > (1) makes all packages FTBFS that build-depend on postgresql-dev > [...] > > Hello, > If this applies to any package Build-Depending on postgresql-dev (and > actually linking against the library) you've missed at least one > package - exim4. So if I am right you perhaps should doublecheck your > list for completeness. Thanks. I already wrote to [EMAIL PROTECTED] Besides, there is already a patch for exim4: http://people.ubuntu.com/~pitti/postgresql-transition/exim4.psqlng.diff BTW, I generated the list based on "apt-cache rdepends libpq3", this should really catch all packages that deal with postgresql and need to be changed. Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: PostgreSQL transition ahead
Hi Florian! Florian Weimer [2005-06-07 19:24 +0200]: > * Martin Pitt: > > > (2) PostgreSQL 8.0 brought a new SONAME for libpq (libpq4), which > > removed a few symbols which were only intended for internal use, > > but were used nevertheless by some client apps (like "psql"). > > libpq4 can talk to all PostgreSQL servers back to 7.3 (same like > > libpq3). > > I assume applications linked to libpq3 should be able to connect to > PostgreSQL 8.0 servers. Is this correct? (According to a few tests, > it is.) Right, it is. libpq4 == libpq3 with a few symbols removed that were not actually intended to be used. I. e. you can use both libraries to connect to servers from 7.3.something to 8.0 (and probably even later versions). However, the idea is to always use the newest version and to fade out the usage of libpq3. Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
PostgreSQL transition ahead
(Sorry if you got this mail several times, I just CC'ed it to every affected binary package). Hi fellow Debian developers! Three months ago I announced the first alpha versions of the new architecture of the PostgreSQL packages [1] in experimental. Now, a few months later, they are mature enough to be used in actual production environments. In addition, Sarge is out of the door (YAY!), so it's high time to break unstable again. :-) The packages have lived in Debian experimental for a while now and are tested by several people (who also write bug reports). Currently they have no open bugs and support all the features that the Sarge version did. However, the new structure is much easier to maintain and develop, and also offers many new features for users (multi-version, multi-cluster, painless upgrades, see [2]). I will upload the new packages to unstable very soon. This has a reasonably big impact to all packages that depend/build-depend on PostgreSQL since the package structure changed a bit: (1) postgresql-dev was split into libpq-dev (for client apps like postfix or pygresql) and postgresql-server-dev- for server extensions (like postgresql-plruby and postgresql-ocaml). (2) PostgreSQL 8.0 brought a new SONAME for libpq (libpq4), which removed a few symbols which were only intended for internal use, but were used nevertheless by some client apps (like "psql"). libpq4 can talk to all PostgreSQL servers back to 7.3 (same like libpq3). (1) makes all packages FTBFS that build-depend on postgresql-dev (I CC'ed all affected packages). These need to be changed to depend on libpq-dev, and make buildable again. This will automatically care for (2) since libpq-dev makes the package depend on libpq4 then. The steps to adapt a client-side application to the new structure are: 1. Change the build-dependency postgresql-dev to libpq-dev. 2. Fix include directory path: - Very few packages use pg_config to determine include and library directories (e. g. pygresql). In this case no additional changes should be required any more. pg_config has been there for ages, but apparently nobody bothered to use it. - If the package does not use pg_config, then the ideal solution is to convert it to do so. This is easily possible for almost all packages (e. g. in debian/rules, add a configure option like --with-pgsql-include=`pg_config --includedir`). - If the packaging hardcodes include paths and has a crappy build system (cyrus-sasl2 was a pretty nonstandard one), then the quick fix is to hardcode the path for now (/usr/include/postgresql/8.0); however, this is not very robust, and it would be nice to eventually convert the package to use pg_config. 3. Test build. As a rule of thumb, if the package builds, it works. libpq-dev mainly changed paths and has a new library SONAME behind (libpq4), but the client library did not change any interface and thus should be fully backwards compatible. 4. Upload. :-) I already did these steps for a fair number of packages. So if you maintain one of the packages that have a debdiff at [3], you are lucky and only need to apply the patch there (however, cyrus-sasl2 and dovecot were nasty cases where the path has been hardcoded for now; this should be improved). The debdiffs were made for Ubuntu packages since I could upload them straight away. So the changelog patch will fail to apply, but the rest should be fine. The server-side packages are more delicate, though. Ideally they would be repackaged to build a module for all supported PostgreSQL versions (i. e. postgresql-7.4-plr, postgresql-8.0-plr, and so on). I will finish plr soon to show an example of how this is supposed to look like. Peter Eisentraut will package PL/Java soon. If you maintain such a package, please consider subscribing to [4] to coordinate the effort. Although the new packages will make all the client packages FTBFS, I will upload them to unstable soon, because: * The already built client app debs will just continue to work. * There is a clean upgrade path from the old postgresql package to the new one (just dist-upgrade). * Sid will be broken for a fair amount of time anyway since there are more transitions ahead of us (g++ 4.0, dbus, etc.) This mail already became longer than intended, so if you have any question, please contact [4] or me personally. Thanks and have a nice day! Martin [1] http://lists.debian.org/debian-devel/2005/03/msg01858.html [2] http://people.debian.org/~mpitt/postgresql-ng.html [3] http://people.ubuntu.com/~pitti/postgresql-transition/ [4] http://lists.alioth.debian.org/mailman/listinfo/pkg-postgresql-public -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developerhttp://www.debian.org signature.asc Description: Digital signature
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
Hi! Josselin Mouette [2005-06-05 18:50 +0200]: > The problem is that the decisions are always taken for the Ubuntu > distribution first. I can't remember any situation where somebody said "Don't do this in Debian yet, Ubuntu wants it first". I don't see any world/Debian domination plan here. Just right now it is much easier to do major changes in Ubuntu than in Debian, since Debian is close to a release, and Ubuntu is still quite early in the release cycle. But in a few weeks (hopefully), Debian can develop at full pace again. > Then, people from Canonical or people wanting to keep compatibility > between the two distributions will always want Debian to follow the > decisions taken for Ubuntu Of course that is always a goal, that's why major changes should usually be coordinated with Ubuntu before the change takes place (this had happened for the C++ transition). > , regardless of their technical merit and relevance for Debian. This > way, Debian ends up being lead by Canonical, and always lagging > behind. If you mean this in a general sense, what is an example of this? If you mean the C++ transition in particular, do you think that it is _not_ relevant to Debian? The people that are responsible for it in Ubuntu are the same that maintain the relevant packages in Debian, so they really should know what they are doing. At the same time you both complain about Debian lagging behind because of Ubuntu, and Debian being pushed forward by Ubuntu. > Actually, you can just look at what happens and see this is already > the case. Many packages in Debian are lagging behind Ubuntu, and > Ubuntu-specific patches are not forwarded to Debian maintainers, > regardless of the declarations. This statement is just wrong. Many patches are forwarded to the BTS and collected at patches.ubuntu.com. And even those that are not forwarded explicitly are always available at http://people.ubuntu.com/~scott/patches/. I'm sure that as soon as any Debian maintainer asks for clarification about the (rather coarse) files in this archive will get a satisfying explanation. > You can also see that the only architectures supposed not to be > dropped from testing in the Vancouver proposal are the architectures > Ubuntu supports. Is it a coincidence? I'd like to think so. Of course, Ubuntu picked some architectures completely arbitrarily. It was a really great piece of luck that these arches happened to be the most prominent in the world out there. > I'm not saying that for this particular decision, it wasn't the right > thing to do. Ok, that answers above question. > I'm questioning the independence of the project as a whole > for important technical decisions. Debian has always been superior > because we used to take the time to evaluate solutions and keep the best > one, technically speaking. If we merely follow Ubuntu, decisions won't > be only based on technical merits, but also on political and economical > ones. Who said that we have to follow Ubuntu all the time? I completely agree. In particular there are things in Ubuntu that don't fit into the concept of Debian (examples: the set of standard installation packages, the "zero debconf questions" policy, not supporting more architectures, and so on). But OTOH there are many good things in Ubuntu which would fit very well into Debian (proactive security enhancements, better hardware support, and whatever). Why do you think adopting them in Debian would be bad in any way? As long as this remains an offering, I think Debian can benefit from that. And at no time Ubuntu will be able to force decisions into Debian. Have a nice day, Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developerhttp://www.debian.org signature.asc Description: Digital signature
Re: FW: Processing of tla-load-dirs_1.0.21ubuntu1_source.changes
Hi! Colin Watson [2005-05-25 11:11 +0100]: > On Wed, May 25, 2005 at 07:39:30AM +1000, Matthew Palmer wrote: > > On Sun, May 22, 2005 at 03:56:35PM -0500, John Goerzen wrote: > > > Can anyone tell me what this means, and who is trying to upload this to > > > Debian without even sending me a patch first? > > > > What it means: the Ubuntu maintainer for tla-load-dirs (sorry, don't know > > who) managed to send their package in the direction of the Debian upload > > queue instead of the Ubuntu one. I'm not sure why this happens, because an > > Ubuntu maintainer should (I presume) change their dput/dupload defaults to > > Ubuntu, and the dput/dupload packages in Ubuntu should probably have their > > defaults changed to Ubuntu, not Debian. > > It requires two mistakes to actually get such an upload accepted (you > need to get the distribution wrong in debian/changelog, *and* you need > to get the upload target wrong). People have made one or other mistake > in the past, but I don't think anyone's managed both simultaneously yet. > Plus you have to be in both upload keyrings, which wasn't the case here. Actually it's even a third required mistake: For Ubuntu we can only do source-only uploads, Debian only accepts binary uploads. Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developerhttp://www.debian.org signature.asc Description: Digital signature
Re: Should Debian use lsb init-functions?
Hi! Thomas Hood [2005-03-26 10:02 +0100]: > > Changes: > > lsb (2.0-6) unstable; urgency=low > > . > >* Create lsb package in binary-indep step. (Closes: #297788) > >* Merge /lib/lsb/init-functions from Ubuntu. > >* Split /lib/lsb/init-functions into arch-all lsb-base package; this > > functionality is thus available for use by other, non-LSB packages. > >* Update README.Debian. > > > Should Debian initscripts use lsb init-functions? By all means. The lsb package provides a clean and abstract interface to init scripts, which has the advantage that it is easy to change the appearance and behaviour of the boot process (usplash, logging to files or remote hosts, quiet, etc.). This is a nightmare if you try this with the current echo constructions. However, during the transition period Debian shouldn't use Ubuntu's implementation, it should be adapted to be conformant to the current Debian policy. Thus during the transition period the boot process will still look consistent. Martin -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian Developer http://www.debian.org signature.asc Description: Digital signature
Announcing PostgreSQL 8.0 packages and a new PostgreSQL infrastructure
Howdy to all database enthusiasts! PostgreSQL 8.0 is out to the public for a few weeks now, and the amount of emails asking "When can we get the debs?" is increasing every day. In addition, the current structure and packaging of the existing PostgreSQL 7.4 packages became too clumsy and inflexible to be supported forever. So some time ago, Oliver Elphick and I developed a completely new architecture specification for PostgreSQL packages which allow to run several major versions in parallel (which finally resolves the upgrading hell) and to run arbitrarily many clusters (which makes the package much more interesting for e. g. web hosters or safe playgrounds). The detailled architecture description can be found at http://people.debian.org/~mpitt/postgresql-ng.html After some weeks of hacking and sleepless nights I am now proud to present the first usable set of 7.4 and 8.0 packages (in experimental) for this new structure: postgresql-: server binaries postgresql-client-: frontend programs postgresql-common: cluster management and frontend wrapper In addition, there are new packages "postgresql", "postgresql-client", "postgresql-contrib", etc., which provide a smooth upgrade path: they register the existing database from the current Hoary PostgreSQL packages to the new multicluster structure, clean up old stuff and immediately start the server again. Please note that this process will install the 7.4 server/client. (Of course you can additionally install the 8.0 server and client to play around with the new version). There is still a lot of work to do. But I feel that the packages now are mature enough to be tested by a wider audience, and also to attract more developers :) Take the plunge today and upgrade, test, and give feedback! i386 debs for Sid (and source packages) are now in experimental. If you just dist-upgrade to the experimental packages, your sid postgresql package should automatically be upgraded to the new structure, your existing database should be configured (check with pg_lsclusters), the new cluster should run and psql etc. should behave as before. If you install postgresql-7.4 or postgresql-8.0 from scratch (i. e. without "postgresql" already installed), you should end up with a fully functional and running "main" cluster. If you are interested in development: the package is developed with tla (or bazaar) in the following repository: tla register-archive http://arch.debian.org/arch/pkg-postgresql/[EMAIL PROTECTED]/ The following projects are relevant for these PostgreSQL packages: postgresql--devel--7.4 postgresql--devel--8.0 postgresql-common--devel--1 postgresql-transition--devel--1 If you want to work on them, either just check them out and send me patches, or do it the arch way and branch off to your own repository and tell me where to merge from. Happy testing and databasing! Martin P.S. This is _not_ Sarge stuff. The detailled reasons are explained in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=274043 -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
Re: debian/kernel security issues (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
Hi! Andres Salomon [2005-03-16 2:43 -0500]: > >>>> You seem to be implying that ubuntu is providing you with confidential > >>>> prior warning about kernel security holes, but I really doubt this, > >>> > >> > >> Actually, that was the case for a while (before ubuntu's kernel team went > >> on vacation, and I went on vacation). However, w/ all the vacations > >> that have been happening, it hasn't been the case for a few months. > >> > >> > > > > Rather, I was mistaken; they were things that had already been made > > public. Right, I never gave away details about undisclosed issues. At most I said to you "hey, there is another issue that will be published in two days, so rather wait with an upload". > > And, as a perfect example; > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0210 > > This has already been made public, and has been fixed in Ubuntu kernels > for 2 days. Sure would be nice the cve folks to let the rest of us in on > it, eh? Mitre generally lacks behind fairly badly with this. I think it is genrally easier to coordinate with the Ubuntu kernel and security teams. I track all issues that affect the Ubuntu kernel (which mostly affect Debian as well) and generally know patch URLS etc. Also, you can always get patches from the source packages, or get them from the arch repository. But in the long run I think it would be easier to apply for vendor-sec subscription. Joey is already subscribed, but since he does not deal with unstable updates, it would be good to have Andres on board. Personally I would apreciate and support Andres' subscription to vendor-sec. Martin -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
Re: usbmount: udev script to automatically (un)mount USB mass storage devices: include in Debian?
Hi! Pierre Habouzit [2005-03-08 16:22 +0100]: > mount -o sync ... is then a solution, especially if you only put small > things, and that the performance loss is not too painfull. That would be completely true if "sync" would hold what the name promises. VFAT does not (completely) implement "sync". Just try it: copy a big file onto a VFAT stick mounted with "sync" and immediately remove it. The file will be truncated. Also, if you immediately execute "sync" after copying something, a big bunch of data will still be written onto the stick. Martin -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
Any objections? -- Bug#293149: Please install libsysfs in /lib
Hi Debian developers! - Forwarded message from Patrick Caulfield <[EMAIL PROTECTED]> - Subject: Bug#293149: Please install libsysfs in /lib Reply-To: Patrick Caulfield <[EMAIL PROTECTED]>, [EMAIL PROTECTED] From: Patrick Caulfield <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Date: Tue, 01 Feb 2005 13:20:08 + X-Spam-Status: No, score=0.1 required=4.0 tests=FORGED_RCVD_HELO autolearn=no version=3.0.2 Package: libsysfs1 Version: 1.2.0-1 Severity: normal Please can you move libsysfs into /lib ? The multipath tools rely on this library for device identification and they really need to be started before /usr is mounted if it is on a different partition. - End forwarded message - libsysfs is small (about 39 KB), does not have any dependencies other than libc6, and tools querying /sys during bootup (when /usr/ is not yet available) are reasonable, so I'm not opposed to doing this. Is there any opposing opinion? Should this be done now / post Sarge / never? Thanks, Martin -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
Re: PostgreSQL-Problem and Problem on Alioth
Hi!
sean finney [2005-01-25 18:38 -0500]:
> On Tue, Jan 25, 2005 at 10:38:37AM +0100, Martin Pitt wrote:
> > There are two common ways to achieve that:
> >
> > - Connect as "www-data". For this you need an appropriate PostgreSQL
> > user ("createuser www-data" as user postgres). Then you either make
> > www-data the owner of the database ("createdb -O www-data mydb") or
> > you set the owner to some application-specific PostgreSQL user and
> > only GRANT the necessary permissions to www-data (usually you need
> > table creation etc. only for package installation and can restrict
> > www-data permissions to SELECT/UPDATE).
>
> if i'm understanding correctly, a security drawback of both these
> methods is that any web application would effectively have r/w privileges
> to every web app's database, right?
It does not make a difference whether you use the "owned by www-data"
approach or use different owners with passwords. The webserver can
read all scripts (_including_ the passwords) anyway, so regardless of
how you do it, all your databases will be fair game to your web
server.
> > This solution has the advantage that you don't need to modify
> > pg_hba.conf (since you can use "ident sameuser" authentication).
>
> which is certainly not to be overlooked. i think maybe a disclaimer
> like "if you run multiple applications, this may present a security
> risk" might be in order, but it should definitely be an option.
See above :-) I still think owning the database by an
application-specific user and granting the necessary permissions to
www-data is an easy method, and it gives you the maximum amount of
security you can expect from this use case (least privilege).
> > - Connect as $dbc_dbuser and use "password" authentication. ident
> > makes not much sense since the database user has not necessarily
> > a system user counterpart (if it has, then this would of course
> > work). But if it hasn't, you need a pg_hba.conf entry.
Well, this is not _exactly_ right since you can map system users to
database users in pg_ident.conf, but that would mean yet another
conffile to touch.
> also, it looks like pg_hba.conf and pg_ident.conf both have some
> kind of @include functionality, which might make messing with either
> of the files moot. i'll have to look more into these details...
I think pg_hba.conf does not have this feature. However, if that would
help and some kind of pg_hba.d/ structure would solve problems, I
think it would not be that hard to add that feature for Debian.
However, the general approach to these web applications wrt
databases should be discussed, and a generally working solution should
be found before I start hacking. :-)
Martin
--
Martin Pitt http://www.piware.de
Ubuntu Developerhttp://www.ubuntulinux.org
Debian GNU/Linux Developer http://www.debian.org
signature.asc
Description: Digital signature
Re: PostgreSQL-Problem and Problem on Alioth
Hi Andreas!
Andreas Tille [2005-01-25 9:43 +0100]:
> On Mon, Jan 24, 2005 at 10:27:10PM +0100, Andreas Tille wrote:
> >some applications do need a changed pg_hba.conf to work as expected.
>
> this raises something i'm wondering... what is the best generalized
> method for setting up an application with a username/database in
> postgresql?
>
> in the latest code, i'm doing the following:
>
> (as postgres)
> createuser $dbc_dbuser
> createdb $dbc_dbname -O $dbc_dbuser
>
> what's not clear is how the application then gets into the
> database as $dbc_dbuser. assuming it runs as www-data (or some
> system user if not a web app), should www-data be added to a map in
> pg_ident.conf to connect as $dbc_dbuser? or something in pg_hba.conf?
> also, what about authorization methods other than ident?
There are two common ways to achieve that:
- Connect as "www-data". For this you need an appropriate PostgreSQL
user ("createuser www-data" as user postgres). Then you either make
www-data the owner of the database ("createdb -O www-data mydb") or
you set the owner to some application-specific PostgreSQL user and
only GRANT the necessary permissions to www-data (usually you need
table creation etc. only for package installation and can restrict
www-data permissions to SELECT/UPDATE).
This solution has the advantage that you don't need to modify
pg_hba.conf (since you can use "ident sameuser" authentication).
The current PostgreSQL default installation does not create the
www-data user by default. If somebody convinces me that this would
be a good idea, then I wouldn't object to creating the user in the
PostgreSQL postinst, though. But instead I would rather just ship a
wrapper script that just ensures that www-data exists, and if not,
creates it.
- Connect as $dbc_dbuser and use "password" authentication. ident
makes not much sense since the database user has not necessarily
a system user counterpart (if it has, then this would of course
work). But if it hasn't, you need a pg_hba.conf entry.
I'm open to suggestions about making modifications to pg_hba.conf
unnecessary in the common case. (I still need some time to read this
thread about the common database infrastructure *sigh*).
Martin
--
Martin Pitt http://www.piware.de
Ubuntu Developerhttp://www.ubuntulinux.org
Debian GNU/Linux Developer http://www.debian.org
signature.asc
Description: Digital signature
Re: Accepted mozilla 2:1.7.5-1 (i386 source)
Hi! Rene Engelhard [2005-01-05 11:26 +0100]: > > mozilla (2:1.7.5-1) unstable; urgency=high > > . > >* New upstream release (closes: Bug#288047,Bug#288044,Bug#287111, > > Bug#277515) > > ARGS. Two of those bugs at least are *NOT* "new upstream release" type bugs. > Is it really to hard to write sensible changeslog which actually say *what* > was fixed (needed for looking offline when needed...) > > Is it too hard to e.g. write?: > > * New upstream release: (closes: #...) > - fixes NNTP security problem (closes: #...) > - fixes this (closes: #...) > - now foo is done (closes: ##...) > [...] Please also always include a CAN number if available (which was the case here). With this changelog it is impossible to track security fixes. Thanks, Martin -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
Re: Documentation for upstream software authors
Hi! Martin Schulze [2004-11-14 20:13 +0100]: > Adrian 'Dagurashibanipal' von Bidder wrote: > > I've just started http://wiki.debian.net/SoftwarePackaging, intended to > > collect thoughts of packagers how upstream developers can make the life of > > a packager easier. > > > > I'm sure all packagers have wondered about "brain-dead" upstream developers > > who have not put much thought into how their software might be distributed > > in a pre-compiled/pre-configured package. Compile-time options are one > > example, user-modifiable files outside of /etc are another, to name the two > > that I could think of just now. > > What comes to my mind: > > - public version control (cvs, arch, svn) by upstream > - public development mailing list > - public availability of old and new versions at a defined location >(for watch files etc.) > - clean clean target > - don't distribute auto-generated files except for configure/autofoo >but add rules to the Makefile to generate them on-demand > - add a private mail address of the lead developer to the distributed >files (contrary to only a mailing list, this is important for security >problems that need to be discussed off the public first) > - configurability of path names (so that the pkg can be made FHS compatible >easily without loads of patches) > - an announce list and a packager list may also be helpful to notify >packages of new versions / security problems (private) - Refrain from including source code from libraries which are externally available, or at least make it easy to use the external version of a library instead. Half a thousand copies of one and the same library scattered throughout Debian is an outright security nightmare. Martin -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
Re: Introducing pmount in Debian / New plugdev group
Hi! Marco d'Itri [2004-11-12 11:39 +0100]: > On Nov 12, Martin Pitt <[EMAIL PROTECTED]> wrote: > > > BTW, I suggest installing the rules files in /etc/udev/ and then > > > creating a symlink in the rules.d/ directory. > > Hmm, the Ubuntu hal package currently places the script directly in > > rules.d/ (as with any other *.d file) since I did not want to clutter > > up /etc/udev. Is this entirely unreasonable? I can change the Ubuntu > > version if necessary. > Using symlinks allows the user to disable or rearrange the rules. Correct, I changed this now. The rules file now lives in /etc/udev/hal-plugdev.rules, with a symlink in rules.d/. > > > > If it is okay for you that pmount also ships /etc/udev/removable.sh, > > > Please use /etc/udev/scripts/removable.sh. > > For the same reason (not cluttering up /etc/udev) I placed the script > > in /usr/share/hal/device-removable.sh. Is this okay as well? > Probably not, because the script may be run before /usr is available. I put it into /etc/udev/scripts/ now. Thanks for your hints and have a nice weekend! Martin -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
Re: Introducing pmount in Debian / New plugdev group
Hi Marco! Marco d'Itri [2004-11-12 10:42 +0100]: > On Nov 10, Martin Pitt <[EMAIL PROTECTED]> wrote: > > > I was not sure whether it is valid that packages put their scripts > > into /etc/udev/rules.d. > It is as long as they discuss it with me. :-) > BTW, I suggest installing the rules files in /etc/udev/ and then > creating a symlink in the rules.d/ directory. Hmm, the Ubuntu hal package currently places the script directly in rules.d/ (as with any other *.d file) since I did not want to clutter up /etc/udev. Is this entirely unreasonable? I can change the Ubuntu version if necessary. > > If it is okay for you that pmount also ships /etc/udev/removable.sh, > Please use /etc/udev/scripts/removable.sh. For the same reason (not cluttering up /etc/udev) I placed the script in /usr/share/hal/device-removable.sh. Is this okay as well? Thanks, Martin -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
Re: Introducing pmount in Debian / New plugdev group
Hi! Marco d'Itri [2004-11-10 14:19 +0100]: > On Nov 10, Martin Pitt <[EMAIL PROTECTED]> wrote: > > > Our /etc/udev/udev.rules has two new rules directly after the cdrom > > and floppy rules: > > > > # put removable IDE/SCSI devices into group 'plugdev' instead of 'disk' > > BUS="scsi", KERNEL="sd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", > > RESULT="1", NAME="%k", MODE="0660", GROUP="plugdev" > > BUS="ide", KERNEL="hd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", > > RESULT="1", NAME="%k", MODE="0660", GROUP="plugdev" > > What about I ship the script in udev (as /etc/udev/scripts/removable.sh) > and your package install the rules file? Or udev provides the rules file > too and your package enables it by creating the symlink? I thought over that again. The removable.sh script and the new rules should not be shipped in pmount, because pmount actually does not care about the device permissions. I ship these scripts in the Ubuntu version of hal now, where it fits much better, because the primary reason for introducing these rules was to allow hal to read the raw devices. As soon as Sjoerd decides to adopt the "hal running as normal user" approach, it is sufficient to adopt the Ubuntu patch to Debian's hal, without caring for any external dependencies. Have a nice day! Martin -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
Re: Introducing pmount in Debian / New plugdev group
Hi! Paul Hampson [2004-11-11 10:03 +1100]: > But don't CD-ROM and floppy devices also need the same sort of pmount > support you're proposing here? After all, you can hot-swap the media in > them, so it seems reasonable to me that they can be pmounted? What's the > rationale for _not_ including these in the pmount infrastructure you're > proposing? CD-ROMs are fully supported by pmount; hal runs in both floppy and cdrom group as well, so that media check and file system detection works. The only problem are floppies, because there is no sysfs entry for the floppy device. That means that pmount cannot currently decide that /dev/fd0 is removable and will refuse to mount it. However, this is not a big practical problem since legacy floppies are usually present in /etc/fstab. If a device is already in fstab, pmount behaves _exactly_ like mount . This fallback allows to use pmount as a complete replacement of mount in e. g. gnome-volume-manager. Maybe there is a misunderstanding here: pmount itself does not care about the group of a device. pmount decides whether or not the user is allowed to mount a device by looking at sysfs, not at device permissions. The udev mangling is not necessary for pmount, but for hal. Normally, /dev/hd* and /dev/sd* are assigned to group 'disk'. But access to group disk is essentially the same as root access, that's why we let hal run only in group 'plugdev' and assign all removable devices to group 'plugdev' instead of 'disk. > Hmm. Now that I think about it, surely the plugdev group would have to > be given using pam_console so that remote users in the plugdev group > can't remotely stomp on the USB memory stick the local user just put in, > before they could mount it? For Ubuntu we decided not to use pam_console, but put users into plugdev by default, because some users want to use their USB hard drives even remotely. However, using pam_console is entirely possible and in fact this decision is unrelated to the matter of device permissions. The administrator has to actively put users into plugdev, pmount will not try to mangle /etc/passwd :-) Have a nice day! Martin -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
Re: Introducing pmount in Debian / New plugdev group
Hi Marco! Marco d'Itri [2004-11-10 14:19 +0100]: > > Our /etc/udev/udev.rules has two new rules directly after the cdrom > > and floppy rules: > > > > # put removable IDE/SCSI devices into group 'plugdev' instead of 'disk' > > BUS="scsi", KERNEL="sd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", > > RESULT="1", NAME="%k", MODE="0660", GROUP="plugdev" > > BUS="ide", KERNEL="hd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", > > RESULT="1", NAME="%k", MODE="0660", GROUP="plugdev" > > What about I ship the script in udev (as /etc/udev/scripts/removable.sh) > and your package install the rules file? Or udev provides the rules file > too and your package enables it by creating the symlink? I was not sure whether it is valid that packages put their scripts into /etc/udev/rules.d. But I would be fine to leave udev.rules untouched and have pmount ship /etc/udev/rules.d/z_plugdev.rules (z_ because it must be executed after the standard rules; if it is executed earlier, CD-ROM and floppy nodes will also be in plugdev, which is not intended). If it is okay for you that pmount also ships /etc/udev/removable.sh, then I can do that as well. In this case the udev package does not need to be modified at all. Thanks for your cooperation and have a nice day! Martin -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
Re: Debian Entwicklung für unstable?
Hi Markus! Please do not crosspost so heavily; this is a question for debian-mentors, not for -devel, and even less for -release, let alone the FTP masters. This is outright spamming. Second, this is an English mailing list. [EMAIL PROTECTED] [2004-11-10 12:36 +0100]: > Ich habe bereits einige Debian Packete erstellt, von AVM (Kisdnwatch, > Kadslwatch etc.), > die dazugehörigen Kernel Module von AVM mit dem Kernel 2.6.9 werden auch > bald folgen. > Das ganze für unstable mit KDE 3.3.1. > Was muss ich machen, um diese auch in unstable mit zu veröffentlichen, > oder muss man den offiziellen weg eines debian Entwicklers, > wie im Internet beschrieben steht, beschreiten? You do not need to be a Debian Developer to maintain packages. It is enough to find a Debian Developer who reviews and uploads packages for you. http://www.de.debian.org/doc/developers-reference/ch-new-maintainer.en.html#s-mentors Martin -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
pmount in Sarge? [was: Re: Introducing pmount in Debian / New plugdev group]
Hi Nikita! Nikita V. Youshchenko [2004-11-10 14:38 +0300]: > AFAIK, Sarge is going to be released with 2.6.8.1 > > I think keeping pmount out of sarge is a bad idea. As long as pmount works > (it it is *released* with ubuntu, probably it does), and may be useful at > least from command line, why keep it out? > > And if, for whatever reason, sarge will not be released for some more time, > maybe some software that will use pmount will also migrate to sarge. For my sake I can close the RC bug and have it in Sarge. I will support it anyway, Ubuntu and Debian are in sync. I was just unsure whether there are opinions that it is better to keep it out. So if anybody does not want pmount to be in Sarge, please speak up now :-) Martin -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
Re: Introducing pmount in Debian / New plugdev group
Hi Marco!
Marco d'Itri [2004-11-09 19:32 +0100]:
> On Nov 09, Martin Pitt <[EMAIL PROTECTED]> wrote:
>
> > We solved (4) by introducing a new group called 'plugdev'. Every user
> > who is a member of this group can access hotpluggable devices (digital
> > cameras, USB drives etc.). pmount can only be executed by members of
> > this group (it is root:plugdev 750), hal runs in this group to be able
> > to detect file systems (but it does not run in 'disk'), and udev
> > assigns the 'plugdev' group to removable devices (static drives remain
> > in group 'disk').
> I'm not sure about what I should do as the udev maintainer. The default
> udev configuration does not really know for sure if a given device is
> removable.
Our /etc/udev/udev.rules has two new rules directly after the cdrom
and floppy rules:
# put removable IDE/SCSI devices into group 'plugdev' instead of 'disk'
BUS="scsi", KERNEL="sd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", RESULT="1",
NAME="%k", MODE="0660", GROUP="plugdev"
BUS="ide", KERNEL="hd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", RESULT="1",
NAME="%k", MODE="0660", GROUP="plugdev"
The removable.sh shell script (pasted below) returns whether a device
is actually removable by looking at the "removable" sysfs attribute.
However, this attribute was introduced in the kernel not before 2.6.8.
This is okay for Ubuntu since it ships with 2.6.8.1, and since even
Sarge ships with 2.6.8.1 (at some architectures at least), Etch will
certainly use 2.6.8+ as standard kernel. BTW, I do not want to force
this solution into Sarge, it is too late in the release cycle for such
changes (pmount has an RC bug to prevent Sarge migration).
However, this udev modification is safe even on older kernels; the
script will always return 0 there, which effectively disables above
rules. If devices are not in the plugdev group, but rather in "disk",
the following features will not work:
- pmount will refuse to mount PCMCIA drives since they look like
normal IDE adapters; mounting USB and FireWire devices will still
work, though, because pmount then checks the sysfs ancestry for
USB/FireWire nodes.
- Media checking will not work (e. g. hal will not recognize the
insertion of a card into an USB card reader), because hal does not
run in the "disk" group.
- hal will be unable to detect file systems and device labels on the
removeable devices for the same reason (not being in "disk").
- Users will be unable to partition, format, and label their USB
devices.
So hal/pmount/g-v-m will still be able to mount USB sticks, USB hard
drives, iPods, and so on, but will lack some reasonably important
features.
Martin
--- /etc/udev/removable.sh ---
#!/bin/sh -e
# print "1" if device $1 is removable, "0" otherwise.
# The "removable" attribute appeared in Linux 2.6.8; this script will always
# print "0" for earlier kernels.
DEV="${1%[0-9]*}"
REMOVABLE="/sys/block/$DEV/removable"
if [ -e "$REMOVABLE" ]; then
cat "$REMOVABLE"
else
echo "0"
fi
exit 0
--
--
Martin Pitt http://www.piware.de
Ubuntu Developerhttp://www.ubuntulinux.org
Debian GNU/Linux Developer http://www.debian.org
signature.asc
Description: Digital signature
Re: Introducing pmount in Debian / New plugdev group
Hi! Henning Makholm [2004-11-09 23:28 +]: > Scripsit [EMAIL PROTECTED] (Paul Hampson) > > On Tue, Nov 09, 2004 at 06:41:40PM +0100, Martin Pitt wrote: > > > > We solved (4) by introducing a new group called 'plugdev'. Every user > > > who is a member of this group can access hotpluggable devices (digital > > > cameras, USB drives etc.). pmount can only be executed by members of > > > this group (it is root:plugdev 750), > > This must be be a typo. Surely such a program would need to be suid > root, i.e. mode 4750 was meant rather than 750. Of course, sorry for that. Like mount, pmount of course needs root privileges to actually do the mounting. Paul, this also solves your question: a non-suid pmount cannot do anything useful. Martin -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
