Proběhla hackerská soutěž Pwn2Own Ireland 2025. Celkově bylo vyplaceno 1 024 750 dolarů za 73 unikátních zranitelností nultého dne (0-day). Vítězný Summoning Team si odnesl 187 500 dolarů. Shrnutí po jednotlivých dnech na blogu Zero Day Initiative (1. den, 2. den a 3. den) a na YouTube.
Byl publikován říjnový přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Pracuje se na podpoře M3. Zanedlouho vyjde Fedora Asahi Remix 43. Vývojáře lze podpořit na Open Collective a GitHub Sponsors.
Iniciativa Open Device Partnership (ODP) nedávno představila projekt Patina. Jedná se o implementaci UEFI firmwaru v Rustu. Vývoj probíhá na GitHubu. Zdrojové kódy jsou k dispozici pod licencí Apache 2.0. Nejnovější verze Patiny je 13.0.0.
Obrovská poptávka po plynových turbínách zapříčinila, že datová centra začala používat v generátorech dodávajících energii pro provoz AI staré dobré proudové letecké motory, konvertované na plyn. Jejich výhodou je, že jsou menší, lehčí a lépe udržovatelné než jejich průmyslové protějšky. Proto jsou ideální pro dočasné nebo mobilní použití.
Typst byl vydán ve verzi 0.14. Jedná se o rozšiřitelný značkovací jazyk a překladač pro vytváření dokumentů včetně odborných textů s matematickými vzorci, diagramy či bibliografií.
Specialisté společnosti ESET zaznamenali útočnou kampaň, která cílí na uživatele a uživatelky v Česku a na Slovensku. Útočníci po telefonu zmanipulují oběť ke stažení falešné aplikace údajně od České národní banky (ČNB) nebo Národní banky Slovenska (NBS), přiložení platební karty k telefonu a zadání PINu. Malware poté v reálném čase přenese data z karty útočníkovi, který je bezkontaktně zneužije u bankomatu nebo na platebním terminálu.
V Ubuntu 25.10 byl balíček základních nástrojů gnu-coreutils nahrazen balíčkem rust-coreutils se základními nástroji přepsanými do Rustu. Ukázalo se, že nový "date" znefunkčnil automatickou aktualizaci. Pro obnovu je nutno balíček rust-coreutils manuálně aktualizovat.
VST 3 je nově pod licencí MIT. S verzí 3.8.0 proběhlo přelicencování zdrojových kódů z licencí "Proprietary Steinberg VST3 License" a "General Public License (GPL) Version 3". VST (Virtual Studio Technology, Wikipedie) je softwarové rozhraní pro komunikaci mezi hostitelským programem a zásuvnými moduly (pluginy), kde tyto moduly slouží ke generování a úpravě digitálního audio signálu.
Open source 3D herní a simulační engine Open 3D Engine (O3DE) byl vydán v nové verzi 25.10. Podrobný přehled novinek v poznámkách k vydání.
V Londýně probíhá dvoudenní Ubuntu Summit 25.10. Na programu je řada zajímavých přednášek. Zhlédnout je lze také na YouTube (23. 10. a 24. 10.).
http://www.youtube.com/watch?v=QrtydD2u1N0&feature=kp
You won't be able to do local builds easily as they rely on the local RPM metadata. I didn't package the tools necessary to do a local mockbuild as I didn't need it.I believe I've seen a tool that is able to mirror the package database in different formats, but I wouldn't recommend(*) using that; mock is the way to go (*) really, don't do that, I've seen all kinds of troubles having their origin in build environment differences that haunt our RHEL developers
quilt setup doesn't always do the job well. Mock is too slow and too complicated for many developer tasks. That could be more or less fixed by adding --nodeps to fedpkg compile.
Mock is too slow and too complicated for many developer tasks.well ... in that case you should rethink the workflow probably, because I usually do not need to run mockbuild more than once for each release, so I'm not bothered by the slowness
and I'm not getting the "too complicated" part - for packager, it's just a matter of `fedpkg mockbuild` ... for the mock package maintainer, don't know how much it is tied to Fedora (e.g. the mentioned python version issue etc.) but I thought it is pretty universal?
well ... in that case you should rethink the workflow probablyI love when people ask me to use a less effective workflow just because they think it's the right thing to do.
because I usually do not need to run mockbuild more than once for each release, so I'm not bothered by the slownessI thought it was pretty clear that I'm not talking about basic maintainance tasks like bumping a release, rebuilding and leaving it until a new one comes. But to be honest, I'm not even using a local mockbuild for that, instead I'm using
koji build --scratch.
and I'm not getting the "too complicated" part - for packager, it's just a matter of `fedpkg mockbuild`I'm not specifically talking about cases
fedpkg mockbuild and waiting for a resulting RPM works well.
The use case for local builds is when you need to repeatedly try to compile the source with relatively small changes until the result of the compilation is good. From SUSE folks I know they're using quilt setup for that but that doesn't work for all packages, although it has the advantage of keeping the patches ready for editing. You could theoretically use rhpkg prep but that doesn't do the configure stage which is not a simple cut-n-paste as it uses some system-level rpmbuild variables.
When you're done with that, a slow final koji build is a natural followup, as you need to handle the dependencies properly and you want to get the installable RPM. Sometimes a local mock build can be useful as an alternative to the koji build, but that's another topic.
I can hardly imagine that a workflow that does not rely on a slow tool (be it mock or koji) that much could be less effective than the one which makes extensive use of itwell ... in that case you should rethink the workflow probablyI love when people ask me to use a less effective workflow just because they think it's the right thing to do.
I thought it was pretty clear that I'm not talking about basic maintainance tasks like bumping a release, rebuilding and leaving it until a new one comes. But to be honest, I'm not even using a local mockbuild for that, instead I'm using koji build --scratch.
but that's the only point where do you need to actually build the package, be it local rpmbuild/mock/koji (the last being the slowest in a typical case, so ...) - I'm not getting why do you talk about mock slowness then ...
I'm not specifically talking about cases fedpkg mockbuild and waiting for a resulting RPM works well.
I'm completely lost then ...
The use case for local builds is when you need to repeatedly try to compile the source with relatively small changes until the result of the compilation is good.ok, but "compile the source" != "build the package" ... seems we're too generic here, I'd need some concrete example to understand what are you trying to achieve ... but I can live without that happily
%prep phase and also part of the %configure phase as RPM is pretty dumb and doesn't distinguish between configuration and compilation, as some other build systems do.
When I want to check whether something works while doing my own little tweaks, I need to step in the build process when it's about to call make, or I can live with stepping in just after. That's possible with mock as well, but it's incredibly slow. And it's just as incredibly slow to reset the state with mock, as its caching capabilities don't seem to be very good.
That you can live without that is fair. Bud to advise an active developer to use a slower way using mock just because you're not familiar with the faster way is just ridiculous.
Mňa by skôr od Pavlixa zaujímalo prečo chce balíčkovať bez riešenia závislostí na konkrétnej vetve Fedorky, alebo mi niečo uniklo?
To sa čudeješ, vieš koľko Jílkových blogových zápiskov tu musel prečítať, to musí zanechať stopyKdo se pročetl až na konec, tak ví, že ten článek je needitovaný výblitek, protože na nějaké vyšperkované povídání jsem neměl čas. Už tak jsem šel spát dost pozdě.
Mňa by skôr od Pavlixa zaujímalo prečo chce balíčkovať bez riešenia závislostí na konkrétnej vetve Fedorky, alebo mi niečo uniklo?Pokud reaguješ na článek, tak uniklo. Ty zabalené nástroje komunikují s fedoří build infrastrukturou, která závislosti řeší tak jak je u RPM distribuce zvykem. Pokud na komentář výše, tak
fedpkg compile používám proto, abych bez zbytečného zdržování dostal adresář, ve kterém můžu dělat úpravy a pouštět make.
Popravdě řečeno, kontrola závislostí ve fedpkg compile je úplně na hovno. Ve Fedoře stejně předtím zavolám yum-builddep a tudíž mám závislosti nainstalované a zkontrolované. Mimo Fedoru nemá fedpkg compile data pro nějakou relevantní kontrolu.
Předpokládám, že se mi právě ozvali dva zapálení fedoří maintaineři.hm, třetí do party.
Tiskni
Sdílej: