Search Results: "Michael Tokarev"

22 June 2015

Lunar: Reproducible builds: week 8 in Stretch cycle

What happened about the reproducible builds effort this week: Toolchain fixes Andreas Henriksson has improved Johannes Schauer initial patch for pbuilder adding support for build profiles. Packages fixed The following 12 packages became reproducible due to changes in their build dependencies: collabtive, eric, file-rc, form-history-control, freehep-chartableconverter-plugin , jenkins-winstone, junit, librelaxng-datatype-java, libwildmagic, lightbeam, puppet-lint, tabble. The following packages became reproducible after getting fixed: Some uploads fixed some reproducibility issues but not all of them: Patches submitted which have not made their way to the archive yet: reproducible.debian.net Bugs with the ftbfs usertag are now visible on the bug graphs. This explain the recent spike. (h01ger) Andreas Beckmann suggested a way to test building packages using the funny paths that one can get when they contain the full Debian package version string. debbindiff development Lunar started an important refactoring introducing abstactions for containers and files in order to make file type identification more flexible, enabling fuzzy matching, and allowing parallel processing. Documentation update Ximin Luo detailed the proposal to standardize environment variables to pass a reference source date to tools that needs one (e.g. documentation generator). Package reviews 41 obsolete reviews have been removed, 168 added and 36 updated this week. Some more issues affecting packages failing to build from source have been identified. Meetings Minutes have been posted for Tuesday June 16th meeting. The next meeting is scheduled Tuesday June 23rd at 17:00 UTC. Presentations Lunar presented the project in French during Pas Sage en Seine in Paris. Video and slides are available.

27 May 2013

Petter Reinholdtsen: How to install Linux on a Packard Bell Easynote LV preinstalled with Windows 8

Two days ago, I asked how I could install Linux on a Packard Bell EasyNote LV computer preinstalled with Windows 8. I found a solution, but am horrified with the obstacles put in the way of Linux users on a laptop with UEFI and Windows 8. I never found out if the cause of my problems were the use of UEFI secure booting or fast boot. I suspect fast boot was the problem, causing the firmware to boot directly from HD without considering any key presses and alternative devices, but do not know UEFI settings enough to tell. There is no way to install Linux on the machine in question without opening the box and disconnecting the hard drive! This is as far as I can tell, the only way to get access to the firmware setup menu without accepting the Windows 8 license agreement. I am told (and found description on how to) that it is possible to configure the firmware setup once booted into Windows 8. But as I believe the terms of that agreement are completely unacceptable, accepting the license was never an alternative. I do not enter agreements I do not intend to follow. I feared I had to return the laptops and ask for a refund, and waste many hours on this, but luckily there was a way to get it to work. But I would not recommend it to anyone planning to run Linux on it, and I have become sceptical to Windows 8 certified laptops. Is this the way Linux will be forced out of the market place, by making it close to impossible for "normal" users to install Linux without accepting the Microsoft Windows license terms? Or at least not without risking to loose the warranty? I've updated the Linux Laptop wiki page for Packard Bell EasyNote LV, to ensure the next person do not have to struggle as much as I did to get Linux into the machine. Thanks to Bob Rosbag, Florian Weimer, Philipp Kern, Ben Hutching, Michael Tokarev and others for feedback and ideas.

21 September 2012

Philipp Kern: IPv6 support in debian-installer, take 2

The IPv6 patch set for netcfg (part of debian-installer) has landed in Debian unstable. In follow-up uploads I diverged from the Ubuntu patch set a little bit:
Thanks to Michael Tokarev's recent upload of busybox, we now also have a more featureful ping and ping6 in debian-installer's environment.

Known bugs:
If you could take another look at a current d-i daily, install a system with it and look if the installed system has a correct network configuration, that would still be appreciated. I also need somebody to test the GNU/kFreeBSD image. I fixed it up to build there but the result might be entirely wrong.

My sincere thanks go to Bernhard Schmidt and Karsten Merker, who successfully completed installations over IPv6 in various environments!

6 June 2006

Martin F. Krafft: Delaying mail

One thing I really miss about email as we know it is the feature to deliver a mail at a specified point in time, not necessarily now. Conceptually, this could be done quite easily: have an alias maildelay deliver to a script, which parses the envelope recipient of the form:
maildelay+2006.06.06.2000=madduck=debian.org@my.mail.relay
The script would drop the mail into a temporary file, removing the control information from the recipient headers:
s [^=]*=(.+)=(.+) \1@\2 
and set the file's modification date to the requested delivery date. Then have a daemon periodically scan the directory and pass expired files to /usr/sbin/sendmail. Michael Tokarev also offers an interesting approach: using Postfix header_checks, he suggests putting messages that contain a header such as X-Delay-Send on hold:
/^X-Delay-Send:/ FILTER hold:
Then, scan the hold queue and set the modification date of the appropriate files to the requested time to let Postfix's qmgr handle the delivery around that time. Of course, I am not supposed to roam about in /var/spool/postfix/deferred, less change any inodes, thus this method right now is not more than a nice idea (I did submit a feature request to Postfix; it doesn't look like it'll be accepted.). Regardless, both approaches are effectively open relays and I am not too inclined to do anything about that. So, moving on... Another method would be to write a policy daemon that returns a 4xx status message until the time specified in the email. Of course, this has the problem of unpredictability, so the mail could be delayed several hours longer than requested. But given the requirement that I'd like to turn my laptop (the submitting MTA) off and still have the mail delivered, the solution may be a second MTA on my SMTP relay (perhaps on port 587/tcp), which takes care of all TLS and SASL submissions and has a predictable retry period. If you have any thoughts (or existing solutions), please let me know!