Re: PulseAudio

[Sune Vuorela]

On 2013-07-20, Andrei POPESCU  wrote:
> Have you been reading debian-user lately? One of the first=20
> recommendations is still "uninstall pulseaudio and see if it works".

I have no idea on how to get sane people writing answers on
debian-users. I personally run out of sanity when done with
debian-devel.

/Sune


-- 
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/slrnkuoi1b.j0.nos...@sshway.ssh.pusling.com

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Josselin Mouette]

Le samedi 20 juillet 2013 à 19:21 -0400, The Wanderer a écrit : 
> [I am almost certainly going to regret this.]

I hope so.

> Making the switch away from the entrenched sysvinit is visibly very
> difficult, at least as a social matter, even in the environment we have.
> systemd et al., by virtue of the integration which is apparently one of
> their selling points and the "proprietary"[0] interfaces they seem to
> use, look like they would create an environment where a similar switch
> to "whatever comes next" would be even harder - at least partly as a
> technical matter, rather than a social one.

Hey guys, I know this “Linux” thing is better than Minix, but it brings
a lot of new features that we will be growing accustomed to. If we ever
want to switch to Hurd one day, this is going to be much more
complicated.

This has to be one of the most twisted and bad faith arguments I ever
heard in a situation of change resistance.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
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/1374440648.4511.9.camel@tomoyo

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Roger Leigh]

On Sun, Jul 21, 2013 at 11:04:08PM +0200, Josselin Mouette wrote:
> Le samedi 20 juillet 2013 à 19:21 -0400, The Wanderer a écrit : 
> 
> > Making the switch away from the entrenched sysvinit is visibly very
> > difficult, at least as a social matter, even in the environment we have.
> > systemd et al., by virtue of the integration which is apparently one of
> > their selling points and the "proprietary"[0] interfaces they seem to
> > use, look like they would create an environment where a similar switch
> > to "whatever comes next" would be even harder - at least partly as a
> > technical matter, rather than a social one.
> 
> Hey guys, I know this “Linux” thing is better than Minix, but it brings
> a lot of new features that we will be growing accustomed to. If we ever
> want to switch to Hurd one day, this is going to be much more
> complicated.
> 
> This has to be one of the most twisted and bad faith arguments I ever
> heard in a situation of change resistance.

Not at all.  If we're looking a bit further ahead than just the
immediate discussion, then this is an legitimate concern.  We don't
want to paint ourselves into a corner we can't get out of.  With
the features and interfaces systemd offers, asking the question of
how we can move to something else in the future is entirely
reasonable, since it's quite likely that the answer would be that
it would be difficult and painful once it became pervasive and
entrenched.  We would be effectively "locked in".


-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
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/20130721214841.gc4...@codelibre.net

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[The Wanderer]

On 07/21/2013 05:04 PM, Josselin Mouette wrote:


Le samedi 20 juillet 2013 à 19:21 -0400, The Wanderer a écrit :


[I am almost certainly going to regret this.]


I hope so.


Please don't be a jerk.


Making the switch away from the entrenched sysvinit is visibly very
difficult, at least as a social matter, even in the environment we
have. systemd et al., by virtue of the integration which is
apparently one of their selling points and the "proprietary"[0]
interfaces they seem to use, look like they would create an
environment where a similar switch to "whatever comes next" would
be even harder - at least partly as a technical matter, rather than
a social one.


Hey guys, I know this “Linux” thing is better than Minix, but it
brings a lot of new features that we will be growing accustomed to.
If we ever want to switch to Hurd one day, this is going to be much
more complicated.


My objection has nothing whatsoever to do with "growing accustomed to
features". (The line further down about "without losing other
functionality" might have hinted at that fact.)

It has to do with A: lock-in to the interfaces of the current proposed
solution, even if those interfaces might not suit "whatever comes next",
and B: potential interdependency between the current proposed solution
and other (theoretically distinct) elements, such that you can't replace
one of them without replacing all of them - unless your replacement
exactly matches all of the interfaces of the current proposed solution.


