Bug#939863: [debian-mysql] Bug#939863: mariadb-server-10.3: won't start without libjemalloc1 from jessie
Mystery solved. I had upgraded two different servers from debian mysql 5.6 and oracle mysql 5.7 to mariadb-10.3. The packages were drop in replacements, but when I removed libjemalloc1, mariadb wouldn't start because my former DBA had put this in my.cnf: [mysqld_safe] socket = /var/run/mysqld/mysqld.sock nice= 0 malloc-lib = /usr/lib/x86_64-linux-gnu/libjemalloc.so.1 Commenting that line out, or putting in libjemalloc2 and changing it to .so.2 both work fine. Thanks for looking at it and sorry for the trouble. This can be closed.
Bug#939863: mariadb-server-10.3: won't start without libjemalloc1 from jessie
Package: mariadb-server-10.3 Version: 1:10.3.17-0+deb10u1 After removing a bunch of "unnecessary" libraries yesterday I discovered that mariadb would not restart. After many seconds of failure, the only worthwhile log entry is a vague message that suggests it would like to have libjemalloc.so.1, but doesn't really need it. Turns out mysqld will not start without it installed. But libjemalloc1 doesn't exist in stable. I downloaded and installed libjemalloc1_3.6.0-3_amd64.deb from Jessie and mysql started right up. So mariadb-server-10.3 needs to depend on libjemalloc1 which needs to be put back in stable. Or have it compiled for and depend on libjemalloc2, which is in stable. # /etc/init.d/mysql start [] Starting MariaDB database server: mysqld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . failed! Sep 9 07:15:50 hs /etc/init.d/mysql[8072]: 190909 07:15:50 mysqld_safe --malloc-lib '/usr/lib/x86_64-linux-gnu/libjemalloc.so.1' can not be read and will not be used Sep 9 07:16:20 hs /etc/init.d/mysql[8510]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in Sep 9 07:16:20 hs /etc/init.d/mysql[8510]: #007/usr/bin/mysqladmin: connect to server at 'localhost' failed Sep 9 07:16:20 hs /etc/init.d/mysql[8510]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)' Sep 9 07:16:20 hs /etc/init.d/mysql[8510]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
Bug#848301: fortune-mod: typo in 'The Least Successful Collector' fortune
Package: fortune-mod Version: 1:1.99.1-7 Severity: minor Dear Maintainer, 'The Least Successful Collector' refers to "The Hisory of the French Revolution", which is missing the 't' in 'History'. -- System Information: Debian Release: stretch/sid APT prefers xenial-updates APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 'xenial'), (100, 'xenial-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-53-generic (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fortune-mod depends on: ii libc6 2.23-0ubuntu5 ii librecode0 3.6-22 Versions of packages fortune-mod recommends: ii fortunes-min [fortune-cookie-db] 1:1.99.1-7 Versions of packages fortune-mod suggests: ii bsdmainutils 9.0.6ubuntu3 pn fortunes ii x11-utils 7.7+3 -- no debconf information
Bug#595070: Grant to you, reply Asap
Bug#784408: milter-greylist should not require sudo
Package: milter-greylist Version: 4.5.11-1 /etc/init.d/milter-greylist Calls sudo, but it should not. # /etc/init.d/milter-greylist reload Checking config: ./milter-greylist.old: 97: ./milter-greylist.old: sudo: not found failed. Quitting with error, no action taken. I suggest a change like the following: # diff -u milter-greylist.old milter-greylist --- milter-greylist.old 2015-05-05 23:15:14.787770285 -0600 +++ milter-greylist 2015-05-05 23:15:33.644436946 -0600 @@ -94,7 +94,7 @@ reload) echo -n Checking config: - if sudo -c $DAEMON -c $USER 21 |grep -v 'config .* okay$' |grep . 2 + if $DAEMON -c 21 |grep -v 'config .* okay$' |grep . 2 then echo failed. Quitting with error, no action taken. exit 1 Cory -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: How much of L vs T is still relevant in light of the Ubuntu announcement?
On 02/14/2014 09:58 AM, James Hogarth wrote: Hi guys, So in light of the new announcement[1] how much of L vs T is still relevant? Upstart is obviously going to be pretty much dead in the water now given this - after who is going to seriously contribute to a deprecated project CLA or no? It would seem to this outside observer at any rate this has an impact on certain discussions at any rate... Regards, James [1] http://www.markshuttleworth.com/archives/1316 Well it looks like upstart is coming to a EOL do to the Vote for systemd in Debian weird -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system coupling etc.
On 02/14/2014 12:14 PM, Steve Langasek wrote: On Fri, Feb 14, 2014 at 04:59:34PM +0100, Andres Freund wrote: On 2014-02-14 15:46:18 +, Ian Jackson wrote: Ansgar Burchardt writes (Bug#727708: init system coupling etc.): Don't you mean drop GNOME, KDE and others? It's not only GNOME that plans to depend on logind... logind is a red herring because AIUI we already have a technical solution to that. The problem is other things that might be in the pipeline. I am not so sure it's there. The current version runs without systemd but doesn't support everything Based on what? There is only one new interface in logind between v204 and v208, an 'org.freedesktop.login1.Manager.GetUserByPID' method. Are you telling me that this is a critical feature for desktops, that they won't run correctly without? and more up2date versions don't run at all. There's promise of more work in that direction, but that might be influenced by Ubuntu seemingly also switching in the not too far away future: http://www.markshuttleworth.com/archives/1316 Which says right in that blog entry that: We’ll certainly complete work to make the new logind work without systemd as pid 1. Even supposing that GetUserByPID is critical for jessie, and even supposing that Canonical did not finish the work to make logind work with cgmanager, backporting this one interface to logind 204 will be trivial. There is no excuse at all for Debian getting the compatibility wrong in jessie. (But an awful lot of people who seem eager to make excuses for it. So you guys are forking systemd? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system coupling etc.
On 02/14/2014 01:52 PM, Steve Langasek wrote: On Fri, Feb 14, 2014 at 07:49:32PM +0100, Andres Freund wrote: I am not so sure it's there. The current version runs without systemd but doesn't support everything Based on what? There is only one new interface in logind between v204 and v208, an 'org.freedesktop.login1.Manager.GetUserByPID' method. Are you telling me that this is a critical feature for desktops, that they won't run correctly without? Nono, that's not what I meant, sorry for being imprecise. Logind calls out to systemd for shutting down. -shim now supports some of that, but the last time I tried logind without systemd but just -shim didn't work fully yet? systemd-shim+logind is working fine in Ubuntu - and shutdown is pretty basic functionality, that's expected to work. I have recently seen some reports (via IRC) that logind-based logout is not working from GNOME in unstable, even when running systemd as PID1. So there may be some bugs here, but I have yet to receive any bug reports on the systemd-shim package pointing to a problem with systemd-shim vs. systemd compatibility. has any one reported this bug on systemd 205 and up also systemd 207 was a bug's fix release and systemd 204 is really dated i use systemd 204 in Debian testing but the ABI's have change with cgroup's for a newer systemd then 204. but on the other hand Wayland support in Mutter relies on logind to handle VT switching this is a nice little rabbit hole that needs looked into Wayland-Mutter requires logind from a PID 1 systemd critical feature and Mir will too as well as they share some code no? down the road also systemd 208 has a major addition to logind for Wayland -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system other points, and conclusion
On 01/04/2014 11:21 AM, Steven Chamberlain wrote: Commenting as a porter, the decision on default init system might affect me something like this: If GNU/Linux defaults to Upstart, it's likely in porters' interest to get that working as well as possible so we can keep consistency with Linux arches. I'm really grateful of Dimitri's work on this already. But if GNU/Linux defaults to systemd, I'd say that's far too big, too specialised around Linux, and likely to be a moving target to either port it or maintain something compatible. In that case, we may have to do the best we can with one of the other init systems. I'd wonder if it's still worth porting Upstart if few systems would be using it, or packages having Upstart jobs. I have good feelings about OpenRC (which Gentoo already uses as an alternative alongside systemd), or keeping plain sysvinit might even be still viable for jessie only. On Sat, 4 Jan 2014 14:09:57 +0800 Anthony Towns wrote: I wonder if folks could clarify what status they expect secondary init systems to have in Debian? This aspect is most crucial to the ports. At the very least, we'd need to be able to get patches applied to fix startup issues on our init system, even if the maintainer doesn't test or want to support this. In the worst case, we might have to give up on getting something like GNOME working usefully without systemd, and thus not be able to ship it on non-Linux ports. Policy may need to explain whether hard systemd requirement is permissible, if it should be expressed in package dependencies, or what it should do otherwise (e.g. refuse to start, fail with error message, fall back to something with reduced functionality). If policy requires keeping functional sysvinit scripts around for jessie, and/or (more controversially) can discourage the use of specific non-portable functionality - which I think would be things like expect fork or socket activation - I'm not necessarily saying this is a good idea, but it would obviously work in our favour. If non-Linux ports end up running and testing daemons on an alternate init system *anyway*, I'd love for that work to benefit GNU/Linux users who dislike the chosen default init system and want to use what we're using instead. And vice-versa, anyone running such a system and finding/fixing startup issues, would likely be helping the ports. [please keep me in Cc if responding directly to anything I said here] Thanks, Regards, If Debian go's with systemd they need to use systemd 207 as its supported in RHEL 7 so we know it's going to be supported for around 10 years also why does Debian have systemd 204 in it's repos?? systemd 207 is way better -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system other points, and conclusion
On 01/04/2014 12:07 PM, Russ Allbery wrote: Cory opensourcesoftwaredevelo...@gmail.com writes: If Debian go's with systemd they need to use systemd 207 as its supported in RHEL 7 so we know it's going to be supported for around 10 years also why does Debian have systemd 204 in it's repos?? systemd 207 is way better Because it's the last version before cgroup handling was changed, which has implications for supporting logind under different init systems than systemd. So, in other words, moving systemd forward right now would force various incompatibilities in an excessively disruptive way before we've figured out how we want to handle them. Regardless of how we decide this, we'll be figuring out how systemd could move forward with newer versions, but it's wrapped up with the broader discussion. logind under different init systems, is a hack job and, is not a real implantation and, should not be used, logind should only be used on systemd systems this is bad that people are trying to fork logind this way and we're soon going to have 4 DE's that use it and or even require logind KDE, Gnome, MATE, E18, all 4 use logind atm and E19 is going to be Wayland based so thats also going to require systemd down the road as systemd and wayland go's hand and hand, so most all of the main linux desktop environments will have systemd integration andor require it i think theincompatibilities down the road on Linux will be not using systemd also BSD is working on there own init system like systemd a huge thing to think about we can openly send patches to the systemd maintainers as over 500 developers have been doing so far Gentoo also is now using systemd as a sysvinit and, RC replacement for Linux systems http://wiki.gentoo.org/wiki/Systemd if Debian end up using Upstart willCanonical force alicense for Upstart?? Just like they're doing to Linux Mint and other Linux's based off from Ubuntu http://distrowatch.com/weekly.php?issue=20131209#qa to use Upstart in Ubuntu any ways you have to pullin systemd packages shim-systemd libsystemd-daemon systemd-services Etc i think Ubuntu 13.10 used even more IIRC so will Debian have to do the same? whats the point of not using systemd if you have to pull in the packages for it any ways?? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: loose ends for init system decision
On 12/30/2013 04:31 PM, Michael Gilbert wrote: On Mon, Dec 30, 2013 at 1:47 PM, Russ Allbery wrote: 4. Conclusions I previously argued that much of the benefit of a new init system comes from when we can stop maintaining init scripts. I still believe that, but after thinking more about the cultural and project issues at stake here, as well as the immediate needs for a clean upgrade path, I ended up at more of a compromise position than I expected. I believe Debian should take this path forward: 1. We should select a new init system for jessie, either systemd or upstart. Support for that init system should be release-critical, but only in the sense that the daemon works properly under that init system. In other words, use of the sysvinit compatibility of either init system is acceptable support for jessie. 2. All packages providing init scripts must continue to support sysvinit scripts through the jessie release. Such support will continue to be release-critical. This is going to be painful for packages that want to do an early conversion, since it means testing two different init systems for this release cycle, but I think this is the right thing to do regardless for a clean upgrade path and Debian's normal robust committment to upgrades. Here it has the additional advantage of giving the non-Linux ports some breathing space to strategize. 3. Related, up through the jessie release, packages must (where possible; it's possible there will be cases where this is simply impossible) support switching back and forth between the new default init system and sysvinit. This means that configurations should not be moved out of /etc/default and that startup files for the new init system should read the same configuration that the existing sysvinit scripts use (or both should be modified compatibly). 4. Post-jessie, support for sysvinit will no longer be release-critical, and package maintainers will no longer be expected to ensure that it continues working. However, for as long as Debian has accepted non-Linux ports using a different init system, package maintainers should continue to ship init scripts if they work and should apply patches and other reasonable fixes from porters for those init scripts. In other words, this should be treated the same as merging patches for the Hurd to remove hard-coded constant assumptions: if the change is reasonable and doesn't break Linux ports (and this should be fairly easy to handle for nearly all cases with init scripts), the package maintainer should merge it. 5. Support for the other init system that was not chosen should be handled in the same fashion, should a team choose to pursue it. If we select systemd, package maintainers should still be willing to merge contributed upstart configuration, with the understanding that they can't test it and any support is on a best-effort basis only. Similarly, if we select upstart, package maintainers should be willing to merge systemd unit files and to enable upstream systemd support where requested and where it doesn't interfere with the operation of the daemon under upstart, with the understanding that the package maintainer is not committing to testing or directly supporting this configuration. 6. Debian's non-Linux ports should either use the same init system as Debian's Linux ports or agree on an init system that they're both going to use. The porting work is going to be hard enough without the ports going in different directions on which secondary init system they want to use. I prefer to leave it up to the porters to decide which init system to choose, but I do think OpenRC would be a strong contender. 7. After jessie, functionality between systems running the primary Linux init system and other init systems (including non-Linux ports) should be allowed to drift. In other words, there will be cases where features will only be available with the primary init system. Possible examples include security hardening, socket activation, automatic daemon restarts, and so forth. Packagers are under no obligation to port those features to other init systems, but should welcome and merge patches that do so. After jessie, packagers will no longer be required to preserve daemon configuration when the init system is switched, so use of such facilities as modification of upstart configuration files or systemd overrides may be used. We should revisit this decision again after the jessie release in case the situation has substantially changed. Doesn't a TC mandate on the default init system in some sense violate Debian's spirit of meritocracy? May I suggest something like the following (this isn't meant to be definitive) as a more meritocratic approach: 1. The TC encourages a team (probably debian-boot) to
Bug#714799: Repy: RFA: windows-el -- window manager for GNU Emacs
Hi, I am interested in adopting windows.el. -Thanks Cory -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#411172: dmraid is looking for the raid45 kernel module and not the raid456 modules.
Bug has been around for a while - is nobody trying to fix it? -- Cory Nelson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#465161: Alsa fails to find maestro3 soundcard with Maestro3: probe of 0000:00:08.0 failed with error -2
This is a copy of bug 464191, where the problem and solution are posted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398847: ax awhile arsenic
Pickup Prescriptiosn and Meidcations while you still can! http://www.afterwordalfredo.accumulate.kusanra.com , axawhile -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321434: almost admix
Buy Prescritpions while you still can! www.adviseeasymmetry.algal%2ebearremember.com may aphasiaapproval almost not amorphous -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461659: New version available (warsow-0.41). License clarified?
Version .41 out now and art license issues have been addressed. Though, I still don't know if this will satisfy Debian. Maybe a non-free, 4th package warsow-artwork should be made if its not free enough? -Cory K. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#153612: Join our marketing team
We are Looking for partners worldwide. The position is home-based. Our Company Head Office is located in UK with branches all over the world. We are looking for talented, honest, reliable representatives from different regions. The ideal candidate will be an intelligent person, someone who can work autonomously with a high degree of enthusiasm. Our Company offers a very competitive salary to the successful candidate, along with an unrivalled career progression opportunity. If you would like to work with our active, dynamic team, we invite you to apply for employment. Preference will be given to applicants with knowledge of multiple languages. Please send the following information to [EMAIL PROTECTED] 1. Full name 2 Address of residence 3 Contact Phone numbers 4 Languages spoken 5 Whether you are interested in part time job or full time employment. Thank you. We look forward to working with you. If you received this message in error, please send a blank email to: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#148034: No act of kindness, no matter how small, is ever wasted.
Well well well! Cards are war, in disguise of a sport. Language is the apparel in which your thoughts parade before the public. Never clothe them in vulgar or shoddy attire. The smaller the head, the bigger the dream. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353565: genuine theres file txt
Structuring of the script files The script language was designed to be crafted in a certain structure, to make maintaining the files easy. AN ALLE FINANZINVESTOREN! DIESE AKTIE WIRD DURCHSTARTEN! FREITAG 20. APRIL STARTET DIE HAUSSE! REALISIERTER KURSGEWINN VON 400%+ IN 5 TAGEN! Symbol: G7Q.F Company: COUNTY LINE ENERGY 5 Tages Kursziel: 0.95 Schlusskurs: 0.21 WKN: A0J3B0 ISIN: US2224791077 Markt: Frankfurt LASSEN SIE SICH DIESE CHANCE NICHT ENTGEHEN! G7Q WIRD WIE EINE RAKETE DURCHSTARTEN! UNSERE ERWARTUNGEN WIRD G7Q.F UBERTREFFEN! I tried the same code with an Excel object and it worked fine. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#150831: Report for investors
http://imagecloset.com/uimages/jdv1176820415j.png He would visit me from time to time in order to practise a duet with me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#212432: Enterprise Desktop compelling
better workFrom my http://img444.imageshack.us/my.php?image=t2xm7.png inviting vent latches -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#178611: Adobe Acrobat 8.0 ready to download
Adobe Acrobat enables business, creative, and engineering professionals who work with graphically complex documents to improve the reliability and efficiency of business-critical document exchange through PDF technology. Adobe Acrobat 8.0 Professional has the following features in addition to the features found in the standard version: Create PDF documents with one-button ease from AutoCAD, Microsoft Visio, and Microsoft Project (Windows only); Preserve document layers in technical drawings in Visio and AutoCAD, and object data in Visio (Windows only); Permanently delete sensitive information, including specific text or illustrations, with redaction tools; Create fillable PDF forms from scanned paper, existing PDF documents, Microsoft Word documents, or Excel spreadsheets; Automatically recognize form fields on static PDF documents and convert them to interactive fields that can be filled electronically by anyone using free Adobe Reader versions 7 or 8; Enable Adobe Reader (versions 7 or 8) users to participate in reviews with complete commenting and markup tools, including sticky notes, highlighter, lines, shapes, and stamps; Enable Adobe Reader (versions 7 or 8) users to fill and save PDF forms locally for offline use, and to digitally sign PDF documents. Adobe Acrobat 8.0 Professional Retail Price $449.00 Our Price $79.95 You save $369.05 http://besttowards.org Please note, that there will be more special offers available for our constant customers. Every effort has been made to ensure the accuracy of all information contained herein. DS Team makes no warranty expressed or implied with respect to accuracy of the information, including price, product editorials or product specifications. Product and manufacturer names are used only for the purpose of identification. We appreciate your cooperation with us and we'll be glad to see you as our clients in the future. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352319: /etc/init.d/tinyerp-server [re]start files bad pid number in /var/run/tinyerp-server.pid
Hello Sven, This bug you mention comes up because tinyerp-server is not configured. Try running from the command line `tinyerp-server`, with your options, to find out why it is not starting. In your example, you killed tinyerp-CLIENT, not the tinyerp-SERVER. The bug is the startup scripts do not print an error when tinyerp-server fails to load. Cory Cross -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403302: tinyerp-server: No sample configuration file included
Package: tinyerp-server Severity: normal Hello, I found no example of a configuration file and had to delve into the source to find the proper options. The current configuration method exposes the database password to all users on the system (through procps). Please offer a sample tinyerp-server.conf like the following in doc/tinyerp-server/examples or fully replace the current system. Thank you, Cory Cross [options] db_user=terp #db_password= #db_host= #db_port= secure=false -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#247255: =?koi8-r?b?PT9LT0k4LVI/UT89RkE9QzE9Q0E9REU9Qzk9REI9Q0I9QzEgPUQzPUQ3PUM5PUQzPUQ0PUNFPUQ1
PUNDID1EMD1DMT1EMj1ENSA9RDI9QzE9REEsPz0=?= Date: Wed, 1 Nov 2006 12:20:47 -0330 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=koi8-r; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 úÄÒÁ×ÓÔ×ÕÊ ÷ÁÓÑ ÷ÚÑÌÓÑ ÚÁ ÇÒÕÄØ, ÏÔÓÏÓÉ ÞÔÏ-ÎÉÂÕÄØ îÏ ÞÕ! Ú×ÏÎÏË! ÏÎÁ ×ÚÄÒÏÇÎÕÌÁ ïÎÁ ÂÏÑÌÁÓØ ÚÁ ÐÉÚÄÕ. é ÐÏÄÎÉÍÁÑ ÈÕÅÍ ÇÉÒÉ ë ÎÅÍÕ ÓËÌÏÎÑÓØ: ìÕËÁ, ÐÏÊÄÅÍ ! âÏÇÁÔÓÔ×Ï, ÓÌÁ×Õ ÉÍ ÄÁÌÁ, é × ÜÔÏÔ ÒÁÚ, ËÁË É ×ÓÅÇÄÁ ëÕÐÞÉÈÁ ÇÏÓÔÑ ÄÏÒÏÇÏÇÏ íÁÔÒÅÎÁ ÔÁÂÁËÕ ÎÀÈÎÕÌÁ, ëÁË ÈÒÁÂÒÙÊ ×ÏÉÎ ÐÒÅÄ ÓÒÁÖÅÎØÅÍ - èÕÅ× ÕÖ ÎÅÔ - ÏÄÎÉ ÈÕÉÛËÉ, îÁ ÜÔÏ ÍÏÌ×ÉÌÁ ×ÄÏ×Å: îÁÍÅÄÎÉ ÈÕÊ Õ ÐÁÒÅÎØËÁ, ïÎÁ ÓÏÂÏÊ ÎÁÓ ×ÓÅÈ ÐÒÅÌØÝÁÅÔ, óÕÄØÂÏÀ ÎÅ ÂÙÌ ÏÎ ÂÁÌÕÅÍ, îÁÕÔÒÏ ÔÁÍ ÎÁÛÌÉ ÔÒÉ ÔÒÕÐÁ - îÅ ÍÅÎØÛÅ ÄÅÓÑÔÉ×ÅÒÛËÏ×ÙÊ, õÖ ÐÏ ÕÔÒÕ ÓÈÏÄÉÔØ Ë ÎÅÍÕ. ìÉÃÏÍ ÒÕÍÑÎÁ É ÂÅÌÁ. îÉËÔÏ ÎÅ ×ÉÄÅÌ ÏÔÒÏÄÑÓØ ! é ×ÏÔ ÐÏ ÚÄÒÁ×ÏÍÕ ÓÕÖÄÅÎØÀ ïÎÁ ÄÌÑ ÖÅÎÝÉÎÙ ÉÇÒÕÛËÁ, ëÁË ÓÏÎ ÄÌÑ ×ÄÏ×ÕÛËÉ ÐÒÏÛÌÉ, ë ÎÅÍÕ ÓËÌÏÎÑÓØ: ìÕËÁ, ÐÏÊÄÅÍ ! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#110997: Would like to here from you regarding...
Our educational counselors are recruiting new people for our home degree program. We are running this program as an experiment and we feel you may qualify. This program will earn you a fully qualified degree, with transcripts. Currently we are recruiting people with vast knowledge or experience in the field/trade of their choice. Give our recruiting office a call when you have time. Thanks Cory Blair Office Number: 1-773-509-4920 We hope to be talking to you soon. *We are taking calls at anytime in the day or evening. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#152932: Ver ify pat harrell
Hi, I have rec eived your filled app. http://geocities.com/KristineTracy3421 Please visit the site above, Our office shall then re-co nfirm your info. With Ref to: pat harrell and your Cr. rating is not a factor. All cash out types have been Ap pro ve d for you pat harrell say never: http://geocities.com/SuzanneGoodwin251/a.htm Best Regards, Cory -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#249083: postgresql: Postgres SIGSEGV if wins in nsswitch.conf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I concur, this is no longer reproducible. Thanks for checking, Martin! C Martin Pitt wrote: tag 249083 unreproducible moreinfo thanks Hi Cory! I just tried to reproduce this bug again on an up to date sarge with postgresql-7.4 and postgresql-8.1 backports. I cannot reproduce this any more, can you? Thanks and have a merry christmas! Martin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDq0lH3A5SrXAiHQcRAs2DAJ92Stmj8bTF1UJm4nMq2QaAuw3phwCdEcVh kqUG7vHLcj3q1WBupSDk2Gk= =ie8u -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#41685: Strapon fucked cunt lickin lesbo.
Hello, handsome! Over 10 hours of video of Liza taking her first monster black johnny! ;) http://simigynilufo.com/view.cgi?s=aaam=FIDBE.iPdR,gfibjW,VSd -- Best regards, Cory -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#10813: Please respond before August 12
THIS IS GOING TO BE OUR ABSOLUTE ATTEMPT We have endevored to speak to you on many periods and we await your response now! Your current finanncial loann situation meets the requirements for you for up to a 3.1 % lower rate. However, based on the fact that our previous attempts to speak to you didn't work, this will be our final attempt to finalize the lower ratee. Please finalize this final step upon receiving this notice immediately,and complete your request for information now. Submission Here. http://vllux.rates-lowered.com/4/index/apb/nsode constipate at fur or even devil as in plagued. Cory was at burglarproof when that happened carburetor. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291274: Fails to build with 2.4.29: missing Makefile
I was able to get the openswan-modules to compile into a deb with the follwing
steps and the patch shown below. However I could not establish a tunnel, but
that's not related to this bug as far as I know (unless there is a compile time
option I'm missing). Info included on this anyway.
Linux mahogany 2.4.27-2-686 #1 Thu Jan 20 11:10:41 JST 2005 i686 GNU/Linux
openswan-modules-source: 2.3.0-2
gcc version 3.3.5 (Debian 1:3.3.5-12)
# cd /usr/src
# apt-get install kernel-source-2.4.27 kernel-headers-2.4.27-2-686
# tar xfj kernel-source-2.4.27.tar.bz2
# cp -r kernel-headers-2.4.27-2-686/* kernel-source-2.4.27
# tar xfz openswan-modules.tar.gz
# cd modules/openswan
# cp linux/net/ipsec/Makefile.fs2_4 linux/net/ipsec/Makefile
# patch -p1 /usr/src/openswan-modules.patch (below)
# debian/rules binary-modules KVERS=2.4.27-2-686
KSRC=/usr/src/kernel-source-2.4.27
While the modules loaded without complaint, I could not establish a tunnel with
netgear's VPN client (3des or aes-128), an openswan 2.2.0-4 debian/testing, nor
an openswan 2.3.0-2 box. The remote debian box and netgear vpn clients work
fine with my x509 certs and a 2.2.0-4 debian/testing server.
The specific problem log entries are below, followed by the patch. Regarding
the ESP_3DES and HMAC_MD5 noted below, I had these modules loaded during
testing (noninclusive):
ipsec
ipsec_cryptoapi
ipsec_aes
aes
des
twofish
serpent
blowfish
sha1
sha256
md5
crypto_null
ipcomp
esp4
ah4
Cory
pluto[2401]: hnr_imperial #6: responding to Quick Mode
pluto[2401]: hnr_imperial #6: ESP transform ESP_3DES / auth
AUTH_ALGORITHM_HMAC_MD5 not implemented yet
pluto[2401]: | pfkey_lib_debug:pfkey_msg_parse: satype 0 conversion to proto
failed for msg_type 4 (delete).
pluto[2401]: | pfkey_lib_debug:pfkey_msg_build: Trouble parsing newly built
pfkey message, error=-22.
pluto[2401]: hnr_imperial #6: pfkey_msg_build of Delete SA [EMAIL PROTECTED]
failed, code -22
pluto[2401]: | pfkey_lib_debug:pfkey_msg_parse: satype 0 conversion to proto
failed for msg_type 4 (delete).
pluto[2401]: | pfkey_lib_debug:pfkey_msg_build: Trouble parsing newly built
pfkey message, error=-22.
pluto[2401]: hnr_imperial #6: pfkey_msg_build of Delete SA [EMAIL PROTECTED]
failed, code -22
pluto[2401]: hnr_imperial #6: ASSERTION FAILED at demux.c:1799:
STATE_IKE_FLOOR = from_state from_state = STATE_IKE_ROOF
pluto[2401]: hnr_imperial #6: interface ipsec0/eth0 xx.xx.xx.xx
pluto[2401]: hnr_imperial #6: %myid = (none)
pluto[2401]: hnr_imperial #6: debug none
pluto[2401]: hnr_imperial #6:
pluto[2401]: hnr_imperial #6:
pluto[2401]: hnr_imperial #6: algorithm IKE encrypt: id=7,
name=OAKLEY_AES_CBC, blocksize=16, keydeflen=128
pluto[2401]: hnr_imperial #6: algorithm IKE encrypt: id=5,
name=OAKLEY_3DES_CBC, blocksize=8, keydeflen=192
pluto[2401]: hnr_imperial #6: algorithm IKE hash: id=2, name=OAKLEY_SHA1,
hashsize=20
pluto[2401]: hnr_imperial #6: algorithm IKE hash: id=1, name=OAKLEY_MD5,
hashsize=16
pluto[2401]: hnr_imperial #6: algorithm IKE dh group: id=2,
name=OAKLEY_GROUP_MODP1024, bits=1024
pluto[2401]: hnr_imperial #6: algorithm IKE dh group: id=5,
name=OAKLEY_GROUP_MODP1536, bits=1536
pluto[2401]: hnr_imperial #6: algorithm IKE dh group: id=14,
name=OAKLEY_GROUP_MODP2048, bits=2048
pluto[2401]: hnr_imperial #6: algorithm IKE dh group: id=pluto[2401]:
hnr_imperial #6: algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072,
bits=3072
pluto[2401]: hnr_imperial #6: algorithm IKE dh group: id=16,
name=OAKLEY_GROUP_MODP4096, bits=4096
pluto[2401]: hnr_imperial #6: algorithm IKE dh group: id=17,
name=OAKLEY_GROUP_MODP6144, bits=6144
pluto[2401]: hnr_imperial #6: algorithm IKE dh group: id=18,
name=OAKLEY_GROUP_MODP8192, bits=8192
pluto[2401]: hnr_imperial #6:
pluto[2401]: hnr_imperial #6: stats db_ops.c: {curr_cnt,total_cnt, maxsz}
:context={0,0,0} trans={0,0,0} attrs={0,0,0}
--- openswan-modules.patch
diff -ru openswan.1/lib/libcrypto/libaes/Makefile
openswan/lib/libcrypto/libaes/Makefile
--- openswan.1/lib/libcrypto/libaes/Makefile2005-01-27 09:45:13.0
-0800
+++ openswan/lib/libcrypto/libaes/Makefile 2005-03-24 13:19:30.0
-0800
@@ -14,7 +14,7 @@
# RCSID $Id: Makefile,v 1.5 2004/07/10 19:06:39 mcr Exp $
-OPENSWANSRCDIR=../../..
+OPENSWANSRCDIR=../../../../..
include ${OPENSWANSRCDIR}/Makefile.inc
include ${OPENSWANSRCDIR}/Makefile.ver
diff -ru openswan.1/linux/net/ipsec/Makefile openswan/linux/net/ipsec/Makefile
--- openswan.1/linux/net/ipsec/Makefile 2005-03-23 16:48:39.0 -0800
+++ openswan/linux/net/ipsec/Makefile 2005-03-24 17:24:14.0 -0800
@@ -170,6 +170,14 @@
#EXTRA_CFLAGS += -g
#endif
+EXTRA_CFLAGS += -include ${KLIPS_TOP}/../config-all.h
+EXTRA_CFLAGS += -I${KLIPS_TOP}/include
+EXTRA_CFLAGS += -I${TOPDIR}/include
+EXTRA_CFLAGS += -I${KLIPS_TOP}/lib/zlib
+EXTRA_CFLAGS += -Wall -D__KERNEL__ -DMODULE
+EXTRA_CFLAGS += -DCONFIG_KLIPS_DEBUG -DCONFIG_KLIPS_ESP -DCONFIG_KLIPS_ALG
+EXTRA_CFLAGS
