FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 03-20-2012, 07:07 AM
Arch Website Notification
 
Default

=== Signoff report for [testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 25 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 11 fully signed off packages
* 44 packages missing signoffs
* 3 packages older than 14 days

(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)


== New packages in [testing] in last 24 hours (25 total) ==

* netcfg-2.7.1-1 (any)
* kmod-7-1 (i686)
* linux-3.3-1 (i686)
* linux-lts-3.0.25-1 (i686)
* openssh-5.9p1-8 (i686)
* wpa_actiond-1.2-1 (i686)
* kmod-7-1 (x86_64)
* linux-3.3-1 (x86_64)
* linux-lts-3.0.25-1 (x86_64)
* openssh-5.9p1-8 (x86_64)
* wpa_actiond-1.2-1 (x86_64)
* fcpci-31107-69 (i686)
* fcpcmcia-31107-65 (i686)
* lirc-1:0.9.0-13 (i686)
* nvidia-295.20-4 (i686)
* nvidia-lts-295.20-3 (i686)
* xf86-video-neomagic-1.2.5-7 (i686)
* fcpci-31107-69 (x86_64)
* fcpcmcia-31107-65 (x86_64)
* lirc-1:0.9.0-13 (x86_64)
* nvidia-295.20-4 (x86_64)
* nvidia-lts-295.20-3 (x86_64)
* xf86-video-neomagic-1.2.5-7 (x86_64)
* bootchart-1.15-1 (i686)
* bootchart-1.15-1 (x86_64)


== Incomplete signoffs for [core] (19 total) ==

* netcfg-2.7.1-1 (any)
0/2 signoffs
* bash-4.2.024-2 (i686)
1/2 signoffs
* dhcpcd-5.5.4-2 (i686)
0/2 signoffs
* dirmngr-1.1.0-4 (i686)
0/2 signoffs
* kmod-7-1 (i686)
0/2 signoffs
* linux-3.3-1 (i686)
0/2 signoffs
* linux-lts-3.0.25-1 (i686)
0/2 signoffs
* lvm2-2.02.95-1 (i686)
1/2 signoffs
* openldap-2.4.30-1 (i686)
0/2 signoffs
* openssh-5.9p1-8 (i686)
1/2 signoffs
* openssl-1.0.1-1 (i686)
0/2 signoffs
* psmisc-22.16-1 (i686)
1/2 signoffs
* syslinux-4.05-4 (i686)
1/2 signoffs
* wpa_actiond-1.2-1 (i686)
0/2 signoffs
* dhcpcd-5.5.4-2 (x86_64)
1/2 signoffs
* linux-lts-3.0.25-1 (x86_64)
1/2 signoffs
* openldap-2.4.30-1 (x86_64)
0/2 signoffs
* openssh-5.9p1-8 (x86_64)
1/2 signoffs
* wpa_actiond-1.2-1 (x86_64)
0/2 signoffs

== Incomplete signoffs for [extra] (20 total) ==

* fcpci-31107-69 (i686)
0/2 signoffs
* fcpcmcia-31107-65 (i686)
0/2 signoffs
* libdrm-2.4.32-1 (i686)
0/2 signoffs
* lirc-1:0.9.0-13 (i686)
0/2 signoffs
* neon-0.29.6-4 (i686)
0/2 signoffs
* nvidia-295.20-4 (i686)
0/2 signoffs
* nvidia-lts-295.20-3 (i686)
0/2 signoffs
* nx-common-3.5.0-4 (i686)
0/2 signoffs
* proftpd-1:1.3.4a-4 (i686)
0/2 signoffs
* xf86-video-neomagic-1.2.5-7 (i686)
0/2 signoffs
* fcpci-31107-69 (x86_64)
0/2 signoffs
* fcpcmcia-31107-65 (x86_64)
0/2 signoffs
* libdrm-2.4.32-1 (x86_64)
0/2 signoffs
* lirc-1:0.9.0-13 (x86_64)
0/2 signoffs
* neon-0.29.6-4 (x86_64)
0/2 signoffs
* nvidia-295.20-4 (x86_64)
1/2 signoffs
* nvidia-lts-295.20-3 (x86_64)
1/2 signoffs
* nx-common-3.5.0-4 (x86_64)
0/2 signoffs
* proftpd-1:1.3.4a-4 (x86_64)
0/2 signoffs
* xf86-video-neomagic-1.2.5-7 (x86_64)
0/2 signoffs

== Incomplete signoffs for [unknown] (5 total) ==

* archlinux-keyring-20120303-1 (any)
0/2 signoffs
* bootchart-1.15-1 (i686)
0/2 signoffs
* cups-filters-1.0.1-1 (i686)
0/2 signoffs
* bootchart-1.15-1 (x86_64)
0/2 signoffs
* cups-filters-1.0.1-1 (x86_64)
1/2 signoffs


== Completed signoffs (11 total) ==

* iproute2-3.2.0-3 (i686)
* bash-4.2.024-2 (x86_64)
* dirmngr-1.1.0-4 (x86_64)
* iproute2-3.2.0-3 (x86_64)
* kmod-7-1 (x86_64)
* linux-3.3-1 (x86_64)
* lvm2-2.02.95-1 (x86_64)
* openssl-1.0.1-1 (x86_64)
* psmisc-22.16-1 (x86_64)
* syslinux-4.05-4 (x86_64)
* bash-completion-1.99-1 (any)


== All packages in [testing] for more than 14 days (3 total) ==

* cups-filters-1.0.1-1 (i686), since 2012-02-17
* cups-filters-1.0.1-1 (x86_64), since 2012-02-17
* archlinux-keyring-20120303-1 (any), since 2012-03-03


== Top five in signoffs in last 24 hours ==

1. bisson - 10 signoffs
2. foutrelis - 4 signoffs
3. eric - 4 signoffs
4. thomas - 2 signoffs
 
Old 03-20-2012, 10:59 AM
"Stevenson, Sarah"
 
Default

Do you need loan for pay up your bills ?if yes contact us back via Email : mrchangloancompany@yahoo.com.hk
 
Old 03-20-2012, 02:58 PM
Székelyi Szabolcs
 
Default

Hi all,

when removing multipaths, I often end up with a situation like this:

# multipath -ll
3600000e00d0000000001185600010000 dm-2 ,
[size=4.3T][features=0][hwhandler=0][rw]
\_ round-robin 0 [prio=0][enabled]
\_ #:#:#:# - #:# [failed][faulty]

I'm unable to remove these stale maps, neither with dmsetup nor multipathd's
command line. Do you have any suggestions how to deal with this? It happens
with multipath-tools 0.4.8+git0.761c66f-10 on up to date Debian, kernel
version 2.6.32.

Thanks,
--
cc


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 03-21-2012, 03:40 AM
"Walter Dnes"
 
Default

On Tue, Mar 20, 2012 at 01:18:24AM +0200, Alan McKinnon wrote

> I'm not sure where you're going with this. We're discussing an init
> system and good, simple ways to start services. App maintainers are
> going to continue to do whatever they feel they ought to do, some might
> write the systemd files, some might not - that is what already
> happens. Someone has to write it and what goes in it depends on what
> the app code does, not the other way round.

The point I'm making is that if the initialization is moved into the
binary, then the binary will have to be patched/modified/whatever.
There's already somebody with a systemd overlay. Assuming that the
initialization code gets shoved into the binary, how does it
simultaneously support openrc/systemd/linux/bsd/Sun/HPUX/etc/etc? The
only realistic answer I see is leaving the init code to the distro
maintainer. We don't expect the upstream for sshd or any other software
to write Gentoo-specific stuff like ebuilds. Whey should they be
expected to write Gentoo-specific initscripts?

> As for the last question, I really have no idea where you're taking
> this. I don't know the answer, I've never been a maintainer in that
> position. Being the arrogant shit that I am, I reckon I would probably
> tell the user to piss off and I don't support hobby crap. But hey,
> that's just what I think I might say while sitting here on my couch.

So you're saying you wouldn't have supported...

> From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
> Newsgroups: comp.os.minix
> Subject: What would you like to see most in minix?
> Summary: small poll for my new operating system Message-ID: <1991Aug25.205708.9541@klaava.Helsinki.FI>
> Date: 25 Aug 91 20:57:08 GMT
> Organization: University of Helsinki
>
> Hello everybody out there using minix - I'm doing a (free) operating
> system (just a hobby, won't be big and professional like gnu) for
> 386(486) AT clones. This has been brewing since april, and is starting
> to get ready.I'd like any feedback on things people like/dislike in
> minix, as my OS resembles it somewhat (same physical layout of the
> file-system(due to practical reasons) among other things). I've
> currently ported bash(1.08) and gcc(1.40),and things seem to
> work.This implies that I'll get something practical within a few
> months, andI'd like to know what features most people would want.
> Any suggestions are welcome, but I won't promise I'll implement
> them :-) Linus (torvalds@kruuna.helsinki.fi) PS. Yes - it's free of
> any minix code, and it has a multi-threaded fs. It is NOT protable
> (uses 386 task switching etc), and it probably never will support
> anything other than AT-harddisks, as that's all I have :-(.

--
Walter Dnes <waltdnes@waltdnes.org>
 
Old 03-21-2012, 07:07 AM
Arch Website Notification
 
Default

=== Signoff report for [community-testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 1 new package in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 0 fully signed off packages
* 4 packages missing signoffs
* 0 packages older than 14 days

(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)


== New packages in [community-testing] in last 24 hours (1 total) ==

* virtualbox-modules-4.1.10-2 (i686)


== Incomplete signoffs for [community] (4 total) ==

* cdemu-daemon-1.5.0-2 (i686)
0/2 signoffs
* virtualbox-modules-4.1.10-2 (i686)
0/2 signoffs
* cdemu-daemon-1.5.0-2 (x86_64)
0/2 signoffs
* virtualbox-modules-4.1.10-2 (x86_64)
0/2 signoffs


== Top five in signoffs in last 24 hours ==

1. tomegun - 7 signoffs
2. dreisner - 6 signoffs
3. thomas - 5 signoffs
4. ibiru - 5 signoffs
5. andyrtr - 2 signoffs
 
Old 03-21-2012, 07:07 AM
Arch Website Notification
 
Default

=== Signoff report for [testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 12 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 7 fully signed off packages
* 33 packages missing signoffs
* 3 packages older than 14 days

(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)


== New packages in [testing] in last 24 hours (12 total) ==

* iproute2-3.3.0-1 (i686)
* isdn4k-utils-3.20-1 (i686)
* iproute2-3.3.0-1 (x86_64)
* isdn4k-utils-3.20-1 (x86_64)
* capi4hylafax-010300-6 (i686)
* fcpci-31107-70 (i686)
* fcpcmcia-31107-66 (i686)
* msmtp-1.4.27-2 (i686)
* capi4hylafax-010300-6 (x86_64)
* fcpci-31107-70 (x86_64)
* fcpcmcia-31107-66 (x86_64)
* msmtp-1.4.27-2 (x86_64)


== Incomplete signoffs for [core] (14 total) ==

* netcfg-2.7.1-1 (any)
1/2 signoffs
* dhcpcd-5.5.4-2 (i686)
0/2 signoffs
* dirmngr-1.1.0-4 (i686)
0/2 signoffs
* iproute2-3.3.0-1 (i686)
0/2 signoffs
* isdn4k-utils-3.20-1 (i686)
0/2 signoffs
* kmod-7-1 (i686)
1/2 signoffs
* linux-3.3-1 (i686)
0/2 signoffs
* linux-lts-3.0.25-1 (i686)
0/2 signoffs
* openldap-2.4.30-1 (i686)
0/2 signoffs
* wpa_actiond-1.2-1 (i686)
0/2 signoffs
* iproute2-3.3.0-1 (x86_64)
0/2 signoffs
* isdn4k-utils-3.20-1 (x86_64)
0/2 signoffs
* openldap-2.4.30-1 (x86_64)
0/2 signoffs
* wpa_actiond-1.2-1 (x86_64)
1/2 signoffs

== Incomplete signoffs for [extra] (14 total) ==

* capi4hylafax-010300-6 (i686)
0/2 signoffs
* fcpci-31107-70 (i686)
0/2 signoffs
* fcpcmcia-31107-66 (i686)
0/2 signoffs
* lirc-1:0.9.0-13 (i686)
0/2 signoffs
* msmtp-1.4.27-2 (i686)
0/2 signoffs
* nvidia-295.20-4 (i686)
0/2 signoffs
* nvidia-lts-295.20-3 (i686)
0/2 signoffs
* capi4hylafax-010300-6 (x86_64)
0/2 signoffs
* fcpci-31107-70 (x86_64)
0/2 signoffs
* fcpcmcia-31107-66 (x86_64)
0/2 signoffs
* lirc-1:0.9.0-13 (x86_64)
0/2 signoffs
* msmtp-1.4.27-2 (x86_64)
0/2 signoffs
* nvidia-295.20-4 (x86_64)
1/2 signoffs
* nvidia-lts-295.20-3 (x86_64)
1/2 signoffs

== Incomplete signoffs for [unknown] (5 total) ==

* archlinux-keyring-20120303-1 (any)
0/2 signoffs
* bootchart-1.15-1 (i686)
0/2 signoffs
* cups-filters-1.0.1-1 (i686)
0/2 signoffs
* bootchart-1.15-1 (x86_64)
1/2 signoffs
* cups-filters-1.0.1-1 (x86_64)
1/2 signoffs


== Completed signoffs (7 total) ==

* syslinux-4.05-4 (i686)
* dhcpcd-5.5.4-2 (x86_64)
* dirmngr-1.1.0-4 (x86_64)
* kmod-7-1 (x86_64)
* linux-3.3-1 (x86_64)
* linux-lts-3.0.25-1 (x86_64)
* syslinux-4.05-4 (x86_64)


== All packages in [testing] for more than 14 days (3 total) ==

* cups-filters-1.0.1-1 (i686), since 2012-02-17
* cups-filters-1.0.1-1 (x86_64), since 2012-02-17
* archlinux-keyring-20120303-1 (any), since 2012-03-03


== Top five in signoffs in last 24 hours ==

1. tomegun - 7 signoffs
2. dreisner - 6 signoffs
3. thomas - 5 signoffs
4. ibiru - 5 signoffs
5. andyrtr - 2 signoffs
 
Old 03-21-2012, 01:29 PM
Alan McKinnon
 
Default

On Wed, 21 Mar 2012 00:40:27 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:

> On Tue, Mar 20, 2012 at 01:18:24AM +0200, Alan McKinnon wrote
>
> > I'm not sure where you're going with this. We're discussing an init
> > system and good, simple ways to start services. App maintainers are
> > going to continue to do whatever they feel they ought to do, some
> > might write the systemd files, some might not - that is what already
> > happens. Someone has to write it and what goes in it depends on what
> > the app code does, not the other way round.
>
> The point I'm making is that if the initialization is moved into the
> binary, then the binary will have to be patched/modified/whatever.
> There's already somebody with a systemd overlay. Assuming that the
> initialization code gets shoved into the binary, how does it
> simultaneously support openrc/systemd/linux/bsd/Sun/HPUX/etc/etc? The
> only realistic answer I see is leaving the init code to the distro
> maintainer. We don't expect the upstream for sshd or any other
> software to write Gentoo-specific stuff like ebuilds. Whey should
> they be expected to write Gentoo-specific initscripts?

Fair enough

> > As for the last question, I really have no idea where you're taking
> > this. I don't know the answer, I've never been a maintainer in that
> > position. Being the arrogant shit that I am, I reckon I would
> > probably tell the user to piss off and I don't support hobby crap.
> > But hey, that's just what I think I might say while sitting here on
> > my couch.
>
> So you're saying you wouldn't have supported...

No, you're saying that you believe that you think I would say that
based on some extrapolation of I don't know what.

I said no such thing.
I said that I don't know what I would do

Let's not get too carried away with Linus's little project being
representative of anything. It's a fluke. There are 100s of other hobby
systems that went nowhere.



--
Alan McKinnnon
alan.mckinnon@gmail.com
 
Old 03-21-2012, 03:02 PM
Michael Mol
 
Default

On Wed, Mar 21, 2012 at 10:29 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Wed, 21 Mar 2012 00:40:27 -0400
> "Walter Dnes" <waltdnes@waltdnes.org> wrote:
>
>> On Tue, Mar 20, 2012 at 01:18:24AM +0200, Alan McKinnon wrote
>>
>> > I'm not sure where you're going with this. We're discussing an init
>> > system and good, simple ways to start services. App maintainers are
>> > going to continue to do whatever they feel they ought to do, some
>> > might write the systemd files, some might not - that is what already
>> > happens. Someone has to write it and what goes in it depends on what
>> > the app code does, not the other way round.
>>
>> * The point I'm making is that if the initialization is moved into the
>> binary, then the binary will have to be patched/modified/whatever.
>> There's already somebody with a systemd overlay. *Assuming that the
>> initialization code gets shoved into the binary, how does it
>> simultaneously support openrc/systemd/linux/bsd/Sun/HPUX/etc/etc? *The
>> only realistic answer I see is leaving the init code to the distro
>> maintainer. *We don't expect the upstream for sshd or any other
>> software to write Gentoo-specific stuff like ebuilds. *Whey should
>> they be expected to write Gentoo-specific initscripts?
>
> Fair enough
>
>> > As for the last question, I really have no idea where you're taking
>> > this. I don't know the answer, I've never been a maintainer in that
>> > position. Being the arrogant shit that I am, I reckon I would
>> > probably tell the user to piss off and I don't support hobby crap.
>> > But hey, that's just what I think I might say while sitting here on
>> > my couch.
>>
>> * So you're saying you wouldn't have supported...
>
> No, you're saying that you believe that you think I would say that
> based on some extrapolation of I don't know what.
>
> I said no such thing.
> I said that I don't know what I would do
>
> Let's not get too carried away with Linus's little project being
> representative of anything. It's a fluke. There are 100s of other hobby
> systems that went nowhere.

I said this before, but it sounds useful to try to reiterate:

* It's probable that service-specific files should not be included in
the init system package.
* Service-specific init files should probably be part of the
distro-localized version of a service-providing package.

This doesn't mean modifying binaries, this is part of bootstrapping a
service's environment. Call it "deferred installation stages", if you
like; things which need to be done for the service to be configured
and properly operate.



--
:wq
 
Old 03-21-2012, 09:55 PM
"Walter Dnes"
 
Default

On Wed, Mar 21, 2012 at 12:02:32PM -0400, Michael Mol wrote

> I said this before, but it sounds useful to try to reiterate:
>
> * It's probable that service-specific files should not be included in
> the init system package.
> * Service-specific init files should probably be part of the
> distro-localized version of a service-providing package.
>
> This doesn't mean modifying binaries, this is part of bootstrapping a
> service's environment. Call it "deferred installation stages", if you
> like; things which need to be done for the service to be configured
> and properly operate.

My point is that the startup, sanity-checking, and initialization code
has to go *SOMEWHERE*. Where do you propose moving it to? This
discussion reminds me of an ethnic joke. A bunch of workers had dug out
a hole for the basement and foundations where a new house was to be
built. The workers ask their foreman what they should do with the pile
of dirt they had from digging out the hole for the new house. Their
foreman, who is ____________ tells them to go dig another hole in the
ground and throw the dirt in there. <G>

--
Walter Dnes <waltdnes@waltdnes.org>
 
Old 03-22-2012, 12:35 AM
Michael Mol
 
Default

On Wed, Mar 21, 2012 at 6:55 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Wed, Mar 21, 2012 at 12:02:32PM -0400, Michael Mol wrote
>
>> I said this before, but it sounds useful to try to reiterate:
>>
>> * It's probable that service-specific files should not be included in
>> the init system package.
>> * Service-specific init files should probably be part of the
>> distro-localized version of a service-providing package.
>>
>> This doesn't mean modifying binaries, this is part of bootstrapping a
>> service's environment. Call it "deferred installation stages", if you
>> like; things which need to be done for the service to be configured
>> and properly operate.
>
> *My point is that the startup, sanity-checking, and initialization code
> has to go *SOMEWHERE*. *Where do you propose moving it to?

Sure. But there's a difference between moving, e.g. sshd's first-time
code into the net-misc/openssh package and moving it into the sshd
binary itself.

I don't want to sound condescending, but I really don't know how much
of this is going to be generally known on this list, and I get the
impression that it's unclear...

(Also, I'm not an expert on this...)

The distribution of software, as I understand it, generally has three
groups of people who hold it:

1) Upstream. Generally, upstream will keep their software portable and
agnostic, so it can be installed in a variety of places. That's not a
requirement, but it's considered polite in the open-source world, and
fairly necessary if they want the software to be broadly used.
Upstream is expected to know their software well enough to keep it in
active development, or at least in current maintenance.

2) Packager. A packager adapts upstream's software so that it fits in
and plays nicely with the rest of the software in the system. The
packager is expected to have the required understanding of both the
software and the target distribution in order to accomplish this.

3) End user. The end user isn't typically expected to have a full
understanding of the software or the distribution. He'll run the
distribution's package manager to install the software, follow any
instructions given for configuration, and apply any domain expertise
he has to configure things to conform to site-local needs.

What we're talking about with systemd vs openrc, and things like ssh'd
first-time initialization is all within the realm of responsibility of
the packager. It's a shift in the way the distribution itself works.
We're not talking about a scenario where you shunt things upstream, so
the whole "your position would have rejected Linux" angle is a red
herring.

Now, let's look at what an init system does. For each service, it
spawns some process, checks a return code, declares either success or
failure, and may take some further action based on that success or
failure.

Why does that spawned process have to be sshd? Why can't it be some
shell script which does the one-time checks, and then launches sshd
itself? Why does that shell script need to be distributed as part of
the init system's package, and not part of the package associated with
the service?

Having the shell script be part of the package associated with the
service keeps bugs related to that script associated with that
package.

As far as compatibility between init systems is concerned, you can
symlink the init system's launch file (e.g. /etc/init.d/some_file) to
wherever this shell script is, or you can configure the init system
such that it knows where the shell script is.

At least, that's the way I see it. Any issue of compatibility between
the two can be addressed by the service's package manager, either by
adaption via that script, or by expressing an explicit dependency on
one init architecture or another.

--
:wq
 

Thread Tools




All times are GMT. The time now is 07:52 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org