I could go on at considerable length about what I mean by this and why
your sarcastic counterexample does not counter it, but I seriously doubt
you would be receptive, and this is probably not a good place for that
discussion. (Though the places which might be more appropriate probably
wouldn't welcome it either.)


This has to be one of the most twisted and bad faith arguments I ever
heard in a situation of change resistance.


My argument may perhaps be twisted (that's at least partly a matter of
perspective), but it is absolutely not in bad faith.

I made my previous post partly in hopes of drawing attention to my
honest concerns, and partly in hopes of having those concerns
convincingly shot down - and of thereby being reassured about the idea
of going forward with systemd. (As I've said, I actually like what I've
read about its functionality and so forth; if those concerns could be
eliminated, I'd be greatly looking forward to seeing it adopted.)

This sort of sneering, hostile response does not serve to convincingly
shoot down my concerns, or to reassure me about systemd. If anything, it
would probably have the opposite effect.

--
   The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
  - LiveJournal user antonia_tiger


--
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/51ec59bd.9080...@fastmail.fm

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Игорь Пашев]

2013/7/22 Roger Leigh :
>  We would be effectively "locked in".

We are locked in sysvinit.


-- 
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/call-q8xfw+ypmuiwagmn0fmvs1ovc+zc4obdbbserurudv-...@mail.gmail.com

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Russ Allbery]

Игорь Пашев  writes:
> 2013/7/22 Roger Leigh :

>> We would be effectively "locked in".

> We are locked in sysvinit.

Except we're not: both systemd and upstart support sysvinit scripts.
Which is why we can do a gradual migration, or even switch back and forth
between various alternatives.  However, the native formats of both systemd
and upstart (and, for that matter, OpenRC) are mutually incompatible, so
migration from one to another is much more difficult than migration from
sysvinit to any of the alternatives once a substantial number of init
scripts are written in the new format and the old init scripts are
dropped.

That's the point.

I can certainly see why people may not consider that a significant
drawback, or may consider other advantages more than worth that tradeoff,
and indeed we do make tradeoffs like that all the time.  I'm not horribly
worried about it personally.  But that doesn't change the fact that it
*is* a potential drawback.  If we adopt a single alternative and move a
substantial number of the current init scripts to the new format, we have
locked ourselves into that alternative in a more substantial way than we
currently have (where we're using a portable, if horrible, init format
that is supported by all the alternatives).

Come on, everyone.  We can maintain a higher quality level of discussion
than this.  Please stop trying to find gotchas in everyone else's
statements and instead take a little time to try to understand what
they're actually saying.  It's perfectly fine if you disagree or weigh
tradeoffs differently, but when people say that they're concerned about an
issue, they're probably neither lying nor idiots.  They're just concerned
about a different set of things than you are.

-- 
Russ Allbery (r...@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/87d2qb4jzh@windlord.stanford.edu

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Vincent Bernat]

 ❦ 21 juillet 2013 23:48 CEST, Roger Leigh  :

>> > Making the switch away from the entrenched sysvinit is visibly very
>> > difficult, at least as a social matter, even in the environment we have.
>> > systemd et al., by virtue of the integration which is apparently one of
>> > their selling points and the "proprietary"[0] interfaces they seem to
>> > use, look like they would create an environment where a similar switch
>> > to "whatever comes next" would be even harder - at least partly as a
>> > technical matter, rather than a social one.
>> 
>> Hey guys, I know this “Linux” thing is better than Minix, but it brings
>> a lot of new features that we will be growing accustomed to. If we ever
>> want to switch to Hurd one day, this is going to be much more
>> complicated.
>> 
>> This has to be one of the most twisted and bad faith arguments I ever
>> heard in a situation of change resistance.
>
> Not at all.  If we're looking a bit further ahead than just the
> immediate discussion, then this is an legitimate concern.  We don't
> want to paint ourselves into a corner we can't get out of.  With
> the features and interfaces systemd offers, asking the question of
> how we can move to something else in the future is entirely
> reasonable, since it's quite likely that the answer would be that
> it would be difficult and painful once it became pervasive and
> entrenched.  We would be effectively "locked in".

