Bug#679853: general: Too much downtime during a big dist-upgrade - avoidable with snapshots
2012/7/2 Philipp Kern : > Alexander, > it is not sufficient on a Debian system to just branch off the root filesystem > given that important state information of the package manager is stored in > /var. Yes, this seems to be a valid objection. However [call me a heretic if you want] does this state information really belong to /var? It is written to only when /usr is written to, by the same package manager that modifies the root fs and /usr. Maybe it's time to move it to /usr so that it is not intermixed with really variable user data. -- Alexander E. Patrakov -- 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/CAN_LGv38-gGcv2H14vCNJJnF_5FgRZ=+ljxi9se4mzb3wiy...@mail.gmail.com
Bug#679853: general: Too much downtime during a big dist-upgrade - avoidable with snapshots
Alexander, am Mon, Jul 02, 2012 at 11:11:51AM +0600 hast du folgendes geschrieben: > 1) The installer should be able to install the system to a btrfs > subvolume (except /home and /var, which should be on separate > subvolumes). > > 2) On such system, dpkg and apt/aptitude, if requested by the user > and/or by default, should make a writeable snapshot of the root > subvolume, mount it to some temporary location, chroot into it and > perform the upgrade there. During this process, the main system will, > of course, continue to work. it is not sufficient on a Debian system to just branch off the root filesystem given that important state information of the package manager is stored in /var. Of course somebody could port the Nexenta snapshotting method (with ZFS) to Debian proper with btrfs... Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Best Practices on testing-proposed-updates vs unstable vs experimental after testing freeze
On Tue, Jun 26, 2012 at 08:31:04AM +0200, Vincent Danjean wrote: > Le 25/06/2012 19:35, Aron Xu a écrit : > > unstable: any version that you would like to hit testing soon, so it's > > the version that Release Team agreed (or likely) to unblock it. > unstable would also works for new packages: they will sit here until > the release happens but they do not block anything nor prevent > migration of other packages. Please note that this might not apply to new revisions of libraries that are uploaded as new non-conflicting source packages and then take over the development package. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#679853: general: Too much downtime during a big dist-upgrade - avoidable with snapshots
Package: general, apt Severity: normal Today I ran "aptitude update ; aptitude dist-upgrade" on my virtual machine that provides some web applications to the clients. There were 126 updated packages (accumulated since 2012-06-18). The upgrade and the following kexec-based reboot went well, except for one thing: it took too long between stopping and starting again apache and mysql. A technology exists that can keep downtime to a minimum. It is called "btrfs snapshots", see below for the details. After Wheezy, Debian should support it natively in installer, dpkg and apt/aptitude. 1) The installer should be able to install the system to a btrfs subvolume (except /home and /var, which should be on separate subvolumes). 2) On such system, dpkg and apt/aptitude, if requested by the user and/or by default, should make a writeable snapshot of the root subvolume, mount it to some temporary location, chroot into it and perform the upgrade there. During this process, the main system will, of course, continue to work. 3) Then a kexec-based reboot should happen, using the new subvolume as the root filesystem. A kexec-based reboot is currently faster than a two-week dist-upgrade of the testing distribution, and thus it should be good for minimizing the downtime. Besides, the kernel is upgraded often in the testing distribution, thus a reboot is needed anyway. Maybe this procedure is also doable with LVM snapshots. Also note that this is different from the "offline updates" proposal from Lennart Poettering (that essentially involves running the current dist-upgrade between two reboots) and has different goals. His goal is to ensure consistency during and after the upgrade, my goal is to minimize downtime. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/1 CPU core) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- Alexander E. Patrakov -- 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/can_lgv2gkvhsxmtkb6jsm6egep_nn_od3pm4gk-7jwax9g7...@mail.gmail.com
Re: Improving our response to "duplicate" packages in Debian
Chris Bannister writes: > Is this [“game-ify”] yet another new word? It's a neologism, yes https://en.wikipedia.org/wiki/Gamification>. -- \“A life spent making mistakes is not only most honorable but | `\ more useful than a life spent doing nothing.” —anonymous | _o__) | Ben Finney -- 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/87txxqq0tm@benfinney.id.au
Re: Improving our response to "duplicate" packages in Debian
On Sun, Jul 01, 2012 at 08:24:27AM -0400, Kevin Mark wrote: > Has anyone quantized the % of tasks that a DD/DM does that are outside of > their > pet projects? Meaning, once they get their itch scratched, how far outside of > their main reason for joining Debian, do they explore? Would it be useful to > game-ify people's efforts outside their 'comfort zone' (eg. a perl packager Is this yet another new word? -- "If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing." --- Malcolm X -- 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/20120702030137.GY15677@tal
Re: Future of update-rc.d in wheezy+1
On Sun, Jul 01, 2012 at 06:39:57PM +0200, Stephan Seitz wrote: > On Thu, Jun 28, 2012 at 10:52:23AM +0100, Roger Leigh wrote: > >On Thu, Jun 28, 2012 at 10:44:53AM +0200, Goswin von Brederlow wrote: > >>The numbers specified for update-rc.d must be well ordered > >>according to the dependencies specified in the LSB headers. That > >>means that that > >>update-rc.d could keep a record of the numbers specified and check that > >>the numbers are valid even though sysv-rc/insserv then ignore them. > >While we could expend the time and effort to do this, I do have to > >question why. What would be the point of this? No one is using > >those numbers, so why retain them? It seems, to me, to be an > >entirely pointless waste of valuable developer time. And not just my > >time, but for every developer who would need to continue to test and > >validate the numbers for their scripts. > > > >We have dependencies for a reason, and the sequence numbers are now > >nothing more than a historical artifact. > > Well, I’m using file-rc on all my systems for many years. > - „vi /etc/runlevel.conf” is easier than working with strange symlinks; > - if I don’t want a service to start, I can replace „2,3,4,5” with „-”; > - third-party software without Debian package doesn’t use > update-rc.d; getting it to start is easier if I only have to edit > one file (runlevel.conf); No one messes with symlinks. We have update-rc.d for that for both sysv-rc and file-rc. For sysv-rc, insserv manages them for you, and in theory we could even get rid of them entirely and have the dependencies computed at runtime. We'd just need a mechanism for recording which scripts were disabled. When you edit runlevel.conf, you have to maintain the script ordering, by hand, using the sequence number field. This is (or is becoming) utterly broken, and is why we have dependency based booting nowadays. The numbers are computed automatically by insserv; this is far less error prone and much more flexible. > I have never used dependency based booting. > - old systems had to many old init scripts without LSB headers, so > the upgrade failed; > - some software needs a database, but the database server may not be > the same server, so the software can’t have a dependency on the > database server; so I have to overwrite the dependency > configuration in some way; > - third-party software doesn’t have any LSB headers; > IIRC the upgrade to dependency based booting doesn’t fail anymore if > you have initscripts without LSB headers (they are now running at > the end of the boot process), but for now I still don’t see any > reason to change. Given that it's been the default for quite a few years now, you really should try it. The sequence numbers are going away, so if there are problems with it that you need fixing, then they need indentifying and reporting. Editing the LSB headers in the scripts to do stuff like not depend on a local server is not exactly rocket science. And we have Should-Start rather than Required-Start for exactly this situation--if you found a buggy LSB dependency, for goodness sake report it and get it fixed, rather than perpetuating the awful static sequence numbers. Dependency based boot works, and works well. There is no reason to continue to use file-rc. [I spent the weekend adding insserv support to file-rc. But the consequence of computing the sequence numbers automatically is that it no longer makes sense to edit runlevel.conf by hand--adding or removing an init script could recompute the sequence numbers of many scripts. runlevel.conf is essentially just marking scripts as enabled if present, disabled if absent.] Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120701233720.gz9...@codelibre.net
Processed: blueman-manager: File Send and all later operations time out (Re: No transfert file from or to the smartphones and my PC: SONY xperia x10 and HTC One X)
Processing commands for cont...@bugs.debian.org: > reassign 679173 blueman Bug #679173 [general] general: No transfert file from or to the smartphones and my PC: SONY xperia x10 and HTC One X Bug reassigned from package 'general' to 'blueman'. Ignoring request to alter found versions of bug #679173 to the same values previously set Ignoring request to alter fixed versions of bug #679173 to the same values previously set > quit Stopping processing here. Please contact me if you need assistance. -- 679173: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679173 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.134118498616644.transcr...@bugs.debian.org
Bug#679173: blueman-manager: File Send and all later operations time out (Re: No transfert file from or to the smartphones and my PC: SONY xperia x10 and HTC One X)
reassign 679173 blueman quit Hi Jean Pierre and blueman maintainers, Jean Pierre Hoareau wrote > You wil find her under some detail about what hapen when I try to > send a file to my "HTC ONE X" smartphone . I think you are able to > reproduce this fail if you use the same hardware. Thanks much for this. [...] > root@soleil:~# lsusb > Usb Bluetooth Dongle : Bus 006 Device 002: ID 0a5c:2121 Broadcom Corp. > BCM2210 Bluetooth [...] > SMARTHONE > HTC-ONE-X, Androide 4.0.3, ICE. > Bluetooth software 4.0. > API HTC SDK: 4.12 > > *WHAT I DO :* > > 1- Start my computer under DEBIAN WHEEZE kernel 3.2.0-2-686-pae > 2- Plug ma bluetooth dongle USB > 3- Launch "blueman-manager" in console to get messages; > 4- Search "new adapter or device" from the screen. (HTC-ONE-X Found) > 5- Pair the Computer and the Smartphone. (Pairing OK) > 6- Send a file size *17ko* from the PC to Smartphone (result OK) > 7- Send a file size *48 ko* . > (Result Fail "Request Time Out") no File send. > 8- Retry (6) OK > 9- Retry (7) OK ..Why ? > 10- Send a file size *220 ko* Result Fail "Request Time Out" no > File send > > After this step any thing you do fail due to a Request Time Out. > > *MESSAGES SUMARY *: [logs snipped, available from [1]] Jean Pierre: please attach output from the "reportbug --template blueman" command. You can use your mailer's reply-to-all feature to ensure that the output is included in the bug log and the blueman maintainers receive it. Blueman maintainers: Known problem? Any ideas for tracking it down? Thanks again and hope that helps, Jonathan [1] http://bugs.debian.org/679173 -- 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/20120701232251.GG3728@burratino
Re: Future of update-rc.d in wheezy+1
On Sun, Jul 01, 2012 at 10:58:09PM +0200, Michael Biebl wrote: > On 27.06.2012 11:13, Roger Leigh wrote: > > > > I'd like to suggest that we do the following in sysv-rc update-rc.d: > > - wheezy: silently drop start|stop sequence numbers and runlevels > > (this is already the case when using insserv, and we can remove the > > non-insserv codepaths) > > - wheezy+1: warn if these options are used > > - wheezy+2: remove support for the options and error out if used > > error out in dh_install or update-rc.d? dh_install initially, since it only breaks builds rather than upgrades. Maybe even for wheezy+1. I'll see about adding a lintian check before that point though. update-rc.d could just warn for wheezy+1, but won't actually use the options for anything (start and stop can just be synonymous with defaults), which will allow old scripts to continue working. > > And additionally, to add lintian warnings for use of these options, > > including when using dh_installinit. > > All in all, sounds reasonable. Please go ahead with this. > It is seriously annoying making up random sequence numbers just to > please dh_install/update-rc.d. I've added insserv support to file-rc this weekend, which was the only thing still using the sequence numbers. I'd like to get this in wheezy, even though it's after the freeze, since it means there will be zero users of the numbers in the wheezy->wheezy+1 upgrade, which will allow us to disable them immediately after the release of wheezy. (#539591) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120701232244.gy9...@codelibre.net
Bug#679173: [Jean Pierre Hoareau: Re: No transfert file from or to the smartphones and my PC: SONY xperia x10 and HTC One X]
submitter 679173 Jean Pierre Hoareau
quit
Forwarding with permission.
--- Begin Message ---
Dear Jonathan,
Thanks for your quick answer, and sory for ma late answer due to a
failure on my mailbox "jphoar...@free.fr". Use my primary mailbox
"*hoarea...@free.fr*" for all new communication about this bluetooth
failure.
You wil find her under some detail about what hapen when I try to
send a file to my "HTC ONE X" smartphone . I think you are able to
reproduce this fail if you use the same hardware.
*Hardware Sumary *:
root@soleil:~# lsusb
Usb Bluetooth Dongle : Bus 006 Device 002: ID 0a5c:2121 Broadcom
Corp. BCM2210 Bluetooth
root@soleil:~# dmesg
[ 14.784063] Bluetooth: RFCOMM TTY layer initialized
[ 14.784069] Bluetooth: RFCOMM socket layer initialized
[ 14.784070] Bluetooth: RFCOMM ver 1.11
[ 14.798390] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 14.798392] Bluetooth: BNEP filters: protocol multicast
[ 2488.100300] usb 2-6.1: reset high-speed USB device number 5
using ehci_hcd
[ 2498.084251] usb 2-6.1: reset high-speed USB device number 5
using ehci_hcd
SMARTHONE
HTC-ONE-X, Androide 4.0.3, ICE.
Bluetooth software 4.0.
API HTC SDK: 4.12
*WHAT I DO :*
1- Start my computer under DEBIAN WHEEZE kernel 3.2.0-2-686-pae
2- Plug ma bluetooth dongle USB
3- Launch "blueman-manager" in console to get messages;
4- Search "new adapter or device" from the screen. (HTC-ONE-X Found)
5- Pair the Computer and the Smartphone. (Pairing OK)
6- Send a file size *17ko* from the PC to Smartphone (result OK)
7- Send a file size *48 ko* .
(Result Fail "Request Time Out") no File send.
8- Retry (6) OK
9- Retry (7) OK ..Why ?
10- Send a file size *220 ko* Result Fail "Request Time Out" no
File send
After this step any thing you do fail due to a Request Time Out.
*MESSAGES SUMARY *:
*root@soleil:~# blueman-manager *
** (process:3103): WARNING **: Trying to register gtype
'GMountMountFlags' as enum when in fact it is of type 'GFlags'
** (process:3103): WARNING **: Trying to register gtype
'GDriveStartFlags' as enum when in fact it is of type 'GFlags'
** (process:3103): WARNING **: Trying to register gtype
'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
Loading configuration plugins
Using gconf config backend
_
Load (/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:68)
['Services', 'PulseAudioProfile']
_
Load (/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:68)
Unable to load plugin module PulseAudioProfile
PulseAudio applet plugin not loaded, nothing to do here
_
__load_plugin
(/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:142)
loading
blueman-manager version 1.22 starting
_
on_bluez_name_owner_changed (/usr/bin/blueman-manager:110)
org.bluez owner changed to :1.5
Using gconf config backend
_
SetAdapter (/usr/lib/python2.7/dist-packages/blueman/gui/DeviceList.py:301)
None
_
on_adapter_changed
(/usr/lib/python2.7/dist-packages/blueman/gui/manager/ManagerToolbar.py:89)
toolbar adapter /org/bluez/1528/hci0
*PAIRING PC to SMARTPHONE*
_
on_device_created
(/usr/lib/python2.7/dist-packages/blueman/gui/DeviceList.py:282)
created /org/bluez/1528/hci0/dev_40_98_4E_55_DA_1E
_
__init__ (/usr/lib/python2.7/dist-packages/blueman/main/Device.py:35)
caching initial properties
_
do_cache (/usr/lib/python2.7/dist-packages/blueman/gui/DeviceList.py:556)
Caching new device 40:98:4E:55:DA:1E
_
row_update_event
(/usr/lib/python2.7/dist-packages/blueman/gui/manager/ManagerDeviceList.py:278)
row update event Fake False
_
row_update_event
(/usr/lib/python2.7/dist-packages/blueman/gui/manager/ManagerDeviceList.py:278)
row update event Trusted 0
_
row_update_event
(/usr/lib/python2.7/dist-packages/blueman/gui/manager/ManagerDeviceList.py:278)
row update event Paired 0
_
init_services (/usr/lib/python2.7/dist-packages/blueman/main/Device.py:91)
Loading services
_
Generate
(/usr/lib/python2.7/dist-packages/blueman/gui/manager/ManagerDeviceMenu.py:230)
HTC_ONE_X
_
row_update_event
(/usr/lib/python2.7/dist-packages/blueman/gui/manager/ManagerDeviceList.py:278)
row update event Fake False
_
on_property_changed
(/usr/lib/python2.7/dist-packages/blueman/gui/DeviceList.py:180)
adapter propery changed Devices
dbus.Array([dbus.ObjectPath('/org/bluez/1528/hci0/dev_40_98_4E_55_DA_1E')],
signature=dbus.Signature('o'), variant_level=1)
_
on_device_property_changed
(/usr/lib/python2.7/dist-packages/blueman/gui/DeviceList.py:191)
list: device_prop_ch Connected 1
/org/bluez/1528/hci0/dev_40_98_4E_55_DA_1E () {}
_
row_update_event
(/usr/lib/python2.7/dist-packages/blueman/gui/manager/ManagerDeviceList.py:278)
row update event Connected 1
_
Generate
(/us
Processed: [Jean Pierre Hoareau: Re: No transfert file from or to the smartphones and my PC: SONY xperia x10 and HTC One X]
Processing commands for cont...@bugs.debian.org: > submitter 679173 Jean Pierre Hoareau Bug #679173 [general] general: No transfert file from or to the smartphones and my PC: SONY xperia x10 and HTC One X Changed Bug submitter to 'Jean Pierre Hoareau ' from 'HOAREAU jean pierre ' > quit Stopping processing here. Please contact me if you need assistance. -- 679173: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679173 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.134118429813657.transcr...@bugs.debian.org
Re: Improving our response to "duplicate" packages in Debian
Hi, On Sat, Jun 30, 2012 at 08:41:07AM +0200, Michael Hanke wrote: > I think this is approaching the problem from the wrong end. Instead of > preserving the status quo and asking oracles to predict the future we > should have better means of _removing_ software that has proven to be > inferior of an equivalent alternative in Debian. The advantage is that > we have objective criteria to be able to make an informed decision -- > not a guess based on heuristics and opinion. The disadvantage is that it > imposes work on other volunteers -- but see below... well, what do you have in mind? If you happen to think along the lines of bug count per package, that's easily challenged (imho), and defining "equivalent" is also far from providing an objective criterion. On top of that, I happen to appreciate the choice I have in Debian, instead of the only one true way to do things. Just think of the "equivalence" between KDE and Gnome, or vim and emacs, for a start. Imho, going that road is the fastest way to wind down our user base to less than a third of the current size. I also think that Craig and Russel are right about the incentives and risks for newcomers not being able to scratch their itch, and failing in a core project. May I ask what are the driving reasons behind the advocated change with respect to our tradision are? Kind regards, --Toni++ -- 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/20120701221120.ga27...@spruce.wiehl.oeko.net
Re: Future of update-rc.d in wheezy+1
On 01.07.2012 22:58, Michael Biebl wrote: > On 27.06.2012 11:13, Roger Leigh wrote: >> - wheezy+2: remove support for the options and error out if used > > error out in dh_install or update-rc.d? ^ dh_installinit > It is seriously annoying making up random sequence numbers just to > please dh_install/update-rc.d. ^ dh_installinit -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Future of update-rc.d in wheezy+1
On 27.06.2012 11:13, Roger Leigh wrote: > > I'd like to suggest that we do the following in sysv-rc update-rc.d: > - wheezy: silently drop start|stop sequence numbers and runlevels > (this is already the case when using insserv, and we can remove the > non-insserv codepaths) > - wheezy+1: warn if these options are used > - wheezy+2: remove support for the options and error out if used error out in dh_install or update-rc.d? > And additionally, to add lintian warnings for use of these options, > including when using dh_installinit. All in all, sounds reasonable. Please go ahead with this. It is seriously annoying making up random sequence numbers just to please dh_install/update-rc.d. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Future of update-rc.d in wheezy+1
On Thu, Jun 28, 2012 at 10:52:23AM +0100, Roger Leigh wrote: On Thu, Jun 28, 2012 at 10:44:53AM +0200, Goswin von Brederlow wrote: The numbers specified for update-rc.d must be well ordered according to the dependencies specified in the LSB headers. That means that that update-rc.d could keep a record of the numbers specified and check that the numbers are valid even though sysv-rc/insserv then ignore them. While we could expend the time and effort to do this, I do have to question why. What would be the point of this? No one is using those numbers, so why retain them? It seems, to me, to be an entirely pointless waste of valuable developer time. And not just my time, but for every developer who would need to continue to test and validate the numbers for their scripts. We have dependencies for a reason, and the sequence numbers are now nothing more than a historical artifact. Well, I’m using file-rc on all my systems for many years. - „vi /etc/runlevel.conf” is easier than working with strange symlinks; - if I don’t want a service to start, I can replace „2,3,4,5” with „-”; - third-party software without Debian package doesn’t use update-rc.d; getting it to start is easier if I only have to edit one file (runlevel.conf); I have never used dependency based booting. - old systems had to many old init scripts without LSB headers, so the upgrade failed; - some software needs a database, but the database server may not be the same server, so the software can’t have a dependency on the database server; so I have to overwrite the dependency configuration in some way; - third-party software doesn’t have any LSB headers; IIRC the upgrade to dependency based booting doesn’t fail anymore if you have initscripts without LSB headers (they are now running at the end of the boot process), but for now I still don’t see any reason to change. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Improving our response to "duplicate" packages in Debian
On Fri, Jun 29, 2012 at 12:18:49PM -0400, Yaroslav Halchenko wrote: > I would go even 1 step further and seek from a perspective maintainer, > especially a non-DD/DM, at least some assurance that it is not a > fire-and-forget project for him (e.g. that he is using it extensively > and planing to do so for the next X years) and that he is willing > to put effort in proper maintenance of the package. ITP -> 1 upload -> > X NMUs -> O is not that uncommon. IMHO if there is a strong personal > motivation (i.e. active user) to get a package packaged, it might > provide additional weight toward "accepting" the package to be part of > Debian even if comparable alternatives exist. Sadly even if you might be an active user in the beginning you might leave the organization where you needed it. Strong personal motivation helps pretty much, but if you lose the environment, you might suddenly lack it completely. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Improving our response to "duplicate" packages in Debian
Le Sun, Jul 01, 2012 at 08:24:27AM -0400, Kevin Mark a écrit : > > Has anyone quantized the % of tasks that a DD/DM does that are outside of > their > pet projects? Meaning, once they get their itch scratched, how far outside of > their main reason for joining Debian, do they explore? Would it be useful to > game-ify people's efforts outside their 'comfort zone' (eg. a perl packager > working on Haskell, or doing debian-www work) ? > If people just work on their pet projects, is that the most typical behavior > throughout Debian's history? Do people explore more as they become more > comfortable/familiar over a number of years? We did not quantify, but the Debian Med project has a wiki page where its members can indicate that they "extended scope". http://wiki.debian.org/DebianMed/Developers Have a nice Sunday, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20120701123237.gb24...@falafel.plessy.net
Re: Improving our response to "duplicate" packages in Debian
On Sun, Jul 01, 2012 at 08:34:01AM +1000, Craig Small wrote: > I'd go even further and say that the reason why people start on > something generally in Free Software projects is to "scratch their itch" > which in Debian could well mean packaing your favourite piece of > software. Has anyone quantized the % of tasks that a DD/DM does that are outside of their pet projects? Meaning, once they get their itch scratched, how far outside of their main reason for joining Debian, do they explore? Would it be useful to game-ify people's efforts outside their 'comfort zone' (eg. a perl packager working on Haskell, or doing debian-www work) ? If people just work on their pet projects, is that the most typical behavior throughout Debian's history? Do people explore more as they become more comfortable/familiar over a number of years? -- | .''`. == Debian GNU/Linux ==.| http://kevix.myopenid.com..| | : :' : The Universal OS| mysite.verizon.net/kevin.mark/.| | `. `' http://www.debian.org/.| http://counter.li.org [#238656]| |___`-Unless I ask to be CCd,.assume I am subscribed._| Kindness is a language which the deaf can hear and the blind can read. -- Mark Twain -- 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/20120701122427.GB8356@horacrux
Re: Bug#621833: System users: removing them
On Sun, May 29, 2011 at 08:32:21PM +0100, Roger Leigh wrote: > We could add special behaviour to adduser to unlock the account > if it already exists when run in the postinst. Yes, that would be the way to go for adduser --system > However, most postinsts wrap the call to adduser with a check for > whether the account already exists, so it would not be called > without an update to every preinst employing this strategy. Yes, packages having used that approached are buggy in the first place. > It would also alter the existing behaviour of adduser, which is to > return nonzero if the user already exists, which could cause > breakage. NACK, adduser --system does return zero if the user already exists and its parameters are sufficiently similiar to the parameters requested by the maintainer script. > I dislike the fact that the behaviour of adduser and deluser would, > in effect, /not/ add or delete users as intended, which is rather > counter-intuitive. Providing that we have consensus on a recommended > strategy for locking and unlocking accounts which can go into policy, > I think all we need are examples for how maintainer scripts are > expected to handle account creation and locking/unlocking. NACK, don't put the same logic into a hundred maintainer scripts where they'll have two hundred different bugs. Put the logic into a central place where bugs can be handled centrally. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- 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/20120701095539.gb7...@torres.zugschlus.de
Re: Bug#621833: System users: removing them
On Sun, May 29, 2011 at 12:04:35PM +0100, Roger Leigh wrote: >I'm currently using this logic (in postinst) > > # Create dedicated sbuild user > if ! getent passwd sbuild > /dev/null; then > adduser --system --quiet --home /var/lib/sbuild --no-create-home \ > --shell /bin/bash --ingroup sbuild --gecos "Debian source builder" > sbuild > fi > > However, consider that if the account is locked, the user already > exists and no unlocking will occur, leaving the reinstalled > package broken. This logic is common to many packages. That's a bug in a lot of packages, yes. adduser has been designed to allow adduser --system to be called without that logic: If called with one non-option argument and the --system option, adduser will add a system user. If a user with the same name already exists in the system uid range (or, if the uid is specified, if a user with that uid already exists), adduser will exit with a warning. This warning can be suppressed by adding "--quiet". So, just remove the extra getent passwd check and you should be fine. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- 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/20120701095311.ga7...@torres.zugschlus.de
