Bug#568806: Account certificaat is verlopen op de 26-04-2013
Uw e-mailaccount certificaat is verlopen op de 26-04-2013, kan dit onderbreken e-mail levering configuratie en account POP-instellingen, pagina fout bij het verzenden van berichten.Om opnieuw nieuwe webmail Certificaat, Neem even tijd om uw administratie bij te werken door het volgen van de verwijzing onderstaande link: http://microsoft-outlook-webaccess.jimdo.com/ http://microsoft-outlook-webaccess.jimdo.com/ Zodra de informatie die overeenkomt met wat is op onze plaat, wordt je account werken als normaal na de verificatie proces, en webmail certificaat wordt opnieuw vernieuwde. Met vriendelijke groet, Mail Service Team.
Bug#706201: linux-image-3.2.0-0.bpo.4-rt-686-pae: Bad vFAT USB pendrive get dead loop errors
Package: src:linux Version: 3.2.41-2~bpo60+1 Severity: important VFAT Filesystem on a Lexar USB pendrive have grave errors on the root directory. Mounting works fine. Reading the secondary directory named PVR and its files works fine. But trying to read the root directory of the USB pen by ls command gives an huge lot of errors messages from kernel : Directory bread failed. Kernel goes in a dead loop to display the error messages on the system console (text mode) or in rsyslog (xorg mode). Only an action with the poweroff button and restart can restore the system. The USB pen was broken by a oversized file on a probably wrong external system (DVB recorder). Fsck confirmed that the root directory is broken. Expected result : Linux kernel should not go in an infinite loop by the errors on a removable peripheral, rendering unusable Debian Squeeze system. -- Package-specific info: ** Version: Linux version 3.2.0-0.bpo.4-rt-686-pae (debian-kernel@lists.debian.org) (gcc version 4.4.5 (Debian 4.4.5-8) ) #1 SMP PREEMPT RT Debian 3.2.41-2~bpo60+1 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-0.bpo.4-rt-686-pae root=UUID=310f205d-4dfc-4293-966c-8b952c4d258b ro quiet ** Tainted: O (4096) * Out-of-tree module has been loaded. ** Kernel log: [ 578.893093] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.894336] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.895579] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.897197] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.898439] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.899675] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.901255] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.902499] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.903739] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.905314] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.906554] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.907791] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.909371] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.910604] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.911836] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.914626] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.917151] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.918518] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.919751] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.922814] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.924357] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.925605] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.926839] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.928463] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.929704] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.930936] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.932517] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.933756] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.934989] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.936560] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.937808] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.939043] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.940610] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.941849] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.943085] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.944657] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.945906] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.947151] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.948738] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.950001] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.951246] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos 62699) [ 578.952837] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF (i_pos
Bug#703640: src:linux: [3.8 - 3.8.1 regression]: Resume from suspend stuck with framebuffer locking rework
#forgot to tag this bug, sorry! fixed 703640 3.8.5-1~experimental.1 thanks Le 25/03/2013 13:33, Vincent Blut a écrit : Le samedi 23 mars 2013 à 22:10 +0100, Vincent Blut a écrit : Le 23/03/2013 18:58, Ben Hutchings a écrit : On Fri, 2013-03-22 at 14:28 +0100, Vincent Blut wrote: Le jeudi 21 mars 2013 à 21:56 +0100, Vincent Blut a écrit : Le jeudi 21 mars 2013 à 19:28 +0100, Vincent Blut a écrit : Package: src:linux Version: 3.8.3-1~experimental.1 Severity: important Tags: upstream Hi, As mentioned in the subject, the following commit prevents me to resume from suspend in kernel ≥ 3.8.1: commit cace7c323ddde7358ab2f2390ece964c55f30330 Author: Alan Cox a...@linux.intel.com Date: Fri Jan 25 10:28:15 2013 +1000 fb: rework locking to fix lock ordering on takeover commit 50e244cc793d511b86adea24972f3a7264cae114 upstream. Adjust the console layer to allow a take over call where the caller already holds the locks. Make the fb layer lock in order. This is partly a band aid, the fb layer is terminally confused about the locking rules it uses for its notifiers it seems. [a...@linux-foundation.org: remove stray non-ascii char, tidy comment] [a...@linux-foundation.org: export do_take_over_console()] [airlied: cleanup another non-ascii char] Signed-off-by: Alan Cox a...@linux.intel.com Cc: Florian Tobias Schandinat florianschandi...@gmx.de Cc: Stephen Rothwell s...@canb.auug.org.au Cc: Jiri Kosina jkos...@suse.cz Tested-by: Sedat Dilek sedat.di...@gmail.com Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Dave Airlie airl...@redhat.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org I didn't try to boot with this commit reverted, and looking at its size, I fear there will be some conflict to solve before attempting to do so. I guess it could be interesting to try 3.9-rc. to see how it behaves (I didn't see what have been merged in this area in the last merge window). I might try to connect through ssh to see if I get a trace. Same issue with 3.9-rc3, I'll try to find some time tomorrow in order to get eventual stack traces. Some news here, the suspend/resume process is doing fine (I checked while connected via ssh), but what I didn't notice because I was in a dark room is that there is just no backlight. But I find a workaround, setting acpi_osi=!Windows 2012 in the kernel command line seems to inhibit the issue. I found this workaround accidentally because I need this parameter to make my brightness control working again (I reported this in #702188 btw). So are these the same bug or two different bugs? Well they both touch the backlight area, have the same workaround, but the latter appears in a specific case: resume from suspend. I still have 3 revisions to test, hope that will give some clue. Ok, my laptop is back to the business, I finished the bisection and I have a completely different result from the first time: commit 719429a54d9c: drm/i915: write backlight harder I reverted it on top of 3.8.1, as expected that fixed the issue. By the way it is reverted in the last drm pull request sent by Dave Airlie. I guess it'll be spread in stable‽ In any case, please do not use the reportbug --no-bug-script option, as the kernel bug script provides lots of useful information. You can get that now by running: /usr/share/reportbug/handle_bugscript /usr/share/bug/linux-image-3.8-trunk-amd64/script $FILE and sending us that output file. Hmm, I didn't use the '--no-bug-script' option explicitly, is that due to the fact I use the 'advanced' mode? Anyway I'll provide the output but that will have to wait a little bit because my power adapter died this afternoon :-( Attached! Thanks for your time, Vincent -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/517a4e3a.4050...@free.fr
Processed: Re: Bug#703640: src:linux: [3.8 - 3.8.1 regression]: Resume from suspend stuck with framebuffer locking rework
Processing commands for cont...@bugs.debian.org: #forgot to tag this bug, sorry! fixed 703640 3.8.5-1~experimental.1 Bug #703640 [src:linux] src:linux: [3.8 - 3.8.1 regression]: Resume from suspend stuck with framebuffer locking rework Marked as fixed in versions linux/3.8.5-1~experimental.1. thanks Stopping processing here. Please contact me if you need assistance. -- 703640: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703640 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13669698248201.transcr...@bugs.debian.org
Processed: tagging 703640
Processing commands for cont...@bugs.debian.org: tags 703640 - moreinfo Bug #703640 [src:linux] src:linux: [3.8 - 3.8.1 regression]: Resume from suspend stuck with framebuffer locking rework Removed tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 703640: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703640 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.136697663426890.transcr...@bugs.debian.org
Bug#703640: marked as done (src:linux: [3.8 - 3.8.1 regression]: Resume from suspend stuck with framebuffer locking rework)
Your message dated Fri, 26 Apr 2013 12:43:37 +0100 with message-id 1366976617.5955.2.ca...@deadeye.wl.decadent.org.uk and subject line Re: Bug#703640: src:linux: [3.8 - 3.8.1 regression]: Resume from suspend stuck with framebuffer locking rework has caused the Debian Bug report #703640, regarding src:linux: [3.8 - 3.8.1 regression]: Resume from suspend stuck with framebuffer locking rework to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 703640: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703640 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: src:linux Version: 3.8.3-1~experimental.1 Severity: important Tags: upstream Hi, As mentioned in the subject, the following commit prevents me to resume from suspend in kernel ≥ 3.8.1: commit cace7c323ddde7358ab2f2390ece964c55f30330 Author: Alan Cox a...@linux.intel.com Date: Fri Jan 25 10:28:15 2013 +1000 fb: rework locking to fix lock ordering on takeover commit 50e244cc793d511b86adea24972f3a7264cae114 upstream. Adjust the console layer to allow a take over call where the caller already holds the locks. Make the fb layer lock in order. This is partly a band aid, the fb layer is terminally confused about the locking rules it uses for its notifiers it seems. [a...@linux-foundation.org: remove stray non-ascii char, tidy comment] [a...@linux-foundation.org: export do_take_over_console()] [airlied: cleanup another non-ascii char] Signed-off-by: Alan Cox a...@linux.intel.com Cc: Florian Tobias Schandinat florianschandi...@gmx.de Cc: Stephen Rothwell s...@canb.auug.org.au Cc: Jiri Kosina jkos...@suse.cz Tested-by: Sedat Dilek sedat.di...@gmail.com Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Dave Airlie airl...@redhat.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org I didn't try to boot with this commit reverted, and looking at its size, I fear there will be some conflict to solve before attempting to do so. I guess it could be interesting to try 3.9-rc. to see how it behaves (I didn't see what have been merged in this area in the last merge window). I might try to connect through ssh to see if I get a trace. Cheers, Vincent -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ---End Message--- ---BeginMessage--- On Fri, 2013-04-26 at 11:51 +0200, Vincent Blut wrote: #forgot to tag this bug, sorry! fixed 703640 3.8.5-1~experimental.1 thanks So it can be closed... Ben. -- Ben Hutchings Klipstein's 4th Law of Prototyping and Production: A fail-safe circuit will destroy others. signature.asc Description: This is a digitally signed message part ---End Message---
Re: Donation of a Calxeda Highbank node
Hello, 2013/4/12 Raphael Hertzog hert...@debian.org: OffensiveSecurity owns a Calxeda Highbank cluster of ARM machines[1] and is willing to dedicate one of the nodes to Debian. Thanks, that is a very kind offer and with ARM hat on, we cannot reject the offer, it makes it very interesting as a playground machine. However, let me make some points here: * ARM porters hat: It is very interesting machine, and very useful to start experimenting with it as Debian is seeking for a full Calxeda chassis. * DSA hat: The machine shall not be a debian.org machine, so DSA could export accounts if requested. * Buildd hat: The machine shall not be used to run buildd software to build official packages. * Kernel hat: As Ben already stated, ARM multiplatform kernel should already support this machine. Now, Raphael, apparently you got a contact already with the donator and a root account on the server machine. Would you be willing to admin or handout root access to few ARM porters, so DD accounts could either be exported or create local accounts for people willing to play with the machine? Best regards -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAODfWeG=O4VLr5HSOMS78J+aF-7sr0gOx8bqWe=qutqes-y...@mail.gmail.com
Re: Donation of a Calxeda Highbank node
Hector Oron hector.o...@gmail.com writes: Hello, 2013/4/12 Raphael Hertzog hert...@debian.org: OffensiveSecurity owns a Calxeda Highbank cluster of ARM machines[1] and is willing to dedicate one of the nodes to Debian. Thanks, that is a very kind offer and with ARM hat on, we cannot reject the offer, it makes it very interesting as a playground machine. However, let me make some points here: * ARM porters hat: It is very interesting machine, and very useful to start experimenting with it as Debian is seeking for a full Calxeda chassis. * DSA hat: The machine shall not be a debian.org machine, so DSA could export accounts if requested. * Buildd hat: The machine shall not be used to run buildd software to build official packages. * Kernel hat: As Ben already stated, ARM multiplatform kernel should already support this machine. yes, it should. My patched 3.8 multiplatform is more or less booting with qemu emulating Highbank machine but I'm getting either some warnings or it just hangs, don't know why. So, if we're lucky, it's something related to qemu and it'll just work, if we're not some patching will be needed. Now, Raphael, apparently you got a contact already with the donator and a root account on the server machine. Would you be willing to admin or handout root access to few ARM porters, so DD accounts could either be exported or create local accounts for people willing to play with the machine? It would also be interesting to know if it's possible to test a kernel to make sure that the multiplatform kernel will boot/work on it. Thanks, Arnaud -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehdx2z71@lebrac.rtp-net.org
Re: Donation of a Calxeda Highbank node
On Fri, 26 Apr 2013, Hector Oron wrote: * DSA hat: The machine shall not be a debian.org machine, so DSA could export accounts if requested. * Buildd hat: The machine shall not be used to run buildd software to build official packages. Did you get those answers from the relevant teams? Was there a rationale for those answers? Now, Raphael, apparently you got a contact already with the donator and a root account on the server machine. Would you be willing to admin or handout root access to few ARM porters, so DD accounts could either be exported or create local accounts for people willing to play with the machine? I can give root rights to porters who want to administrate the machine, yes. I'd rather not have to take care of routine maintenance but I can stay as a backup in case of need. To be a useful porter machine, it would be nice if all DD can have access to it. But if it's not administrated by DSA, I don't know if the newly announced self-served chroot service can be setup on this machine. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130426140403.ga4...@x230-buxy.home.ouaza.com
Wheezy Wheezy XEN Kernel Different ?
HI, I was hoping someone can help me understand the difference between XEN kernel installed with the XEN package and the stock wheezy RC1 kernel ? I was under the impressions, from Ian Campell's XEN/Debian presentation, that XEN DomU was native in the wheezy kernel.. Ian's presentation: http://penta.debconf.org/dc12_schedule/attachments/225_2012-07-debconf-xen-past-present-future.pdf cheers, gary
Re: Wheezy Wheezy XEN Kernel Different ?
On Fri, 2013-04-26 at 09:46 -0600, gary mazzaferro wrote: I was hoping someone can help me understand the difference between XEN kernel installed with the XEN package and the stock wheezy RC1 kernel ? There is no difference, there is no Xen flavour Linux kernel any more in Wheezy, the -amd64 or -686-pae flavours now work on top of Xen. (there may be some transitional metapackages, I'm not sure). Perhaps if you could reference to precise package names and versions you are looking for information on someone can answer further. Ian. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1366992632.3142.157.ca...@zakaz.uk.xensource.com
Re: Donation of a Calxeda Highbank node
On Fri, Apr 26, 2013 at 02:49:05PM +0200, Hector Oron wrote: 2013/4/12 Raphael Hertzog hert...@debian.org: OffensiveSecurity owns a Calxeda Highbank cluster of ARM machines[1] and is willing to dedicate one of the nodes to Debian. Thanks, that is a very kind offer and with ARM hat on, we cannot reject the offer, it makes it very interesting as a playground machine. However, let me make some points here: * ARM porters hat: It is very interesting machine, and very useful to start experimenting with it as Debian is seeking for a full Calxeda chassis. * DSA hat: The machine shall not be a debian.org machine, so DSA could export accounts if requested. Why in the world not? I'm sure there's no requirement for debian.org machines to be hardware owned by Debian. The s390 porter machines/buildds certainly aren't; I don't see why this machine would necessarily *not* be a d.o machine managed by DSA. Of course if it's going to be DSA-administered, I'm sure DSA would want exclusive admin rights on the machine; but that's just common sense, and AIUI not excluded by the offer. * Buildd hat: The machine shall not be used to run buildd software to build official packages. Again, why not? As far as I can see, this would be the single best use that a Highbank node could be put to by the project. As http://release.debian.org/wheezy/arch_qualify.html shows, we have quite a few more buildds deployed for both armel and armhf than is optimal - and in the case of armhf, we have so many that we're technically exceeding the release requirements. A single Highbank node could replace at least 2 of the fastest buildds we currently have in production... and probably somewhere between 4 and 8 of the slow ones. It absolutely makes sense to leverage this donation as a buildd and decommision/reallocate some of the lower-powered buildds, increasing the reliability of the buildd pool and reducing the total machine management overhead. Being the only highbank machine we have access to does imply some logistical challenges for ensuring that we continue to have good kernel support during the development cycle, so that release+1 will be supportable on the box. But this is a problem we've dealt with before, and certainly in this case the upstream kernel support is quite good, which I think makes this a fairly low risk. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Wheezy Wheezy XEN Kernel Different ?
On Fri, Apr 26, 2013 at 09:46:33AM -0600, gary mazzaferro wrote: HI, I was hoping someone can help me understand the difference between XEN kernel installed with the XEN package and the stock wheezy RC1 kernel ? [...] If you're referring to the xen-linux-system-* packages, these are simply metapackages that depend on appropriate versions of Xen and Linux. They don't contain alternate kernel images. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130426225214.gg2...@decadent.org.uk