We are currently "locked in" with an old and ineffective init system. It
would be better to be "locked in" by something more modern.
-- 
Replace repetitive expressions by calls to a common function.
- The Elements of Programming Style (Kernighan & Plauger)


pgpCJAzPquwqJ.pgp
Description: PGP signature

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Matthias Klumpp]

2013/7/22 Russ Allbery :
> Игорь Пашев  writes:
>> 2013/7/22 Roger Leigh :
>
>>> We would be effectively "locked in".
>
>> We are locked in sysvinit.
>
> Except we're not: both systemd and upstart support sysvinit scripts.
> Which is why we can do a gradual migration, or even switch back and forth
> between various alternatives.  However, the native formats of both systemd
> and upstart (and, for that matter, OpenRC) are mutually incompatible, so
> migration from one to another is much more difficult than migration from
> sysvinit to any of the alternatives once a substantial number of init
> scripts are written in the new format and the old init scripts are
> dropped.
>
> That's the point.
>
> I can certainly see why people may not consider that a significant
> drawback, or may consider other advantages more than worth that tradeoff,
> and indeed we do make tradeoffs like that all the time.  I'm not horribly
> worried about it personally.  But that doesn't change the fact that it
> *is* a potential drawback.  If we adopt a single alternative and move a
> substantial number of the current init scripts to the new format, we have
> locked ourselves into that alternative in a more substantial way than we
> currently have (where we're using a portable, if horrible, init format
> that is supported by all the alternatives).
Well, if a new alternative is written in future, and there already is
a substantial number of scripts in $format, it will almost certainly
support these, and we can migrate away to the new system. It will be
the same situation as we currently have sith SysV-Init.
So I wouldn't worry about this at all :-)
Regards,
Matthias


--
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/caknhny9fvwc4thez6jmn8cezkhdrnzootxmhwxvfk37f1vg...@mail.gmail.com

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Uoti Urpala]

The Wanderer wrote:
> On 07/21/2013 05:04 PM, Josselin Mouette wrote:
> > Le samedi 20 juillet 2013 à 19:21 -0400, The Wanderer a écrit :
> >> Making the switch away from the entrenched sysvinit is visibly very
> >> difficult, at least as a social matter, even in the environment we
> >> have. systemd et al., by virtue of the integration which is
> >> apparently one of their selling points and the "proprietary"[0]
> >> interfaces they seem to use, look like they would create an
> >> environment where a similar switch to "whatever comes next" would
> >> be even harder - at least partly as a technical matter, rather than
> >> a social one.
> 
> > Hey guys, I know this “Linux” thing is better than Minix, but it
> > brings a lot of new features that we will be growing accustomed to.
> > If we ever want to switch to Hurd one day, this is going to be much
> > more complicated.
> 
> My objection has nothing whatsoever to do with "growing accustomed to
> features". (The line further down about "without losing other
> functionality" might have hinted at that fact.)

I think the Minix comparison is still a very valid one, whatever the
exact reasons are that you fear will make a future switch harder. Let's
assume there are very valid technical reasons why you think switching to
Linux will make a future move to Hurd harder than switching directly
from Minix would have been. Is this a good reason to stay with Minix for
now?

I think the above is a good parallel for the systemd situation. The
current alternatives are simply much worse than systemd. Staying with
them in the hope of some possible benefit in the far future is not sane.


> > This has to be one of the most twisted and bad faith arguments I ever
> > heard in a situation of change resistance.
> 
> My argument may perhaps be twisted (that's at least partly a matter of
> perspective), but it is absolutely not in bad faith.
> 
> I made my previous post partly in hopes of drawing attention to my
> honest concerns, and partly in hopes of having those concerns
> convincingly shot down - and of thereby being reassured about the idea
> of going forward with systemd. (As I've said, I actually like what I've
> read about its functionality and so forth; if those concerns could be
> eliminated, I'd be greatly looking forward to seeing it adopted.)

Whether your argument was honest or not, I think it was a bad one. OK,
perhaps you have concerns about the philosophy behind systemd and where
that might take it in the future. Such "philosophy" issues are rather
subjective. But your argument objectively fails at the "... and
therefore moving to systemd may not be the right choice" part. Your
concerns, even if taken seriously, do justify such a conclusion. If
systemd development goes in a direction you don't like, the rational
answer is to fork it and do better if you can. Leaving Debian behind
with an inferior init system is not an answer to your concerns.



-- 
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/1374451160.21442.60.camel@glyph.nonexistent.invalid

Bug#717532: RFP: odb - object-relational mapping (ORM) system for the C++ language

[Onur Aslan]

Package: wnpp
Severity: wishlist

* Package name: odb
  Version : 2.2.2
  Upstream Author : Code Synthesis
* URL : http://www.codesynthesis.com/products/odb/
* License : GPL-2
  Programming Lang: C++
  Description : object-relational mapping (ORM) system for the C++ language

ODB is an open-source, cross-platform, and cross-database object-relational
mapping (ORM) system for C++. It allows you to persist C++ objects to a
relational database without having to deal with tables, columns, or SQL and
without manually writing any mapping code. ODB supports MySQL, SQLite,
PostgreSQL, Oracle, and Microsoft SQL Server relational databases as well
as C++98/03 and C++11 language standards. It also comes with optional
profiles for Boost and Qt which allow you to seamlessly use value types,
containers, and smart pointers from these libraries in your persistent C++
classes.


-- 
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/20130722001214.ga27...@ev.onur.im

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[The Wanderer]

On 07/21/2013 07:06 PM, Matthias Klumpp wrote:


2013/7/22 Russ Allbery :


Игорь Пашев  writes:



We are locked in sysvinit.


Except we're not: both systemd and upstart support sysvinit
scripts. Which is why we can do a gradual migration, or even switch
back and forth between various alternatives.  However, the native
formats of both systemd and upstart (and, for that matter, OpenRC)
are mutually incompatible, so migration from one to another is much
more difficult than migration from sysvinit to any of the
alternatives once a substantial number of init scripts are written
in the new format and the old init scripts are dropped.

That's the point.

I can certainly see why people may not consider that a significant
drawback, or may consider other advantages more than worth that
tradeoff, and indeed we do make tradeoffs like that all the time.
I'm not horribly worried about it personally.  But that doesn't
change the fact that it *is* a potential drawback.


Thank you for understanding the idea.

I don't know if I'd even consider it a critical, fatal drawback myself;
if we do end up moving to systemd without this concern having been
addressed, I'm not likely to raise a screaming fit or go tearing my hair
out over it or anything.

But I would probably still go forward with a niggling sense of
discomfort, a sense that things aren't quite right, that my world
doesn't quite fit me the way it should - "there's a screw loose
somewhere, there is a leak in the tank", if that conveys the idea.


If we adopt a single alternative and move a substantial number of
the current init scripts to the new format, we have locked
ourselves into that alternative in a more substantial way than we
currently have (where we're using a portable, if horrible, init
format that is supported by all the alternatives).


Well, if a new alternative is written in future, and there already is
a substantial number of scripts in $format, it will almost certainly
support these, and we can migrate away to the new system.


My concern in that context is that having to support that format could
impose a limitation on the ability of the new alternative to provide
added functionality, just as having to live within the constraints of
sysvinit would (and, for the fallback case, ISTR allegedly does) impose
limits on the benefits that systemd can provide.

The potential need to also interoperate with the various other things
with which systemd apparently integrates (e.g. journald, and I think
other things - which may eventually include udev) *in the same way that
systemd then does* seems like it could also impose an even stronger
limitation on potential functionality; either you'd have to limit your
functionality to what that interoperation would support, or you'd have
to either fork those "other things" or implement replacements for them
as well. Either would make the process of implementing a new alternative
much bigger than just implementing a new init system; any new
alternative would then have to jump over considerably bigger hurdles
than systemd did.


It will be the same situation as we currently have sith SysV-Init.
So I wouldn't worry about this at all :-)


Isn't the current situation with trying to migrate from sysvinit plenty
bad enough?

--
   The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
  - LiveJournal user antonia_tiger


--
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/51ec7b9d.10...@fastmail.fm

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[The Wanderer]

On 07/21/2013 06:12 PM, Игорь Пашев wrote:


2013/7/22 Roger Leigh :


We would be effectively "locked in".


We are locked in sysvinit.


Agreed, to an extent we are. And you can see how hard it's being to
migrate away from that, even once alternatives have been implemented.

I'm saying that it looks to me as if the lock-in to systemd would be
even stronger than the lock-in to sysvinit, and might well extend to the
point of even making it harder to implement another new alternative in
the first place.


If someone implementing a new alternative wanted to retain the other
tools with which systemd integrates, that person would have to match
their interfaces, which might limit the functionality the new
alternative could be able to provide - much as having to match the
sysvinit interfaces would seem to limit the functionality systemd can
provide.

If someone implementing a new alternative didn't want to retain those
tools, then since those tools would have by then come to replace all the
non-integrated tools which now perform (lesser versions of?) the same
roles, that person would have to implement alternatives to all of them
as well - a potentially much bigger job than just implementing a new
init system.

--
   The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
  - LiveJournal user antonia_tiger


--
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/51ec7b61.5000...@fastmail.fm

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[brian m. carlson]

On Mon, Jul 22, 2013 at 02:59:20AM +0300, Uoti Urpala wrote:
> Whether your argument was honest or not, I think it was a bad one. OK,
> perhaps you have concerns about the philosophy behind systemd and where
> that might take it in the future. Such "philosophy" issues are rather
> subjective. But your argument objectively fails at the "... and
> therefore moving to systemd may not be the right choice" part. Your
> concerns, even if taken seriously, do justify such a conclusion. If
> systemd development goes in a direction you don't like, the rational
> answer is to fork it and do better if you can. Leaving Debian behind
> with an inferior init system is not an answer to your concerns.

Since Debian is always in need of developers and volunteers, it isn't
objectively reasonable to expect that forking a project will be
possible.  One thing that needs to be taken into consideration is the
*likelihood* that upstream will take development in an undesirable
direction, or in a direction that is not acceptable for Debian.

For example, if an upstream expresses disinterest in supporting non-PC
architectures, that may be a bad piece of software for Debian to place
in an important role, even if it currently works on all our
architectures, since Debian is very portable among different
architectures.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Let me introduce!

[Ian Sapelino]

Hello guys!! I am Ian Sapelino I am also Programmer and I want to know how
to make a Debian Based OS??

Please reply to my answer! Thank you :)

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Zbigniew Jędrzejewski-Szmek]

