Bug#884762: Recovering

[Thibaut VARÈNE]

Confirmed.

It’s possible to recover using « nosmp » on the kernel command line (set from 
the bootloader).

T-Bone

Bug#796612: flashybrid: diff for NMU version 0.18+nmu2

[Thibaut Varène]

> On 10 Jul 2016, at 01:14, Andreas Beckmann  wrote:
> 
> On Sat, 9 Jul 2016 21:43:15 +0200 Thibaut VARENE  wrote:
>> I’m not interested in becoming a second-class DD after 12 years of 
>> service. If that package cannot muster the interest of an actual maintainer, 
>> then maybe it should indeed be removed from the archive. I will keep it 
>> alive on my website anyway.
> 
> To attract interest of prospective maintainers the package should be
> orphaned (or at least RFAed).

Done.
#830769

Bug#796612: flashybrid: diff for NMU version 0.18+nmu2

[Thibaut Varène]

> On 08 Jul 2016, at 01:12, Thibaut Varène <vare...@debian.org> wrote:
> 
> 
>> On 08 Jul 2016, at 01:01, Felipe Sateler <fsate...@debian.org> wrote:
>> 
>> Hi Thibaut,
>> 
>> On 7 July 2016 at 18:41, Thibaut Varène <vare...@debian.org> wrote:
>>> 
>>>> On 03 Jul 2016, at 22:06, z...@debian.org wrote:
>>>> 
>>>> Control: tags 796612 + patch
>>>> Control: tags 796612 + pending
>>>> 
>>>> Dear maintainer,
>>>> 
>>>> I've prepared an NMU for flashybrid (versioned as 0.18+nmu2) and
>>>> uploaded it to DELAYED/5. Please feel free to tell me if I
>>>> should delay it longer.
>>> 
>>> It’s ok, you do what you have to do.
>>> If you want to take over maintainership, please be my guest. I’m 
>>> maintaining “upstream” here now:
>>> 
>>> http://hacks.slashdirt.org/sw/flashybrid/
>>> 
>>> I’d welcome a patch to merge btw.
>> 
>> Your upstream page claims that 0.19 supports systemd.
> 
> It “supports” it to the extent that it fixes #784890 and boots correctly on 
> Jessie (as far as my very basic tests showed). It does not have the glue that 
> the NMU supposedly fixes. Glue I’d be happy to merge were I sent a patch.

For the record I should probably point out that the NMU is rather meaningless 
given that 0.18 on a systemd-enabled Jessie system will be utterly broken (as 
in, the system will go kaboom), precisely because 0.18 is plagued by #784890

Cheers,
T.

Bug#796612: flashybrid: diff for NMU version 0.18+nmu2

[Thibaut Varène]

> On 08 Jul 2016, at 01:01, Felipe Sateler <fsate...@debian.org> wrote:
> 
> Hi Thibaut,
> 
> On 7 July 2016 at 18:41, Thibaut Varène <vare...@debian.org> wrote:
>> 
>>> On 03 Jul 2016, at 22:06, z...@debian.org wrote:
>>> 
>>> Control: tags 796612 + patch
>>> Control: tags 796612 + pending
>>> 
>>> Dear maintainer,
>>> 
>>> I've prepared an NMU for flashybrid (versioned as 0.18+nmu2) and
>>> uploaded it to DELAYED/5. Please feel free to tell me if I
>>> should delay it longer.
>> 
>> It’s ok, you do what you have to do.
>> If you want to take over maintainership, please be my guest. I’m maintaining 
>> “upstream” here now:
>> 
>> http://hacks.slashdirt.org/sw/flashybrid/
>> 
>> I’d welcome a patch to merge btw.
> 
> Your upstream page claims that 0.19 supports systemd.

It “supports” it to the extent that it fixes #784890 and boots correctly on 
Jessie (as far as my very basic tests showed). It does not have the glue that 
the NMU supposedly fixes. Glue I’d be happy to merge were I sent a patch.

> Why not upload
> that version to debian?

Because my upload rights have been revoked with the 1024-bit keys purge, and at 
this point I don’t care anymore.

Cheers,
T.

Bug#796612: flashybrid: diff for NMU version 0.18+nmu2

[Thibaut Varène]

> On 03 Jul 2016, at 22:06, z...@debian.org wrote:
> 
> Control: tags 796612 + patch
> Control: tags 796612 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for flashybrid (versioned as 0.18+nmu2) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.

It’s ok, you do what you have to do.
If you want to take over maintainership, please be my guest. I’m maintaining 
“upstream” here now:

http://hacks.slashdirt.org/sw/flashybrid/

I’d welcome a patch to merge btw.

Best,
T.

Bug#804644: RFS: flashybrid/0.19 [ITA]

[Thibaut Varène]

> On 25 Nov 2015, at 18:24, Gianfranco Costamagna 
>  wrote:
> 
> Control: tags -1 moreinfo
> Control: owner -1 !
> 
> Hi Tim  and Thibaut
> 
> 
> (Thibaut do you have any keyring issue that you can't upload? I see your key 
> has been dropped because
> too weak, maybe you can take the opportunity to make a new and shiny one!
> https://wiki.debian.org/Keysigning/Offers)

I did make a new key, see rt#5454.

I’m not interested in attending keysigning. I fail to see how signing my new 
key with my older, still valid (and at the time still accepted by debian) key 
isn’t enough.

Best.

Bug#804644: RFS: flashybrid/0.19 [ITA]

[Thibaut Varène]

> On 25 Nov 2015, at 18:33, Gianfranco Costamagna 
>  wrote:
> 
> Hi Thibaut!
> 
> 
>> I’m not interested in attending keysigning. I fail to see how signing my new 
>> key with my older, still valid (and at the time still accepted by debian) 
>> key isn’t >enough.
> 
> 
> 
> I don't know the policy and if they allow this kind of signing...
> 
> anyway, please let me know if you need a sponsor :)

I suppose what I need is having people take over my packages and call it a day, 
tbh. With my upload rights revoked there’s not much meaning in being a DD.

T.

Bug#784890: flashybrid: Unable to Sync ramstore directories ...

[Thibaut Varène]

Thanks for trying still.

I have put up a small webpage for flashybrid anyway, since it seems to be 
abandoned upstream:
http://hacks.slashdirt.org/sw/flashybrid/

T.

> On 08 Nov 2015, at 11:24, Tim Weippert <we...@weiti.org> wrote:
> 
> HI, 
> 
> DM's not allowed to do an NMU Upload. Sorry, can't help. 
> 
> cheers, 
> tim
> 
> On Sun, Nov 08, 2015 at 10:55:03AM +0100, Tim Weippert wrote:
>> HI, 
>> 
>> i prepared an NMU and try to upload it. Don't know if i'm allowed to do so 
>> ... will see.
>> 
>> I also included the italian translation to the new package and your fix. 
>> Hopefully it is ok.
>> 
>> Cheers, 
>> tim
>> 
>> On Sun, May 17, 2015 at 03:00:24PM +0200, Thibaut Varène wrote:
>>> OK, thanks everybody.
>>> 
>>> For the records, I'm attaching source for flashybrid-0.19 and a patch from 
>>> 0.18 to this bug report. I can't upload it to the archive, but if some DD 
>>> wants to, let them be my guest.
>>> 
>>> T.
>>> 
>>> 
>> 
>> 
>> 
>> 
>> 
>> -- 
>> Tim Weippert
>> http://weiti.org - we...@weiti.org
>> GPG Fingerprint - E704 7303 6FF0 8393 ADB1  398E 67F2 94AE 5995 7DD8
> 
> -- 
> Tim Weippert
> http://weiti.org - we...@weiti.org
> GPG Fingerprint - E704 7303 6FF0 8393 ADB1  398E 67F2 94AE 5995 7DD8

Bug#785525: systemd fails to boot if non-essential block device is missing

[Thibaut Varène]

