Bug#770425: Possibility of update to 4.x

2014-11-30 Thread Nick Phillips
On Sat, 2014-11-29 at 14:53 +1100, Craig Small wrote: 
 Hi Nick,
   The security update will only be 3.6.1 with the 4.7.4-4.7.5 patches.
 It's difficult balancing act really but the whole purpose of the
 security updates is just to update for security.
 
 It's not ideal for certain situations. The proposed update went to the
 security team a few minutes ago and should mean an update for wordpress
 in wheezy will be out today.


Thanks for that. Doesn't actually concern me which solution was picked,
as long as one was chosen and implemented reasonably quickly (I'll stick
with the 4.x packages I now have anyway).


Cheers,


Nick
-- 
Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195
# These statements are mine, not those of the University of Otago


Bug#770425: Dependencies

2014-11-27 Thread Nick Phillips
Seems that the only new dep in 4.0.1 (besides the themes, which should
probably be re-merged if taking this route) is on ca-certificates.

In a pbuilder vanilla wheezy chroot, just installed current stable
wordpress, then replaced with the built version and 3 themes using dpkg.
Only extra package needed was ca-certificates. Which, obviously, is in
stable.

Craig - if you're going to do the work on backporting the fixes, you
might also consider the likelihood of there being further such fixes
required during the stable security support window.

In this case already, the delay in getting a fixed version into the
archive is probably long enough for these issues to be being exploited.
Is there any reason to think we'd be able to be quicker next time?


Cheers,


Nick
-- 
Nick Phillips / n...@debian.org / 03 479 4195
# These statements are mine, not those of the University of Otago


Bug#770425: Possibility of update to 4.x

2014-11-26 Thread Nick Phillips
FYI...

* 4.0.1+dfsg-1 appears to build fine with a wheezy-only pbuilder.
* Review at
http://premium.wpmudev.org/blog/wordpress-4-0-hugely-underwhelming/
claims that The fact is, users who upgrade to 4.0 when it’s released on
August 27 won’t even realize there are any changes.

It's worked smoothly on 2 out of 3 of my machines. The other relied on
customisations in /etc/wordpress/wp-config.php (which warns you not to
make changes, despite being a config file).


Issues:
* New package splits out the themes into separate packages.
* New package no longer links /usr/share/wordpress/wp-config.php
to /etc/wordpress/wp-config.php - customisations there will be ignored
until admin intervenes.

Both of these issues could fairly easily be reverted to old behaviour, I
think.


Cheers,


Nick
-- 
Nick Phillips / n...@debian.org / 03 479 4195
# These statements are mine, not those of the University of Otago


Bug#388609: teapop-mysql: purging the package fails (update-inetd unavailable)

2006-09-27 Thread Nick Phillips


On 28/09/2006, at 2:15 PM, Mohammed Adnène Trojette wrote:


On Fri, Sep 22, 2006, Nick Phillips wrote:

Ah. Bother.

Thanks, I'll have a look.


Hi Nick!

May I suggest a fix similar to the one in the netkit-tftp package?


purge)
# If netbase is not installed, then we don't need to do  
the remove.

if command -v update-inetd /dev/null 21; then
update-inetd --remove tftp .*  /usr/sbin/ 
in.tftpd

fi
;;


Thanks for that...


Cheers,


Nick




Bug#388609: teapop-mysql: purging the package fails (update-inetd unavailable)

2006-09-22 Thread Nick Phillips
Bill Allombert wrote:
 Package: teapop-mysql
 Version: 0.3.7-4.1+b1
 Severity: serious

 Hello Nick,

 There is an error when attempting to purge teapop-mysql:

   Removing teapop-mysql ...
   Purging configuration files for teapop-mysql ...
   /var/lib/dpkg/info/teapop-mysql.postrm: line 28: update-inetd: command not 
 found
   dpkg: error processing teapop-mysql (--purge):
subprocess post-removal script returned error exit status 127

 update-inetd is not provided by an essential package.

 See Policy 7.2:
   Note, however, that the `postrm' cannot rely on any non-essential packages 
 to
   be present during the `purge' phase.

 Cheers,
   
Ah. Bother.

Thanks, I'll have a look.


Cheers,


Nick


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#311264: libkwiki-perl is in the archive

2006-03-06 Thread Nick Phillips

Luk Claes wrote:


Hi

Shouldn't this bug be closed now that libkwiki-perl is available in the
archive?

Cheers

Luk

 


Probably; I need to go over a bunch of bugs and check the current status.


Cheers,


Nick


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#351030: libmail-spf-query-perl: FTBFS: Missing Build-Depends