On Sun, Jul 21, 2013 at 05:59:25PM -0400, The Wanderer wrote:
> On 07/21/2013 05:04 PM, Josselin Mouette wrote:
> 
> >Le samedi 20 juillet 2013 à 19:21 -0400, The Wanderer a écrit :
> >
> >>[I am almost certainly going to regret this.]
> >
> >I hope so.
> 
> Please don't be a jerk.
> 
> >>Making the switch away from the entrenched sysvinit is visibly very
> >>difficult, at least as a social matter, even in the environment we
> >>have. systemd et al., by virtue of the integration which is
> >>apparently one of their selling points and the "proprietary"[0]
> >>interfaces they seem to use, look like they would create an
> >>environment where a similar switch to "whatever comes next" would
> >>be even harder - at least partly as a technical matter, rather than
> >>a social one.
> >
> >Hey guys, I know this “Linux” thing is better than Minix, but it
> >brings a lot of new features that we will be growing accustomed to.
> >If we ever want to switch to Hurd one day, this is going to be much
> >more complicated.
> 
> My objection has nothing whatsoever to do with "growing accustomed to
> features". (The line further down about "without losing other
> functionality" might have hinted at that fact.)
> 
> It has to do with A: lock-in to the interfaces of the current proposed
> solution, even if those interfaces might not suit "whatever comes next",
> and B: potential interdependency between the current proposed solution
> and other (theoretically distinct) elements, such that you can't replace
> one of them without replacing all of them - unless your replacement
> exactly matches all of the interfaces of the current proposed solution.
Hi,

