On Thu, 4 Mar 2010, Enrico Scholz wrote:
[ two year tor insanity ]
It's been two years. I'm done with this discussion. I'm not spending more
time on the "tor-enrico" pacakge.
Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Kevin Kofler writes:
>>> The mandatory (MUST) guideline is that %post MUST NOT OUTPUT anything
>>
>> this means only output like license agreements, but not diagnostic
>> output on stderr
>
> No, diagnostic output is also not allowed,
from where do you have this information?
> especially not
Enrico Scholz wrote:
> Kevin Kofler writes:
>> The mandatory (MUST) guideline is that %post MUST NOT OUTPUT anything
>
> this means only output like license agreements, but not diagnostic
> output on stderr
No, diagnostic output is also not allowed, especially not when the failure
is not going
On Thu, 4 Mar 2010, Kevin Kofler wrote:
> Enrico Scholz wrote:
>> %post can give out something; e.g. '%post failed' which would happen
>> here due to the redhat-lsb bug. I just give out a more useful message
>> than '%post failed' which helps people to identify the problem.
>
> %post MUST *NEVER*
Kevin Kofler writes:
>> %post can give out something; e.g. '%post failed' which would happen
>> here due to the redhat-lsb bug. I just give out a more useful message
>> than '%post failed' which helps people to identify the problem.
>
> %post MUST *NEVER* FAIL!!!
that's why it executes a workar
Enrico Scholz wrote:
> %post can give out something; e.g. '%post failed' which would happen
> here due to the redhat-lsb bug. I just give out a more useful message
> than '%post failed' which helps people to identify the problem.
%post MUST *NEVER* FAIL!!!
The mandatory (MUST) guideline is that
Paul Wouters writes:
>>> Upstream reports a logging bug.
>>
>> ??? You and Noa Resare were the only one who reported the non-logging as
>> a bug and some posts ago you said that you are not upstream. So, why do
>> you think that upstream reported a logging bug?
>
> I pointed you to http://bugs.n
On Wed, 3 Mar 2010, Enrico Scholz wrote:
>> Upstream reports a logging bug.
>
> ??? You and Noa Resare were the only one who reported the non-logging as
> a bug and some posts ago you said that you are not upstream. So, why do
> you think that upstream reported a logging bug?
I pointed you to ht
On 03/04/2010 01:42 AM, Enrico Scholz wrote:
>
> its a bug in redhat-lsb (https://bugzilla.redhat.com/show_bug.cgi?id=522053),
> not tor
>
Why do you have a dependency on redhat-lsb ?
Rahul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/de
Paul Wouters writes:
> Upstream reports a logging bug.
??? You and Noa Resare were the only one who reported the non-logging as
a bug and some posts ago you said that you are not upstream. So, why do
you think that upstream reported a logging bug?
> WONTFIX; The alternative would be so
On Wed, Mar 03, 2010 at 02:26:19PM -0500, Paul Wouters wrote:
> Upstream reports a logging bug. You claim to know better and WONTFIX
> because obviously you have more experience in the legalities of running
> tor nodes and the police then upstream does..
What is the big problem with the disab
On Wed, 3 Mar 2010, Enrico Scholz wrote:
The tor upstream has filed that as bug report as well.
>>>
>>> ... and understand my reasons not to activate logging
>>
>> That is not true. It just decided not to pick a fight over that while
>> more pressing bugs required you to fix them.
>
> ok; sor
Enrico Scholz wrote:
> please do not blame me for redhat-lsb packaging...
You're not being blamed for the redhat-lsb packaging but for requiring
redhat-lsb in the first place. That package is not supposed to be required
by Fedora packages.
Kevin Kofler
--
devel mailing list
devel@list
"Chen Lei" writes:
> BTW, /var/lib/tor-data seems not used at all, maybe this directory
> should not be included in tor-core?
thx; was a leftover from GeoIP stuff which was removed due to anonymity
reasons. It will be fixed in the next packages.
Enrico
--
devel mailing list
devel@lists.fedor
Kevin Kofler writes:
>> Upstart does not have a good way yet to disable/enable service so you
>> have to edit /etc/init/tor.conf resp. /etc/event.d/tor manually.
>
> Which is one of the reasons why you aren't supposed to use native
> Upstarts scripts yet!
it's a somehow strange situation... ther
James Antill writes:
> You are joking, right? I mean apart from the fact that there is a
> _huge_ difference between requiring "mount" and "libX*" ...
please do not blame me for redhat-lsb packaging...
> the _kernel_ requires the package initscripts is installed.
initscripts are not required
Paul Wouters writes:
>>> The tor upstream has filed that as bug report as well.
>>
>> ... and understand my reasons not to activate logging
>
> That is not true. It just decided not to pick a fight over that while
> more pressing bugs required you to fix them.
ok; sorry that I thought that you w
On Tue, 2010-03-02 at 20:31 +0100, Enrico Scholz wrote:
> Adam Williamson writes:
>
> > I'm not quite sure why it needs separate lsb/upstart init scripts
> > anyway.
>
> All the initscripts have huge and broken dependency chains.
> E.g. assuming I would use the vanilla fedora 'initscripts' pack
I think redhat-lsb should be forbideen strictly to be used in official fedora
and rpmfusion package, it's can only be used by third-part sofiware develpers
and packagers who do not familiar with fedora and want their packagers to
support multiple linux platform.
redhat-lsb is an encumbrance for
Enrico Scholz wrote:
> Upstart does not have a good way yet to disable/enable service so you
> have to edit /etc/init/tor.conf resp. /etc/event.d/tor manually.
Which is one of the reasons why you aren't supposed to use native Upstarts
scripts yet!
We have packaging guidelines to follow for inits
Paul Wouters wrote:
> As noted before, the issue here is the Enrico is packging "his tor
> package", going against the desires of both Fedora guidelines and Tor
> upstream.
It's really that Enrico is inventing his own baroque packaging system for
initscripts, with a bizarre mess of subpackages, w
Eric Sandeen wrote:
> Should be easy to fix (but too bad doing it that way results in such
> punishment!)
As far as I can tell, the package is not compliant with our packaging
guidelines (see the guidelines for initscripts) and as such can be fixed by
any provenpackager.
Kevin Kofler
-
On Tue, 2 Mar 2010, Enrico Scholz wrote:
>> It does not log anything because Enrico broke logging in tor package.
>
> Not that this was the reason, but it is the upstream setup to have
> logging disabled. Your comment is unrelated to this discussion because
> logging can be done into a file and d
Paul Wouters writes:
>>> All the initscripts have huge and broken dependency chains.
>>> E.g. assuming I would use the vanilla fedora 'initscripts' package, then
>>> tor would still require[1] syslog, cpio, e2fsprogs, ethtool, mount, ...
>>> although it does not log anything, does not extract/pac
On Tue, Mar 02, 2010 at 02:21:55PM -0500, Seth Vidal wrote:
>
>
> On Tue, 2 Mar 2010, Enrico Scholz wrote:
>
> > Jesse Keating writes:
> >
> >> On Tue, 2010-03-02 at 12:37 -0500, Dave Jones wrote:
> >>> --> Processing Dependency: tor-lsb = 0.2.1.23-1200.fc12 for package:
> >>> tor-0.2.1.23-1200
On Tue, 2 Mar 2010, Bill Nottingham wrote:
> Enrico Scholz (enrico.sch...@informatik.tu-chemnitz.de) said:
>> All the initscripts have huge and broken dependency chains.
>> E.g. assuming I would use the vanilla fedora 'initscripts' package, then
>> tor would still require[1] syslog, cpio, e2fspro
Eric Sandeen (sand...@redhat.com) said:
> I'm guessing e2fsprogs may have been sucked in due to the various tools it
> has (had) in its junkbox. Lots of those which are not ext2-specific (blkid
> for example) have been split out or moved to util-linux-ng.
Sort of.
...
* Mon Oct 05 1998 Cristian
Bill Nottingham wrote:
> Bill Nottingham (nott...@redhat.com) said:
>>> All the initscripts have huge and broken dependency chains.
>>> E.g. assuming I would use the vanilla fedora 'initscripts' package, then
>>> tor would still require[1] syslog, cpio, e2fsprogs, ethtool, mount, ...
>>> although
Bill Nottingham writes:
>> E.g. assuming I would use the vanilla fedora 'initscripts' package,
>> then tor would still require[1] syslog, cpio, e2fsprogs, ethtool,
>> mount, ... although it does not log anything, does not extract/pack
>> anything, does not format a filesystem, does not configure
Bill Nottingham (nott...@redhat.com) said:
> > All the initscripts have huge and broken dependency chains.
> > E.g. assuming I would use the vanilla fedora 'initscripts' package, then
> > tor would still require[1] syslog, cpio, e2fsprogs, ethtool, mount, ...
> > although it does not log anything,
Enrico Scholz (enrico.sch...@informatik.tu-chemnitz.de) said:
> > I'm not quite sure why it needs separate lsb/upstart init scripts
> > anyway.
>
> All the initscripts have huge and broken dependency chains.
> E.g. assuming I would use the vanilla fedora 'initscripts' package, then
> tor would s
Dave Jones writes:
> > | yum install tor-core tor-upstart
>
> still no good, because tor-upstart requires tor which requires tor-lsb
> which...
thx for noticing this; this requirement is broken and has been fixed
now. I did not noticed it myself because I use yet another instance of
'init(tor)
On 03/02/2010 07:48 PM, Dave Jones wrote:
> The tor package is at least fixable.
Over the dead body of the current package maintainer. That's the root of
the problem.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, 2010-03-02 at 20:31 +0100, Enrico Scholz wrote:
> Adam Williamson writes:
>
> > I'm not quite sure why it needs separate lsb/upstart init scripts
> > anyway.
>
> All the initscripts have huge and broken dependency chains.
> E.g. assuming I would use the vanilla fedora 'initscripts' pack
On Tue, Mar 02, 2010 at 08:23:22PM +0100, Enrico Scholz wrote:
> Enrico Scholz writes:
>
> > | yum install tor tor-upstart
>
> should be
>
> | yum install tor-core tor-upstart
still no good, because tor-upstart requires tor which requires tor-lsb which...
Dave
--
devel mailin
Adam Williamson writes:
> I'm not quite sure why it needs separate lsb/upstart init scripts
> anyway.
All the initscripts have huge and broken dependency chains.
E.g. assuming I would use the vanilla fedora 'initscripts' package, then
tor would still require[1] syslog, cpio, e2fsprogs, ethtool,
Enrico Scholz writes:
> | yum install tor tor-upstart
should be
| yum install tor-core tor-upstart
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, 2 Mar 2010, Enrico Scholz wrote:
> Jesse Keating writes:
>
>> On Tue, 2010-03-02 at 12:37 -0500, Dave Jones wrote:
>>> --> Processing Dependency: tor-lsb = 0.2.1.23-1200.fc12 for package:
>>> tor-0.2.1.23-1200.fc12.i686
>>
>> This is where things go to hell. Why in the hell is tor-lsb
Dave Jones writes:
> (12:24:07:r...@firewall:~)# yum install tor
fwiw; when you can not wait for a fixed redhat-lsb package, do
| yum install tor tor-upstart
Upstart does not have a good way yet to disable/enable service so you
have to edit /etc/init/tor.conf resp. /etc/event.d/tor manually.
Jesse Keating writes:
> On Tue, 2010-03-02 at 12:37 -0500, Dave Jones wrote:
>> --> Processing Dependency: tor-lsb = 0.2.1.23-1200.fc12 for package:
>> tor-0.2.1.23-1200.fc12.i686
>
> This is where things go to hell. Why in the hell is tor-lsb /required/
> by tor?
tor-lsb requires only lsb-co
Adam Williamson (awill...@redhat.com) said:
> > > I'm not quite sure why it needs separate lsb/upstart init scripts
> > > anyway. Don't most of our packages just include one initscript with both
> > > bits in the headers?
> >
> > No. A package could have either a SystemV init script or an upstart
On Tue, Mar 02, 2010 at 01:43:13PM -0500, Paul Wouters wrote:
> On Tue, 2 Mar 2010, Bill Nottingham wrote:
>
> > Adam Williamson (awill...@redhat.com) said:
> >>> We should make a stand and drop it from Fedora until it's not made up of
> >>> bonghits and failure. (haha, yeah. thanks, here al
On Tue, 2 Mar 2010, Bill Nottingham wrote:
> Adam Williamson (awill...@redhat.com) said:
>>> We should make a stand and drop it from Fedora until it's not made up of
>>> bonghits and failure. (haha, yeah. thanks, here all week, etc)
>>
>> I'm not quite sure why it needs separate lsb/upstart init
On Tue, 2010-03-02 at 13:25 -0500, Bill Nottingham wrote:
> Adam Williamson (awill...@redhat.com) said:
> > > We should make a stand and drop it from Fedora until it's not made up of
> > > bonghits and failure. (haha, yeah. thanks, here all week, etc)
> >
> > I'm not quite sure why it needs sepa
Adam Williamson (awill...@redhat.com) said:
> > We should make a stand and drop it from Fedora until it's not made up of
> > bonghits and failure. (haha, yeah. thanks, here all week, etc)
>
> I'm not quite sure why it needs separate lsb/upstart init scripts
> anyway. Don't most of our packages j
On Tue, 2010-03-02 at 13:14 -0500, Dave Jones wrote:
> On Tue, Mar 02, 2010 at 09:51:17AM -0800, Jesse Keating wrote:
> > On Tue, 2010-03-02 at 12:37 -0500, Dave Jones wrote:
> > > --> Processing Dependency: tor-lsb = 0.2.1.23-1200.fc12 for package:
> > > tor-0.2.1.23-1200.fc12.i686
> >
> > T
On Tue, 2 Mar 2010, Dave Jones wrote:
> On Tue, Mar 02, 2010 at 09:51:17AM -0800, Jesse Keating wrote:
> > On Tue, 2010-03-02 at 12:37 -0500, Dave Jones wrote:
> > > --> Processing Dependency: tor-lsb = 0.2.1.23-1200.fc12 for package:
> > > tor-0.2.1.23-1200.fc12.i686
> >
> > This is where thing
On Tue, Mar 02, 2010 at 09:51:17AM -0800, Jesse Keating wrote:
> On Tue, 2010-03-02 at 12:37 -0500, Dave Jones wrote:
> > --> Processing Dependency: tor-lsb = 0.2.1.23-1200.fc12 for package:
> > tor-0.2.1.23-1200.fc12.i686
>
> This is where things go to hell. Why in the hell is tor-lsb /requ
On Tue, Mar 02, 2010 at 01:06:25PM -0500, Seth Vidal wrote:
> but if it isn't, then tor-upstart requires tor which is going to require
> tor-lsb.
> yes - that's never going to end well.
https://bugzilla.redhat.com/show_bug.cgi?id=569933
--
Matthew Miller
Senior Systems Architect -- Instructio
Le mardi 02 mars 2010 à 09:51 -0800, Jesse Keating a écrit :
> On Tue, 2010-03-02 at 12:37 -0500, Dave Jones wrote:
> > --> Processing Dependency: tor-lsb = 0.2.1.23-1200.fc12 for package:
> > tor-0.2.1.23-1200.fc12.i686
>
> This is where things go to hell. Why in the hell is tor-lsb /required/
>
y
On Tue, 2 Mar 2010, David Malcolm wrote:
> On Tue, 2010-03-02 at 12:37 -0500, Dave Jones wrote:
>> So after having heard the nth discussion about tor, I decided to check it
>> out.
>> I tried installing it on a stripped down f12 box that has no X, or other
>> stuff
>> unnecessary for routing
On Tue, Mar 02, 2010 at 12:59:52PM -0500, Seth Vidal wrote:
> especially considering what it provides :(
> repoquery -ql tor-lsb
> /etc/rc.d/init.d/tor
> /var/run/tor
Check out the post/preun scripts:
%post lsb
/usr/lib/lsb/install_initd %_initrddir/tor || {
cat <&2
oouch
On Tue, 2010-03-02 at 12:37 -0500, Dave Jones wrote:
> So after having heard the nth discussion about tor, I decided to check it out.
> I tried installing it on a stripped down f12 box that has no X, or other stuff
> unnecessary for routing network packets.
>
> What happened next has me lost for w
Jesse Keating wrote:
> On Tue, 2010-03-02 at 12:37 -0500, Dave Jones wrote:
>> --> Processing Dependency: tor-lsb = 0.2.1.23-1200.fc12 for package:
>> tor-0.2.1.23-1200.fc12.i686
>
> This is where things go to hell. Why in the hell is tor-lsb /required/
> by tor? LSB isn't really good for anythi
On Tue, 2 Mar 2010, Jesse Keating wrote:
> On Tue, 2010-03-02 at 12:37 -0500, Dave Jones wrote:
>> --> Processing Dependency: tor-lsb = 0.2.1.23-1200.fc12 for package:
>> tor-0.2.1.23-1200.fc12.i686
>
> This is where things go to hell. Why in the hell is tor-lsb /required/
> by tor? LSB isn't
On Tue, 2010-03-02 at 12:37 -0500, Dave Jones wrote:
> --> Processing Dependency: tor-lsb = 0.2.1.23-1200.fc12 for package:
> tor-0.2.1.23-1200.fc12.i686
This is where things go to hell. Why in the hell is tor-lsb /required/
by tor? LSB isn't really good for anything except landing a bunch of
cr
56 matches
Mail list logo
