Jamie Nguyen writes:
> Thanks very much for adding me as a co-maintainer. I guess that you
> probably don't have much time for updating the Tor package, so I'm glad
> to be on board and will be taking a very active role in maintaining the
> package so that you can spend time on other things. I ha
Michael Scherer writes:
> - a script with lots of iptables calls ( quite awful, slow and
> unauditable in practice as Reindl explained in another mail, and as I
> too often seen at customers deployment )
> - a script that run 1 command, iptables-restore < file. Which is
> equally as awful and u
Adam Williamson writes:
>> > - don't auto-page;
>>
>> yes; that's the best solution. The auto-pager is perhaps the most
>> annoying feature of systemd. I have no problem in scrolling back some
>> pages in my terminal with shift-pgup, but having a status request block
>> (plain 'systemctl' or
Matthew Miller writes:
> - don't auto-page;
yes; that's the best solution. The auto-pager is perhaps the most
annoying feature of systemd. I have no problem in scrolling back some
pages in my terminal with shift-pgup, but having a status request block
(plain 'systemctl' or 'journalctl' reque
Todd Zullinger writes:
>>> Doing this would break current users that have already configured
>>> their system to use __git_ps1().
>>
>> What are "current users"? Those who installed your just released
>> rawhide changes?
>
> No, it breaks anyone that's currently using __git_ps1(), as the
> functi
Todd Zullinger writes:
>>> I placed git-prompt.sh in /etc/profile.d where it should be sourced
>>> for normal login shells.
>>
>> As I wrote in the update comment, please revert it. It pollutes the
>> environment of every user with functions which are probably never be
>> used.
> ...
> Doing thi
Todd Zullinger writes:
> I placed git-prompt.sh in /etc/profile.d where it should be sourced
> for normal login shells.
As I wrote in the update comment, please revert it. It pollutes the
environment of every user with functions which are probably never be
used.
As these functions are useless
Richard Shaw writes:
> I like the idea of quilt but I can't seem to find the magic recipe to
> get it to integrate with rpmbuild.
I use an %apply macro in ways like
| %apply -n4 -p1
which is equivalent to
| %patch4 -p1
on ordinary hosts. But defining this macro as
| %apply(p:n:b:)
Ralph Lange writes:
> Today I had to learn that the koji client, while being the only way to
> request a build, does not support proxies.
yes; like most python programs it does not have proper proxy support.
> In a university like environment with no open ports whatsoever, with
> an increasin
Jesse Keating writes:
> I want to build a new libfoo for rawhide:
> fedpkg build
where can be done local customization like in ~/.cvsextrasrc?
E.g. I set
| BUILD_CLIENT = ${HOME}/bin/tkoji
| KOJI_FLAGS= --nowait
there.
> fedpkg new-sources [ ]
Where can be defined hooks for these o
Bill Nottingham writes:
> I suspect the biggest issue here is confined daemons, as they may
> not have permissions to create their own directories in /var/run
is this really an issue? upstart (and systemd probably too) work best
with non forking daemons so that the pidfile hack is not needed a
Tomas Mraz writes:
>> We never remove users or groups created by packages.
>
> Someone should perhaps correct the
> http://fedoraproject.org/wiki/PackageUserCreation then.
fwiw, %__fe_userdel + %__fe_groupdel evaluate to a noop in rawhide
(unless, '--with fedora_userdel' is set).
Enrico
--
de
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
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
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
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
"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
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
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
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)
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
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
Roland McGrath writes:
> So the generic advice is to put:
>
> /* GNU ld script
thx; adding this comment fixed the ldconfig issue.
Enrico
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Kevin Kofler writes:
>> | ldconfig: /usr/lib64/libxmlrpc_client.so is not an ELF file - it has the
>> | wrong magic bytes at the start.
> ...
> Check the library's DT_SONAME field, it should be libxmlrpc.so.3, not
> libxmlrpc.so (which I suspect it is).
should be ok:
$ readelf -a /usr/lib64/li
Hi,
after replacing .so files with linker scripts, I get
| ldconfig: /usr/lib64/libxmlrpc_client.so is not an ELF file - it has the
wrong magic bytes at the start.
from /sbin/ldconfig calls. File above is
| $ ls -l /usr/lib64/libxmlrpc_client.so
| -rw-r--r--. 1 root root 108 15. Feb 22:34 /us
Gerd Hoffmann writes:
> Well. Even pretty fundamental GNOME stuff like gtk2-devel is still
> broken. Look here:
>
> [r...@localhost ~]# pkg-config --libs gtk+-2.0
> -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0
> -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0
Enrico Scholz writes:
> I have problems to understand the xmlrpc-c build failure
>
> | /usr/bin/ld.bfd: xml-rpc-api2cpp.5842.test: undefined reference to symbol
> 'pthread_cancel@@GLIBC_2.2.5'
It happens because a library where the program is linked against uses
pthre
Charley Wang writes:
> https://fedoraproject.org/wiki/DSOLinkBugs
>
> Please note that many of the packages may be failing because of a few
> DSO's. Further exploration is needed to evaluate this possibility so
> we can apply one patch to the source of the problem instead of dozens
> of superfluo
33 matches
Mail list logo