On 17 mai 2015, at 14:57, Martin Pitt mp...@debian.org wrote:

 Control: tag -1 wontfix
 
 Hello Thibaut,
 
 Thibaut VARENE [2015-05-17 14:41 +0200]:
 Just upgraded my system from wheezy to jessie. Boot stopped after initial 
 reboot, with prompt to enter root password. After looking at the logs, it 
 seems that systemd choked on this line of my fstab:
 
 UUID=8633-12F1 /media/WDX360   vfat
 user,auto,utf8=no,iocharset=iso8859-1   0   2
 
 That's a line I added for convenience whenever I plug a specific USB
 drive to the machine. Granted, it doesn't have the nofail flag
 
 Indeed, that *and* it's marked as auto.
 
 and it does have a 2 pass_no (instead of 0), but this never caused
 any problem in wheezy, so the new behavior, and the fact that it
 entirely halts the boot process (the machine isn't even remotely
 accessible) is quite a huge change from previous behavior...
 
 It's a change indeed, but IMHO a correct one. Aside from auto and
 nofail there is no other indication whether a file system in fstab
 should be considered essential (in your terms) or not. That's
 precisely what these flags are for. sysvinit might have not complained
 about this situation, but that doesn't mean that I'd like to
 proliferate that bug forever.
 
 Hence I consider this a wontfix.

A footnote in the release/upgrade instructions would have been nice. If that 
machine had been remote without OOB access, I'd have been screwed over, because 
something that never broke previous upgrades.

T.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784890: flashybrid: Unable to Sync ramstore directories ...

[Thibaut Varène]

OK, thanks everybody.

For the records, I'm attaching source for flashybrid-0.19 and a patch from 0.18 
to this bug report. I can't upload it to the archive, but if some DD wants to, 
let them be my guest.

T.




flashybrid_0.18-0.19.patch
Description: Binary data


flashybrid_0.19.dsc
Description: Binary data


flashybrid_0.19.tar.xz
Description: Binary data

Bug#785525: systemd fails to boot if non-essential block device is missing

[Thibaut Varène]

On 17 mai 2015, at 14:59, Thibaut Varène vare...@debian.org wrote:

 
 On 17 mai 2015, at 14:57, Martin Pitt mp...@debian.org wrote:
 
 Control: tag -1 wontfix
 
 Hello Thibaut,
 
 Thibaut VARENE [2015-05-17 14:41 +0200]:
 Just upgraded my system from wheezy to jessie. Boot stopped after initial 
 reboot, with prompt to enter root password. After looking at the logs, it 
 seems that systemd choked on this line of my fstab:
 
 UUID=8633-12F1/media/WDX360   vfat
 user,auto,utf8=no,iocharset=iso8859-1   0   2
 
 That's a line I added for convenience whenever I plug a specific USB
 drive to the machine. Granted, it doesn't have the nofail flag
 
 Indeed, that *and* it's marked as auto.
 
 and it does have a 2 pass_no (instead of 0), but this never caused
 any problem in wheezy, so the new behavior, and the fact that it
 entirely halts the boot process (the machine isn't even remotely
 accessible) is quite a huge change from previous behavior...
 
 It's a change indeed, but IMHO a correct one. Aside from auto and
 nofail there is no other indication whether a file system in fstab
 should be considered essential (in your terms) or not. That's
 precisely what these flags are for. sysvinit might have not complained
 about this situation, but that doesn't mean that I'd like to
 proliferate that bug forever.
 
 Hence I consider this a wontfix.
 
 A footnote in the release/upgrade instructions would have been nice. If that 
 machine had been remote without OOB access, I'd have been screwed over, 
 because something that never broke previous upgrades.

because of

While I'm there, your argument about what should and shouldn't be considered 
essential seems rather bogus considering all of that is made pretty clear by 
the FHS:
http://www.pathname.com/fhs/pub/fhs-2.3.html#REQUIREMENTS

This also states that /media is for removable media, so a hard fail on anything 
below that mount point seems equally wrong.

I'm sure you won't change your mind, but I believe the current behavior of 
systemd is inappropriate. Then again, I suppose I can always switch back to a 
saner sysvinit.


 
 T.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#785525: systemd fails to boot if non-essential block device is missing

[Thibaut Varène]

On 17 mai 2015, at 15:32, Michael Biebl bi...@debian.org wrote:

 Am 17.05.2015 um 14:59 schrieb Thibaut Varène:
 A footnote in the release/upgrade instructions would have been nice. If that 
 machine had been remote without OOB access, I'd have been screwed over, 
 because something that never broke previous upgrades.
 
 It would have been nice if people actually read the release notes:
 https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#systemd-auto-mounts-incompat

Indeed, my bad. I focused on Chapter 4 and blazed through Chapter 5 a bit too 
fast it seems. I suppose I have only myself to blame. The more I read it the 
more I think systemd is not for me.

T.

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784890: flashybrid: Unable to Sync ramstore directories ...