I think that in the end you are worried about lock-in due to features,
not anything else. Replacing systemd, in part or in whole, is hard
only because of compelling features, not found in other systems. There
is no classical lock-in in the sense of e.g. undocumented and brittle
interfaces, APIs or syntax, or the inability to retrieve existing
data. The unit syntax is trivial to parse, meaning of various items is
documented, and in general it is pretty easy to substitue one provider
of a dbus interface for another. A similar situation is true in the
case of the journal, which (for producers) provides just a few simple
C functions.

And there *are* examples of piecewise replacement:
- Ubuntu is using just logind, without using systemd. Probably
  the hardest part is building journald cleanly, without the
  rest of systemd. And if you were implementing a replacemnt,
  this problem wouldn't exist.
- rsyslog provides a replacement of the journal logging API,
  allowing one to use journal logging functions on systemd-journald-less
  systemd.
- rsyslog slurps journal files, so if for whatever reason you
  wanted to stop even using journalctl, you could pull in
  the data into another logging solution from disk without any
  trouble. (There are other ways to retrieve this data, but I
  mention this one because it is a different program reading the same
  data, i.e. a reimplementation.)

Zbyszek
-- 
they are not broken. they are refucktored
   -- alxchk


-- 
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/20130722023959.gi28...@in.waw.pl

Bug#717538: ITP: python-django-oauth-plus -- Support of OAuth 1.0a in Django using python-oauth2

[Kouhei Maeda]

Package: wnpp
Severity: wishlist
Owner: Kouhei Maeda 

* Package name: python-django-oauth-plus
  Version : 2.1.2
  Upstream Author : David Larlet 
* URL : http://code.larlet.fr/django-oauth-plus/
* License : BSD
  Programming Lang: Python
  Description : Support of OAuth 1.0a in Django using python-oauth2

 The OAuth protocol enables websites or applications (Consumers) to access
 Protected Resources from a web service (Service Provider) via an API, without
 requiring Users to disclose their Service Provider credentials to the
 Consumers. More generally, OAuth creates a freely-implementable and generic
 methodology for API authentication.


-- 
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/20130722025355.8322.30277.report...@vmdeb.cyberagent.co.jp

Grub 2.00 in testing?

[Carl Johnson]

Does anybody know what is going on with grub in testing?  I have been
waiting for 2.00, but it seems to be stuck at 1.99.  Grub-common at
http://packages.debian.org/jessie/grub-common shows that it is at
1.99-27+deb7u1, but the source files show 2.00-14.  The qa page at
http://packages.qa.debian.org/g/grub2.html shows that 2.00-14 was
migrated to testing on 2013-06-14, so there appear to be some
inconsistancies.

I am not subscribed, so I would appreciate a cc, although I will monitor
the web interface.  I asked this on debian-user, but there were no
answers there.

Thanks.
-- 
Carl Johnsonca...@peak.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/871u6r5kg1.fsf@oak.localnet

Bug#717542: ITP: python-shortuuid -- generates concise, unambiguous, URL-safe UUIDs

[Kouhei Maeda]

