Re: squid3 LTS assertion errors
El 03/03/16 a las 00:53, santiag...@riseup.net escribió: > El 03/03/16 a las 10:15, Brian May escribió: > > Matus UHLAR - fantomas writes: > > > > > 2016/03/01 06:58:31| assertion failed: forward.cc:298: "fd == server_fd" > > > ... > > > 2016/03/01 07:16:54| assertion failed: forward.cc:298: "fd == server_fd" > > > 2016/03/01 07:17:16| assertion failed: forward.cc:491: "server_fd == fd" > > > 2016/03/01 07:17:38| assertion failed: forward.cc:298: "fd == server_fd" > > > 2016/03/01 07:17:42| assertion failed: forward.cc:491: "server_fd == fd" > > > 2016/03/01 07:17:54| assertion failed: forward.cc:298: "fd == server_fd" > > > > Have had a preliminary look at the changes made between the squeeze > > version (3.1.6-1.2+squeeze3) and squeeze-lts version > > (3.1.6-1.2+squeeze6) however nothing seems to touch either forward.cc or > > the server_fd global variable. > > > > Seems to be crashing when trying to close a connection. > > Thanks for taking a look on this. I was just able to get this: > ... So, even if upgrading to wheezy (and then jessie) is now required, I'll prepare a fixed package for users who for some reason are not able to move forward right now. Sorry again, Santiago
Re: squid3 LTS assertion errors
El 03/03/16 a las 10:15, Brian May escribió: > Matus UHLAR - fantomas writes: > > > 2016/03/01 06:58:31| assertion failed: forward.cc:298: "fd == server_fd" > > ... > > 2016/03/01 07:16:54| assertion failed: forward.cc:298: "fd == server_fd" > > 2016/03/01 07:17:16| assertion failed: forward.cc:491: "server_fd == fd" > > 2016/03/01 07:17:38| assertion failed: forward.cc:298: "fd == server_fd" > > 2016/03/01 07:17:42| assertion failed: forward.cc:491: "server_fd == fd" > > 2016/03/01 07:17:54| assertion failed: forward.cc:298: "fd == server_fd" > > Have had a preliminary look at the changes made between the squeeze > version (3.1.6-1.2+squeeze3) and squeeze-lts version > (3.1.6-1.2+squeeze6) however nothing seems to touch either forward.cc or > the server_fd global variable. > > Seems to be crashing when trying to close a connection. Thanks for taking a look on this. I was just able to get this: Program received signal SIGABRT, Aborted. 0x75efbed5 in raise () from /lib/libc.so.6 (gdb) bt #0 0x75efbed5 in raise () from /lib/libc.so.6 #1 0x75efece0 in abort () from /lib/libc.so.6 #2 0x004ca905 in xassert (msg=0x9a7 , file=0x1034ff0 "\240\324\004\001", line=298) at debug.cc:556 #3 0x004e48d9 in FwdState::unregister (this=0xf5e398, fd=111) at forward.cc:298 #4 0x0050a4a9 in HttpStateData::closeServer (this=0x100d428) at http.cc:1470 #5 0x0055d15c in ServerStateData::swanSong (this=0x100d428) at Server.cc:103 #6 0x005723ef in AsyncJob::callEnd (this=0x100d518) at AsyncJob.cc:135 #7 0x00570c69 in AsyncCall::make (this=0x1027b20) at AsyncCall.cc:34 #8 0x0057322b in AsyncCallQueue::fireNext (this=) at AsyncCallQueue.cc:53 #9 0x005733c0 in AsyncCallQueue::fire (this=0xa32040) at AsyncCallQueue.cc:39 #10 0x004de5d3 in EventLoop::runOnce (this=0x7fffe540) at EventLoop.cc:118 #11 0x004de708 in EventLoop::run (this=0x7fffe540) at EventLoop.cc:94 #12 0x005269da in SquidMain (argc=, argv=) at main.cc:1400 #13 0x00526f26 in SquidMainSafe (argc=2471, argv=0x9a7) at main.cc:1160 #14 main (argc=2471, argv=0x9a7) at main.cc:1152
Re: squid3 LTS assertion errors
El 02/03/16 a las 13:45, Matus UHLAR - fantomas escribió: > Hello, > > since upgrade to LTS squid3 version 3.1.6-1.2+squeeze6, it repeatedly > crashes with assertion errors: > > 2016/03/01 06:58:31| assertion failed: forward.cc:298: "fd == server_fd" > ... > 2016/03/01 07:16:54| assertion failed: forward.cc:298: "fd == server_fd" > 2016/03/01 07:17:16| assertion failed: forward.cc:491: "server_fd == fd" > 2016/03/01 07:17:38| assertion failed: forward.cc:298: "fd == server_fd" > 2016/03/01 07:17:42| assertion failed: forward.cc:491: "server_fd == fd" > 2016/03/01 07:17:54| assertion failed: forward.cc:298: "fd == server_fd" > > I have solved this by upgrading to wheezy version, but this is not correct > way to push users to wheezy ;-) > I'm sorry about this. I didn't identify this crash, squid3 has been running on my squeeze test setup without any trouble. Santiago signature.asc Description: Digital signature
Re: squeeze update of gtk+2.0?
Hi Lenz, El 23/02/16 a las 20:15, PICCORO McKAY Lenz escribió: > i can test the uploads, what must be doit? how, i'm using squeze on > many of my hardware due wheeze and jeesie are very slowly for the > older hardware I have uploaded the packages to my personal repository. The easier would be to add it to your sources.list: deb https://people.debian.org/~santiago/debian santiago-squeeze-lts/ deb-src https://people.debian.org/~santiago/debian santiago-squeeze-lts/ Install the new gtk+2.0 packages and test depending software. Please, tell me if you need more info. Cheers, Santiago signature.asc Description: Digital signature
Re: Accepted eglibc 2.11.3-4+deb6u10 (source all amd64) into squeeze-lts
El 12/02/16 a las 20:42, Brian May escribió: > Matus UHLAR - fantomas writes: > > > yes, there was: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814078 > > Is the BTS the appropriate place for these bugs? I don't think they come > to the LTS team who need to see them. > ... > > Look the same??? > > No, because in upstream __secure_getenv is part of GLIBC_PRIVATE, in > squeeze __secure_getenv was part of GLIBC_2.0 - So we end up putting the > code in a different spot. You can't tell this for certain just by > looking at the patch (although the references to the public symbols > should be a hint). > > I am guessing this is because they were more conservative with what they > use GLIBC_PRIVATE for back in the time of squeeze. > > Question is: Is it worth fixing this? As it is extra symbols, I don't > think it can cause any breakage other then with already running > processes. Especially as squeeze-lts support will be ending soon. > -- > Brian May > Ooups! Really sorry, I needed to be even more careful. But as you said, I don't think it is worth to fix it giving the context. I'll send the regression DLA. Santiago
squeeze update of wordpress?
Hello dear maintainer(s), the Debian LTS team would like to fix the security issues which are currently open in the Squeeze version of wordpress: https://security-tracker.debian.org/tracker/CVE-2016-2221 https://security-tracker.debian.org/tracker/CVE-2016- Would you like to take care of this yourself? If yes, please follow the workflow we have defined here: http://wiki.debian.org/LTS/Development If that workflow is a burden to you, feel free to just prepare an updated source package and send it to debian-lts@lists.debian.org (via a debdiff, or with an URL pointing to the source package, or even with a pointer to your packaging repository), and the members of the LTS team will take care of the rest. Indicate clearly whether you have tested the updated package or not. If you don't want to take care of this update, it's not a problem, we will do our best with your package. Just let us know whether you would like to review and/or test the updated package before it gets released. Thank you very much. Santiago, on behalf of the Debian LTS team. PS: A member of the LTS team might start working on this update at any point in time. You can verify whether someone is registered on this update in this file: https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup signature.asc Description: Digital signature
[Fwd: Preparing to announce Squeeze LTS end-of-life]
Dear i18n and l10n-english teams, Debian LTS would like to announce the end-of-support for Squeeze, so we have prepared a draft announcement: https://anonscm.debian.org/cgit/publicity/announcements.git/tree/en/2016/20160212.wml Could you please take a look at it? Cheers, Santiago signature.asc Description: Digital signature
squeeze update of xymon?
Hello dear maintainer(s), The Debian LTS team would like to fix the security issues which are currently open in the Squeeze version of xymon: https://security-tracker.debian.org/tracker/source-package/xymon Would you like to take care of this yourself? If yes, please follow the workflow we have defined here: http://wiki.debian.org/LTS/Development If that workflow is a burden to you, feel free to just prepare an updated source package and send it to debian-lts@lists.debian.org (via a debdiff, or with an URL pointing to the source package, or even with a pointer to your packaging repository), and the members of the LTS team will take care of the rest. Indicate clearly whether you have tested the updated package or not. If you don't want to take care of this update, it's not a problem, we will do our best with your package. Just let us know whether you would like to review and/or test the updated package before it gets released. Thank you very much. Santiago R.R., on behalf of the Debian LTS team. PS: A member of the LTS team might start working on this update at any point in time. You can verify whether someone is registered on this update in this file: https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup signature.asc Description: Digital signature
Re: Preparing to announce Squeeze LTS end-of-life
Hi, El 09/02/16 a las 10:33, Holger Levsen escribió: > Hi, > > On Dienstag, 9. Februar 2016, Raphael Hertzog wrote: > > My personal preference is also at the end of the month. Mine too. > > But I believe that > > Ben sort of officially declared end of support for the squeeze kernel > > already. > > Ben has "just" closed a lot of linux bugs which only affected 2.6.32 with a > note saying > > "Debian 6.0 Long Term Support has now ended, and the 'linux-2.6' source > package will no longer be updated. This bug is being closed on the > assumption that it does not affect the kernel versions in newer Debian > releases. > > If you can still reproduce this bug in a newer release, please reopen > the bug report and reassign it to 'src:linux' and the affected version > of the package. [...]" > I've started to draft the announce to be consistent with this. But I think there is a problem with the imprecise date (February 2016) on the wiki. Some of us, and more important, some users may thought it was at the end of the month. > > Looking more at the wider future, I think it would be great if we could > support one LTS version until the next oldstable becomes oldstable-lts. For wheezy-lts, it would mean until stretch's release date + 1 year, and not wheezy's release date + 5 years: 4th May 2018. Isn't it? Cheers, Santiago