[Thibaut Varène]

 Le 14 mai 2015 à 18:07, Stefan Blochberger stefan.blochber...@mail.de a 
 écrit :

 tmpfs (rw,relatime,size=122880k) tmpfs on /ram/var/run.flash type
 tmpfs (rw,nosuid,noexec,relatime,size=25272k,mode=755) tmpfs on
 /run type tmpfs (rw,nosuid,noexec,relatime,size=25272k,mode=755) 
 


 But /var/run still in use ;(

See the above two lines. I suspect in Jessie, /var/run is by default a bind 
mount of /run. Try commenting it out from /etc/flashybrid/ramstore and see if 
anything breaks.

In case that wasn’t obvious, I don’t have (yet) a Jessie machine to check this 
out.

 You just have to add --make-private to all mounts in
 /etc/init.d/flashybrid

That makes sense. From the Debian Wiki it’s obvious systemd broke everything by 
overriding the kernel default for bind mounts. This comment in the bug thread 
aligns nicely with my personal opinion on the matter:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739593#97

Best,
T

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784890: flashybrid: Unable to Sync ramstore directories ...

[Thibaut Varène]

On 11 mai 2015, at 19:32, Tim Weippert we...@weiti.org wrote:


 If i found another CF card i will try to install an fresh wheezy and update 
 to jessie without migration to systemd (think this should be possible)
 maybe then we know if it is an systemd or kernel fault.

Thanks. First ensure it's working fine in Wheezy.

That would be a very valuable experiment.

Best,
T.

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784890: flashybrid: Unable to Sync ramstore directories ...

[Thibaut Varène]

On 11 mai 2015, at 08:46, Tim Weippert we...@weiti.org wrote:

 Hi Thibaut, 
 
 yes i can confirm, this happens in an fresh and newly started Jessie System.
 
 The Config Files are the Files from the Package, i only commented /etc in 
 ramstore File. /root is there already. No change from
 my side.

ok.

 I haven't started any daemons/processes rather than connect via SSH to the 
 System. For your information my mount table looks after 
 clean start like this:
 
 weiti@indoor01:~$ mount
 tmpfs on /ram type tmpfs (rw,relatime,size=122880k)
 tmpfs on /tmp type tmpfs (rw,relatime,size=122880k)
 tmpfs on /run/lock type tmpfs (rw,relatime,size=122880k)
 tmpfs on /var/lib/dhcp type tmpfs (rw,relatime,size=122880k)
 tmpfs on /var/lib/misc type tmpfs (rw,relatime,size=122880k)
 tmpfs on /var/lib/urandom type tmpfs (rw,relatime,size=122880k)
 tmpfs on /var/tmp type tmpfs (rw,relatime,size=122880k)
 /dev/sda1 on /ram/var/lib/exim4.flash type ext4 
 (ro,relatime,errors=remount-ro,data=ordered)
 tmpfs on /var/lib/exim4 type tmpfs (rw,relatime,size=122880k)
^ Up to this, it's fine
 tmpfs on /ram/var/lib/exim4.flash type tmpfs (rw,relatime,size=122880k)
^ But this is wrong

 /dev/sda1 on /ram/var/log.flash type ext4 
 (ro,relatime,errors=remount-ro,data=ordered)
 tmpfs on /var/log type tmpfs (rw,relatime,size=122880k)
^ again, that's correct
 tmpfs on /ram/var/log.flash type tmpfs (rw,relatime,size=122880k)
^ that shouldn't be there.

 My thoughs are that these situation are my problem:
 
 /dev/sda1 on /ram/root.flash type ext4 
 (ro,relatime,errors=remount-ro,data=ordered)
 tmpfs on /root type tmpfs (rw,relatime,size=122880k)
 tmpfs on /ram/root.flash type tmpfs (rw,relatime,size=122880k)
 
 It seems that root.flash gets mounted twice, on ro from the cf card which is 
 ok, the other (later?) mount
 is an rw tmpfs ... and every sync while go to the tmpfs i think. And after an 
 reboot these changes are lost, because
 the tmpfs get cleared.

There's an extraneous (and wrong) mount, and I can't quite figure out where 
it's coming from.

Maybe you could try adding a -x to /etc/init.d/flashybrid first line:
#!/bin/sh -x

and then record the boot output and add it to this bug report. 
 
 When i change fh-sync to do an remount,ro,bind, no errors occures, but 
 changes weren't synced to CF also.

fh-sync isn't the culprit here. The problem lies somewhere with the init script 
and/or the way the boot sequence happens. The init script has not been changed 
so I suspect this is a nasty side effect of jessie's switch to systemd.

HTH,
T.

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784890: flashybrid: Unable to Sync ramstore directories ...

[Thibaut Varène]

tags 784890 moreinfo
thx

On 10 mai 2015, at 09:57, Tim Weippert we...@weiti.org wrote:

 Package: flashybrid
 Version: 0.18
 Severity: important
 
 Dear Maintainer,
 
 i hav an fresh jessie installation on an Alix Board (alix 2d13) with an CF 
 Card. I tried flashybrid
 for the first time and was unable to sync ramstore directiories to real CF 
 Location. 
 
 fh-sync run reports the following errors:
 
 root@indoor01:~# fh-sync
 Syncing flashybrid system... 
 Synchronizing /var/lib/exim4mount: /ram/var/lib/exim4.flash is busy
 .
 Synchronizing /var/logmount: /ram/var/log.flash is busy
 .
 Synchronizing /var/runmount: /ram/var/run.flash is busy
 .
 Synchronizing /rootmount: /ram/root.flash is busy
 .
 Synchronizing /var/spoolmount: /ram/var/spool.flash is busy
 .
 Synchronizing /var/mailmount: /ram/var/mail.flash is busy
 .
 done.

NB: there's not much I can do since I can't upload to debian anymore.

This typically happens after a mounting parts of the filesystem read-write, 
followed by the installation/startup of some daemon. The daemon then opens a 
write file descriptor to the non-mirrored location (the actual media support), 
and when flashybrid tries to remount that media read-only, it fails. It does 
strike me as odd to find /root in the list though.

Can you confirm that this happens (or not) immediately after booting a clean 
system (unmodified flashybrid) and /without/ installing or starting anything 
after a read-write mount. If it does, it would suggest that flashybrid is 
started too late in the boot process.

T.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#741221: Licensing clarification

[Thibaut Varène]

So it turns out pbuilder is broken and nobody cares:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709053

That’s why I couldn’t upload the new version yet…

Cheers

Le 14 avr. 2014 à 05:31, Alexandre Courbot gnu...@gmail.com a écrit :

 Hi everyone,
 
 Version 1.0.2 of Tagaini Jisho has been released. This version removes
 SKIP codes from the kanjidic as well as their support in the software.
 Hopefully this should solve all concerns.
 
 https://github.com/Gnurou/tagainijisho/archive/1.0.2.tar.gz
 
 I will check with the SKIP code copyright holder whether he could
 relax his license to avoid this issue. In any case, I will ensure that
 Tagaini remains distributable by Debian from now on.
 
 Cheers and thanks for spotting this issue,
 Alex.
 
 
 On Thu, Apr 10, 2014 at 6:28 PM, Thibaut Varène vare...@debian.org wrote:
 tags 741221 confirmed upstream pending
 thanks
 
 Hi,
 
 Due to lack of response from kanjidic’s upstream, and after careful 
 reviewing of its documentation (which further restricts the licensing 
 terms), tagainijisho’s upstream author has decided to remove support for 
 SKIP codes from his software and remove SKIP codes from the embedded 
 kanjidic file.
 
 A new version of tagainijisho will be prepared in the coming days and 
 uploaded as soon as possible.
 
 T-Bone


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#741221: Licensing clarification

[Thibaut Varène]

tags 741221 confirmed upstream pending
thanks

Hi,

Due to lack of response from kanjidic’s upstream, and after careful reviewing 
of its documentation (which further restricts the licensing terms), 
tagainijisho’s upstream author has decided to remove support for SKIP codes 
from his software and remove SKIP codes from the embedded kanjidic file.

A new version of tagainijisho will be prepared in the coming days and uploaded 
as soon as possible.

T-Bone

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#741221: Licensing clarification

[Thibaut Varène]

Hi,

Alexandre, your understanding is correct and applicable to most Linux 
distributions.

CC-BY-SA-NC isn’t freely redistributable due to the restriction on commercial 
use, thus, in a broad sense, not free software.

I’m CC’ing the original bug report so that this information is available to 
others (I hope it’s fine with both of you).

Cheers,
Thibaut

Le 10 avr. 2014 à 15:54, Alexandre Courbot gnu...@gmail.com a écrit :

 Hi Jim,
 
 Thanks for your quick reply! That's good news. However I'm afraid the
 Non-commercial clause is not compatible with Debian's terms of
 distribution (a non-commercial licensing is not acceptable because
 Debian CDs can be sold for instance). Thibaut, is my understanding
 correct? If I remember correctly we ran into the same issue with
 KanjiVG, which made us change its license to CC-SA.
 
 Getting permission by Jack for Tagaini only would also probably not
 work since the right would not be transmitted to derived software.
 
 So it seems that in my case I still have no choice but to strip the
 SKIP codes from Kanjidic. :(
 
 Cheers,
 Alex.
 
 On Thu, Apr 10, 2014 at 9:54 PM, Jim Breen jimbr...@gmail.com wrote:
 When Jack Halpern finally moved to CCSA-NonCommercial licence in
 2008 I updated my general licence page, but forgot to update the
 Kanjidic one. I have now made them conform.
 See http://www.csse.monash.edu.au/~jwb/kanjidic_doc.html#IREF14
 
 I think for free software you can include the SKIPs without any problem.
 
 Cheers
 
 Jim
 
 --
 Jim Breen
 Adjunct Snr Research Fellow, Japanese Studies Centre, Monash University


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739358: wontfix

[Thibaut Varène]

tags 739358 wontfix
kthxbye

martin f krafft madd...@debian.org said:

 Please change the dependency on libmysqlclient18 to a recommendation
 or even a suggestion (and change the code to conditionally load the
 MySQL stuff). libmysqlclient18 or MySQL is fortunately not required
 to use libapache2-mod-musicindex and I'd really rather not have it
 on my systems.


No.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#741221: Licensing clarification

[Thibaut Varène]

Hi,

I am contacting you about KanjiDic2: I am the Debian maintainer of a package 
which includes it (tagainijisho, upstream author CC’d on this email), and it’s 
been brought to my attention that KanjiDic2 may raise some licensing questions, 
see:

http://bugs.debian.org/741221

In a nutshell, it’s unclear from the wording of the file, the wording of the 
kanjidic documentation[1] and the wording of the EDRDG license[2] whether or 
not the SKIP codes included in kanjidic2.xml are submitted to the licensing 
terms of kanjidic2 (CC-BY-SA).

[1] http://www.csse.monash.edu.au/~jwb/kanjidic_doc.html#IREF08
[2] http://www.edrdg.org/edrdg/licence.html

In particular, [2] paragraph 7 is different from [1]. This casts a doubt on the 
distributability of the kanjidic2.xml file as-is, so can you clarify whether or 
not CC-BY-NC-SA applies to the skip codes embedded into the file, in which case 
we’ll have to remove them, or if they are covered under CC-BY-SA?

Thank you,

Thibaut Varène

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#741221: Need more (legal) information

[Thibaut Varène]

tags 741221 moreinfo
thanks

Hi,

[CCing debian-legal as I'd very much like their input on the matter]
Initial thread: http://bugs.debian.org/741221

Meijiko wrote:

 This Kanjidic contain SKIP code, SKIP code License is CC-BY-NC-SA.
 This license is not permit commercial use. Its non-free. (Violate DFSG 6)
 
 Note: Kanjidic license is CC-BY-SA, but Kanjidic is contain SKIP code, SKIP 
 code license is CC-BY-NC-SA.


I'm not sure I can quite agree with your statement. See:

http://www.csse.monash.edu.au/~jwb/kanjidic_doc.html#IREF08

The kanjidic documentation states (emphasis is mine):

 The following people have granted permission for material for which they hold 
 copyright to be included in the files, _and distributed under the above 
 conditions_, while retaining their copyright over that material:
 
 Jack HALPERN: The SKIP codes in the KANJIDIC file.

As I understand this, kanjidic and the SKIP codes it embeds are freely 
redistributable under the licensing terms of kanjidic.

That other licensing provisions for the SKIP codes may be made in other use 
cases (as detailed in Appendix F of the same document) seems quite irrelevant 
to me: you are questioning the DFSG-compliance of kanjidic (and by extension 
the package that includes it: tagainijisho) and as far as I can see, the whole 
content of the file `tagainijisho-[version number]/3rdparty/kanjidic2.xml', 
including the SKIP codes, are covered by the license stated at the top of the 
file: CC-BY-SA, which is DFSG-compliant.

Can someone from d-legal shed some insightful light on this?

Thanks,

T-Bone

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#734713: uprecords-cgi: postinst world-readability test fails due to change in nobody's shell

[Thibaut Varène]

tags 734713 confirmed pending
thanks

ACK.

Thanks for the patch, will upload soon.

T-Bone

On 9 janv. 2014, at 12:34, Colin Watson cjwat...@debian.org wrote:

 Package: uprecords-cgi
 Version: 1:0.3.17-3.1
 Severity: normal
 Tags: patch
 User: base-pas...@packages.debian.org
 Usertags: shell-fallout
 
 In base-passwd 3.5.30, I changed nobody's shell to /usr/sbin/nologin (a
 change that I really should have made about ten years ago).  This has
 unfortunately had a bit of collateral damage:
 
  $ sudo chmod +x /etc/uprecords-cgi/*
  $ sudo apt-get --reinstall install uprecords-cgi
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  The following packages were automatically installed and are no longer 
 required:
libbind9-80 libdns88 libisc84 libisccc80 libisccfg82 liblwres80 python3.2 
 python3.2-minimal
  Use 'apt-get autoremove' to remove them.
  0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 118 not 
 upgraded.
  Need to get 0 B/20.8 kB of archives.
  After this operation, 0 B of additional disk space will be used.
  debconf: delaying package configuration, since apt-utils is not installed
  (Reading database ... 18737 files and directories currently installed.)
  Preparing to replace uprecords-cgi 1:0.3.17-3.1 (using 
 .../uprecords-cgi_1%3a0.3.17-3.1_all.deb) ...
  Unpacking replacement uprecords-cgi ...
  Setting up uprecords-cgi (1:0.3.17-3.1) ...
  This account is currently not available.
  This account is currently not available.
  This account is currently not available.
 
  * Pass -s /bin/sh to su nobody to cope with the change of nobody's
shell in base-passwd 3.5.30.
 
 diff -Nru uptimed-0.3.17/debian/uprecords-cgi.postinst 
 uptimed-0.3.17/debian/uprecords-cgi.postinst
 --- uptimed-0.3.17/debian/uprecords-cgi.postinst  2012-05-25 
 01:52:27.0 +0100
 +++ uptimed-0.3.17/debian/uprecords-cgi.postinst  2014-01-09 
 11:32:09.0 +
 @@ -44,7 +44,8 @@
   # is necessary for the CGI script to work)
   for i in uprecords.conf uprecords.footer uprecords.header; do
   if [ -x /etc/uprecords-cgi/$i  ]; then
 - if su nobody -c 'test ! -r /etc/uprecords-cgi/'$i; then
 + if su nobody -s /bin/sh \
 + -c 'test ! -r /etc/uprecords-cgi/'$i; then
   echo Making $i world readable
   chmod o+r /etc/uprecords-cgi/$i
   fi
 
 Sorry,
 
 -- 
 Colin Watson   [cjwat...@debian.org]


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#575461: finch: ability to use OTR-encryption

[Thibaut Varène]

On 3 janv. 2014, at 04:19, intrigeri intrig...@debian.org wrote:

 Hi,
 
 at this point of the discussion (both here and with upstream), it
 seems to me that this bug has nothing to do anymore on the pidgin-otr
 bugs list. It should be converted into a RFP (request for package)
 asking for purple-otr, right? I'm happy to do so if Thibaut or Howard
 give me a go-ahead.

How about taking over maintainership? I don't use pidgin-otr anymore.

Cheers.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725779: libotr: OTR clients supporting both OTRv1 and v2 are subject to protocol downgrade attacks

[Thibaut Varène]

On 22 oct. 2013, at 20:17, intrigeri intrig...@debian.org wrote:

 Hi Thibault,

Hi,
 
 intrig...@debian.org wrote (08 Oct 2013 09:27:56 GMT) :
 as you are surely aware of, it's been known [1] since 2006 that
 clients supporting both OTRv1 and v2 (such as libotr 3.x) are subject
 to protocol downgrade attacks clients. It's also been known for
 a while that OTRv1 has serious security issues (that were the main
 reason for a v2, actually). In short, support v2 only is the only safe
 way to go these days.
 
 [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.165.7945
 
 It took a while to obsolete older v1-only software, and another while
 to complete the libotr 4.x transition and get to a sane state in
 Debian testing. Now, I think the time has come when we can reasonably
 expect v2-only to work for everyone.
 
 I think that the only reasonable course of action from now on is to
 patch libotr in stable and oldstable to only support OTR v1.
 
 (s/v1/v2/ in the last sentence, obviously.)
 
 Ping? If you have no time to take care of that, fair enough, but then
 I would really appreciate to read your general opinion on the matter,
 even if it's a simple please go ahead and NMU. Thanks in advance!

I have to admit having absolutely no time to deal with that. If everyone is 
fine this won't be disruptive for existing users of otr (it's not entirely 
clear to me what the implications of such a change are, TBH), you're more than 
welcome to NMU if you're confident this is The Right Thing(tm).

Cheers,

T-Bone

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725779: libotr: OTR clients supporting both OTRv1 and v2 are subject to protocol downgrade attacks

[Thibaut Varène]

On 23 oct. 2013, at 01:53, Ian Goldberg i...@cypherpunks.ca wrote:
 
 To be explicit, removing support for OTRv1 from libotr 3.x is totally
 fine (and indeed libotr 4.x has already done it).

Ian, thanks a lot for the input.
I guess it's all good then, no objection for an NMU and thanks in advance to 
whoever will deal with it.
I hope to be able to resume my normal DD duties ASAP ;P

T-Bone

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#718787: libapache2-mod-musicindex: Dependency on apache2.2 (-common) holds up migration to Apache 2.4

[Thibaut Varène]

forcemerge 718787 666834
thanks

Hi

libapache2-mod-musicindex has been removed from testing precisely because of 
this.

I'm currently unable to upload an updated version of the module, so for the 
time being, the solution is to remove the module from your system.

T.

On 5 août 2013, at 15:01, Dominique Brazziel dbrazz...@snet.net wrote:

 Package: libapache2-mod-musicindex
 Version: 1.3.7-2+b1
 Severity: important
 
 Dear Maintainer,
 
I guess all apache2 modules should be rebuilt due
 to upstream ABI changes.  I am getting updates for
 apache 2.4 but they can't be installed because of 
 dependencies on apache2.2-common from a few packages
 (this one, apache2-mod-perl2, etc.).
 
 -- System Information:
 Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
 Architecture: i386 (i686)
 
 Kernel: Linux 3.9.6-1inter02-686-pae (SMP w/2 CPU cores; PREEMPT)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
 LC_ALL set to en_US.UTF-8)
 Shell: /bin/sh linked to /bin/dash
 
 Versions of packages libapache2-mod-musicindex depends on:
 ii  apache2.2-common   2.2.22-13
 ii  libapr11.4.8-1
 ii  libarchive12   3.0.4-3+nmu1
 ii  libc6  2.17-7
 ii  libflac8   1.3.0-1
 ii  libid3tag0 0.15.1b-10
 ii  libmad00.15.1b-8
 ii  libmp4v2-2 2.0.0~dfsg0-2
 ii  libmysqlclient18   5.5.31+dfsg-1
 ii  libvorbis0a1.3.2-1.3
 ii  libvorbisfile3 1.3.2-1.3
 ii  mod-musicindex-common  1.3.7-2
 ii  zlib1g 1:1.2.8.dfsg-1
 
 libapache2-mod-musicindex recommends no packages.
 
 libapache2-mod-musicindex suggests no packages.
 
 -- no debconf information


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#549431: pidgin-otr: Logging should be disabled by default

[Thibaut Varène]

On 30 juil. 2013, at 09:38, intrigeri intrig...@debian.org wrote:

 Hi Thibaut,
 
 I've seen you've tagged this bug `upstream' a while ago,
 but I see no mention of this bug being forwarded to them.
 
 Was it?

Upstream is subscribed to the BTS.

HTH


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#673154: CVE-2012-2369: Format string security vulnerability

[Thibaut VARÈNE]

I've no idea how to fix this in stable and I'm currently in vacation with 
limited Internet access...

Le 17 mai 2012 à 05:33, Florian Mayer segfaulthun...@gmail.com a écrit :

 Hello! I've been wondering why this isn't fixed in stable yet and
 there's no DSA about it either.
 
 



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#673154: CVE-2012-2369: Format string security vulnerability

[Thibaut VARÈNE]

The update is ready I'm about to upload it. Thx

Le 16 mai 2012 à 06:56, Jonathan Wiltshire j...@debian.org a écrit :

 Package: pidgin-otr
 Version: 3.2.0-5
 Severity: serious
 Tags: security upstream patch
 
 Hi,
 the following CVE (Common Vulnerabilities  Exposures) id was
 published for pidgin-otr.
 
 CVE-2012-2369[0]:
 | Versions 3.2.0 and earlier of the pidgin-otr plugin contain a format
 | string security flaw.  This flaw could potentially be exploited by
 | a remote attacker to cause arbitrary code to be executed on the user's
 | machine.
 
 Upstream's patch:
 
 --- a/otr-plugin.c
 +++ b/otr-plugin.c
 @@ -296,7 +296,7 @@ static void still_secure_cb(void *opdata, ConnContext 
 *conte
 
 static void log_message_cb(void *opdata, const char *message)
 {
 -purple_debug_info(otr, message);
 +purple_debug_info(otr, %s, message);
 }
 
 static int max_message_size_cb(void *opdata, ConnContext *context)
 
 If you fix the vulnerability please also make sure to include the
 CVE id in your changelog entry.
 
 I will shortly prepare an update for stable unless you wish to.
 
 For further information see:
 
 [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2369
http://security-tracker.debian.org/tracker/CVE-2012-2369
 
 
 -- System Information:
 Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
 'experimental')
 Architecture: amd64 (x86_64)
 
 Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores)
 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/bash
 
 



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#595502: linux-image-2.6.32-5-mckinley: panics while loading INIT, IOMMU out of mapping resources

[Thibaut VARÈNE]

Le 14 sept. 10 à 04:22, dann frazier a écrit :


On Tue, Sep 14, 2010 at 12:48:22AM +0100, Ben Hutchings wrote:

On Tue, 2010-09-14 at 01:19 +0200, Thibaut VARÈNE wrote:

Le 14 sept. 10 à 01:11, Thibaut VARÈNE a écrit :


Le 14 sept. 10 à 00:09, dann frazier a écrit :


On Sat, Sep 04, 2010 at 05:38:13PM +0200, Thibaut VARÈNE wrote:

Package: linux-image-2.6.32-5-mckinley
Version: 2.6.32-20
Severity: grave
Justification: renders system unusable


System boots fine with linux-image-2.6.32-3-mckinley 2.6.32-9.
Panics with 2.6.32-20 with: I/O MMU @ c000fed01000 is out of
mapping
resources


fyi, my rx2600 boots fine on both 2.6.32-20 and 2.6.32-21.
(ROM Version 2.31)



This was a zx2000, same ROM, and I was about to try a rx2600. I
guess this makes it moot ;P



Just thinking out loud, but given the symptoms (disk errors) and the
specifics of zx2000 vs rx2600, I'm guessing the IOMMU pukes on IDE,
which rx2600 doesn't use for disks...


That might be significant, since we've made the libata transition.
Did you get a traceback for the kernel panic?


Another datapoint - also was unable to reproduce on a zx2000 here,
though mine uses contains only SCSI disks.



Well then, looks like you've got the culprit (IDE)...

HTH

--
Thibaut VARÈNE
http://www.parisc-linux.org/~varenet/




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#595502: linux-image-2.6.32-5-mckinley: panics while loading INIT, IOMMU out of mapping resources

[Thibaut VARÈNE]

Le 14 sept. 10 à 00:09, dann frazier a écrit :


On Sat, Sep 04, 2010 at 05:38:13PM +0200, Thibaut VARÈNE wrote:

Package: linux-image-2.6.32-5-mckinley
Version: 2.6.32-20
Severity: grave
Justification: renders system unusable


System boots fine with linux-image-2.6.32-3-mckinley 2.6.32-9.
Panics with 2.6.32-20 with: I/O MMU @ c000fed01000 is out of  
mapping

resources


fyi, my rx2600 boots fine on both 2.6.32-20 and 2.6.32-21.
(ROM Version 2.31)



This was a zx2000, same ROM, and I was about to try a rx2600. I guess  
this makes it moot ;P


Cheers

--
Thibaut VARÈNE
http://www.parisc-linux.org/~varenet/




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#595502: linux-image-2.6.32-5-mckinley: panics while loading INIT, IOMMU out of mapping resources

[Thibaut VARÈNE]

Le 14 sept. 10 à 01:11, Thibaut VARÈNE a écrit :


Le 14 sept. 10 à 00:09, dann frazier a écrit :


On Sat, Sep 04, 2010 at 05:38:13PM +0200, Thibaut VARÈNE wrote:

Package: linux-image-2.6.32-5-mckinley
Version: 2.6.32-20
Severity: grave
Justification: renders system unusable


System boots fine with linux-image-2.6.32-3-mckinley 2.6.32-9.
Panics with 2.6.32-20 with: I/O MMU @ c000fed01000 is out of  
mapping

resources


fyi, my rx2600 boots fine on both 2.6.32-20 and 2.6.32-21.
(ROM Version 2.31)



This was a zx2000, same ROM, and I was about to try a rx2600. I  
guess this makes it moot ;P



Just thinking out loud, but given the symptoms (disk errors) and the  
specifics of zx2000 vs rx2600, I'm guessing the IOMMU pukes on IDE,  
which rx2600 doesn't use for disks...


May be a brainfart tho.

T-Bone


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#595502: linux-image-2.6.32-5-mckinley: panics while loading INIT, IOMMU out of mapping resources

[Thibaut VARÈNE]

Le 14 sept. 10 à 01:48, Ben Hutchings a écrit :


On Tue, 2010-09-14 at 01:19 +0200, Thibaut VARÈNE wrote:

Le 14 sept. 10 à 01:11, Thibaut VARÈNE a écrit :


Le 14 sept. 10 à 00:09, dann frazier a écrit :


On Sat, Sep 04, 2010 at 05:38:13PM +0200, Thibaut VARÈNE wrote:

Package: linux-image-2.6.32-5-mckinley
Version: 2.6.32-20
Severity: grave
Justification: renders system unusable


System boots fine with linux-image-2.6.32-3-mckinley 2.6.32-9.
Panics with 2.6.32-20 with: I/O MMU @ c000fed01000 is out of
mapping
resources


fyi, my rx2600 boots fine on both 2.6.32-20 and 2.6.32-21.
(ROM Version 2.31)



This was a zx2000, same ROM, and I was about to try a rx2600. I
guess this makes it moot ;P



Just thinking out loud, but given the symptoms (disk errors) and the
specifics of zx2000 vs rx2600, I'm guessing the IOMMU pukes on IDE,
which rx2600 doesn't use for disks...


That might be significant, since we've made the libata transition.
Did you get a traceback for the kernel panic?



All the information I could collect was pasted in the first email and  
attached to the second...


HTH




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#595502: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#595502: linux-image-2.6.32-5-mckinley: panics while loading INIT, IOMMU out of mapping resources)

[Thibaut VARÈNE]

Le 12 sept. 10 à 18:49, Ben Hutchings a écrit :


On Tue, 2010-09-07 at 01:31 +0200, Thibaut VARÈNE wrote:
[...]

I'm afraid this is absolutely not happening, this machine is a
webserver and I've just spent enough time bringing it back to life...
Besides squeeze is not shipping with 2.6.35, right? I'm hoping you
plan on releasing a working kernel for the upcoming stable release?


Right, but if the bug is fixed in 2.6.35 then I can look for a fix in
between, and if it is not then you can report the bug to upstream.



I have a different ia64 machine on which I could try kernel on,  
although not very easily. I'll see if I can first reproduce the bug on  
it, and then if it happens with 2.6.35, but that may take some time...


HTH

--
Thibaut VARÈNE
http://www.parisc-linux.org/~varenet/




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#595502: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#595502: linux-image-2.6.32-5-mckinley: panics while loading INIT, IOMMU out of mapping resources)

[Thibaut VARÈNE]

Le 7 sept. 10 à 01:18, Ben Hutchings a écrit :


On Mon, 2010-09-06 at 13:40 +0200, Thibaut VARENE wrote:

reopen 595502
thanks

Version: 2.6.32-21

Please, explain to me how changing a Panic into a Warning without
effectively fixing the root cause of the bug fixes anything?

And, oh, if by graceful failure you mean: it will blow up your  
raid

devices and kill your filesystems, then yes, the failure has been
very graceful for me, thankyouverymuch. I could have lived with a
little less gracefulness, though ;-/

[...]

There's no need to take your frustration out on me.  I know nothing


I don't think I've taken out my frustration on you, I would have been  
a lot less ironic and a lot more postal if I had been to take the  
frustration resulting from the pain this caused me on anyone... I must  
say tho I'm quite frustrated that incremental kernel upgrades to the  
now frozen next stable release introduce *regressions*...



about IA64 and have to assume that upstream developers know what they
are doing.


That remains an open question ;P


Please test Linux 2.6.35 as packaged in experimental.



I'm afraid this is absolutely not happening, this machine is a  
webserver and I've just spent enough time bringing it back to life...  
Besides squeeze is not shipping with 2.6.35, right? I'm hoping you  
plan on releasing a working kernel for the upcoming stable release?


One thing I don't get is why the need to break a perfectly working  
kernel (2.6.32-9)? Can't the specific change that introduced this bug  
be simply reverted?





--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#595502: linux-image-2.6.32-5-mckinley: panics while loading INIT, IOMMU out of mapping resources

[Thibaut VARÈNE]

Package: linux-image-2.6.32-5-mckinley
Version: 2.6.32-20
Severity: grave
Justification: renders system unusable


System boots fine with linux-image-2.6.32-3-mckinley 2.6.32-9.
Panics with 2.6.32-20 with: I/O MMU @ c000fed01000 is out of  
mapping resources



Full boot log:

Loading.: Debian GNU/Linux
Starting: Debian GNU/Linux
ELILO v3.12 for EFI/IA-64
..
Uncompressing Linux... done
Loading file \EFI\debian\initrd.img...done
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 2.6.32-5-mckinley (Debian 2.6.32-20) (b...@decadent.org.uk 
) (gcc version 4.3.5 (Debian 4.3.5-2) ) #1 SMP Thu Aug 12 15:34:34 UTC  
2010
[0.00] EFI v1.10 by HP: SALsystab=0x3fb38000 ACPI  
2.0=0x3fb2e000 SMBIOS=0x3fb3a000 HCDP=0x3fb2c000

[0.00] booting generic kernel on platform hpzx1
[0.00] PCDP: v0 at 0x3fb2c000
[0.00] Early serial console at MMIO 0xff5e (options  
'9600n8')

[0.00] bootconsole [uart8250] enabled
[0.00] ACPI: RSDP 3fb2e000 00028 (v02 HP)
[0.00] ACPI: XSDT 3fb2e02c 0007C (v01 HP   zx2000  
   HP )
[0.00] ACPI: FACP 3fb373e0 000F4 (v03 HP   zx2000  
   HP )
[0.00] ACPI Warning: 32/64X length mismatch in Gpe0Block:  
32/16 (20090903/tbfadt-526)
[0.00] ACPI Warning: 32/64X length mismatch in Gpe1Block:  
32/16 (20090903/tbfadt-526)
[0.00] ACPI: DSDT 3fb2e0e0 05781 (v01 HP   zx2000  
0007 INTL 02012044)

[0.00] ACPI: FACS 3fb374d8 00040
[0.00] ACPI: SPCR 3fb37518 00050 (v01 HP   zx2000  
   HP )
[0.00] ACPI: DBGP 3fb37568 00034 (v01 HP   zx2000  
   HP )
[0.00] ACPI: APIC 3fb37628 00084 (v01 HP   zx2000  
   HP )
[0.00] ACPI: SPMI 3fb375a0 00050 (v04 HP   zx2000  
   HP )
[0.00] ACPI: CPEP 3fb375f0 00034 (v01 HP   zx2000  
   HP )
[0.00] ACPI: SSDT 3fb33870 00A14 (v01 HP   zx2000  
0006 INTL 02012044)
[0.00] ACPI: SSDT 3fb34290 022E2 (v01 HP   zx2000  
0006 INTL 02012044)
[0.00] ACPI: SSDT 3fb36580 00342 (v01 HP   zx2000  
0006 INTL 02012044)
[0.00] ACPI: SSDT 3fb368d0 00A16 (v01 HP   zx2000  
0006 INTL 02012044)
[0.00] ACPI: SSDT 3fb372f0 000EB (v01 HP   zx2000  
0006 INTL 02012044)

[0.00] ACPI: Local APIC address c000fee0
[0.00] SMP: Allowing 1 CPUs, 0 hotplug CPUs
[0.00] warning: skipping physical page 0
[0.00] warning: skipping physical page 0
[0.00] warning: skipping physical page 0
[0.00] warning: skipping physical page 0
[0.00] Initial ramdisk at: 0xe0407df27000 (17221974 bytes)
[0.00] SAL 3.1: HP version 2.31
[0.00] SAL Platform features: None
[0.00] SAL: AP wakeup using external interrupt vector 0xff
[0.00] ACPI: Local APIC address c000fee0
[0.00] GSI 47 (level, low) - CPU 0 (0x) vector 48
[0.00] 1 CPUs available, 1 CPUs total
[0.00] MCA related initialization done
[0.00] warning: skipping physical page 0
[0.00] Virtual mem_map starts at 0xa0007fffc790
[0.00] Zone PFN ranges:
[0.00]   DMA  0x0001 - 0x0004
[0.00]   Normal   0x0004 - 0x0102
[0.00] Movable zone start PFN for each node
[0.00] early_node_map[5] active PFN ranges
[0.00] 0: 0x0001 - 0xfd79
[0.00] 0: 0xfec0 - 0xfecb
[0.00] 0: 0x0101 - 0x0101ff5a
[0.00] 0: 0x0101ff69 - 0x0101ff84
[0.00] 0: 0x0101ffa0 - 0x0101fff2
[0.00] Built 1 zonelists in Node order, mobility grouping  
off.  Total pages: 72586

[0.00] Policy zone: Normal
[0.00] Kernel command line: BOOT_IMAGE=atapi0:/EFI/debian/ 
vmlinuz root=/dev/md1  ro

[0.00] PID hash table entries: 4096 (order: 1, 32768 bytes)
[0.00] Memory: 2046816k/2057056k available (7315k code, 39248k  
reserved, 3536k data, 736k init)

[0.00] Leaving McKinley Errata 9 workaround enabled
[0.00] SLUB: Genslabs=16, HWalign=128, Order=0-3,  
MinObjects=0, CPUs=1, Nodes=256

[0.00] Hierarchical RCU implementation.
[0.00] NR_IRQS:1024
[0.00] Console: colour dummy device 80x25
[0.06] Calibrating delay loop... 1347.58 BogoMIPS (lpj=2695168)
[0.236063] Security Framework initialized
[0.288011] SELinux:  Disabled at boot.
[0.340165] Dentry cache hash table entries: 262144 (order: 7,  
2097152 bytes)
[0.434371] Inode-cache hash table entries: 131072 (order: 6,  
1048576 bytes)

[0.529254] Mount-cache hash table entries: 1024
[0.592420] Initializing cgroup subsys ns
[

Bug#579025: libflac-dev: libFLAC.m4 may set empty -L flag

[Thibaut VARÈNE]

Le 14 juin 10 à 10:10, Fabian Greffrath a écrit :


Am 27.04.2010 19:25, schrieb Thibaut VARÈNE:
It does, provided of course that the target package's configure  
script

is properly re-generated against the fixed libFLAC.m4


Ugh, don't want!


This means that any package that was autoconf'd against the broken m4
file will fail to build when its configure script is executed without
any option. You might want to add a note about that somewhere...


How come that no package in Debian that builds against libflac-dev  
FTBFS so far?



for the same reason my package didn't FTBFS *in Debian*: rules define  
--prefix, which masks the bug. The bug is hit when there's no defined  
prefix and the configure script has to guess it. I thought this was  
clear enough from my initial bug report: when configure is called  
without arguments...


HTH

T-Bone


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#583926: libapache-mod-musicindex: [INTL:de] German translation

[Thibaut VARÈNE]

tags 583926 pending
thanks

Le 31 mai 10 à 19:31, Chris Leick a écrit :


Package: libapache-mod-musicindex
Version: 1.3.1
Severity: wishlist
Tags: l10n


Hi,

please find attached the initial german translation of libapache-mod- 
musicindex.


Thanks, it'll be applied to the upcoming upload.

T-Bone


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532123: What's up

[Thibaut VARÈNE]

Hi,

Why is this bug taking so long to fix? It's plaguing the soon to be  
released squeeze and renders webalizer useless...


HTH




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#286917: [PATCH] fix endless loop in local queries

[Thibaut VARÈNE]

Le 29 avr. 10 à 18:36, Thibaut VARÈNE a écrit :

I'm pondering cleaning up/rewriting the code. I've spotted a few  
other problems. If I get around to doing that, maybe I'll step up to  
maintain the code while I'm there, if that can help.


Just for the records, I'm doing it. It's gonna be pretty much a  
rewrite, but I'll keep the original construct and spirit. I'm fixing  
a few issues on the go: mostly better error checking, better  
compliance with RFC, as well as a few bugs.


I'm also trying to make the code more portable (I'm hoping to have it  
run on BSD, at least for local queries) and I'm making way for  
eventual IPV6 support. Not saying I'm actually gonna implement any of  
these tho ;-)


I'll keep you posted.

HTH

T-Bone


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#286917: bidentd new incarnation

[Thibaut VARÈNE]

Hi,

Here's the code. It's standalone. I do not consider it release-ready  
just yet, I want to stress test it a little more.


I've done preliminary testing on local/forward on 2.4 and 2.6. I can't  
test 2.2 (hence the #define in the code).


Builds with `gcc -Wall -pedantic -o bidentd bidentd.c`

Here's a quick summary of what I did:
- run indent -linux main.cc
- converted to pure C, C90 compliant
- switched to getopt()
- simplified logging and verbosity
- removed no longer necessary wrappers
- moved magic numbers to defines
- added more error checking
- added supplementary checks on local/forward resolvers:
  + modified check that proto is TCP (no more strcmp)
  + check that connection is ESTABLISHED
  + check that receiving query IP matches resolver found entry  
(machines with several addresses could have the same local/remote  
ports used on different addresses by different users)
- rewrote code path to have only one exit point in main(), with proper  
cleanup

- removed sending numeric uid (that's non-RFC and a security leak)
- split Resolve()
- prepared for other OS support (linux-specific only: resolv_*_linux()  
and the 3 fopen() in main)

- prepared for IPV6 support

I think that's it. I may have forgotten a bit or two...

Since I've completely rewritten the code, I understand it well enough  
to be ok to maintain it, if that's fine with Joel.


I'd rather avoid forking if Joel doesn't plan to maintain bidentd  
anymore, it would only confuse users since this code does nothing less  
than what the previous version does.


BTW, there was no copyright notice in main.cc, I assumed the file was  
licensed under GPL v2.0 and that Joel had (C) 1992,2005.


Let me know what you think. Feedback welcome.

HTH

--
Thibaut VARÈNE
http://www.parisc-linux.org/~varenet/



bidentd.c
Description: Binary data

Bug#286917: bidentd new incarnation

[Thibaut VARÈNE]

Le 1 mai 10 à 03:42, Thibaut VARÈNE a écrit :


I think that's it. I may have forgotten a bit or two...


- a timeout handler for the forwarder. Default socket timeout can be  
very long, and a timeout can especially occur if the remote host is  
firewalled (DROP instead of REJECT).


HTH




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#286917: [PATCH] fix endless loop in local queries

[Thibaut VARÈNE]

Le 29 avr. 10 à 17:06, Wesley W. Terpstra a écrit :


Well, what I mean is that as long as the firewall doesn't have any  
connections of its own. Which is pretty typical for a firewall, I'd  
say.


Well, depends. The initial submitter had MTA running on his firewall,  
which is not entirely silly, and exposed the bug. But yeah, it doesn't  
happen if the firewall doesn't make any connection of its own.



 I'll try this now and see if I can make the problem appear and then
 disappear.

Ok, I've gotten it to appear:
Apr 29 16:44:37 orange inetd[17916]: ident/tcp server failing  
(looping), service terminated for 10 min

Apr 29 16:44:37 orange bidentd[18702]: 57372, 22 :  :
Apr 29 16:44:37 orange bidentd[18701]: 57372, 22 :  :

... a minor note: if you load ip_conntrack, you need to recreate the  
connection after loading it, or the problem doesn't appear.


That's expected since the lookup only happens at connection init.


Also, you might consider merging my manpage fixes upstream. They're  
needed for UTF-8 terminals.



I'm pondering cleaning up/rewriting the code. I've spotted a few other  
problems. If I get around to doing that, maybe I'll step up to  
maintain the code while I'm there, if that can help.


HTH

Bug#286917: [PATCH] fix endless loop in local queries

[Thibaut VARÈNE]

Hi,

Using bidentd 1.1.1 (lenny), I have the exact same problem.

Steps to reproduce: install bidentd and an IRC client locally. Connect  
to any IRC server.


Cause: bidentd code for local query is never reached.

Fix: see attached patch. I simply moved the local query code before  
the forwarding path. Checked, works both locally and with remote  
(forwarded) queries.


I really have to wonder if people drink their own shit :-/

T-Bone

--
Thibaut VARÈNE
http://www.parisc-linux.org/~varenet/



fix.diff
Description: Binary data

Bug#579025: libflac-dev: libFLAC.m4 may set empty -L flag

[Thibaut VARÈNE]

Le 26 avr. 10 à 10:05, Fabian Greffrath a écrit :


So, can you confirm the attached patch fixes this issue?


It does, provided of course that the target package's configure script  
is properly re-generated against the fixed libFLAC.m4


This means that any package that was autoconf'd against the broken m4  
file will fail to build when its configure script is executed without  
any option. You might want to add a note about that somewhere...


Also plagues libflac-dev in lenny, btw.

my 2c

T-Bone


empty_-L_flag.patch


--
Thibaut VARÈNE
http://www.parisc-linux.org/~varenet/




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#516382: closed by Ben Hutchings b...@decadent.org.uk (Re: linux-image-2.6.26-1-alpha-generic: tg3: incoming ssh fails with Corrupted MAC on input)

[Thibaut VARÈNE]

Le 6 avr. 10 à 05:27, Debian Bug Tracking System a écrit :



De : Ben Hutchings b...@decadent.org.uk
Date : 6 avril 2010 05:24:00 HAEC
À : 516382-d...@bugs.debian.org
Objet : Rép : linux-image-2.6.26-1-alpha-generic: tg3: incoming ssh  
fails with Corrupted MAC on input



Closing due to lack of response.


lack of response to what? This bug has sufficient evidence proving  
that it's real and affecting 2.6.26 in lenny.

Bug#517449: closed by maximilian attems m...@stro.at (Re: linux-image-2.6.26-1-amd64: SCHED_IDLE issues (tasks blocked for more than 120 seconds))

[Thibaut VARÈNE]

Le 12 mars 10 à 03:16, maximilian attems a écrit :

On Fri, Mar 12, 2010 at 01:48:20AM +0100, Thibaut VARENE wrote:

On Fri, Mar 12, 2010 at 12:33 AM, Debian Bug Tracking System
ow...@bugs.debian.org wrote:


Version: 2.6.26-21

this should have been fixed on stable update, thus closing.


Which stable update? It happened to me no later than this morning,  
and

I'm running:

ii  linux-image-2.6.26-2-amd64  2.6.26-21lenny3   
Linux

2.6.26 image on AMD64


please post aboves, thanks



?

--
Thibaut VARÈNE
http://www.parisc-linux.org/~varenet/




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#566512: Cache directory creation

[Thibaut VARÈNE]

Le 24 janv. 10 à 02:48, Dominique Brazziel a écrit :


So, this bit here ---

if (chdir((char *)(conf-cache_setup))) {
   mi_serror(%s, strerror(errno));
   goto exit;

One last thing, if a note is added to the documentation
about cache file directory, perhaps something about the
ownership of the directory (www-data:www-data) should be included.


It already is, as I said in my first email:
- flat file: 'file://absolute/path/to/cache/tree'
  This path must be read/write accessible for the webserver's uid.


mkdir /some persistent directory/musicindex
chown www-data:www-data /some persistent directory/musicindex


I cannot be this specific, the README is intended to everyone, not  
just Debian users, and on some systems the webserver runs eg as  
httpd:httpd or nobody:nogroup, etc.


--
Thibaut VARÈNE
http://www.parisc-linux.org/~varenet/




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#561055: FTBFS: ../astronomy/boinc_astronomy.C:29:21: error: config.h: No such file or directory

[Thibaut VARÈNE]

reassign 561055 boinc-dev
merge 561055 556816
affects 556816 boinc-app-milkyway
thanks

This is a duplicate of #556816

Thanks

Le 14 déc. 09 à 03:00, Nobuhiro Iwamatsu a écrit :


Package: boinc-app-milkyway
Version: 0.18d-1
Justification: FTBFS
Severity: serious

Hi,

boinc-app-milkyway FTBFS on i386 and other architecture.

-
dh_testdir
# Add here commands to configure the package.
touch configure-stamp
dh_testdir
# Add here commands to compile the package.
cd bin  /usr/bin/make -f make.linux
make[1]: Entering directory `/tmp/buildd/boinc-app-milkyway-0.18d/bin'
g++ -DGMLE_BOINC -DBOINC_APP_VERSION=0.18
-DBOINC_APP_NAME='milkyway' -g -O2 -ftree-vectorize -funroll-loops
-I/usr/include/BOINC -m32  -Wall -x c++ -c
../astronomy/boinc_astronomy.C -o ../astronomy/boinc_astronomy.o
../astronomy/boinc_astronomy.C:29:21: error: config.h: No such file  
or directory

make[1]: *** [../astronomy/boinc_astronomy.o] Error 1
make[1]: Leaving directory `/tmp/buildd/boinc-app-milkyway-0.18d/bin'
make: *** [build-stamp] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
-

Plese check and fix this problem.

Best regards,
 Nobuhiro

--
Nobuhiro Iwamatsu
  iwamatsu at {nigauri.org / debian.org}
  GPG ID: 40AD1FA6








--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#450520: What's up?

[Thibaut VARÈNE]

Hi,

Any reason why ushare still hasn't been uploaded to debian?

It's been packaged in Ubuntu, so most of the work seems to have been  
done already...


If the original submitter no longer intends to package the software,  
this ITP should be updated.


Thanks

--
Thibaut VARÈNE
http://www.parisc-linux.org/~varenet/




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#518466: pidgin-otr: update the translation template during the build

[Thibaut VARÈNE]

tags 518466 confirmed pending
thanks

Le 6 mars 09 à 12:34, Sebastien Bacher a écrit :


Package: pidgin-otr
Version: 3.2.0-3
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jaunty ubuntu-patch


Hi,

The Ubuntu packages in main need to update their translation template
during the build so the strings are available for the translators. The
change is not really revelant for debian but doesn't cost a lot either
and would allow us to keep the package in sync between the  
distributions

so it would be nice if you  could do a similar change to the debian
version


Looks good to me, I'll upload it when I come back from vacation

@+

--
Thibaut VARÈNE
http://www.parisc-linux.org/~varenet/




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#517627: linux-image-2.6.26-1-parisc64-smp: Acenic driver without firmware triggers HPMC

[Thibaut VARÈNE]

] dev_ifsioc+0x1d8/0x410
[17179672.056000]  [40215bc8] compat_sys_ioctl+0x3e8/0x480
[17179672.056000]  [40104ef8] syscall_exit+0x0/0x14
[17179672.056000]
[17179672.056000] Kernel panic - not syncing: Kernel Fault




** VIRTUAL FRONT PANEL **
System Boot detected
*
LEDs:  RUN  ATTENTION FAULT REMOTE POWER
   ON   FLASH FLASH ON ON
LED State: System Running.  Unexpected Reboot.  Non-critical Error  
Detected.

Check Chassis and Console Logs for error messages.

processor system panic   1B00

*

 EARLY BOOT VFP *
End of early boot detected
*

** VIRTUAL FRONT PANEL **
System Boot detected
*
LEDs:  RUN  ATTENTION FAULT REMOTE POWER
   ON   FLASH FLASH ON ON
LED State: System Running.  Unexpected Reboot.  Non-critical Error  
Detected.

Check Chassis and Console Logs for error messages.

processor system panic   1B00


With jumb disabled:

Configuring network interfaces...[17179671.856000] eth0: Firmware not  
running!

SIOCSIFFLAGS: De[17179671.864000] eth0: Firmware not running!
vice or resource busy
SIOCSIFFLAGS: Device or resource busy
Failed to bring up eth0.
done.


--
Thibaut VARÈNE
http://www.parisc-linux.org/~varenet/




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#515956: linux-image-2.6.26-1-alpha-generic: 2.6.26-1-alpha-generic fails to boot on DS10 (Tsunami)

[Thibaut VARÈNE]

Le 18 févr. 09 à 19:40, maximilian attems a écrit :


On Wed, Feb 18, 2009 at 02:39:43PM +0100, Thibaut VARENE wrote:



19:39 vorlon abrotman: upgrade the aboot on your disk
19:39 abrotman isn't that part of the upgrade process from etch- 
lenny ?

19:39 vorlon no
19:39 vorlon we never change the boot block on upgrade

can you confirm to have been hit by this?



Running swriteboot /dev/sda /boot/bootlx -f1 allowed me to boot the  
new kernel. AFAICT, this wasn't mentioned in the release notes...


Still, it's still a no go: with the new kernel booted, I can no longer  
log into the box using SSH:


OpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to pluto  port 22.
debug1: Connection established.
debug1: identity file /home/varenet/.ssh/identity type -1
debug1: identity file /home/varenet/.ssh/id_rsa type -1
debug1: identity file /home/varenet/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version  
OpenSSH_5.1p1 Debian-5

debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server-client aes128-cbc hmac-md5 none
debug1: kex: client-server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'pluto' is known and matches the RSA host key.
debug1: Found key in /home/varenet/.ssh/known_hosts:8
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
Disconnecting: Corrupted MAC on input.

This is consistently happening across reboots (box sporting a BCM5701,  
tg3 driver). I guess I'm gonna have to submit another bug report...


HTH

--
Thibaut VARÈNE
http://www.parisc-linux.org/~varenet/




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#515653: uptimed: on brutal reboot, all records are lost

[Thibaut VARÈNE]

Please don't remove the BTS from the CC-list. Bug report information  
must be recorded.


Le 16 févr. 09 à 19:26, Sandro Tosi a écrit :
On Mon, Feb 16, 2009 at 19:19, Thibaut VARENE vare...@debian.org  
wrote:

What filesystem are you using on /var?


xfs


By default, XFS will zero-out inconsistent files after an unclean  
mount. If that's what happened, it's likely uptimed tried to use the  
(invalid) content of the file instead of its backup, which is why you  
didn't see anything in the log (when it uses its backup database it  
prints a message).


Radek, I don't really know what to do about this. Working around  
filesystem issues is gonna be a burden. Adding supplementary checks to  
assert the validity of the file being read doesn't look really  
straightforward; do you have any suggestion about this? The way I see  
it, we could bail out in urec.c:231, and 1) give feedback on failure  
to read record entry, while 2) falling back to the backup database on  
such a failure... Of course, if the backup db is also damaged, we're  
doomed.



What's the content of /var/spool/uptimed/records* ?


$ for file in /var/spool/uptimed/records* ; do echo --- $file ---
; cat $file ; done
--- /var/spool/uptimed/records ---
35228:1234767249:Linux 2.6.25-2-amd64
5978:1234802550:Linux 2.6.25-2-amd64
--- /var/spool/uptimed/records.old ---
35228:1234767249:Linux 2.6.25-2-amd64
5918:1234802550:Linux 2.6.25-2-amd64




That's ok.

--
Thibaut VARÈNE
http://www.parisc-linux.org/~varenet/




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org