Package: wnpp
Severity: wishlist
Owner: Kouhei Maeda 

* Package name: python-shortuuid
  Version : 0.3
  Upstream Author : Stochastic Technologies
* URL : https://github.com/stochastic-technologies/shortuuid/
* License : BSD
  Programming Lang: Python
  Description : generates concise, unambiguous, URL-safe UUIDs

 Often, one needs to use non-sequential IDs in places where users will see them,
 but the IDs must be as concise and easy to use as possible. shortuuid solves
 this problem by generating uuids using Python's built-in uuid module and then
 translating them to base57 using lowercase and uppercase letters and digits,
 and removing similar-looking characters such as l, 1, I, O and 0.


-- 
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/20130722053153.14553.38683.report...@vmdeb.cyberagent.co.jp

Why we need supervision in init(1)

[Ondřej Surý]

Hi,

JFTR this is yet another example: #681088, why we really need a native
supervision of the daemons and where (apart from switching from quagga to
bird :) the supervision would have helped tremendously instead of writing
yet-another-supervision-script.

O.
-- 
Ondřej Surý 

Re: Grub 2.00 in testing?

[Andreas Metzler]

On 2013-07-22 Carl Johnson  wrote:
> Does anybody know what is going on with grub in testing?  I have been
> waiting for 2.00, but it seems to be stuck at 1.99.  Grub-common at
> http://packages.debian.org/jessie/grub-common shows that it is at
> 1.99-27+deb7u1, but the source files show 2.00-14.  The qa page at
> http://packages.qa.debian.org/g/grub2.html shows that 2.00-14 was
> migrated to testing on 2013-06-14, so there appear to be some
> inconsistancies.
[...]

Hello,

FYI I think your analysis is correct, I cannot find anything obvious.

I guess some manual intervention happened.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
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/20130722062315.ga3...@downhill.g.la

Re: Grub 2.00 in testing?

[Adam D. Barratt]

On Sun, 2013-07-21 at 20:42 -0700, Carl Johnson wrote:
> Does anybody know what is going on with grub in testing?  I have been
> waiting for 2.00, but it seems to be stuck at 1.99.  Grub-common at
> http://packages.debian.org/jessie/grub-common shows that it is at
> 1.99-27+deb7u1, but the source files show 2.00-14.  The qa page at
> http://packages.qa.debian.org/g/grub2.html shows that 2.00-14 was
> migrated to testing on 2013-06-14, so there appear to be some
> inconsistancies.

The migration notification is in error; it's a bug in the script that
generates the notifications, that doesn't ignore extra entries included
in the Sources files added by the archive management software in order
to help with some license compliance. Now that we're aware of it, that
bug will be fixed.

As you mention checking the Sources files, I suspect you've made the
same (reasonable) mistake that the script is currently making - if the
stanza has "Extra-Source-Only: yes" then it is only there for compliance
and does not indicate that the package is in testing.

Apologies for the confusion; grub2 2.00 has indeed not yet made it to
testing.

Regards,

Adam


-- 
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/1374474982.5881.49.ca...@jacala.jungle.funky-badger.org

Re: Grub 2.00 in testing?

[Andrey Rahmatullin]

On Mon, Jul 22, 2013 at 07:36:22AM +0100, Adam D. Barratt wrote:
> The migration notification is in error; it's a bug in the script that
> generates the notifications, that doesn't ignore extra entries included
> in the Sources files added by the archive management software in order
> to help with some license compliance. Now that we're aware of it, that
> bug will be fixed.
> 
> As you mention checking the Sources files, I suspect you've made the
> same (reasonable) mistake that the script is currently making - if the
> stanza has "Extra-Source-Only: yes" then it is only there for compliance
> and does not indicate that the package is in testing.
See also e.g. rmadison:

 grub2 | 2.00-14   | jessie | source

-- 
WBR, wRAR


-- 
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/20130722064216.ga24...@belkar.wrar.name