2006-02-02 Thread Nick Phillips

Julian Mehnle wrote:


Daniel Schepler wrote:
 


If I add netbase to the Build-Depends, the package builds fine [in my
pbuilder chroot]. 
   



Is it really necessary to list netbase in a package's Build-Depends 
(-Indep) control field?  Or could there be something wrong with your 
pbuilder?


(Sorry, I have little experience with Debian packages that require a net 
connection during building.)
 

That'll be because they shouldn't exist. I'm not sure offhand whether 
it's ever made it as far as policy, but it's been discussed several 
times (sometimes in the context of trying to update sources from 
upstream revision control systems, sometimes for tests), and the general 
consensus, AFAIR, has always been don't -- if it's only a test, you 
should probably skip it.


I'm not sure what the feeling would be about trying to detect whether or 
not the requisite infrastructure is present and running the tests in 
question if so would be; probably still don't (as it will enable 
'someone' to detect where builds are happening).



Cheers,


Nick

--
Nick Phillips / +64 3 479 4195 / [EMAIL PROTECTED]
# these statements are my own, not those of the University of Otago



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#311264: Status of libkwiki-perl

2005-07-08 Thread Nick Phillips

Florian Ragwitz wrote:


Package: kwiki
Followup-For: Bug #311264

So what's the current state of this bug? Are you still working on it?
If not I'd like to adopt that package.

 

Current state is as it said; being worked on. I will upload my svn 
repository to svn.d.o as soon as I can now; I just have to get the 
structure at least vaguely right for creation of .orig.tar.gz files 
(these need to include *all* the different CPAN packages which will be 
in the main Kwiki package).



Cheers,


Nick


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#302797: libspoon-perl: libio-all-perl package

2005-07-08 Thread Nick Phillips

Florian Ragwitz wrote:


Package: libspoon-perl
Version: 0.20-1
Followup-For: Bug #302797

Hello,

I prepared a package for libio-all-perl. It's available here:
http://www-user.tu-chemnitz.de/~rafl/Code/Debian/

I'd be glade if someone would sponsor it because I'm not a DD yet.

 


Please don't; it needs to be co-ordinated with all the Kwiki stuff.


Cheers,


Nick


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#311264: kwiki 0.36-1 uninstallable due to missing libkwiki-perl

2005-06-30 Thread Nick Phillips

Mohammed Adnène Trojette wrote:


On Mon, May 30, 2005, Jan Niehusmann wrote:
 


# apt-get install kwiki
[...]
The following packages have unmet dependencies:
 kwiki: Depends: libkwiki-perl (= 0.36-2) but it is not installable
E: Broken packages
   



I have just tried to have a look at this one.

Unfortunately, I did not understand well the packaging:

1/ there seems to be a typo in debian/control:

Depends: ${perl:Depends}, ${shlibs:Depends}, liblocale-maketext-perl, 
libkwiki-perl (= 0.36-2)
Provides: libcgi-kwiki-perl

The new package is first called libkwiki-perl and then
libcgi-kwiki-perl. Moreover, it is not defined in debian/control :(

2/ kwiki seems to be a transition package as said in debian/changelog:

 * Compatibility package to enable gentler transition between
   old-style kwiki and new-style kwiki, also ensuring that new
   users don't accidentally get into old-style kwiki.

and in the description:

This package is here to make sure people don't accidentally
start new Kwikis using the old-style CGI::Kwiki system.
.
If you are starting a new Kwiki, you DO NOT NEED this
package. Install the libkwiki-perl package instead.

3/ however, it doesn't use the classical way to make a smooth
transition, that is to say defining a dummy package kwiki depending on
the new libkwiki-perl package that replaces kwiki and conflicts kwiki.

4/ I have tried to make a submittable patch, but I noticed that 0.36-1
was using upstream's 0.18 release (I may have been mistaken).

As far as I am concerned, I thus think that this package is an
incomplete transition package. Did I misunderstood something?

 

The fact that the new replacement package was rejected by ftpmaster, and 
I haven't completed repackaging yet. I'm working on it.



Cheers,


Nick



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#302797: libspoon-perl depends on libio-all-perl, which is not in the archive

2005-04-07 Thread Nick Phillips
On Sat, Apr 02, 2005 at 04:20:23PM -0800, Steve Langasek wrote:
 Package: libspoon-perl
 Severity: grave

 I can't even find any mention of libio-all-perl in the NEW queue.

Was rejected due to silly mistake with description; now that I have ADSL
back I will reupload ASAP.


Cheers,


Nick


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]